Don,
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.
Tom
At 12:05 10/21/1997 PDT, don at lexmark.com wrote:
>>Tom Hastings said:
>>>Take the "job-name" (name) attribute as an example.
>>>>Windows clients puts the name of the application as the first n characters
>of
>>the job name, followed by a dash and the document file name.
>>So "Microsoft Word - ", takes up 17 characters. But BSD lpq only
>>returns 18 characters in the lpq command (at least on my system
>>produced by another company in the PWG).
>>So only the first letter of the document is shown in the list of jobs in
>>the lpq command! Not exactly helpful.
>>>>>>But RFC 1179 says that the job name is up to 99 characters (analoguous
>>to our statement about up to 255 octets in IPP 'name' attribute syntax).
>>Remember RFC1170 is not a standard. It documented existing practice
>and some implementations.
>>We could get the same sort of disconnect in IPP implementations, if we
>>don't agreee as to what a conforming implementation SHALL accept, store,
>>and return in operation responses.
>>>>I don't see the market place helping to fix the different ideas about
>>the length of the job-name between Windows and LPD. Lets not repeat
>>this same mistake for IPP.
>I bet most of the LPD implmentations were originally written before
>any applications generated job-names longer than 18 characters!!
>No one noticed -- no one cared -- until Windows came along.
>>>For clarity, I think we should add some kind of NOTE to "job-name" to
>>indicate that the client MAY add an application name as part of the
>>job-name, to make it clear to all (clients, users, IPP Printer object
>>implementors), that the job-name may not be just the document name
>>and/or file name. Then they might allocate a few more characters
>>to the job name. I suggest something like, after the 4th sentence:
>>>>If the user doesn't supply an explicit job name, the client MAY
>>automatically supply a job name that consists of the document name
>>(or file name) and, possibly, the application program name.
>>If IPP says the job-name is x octets and some implementation
>only supports 16 octets I suspect that market pressures will
>force compliance. In a world now used to browsers and the
>GUI interfaces, a truncated job-name will stand out like a
>sore thumb. In the only recently GUI-ed UNIX world, everyone
>expects highly irregular and inconsistent print implementations.
>There will be a lot of reviews in magazines, etc. because
>this is going to hit the mainstream Windows users. What are
>they maybe one or two magazines that review Unix?
>>As I said before, if we were to look at every little corner
>and find places like this there would be so many SHALLs
>shouting at the reader that the standard would be unreadable.
>>Don
>>**********************************************
>* Don Wright don at lexmark.com *
>* Manager, Strategic Alliances and Standards *
>* Lexmark International *
>* 740 New Circle Rd *
>* Lexington, Ky 40550 *
>* 606-232-4808 (phone) 606-232-6740 (fax) *
>**********************************************
>>>>