All we have to say is that attributes whose values are of=A0 "type 4=
keyword |
name" become=A0 "type 3 keyword | name" and we abolish "type 4 keywords".
At 08:25 AM 3/19/98 , Carl Kugler wrote:
>I don't understand this sentence:
>
>> All
>> we have to say is that attributes whose values are of=A0 "type 4 keyword=
|
>> name" become=A0 "type 3 keyword | name" and we abolish "type 3 keywords".
>
>=A0 -Carl
>
>
>
>
>ipp-owner@pwg.org on 03/18/98 04:38:55 PM
>Please respond to ipp-owner@pwg.org @ internet
>To: ipp@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=
keyword"s
>are actually "type 4 keyword | name".=A0 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"=A0=
provides
>the sole mechanism for an administrator to add new values.=A0 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.=A0 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.=A0 For type1 through type 3, the mapping can be canned
>because the keywords are all known at implementation time.=A0 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.=A0 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.=A0 From the
>clients standpoint name and text values have a single language associated
>with them.=A0 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.=A0 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=A0 "type 4 keyword |
>name" become=A0 "type 3 keyword | name" and we abolish "type 3 keywords".=
=A0 We
>show indicate that the "name" exists for administrator to add values that
>are not supported by the implementation.
>
>Bob Herriot
>=20