Subject: Re: Last Call: <draft-mcdonald-ipps-uri-scheme-15.txt> (IPP over HTTPS Transport Binding and 'ipps' URI Scheme) to Proposed Standard

From: t.p. <[email-masked]>
Date: Thu, 30 Oct 2014 15:32:34 +0000

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" <[email-masked]>
To: "IETF-Announce" <[email-masked]>
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
> [email-masked] mailing lists by 2014-11-25. Exceptionally, comments may
be
> sent to [email-masked] 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.