[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Last Call: Internet Printing Protocol (IPP): Event Notifications and Subscriptions to Proposed Standard
Michelle, Ned, and Harry,
I've been traveling, but now I'm back. I can see from some of the confusion
that the IANA section needs some clarification in
<draft-ietf-ipp-not-spec-10.txt>. I've been working with Michelle on the
existing IPP Registry and I still owe her a fully populated IPP registry
that adds the items in RFC2911 and RFC2910.
I've discussed your comments with Ira McDonald as well. See my replies
bracketed by <tom> and </tom>. Most items I agreed with as well, so I've
not included any comment on them.
Because of the extent of the fixes to the IANA Considerations section, Ira
and I think that it may be easier to republish another I-D for
<draft-ietf-ipp-not-spec-10.txt>, rather than handling as a Note to the RFC
editor. See if you agree. And if we are doing one, we may as well do
<draft-ietf-ipp-notify-get-08> and add the new IP section. I'll try to get
these out this week or the first of next week.
Tom
-----Original Message-----
From: IANA [mailto:iana@iana.org]
Sent: Wednesday, February 05, 2003 18:20
To: Harry Lewis; carl@manros.com
Cc: bob@herriot.com; hastings@cp10.es.xerox.com; iesg@ietf.org;
ned.freed@mrochek.com
Subject: RE: Last Call: Internet Printing Protocol (IPP): Event
Notifications and Subscriptions to Proposed Standard
Carl and Harry,
Thanks for the response. I will also wait for Tom's comments.
Michelle
IANA
-----Original Message-----
From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com]
Sent: Friday, January 31, 2003 14:58
To: IANA
Cc: iesg@ietf.org; bob@herriot.com; hastings@cp10.es.xerox.com;
harryl@us.ibm.com; carl@manros.com
Subject: RE: Last Call: Internet Printing Protocol (IPP): Event
Notifications and Subscriptions to Proposed Standard
> IESG:
> The IANA has reviewed the following Internet-Drafts which
> are in Last Call and has the following comments with
> regards to the publication of these documents:
> o "Internet Printing Protocol (IPP): Event Notifications and
> Subscriptions"
> <draft-ietf-ipp-not-spec-10.txt>
> We would like to suggest in section 24.7.2.3, that there is
> mention of the reviewer sending a message or contacting the
> IANA when a request is ready for registration. Adding this
> will make it a bit more clear.
OK, how about:
24.7.2.3 IANA Registration
Provided that the Delivery Method registration proposal has either
passed review or has been successfully appealed to the IESG, the
IANA will be notified by the delivery method reviewer and asked to
register the Delivery Method and make it available to the
community.
I can make this change with an RFC Editor note if there are no other
changes.
> We understand a new sub-registry in the IPP Registry will
> be created for "Events and Delivery Methods". Are there any
> defined registrations for this registry in this document?
Not in this document, however, the companion document
draft-ietf-ipp-notify-get-08.txt registers one. I expect this to be the only
registration made in the short term.
<tom>
Michelle is correct that <draft-ietf-ipp-not-spec-10> needs to add all the
events that it defines to the IPP Registry to be registered with IANA.
So I'll add the following Event registrations to section 24.6 of
<draft-ietf-ipp-not-spec-10> which will be included in the IPP Registry
under Keyword Attribute Value registrations:
Attribute (attribute syntax)
Value Ref. Section
--------------------- -------- -------
notify-events (1setOf type2 keyword) RFC NNNN 5.3.3
notify-events-default (1setOf type2 keyword) RFC NNNN 5.3.3.1
notify-events-supported (1setOf type2 keyword) RFC NNNN 5.3.3.2
No Events:
none RFC NNNN 5.3.3.4.1
Printer Events:
printer-state-changed RFC NNNN 5.3.3.4.2
printer-restarted RFC NNNN 5.3.3.4.2
printer-shutdown RFC NNNN 5.3.3.4.2
printer-stopped RFC NNNN 5.3.3.4.2
printer-config-changed RFC NNNN 5.3.3.4.2
printer-media-changed RFC NNNN 5.3.3.4.2
printer-finishings-changed RFC NNNN 5.3.3.4.2
printer-queue-order-changed RFC NNNN 5.3.3.4.2
Job Events:
job-state-changed RFC NNNN 5.3.3.4.3
job-created RFC NNNN 5.3.3.4.3
job-completed RFC NNNN 5.3.3.4.3
job-stopped RFC NNNN 5.3.3.4.3
job-config-changed RFC NNNN 5.3.3.4.3
job-progress RFC NNNN 5.3.3.4.3
</tom>
> We understand the following registrations will be made upon
> approval of this document:
> 6 registrations in the "ENUM ATTRIBUTE VALUES" IPP registry
> (the value will need to be confirmed with the IPP expert)
check.
> 28 registrations in the "ATTRIBUTES" IPP registry
check.
> 8 registrations in the "OPERATIONS" IPP registry
There are 9 by my count:
1 Cancel-Subscription Operation RFC NNNN 11.2.7
2 Create-Job-Subscriptions Operation RFC NNNN 11.1.1
3 Create-Printer-Subscriptions Operation RFC NNNN 11.1.2
4 Get-Printer-Attributes - Extensions RFC NNNN 11.2.3
5 Get-Subscription-Attributes Operation RFC NNNN 11.2.4
6 Get-Subscriptions Operation RFC NNNN 11.2.5
7 Job Creation Operations - Extensions RFC NNNN 11.1.3
8 Renew-Subscription Operation RFC NNNN 11.2.6
9 Validate-Job Operation - Extensions RFC NNNN 11.2.2
<tom>
Section 24.3: Well, there are 6 new operations and 3 that said
" - Extensions". The idea was that this specification is adding 6 new
operations and additional semantics to 3 existing operations.
The ones with " - Extensions" would be separate lines right under the lines
of operations with the same name with a reference to where the operation was
first defined.
Also one of these 3 lines is listed as "Job Creation operation" which isn't
an operation at all, but is three operations: Print-Job, Print-URI, and
Create-Job. Ira and I think that we really need three separate lines in the
registry all referring to the same section 11.1.3:
Print-Job - Extensions [RFCNNNN] 11.1.3
Print-URI - Extensions [RFCNNNN] 11.1.3
Create-Job - Extensions [RFCNNNN] 11.1.3
instead of a single line:
Job Creation Operations - Extensions [RFCNNNN] 11.1.3
So the eventual IPP Registry (when I give Michelle the IPP Registry with RFC
2911 and RFC 2910 added) would be adding 6 new operations and extensions to
5 existing [RFC2911] operations and would look like this:
Name Reference Section
-------------------------------------- --------- -------
Cancel-Subscription [RFCNNNN] 11.2.7
Create-Job [RFC2911] 3.2.4
Create-Job - Extensions [RFCNNNN] 11.1.3
Create-Job-Subscriptions [RFCNNNN] 11.1.1
Create-Printer-Subscriptions [RFCNNNN] 11.1.2
Get-Printer-Attributes [RFC2911] 3.2.5
Get-Printer-Attributes - Extensions [RFCNNNN] 11.2.3
Get-Subscription-Attributes Operation [RFCNNNN] 11.2.4
Get-Subscriptions [RFCNNNN] 11.2.5
Print-Job [RFC2911] 3.2.1
Print-Job - Extensions [RFCNNNN] 11.1.3
Print-URI [RFC2911] 3.2.2
Print-URI - Extensions [RFCNNNN] 11.1.3
Renew-Subscription Operation [RFCNNNN] 11.2.6
Validate-Job [RFC2911] 3.2.3
Validate-Job Operation - Extensions [RFCNNNN] 11.2.2
</tom>
> 4 registration in the "STATUS CODES" IPP registry
> (the values will need to be confirmed with the IPP expert)
I only see 2. I think you are misreading table subheadings as entries.
<tom>
Yes, only 2 status codes are being registered, the other two lines are the
subheadings for the entries as Ned indicates.
</tom>
> 2 registrations in the "ATTRIBUTE GROUP TAGS" IPP registry
> (the values will need to be confirmed with the IPP expert)
check.
> o "Internet Printing Protocol (IPP): The 'ippget' Delivery Method
> for Event Notifications" <draft-ietf-ipp-notify-get-08.txt>
> We understand the following registrations will be made upon
> approval of this document:
> 3 registrations in the "KEYWORD ATTRIBUTE VALUES" IPP registry
I don't think this is correct. It looks to me like the boilerplate
from not-spec is still present. Authors, can you clarify?
<tom>
Ned is correct that only one Event keyword value is being registered. The
preceding lines are the attributes for which the keyword values belong. The
idea that was tried to be explained in <draft-ietf-ipp-not-spec-10.txt>
section 24.6 Registration of Events, is that we have to register the
keywords for the "notify-events", "notify-events-default", and
"notify-events-supported" attributes, why not use that same entries for
registering of the Events themselves that each keyword represents, rather
than duplicating the Events in a separate section in the Registry.
However, we need to make it clear to the reader of the IPP Registry where
Events are registered. So I suggest that we just add a line to the table of
contents of the IPP Registry that points to the "notify-events" attribute
value registration. Similarly for Push Delivery Methods and Pull Delivery
Methods (see <draft-ietf-ipp-not-spec-10.txt> section 24.7.3). So the Table
of Contents of the IPP Registry would be augmented as follows with section
9, 10, and 11 referring to the keyword attributes which have the
corresponding keyword values registered:
Internet Printing Protocol (IPP) Registrations - per [RFC2911]
(last updated 2003-02-20)
1. Attributes
2. Keyword Attribute Values
3. Enum Attribute Values
4. Attribute Syntaxes
5. Operations
6. Attribute Group Tags
7. Status Codes
8. Out-of-band Attribute Value Tags
The following entities are registered as keyword values of the indicated
attributes in Section 2:
9. Events - see "notify-events" attribute
10. Pull Delivery Methods - see "notify-pull-method" attribute
11. Push Delivery Methods - see "notify-schemes-supported" attribute
12. References
</tom>
> 1 registration in the "ENUM ATTRIBUTE VALUES" IPP registry
> (the value will need to be confirmed with the IPP expert)
check.
> 1 registration in the "ATTRIBUTES" IPP registry
check.
> 1 registration in the "OPERATIONS" IPP registry
check.
> 1 registration in the "STATUS CODES" IPP registry
check.
Authors, shouldn't this document also make an entry in the new
"Events and delivery methods" registry?
<tom>
Yes, it should make an entry in the Delivery Methods registry, but since it
doesn't define any new events, there is no need to register any additional
events. See above for the technique for registering Pull Delivery Methods
as keyword values of the "notify-pull-method" attribute, rather than as a
separate registry, as attempted to be explained in
<draft-ietf-ipp-not-spec-10.txt> section 24.7.3.
</tom>
Ned
-----Original Message-----
From: Harry Lewis [mailto:harryl@us.ibm.com]
Sent: Tuesday, February 04, 2003 9:49 PM
To: IANA
Cc: bob@herriot.com; carl@manros.com; hastings@cp10.es.xerox.com;
iesg@ietf.org; ned.freed@mrochek.com
Subject: RE: Last Call: Internet Printing Protocol (IPP): Event
Notifications and Subscriptions to Proposed Standard
Regarding draft-ietf-ipp-not-spec-10
1. Accept IANA recommendation and Ned Freed's wording regarding 24.7.2.3
IANA Registrations
2. Ned is correct in pointing out that registration for Event and Delivery
methods for IPP will be requested in companion documents and that, as the
draft-ietf-ipp-notify-get-08.txt is the only such request at this time. "IPP
Get" is the only Delivery Method to be registered at this time.
<tom>
No, <draft-ietf-ipp-notify-get-08.txt> does not define any new Events, but
<draft-ietf-ipp-not-spec-10> defines 15 Events (which need to get
registered). See above for the contents that I will edit into a new I-D.
</tom>
3. Confirm 6 registrations of ENUM ATTRIBUTE VALUES
4. Confirm 28 registrations in the ATTRIBUTES IPP registry
5. Confirm that there are 9 (as listed by Ned), not 8, registrations in the
OPERATIONS IPP registry
<tom>
Well, the actual count is 6 new operations and extensions to 5 existing
operations. See above.
</tom>
6. There are two status codes to register "successful" and "client-error"...
(not 4).
7. Yes, there are 2 ATTRIBUTE GROUP TAGS registered
Regarding draft-ietf-ipp-notify-get-08
1. Only one registration ("ippget") in the KEYWORD ATTRIBUTE VALUES IPP
registry is requested in draft-ietf-ipp-notify-get-08 registrations. What
may appear as a cut and paste error is the author's attempt to reference the
"base" Notification specification reflecting usage of this keyword.
<tom>
Yes, only one keyword value is being registered here: the 'ippget' keyword
value. The idea for registration of keyword attribute values and enum
attribute values, including Events, is to precede the values with one or
more lines indicating all the attributes for which the values are defined.
This technique obviously needs better explaining.
</tom>
2. 1 registration in the ENUM ATTRIBUTE VALUES IPP registry is correct.
3. 1 registration in the ATTRIBUTES IPP registry is correct.
4. 1 registration in the OPERATIONS IPP registry is correct.
5. 1 registration in the STATUS CODES IPP registry is correct.
6. Ned is correct in pointing out that draft-ietf-ipp-notify-get-08 should
request an entry in the new Events and Delivery Methods registry for IPP!
<tom>
But that Delivery Method entry will be registered as a keyword value of the
"notify-schemes-supported" attribute.
</tom>
Please note that one of the authors (Tom Hastings) may be on vacation or
short term sabbatical as my attempts to collaborate a response have failed
and I have heard that he is out of the country. I will get further
clarification on Tom's whereabouts and ability to respond.
----------------------------------------------
Harry Lewis
IBM Printing Systems
----------------------------------------------