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

[Jari Arkko <[e-mail]>]

Thanks for the review, Russ & thanks Michael for taking it into account. I trust that these changes will find their way into the document, and have balloted No Objection.

Jari

On 26 Jul 2016, at 23:54, Michael Sweet <[e-mail]> wrote:

> Russ,
> 
> 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 <[e-mail]> 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 iana.org.
>> The [IANA-CS] and [IANA-MT] should point to these URLs:
>> <http://www.iana.org/assignments/character-sets/character-sets.xhtml>
>> and <http://www.iana.org/assignments/media-types/media-types.xhtml>.
> 
> 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, 4.2.1.2, and C give ...".  I
>> found this confusing.  I think that Section C is really a reference to
>> Appendix C.
> 
> Correct.
> 
>> 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, 4.2.1.2, 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 4.1.6.4 and 5.3.11, there is an example URL.  It would be
>> better to use "example.com" or "example.net" in the URL.  Consider:
>> 
>>  (404) http://ftp.example.com/pub/ipp-model-v11-990510.pdf
> 
> 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 example.com 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
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art