Petrie, Glen | 10 Jun 2013 23:47

Comments and Idea for paid printing

Hello

As with the IPP FaxOut, I have unable to review the IPP Paid Printing document until now.

Overall, I was concerned that "Extension for Paid Printing" is being extended through 'finishings" while the concept of "paid-printing" is a business or commerce notion and not a finishing step.  While I need to study the document in more detail; how does the current paid-printing model support a print job where a set of differently priced transform service are needed. 

Having recently reviewed the PrintTalk specification of JDF; this is an interesting model to explore for PWG (independent of just IPP) "paid-prinitng" for several reason.   Instead of modifying/extending JDF, PrintTalk wraps JDF in a business transaction or commerce transaction.   With it's relatively simple set API calls it supports very complex set of operations ranging from Quoting, Notations, etc.; again with out modification to the print job JDF.  PrintTalk can itemize items and provide a quote for each item.  And, finally, PrintTalk is already widely used and deployed.    PWG could create a version of PrintTalk, called IppPrintTalk (or PrintTalkIpp or PrintTalkPwg) by simply replacing JDF with PWG (or IPP) in the existing PrintTalk specification.   Now IPP stays the same while extending an existing "paid printing" API and implementations which could be applied to any PWG model (Cloud?)

Other comments on the specification itself

The attribute "printer-charge-info-uri" is not defined in this document (perhaps somewhere else).  But my concern that a discussion about how a User is associated with a paid (payment) service is out-of-scope.


Section 4.2 PIN/Passcode Printing
Section 4.3 Release Printing
    I believe these sections are out-of-scope for paid-printing since there is not "payment" requirement for these types of printing functionalities.

Section 4.5 Job Review
    I believe this section is out-of-scope for paid-printing.  "Job Review" could be applied to any print scenario and not specific relevance to paid-printing.   In fact, if a User submits a print job for (100,000 copies) and payment is confirmed; then print the 100,000 copies.  

(Mike I assume specification are written to American English notation so 100.000 should be 100,000?)

 glen




--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
ipp mailing list
ipp <at> pwg.org
https://www.pwg.org/mailman/listinfo/ipp
Ira McDonald | 10 Jun 2013 22:11
Picon

High North has reviewed the IPP FaxOut specification and has no comments

Hi,

No comments - good job Mike!

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
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


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
ipp mailing list
ipp <at> pwg.org
https://www.pwg.org/mailman/listinfo/ipp
Michael Sweet | 10 Jun 2013 22:08
Picon
Favicon

Minutes posted from today's IPP concall

All,

I have posted the minutes from today's IPP WG conference call to:

	ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20130610.pdf

Our next conference call is June 24, 2013 at 3pm ET.

New action items:

	- Paul to post summary of finishing-template investigation to IPP WG list
	- Mike to issue PWG Last Call of IPP Paid Printing Extensions
	- Mike to extend IPP FaxOut Service Last Call to June 28 (DONE)

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

--

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp <at> pwg.org
https://www.pwg.org/mailman/listinfo/ipp

Michael Sweet | 10 Jun 2013 21:39
Picon
Favicon

Apple has reviewed the IPP FaxOut specification and has no comments


_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

--

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
ipp <at> pwg.org
https://www.pwg.org/mailman/listinfo/ipp

Ira McDonald | 10 Jun 2013 02:38
Picon

IPP Agenda - 3-5pm EDT 10 June 2013

Hi,
Our next IPP WG call is this week Monday 10 June 12-2pm US Pacific / 3-5pm US Eastern

Call-in toll-free number (US/Canada): 1-866-469-3239
Call-in toll number (US/Canada): 1-650-429-3300 (Primary)
Call-in toll number (US/Canada): 1-408-856-9570 (Backup)

Attendee Access Code: *******#
Attendee ID Code: # (empty)

