Tom
At 16:24 04/06/1998 PDT, Carl Kugler wrote:
>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?
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.
>
>>
>>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?
I think it would help to write the above separately for requests
and responses which are separate parts of section 15.3.4.3.
>
>Why aren't the attributes-charset and attributes-natural-language (M*) for
>"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.
>
>>
>>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@Eng.Sun.COM on 04/06/98 01:48:31 PM
>>>Please respond to robert.herriot@Eng.Sun.COM
>>>To: ipp@pwg.org, 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.
>>>>
>>>
>>>
>
>