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

From: Carl Kugler <[email-masked]>
Date: Mon, 6 Apr 1998 17:28:15 -0400

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"?

Could it be that the word MANDATORY has different meanings in these two
sections?

 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

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 15:31:24 PDT

>in MOD/15.3.4.3 "Validate the presence of a single occurrence of required

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

See above.

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

---

From: Robert Herriot <[email-masked]>
Date: Mon, 06 Apr 1998 16:17:46 -0700

Attributes-charset and attributes-natural-language must be in the operation
attributes group
for each request and each response.  This implies that the Printer must
support
these job
description attributes in order to show what values were sent with submit-job
operations.
Thus they are MANDATORY.

The job attributes group contains values of job attributes. For the Print-Job,
Print-URI,
Create-Job, Send-Document, Send-URI operations, there is no need for the job
attributes 
group to contain the attributes-charset and attributes-natural-language of the
job because they
normally have the same value the ones in the operation attributes group, and
those are the
important values for the response anyway. It was a judgement call as to which
attributes
to return automatically. We picked likely useful ones.

For Get-Job-Attributes and Get-Jobs, attributes-charset and
attributes-natural-language
would be present in the job attributes group only if the client had named them
explicitly
or implicitly in the "requested-attributes" attribute in the request.  Their
values might differ 
from those in the operation attributes group, especially if the job
belonged to
someone else.

Bob Herriot