[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
Thanks Tom!
Looking forward to the new versions, if that is what
folks want to do. If not, we can work together on
getting this straightened out. Your comments below
seem to clear up things.
Michelle
IANA
> -----Original Message-----
> From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
> Sent: Thursday, February 20, 2003 4:57 PM
> To: IANA; Harry Lewis; carl@manros.com
> Cc: bob@herriot.com; Hastings, Tom N; iesg@ietf.org;
> ned.freed@mrochek.com
> Subject: 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
> ----------------------------------------------
>