I agree that JPS2 definitely has an ambiguity in it about whether the "requesting-user-name" (operation attribute) or its corresponding "job-originating-user-name" (Job Description attribute) should be the keyword returned amongst the values of "job-creation-attribute-supported". There are two contradictory statements in JPS2:
This extension allows the IPP client to dynamically determine all the job attributes that it can specify at the time of
job creation.
all operation attributes that are written to the job object as job description attributes (e.g.,
"job-name") at the job level [which suggests that the the "requesting-user-name" operation attribute is a valid keyword which is written to the job object as the "job-originating-user-name" Job Description attribute]]
vs.
The list of attribute names in “job-creation-attributes-supported” MUST NOT include:
• collection member attribute names
Note: The client can determine which member attributes of “xxx” collection attributes are
supported by querying the “xxx-supported” Printer attribute (see [RFC3382]).
• operation attributes that are not job attributes [which suggests that "requesting-user-name" operation attribute is not a valid value]
I agree with Michael that the "requesting-user-name" keyword should be the valid value of "job-creation-attributes-supported". One way to clarify this would be to replace:
(e.g., "job-name")
with:
(e.g., the 'job-name' keyword value which indicates that the "job-name" operation attribute is copied to the "job-name" Job Description attribute and the 'requesting-user-name' keyword value which indicates that the "requesting-user-name" operation attribute is copied to the "job-originating-user-name" Job Description attribute)
Tom
Jan 19, 2011 02:58:21 PM, msweet at apple.com wrote:
===========================================
Ira,
I mainly ask because JPS2 is pretty specific about what keywords can be listed for job-creation-attributes-supported. Operation attributes that are not also job attributes are specifically excluded, however in the case of requesting-user-name there *is* a mirror job attribute called job-originating-user-name.
Now, I can't include job-originating-user-name in job-creation-attributes-supported since it isn't an operation or job template attribute. But at the same time I can't (currently) include requesting-user-name because it is only an operation attribute and not something that is exposed as a job attribute.
(FWIW, I am perfectly fine with the "include requesting-user-name" interpretation, I just want it to be the "accepted" interpretation within the PWG...)
On Jan 19, 2011, at 2:39 PM, Ira McDonald wrote:
Hi Mike,
The classic (RFC 2911) approach would be that "requesting-user-name"
is only an operation and not Job object attribute. The modern (IPP/2.0 SE)
approach would be to also list the required/allowed operation attributes.
I prefer the modern approach.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto:blueroofmusic at gmail.com
Christmas through April:
579 Park Place Saline, MI 48176
734-944-0094
May to Christmas:
PO Box 221 Grand Marais, MI 49839
906-494-2434
On Wed, Jan 19, 2011 at 1:25 AM, Michael Sweet wrote:
All,
In reviewing some implementation details of JPS2, I have a question about the contents of the job-creation-attributes-supported attribute. Specifically I am wondering about the requesting-user-name operation attribute - normally this gets mapped to the job-originating-user-name job description attribute, however based on the definition in section 10.1 it would seem that "requesting-user-name" attribute should not be listed since it is not (strictly speaking) a job attribute.
Thoughts?
________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
ipp mailing list
ipp at pwg.orghttps://www.pwg.org/mailman/listinfo/ipp
________________________________________________________________________Michael Sweet, Senior Printing System Engineer, PWG Chair
--
This message has been scanned for viruses and
dangerous content by
MailScanner, and is
believed to be clean.
_______________________________________________
ipp mailing list
ipp at pwg.orghttps://www.pwg.org/mailman/listinfo/ipp
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.