Hi Robert,
Small clarification to Mike Sweet's comment this morning - [RFC-IPPS] does
*not*
update [RFC3510]. As the [RFC-IPPS] abstract says, it's an alternative.
It does
indeed update [RFC2910] and [RFC2911].
The later versions of IPP protocol (2.0, 2.1, and 2.2) defined in IEEE-ISTO
PWG
specs normatively depend on over twenty other PWG specs (IPP and otherwise),
so republishing them as IETF RFCs is not feasible.
Thanks for catching the several reference errors and suggesting the
simplification
of the IPPS connection startup sequence.
I'm under the weather with flu, but will reply soon to your other comments.
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(_at_)gmail(_dot_)com
Winter 579 Park Place Saline, MI 48176 734-944-0094
Summer PO Box 221 Grand Marais, MI 49839 906-494-2434
On Mon, Nov 24, 2014 at 8:00 AM, Michael Sweet <msweet(_at_)apple(_dot_)com>
wrote:
Robert,
Thanks for your comments. I have one response (inline below)...
On Nov 21, 2014, at 4:55 PM, Robert Sparks
<rjsparks(_at_)nostrum(_dot_)com> wrote:
...
First: (For Barry as sponsoring AD and shepherd):
I think you might want to say more about how this and the related PWG
documents are being handled cross-organization.
An RFC that normatively updates a document under some other
organization's change control is an unusual thing. Usually there are
parallel documents coordinating this. Is there such a parallel PWG doc this
time?
No.
Generally speaking, the PWG IPP WG doesn't develop parallel documents for
publication by both the PWG (IEEE-ISTO) and IETF - there is no point. PWG
documents include IANA registration templates which go through the usual
registration process, independent of any IETF RFC publication.
However, since RFC 3510 is an IETF document that was produced by the (now
defunct) IETF IPP WG, and since this document is updating RFC 3510 (and
inherits most of the text of RFC 3510), we (the PWG IPP WG) decided it
should be submitted for publication by (and under the IP rules of) the IETF
rather than publishing it as a PWG standard. And Barry has graciously
agreed to shepard the document...
Why aren't there RFC variants of the PWG docs (we've republished other
organization's documents in the RFC series before...)
Second: The 6 step construction in section 3 is a little odd. Why aren't
steps 3-5 collapsed into one step that says "go do what https: says to do"?
Split this way, especially with the repeated guidance in the security
considerations section pointing somewhat loosely to 7320 and 5246 for
things that "can be used to address this threat" looks like an
opportunity for someone to get creative with how they check the certificate
supplied by the server against the name in the URI. If you don't want
anything but what happens in https to happen, I think it needs to be more
clearly stated. Otherwise, doesn't this go off into RFC 6125 territory?
Lastly (and much smaller nits):
There are several callouts from the text that look like references that
are not represented in the references section.
ID nits complains about all of these, and should make them easy to find
and fix.
For example (from section 1.2):
2) Some existing IPP Client and IPP Printer implementations of HTTP
Upgrade [RFC 2717] do not perform upgrade at the beginning of
This reference is oddly constructed - please check early with the RFC
Editor on whether they
will take this, or want something a little different.
[HTTP1.1] HTTP/1.1. See [RFC7230], [RFC7231], [RFC7232],
[RFC7233], [RFC7234], and [RFC7235].
This line is wrong, and is causing idnits to complain once where it
shouldn't.
(The thing in the [] should be RFC7235, not 4):
[RFC7234] Fielding, R., and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Authentication", RFC 7235, June 2014.
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair