I wish that we could depend on the market place and product acceptance
to get reasonable behavior from various vendors that have products
that customers try to get to work together. But if each vendor has a
different idea about the agreements, then the products won't fit together
the way that the customer would hope.
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).
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.
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.
Tom
At 05:24 10/21/1997 PDT, don@lexmark.com wrote:
>
>Tom Hastings said:
>>
>>Our current Model text gives upper bounds on the lengths of the 'text' and
>>'name' attributes as 4095 and 255 octets, respectively. However, we don't
>>say how many of those octets a Printer object SHALL store. We also don't
>>say what happens if a client supplies a value that is longer than
>>the maximum size that a Printer supports.
>>
>>These are two issues that will affect interoperability.
>>
>>I suggest that we add two sentences something like:
>>
>>A Printer object SHALL support at least nnn octets in requests and
>responses.
>>If a client supplies a value that exceeds nnn, the Printer object SHALL
>>truncate the value on the right after the nnn-th octet.
>>
>>I propose that 'nnn' be 255 for text and 127 for names. UTF-8 takes about
>>1.7 octets per character on average for Western European names.
>>
>>Comments? Lets discuss at Wednesdays telecon.
>IMHO, people who read what we have and don't design to what you have
>explicitly
>required deserve the wrath of the users they will surely get. I can't see
>wasting the
>toner for two more paragraphs of SHALLs for something that is intuitively
>obvious. I'm not going to waste my time but I suspect if I looked, I could
>find 1000 other places where we have not defined every word of the Emglish
>language.
>
>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) *
>**********************************************
>
>
>
>