[IPP] Toward a "prototype" of the IPP Implementor's Guide v2 - agreeing on the scope

[IPP] Toward a "prototype" of the IPP Implementor's Guide v2 - agreeing on the scope

Ira McDonald blueroofmusic at gmail.com
Mon Mar 17 21:05:03 UTC 2014


Hi,

I agree with Mike - if this is a PWG standards-track document, then there
needs
to be a top-level section "Conformance Requirements" and subsections for
"IPP Client Conformance Requirements" and "IPP Printer Conformance
Requirements" (not exhaustive - just pointers to the named sections
elsewhere
that contain detailed conformance requirements).

See IPP 2.0 Second Edition (PWG 5100.12) for conformance examples.

By recent tradition, we have done all the REQUIRED features in prototypes.
But PWG Process 3.0 does *not* have a prototype definition that mandates
this coverage.

For the IPP Implementors Guide v2, we might want to be less exhaustive (or
we may not get prototype reports, which would be counterproductive).

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/highnorthinc
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, Mar 17, 2014 at 11:24 AM, Michael Sweet <msweet at apple.com> wrote:

> Smith,
>
> 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.
>
> 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).
>
>
> On Mar 10, 2014, at 12:39 PM, Kennedy, Smith (Wireless Architect) <
> smith.kennedy at hp.com> wrote:
>
> > Greetings,
> >
> > 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.
> >
> > 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.
> >
> > Thanks for any feedback!
> >
> > Smith
> >
> > /**
> >    Smith Kennedy
> >    Hewlett-Packard Co.
> > */
> >
> >
> > 1. Introduction
> >
> >
> > 2. Terminology
> > 2.1 Conformance Terminology
> > 2.2 Imaging Terminology
> > 2.3 Other Terminology
> > 2.4 Acronyms and Organizations
> >
> >
> > 3. Requirements
> > 3.1 Rationale
> > 3.2 Use Cases
> > 3.2.1 Developer Implementing IPP Client Support
> > 3.2.2 Developer Implementing IPP Support in a New Printer
> > 3.3 Out of Scope
> > 3.4 Design Requirements
> >
> >
> > 4. Tasks and Implementation Alternatives
> > 4.1 Create A Relationship With A Printer
> > 4.1.1 Discover And Select A Printer Via A Discovery Protocol
> > 4.1.2 Select A Printer Via Static DNS Hostname, IPv6 Address Or IPv4
> Address
> > 4.2 Validate User Access to Printer
> > 4.3 Get Printer Information and Print Job Options
> > 4.4 Check constraints between presented options
> > 4.5 Submitting a Print Job
> > 4.5.1 Submitting a Job with document data
> > 4.5.2 Submitting a Job with document references
> > 4.5.3 Handling Print Job Creation Errors
> > 4.6 Monitoring print job status
> > 4.7 Canceling a Print Job
> > 4.8 Getting Printer supplies status
> >
> >
> > 5. Using Attributes with IPP Operations
> > 5.1 General Principles
> > 5.1.1 IPP Client Recommendations
> > 5.1.2 IPP Printer Recommendations
> > 5.2 Explicit "document-format" Selection
> > 5.2.1 IPP Client Recommendations
> > 5.2.2 IPP Printer Recommendations
> > 5.3 Prefer "media-col" Attribute To "media" Attribute
> > 5.4 Specifying Finishings With "finishings-col", "finishings" and Others
> > 5.4.1 IPP Client Recommendations
> > 5.4.2 IPP Printer Recommendations
> > 5.5 Controlling Intended Output Using "ipp-attribute-fidelity",
> "job-mandatory-attributes", and "pdl-override-supported"
> > 5.5.1 IPP Client Recommendations
> > 5.5.2 IPP Printer Recommendations
> > 5.6 Prefer "multiple-document-handling" For Copies Collation
> > 5.7 Prefer Supplying Explicit "orientation-requested" Attribute
> > 5.8 Evaluating Printer Capability Attributes
> > 5.8.1 ipp-features-supported
> > 5.8.2 xxx-supported
> > 5.8.3 xxx-default
> > 5.8.4 xxx-ready
> > 5.8.5 job-creation-attributes-supported
> > 5.8.6 printer-settable-attributes-supported
> > 5.8.7 operations-supported
> > 5.8.8 job-constraints-supported / job-resolvers-supported
> > 5.8.9 media-col-database
> >
> >
> > 6. IPP Object Status Attributes
> > 6.1 Printer Status and Notifications
> > 6.2 Job Status
> > 6.3 Document Status
> >
> >
> > 7. IPP Printer Best Practices
> > 7.1 Resource URIs
> >
> >
> > 8. HTTP Protocol Use
> > 8.1 HTTP/1.1 Update
> > 8.2 HTTP/1.1 Expect Header
> > 8.2.1 HTTP Client
> > 8.2.2 HTTP Server
> > 8.3 "Host" Header Field
> > 8.4 If-Modified-Since, Last-Modified, and 304 Not Modified
> > 8.5 Cache-Control
> >
> >
> > 9. Security Considerations
> > 9.1 Client Security Considerations
> > 9.1.1 HTTP/1.1 Expect Header
> > 9.1.2 HTTP Upgrade (RFC 2817)
> > 9.1.3 IPP Operations Used To Detect Authentication or Encryption
> > 9.1.4 Using the "ipps:" URI Scheme
> > 9.1.5 Document Encryption
> > 9.2 Server Security Considerations
> > 9.2.1 HTTP/1.1 Expect Header
> > 9.2.2 Support for HTTP Upgrade (RFC 2817)
> > 9.2.3 Support For The "ipps:" URI Scheme
> > 9.2.4 Document Encryption
> >
> >
> > 10. Important Implementation Options
> > 10.1 Using "xxx-actual" attribute
> > 10.2 Using "preferred-attributes" attribute
> >
> >
> > 11. Internationalization Considerations
> > 11.1 Client Considerations
> > 11.2 Server Considerations
> >
> > _______________________________________________
> > ipp mailing list
> > ipp at pwg.org
> > https://www.pwg.org/mailman/listinfo/ipp
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>
> _______________________________________________
> ipp mailing list
> ipp at pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140317/69b0d732/attachment.html>


More information about the ipp mailing list