A good summary.
Tom
>-----Original Message-----
>From: Hugo Parra [mailto:HPARRA@novell.com]
>Sent: Friday, November 06, 1998 15:04
>To: ipp@pwg.org; kugler@us.ibm.com
>Subject: Re: IPP> MOD> Issue 1.19
>
>
>Carl wrote:
>
>> Were these concerns discussed any further before Issue 1.19
>was moved to
>> the Approved Clarifications List and into the new Mod doc?
>If so, could
>> someone point me to the discussion (I've been out of town
>for a while).
>>
>> -Carl
>
>I don't think we articulated a definite answer to this
>question. The desired behavior might not be far from what's
>currently documented but one or two clarifying statement may
>be necessary. To address the questions raised by Carl, I propose that:
>
>1. The "attribute-charset" attribute be required to be the
>first operation attribute. [Same as currently documented]
>
>2. A request (or response) containing more than one
>"attribute-character" attribute should be rejected. [As
>currently documented]
>
>3. All responses use the same 'valid' "attribute-charset"
>received in the corresponding request (i.e., the first
>operation attribute, if supported) [Might need to be
>clarified in the current doc]
I think that the first paragraph in "attributes-charset" in Section 3.1.4.2
is pretty clear:
This operation attribute identifies the charset used by any 'text' and
'name' attributes that the Printer object is returning in this response.
The value in this response MUST be the same value as the
"attributes-charset" operation attribute supplied by the client in the
request. If this is not possible (i.e., the charset requested is not
supported), the request would have been rejected. See "attributes-charset"
described in Section 3.1.4.1 above.
The sentence referred to in Section 3.1.4.1 is:
If the Printer object does not support the client supplied charset value,
the Printer object MUST reject the request and return the
'client-error-charset-not-supported' status code and any 'text' or 'name'
attributes using the Printer's "charset-configured" charset.
>
>4. The IPP object should always attempt to retrieve the
>"attribute-charset" attribute from the request (i.e., the
>first operation attribute) even if it has detected errors with
>the version, operation, or request numbers, and use it in the
>response informing the error condition. [Needs to be
>clarified in the current doc]
I think this is a good add as a SHOULD to the Model document.
>
>5. Whenever an IPP object cannot obtain a 'valid'
>"attribute-charset" attribute from the request (because it
>gets a request without an "attribute-charset" attribute as the
>first operation attribute or because it's given an attribute
>set is doesn't support) the response should be given in the
>server's default charset. [Needs to be clarified in the current doc]
I think that the sentence from 3.1.4 1 above is clear enough, don't you?
>
>6. Reporting a duplicate "attribute-charset" attribute error
>does not take any precedence over reporting any other error
>condition. The IPP object should not need to parse the entire
>request first to make sure the "attribute-charset" attribute
>appears once and only once in the request. [Needs to be
>clarified in the current doc]
There as been some debate about duplicate attributes. Its hard to detect
duplicates. Lazy or forgiving servers would just accept the first
attributes-charset that it found, since its supposed to be first.
Section 16.3.4.3 says that an IPP object rejects duplicates, but there is no
SHALL or SHOULD, so this section is just a recommendation, not a
requirement.
>
>Did I miss anything?
>
>-Hugo
>