-------------------------------------------------------
Meeting information
-------------------------------------------------------
Date: Every Monday, from Monday, July 9, 2012 to no end date
Time: 12:00 pm, Pacific Daylight Time (San Francisco)
Meeting Number: 624 587 312
Meeting Password: pwg123
-------------------------------------------------------
To start or join the online meeting
-------------------------------------------------------
Go to https://appleinc.webex.com/appleinc/j.php?ED=204995427&UID=504472682&PW=NNzM5MmRlMzBl&RT=MiM0
-------------------------------------------------------
Agenda:
(1) PWG IP Policy and Minute Taker
- Mike

(2) Approve IPP minutes from previous meeting
- ftp://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-f2f-minutes-20130516.pdf

(3) Status of IPP Paid Printing Extensions (Mike)
- ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ipppaid10-20130501-rev.pdf
- Apple prototype report posted

(4) Status of IPP Fax Out (Mike)
- PWG Last Call - ended 7 June - quorum not achieved
- extend PWG LC?

(5) Status of IPP Shared Infrastructure Extensions (Mike)
- model issues from Cloud WG?

(6) Next steps
- IPP WG telecon on Monday 24 June
- IPP WG telecon on Monday 8 July

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
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


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
ipp mailing list
ipp <at> pwg.org
https://www.pwg.org/mailman/listinfo/ipp
Lida Wang | 8 Jun 2013 02:46

Kyocera Document Solution has reviewed the IPP FAXout specification and has the comments

All,

 

The following are comments from Kyocera on IPP Faxout specification.

 

·         Line 362. 4.1.4 Job History "IPP FaxOut Jobs MUST be retained for a minimum of 300 seconds."

is actually difficult because of limitation of real memory capacity. A possible alternative is "IPP FaxOut MUST retains for a minimum of xxx Jobs."

 

·         Line 406 Table 2 - Required Printer Description Attributes

number-of-retries-default PWG 5100.FAX

number-of-retries-supported (note 6) PWG 5100.FAX

This 2 items should not be included because there are individual upper limits on retry number in each countries legally.

For example, the following are from FCC68, line standard of North America:

§ 68.318   Additional limitations.

(b) Registered terminal equipment with automatic dialing capability. (1) Automatic dialing to any individual number is limited to two successive attempts. Automatic dialing equipment which employ means for detecting both busy and reorder signals shall be permitted an additional 13 attempts if a busy or reorder signal is encountered on each attempt. The dialer shall be unable to re-attempt a call to the same number for at least 60 minutes following either the second or fifteenth successive attempt, whichever applies, unless the dialer is reactivated by either manual or external means. This rule does not apply to manually activated dialers that dial a number once following each activation.

 

·         Line 406 Table 2 - Required Printer Description Attributes

printer-fax-modem-info PWG 5100.FAX

printer-fax-modem-name PWG 5100.FAX

printer-fax-modem-number PWG 5100.FAX

This 3 items seems to be unnecessary and should be deleted, No user needs to see this kind of modem info.

 

·         Line 406 Table 2 - Required Printer Description Attributes

retry-interval-default (note 6) PWG 5100.FAX

retry-interval-supported (note 6) PWG 5100.FAX

retry-timeout-default (note 6) PWG 5100.FAX

retry-timeout-supported (note 6) PWG 5100.FAX

This 3 items should not be included, Some countries assign a restriction for automatic retry interval in consideration for avoiding the overload of their switching devices.

 

·         Line 656 7.2.6 retry-time-out (integer(1:MAX))

What is the difference between "7.2.6 retry-time-out (integer(1:MAX))" and "7.2.5 retry-interval (integer(1:MAX))"? what is the reason  both items are needed?

 

Best regards,

Lida

 

From: pwg-announce-bounces <at> pwg.org [mailto:pwg-announce-bounces <at> pwg.org] On Behalf Of Michael Sweet
Sent: Wednesday, May 01, 2013 11:42 AM
To: PWG Announcements Inc.
Subject: [Pwg-Announce] PWG Last Call of IPP FaxOut Service (05/01/13 to 06/07/13)

 

All,

[This PWG Last Call starts today Wednesday May 1, 2013 and ends Friday June 7, 2013 at 10pm US PST.]

This is the formal announcement of the PWG Last Call for the IPP FaxOut Service specification, located at:

            ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippfaxout10-20130501.pdf

