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

From: Ira McDonald <[email-masked]>
Date: Fri, 31 Oct 2014 19:15:42 -0400

Hi Tom,

Thanks for your cogent comments once again - inline thoughts below.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Thu, Oct 30, 2014 at 11:32 AM, t.p. <[email-masked]> wrote:

> Looks good.
>
> Some minor thoughts
>
> s.3 " section 7 'The TLS Handshake Protocol' in [RFC5246]"
> should now refer to
> "section 7 'TLS Handshaking Protocols'   "
>

<ira> Agreed - will fix in next draft.

>
> 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'
>

<ira> Agreed - will fix in next draft.

>
> 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.
>

<ira> Good catch.  I'll think about making sure that somewhere in s.6
there's a back reference to most or all security-related requirements
or recommendations included in the registration template in s.4.

s.5
> "   Encoding Considerations:  See section 4.3 of RFC xxxx.
> "
> should now be section 4.5.
>

<ira> Agreed - will fix in next draft.

>
> 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:-)
>

<ira> Yuck - well, I'll follow the RFC Editor's advice in next draft.

>
> 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.
>
>

---

From: Barry Leiba <[email-masked]>
Date: Mon, 10 Nov 2014 16:23:06 -0500

Late with this, but...

> TBD2 etc to xxxx which seems to me very silly - I await their response

No, the guidelines say that IANA prefers "TBD1", etc, for IANA code
points that have not yet been allocated.  That has nothing to do with
whether or not you say "RFC xxxx".

Barry