Subject: IPP>MOD Suggest dropping type 4 keyword to simplify implementations

From: Robert Herriot <[email-masked]>
Date: Wed, 18 Mar 1998 15:38:05 -0800

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 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