IPP Mail Archive: RE: RE: IPP> NLO votes [nlo 4 of 4 - Issue 1.48]

IPP Mail Archive: RE: RE: IPP> NLO votes [nlo 4 of 4 - Issue 1.48]

RE: RE: IPP> NLO votes [nlo 4 of 4 - Issue 1.48]

Hastings, Tom N (hastings@cp10.es.xerox.com)
Thu, 5 Nov 1998 18:16:35 -0800


If our tentative agreement on nlo 4 of 4 to keep both text/nameWithLanguage
and text/nameWithoutLanguage, then we still need the
"attributes-natural-language" in the response to tell what the implicit
natural language is for any text/nameWithoutLanguage, correct?

On the other hand, if we reverse ourselves and do decide to remove
text/nameWithoutLanguage, then I agree with you, we can make the
"attributes-natural-language" in a response, just a MAY. In fact, we could
go even further to make it a SHOULD NOT. But we don't want to rule it out
altogether, since there be implementations that are always returning


>-----Original Message-----
>From: Carl Kugler [mailto:kugler@us.ibm.com]
>Sent: Wednesday, November 04, 1998 10:02
>To: ipp@pwg.org
>Subject: Re: RE: IPP> NLO votes
>> >Carl and others, including Keith Moore, have tried to express
>> >that the NL/NLO
>> >scheme is unduly complex and prone to error. Carl's proposal
>> >represents a
>> >simpler scheme where every text and name attribute would have
>> >an explicit
>> >natural language thereby simplifying the implementation with
>> >fewer attribute
>> >syntax's, and reducing the number of attributes which have
>> >multiple syntax's -
>> >all with NO LOSS of functionality.
>> Exactly. NLO 4 of 4 proposes exactly that: Drop
>textWithoutLanguage and
>> nameWithoutLanguage
>> and always use textWithLanguage and nameWIthLanguage in requests and
>> responses. But 4 of 4 (unlike Carl's proposal) does not change the
>> "attributes-natural-language" Operation attribute in
>requests and keeps it
>> in responses as well for compatibility (though its not used).
>I disagree strongly with keeping the (unused)
>"attributes-natural-language" Operation attribute in
>responses. If it's not necessary let's apply Occam's Razor
>and get rid of it. Useless appendages just cause confusion
>for implementors. For example, what value should be sent?
>How does the client check the received value?
>I'd go along with leaving it in as a MAY, purely for
>historical reasons, with a note to the effect that it's there
>only for compatibility and it is to be ignored.
> -Carl
>See the original message at http://www.egroups.com/list/ipp/?start=4717
>Free e-mail group hosting at http://www.eGroups.com/