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 <msw...@apple.com> 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 <hous...@vigilsec.com> 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 > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
