[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf
Subject: Re: Last Call: <draft-mcdonald-ipps-uri-scheme-15.txt> (IPP over HTTPS Transport Binding and 'ipps'
From: Ira McDonald <blueroofmusic () gmail ! com>
Date: 2014-10-31 23:15:42
Message-ID: CAN40gStxMVdM8oA2aRwGf7icUjGt9Sg5gXdx0AX6K7RmTz=kCA () mail ! gmail ! com
[Download RAW message or body]
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: blueroofmusic@gmail.com
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. <daedulus@btconnect.com> 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" <iesg-secretary@ietf.org>
> To: "IETF-Announce" <ietf-announce@ietf.org>
> 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@ietf.org mailing lists by 2014-11-25. Exceptionally, comments may
> be
> > sent to iesg@ietf.org 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.
>
>
[Attachment #3 (text/html)]
Hi Tom,<br><br>Thanks for your cogent comments once again - inline thoughts \
below.<br><br>Cheers,<br>- Ira<br><br clear="all"><div><div \
class="gmail_signature"><div dir="ltr">Ira McDonald (Musician / Software \
Architect)<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>Chair - Linux \
Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working \
Group<br>Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br>IETF Designated \
Expert - IPP & Printer MIB<br>Blue Roof Music / High North Inc<br><a \
style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" \
target="_blank">http://sites.google.com/site/blueroofmusic</a><br><a \
style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" \
target="_blank">http://sites.google.com/site/highnorthinc</a><br>mailto: <a \
href="mailto:blueroofmusic@gmail.com" \
target="_blank">blueroofmusic@gmail.com</a><br>Winter 579 Park Place Saline, MI \
48176 734-944-0094<br>Summer PO Box 221 Grand Marais, MI 49839 \
906-494-2434<br><br><div style="display:inline"></div><div \
style="display:inline"></div><div \
style="display:inline"></div><div></div><div></div><div></div><div></div></div></div></div>
<br><div class="gmail_quote">On Thu, Oct 30, 2014 at 11:32 AM, t.p. <span \
dir="ltr"><<a href="mailto:daedulus@btconnect.com" \
target="_blank">daedulus@btconnect.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Looks good.<br> <br>
Some minor thoughts<br>
<br>
s.3 " section 7 'The TLS Handshake Protocol' in [RFC5246]"<br>
should now refer to<br>
"section 7 'TLS Handshaking Protocols' "<br></blockquote><div> \
</div><div><span style="color:rgb(102,0,204)"><ira> Agreed - will fix in next \
draft. </span><br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
s.4.1 "Any other transport binding for IPP would require a different URI<br>
scheme. "<br>
sounds rather like a MUST e.g. 'This URI scheme MUST only be used with<br>
the transport bindings specified here'<br></blockquote><div><br><span \
style="color:rgb(102,0,204)"><ira> Agreed - will fix in next draft. \
</span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"> <br>
s.4.2 'Note: Literal IPv4 addresses'<br>
sounds like good security advice but is not referenced by s.6 On the<br>
other hand, I cannot see a good place in s.6 in which to insert a<br>
reference so probably best left.<br></blockquote><div><br><span \
style="color:rgb(51,51,255)"><ira> Good catch. I'll think about making \
sure that somewhere in s.6<br>there's a back reference to most or all \
security-related requirements<br>or recommendations included in the registration \
template in s.4.</span><br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> s.5<br>
" Encoding Considerations: See section 4.3 of RFC xxxx.<br>
"<br>
should now be section 4.5.<br></blockquote><div><br><span \
style="color:rgb(102,0,204)"><ira> Agreed - will fix in next draft. \
</span><br></div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
I note that the latest RFC Editor guidelines say that they prefer TBD1,<br>
TBD2 etc to xxxx which seems to me very silly - I await their response<br>
with interest:-)<br></blockquote><div><br><span \
style="color:rgb(51,51,255)"><ira> Yuck - well, I'll follow the RFC \
Editor's advice in next draft. </span><br></div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
Tom Petch<br>
<br>
<br>
----- Original Message -----<br>
From: "The IESG" <<a \
href="mailto:iesg-secretary@ietf.org">iesg-secretary@ietf.org</a>><br>
To: "IETF-Announce" <<a \
href="mailto:ietf-announce@ietf.org">ietf-announce@ietf.org</a>><br>
Sent: Tuesday, October 28, 2014 1:30 PM<br>
Subject: Last Call: <draft-mcdonald-ipps-uri-scheme-15.txt> (IPP over<br>
HTTPS Transport Binding and 'ipps' URI Scheme) to Proposed Standard<br>
<br>
<br>
><br>
> The IESG has received a request from an individual submitter to<br>
consider<br>
> the following document:<br>
> - 'IPP over HTTPS Transport Binding and 'ipps' URI Scheme'<br>
> <draft-mcdonald-ipps-uri-scheme-15.txt> as Proposed Standard<br>
><br>
> The IESG plans to make a decision in the next few weeks, and solicits<br>
> final comments on this action. Please send substantive comments to the<br>
> <a href="mailto:ietf@ietf.org">ietf@ietf.org</a> mailing lists by 2014-11-25. \
Exceptionally, comments may<br> be<br>
> sent to <a href="mailto:iesg@ietf.org">iesg@ietf.org</a> instead. In either \
case, please retain the<br> > beginning of the Subject line to allow automated \
sorting.<br> ><br>
> Abstract<br>
><br>
> This document defines the Internet Printing Protocol (IPP) over<br>
HTTPS<br>
> transport binding and the corresponding 'ipps' URI scheme, that \
is<br> > used to designate the access to the network location of a secure<br>
IPP<br>
> print service or a network resource managed by such a service.<br>
><br>
> This document defines an alternate IPP transport binding to that<br>
> defined in the original IPP URL Scheme (RFC 3510), but this<br>
document<br>
> does not update or obsolete RFC 3510.<br>
><br>
> This document updates RFC 2910 and RFC 2911.<br>
><br>
> The file can be obtained via<br>
> <a href="http://datatracker.ietf.org/doc/draft-mcdonald-ipps-uri-scheme/" \
target="_blank">http://datatracker.ietf.org/doc/draft-mcdonald-ipps-uri-scheme/</a><br>
><br>
> IESG discussion can be tracked via<br>
> <a href="http://datatracker.ietf.org/doc/draft-mcdonald-ipps-uri-scheme/ballot/" \
target="_blank">http://datatracker.ietf.org/doc/draft-mcdonald-ipps-uri-scheme/ballot/</a><br>
><br>
> No IPR declarations have been submitted directly on this I-D.<br>
<br>
</blockquote></div><br>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic