Charset clearly needs to be at the beginning so that a receiving process
knows how to decode string fields before it encounters any of them. The
charset field is a string field, but the names are all ASCII so the decoding
need not be known for the class of encodings that IPP support. BTW, XML puts
charset at the beginning for the same reason.
Natural language is the next most important value because it specifies the
language of any text or name field. Processing is easier if the implicit
language is known at the time a text or name field is encountered. XML has
similar rules for language.
The printer-uri/job-uri/job-id should be easy to find if it not in the
enclosing layer. For HTTP, the position of the target isn't important
because the target is redundant. The position would be important for a
transport where the target is specified only in IPP layer.
So that's the reasoning. Do you agree?
Bob Herriot
At 11:42 AM 6/8/98 , Paul Moore wrote:
>I obviously missed this one. So 'special position' means that literally. I
>thought it mean 'special purpose'.
>
>For my interest. Why are we putting things in special positions?
>
>> -----Original Message-----
>> From: Robert Herriot [SMTP:robert.herriot@Eng.Sun.COM]
>> Sent: Friday, June 05, 1998 8:46 PM
>> To: Paul Moore; 'Carl Kugler'; ipp@pwg.org
>> Subject: RE: RE: IPP> Identifying jobs in requests
>>
>> We agreed recently that the following operation attributes would be
>> ordered.
>> attributes-charset (always first for requests and responses)
>> attributes-natural-language (always second for requests and response)
>> printer-uri or job-uri (always third for requests, though we are
>> discusses whether it should be present)
>> job-id (always fourth for requests if present )
>>
>> At 05:00 PM 6/5/98 , Paul Moore wrote:
>> > I think we are approaching group consensus on this. I propose
>> that
>> >we remove "printer-uri" and "job-uri" as request Operation attributes,
>> but
>> >leave them in their special position in the protocol.
>> >
>> > [Paul Moore] What 'special position'?
>> >
>>
>
--=====================_6796152==_.ALT
Content-Type: text/html; charset="us-ascii"
Charset clearly needs to be at the beginning so that a
receiving process
knows how to decode string fields before it encounters any of them.
The
charset field is a string field, but the names are all ASCII so the
decoding
need not be known for the class of encodings that IPP support. BTW, XML
puts
charset at the beginning for the same reason.
Natural language is the next most important value because it specifies
the
language of any text or name field. Processing is easier if the
implicit
language is known at the time a text or name field is encountered. XML
has
similar rules for language.
The printer-uri/job-uri/job-id should be easy to find if it not in the
enclosing layer. For HTTP, the position of the target isn't
important
because the target is redundant. The position would be important for a
transport where the target is specified only in IPP layer.
So that's the reasoning. Do you agree?
Bob Herriot
At 11:42 AM 6/8/98 , Paul Moore wrote:
>I obviously missed this one. So 'special position' means that
literally. I
>thought it mean 'special purpose'.
>
>For my interest. Why are we putting things in special
positions?
>
>> -----Original Message-----
>>
From:
>>
Sent:
>> To:
>> Subject:
>>
>> We agreed recently that the following operation attributes would
be
>> ordered.
>> attributes-charset (always first for
requests and responses)
>> attributes-natural-language (always
second for requests and response)
>> printer-uri or job-uri (always third for
requests, though we are
>> discusses whether it should be present)
>> job-id (always fourth for requests if
present )
>>
>> At 05:00 PM 6/5/98 , Paul Moore wrote:
>> > I think we are
approaching group consensus on this. I propose
>> that
>> >we remove "printer-uri" and "job-uri" as
request Operation attributes,
>> but
>> >leave them in their special position in the protocol.
>> >
>> > [Paul Moore] What
'special position'?
>> >
>>
>
--=====================_6796152==_.ALT--