I don't understand this sentence:
> All
> we have to say is that attributes whose values are of "type 4 keywor=
d |
> name" become "type 3 keyword | name" and we abolish "type 3 keywords=
".
-Carl
ipp-owner at pwg.org on 03/18/98 04:38:55 PM
Please respond to ipp-owner at pwg.org @ internet
To: ipp at pwg.org @ internet
cc:
Subject: IPP>MOD Suggest dropping type 4 keyword to simplify implemen
Tom and I discussed this issue and I agreed to write it up.
Summary
In the model document, all attributes whose values include "type 4 keyw=
ord"s
are actually "type 4 keyword | name". Name and type 4 provide two near=
ly
identical mechanisms that will burden IPP implementations and confuse
administrators.
I propose that we drop type 4 keywords and state that the "name" provi=
des
the sole mechanism for an administrator to add new values. If we want =
to
support multiple languages for administrator created names, we can allo=
w
name values to stand for a collection of names, each in a different
language. But this is not a protocol issue -- it is a server implementa=
tion
and administrator issue. It becomes a hint to implementors and does no=
t
change the protocol.
Details
The current model document has four levels of keywords from type1 to ty=
pe 4.
We intended that type 4 keywords would be created locally by
administrators, and that type 1 through type 3 would be registered with=
IANA
making them publicly known.
We intended that a client would map a keyword to some human-readable
localized string. For type1 through type 3, the mapping can be canned
because the keywords are all known at implementation time. Mapping of =
type
4 keywords require some ADDITIONAL mapping mechanism that an administra=
tor
can configure and clients can download. This idea was proposed in ISO D=
PA
and then removed from DPA. It has never been completed or implemented. =
I
don't think any of us really wants to implement this mechanism.
We intended that a client would display a name as is. So a client does=
n't
have to do anything special when an administor adds a new name. Current=
ly we
think of a name as existing in a single language on the server. From t=
he
clients standpoint name and text values have a single language associat=
ed
with them. But from an administrative and server standpoint, we could =
allow
a name value to stand for a collection of name values each in a differe=
nt
language. When a client requests and attributes with a name value, the=
client would receive the name in the language requested or, if not
available, the one in the server's configured language. The same rule c=
ould
apply to text.
For IPP version 1.0, we don't have to deal with the server end of this.=
All
we have to say is that attributes whose values are of "type 4 keyword =
|name" become "type 3 keyword | name" and we abolish "type 3 keywords".=
We
show indicate that the "name" exists for administrator to add values th=
at
are not supported by the implementation.
Bob Herriot
=