Re: [IPP] Posted IPP over HTTPS Transport Binding and 'ipps' URI Scheme (18 Dec 2014)
"Kennedy, Smith (Wireless Architect)" <smith.kennedy@hp.com> Thu, 18 December 2014 21:13 UTC
Return-Path: <ipp-bounces@pwg.org>
X-Original-To: ietfarch-ipp-archive@ietfa.amsl.com
Delivered-To: ietfarch-ipp-archive@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582321A1B94 for <ietfarch-ipp-archive@ietfa.amsl.com>; Thu, 18 Dec 2014 13:13:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6FPwiwOYMNW for <ietfarch-ipp-archive@ietfa.amsl.com>; Thu, 18 Dec 2014 13:13:23 -0800 (PST)
Received: from www.pwg.org (www.pwg.org [IPv6:2600:3c01::f03c:91ff:fe70:b03f]) by ietfa.amsl.com (Postfix) with ESMTP id 357081A047A for <ipp-archive@lists.ietf.org>; Thu, 18 Dec 2014 13:13:23 -0800 (PST)
Received: by www.pwg.org (Postfix, from userid 502) id A7A74857E; Thu, 18 Dec 2014 21:22:01 +0000 (UTC)
Received: from pwg.org (localhost [IPv6:::1]) by www.pwg.org (Postfix) with ESMTP id 781DE86F1; Thu, 18 Dec 2014 21:21:57 +0000 (UTC)
X-Original-To: ipp@pwg.org
Delivered-To: ipp@pwg.org
Received: by www.pwg.org (Postfix, from userid 502) id 4706E86F2; Thu, 18 Dec 2014 21:21:56 +0000 (UTC)
Received: from g4t3425.houston.hp.com (g4t3425.houston.hp.com [15.201.208.53]) by www.pwg.org (Postfix) with ESMTPS id 58294857E for <ipp@pwg.org>; Thu, 18 Dec 2014 21:21:54 +0000 (UTC)
Received: from G4W6310.americas.hpqcorp.net (g4w6310.houston.hp.com [16.210.26.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t3425.houston.hp.com (Postfix) with ESMTPS id 1C4BE242; Thu, 18 Dec 2014 21:13:12 +0000 (UTC)
Received: from G4W6305.americas.hpqcorp.net (16.210.26.230) by G4W6310.americas.hpqcorp.net (16.210.26.217) with Microsoft SMTP Server (TLS) id 14.3.169.1; Thu, 18 Dec 2014 21:12:04 +0000
Received: from G9W0739.americas.hpqcorp.net ([169.254.10.17]) by G4W6305.americas.hpqcorp.net ([16.210.26.230]) with mapi id 14.03.0169.001; Thu, 18 Dec 2014 21:12:04 +0000
From: "Kennedy, Smith (Wireless Architect)" <smith.kennedy@hp.com>
To: Ira McDonald <blueroofmusic@gmail.com>
Thread-Topic: [IPP] Posted IPP over HTTPS Transport Binding and 'ipps' URI Scheme (18 Dec 2014)
Thread-Index: AQHQGwRaJm3Ar2Qm1Uy9/eX2KCw6k5yV2IGA
Date: Thu, 18 Dec 2014 21:12:03 +0000
Message-ID: <30B70A90-5227-475F-B5F1-386762129B55@hp.com>
References: <CAN40gSuqnC5sKCeMC7bMkF016kdQU1ZK+D4g2qQo=NO2TFV7vg@mail.gmail.com>
In-Reply-To: <CAN40gSuqnC5sKCeMC7bMkF016kdQU1ZK+D4g2qQo=NO2TFV7vg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [16.216.65.178]
MIME-Version: 1.0
Cc: "<ipp@pwg.org>" <ipp@pwg.org>
Subject: Re: [IPP] Posted IPP over HTTPS Transport Binding and 'ipps' URI Scheme (18 Dec 2014)
X-BeenThere: ipp@pwg.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Internet Printing Protocol Workgroup discussion list <ipp.pwg.org>
List-Unsubscribe: <https://www.pwg.org/mailman/options/ipp>, <mailto:ipp-request@pwg.org?subject=unsubscribe>
List-Archive: <http://www.pwg.org/pipermail/ipp/>
List-Post: <mailto:ipp@pwg.org>
List-Help: <mailto:ipp-request@pwg.org?subject=help>
List-Subscribe: <https://www.pwg.org/mailman/listinfo/ipp>, <mailto:ipp-request@pwg.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1367640478=="
Sender: ipp-bounces@pwg.org
Errors-To: ipp-bounces@pwg.org
Hi Ira, > - Editorial - Revised section 6.2.4 No Client Authentication for 'ipps' > URI to remove all references to downgrade (from TLS to straight TCP), > explicitly mention the IPP "three sisters" relevant attributes, and > add example of LDAP Printer Schema [RFC3712] for directory protocols, > per Sandra Murphy and Mike Sweet. Just to satisfy my own curiosity, what are the “three sisters”? Smith /** Smith Kennedy Wireless Architect - Client Software - IPG-PPS Hewlett-Packard Co. */ > On 2014-12-18, at 1:50 PM, Ira McDonald <blueroofmusic@gmail.com> wrote: > > Hi, > > This version has editorial changes requested by IESG reviewers in early December, > when it was approved for publication as a standards-track RFC. > > I've just posted another Internet-Draft of IPP over HTTPS Transport Binding and > 'ipps' URI Scheme to: > > ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ipps-uri-scheme-18-20141218.txt <ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ipps-uri-scheme-18-20141218.txt> > - plaintext Internet-Draft format (warning - contains explicit formfeed characters) > > ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ipps-uri-scheme-18-20141218.log <ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ipps-uri-scheme-18-20141218.log> > - plaintext change log (removed from body of spec) > > ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ipps-uri-scheme-18-20141218.pdf <ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ipps-uri-scheme-18-20141218.pdf> > - PDF of plaintext w/ line numbers (review *this* one) > > This document has already been accepted and posted to the IETF I-D repository. > > This document is parallel to, but does not update or obsolete, RFC 3510. > > Comments? > > Cheers, > - Ira > > -------------------------------- > > Change History > > 18 December 2014 - draft-mcdonald-ipps-uri-scheme-18.txt > > - Editorial - Revised section 1 Introduction to expand bullet (a) > to update sections 4, 5, and 8.2 of [RFC2910] to explicitly add new > standard scheme of 'ipps' for IPP Printers, > per Sandra Murphy. > > - Editorial - Revised section 1 Introduction to expand bullet (b) > to update sections 4.1.6 and 4.4.1 of [RFC2911] to explicitly add new > standard scheme of 'ipps' for IPP Printers, > per Sandra Murphy. > > - Editorial - Revised section 1 Introduction to delete bullet (c) > reference to updating PWG IPP 2.0 [PWG5100.12] (will be covered by a new > PWG version of [PWG5100.12] in 2015 to move to full IEEE Standard), > per Spencer Dawkins, Adrian Farrel, Barry Leiba, Sandra Murphy, Pete > Resnick, Robert Sparks, and other reviewers. > > - Editorial - Revised section 1.2 Rationale for this Document bullet (1) > about flawed implementations of HTTP Upgrade [RFC2817] to add > "although this is not due to specification defects in [RFC2817] itself", > per Pete Resnick. > > - Editorial - Revised section 1.2 Rationale for this Document bullet (2) > and section 6.1.2 Layers of Attacks bullet (a) > to replace [STD7] with [TCPROAD] for normative TCP reference, > per Barry Leiba and Spencer Dawkins. > > Editorial - Revised section 2.1 Printing Terminology definition of IPP > Client to change "a downstream IPP Printer" to simply "an IPP Printer", > since discussion of forwarding and "fan-out" of print jobs [RFC3998] is > out-of-scope in this specification, > per Sandra Murphy and Mike Sweet. > > Editorial - Revised section 2.1 Printing Terminology definition of IPP > Printer to change "an upstream IPP Client or IPP Printer" to simply > "an IPP Client", since discussion of forwarding and "fan-out" of print > jobs [RFC3998] is out-of-scope in this specification, > per Sandra Murphy and Mike Sweet. > > - Editorial - Revised section 4.2 Syntax of 'ipps' URI Scheme to > mention general caution about IPP Printer URI lengths greater than 255 > octets for both 'ipp' [RFC3510] and 'ipps' schemes, > per Sandra Murphy. > > - Editorial - Revised section 4.3 Associated Port for 'ipps' URI Scheme > to delete (confusing) last paragraph about listening on port 443, > per Pete Resnick and Mike Sweet. > > - Editorial - Revised section 4.5 Examples of 'ipps' URI to delete > (confusing) example about use of port 443, > per Pete Resnick and Mike Sweet. > > - Editorial - Revised section 4.5 Examples of 'ipps' URI actual examples > to align with IPP Everywhere [PWG5100.14], IPP FaxOut Service > [PWG5100.15], and IPP Scan Service [PWG5100.17] best practice, > per Mike Sweet. > > - Editorial - Revised section 6.1.1 Targets of Attacks bullet (d) to add > "for example, to steal the data" (i.e., theft of data in transit), > per Kathleen Moriarty. > > - Editorial - Revised section 6.2.4 No Client Authentication for 'ipps' > URI to remove all references to downgrade (from TLS to straight TCP), > explicitly mention the IPP "three sisters" relevant attributes, and > add example of LDAP Printer Schema [RFC3712] for directory protocols, > per Sandra Murphy and Mike Sweet. > > - Editorial - Revised section 6.3 TLS Version Requirements to add > informative reference to IETF UTA TLS BCP > "Recommendations for Secure Use of TLS and DTLS", > per Kathleen Moriarty. > > - Editorial - Revised section 7 Acknowledgments to add other IETF and > PWG reviewers. > > - Editorial - Revised section 8.1 Normative References > to delete unused [RFC7232], [RFC7233], [RFC7234], and [RFC7235], > per ID-Nits. > > - Editorial - Revised section 8.1 Normative References > to delete [STD7] for normative TCP reference, > > - Editorial - Revised section 8.2 Informative References > to add missing [IPPREG] (IANA IPP Registry), > per ID-Nits. > > - Editorial - Revised section 8.2 Informative References to add > LDAP Printer Schema [RFC3712] for update to section 6.2.4 above, > per Sandra Murphy and Mike Sweet. > > - Editorial - Revised section 8.2 Informative References to add > IPP FaxOut Service [PWG5100.15] and IPP Scan Service [PWG5100.17], > per Mike Sweet. > > - Editorial - Revised section 8.2 Informative References to add > [TCPROAD] for informative TCP reference, > per Barry Leiba and Spencer Dawkins. > > - Editorial - Revised section Authors' Addresses to update Mike Sweet's > contact info. > > > > _______________________________________________ > ipp mailing list > ipp@pwg.org > https://www.pwg.org/mailman/listinfo/ipp
_______________________________________________ ipp mailing list ipp@pwg.org https://www.pwg.org/mailman/listinfo/ipp
- [IPP] Posted IPP over HTTPS Transport Binding and… Ira McDonald
- Re: [IPP] Posted IPP over HTTPS Transport Binding… Kennedy, Smith (Wireless Architect)
- Re: [IPP] Posted IPP over HTTPS Transport Binding… Michael Sweet
- Re: [IPP] Posted IPP over HTTPS Transport Binding… Ira McDonald