Re: Z39.50 character encoding

If character set negotiation applied to all InternationalStrings transferred over the protocol (which seems much more consistent than just message and name strings transferred via the protocol [I had never known previously there was the list of which InternationalStrings character set negotiation applies to--thanks for the reference the other day!]), then query terms would also be negotiated by sending them as characterString (InternationalString).

I understand how language negotation would apply only to message strings, but what's really the motivation for limiting character set negotation to name and message strings?


  ----- Original Message ----- 


  Pieter Van Lierop wrote: 
     I went back to Ray's mail to see what the problem is.What is the problem?The problem is that Z39.50 implementations do not use the Z39.50 Character Set Negotiation. They have been not doing that for many years, so why suddenly this becomes a problem?So Ray maybe you could tell us which problem we are trying to solve, and why, and who wants it to be solved?

  It started as an urgent Bath issue, to specify the character set/encoding of a search term. Character set negotiation doesn't help much there.  We kicked that around for awhile, and then Joe Zeeman suggested that it's probably not productive to spend much time coming up with a mechanism for this (i.e. a new attribute, plus a list of values, and we would need to amend the architecture too) and he suggested that we declare Z39.50 to be a unicode/utf-8 protocol, and work backwards from there. We thought that was a good idea, and that's where we are now. 

  So: what problem are we trying to solve? specifying the encoding of a search term and a record.  Why not use character set negotiation?  because it doesn't help much. It's oriented towards message and name strings.  Who want it solved? Bath, for starts, and just about everyone else. 

  --Ray