Subject: Re: IPP> PRO Section 9.7 vs. MOD section 4.3: need clarifica

From: Carl Kugler <[email-masked]>
Date: Mon, 6 Apr 1998 19:24:32 -0400

Tom Hastings wrote:
>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
>

So, attributes-charset and attributes-natural-language are MANDATORY Job
Description Attributes (4.3.23 and 4.3.24) only in the sense that a Printer
must support them.  I.e., it must be able return them if a client requests
them specifically?

>
>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.

But the context here is a Response, which surely is supplied by a
Printer, never a client?

Why aren't the attributes-charset and attributes-natural-language (M*) for
"Group 3: Job Object Attributes"?

>
>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
>>
>>
>>
>>[email-masked] on 04/06/98 01:48:31 PM
>>Please respond to [email-masked]
>>To: [email-masked], Carl Kugler/Boulder/IBM@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.
>>>
>>
>>

---

From: Tom Hastings <[email-masked]>
Date: Mon, 6 Apr 1998 17:44:43 PDT

Responses buried in this thread.

Tom

>must support them.  I.e., it must be able return them if a client requests

More than that.  An IPP object must accept attributes-charset and
attributes-natural-language as operation attributes and take action as
specified
by the semantics of those operation attributes.

>But the context here is a Response, which surely is supplied by a

I think it would help to write the above separately for requests
and responses which are separate parts of section 15.3.4.3.

>"Group 3: Job Object Attributes"?

Because they are Group 1 operation attributes in all requests and
all responses.  They just happen to also be copied to the Job object 
on create requests.  So a client could request "attributes-charset" and
"attributes-natural-language" job attributes in a Get-Jobs or 
Get-Job-Attributes operation and get back the values (in Group 3)
that had been copied to the job object in the create request.

But the "attributes-charset" and "attributes-natural-language" that always
come back in Group 1 in the response to such a request don't have 
anything to do with the values that come back in Group 3 in such a 
response.  The Group 1 reponse MUST be the same as the requester
supplied in the Get-Jobs Group 1 request, which is independent of what
was supplied (often by some other client) on the create request that
created the Job object in the first place.