>Subject: Re: IPP> ADM> IPP 1.0 Issues List?
>>>I wouldn't mind an issues list, but the ones that you mentioned were a=
ll
>raised and discussed at the last meeting. See comments below.
I'm glad to see these were discussed at the meeting! Some of these
issues have been around a while and wasn't aware of a plan or process
in place for resolving them so I piped up.
>>>1. "printer-uri" or "job-uri" mandatory and required op att? Form?
>>Discussed and resolved at the 5/20-21 meeting. See new text to be
>published by 5/29.. Meeting notes
>due out soon.
>>>2. Mixed case allowed in 'naturalLanguage' and 'charset' values?
>>What is the issue? The model document syntax rules for charset and
>naturalLanguage state that IPP does not allow mixed case. 4.1.9
>'charset' currently says:
The issue is that the protocol document shows mixed case used for
'naturalLanguage' and 'charset' values in the examples. Does the
MOD doc take precedence over PRO? Anyway, I'd bet that most existing
implementations are based more on the examples than anything else.
"Be conservative in what you send, lenient in what you accept, yada,
yada, yada."
>>"Though RFC 2046 requires that the values be case-insensitive US-ASCII=
,
>IPP requires all lower case to simplify comparing by IPP clients and
>Printer objects."
>>4.1.10 'naturalLanguage' currently says:
>>"Though RFC 1766 requires that the values be case-insensitive US-ASCII=
,
>IPP requires all lower case to simplify comparing by IPP clients and
>Printer objects."
>>>3. 'client-error-request-uri-too-long' vs.
>>'client-error-request-value-too-long' ? Types applied to?
>>Discussed and resolved at the 5/20-21 meeting. See new text to be
>published by 5/29 Meeting notes
>due out soon.
>>>4. "attributes-charset" and "attributes-natural-language" must alway=
s be
>>positioned up front?
>>Discussed and resolved at the 5/20-21 meeting. See new text to be
>published by 5/29 Meeting notes
>due out soon.
>>>>=