- From: Ray Denenberg <rden@loc.gov>
- Date: Tue, 09 Jul 2002 10:33:37 -0400
Pieter Van Lierop wrote: > Does this mean that the character set negotiation for Term as OCTET STRING > does not apply for Z39.50 version 3 ?? Yes, that's what it means. The proposal at http://www.loc.gov/z3950/agency/zig/meetings/oclc2002/charneg-4.html was approved at the April meeting (sorry, I haven't yet updated the definitions). We had seemingly endless discussion during several months leading up to the meeting and I hope we don't have to re-hash all of it. But to summarize: As background, "Character Set and Language Negotiation" had meant *both* "character set" and "language" for version 3 *but only* "language" for version 2. The reason being that in version 2 term could only be OCTET STRING and so there was no way to distinguish whether a term represented character or binary data. Version 3 provides that by supporting additional datatypes (notably, InternationalString) for Term. So when we originally defined the negotiation, we didn't bother to provide for character support for version 2. The proposal came about because some folks wanted a way, albeit crude, to extend character set negotiation to version 2. That was the sole motivation; there was no need expressed to amend the definition with respect to version 3. And why would you need character set negotiation to apply to OCTET STRING if you're using version 3? One of the primary features of version 2 is the additional datatypes for term. And the reason for it (one of them) is to be able to distinguish character from binary data. If you negotiate the meaning of octet string, you'll have a hard time sending binary data on that association. So that's a limitation you have to live with for version 2, not for version 3. --Ray
Received on Tuesday, 9 July 2002 10:32:42 UTC