Looks good. Some minor thoughts s.3 " section 7 'The TLS Handshake Protocol' in [RFC5246]" should now refer to "section 7 'TLS Handshaking Protocols' " s.4.1 "Any other transport binding for IPP would require a different URI scheme. " sounds rather like a MUST e.g. 'This URI scheme MUST only be used with the transport bindings specified here' s.4.2 'Note: Literal IPv4 addresses' sounds like good security advice but is not referenced by s.6 On the other hand, I cannot see a good place in s.6 in which to insert a reference so probably best left. s.5 " Encoding Considerations: See section 4.3 of RFC xxxx. " should now be section 4.5. I note that the latest RFC Editor guidelines say that they prefer TBD1, TBD2 etc to xxxx which seems to me very silly - I await their response with interest:-) Tom Petch ----- Original Message ----- From: "The IESG" <iesg-secretary@xxxxxxxx> To: "IETF-Announce" <ietf-announce@xxxxxxxx> Sent: Tuesday, October 28, 2014 1:30 PM Subject: Last Call: <draft-mcdonald-ipps-uri-scheme-15.txt> (IPP over HTTPS Transport Binding and 'ipps' URI Scheme) to Proposed Standard > > The IESG has received a request from an individual submitter to consider > the following document: > - 'IPP over HTTPS Transport Binding and 'ipps' URI Scheme' > <draft-mcdonald-ipps-uri-scheme-15.txt> as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@xxxxxxxx mailing lists by 2014-11-25. Exceptionally, comments may be > sent to iesg@xxxxxxxx instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > This document defines the Internet Printing Protocol (IPP) over HTTPS > transport binding and the corresponding 'ipps' URI scheme, that is > used to designate the access to the network location of a secure IPP > print service or a network resource managed by such a service. > > This document defines an alternate IPP transport binding to that > defined in the original IPP URL Scheme (RFC 3510), but this document > does not update or obsolete RFC 3510. > > This document updates RFC 2910 and RFC 2911. > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-mcdonald-ipps-uri-scheme/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-mcdonald-ipps-uri-scheme/ballot/ > > No IPR declarations have been submitted directly on this I-D.