IPP Mail Archive: RE: IPP> Final Editing Steps for draft-iet

RE: IPP> Final Editing Steps for draft-ietf-ipp-ops-set2

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Thu Jul 29 2004 - 20:17:44 EDT

  • Next message: Hastings, Tom N: "RE: IPP> Final Editing Steps for draft-ietf-ipp-ops-set2"

    Hi Scott and Carl-Uno,

    I agree with Scott's proposed changes.

    Harry Lewis (IBM, co-editor of IPP Admin) is on vacation until
    next week (he's been gone two weeks). I'll chase him to reply
    about this early next week.

    Cheers,
    - Ira

    Ira McDonald (Musician / Software Architect)
    Blue Roof Music / High North Inc
    PO Box 221 Grand Marais, MI 49839
    phone: +1-906-494-2434
    email: imcdonald@sharplabs.com

    -----Original Message-----
    From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org]On Behalf Of
    carl@manros.com
    Sent: Thursday, July 29, 2004 3:41 PM
    To: ipp@pwg.org; Scott Hollenbeck
    Cc: Carl-Uno Manros
    Subject: RE: IPP> Final Editing Steps for draft-ietf-ipp-ops-set2

    Scott,

    I don't see any harm in changing the text as you have suggested.

    Objections from anybody else on the DL or we are done, not only with
    this documents, but with all the original work items of the WG?

    Carl-Uno

    Carl-Uno Manros
    Chair of IETF IPP WGG
    700 Carnegie Street #3724
    Henderson, NV 89052, USA
    Tel +1-702-617-9414
    Fax +1-702-617-9417
    Mob +1-702-525-0727
    Email carl@manros.com
    Web www.manros.com

    > -----Original Message-----
    > From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org]On Behalf Of Scott
    > Hollenbeck
    > Sent: Thursday, July 29, 2004 11:02 AM
    > To: ipp@pwg.org
    > Subject: IPP> Final Editing Steps for draft-ietf-ipp-ops-set2
    >
    >
    > I've been working with the two Security area ADs to get the final IESG
    > approvals for draft-ietf-ipp-ops-set2. Steve Bellovin still had some
    > minor concerns with the second paragraph of the new Security
    > Considerations section (he said that he still found it hard to read), but
    > we can deal with that without requiring a new version of the document. I
    > can have the document approved with a note to the RFC Editor requesting
    > some minor changes. That being the case, here's how I wish to proceed:
    >
    > Change this:
    >
    > "Printer operations defined in this specification (see section 3) and
    > Pause-Printer, Resume-Printer, and Purge-Job (defined in [RFC2911])
    > are intended for use by an operator and/or administrator. Job
    > operations defined in this specification (see section 4) and Cancel-
    > Job, Hold-Job, Release-Job defined in [RFC2911]) are intended for use
    > by the job owner or may be an operator or administrator of the
    > Printer object. These operator and administrative operations affect
    > the service of all users. In appropriate use of an administrative
    > operation by an un-authenticated end user could affect the quality of
    > service for all users. Therefore, for both inter-net and intra-net,
    > conformance to this specification REQUIRES that initial configuration
    > of IPP Printer implementations MUST require successful certificate-
    > based TLS [RFC2246] client authentication and successful operator and
    > administrator authorization (see [RFC2911] sections 5.2.7 and 8 and
    > [RFC2910]) for any administrative operations defined in this
    > document. [RFC2910] REQUIRES the IPP Printer to support the minimum
    > cypher suite required for TLS/1.0. The means for authorizing an
    > operator or administrator of the Printer object are outside the scope
    > of this specification, [RFC2911], and [RFC2910]."
    >
    > to this:
    >
    > "Printer operations defined in this specification (see section 3) and
    > Pause-Printer, Resume-Printer, and Purge-Job (defined in [RFC2911]) are
    > intended for use by an operator and/or administrator. Job operations
    > defined in this specification (see section 4) and Cancel-Job,
    > Hold-Job, and
    > Release-Job (defined in [RFC2911]) are intended for use by the job owner,
    > operator, or administrator of the Printer object. These operator and
    > administrative operations affect service for all users.
    >
    > Inappropriate use of an administrative operation by an unauthenticated end
    > user can affect the quality of service for all users. Therefore, IPP
    > Printer implementations MUST require both successful certificate-based TLS
    > [RFC2246] client authentication and successful operator/administrator
    > authorization (see [RFC2911] sections 5.2.7 and 8 and [RFC2910])
    > to perform
    > the administrative operations defined in this document.
    > [RFC2910] requires
    > the IPP Printer to support the minimum cipher suite specified for TLS/1.0.
    > The means for authorizing an operator or administrator of the
    > Printer object
    > are outside the scope of this specification, RFC 2910, and RFC 2911."
    >
    > In addition, a normative reference to RFC 2119 will need to be added. The
    > "change history" comment at the end of the list of informative references
    > will need to be removed.
    >
    > Please let me know ASAP if there are any objections to this approach. if
    > not, I will ask the IESG to approve the document with the RFC Editor note
    > included.
    >
    > -Scott-
    >



    This archive was generated by hypermail 2b29 : Thu Jul 29 2004 - 20:18:58 EDT