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

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Mon, 10 Mar 2014 16:39:10 +0000

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
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Mon, 17 Mar 2014 11:24:13 -0400

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).

> 11.2 Server Considerations

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Ira McDonald <[email-masked]>
Date: Mon, 17 Mar 2014 17:05:03 -0400

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: [email-masked]
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 <[email-masked]> 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).
>
>
> > 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
> > 5.5 Controlling Intended Output Using "ipp-attribute-fidelity",
> "job-mandatory-attributes", and "pdl-override-supported"
> > 10.2 Using "preferred-attributes" attribute
> >
> >