I'm still not understanding this issue.
The list of attributes to be registered with IANA is:
Subscription Template attributes: Reference Section
--------------------------------- --------- -------
notify-attributes (1setOf type2 keyword) [RFCNNNN] 5.3.4
notify-attributes-supported (1setOf type2 keyword)
[RFCNNNN] 5.3.4.1
notify-charset (charset) [RFCNNNN] 5.3.6
notify-events (1setOf type2 keyword) [RFCNNNN] 5.3.3
notify-events-default (1setOf type2 keyword) [RFCNNNN] 5.3.3.1
notify-events-supported (1setOf type2 keyword) [RFCNNNN] 5.3.3.2
notify-lease-duration (integer(0:67108863)) [RFCNNNN] 5.3.8
notify-lease-duration-default (integer(0:67108863))
[RFCNNNN] 5.3.8.1
notify-lease-duration-supported (1setOf (integer(0: 67108863) |
rangeOfInteger(0:67108863))) [RFCNNNN] 5.3.8.2
notify-max-events-supported (integer(2:MAX)) [RFCNNNN] 5.3.3.3
notify-natural-language (naturalLanguage) [RFCNNNN] 5.3.7
notify-pull-method (type2 keyword) [RFCNNNN] 5.3.2
notify-pull-method-supported (1setOf type2 keyword)
[RFCNNNN] 5.3.2.1
notify-recipient-uri (uri) [RFCNNNN] 5.3.1
notify-schemes-supported (1setOf uriScheme) [RFCNNNN] 5.3.1.1
notify-time-interval (integer(0:MAX)) [RFCNNNN] 5.3.9
notify-user-data (octetString(63)) [RFCNNNN] 5.3.5
Subscription Description Attributes:
notify-job-id (integer(1:MAX))) [RFCNNNN] 5.4.6
notify-lease-expiration-time (integer(0:MAX))) [RFCNNNN] 5.4.3
notify-printer-up-time (integer(1:MAX))) [RFCNNNN] 5.4.4
notify-printer-uri (uri)) [RFCNNNN] 5.4.5
notify-sequence-number (integer (0:MAX))) [RFCNNNN] 5.4.2
notify-subscriber-user-name (name(MAX))) [RFCNNNN] 5.4.7
notify-subscription-id (integer (1:MAX))) [RFCNNNN] 5.4.1
Printer Description Attributes:
printer-state-change-date-time (dateTime)) [RFCNNNN] 6.2
printer-state-change-time (integer(1:MAX))) [RFCNNNN] 6.1
Attributes Only in Event Notifications
notify-subscribed-event (type2 keyword) [RFCNNNN] 8.1
notify-text (text(MAX)) [RFCNNNN] 8.2
There are different operations on different objects to get each:
Get-Printer-Attributes
Get-Subscription-Attributes
Get-Job-Attributes
Where is the problem?
Tom
-----Original Message-----
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Tuesday, June 17, 2003 19:59
To: 'Hastings, Tom N'; McDonald, Ira; 'Dennis Carney'; ipp at pwg.org
Subject: RE: Dennis's ISSUE about Job and Printer Description names
being the same
Hi Tom,
The issue is that the namespace is FLAT for the "notify-attributes"
list in the IPP Subscription object (the names of Printer, Job,
and Subscription attributes are mixed, without prefixes).
Cheers,
- Ira
-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Tuesday, June 17, 2003 8:01 PM
To: McDonald, Ira; 'Dennis Carney'; ipp at pwg.org
Subject: Re: Dennis's ISSUE about Job and Printer Description names
being the same
I don't understand the ISSUE that Dennis is raising about the same name for
a Job and a Printer attribute (e.g., "document-charset-default" for both a
Job Description attribute and a Printer Description attribute).
Dennis wrote:
"This is fine as long as there are no Printer attributes that have the same
name as Job attributes. We are breaking that now: if the client requests
the
"document-charset-default" attribute, for example, the Printer doesn't
know
whether to return the Printer level "document-charset-default" or the Job
level one, and the client that receives the notification doesn't know
which
is which either."
Which "xxx" attribute is returned depends on the Get-Attributes-Xxxx
operation being queried (Xxxx = Printer versus Xxxx = Job). For example, if
the client requests the "xxx" attribute, the response is:
Request Response
------- --------
Get-Printer-Attributes returns the Printer's "xxx" attr
Get-Job-Attributes returns the Job's "xxx" attr
Get-Document-Attributes returns the Document's "xxx" attr
Get-Subscription-Attributes returns the Subscription's "xxx" attr
What am I missing?
Tom
-----Original Message-----
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Monday, June 16, 2003 10:06
To: 'Dennis Carney'; ipp at pwg.org
Subject: RE: IPP> Re: SM> JobX Telecon *NEW NUMBER & PASSCODE*
Hi Dennis,
A more faithful suffix (than "docdefault" or "default")
might be "requested" (which currently means "client
requested" as opposed to "administrator configured"
for "default").
I agree that the flat namespace in "notify-attributes"
(any Subscription, Printer, or Job, attribute name) is
a problem that gets worse over time (as we define new
IPP attributes and extensions).
Cheers,
- Ira McDonald
High North Inc
-----Original Message-----
From: Dennis Carney [mailto:dcarney at us.ibm.com]
Sent: Monday, June 16, 2003 10:46 AM
To: ipp at pwg.org
Subject: IPP> Re: SM> JobX Telecon *NEW NUMBER & PASSCODE*
All,
If I'm not mistaken, in the teleconference yesterday, we pretty much
accepted Pete's proposal below without change.
However, I realized something: the "xxx-default" names that we have
assigned at the Job level (e.g. document-format-default) are the first case
where a Job level attribute has the same name as a Printer level attribute.
This would not be a problem except that we discovered the other day that
IPP notifications have a flat name space of attributes that the client
requests and that the Printer responds with. This is fine as long as there
are no Printer attributes that have the same name as Job attributes. We
are breaking that now: if the client requests the
"document-charset-default" attribute, for example, the Printer doesn't know
whether to return the Printer level "document-charset-default" or the Job
level one, and the client that receives the notification doesn't know which
is which either.
Do we need to rethink our decision?
An idea that I had that I never brought up because I was persuaded by the
other participants was to create a new suffix for this type of attribute.
For example, "-docdefault", rather than "-default". I thought this might
not be a bad idea due to the fact that we were introducing a new concept.
Dennis Carney
IBM Printing Systems
"Zehler, Peter"
<PZehler at crt.xero To: "IPP Discussion
List (E-mail)" <IPP at pwg.org>
x.com> cc: "PWG Semantic Model
WG (E-mail)" <sm at pwg.org>
Sent by: Subject: SM> JobX Telecon
*NEW NUMBER & PASSCODE*
owner-sm at pwg.org
06/09/03 01:17 PM
All,
This Thursday at 1pm EDT is the Semantic Model teleconference. This week's
teleconference will be dedicated to IPP Jobx. I will post the document
later today. This review will prepare the document for the Face-to-Face.
The teleconference is 2 hours long. It will be run using phone and Webex.
Anyone that does not yet have Webex installed should do that before
Thursday. Information for the phone and Webex are included below. NOTE:
New Dial in number and passcode
The agenda for the Semantic Model teleconference is :
1) Discuss the remaining issue and reach consensus
The following issue came up during the Review of the JOBX specification on
June 4, which affects the Job Extension spec, the Document Object spec, and
the PWG Semantic Model spec.
For IPP there are the following Operation attributes that a client MAY
supply in a Print-Job or Print-URI operation for specifying Document
Attributes that do not have corresponding Description attributes defined
until the Document Object specification:
compression (type2 (keyword))
document-charset (charset)
document-digital-signature (type2 (keyword))
document-format (mimeMediaType)
document-format-details (1setOf (collection))
document-format-version (text(127))
document-message (text(MAX))
document-name (name(MAX))
document-natural-language (naturalLanguage)
The preceding attributes are attributes of a Document. Therefore, unless
the Document object is implemented, it is not possible for a client to
completely determine what a client had submitted. As a consequence, it is
also not possible for an application to completely archive a single
document
job using the Get-Job-Attributes operation. Furthermore FSG is using these
attributes at the Job level in its APIs. When implementing the Document
object, these same attributes can be supplied in the Send-Document and
Send-URI operation as well. These attribute have slightly different
semantics at the Job level than they do at the Document level.
A solution for IPP JOBX (whether or not implementing the Document object)
would be to define corresponding Job Description attributes for these
specific operation attributes with the semantics that they are the defaults
for the all the Document objects in the Job (even single document jobs
created with Print-Job and Print-URI). These new Job Description
attributes
would be :
compression-default (type2 (keyword))
document-charset-default (charset)
document-digital-signature-default (type2 (keyword))
document-format-default (mimeMediaType)
document-format-details-default (1setOf (collection))
document-format-version-default (text(127))
document-message-default (text(MAX))
document-name-default (name(MAX))
document-natural-language-default (naturalLanguage)
These new attributes would be populated by the associated operational
attribute if supplied.
The file for telecon is the pdf file:
ftp://www.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030609.pdf
NOTE: This file does not include the above proposal for the remaining
issue.
However, given the time and my schedule I wanted to get something out. If
possible I will get an update out later this week. The main issue and
resolution proposal is explained fairly well above.
Pete
________________________________________________
Dial in Info:
Phone Number:(877) 707-6056
(Phone Number for Xerox Employees: 8*594-0077)
PARTICIPANT PASSCODE: 437874#
________________________________________________
webex info:
We will also use an on line tool called webex,
if you have not used this before, setup up by
following the First Time Users instructions.
Do this in advance of the meeting.
-------------------------
FIRST TIME USERS
-------------------------
For fully interactive meetings, including the ability
to present your documents and applications, a one-time
setup takes less than 10 minutes. Click this URL to set up now:
http://hp.webex.com
Then click New User.
-------------------------
On Thursday use:
https://hp.webex.com/join/
Then click join unlisted meeting.
Use the info below:
-------------------------
Webex MEETING SUMMARY
-------------------------
Topic: PWG Semantic Model
Date: Thursday, June 12, 2003
Time: 10:00 am, Pacific Daylight Time (GMT -07:00, San Jose)
Meeting number: 21366675
Meeting password: pwg_sm1!
Host:
Bob Taylor (HP)
___________________________________________________
Peter Zehler
XEROX
Xerox Innovation Group
Email:
PZehler at crt.xerox.com
Voice: (585) 265-8755
FAX: (585) 422-7961
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY,
14580-9701