All required attributes and values defined in this document have been prototyped by Apple and/or other vendors. The IPP WG has completed extensive review of the various revisions of this document and an IPP WG last call.

The PWG Process/3.0 requires that a quorum (30%) of PWG voting members must acknowledge a PWG Last Call (with or without comments), before any document can progress to PWG Formal Vote.  This PWG Last Call is NOT a Formal Vote but it DOES require your review acknowledgment.


HOW TO RESPOND

Send an email with *exactly* the following subject line format:
Subject: <Company Name> has reviewed the IPP FaxOut specification and has [no] comments


WHERE TO SEND YOUR RESPONSE

Please send your response to *all* of the following email addresses (replacing "dot" with '.' and "at" with ' <at> '):

ipp "at" pwg "dot" org (IPP WG mailing list - you must be subscribed!)
blueroofmusic "at" gmail "dot" com (Ira McDonald, IPP WG Co-Chair)
ptykodi "at" tykodi "dot" com (Paul Tykodi, IPP WG Co-Chair)
msweet "at" apple "dot" com (Michael Sweet, IPP WG Secretary and IPP FaxOut Editor)

Note that you must be subscribed to the IPP WG mailing list to send email there - otherwise your email will be silently discarded.

Please do NOT simply reply to this note on the PWG-Announce list.

Note: The PWG Definition of the Standards Development Process Version 3.0 is located at:

            http://www.pwg.org/chair/membership_docs/pwg-process30.pdf

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair



--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
ipp mailing list
ipp <at> pwg.org
https://www.pwg.org/mailman/listinfo/ipp
Ira McDonald | 4 Jun 2013 23:02
Picon

[Pwg-Announce] Fwd: IETF approves EMAN Requirements as Informational RFC




---------- Forwarded message ----------
From: The IESG <iesg-secretary <at> ietf.org>
Date: Tue, Jun 4, 2013 at 10:01 AM
Subject: [eman] Document Action: 'Requirements for Energy Management' to Informational RFC (draft-ietf-eman-requirements-14.txt)
To: IETF-Announce <ietf-announce <at> ietf.org>
Cc: eman mailing list <eman <at> ietf.org>, eman chair <eman-chairs <at> tools.ietf.org>, RFC Editor <rfc-editor <at> rfc-editor.org>


The IESG has approved the following document:
- 'Requirements for Energy Management'
  (draft-ietf-eman-requirements-14.txt) as Informational RFC

This document is the product of the Energy Management Working Group.

The IESG contact persons are Joel Jaeggli and Benoit Claise.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/




Technical Summary:

This document defines requirements for standards specifications for
energy management.  These concern monitoring functions as well as
control functions: Monitoring functions include identification of
energy-managed devices and their components, monitoring of their power
states, power inlets, power outlets, actual power, power properties,
received energy, provided energy, and contained batteries.  Control
functions serve for controlling power supply and power state of
energy-managed devices and their components.

Working Group Summary:

Version -08 of this draft was presented in the EMAN session at
IETF 84 (Vancouver).  The authors published -09, resolving the
open issues discussed at that meeting.  The draft's Working Group
Last Call ran from 4 October to 22 October this year, and raised
several more issues.  After IETF-85, the authors published its
-10 version; we believe it is now ready to submit to IESG.

Document Quality:

Are there existing implementations of the protocol?
  This is a requirements draft, not a protocol.
Have a significant number of vendors indicated their plan to implement
the specification?
  At least two vendors have implemented Energy Management systems,
  and - presumably - will make them EMAN-compliant.
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues?
  Since September the following have contributed comments on the
  EMAN list:  Ira McDonald, John Parello, Brad Schoening, Georgios
Karagian.
  However, the draft's authors/editors have done most of the work
  in developing it.
If there was a MIB Doctor, Media Type or other expert review, what was
its course (briefly)?
  The draft hasn't had any kind of expert review.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?
   Shepherd:      Nevil Brownlee
   Area Director: Joel Jaeggli


_______________________________________________
eman mailing list
eman <at> ietf.org
https://www.ietf.org/mailman/listinfo/eman


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
pwg-announce mailing list
pwg-announce <at> pwg.org
https://www.pwg.org/mailman/listinfo/pwg-announce
Michael Sweet | 4 Jun 2013 17:18
Picon
Favicon

