SM> IPP/SM ISSUE 10: Name of JobMandatoryElements

SM> IPP/SM ISSUE 10: Name of JobMandatoryElements

Hastings, Tom N hastings at cp10.es.xerox.com
Fri Jan 17 16:55:24 EST 2003


Here is ISSUE 10 to be added to the 9 ISSUE.  This one affects both the IPP
Document object spec and the PWG Semantic Model document.

Version 0.6 of the IPP Document object specification aligns with the
attributes of the Semantic Model version 0.18.

The Semantic Model has the Job Description Element: JobMandatoryElements
The values are a list of Element names of the Job Processing and Document
Processing Elements that the submitter wants to be Mandatory, else the
provider MUST reject the request.

The IPP Document object spec has the "job-mandatory-attributes" (1setOf
type2 keyword) operation attribute which the Printer copies to the
corresponding "job-mandatory-attributes" Job Description attributes.  The
values are a list of the keyword names of the Job Template and Document
Template attributs that the submitter wants to be Mandatory, else the
provider MUST reject the request.

Neither spec allows this same Element/attribute to also be a Document
Description Element/attribute.  This simplification is fine.  So whatever
Job and Document Elements/attributes are declared to be mandatory at the Job
level must be mandatory at the Document level as well.

A possible extension in the future might be to allow the submitted to submit
this Element/Attribute in a Document Creation request.  If that ever
happens, we will regret that its name started with "Job"/"job-", because we
have to invent a new name with the "Job"/"job-" prefix either removed or
change to something else, like "Document"/"document-".  Since the values are
already contaiing both job and document attributes, I don't see any problem
with just dropping the "Job"/"job-" prefix now.  But I'm not suggesting that
the renamed Element/attribute can be submitted at the Document level.

A further agrument of removing the "Job"/"job-" prefix is that a closely
relate Element/attribute: ElementFidelity/"ipp-attribute-fidelity" is also
limited to being a Job level attribute by being a Job Description attribute
and not a Document Description attribute.  However, it too also affects both
job and document attributes making them all mandatory.

Comments?

Tom

-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Friday, January 17, 2003 02:46
To: sm at pwg.org
Subject: SM> Version 0.6 of the IPP Document object specification is
available


I've stored version 0.6 of the IPP Document object on the PWG server at:

ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-latest.doc
which are the same as:
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113.doc

The version with revision marks is available at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113-rev
.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/pwg-ipp-document-object-v06-030113-rev
.doc

Version 0.6 contains the agreements reached at the last PWG face to face and
on the SM telecons.
Version 0.6 also aligns with version 0.18 of the PWG Sementic Model just
posted.

The issues will be reviewed during the PWG Semantic Model face to face
meeting, Thursday, 23.
Is this specification ready for Last Call?


Here are 9 ISSUES:
ISSUE 01:  It is the [override] specification the allowed these four
"compression", "document-format", "document-name", and
"document-natural-language" operation attributes to be supplied in the
Create-Job request.  There needs to be a way for a client to query to see
what was submitted.  Possible solutions:
a. OK to have the exception to the no copy down rule for these four which do
not have any corresponding Job Description attributes to hold them?
Otherwise, there would be no queriable record of what the client had
supplied when the client only supplies them in the Create-Job operation.  
b. Or would it be better, simpler, and more consistent to define the four
corresponding Job Description attributes and have the Printer just copy the
operation attributes to them, like most other operation attributes?  
c. Or should we forget the [override] extension and go back to the RFC2911
Create-Job definition (see [RFC2911] section 3.2.4) which does not allow
these four operation attributes to be submitted in the Create-Job, but
requires that the client supply them each time in each Send-Document and
Sent-URI operation, if the client wants to submit them at all.  Then the
Printer just copies them to the corresponding Document Description
attributes and there is no inheritance problem between the Job and Document
level for these four attributes.

