IPP Mail Archive: RE: IPP>MOD: Problem in IPP encoding with "attributes-charset"

RE: IPP>MOD: Problem in IPP encoding with "attributes-charset"

Turner, Randy (rturner@sharplabs.com)
Sat, 21 Mar 1998 15:19:16 -0800

I believe we have found some other hidden dependencies that are similar
to this, but we just reorder the logic of our attribute processing in
order to "do the right thing". While doing in this in the protocol
specification may help some implementations, it hasn't hindered our
efforts too much. But then again our server is only a proof-of-concept
implementation with limited capability. But even with our prototype,
taking the attributes in a particular order hasn't been too difficult.
If the WG agrees to make this change to the documents, I would have no
problem with it.

Randy
-----Original Message-----
From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM]
Sent: Friday, March 20, 1998 6:02 PM
To: ipp@pwg.org
Subject: IPP>MOD: Problem in IPP encoding with
"attributes-charset"

I have found a problem that relates to the "attributes-charset"
and
"attributes-natural-language" attributes.

They must be in the first group of attributes (the operation
attributes),
but they need not be first in the operation attributes group
because the IPP
model document states that attributes in groups such as
"operation
attributes" are unordered. Except for this case, that is good.
But the
charset and natural language are special because they determine
how name and
text values of all attributes should be interpreted. Such a text
or name
attribute may precede the occurrence of "attributes-charset" and

"attributes-natural-language".

This makes an implementation more difficult because it cannot
convert the
octet string of the protocol to an internal String until it has
found the
"attributes-charset" value which could come many attributes
later.

We need to change the documents to state that two attributes
need to be
first in the operations group, even though attributes in groups
are
otherwise unordered.

How are you other implementors coping with this?

By the way, XML doesn't have this problem because the charset
comes at a
specific place at the very beginning and the language
specification always
precedes the text which it applies to.

Bob Herriot