[Pwg-Announce] Updated templates posted with new PWG logo

All,

I have posted updated Powerpoint, Keynote, and Word templates that use the new PWG logo to:


The working draft templates also include a new Exceptions section (3.3) based on our discussions at the May 2013 face-to-face.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
pwg-announce mailing list
pwg-announce <at> pwg.org
https://www.pwg.org/mailman/listinfo/pwg-announce
Petrie, Glen | 30 May 2013 16:40

Discussion on IPP FaxOut

All,

 

I have not had the cycles to review the IPP-FaxOut specification until now and was greatly surprised at the some of the requirements and specification.  

 

For example "IPP FaxOut Jobs MUST be retained for a minimum of 300 seconds", "Printers [IPP FaxOut Service???] MUST support scaling and color space conversion of document data to match the negotiated facsimile image format at the job processing time", and "Imaging Devices [IPP FaxOut Services???] that can only stream print jobs to a single destination URI MUST support retransmission of the current page".  

 

There are many of these types of requirements that appear to be Client and/or the Imaging Devices "product/implementation design specifications" and not what I expected to be API interfaces capability and job submission specifications.

 

For instance, the IPP FaxOut Service should be provide capability on "Job Retention times supported", "Fax Scaling Supported", "Color Spaces Conversion Supported" and "Retransmission Supported" versus this specification setting device and client design and implementation requirements for these capabilities.

 

An example of the simplest fax out would be something like "no-cover, single-sheet, one-recipient, (jpeg) image – to – fax binary CCITT Encoding, no-retry, no-job-hold-after".  Anything beyond that should be based on the capability of the specific IPP FaxOut Service implementation and/or the Client implementation but independent of a "MUST" requirement of the PWG / IPP FaxOut Service specification.   However, the PWG / IPP FaxOut Service specification must define how capability information is specified.

 

Glen

 

 

 


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
ipp mailing list
ipp <at> pwg.org
https://www.pwg.org/mailman/listinfo/ipp
Michael Sweet | 23 May 2013 19:37
Picon
Favicon

NOTICE: IPv6 Link-Local Addresses in URIs

All,

RFC 3986/STD 66 (Uniform Resource Identifier (URI): Generic Syntax) did not define a syntax for specifying IPv6 link-local addresses with zone identifiers (interface names/numbers).  Back in 2005, I requested clarification and received the following advice: use the IPvFuture syntax and "+" as a separator between the IPv6 address and Zone ID, for example an IPP URI at address FE80::1234 on interface "en0" would be encoded as follows:


For IPP Everywhere we require that Clients use this form in the Host: header when submitting a request to a Printer so that the Printer can provide the Client with link-local addresses containing the Client's Zone ID information.  This allows referenced URIs in IPP responses to work from the Client, and similarly for URLs in HTML returned by the Printer's Embedded Web Server (EWS).

Fast forward (!) 8 years and now the IETF has finally published an official extension to RFC 3986 titled Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers (RFC 6874). Unfortunately, the extension introduces an incompatible new address format (IPv6addrz); for the previous example the URI would be encoded as:


However, applications conforming to RFC 3986 will reject this address information since percent-encoding and Zone ID information is not allowed for an IPv6address literal. In particular, all versions of CUPS since 2005 will reject IPv6 link local addresses using this format.

In addition, RFC 6874 introduces some unfortunate conformance requirements: Clients MUST NOT include their Zone ID in URIs or the HTTP Host header for the reason that the Server has no use for the information (!).

I have had some fruitful initial discussions with the IETF Area Directors and the 6man (IPv6) working group chairs about updating this document and will be preparing a replacement for RFC 6874 with review from the PWG IPP WG to ensure that our needs are met.  My planned changes are as follows:

1. Add the IPvFuture encoding ([v1.address+zoneid]) as an alternate, backwards-compatible encoding. The new percent-encoded format will still be preferred. Provide implementation guidance with an eye towards backwards-compatibilty.

