attachment-0001

<html> I vote NO for the proposal to remove textWithoutLanguage and nameWithoutLanguage. I could be persuaded to change my vote with cogent arguments. If this change had been proposed 9 months ago, I might have supported it. But now I have written the code, and I suspect others have too.  If an implementer views textWithLanguage and nameWithLanguage as the true internal data types, and views textWithoutLanguage and nameWithoutLangage as protocol optimizations, then the code for handling textWithoutLanguage and nameWithoutLangage is trivial. Ripping out the existing code to conform with the proposal is probably about as much work as adding code to handle the existing specification. There are more severe implementation problems with the IPP design, such as the encoding of an empty set.  It is the keyword "none" for some values and the enum 3 (for 'none') for other values. An out-of-bound value of "none" would have been a better choice. Historically, we arrived at this solution because we believed that textWithoutLanguage and nameWithoutLangage were a 95% or better solution.  We added the textWithLanguage and nameWithLanguage types to handle the very unusual case where a server is operating in a multilingual environment.  When we added the textWithLanguage and nameWithLanguage types, we decided not to delete the textWithoutLanguage and nameWithoutLangage types because we didn't want clients and servers operating in the most typical environment to deal with the overhead of textWithLanguage and nameWithLanguage. Perhaps we were overly concerned with overhead for this mechanism where we weren't in other parts of the protocol. Bob Herriot At 07:53 AM 10/21/98 , Hastings, Tom N wrote: >Summary:  This mail messages proposes to remove the 'textWithoutLanguage' >and 'nameWithoutLanguage' attribute syntaxes and require all 'text' and >'name' attributes to always explicitly include the natural language using >the 'textWithLanguage' and 'nameWithLanguage' syntaxes. > >************************************************************* >* The proposal to vote on is to require all attributes to always >* use the 'textWithLanguage' and 'nameWithLanguage' forms >* and to delete the 'textWithoutLanguage' and >* 'nameWithoutLanguage' forms. >* >* Please indicate your acceptance or rejection of this >* proposal on the mailing list by Monday, Nov 2. >************************************************************* > >This change will affect implementations that correctly implement the June >1998 Mode and Semantics specification.  Implementations that only support >the 'textWithoutLanguage' and 'nameWithoutLanguage' would need to be changed >to conform to either the June specification or this proposal (and changing >to this proposal would be easier than the June specification which requires >supporting both forms of 'text' and both forms of 'name'). > >Background: > >Currently requests and responses that supply 'text' and 'name' attributes in >a different natural language than that supplied for the request or response >as a whole as indicated in the "attributes-natural-language" Operation >attribute MUST include the different natural language explicitly as an >override (and MAY include it explicitly even when they are the same -- >according to the NLO 2 of 4 clarification).  > >This proposal is to change the Natural Language Override mechanism so that >the 'text' attribute syntax is only 'textWithLanguage' and the 'name' >attribute syntax is only 'nameWithLanguage'.  In other words, each 'text' >and 'name' attribute would always contain the natural language explicitly as >part of the value.  (The Encoding and Transport specification - PRO - >specifies that 'textWithLanguage' and 'nameWithLanguage' values MUST be >encoded as 2 octets of length, the natural-language string, 2 octets of >length, and the text or name value.) > >Eliminating one of the two forms of 'text' and one of the two forms of >'name' attribute syntax will simplify comparison in job validation, since >the "xxx" attribute syntax code would have to match the corresponding >"xxx-supported". > >The PRO document would simply delete the 'textWithoutLanguage' and >'nameWithoutLanguage' attribute syntaxes. > > >This proposal does not change any other parts of the Model: > >1. The "attributes-natural-language" operation attribute in requests MUST >still be supplied by the client to indicate its preference for natural >language to be returned in responses as currently specified in Section >3.1.4.1 and 3.2.1.1.  > >Rationale:  So that an implementation that implements the OPTIONAL >"status-message" response attribute will know which natural language to use. > >2.  For create operations, the IPP Printer MUST still copy the >"attributes-natural-language" operation attribute supplied by the client to >the job object as currently specified in Section 3.2.1.1. > >Rationale:  Subsequent communication with the submitting user, such as >operator messages, notification using e-mail, and the job-sheets MAY want to >use the natural language of the job submitter. > >3.  All responses MUST return the "attributes-natural-language" operation >attribute as specified in 3.1.4.2, though it no longer has any effect on the >interpretation of any of the returned attributes. > >Rationale:  no need to change this behavior, since all implementations seem >to be doing it.  Removing it would save only 37-40 octets per response. > > > >Tom Hastings >(310) 333-6413 > </html>