Summary
In the model document, all attributes whose values include "type 4 keyword"s
are actually "type 4 keyword | name". Name and type 4 provide two nearly
identical mechanisms that will burden IPP implementations and confuse
administrators.
I propose that we drop type 4 keywords and state that the "name" provides
the sole mechanism for an administrator to add new values. If we want to
support multiple languages for administrator created names, we can allow
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 implementation
and administrator issue. It becomes a hint to implementors and does not
change the protocol.
Details
The current model document has four levels of keywords from type1 to type 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 administrator
can configure and clients can download. This idea was proposed in ISO DPA
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 doesn't
have to do anything special when an administor adds a new name. Currently we
think of a name as existing in a single language on the server. From the
clients standpoint name and text values have a single language associated
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 different
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 could
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 that
are not supported by the implementation.
Bob Herriot