Re: character sets: Term as OCTET STRING

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