It looks like we have agreement to add the text about the range of the
data types to the "5.2 Printer Object Conformance Requirements" section.
You bring up a good question about the client and the range.
1. I suggest that we add the same sort of statement to section "5.1 Client
Conformance Requirements".
The current third paragraph reads:
A client SHALL be able to accept any of the attribute syntaxes defined in
Section 4.1 that may be returned to it in a response from a Printer
I suggest that we change it to read:
A client SHALL be able to accept any of the attribute syntaxes defined in
Section 4.1, including their full range, that may be returned to it in a
response from a Printer object.
2. We could also add something like we have in the second paragraph about
example client implementations. Perhaps something like:
Truncation of long attribute values is not recommended. A recommended
approach would be for the client implementation to allow the user to
scroll through long attribute values.
3. Now that we have MANDATORY (and OPTIONAL) "operation attributes" we need
to fix the second paragraph from:
When sending a Get-Attributes or create request, an IPP client need not
supply any attributes.
to:
When sending a Get-Attributes or create request, an IPP client NEED NOT
supply any OPTIONAL attributes.
Comments?
Tom
At 05:23 10/22/1997 PDT, don@lexmark.com wrote:
>
>Tom Hastings said:
>
>>How about if we just clarify the conformance section that talks about
>>implementation of the attribute syntaxes. Then we won't be adding any
>>more SHALLs, but we will be clarifying that the ranges of each syntax
>>is required? Then it will be clear that 'text' attributes are 4095 octets
>>and 'name' are 255 octets. (So far there are no 'text' attributes that
>>a client can supply and only 3 'name' attributes: "document-name",
>>"job-name", and "job-originating-user".) For those attributes that
>>can only be returned, if an implementation has a lower limit, who is to
>>know?
>>
>>The current text is:
>>
>>5.2.5 Attribute Syntaxes
>>A Printer SHALL be able to accept any of the attribute syntaxes defined in
>>Section 4.1 in any operation in which a client may supply attributes.
>>Furthermore, a Printer SHALL return attributes to the client in operation
>>responses that conform to the syntax specified in Section 4.1.
>>
>>I propose that we clarify it as:
>>
>>5.2.5 Attribute Syntaxes
>>A Printer SHALL be able to accept any of the attribute syntaxes defined in
>>Section 4.1, including their full range, in any operation in which a
>client
>>may supply attributes. Furthermore, a Printer SHALL return attributes to
>>the client in operation responses that conform to the syntax specified in
>>Section 4.1, including their full range if supplied previously by a
>client.
>
>I like this much better but I have one question -- shouldn't clients have
>to follow the same rule for anything that come from the IPP printer, i.e.
>you bomb out if the job-uri is really long?
>
>Don
>
>**********************************************
>* Don Wright don@lexmark.com *
>* Manager, Strategic Alliances and Standards *
>* Lexmark International *
>* 740 New Circle Rd *
>* Lexington, Ky 40550 *
>* 606-232-4808 (phone) 606-232-6740 (fax) *
>**********************************************
>
>
>
>