attachment
<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>Hi,<br><br></div>I agree with Mike - if this is a PWG standards-track document, then there needs<br>to be a top-level section "Conformance Requirements" and subsections for<br>
</div>"IPP Client Conformance Requirements" and "IPP Printer Conformance <br>Requirements" (not exhaustive - just pointers to the named sections elsewhere<br>that contain detailed conformance requirements).<br>
<br></div><div>See IPP 2.0 Second Edition (PWG 5100.12) for conformance examples.<br><br>By recent tradition, we have done all the REQUIRED features in prototypes.<br></div></div></div></div>But PWG Process 3.0 does *not* have a prototype definition that mandates <br>
this coverage. <br><br>For the IPP Implementors Guide v2, we might want to be less exhaustive (or <br>we may not get prototype reports, which would be counterproductive).<br></div></div><br></div>Cheers,<br></div>- Ira<br>
<div><div><br></div></div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr">Ira McDonald (Musician / Software Architect)<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>Chair - Linux Foundation Open Printing WG<br>
Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br>IETF Designated Expert - IPP & Printer MIB<br>Blue Roof Music / High North Inc<br><a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br>
<a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>
Winter 579 Park Place Saline, MI 48176 734-944-0094<br>Summer PO Box 221 Grand Marais, MI 49839 906-494-2434<br><br><div style="display:inline"></div><div style="display:inline"></div><div style="display:inline"></div>
<div></div><div></div><div></div><div></div></div></div>
<br><br><div class="gmail_quote">On Mon, Mar 17, 2014 at 11:24 AM, Michael Sweet <span dir="ltr"><<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Smith,<br>
<br>
I think as long as we have clients and printers that implement the good, better, or best behaviors in sections 4-7 and the required bits in section 8, then we can claim sufficient prototyping to advance the document to stable status.<br>
<br>
And it might make sense to add a Conformance Requirements section that specifically states the minimum conformance requirements (which we can use/treat as minimum prototype requirements).<br>
<div><div class="h5"><br>
<br>
On Mar 10, 2014, at 12:39 PM, Kennedy, Smith (Wireless Architect) <<a href="mailto:smith.kennedy@hp.com">smith.kennedy@hp.com</a>> wrote:<br>
<br>
> Greetings,<br>
><br>
> Following up from our last conference call, in order to bring the IPP Implementor’s Guide v2 to the “Prototype” state, we need to decide on the scope of the IPP Implementor’s Guide v2.<br>
><br>
> Below is the outline of the document as it currently stands, with separating space between each primary section. Please reply to comment on its scope to recommend topic addition / change / removal, so we can discuss via email.<br>
><br>
> Thanks for any feedback!<br>
><br>
> Smith<br>
><br>
> /**<br>
> Smith Kennedy<br>
> Hewlett-Packard Co.<br>
> */<br>
><br>
><br>
> 1. Introduction<br>
><br>
><br>
> 2. Terminology<br>
> 2.1 Conformance Terminology<br>
> 2.2 Imaging Terminology<br>
> 2.3 Other Terminology<br>
> 2.4 Acronyms and Organizations<br>
><br>
><br>
> 3. Requirements<br>
> 3.1 Rationale<br>
> 3.2 Use Cases<br>
> 3.2.1 Developer Implementing IPP Client Support<br>
> 3.2.2 Developer Implementing IPP Support in a New Printer<br>
> 3.3 Out of Scope<br>
> 3.4 Design Requirements<br>
><br>
><br>
> 4. Tasks and Implementation Alternatives<br>
> 4.1 Create A Relationship With A Printer<br>
> 4.1.1 Discover And Select A Printer Via A Discovery Protocol<br>
> 4.1.2 Select A Printer Via Static DNS Hostname, IPv6 Address Or IPv4 Address<br>
> 4.2 Validate User Access to Printer<br>
> 4.3 Get Printer Information and Print Job Options<br>
> 4.4 Check constraints between presented options<br>
> 4.5 Submitting a Print Job<br>
> 4.5.1 Submitting a Job with document data<br>
> 4.5.2 Submitting a Job with document references<br>
> 4.5.3 Handling Print Job Creation Errors<br>
> 4.6 Monitoring print job status<br>
> 4.7 Canceling a Print Job<br>
> 4.8 Getting Printer supplies status<br>
><br>
><br>
> 5. Using Attributes with IPP Operations<br>
> 5.1 General Principles<br>
> 5.1.1 IPP Client Recommendations<br>
> 5.1.2 IPP Printer Recommendations<br>
> 5.2 Explicit "document-format" Selection<br>
> 5.2.1 IPP Client Recommendations<br>
> 5.2.2 IPP Printer Recommendations<br>
> 5.3 Prefer "media-col" Attribute To "media" Attribute<br>
> 5.4 Specifying Finishings With "finishings-col", "finishings" and Others<br>
> 5.4.1 IPP Client Recommendations<br>
> 5.4.2 IPP Printer Recommendations<br>
> 5.5 Controlling Intended Output Using "ipp-attribute-fidelity", "job-mandatory-attributes", and "pdl-override-supported"<br>
> 5.5.1 IPP Client Recommendations<br>
> 5.5.2 IPP Printer Recommendations<br>
> 5.6 Prefer "multiple-document-handling" For Copies Collation<br>
> 5.7 Prefer Supplying Explicit "orientation-requested" Attribute<br>
> 5.8 Evaluating Printer Capability Attributes<br>
> 5.8.1 ipp-features-supported<br>
> 5.8.2 xxx-supported<br>
> 5.8.3 xxx-default<br>
> 5.8.4 xxx-ready<br>
> 5.8.5 job-creation-attributes-supported<br>
> 5.8.6 printer-settable-attributes-supported<br>
> 5.8.7 operations-supported<br>
> 5.8.8 job-constraints-supported / job-resolvers-supported<br>
> 5.8.9 media-col-database<br>
><br>
><br>
> 6. IPP Object Status Attributes<br>
> 6.1 Printer Status and Notifications<br>
> 6.2 Job Status<br>
> 6.3 Document Status<br>
><br>
><br>
> 7. IPP Printer Best Practices<br>
> 7.1 Resource URIs<br>
><br>
><br>
> 8. HTTP Protocol Use<br>
> 8.1 HTTP/1.1 Update<br>
> 8.2 HTTP/1.1 Expect Header<br>
> 8.2.1 HTTP Client<br>
> 8.2.2 HTTP Server<br>
> 8.3 "Host" Header Field<br>
> 8.4 If-Modified-Since, Last-Modified, and 304 Not Modified<br>
> 8.5 Cache-Control<br>
><br>
><br>
> 9. Security Considerations<br>
> 9.1 Client Security Considerations<br>
> 9.1.1 HTTP/1.1 Expect Header<br>
> 9.1.2 HTTP Upgrade (RFC 2817)<br>
> 9.1.3 IPP Operations Used To Detect Authentication or Encryption<br>
> 9.1.4 Using the "ipps:" URI Scheme<br>
> 9.1.5 Document Encryption<br>
> 9.2 Server Security Considerations<br>
> 9.2.1 HTTP/1.1 Expect Header<br>
> 9.2.2 Support for HTTP Upgrade (RFC 2817)<br>
> 9.2.3 Support For The "ipps:" URI Scheme<br>
> 9.2.4 Document Encryption<br>
><br>
><br>
> 10. Important Implementation Options<br>
> 10.1 Using "xxx-actual" attribute<br>
> 10.2 Using “preferred-attributes” attribute<br>
><br>
><br>
> 11. Internationalization Considerations<br>
> 11.1 Client Considerations<br>
> 11.2 Server Considerations<br>
><br>
> _______________________________________________<br>
> ipp mailing list<br>
> <a href="mailto:ipp@pwg.org">ipp@pwg.org</a><br>
> <a href="https://www.pwg.org/mailman/listinfo/ipp" target="_blank">https://www.pwg.org/mailman/listinfo/ipp</a><br>
<br>
</div></div>_________________________________________________________<br>
Michael Sweet, Senior Printing System Engineer, PWG Chair<br>
<br>
<br>_______________________________________________<br>
ipp mailing list<br>
<a href="mailto:ipp@pwg.org">ipp@pwg.org</a><br>
<a href="https://www.pwg.org/mailman/listinfo/ipp" target="_blank">https://www.pwg.org/mailman/listinfo/ipp</a><br>
<br></blockquote></div><br></div>