At 14:28 04/06/1998 PDT, Carl Kugler wrote:
>Thanks, Bob, I think I get it now.
>>Maybe your answer also provides a clue to my next question:
>>If attributes-charset and attributes-natural-language Job Description
>Attributes are MANDATORY according to MOD/4.3, why aren't they shown as
>MANDATORY in "Group 3: Job Object Attributes" under
>> Print-Job Response:
> Print-URI Response:
> Create-Job Response:
> Send-Document Response:
> Send-URI Response:
> Get-Job-Attributes Response:
> Get-Jobs Response:
>>in MOD/15.3.4.3 "Validate the presence of a single occurrence of required
>Operation attributes"?
Because "attributes-charset" and "attributes-natural-language" MUST
be returned in Group 1 (not Group 3) as shown.
See sections 3.1.4.2 Response Operation Attributes and
Sections 3.2 Printer Operations under each Xxx Response Group 1.
As Bob explained, MANDATORY in the document mostly means that a
Server MUST support the attribute. It is a separate question as to whether
the client MUST supply a MANDATORY attribute and whether an IPP object
MUST return a MANDATORY attribute. In some cases, the client MUST
supply a MANDATORY attribute and in other cases the client NEED NOT
supply the MANDATORY attribute in a request. Similarly, in some cases,
an IPP object MUST supply a MANDATORY attribute and in other cases the IPP
object NEED NOT supply the MANDATORY attribute in a response.
We tried to avoid using the word MANDATORY and OPTIONAL to mean whether
a sender had to supply in a request or a response. We tried to only
use the words MANDATORY and OPTIONAL to mean whether an IPP object
had to implement or not.
So there are four combinations for attributes in requests, of which only
three are possible:
MANDATORY OPTIONAL for an IPP object to support
MUST supply we have we don't have
MAY omit we have we have
Keep those questions coming. We can always improve the spec and fix
bugs that you find.
>>Could it be that the word MANDATORY has different meanings in these two
>sections?
See above.
>> 4.3: MANDATORY ... attribute[s] MUST be supported by Printer objects.
>If it is not indicated as MANDATORY, then it is OPTIONAL
>> 15.3.4.3: MANDATORY attributes [are those] that an IPP object MUST
>support and that a client MUST supply
I think I see the confusion. The entire section in 15.3.4.3 is:
The following tables list all the attributes for all the operations by
attribute group in each request and each response. The left to right order
of the groups is the order that the client supplies the groups as specified
in Section 3.3. The order of the attributes within a group is arbitrary,
though the tables below lists the attributes in the following order with
the following notation:
(M) MANDATORY attributes that an IPP object MUST support and that a client
MUST supply
(M*) MANDATORY attributes that an IPP object MUST support, but that a
client may omit in a request or an IPP object may omit in a response
(O) OPTIONAL attributes that an IPP object NEED NOT support
(O*) OPTIONAL attributes that an IPP object NEED NOT support and a client
may omit in a request or an IPP object may omit in a response
The first line is NOT the definition of MANDATORY, but is explaining
the notation (M) which means MANDATORY and that a client MUST supply.
The notation (M*) in the second line is also MANDATORY, but a client MAY
omit. The presence or absence of the "*" indicates whether the MANDATORY
attribte (for support) MAY be omitted or not in a request or response.
Would the following rewording help:
In parenthesis the following notation is used:
M indicates a MANDATORY attirbute that an IPP object MUST support
O indicated an OPTIONAL attirbute that an IPP object NEED NOT support
* indicates that a client MAY omit the attribute in a request and that
an IPP object MAY omit the attribute in a response. The absence of
an * means that a client MUST supply the attribute in a request and
and an IPP object MUST supply the attribute in a response.
Perhaps there is a better notation than *? Perhaps surrounding the
attribute name itself inside [] would be a more familiar notation to
indicate what can be omitted in a request or a response?
>>It's still not clear to me.
>> -Carl
>>>>robert.herriot at Eng.Sun.COM on 04/06/98 01:48:31 PM
>Please respond to robert.herriot at Eng.Sun.COM>To: ipp at pwg.org, Carl Kugler/Boulder/IBM at ibmus>cc:
>Subject: Re: IPP> PRO Section 9.7 vs. MOD section 4.3: need clarifica
>>>If I understand your question correctly, I think that you have having the
same
>confusion
>that many other people have had about the word "MANDATORY". It means that
>the "Printer" must support the attribute. It does NOT mean that the attribute
>must
>be included in each request/response.
>>In this particular case, attributes-charset is MANDATORY, i.e. the printer
>must
>>support the attribute, but in the get-jobs reponse it MUST be in the
operation
>attributes
>group and it is only in each job attribute group if the client requested the
>attribute via the
>requested-attributes attribute in the request. Note, even if it is present
>in a
>job attributes
>group it does not affect the charset of those attributes. All attributes in
>the entire
>response are in the charset specified by attributes-charset in the operations
>attribute
>group, which I still believe must be first in that group (a change we need to
>make
>to the model document).
>>Note that in the example attributes-natural-language is in one of the job
>attribute
>groups in order to override the natural-language in the operation attributes.
>As I
>have been implementing IPP, I have come to believe that this was a bad idea.
>It again
>requires a special ordering, i.e. attributes-natural-language must precede
all
>other
>attributes if processing is to be simple.
>>Bob Herriot
>>>At 03:34 PM 4/3/98 , Carl Kugler wrote:
>>Looking at example 9.7, Get-Jobs Response, I don't see an attributes-charset
>>attribute in any of the three job attributes groups.* But section 4.3 of the
>>Model document, "Job Description Attributes", says that
attributes-charset is
>>MANDATORY in the "job-description" attribute group.* This is causing me
>>cognitive dissonance.
>>>>>>>>