attachment-0001

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