> we have to say is that attributes whose values are of "type 4 keywor=
> name" become "type 3 keyword | name" and we abolish "type 3 keywords=
email@example.com on 03/18/98 04:38:55 PM
Please respond to firstname.lastname@example.org @ internet
To: email@example.com @ internet
Subject: IPP>MOD Suggest dropping type 4 keyword to simplify implemen
Tom and I discussed this issue and I agreed to write it up.
In the model document, all attributes whose values include "type 4 keyw=
are actually "type 4 keyword | name". Name and type 4 provide two near=
identical mechanisms that will burden IPP implementations and confuse
I propose that we drop type 4 keywords and state that the "name" provi=
the sole mechanism for an administrator to add new values. If we want =
support multiple languages for administrator created names, we can allo=
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=
and administrator issue. It becomes a hint to implementors and does no=
change the protocol.
The current model document has four levels of keywords from type1 to ty=
We intended that type 4 keywords would be created locally by
administrators, and that type 1 through type 3 would be registered with=
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 =
4 keywords require some ADDITIONAL mapping mechanism that an administra=
can configure and clients can download. This idea was proposed in ISO D=
and then removed from DPA. It has never been completed or implemented. =
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=
have to do anything special when an administor adds a new name. Current=
think of a name as existing in a single language on the server. From t=
clients standpoint name and text values have a single language associat=
with them. But from an administrative and server standpoint, we could =
a name value to stand for a collection of name values each in a differe=
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=
apply to text.
For IPP version 1.0, we don't have to deal with the server end of this.=
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".=
show indicate that the "name" exists for administrator to add values th=
are not supported by the implementation.