Re: [Gen-art] Gen-ART Review of draft-sweet-rfc2911bis-09

Michael Sweet <> Tue, 26 July 2016 21:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C44BB12D9BD for <>; Tue, 26 Jul 2016 14:54:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.589
X-Spam-Status: No, score=-5.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XeiSScmMssmG for <>; Tue, 26 Jul 2016 14:54:08 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF8D412D998 for <>; Tue, 26 Jul 2016 14:54:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256;; s=mailout2048s; c=relaxed/simple; q=dns/txt;; t=1469570048; x=2333483648; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=O2ry5NnPtePbTpzBJ04RPSJAf4HUbWpqvtLZ8U/zKoU=; b=ZSWTXQjOzLjvbOyL2FeV1TuS7WvGJnGxw9Nll74MOpZU5Qc56VHoeg+twqZhqgln mbC4fEuIdz7a1QmYDt5xjHW01qsrVHlocgyg2CIXpRvx6gJ/tBrMMkSjicf7YRvd 7+mRNj2gcuPORBUGkB8RRlQ4IixwNwt3gUajjKmlCDxQpcz0+rS11Gj/guhvzWYG NbLDw115Y/9J4JB4xeancbg1+LeTFYTrQO8Vo3RvAlkqBSy1a9mYcHvP1UOlkk1W HAVQX4ugMl8dc34RZt54y+ybp3vH+tUk+n+J9INe+hJsUV1V0JcJHD468a/vtuCS J2I9Qa2T4efw9oJW2u2iyA==;
Received: from ( []) by (Apple Secure Mail Relay) with SMTP id AB.AD.07433.00CD7975; Tue, 26 Jul 2016 14:54:08 -0700 (PDT)
X-AuditID: 11973e12-f79b16d000001d09-3f-5797dc009103
Received: from ( []) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by (Apple SCV relay) with SMTP id 4A.39.31551.00CD7975; Tue, 26 Jul 2016 14:54:08 -0700 (PDT)
Received: from [] (unknown []) by (Oracle Communications Messaging Server 64bit (built Mar 31 2015)) with ESMTPSA id <>; Tue, 26 Jul 2016 14:54:08 -0700 (PDT)
MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-type: text/plain; charset="us-ascii"
From: Michael Sweet <>
In-reply-to: <>
Date: Tue, 26 Jul 2016 17:54:06 -0400
Content-transfer-encoding: quoted-printable
Message-id: <>
References: <>
To: Russ Housley <>
X-Mailer: Apple Mail (2.3124)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUi2FAYpctwZ3q4wbFpEhYtvY1MFldffWZx YPJYsuQnUwBjFJdNSmpOZllqkb5dAlfG0e8z2QpOqFU86KptYLwk18XIySEhYCIxvfsIK4Qt JnHh3nq2LkYuDiGBvYwS+1+/ZYcpunLmAJgtJLCcSWLfWh2Iom4miSl/l4J1CwtISBzvXwhl W0g82HEfrIFXQE9i8tEGNhCbWUBLYv3O40wgNpuAmsTvSX1g9ZwCDhIfmn4zg9gsAqoSq36d hKr3kDi35BuUrS3x5N0FVoiZNhLTZ05ihDjIXuLVnHawmSIC6hJ/51+AOlpW4snJRSwgh0oI zGGTeP7nH/sERpFZSG6aheSmWUh2LGBkXsUolJuYmaObmWeil1hQkJOql5yfu4kRFOjT7YR2 MJ5aZXWIUYCDUYmH98H26eFCrIllxZW5hxilOViUxHkPngUKCaQnlqRmp6YWpBbFF5XmpBYf YmTi4JRqYFxUVSbw77feRomn3j5HrssG2k9dnvadvcz2ouDtnnMFNUqTpgl0BuofNBa/7nnH cc6FdUv63nRP+Lnb6WvcpeuWfu51XHqZhY/nBep+rHy9IPIAx03HrTpfdf67GRYvKnj/YZ+X 5GX1qZmvehTW3tkSx5L8Wl/+9heWTAa2d51ZD23l3Oq+TVBiKc5INNRiLipOBADd5v4pVQIA AA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUi2FB8Q5fhzvRwg/+bRS1aehuZLK6++szi wOSxZMlPpgDGKC6blNSczLLUIn27BK6Mo99nshWcUKt40FXbwHhJrouRk0NCwETiypkD7BC2 mMSFe+vZQGwhgeVMEvvW6nQxcgHZ3UwSU/4uZQVJCAtISBzvXwhlW0g82HEfrJlXQE9i8tEG sGZmAS2J9TuPM4HYbAJqEr8n9YHVcwo4SHxo+s0MYrMIqEqs+nUSqt5D4tySb1C2tsSTdxdY IWbaSEyfOYkR4iB7iVdz2sFmigioS/ydfwHqaFmJJycXsUxgFJyF5IxZSM6YhWTsAkbmVYwC Rak5iZVmeokFBTmpesn5uZsYwYFZGLWDsWG51SFGAQ5GJR7eB9unhwuxJpYVV+YeYpTgYFYS 4c28DRTiTUmsrEotyo8vKs1JLT7EmAz0zERmKdHkfGDU5JXEG5qYGJgYG5sZG5ubmJMmrCTO O/Es0AqB9MSS1OzU1ILUIpgtTBycUg2MDLpiC5Vesqvt7E5j42/Y/S7Ce8+WIwIO8d8kHonx 10YsTl26T/C6ecSG2bFXk5rTr596pZG12NcnMveqsENK/KvTZ/6yGzf8TpXM7rlqfJKnr31N hl33qvnbj/M+yJCQLv4RPmXSg14WhpNHwj7HdB8/8trF87K80ZrNSQeDvrZULmO+LVKkxFKc kWioxVxUnAgADHgCq5ACAAA=
Archived-At: <>
Cc: IETF Gen-ART <>,
Subject: Re: [Gen-art] Gen-ART Review of draft-sweet-rfc2911bis-09
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Jul 2016 21:54:11 -0000


