IPP Mail Archive: IPP> RE: IFX> Attempt to close on the t

IPP> RE: IFX> Attempt to close on the two Notification specs at the fa ce to fac e meetings

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Mon Aug 26 2002 - 17:26:01 EDT

  • Next message: Hastings, Tom N: "IPP> RE: IFX> Attempt to close on the two Notification specs at the fa ce to face meetings"

    Hi Tom,

    First - I agree that it would still be good to drop redirect from IPPGET
    and design it IN GENERAL for IPP (any operation response could return
    the redirect), including the fact that while it's nice for interoperability
    IPP Clients do NOT need to honor and follow redirects (any more than
    HTTP Clients need to do so - it's a matter of client policy).

    Second - if we publish IPPGET as a Proposed Std RFC (as you suggest)
    and LATER add redirect, we MUST recycle at Proposed Std RFC - it's
    illegal to add ANY new features when moving from Proposed Std to
    Draft Std status - only dropping existing features is legal.

    Cheers,
    - Ira McDonald
      High North Inc

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Friday, August 23, 2002 10:54 PM
    To: ipp@pwg.org; ifx@pwg.org
    Cc: pwg@pwg.org
    Subject: IFX> Attempt to close on the two Notification specs at the face
    to fac e meetings

    The IPP WG Last Call period closed July 31 on the two IPP Notification specs
    that are required for IPP Notification:

    (1) IPP Event Notifications and Subscriptions
    <draft-ietf-ipp-not-spec-09.txt>
    (2) The 'ippget' Delivery Method for Event Notifications
    <draft-ietf-ipp-notify-get-07.txt>

    and Carl-Uno declared that (1) was approved, since there were no comments
    and that (2) achieved consensus to drop the redirection mechanism entirely
    from the IPPGET document.

    However, we have continued discussion about the merits and problems of the
    redirection mechanism because Harry Lewis has been the main objector to
    removing the redirection mechanism from IPPGET. As a result I have not yet
    produced a new version of the document and Carl-Uno has not forwarded either
    of the documents to Ned Freed, our Area Director.

    <...snip...>

    Process considerations:

    Could we delete the redirection mechanism for now from IPPGET? Get our RFC
    published as a Proposed standard. Implement IPPGET and do interoperability
    testing. See if the burden in the Printer of supporting the IPPGET method
    justifies offloading it to a Notification Server using the redirect
    mechanism. If the implementation experience shows that its not much of a
    burden in the Printer we made the right decision to delete redirection. If
    implementation experience shows that having a Notification Server is
    important to off-load the Printer's support of the IPPGET method, then add
    the redirection back into the IPPGET spec before progressing the document to
    a Draft standard. Perhaps in the meantime, IBM can also implement the
    Notification Server and see if it is really a win and that the extra
    administrative effort is worth the benefit to simplifying the Printer
    implementation.

    Comments?

    Tom

    <...snip...>



    This archive was generated by hypermail 2b29 : Mon Aug 26 2002 - 17:31:08 EDT