Ira/Smith,
As an implementor's guide, I do not believe the guide should introduce any MUSTs specific to this document since we are documenting best practices based on existing specifications. I am OK with reiterating MUSTs that come from a base spec, but I suspect that might limit the useful life of the document when those base specifications are updated/replaced. I have no problem with SHOULDs since that matches the spirit of best practices.
(let's not forget that RFC 3196 is Informational...)
> On Dec 8, 2014, at 1:16 PM, Ira McDonald <blueroofmusic at gmail.com> wrote:
>> Hi Smith,
>> I strongly agree with your position - the IPP Implementor's Guide v2 is going
> to be a standards-track (Normative) PWG spec. And statements about
> MUST (requirement) or SHOULD (recommendation) for *both* Clients and
> Printers should be in the document.
>> Because the title of section 4 says it's about Clients, any MUST/SHOULD
> for Printers should be via a point to section 7.
>> While this document mostly contains the first-ever guidance for Clients, the
> original IG v1 was all about Printer implementations, and IG v2 certainly
> should add best practices (especially strong SHOULD statements) about
> Printer behavior, when they haven't already been specified in other IETF
> or PWG standards-track IPP specs.
>> It's also appropriate for IG v2 to recommend updates/tightening of other
> existing PWG IPP specs, when those are updated.
>> 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/blueroofmusic>
>http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
> mailto: blueroofmusic at gmail.com <mailto:blueroofmusic at gmail.com>
> Winter 579 Park Place Saline, MI 48176 734-944-0094
> Summer PO Box 221 Grand Marais, MI 49839 906-494-2434
>>> On Mon, Dec 8, 2014 at 12:16 PM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com <mailto:smith.kennedy at hp.com>> wrote:
> Greetings,
>> The IPP Implementor’s Guide v2 has a number of comments identifying issues that need to be resolved, some of which require discussion. I wanted to raise each topic in its own email thread to the reflector rather than relying on members of the WG finding on their own, or raising them in the meeting and hoping attendees can develop a position on the fly.
>> Topic #1: Normative Statements in section 4
> In the minutes from “ippv2-concall-minutes-20140428.pdf” :
>>http://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20140428.pdf <http://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20140428.pdf>
> Item 5d says “4.x: Remove any hidden conformance requirements for Printers - basically this document is about recommendations for existing standards, which define those conformance requirements”. I’m not sure that I agree with this, because that seems to remove any demand to qualitatively evaluate the different options in the subsections of section 4. I think it isn’t a question of “pass / fail” but rather evaluation using the qualitative labels in section 4. I know this makes section 4 unique when compared with the typical conventions of using RFC 2119 normative language and generating conformance requirements and test plans from that. But I pretty strongly believe an IPP Implementor’s Guide v2 test suite needs to evaluate Clients and Printers for their quality.
>> Thoughts?
>> Smith
>>>>> _______________________________________________
> ipp mailing list
>ipp at pwg.org <mailto:ipp at pwg.org>
>https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>
>>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20141208/5e5acb7a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4798 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20141208/5e5acb7a/attachment.p7s>