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

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

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

Hastings, Tom N hastings at cp10.es.xerox.com
Thu Nov 5 21:16:35 EST 1998


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 at us.ibm.com]
>Sent: Wednesday, November 04, 1998 10:02
>To: ipp at 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/

More information about the Ipp mailing list