ISSUE 02:  Should we DEPRECATE the use of the "document-overrides" operation
attribute in Send-Document and Send-URI when supporting this specification?
Or forbid?

ISSUE 03:  Should we DEPRECATE the use of the "pages-overrides" operation
attribute in Send-Document and Send-URI when supporting this specification?
Or forbid?

ISSUE 04:  Is the definition of "document-format-detail" OK?

ISSUE 05:  Should we call this member attribute "os-type", instead of
"platform", in order to agree with the PWG Printer Installation Extension
(see draft-ietf-ipp-install-04.txt)?

ISSUE 06: The effect of the IPP "page-overrides" Job Template attribute when
supplied at the job level of a multi-document job depends on the value of
the "multiple-document-handling" Job Template attribute.  For the
'single-document' and 'single-document-new-sheet' values, the pages are
numbered as a single set from 1 to n for the job as a whole.  For the
'separate-documents-collated-copies' and
'separate-document-uncollated-copies' values, the pages are numbered from 1
to n for each document separately.  ISSUE 06:  This is a change from
[override], OK?

ISSUE 07: The effect of the IPP "page-ranges" Job Template attribute when
supplied at the job level of a multi-document job depends on the value of
the "multiple-document-handling" Job Template attribute.  For the
'single-document' and 'single-document-new-sheet' values, the pages are
numbered as a single set from 1 to n for the job as a whole.  For the
'separate-documents-collated-copies' and
'separate-document-uncollated-copies' values, the pages are numbered from 1
to n for each document separately.   ISSUE 07:  This is a change from
[override], OK?

 ISSUE 08:  Need to add "job-password" to [prod-print2] as a Job Description
attribute to go along with the Operation attribute with suitable security in
Get-Job-Attributes response in order to align with the PWG Semantic Model,
OK?

 ISSUE 09:  Need to add "job-password-encryption" to [prod-print2] as a Job
Description attribute to go along with the Operation attribute with suitable
security in Get-Job-Attributes response in order to align with the PWG
Semantic Model, OK?


Version 0.6, 13 January 2003, agreements from New Orleans October PWG
meeting and subsequent telecons:
	1.	Deleted the Cancel-Current-Document and Validate-Document
operations.
	2.	Deprecated the "input-document-number" operation attribute
from the Document Creation operations.
	3.	Deleted the "document-mandatory-attributes" operation
attribute to align with the PWG Semantic model.  So both specifications have
only the "job-mandatory-attributes" operation attribute.  The client can
only supply at the Job Level.  The Document Level inherits from the Job
Level.
	4.	Increased "document-message" operation attribute length from
127 to MAX (1023) octets.
	5.	Clarified that "ipp-attribute-fidelity" and
"job-mandatory-attributes" can only be supplied at the Job Level; the
Document level inherits their values.
	6.	Added "ipp-attribute-fidelity" and
"job-mandatory-attributes" Job Description attributes.
	7.	Added the "media-size-name" as a member attribute of
"media-col" and as a separate Job Template attribute as used by UPnPv1 and
UPnPv2.
	8.	Added the "media-type" as a Job and Document Template
attribute on its own as used by  UPnPv1 and UPnPv2 (as well as leaving it as
a member attribute of the "media-col" Job and Document Template attributes).
	9.	Renamed "document-printer-up-time" Document Description
attribute to simply "printer-up-time".
	10.	Added the following Job Description attributes:
"ipp-attribute-fidelity", and "job-mandatory-attributes".
	11.	Removed the following Document Description attributes:
"ipp-attribute-fidelity".
	12.	Added the following Document Description attributes:
"document-format-detail", "document-format-detected", "job-id",
"job-printer-uri", "job-uri", "output-device-assigned".
	13. Defined all of the Document Description attributes, often with
references to other specifications, so that they appear in the table of
contents.

Send comments to the mailing list.

Thanks,
Tom

P.S. I'll not be attending the meeting.



More information about the Sm mailing list