2. Add use cases and discussion concerning why/when IPv6 link-local addresses are used, and how clients and servers can use the zone ID to provide/generate accessible URIs

3. Modify the current conformance terms to align with our usage in IPP (Host header) and require servers to validate and use the Host value as supplied

In the meantime, please make sure to *NOT* strictly follow RFC 6874 as it will break your printers when used with IPv6 link-local addresses.  My recommendation would be to support consumption/use of RFC 6874 URIs but continue to include and accept the Zone ID in the Host header.  For printers this means returning URIs using the same format as supplied, i.e. if a Client supplies an RFC 6874 address, return an RFC 6874 URI, otherwise return an RFC 3986 URI.

References:

    RFC 3986/STD 66: Uniform Resource Identifier (URI): Generic Syntax


    RFC 6874: Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers


_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
ipp mailing list
ipp <at> pwg.org
https://www.pwg.org/mailman/listinfo/ipp
Michael Sweet | 21 May 2013 16:45
Picon
Favicon

RFC: Proposed errata for PWG 5100.3 (Production Printing)

All,

As discussed in last week's session, there is no easy migration from the finishings attribute (1setOf type2 enum) to the finishings-col attribute (1setOf collection).

The primary issue is that the finishing-template member attribute is defined as a name value and does not support well-known keyword values.  I propose that we amend the definition of the finishing-template member attribute and finishing-template-supported Printer attribute to include type2 keywords, e.g.:

    "finishings-col (1setOf collection)"
        "finishing-template (name(MAX) | type2 keyword)"  <--- NEW
        "stitching (collection)"
            "stitching-locations (1setOf integer(0:MAX))"
            "stitching-offset (integer(0:MAX))"
            "stitching-reference-edge (type2 keyword)"

    "finishing-template-supported (1setOf (name(MAX) | type2 keyword))"  <--- NEW
    "finishings-col-supported (1setOf type2 keyword)"
    "stitching-locations-supported (1setOf (integer(0:MAX) | rangeOfInteger(0:MAX)))"
    "stitching-offset-supported (1setOf (integer(0:MAX) | rangeOfInteger(0:MAX)))"
    "stitching-reference-edge-supported (1setOf type2 keyword)"

The keyword values would correspond to the finishings enum names (staple, punch, bale, etc.).

Longer term we should also probably extend the finishings-col Job Template attribute to include fold, punch, and trim member attributes, which would make use of the same kinds of values as as the current "stitching" member attribute (which IIRC handles bind, edge stitch, and staple, although that too could be made explicit), for example:

    "finishings-col (1setOf collection)"
        "fold (1setOf collection)" (list of folds)
            "fold-direction (type2 keyword)" (in/out or up/down)
            "fold-location (integer(0:MAX))"
            "fold-reference-edge (type2 keyword)"
        "punch (collection)"
            "punch-locations (1setOf integer(0:MAX))"
            "punch-offset (integer(0:MAX))"
            "punch-reference-edge (type2 keyword)"
        "trim (1setOf collection)" (list of cuts)
            "trim-location (1setOf integer(0:MAX))"
            "trim-reference-edge (type2 keyword)"

    "fold-direction-supported (1setOf type2 keyword)"
    "fold-location-supported (1setOf (integer(0:MAX) | rangeOfInteger(0:MAX)))"
    "fold-reference-edge-supported (1setOf type2 keyword)"

    "punch-locations-supported (1setOf (integer(0:MAX) | rangeOfInteger(0:MAX)))"
    "punch-offset-supported (1setOf (integer(0:MAX) | rangeOfInteger(0:MAX)))"
    "punch-reference-edge-supported (1setOf type2 keyword)"

    "trim-location-supported (1setOf (integer(0:MAX) | rangeOfInteger(0:MAX)))"
    "trim-reference-edge-supported (1setOf type2 keyword)"

That said, I think extending finishings-col needs to happen in a separate (small) spec, and we should look to other specs (e.g. JDF and MSPS) to make sure we aren't defining something completely out in left field.

Thoughts?

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
ipp mailing list
ipp <at> pwg.org
https://www.pwg.org/mailman/listinfo/ipp

Gmane