Thank you for reviewing this (admittedly long) document.  Responses to your questions and comments are inline below...

> On Jul 26, 2016, at 2:36 PM, Russ Housley <> wrote:
> ...
> Major Concerns:
> It seems that [PWG5100.12] specifies IPP Version 2.0, 2.1, and 2.2.  Why
> is this document specifying IPP Version 1.1?  I think the introduction
> ought to contain an explanation of this situation.  Further, I expect
> this will have some impact on the discussion of the REQUIRED
> ipp-versions-supported attribute.

IPP/1.1 was defined in 1999/2000.  IPP/2.0 was originally defined in 2009 and has had several updates since then, but it shares the same message format and semantics - the main difference is in the required operations and attributes compared to IPP/1.1.  I'll add a note that IPP 2.0, 2.1, and 2.2 are defined separately.

> The two IANA references are broken.  They should point to
> The [IANA-CS] and [IANA-MT] should point to these URLs:
> <>
> and <>.

I will update these accordingly.

> Minor Concerns:
> Throughout the document, "Printer object" and "IPP object" and "Printer"
> are used.  I think they mean the same thing.  If they are different,
> please include a discussion in the Introduction.  If they are the same,
> I think that using one throughout would be helpful.

Generally speaking, "Printer" and "Job" are shorthand for "Printer object" and "Job object".  "IPP object" means any IPP object (Printer or Job in this document, there are others defined in other documents...)  I can look at making this clearer in the introduction to the model.

> How does the concepts of an impression (in Section 2.3.4) and a media
> sheet (in Section 2.3.8) apply to a 3D printer?  Also, many of the
> description and status attributes described in Section 5.4 do not seem
> relevant to a 3D printer.

That's because IPP/1.1 is exclusively for 2D printers...

(The PWG is defining an IPP/2.0 extension for 3D printers which includes new attributes and values specific to 3D printers.)

> In Section 3.1, it says: "The following figures show ...".  However, it
> is talking about Figure 2, which shows several configurations.  Either
> label each configuration as a separate figure, or reword this text to
> match the existing Figure 2.

Will fix.

> In Section 4.1.3, it says: "Sections 4.1.7,, and C give ...".  I
> found this confusing.  I think that Section C is really a reference to
> Appendix C.


> In section 4.1.7, it says:
>   This value's syntax type is "out-of-band" and its encoding is defined
>   by special rules for "out-of-band" values in the "Encoding and
>   Transport" document [RFC2910bis].  Its value indicates no support for
>   the attribute itself - see the beginning of Section 5.1.
> Please clarify whether the referenced section is in [RFC2910bis] or this
> document.

Will fix.

> In Sections 4.1.9,, and 4.2.2. there are references to [RFC3196]
> and [PWG5100.19], saying that these documents "present suggested steps".
> Please reword this sentence to indicate whether these steps
> MUST/SHOULD/MAY be followed.

The implementor's guides are informative documents (and references), so I don't believe conformance terminology is appropriate here.

> In Section 5.2.11, there are references to [PWG5100.3] and [PWG5100.13].
> Please reword this sentence to indicate whether these steps
> MUST/SHOULD/MAY be followed.

I can make this a MAY.

> Nits:
> The URL for [1] and [3] are the same.  Get rid of [3].

That's an artifact of xml2rfc; I've replaced the eref's with a xref to an informative reference.

> In Section 1.1: s/The model described in this model document /
>                 /The model described in this document /
> In Section 1.1: s/some sort of filtered and context based searching /
>                 /some sort of filtered context-based searching /

Will fix.

> In Sections and 5.3.11, there is an example URL.  It would be
> better to use "" or "" in the URL.  Consider:
>   (404)

This is actually a real link to an (old) archived draft of the original RFC 2911, but I can update it to be a fake URL...

> In Section 5.3.7, the reference to "Figure 1" should be "Figure 3", and
> the legend on the figure on that same page should be corrected.  The
> figure is currently labelled with two numbers.

This is probably a bug in the XML sources; will fix.

Michael Sweet, Senior Printing System Engineer