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
>
--=====================_-1264620258==_.ALT
Content-Type: text/html; charset="us-ascii"
I vote NO for the proposal to remove textWithoutLanguage and
--=====================_-1264620258==_.ALT--
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
>