headers
Michael Sweet | 2 Apr 2012 23:08
Picon
Favicon

Minutes posted from today's Cloud/IPP concall

All,

I have posted the minutes from today's combined Cloud Imaging and IPP working group conference call to:


Our next Cloud Imaging WG conference call will be April 16, 2012 at 3:00pm Eastern Time.

New action items:

- Mike to post prototype statement for IPP JPS3
- Mike to provide IPP slide on supply types and their printer-state-reasons
- Ira to reduce RFC 4559 reference in LDAP schema to informative

________________________________________________________________________
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
Permalink | Reply | 0 comments |
headers
Petrie, Glen | 3 Apr 2012 00:38

A different function model for discuss

All,

 

After today’s meeting, I thought I would try to draw a slightly different representation of the functional model diagram than what is in the current model document.  In the current model it is very unclear what and where the “Cloud Print Manager” is (is in its own cloud or is it proxy (so not really a cloud service) or in the printer (so not really a cloud service)).   Why does the (Print) Client “register” with the Cloud Provider instead of just using the Cloud Print Provider.

 

In the functional model attached, I propose the more cloud centric model which places service, security and other functionality in the Cloud. The model is not specifically concerned with interfaces such as using IPP; it is meant to be more a very top level view.  In the attached model the Client uses or accesses the Cloud Provider for printing services.  The User interacts with the Cloud Print Provider to select a Print Service associated with the User.  The Cloud Print Provider then sends Capability information (which likely has no secure information) to the Client.  The Print Client creates Print Job Ticket (with a Print Content reference) which is sent to the Print Service (or Print Service Manager) for printing.  The Print Service accepts (or rejects the Print Job).  The Print Service prints the Print Job and sends status info to the Print Status Service.   Federated printing also work quit well with this model.

 

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
Permalink | Reply | 1 comment |
headers
larryupthegrove | 3 Apr 2012 02:38
Picon

RE: A different function model for discuss

All,

 

The reason I see for having a “Print Manager” is for the purpose of having a standard for connecting a printer (logical or physical) to the cloud provider.

 

So the simplest implementation would reflect just a user connecting to the cloud provider.  The cloud provider “owns” the printers, so there isn’t any outgoing connection to model.

Examples would be Staples, Mimeo.com, Vistaprint.com

 

Second implementation would be devices not owned by the cloud provider.  Current implementations include mail protocols, FTP, IPP, route via Dropbox, Box, Google cloud print, etc.  So a standard should address a common solution that works for a variety of implementations.  So having a cloud print manager at , or as part of, each device makes sense to me.

 

The third implementation would be a more robust print manager, which would control multiple devices off of a single connection.  My example would be IBM InfoPrint manager or similar output manager.

 

So I see two parts to this, one between the user and the cloud provider, and one between the cloud provider and some common point that works for multiple implementations.  Since in a large number of cases the print data has to transverse into a private network, that common point should be capable of being hosted within a private network.

 

Just my thoughts…

 

Larry

 

 

From: ipp-bounces <at> pwg.org [mailto:ipp-bounces <at> pwg.org] On Behalf Of Petrie, Glen
Sent: Monday, April 02, 2012 3:38 PM
To: ipp <at> pwg.org
Subject: [IPP] A different function model for discuss

 

All,

 

After today’s meeting, I thought I would try to draw a slightly different representation of the functional model diagram than what is in the current model document.  In the current model it is very unclear what and where the “Cloud Print Manager” is (is in its own cloud or is it proxy (so not really a cloud service) or in the printer (so not really a cloud service)).   Why does the (Print) Client “register” with the Cloud Provider instead of just using the Cloud Print Provider.

 

In the functional model attached, I propose the more cloud centric model which places service, security and other functionality in the Cloud. The model is not specifically concerned with interfaces such as using IPP; it is meant to be more a very top level view.  In the attached model the Client uses or accesses the Cloud Provider for printing services.  The User interacts with the Cloud Print Provider to select a Print Service associated with the User.  The Cloud Print Provider then sends Capability information (which likely has no secure information) to the Client.  The Print Client creates Print Job Ticket (with a Print Content reference) which is sent to the Print Service (or Print Service Manager) for printing.  The Print Service accepts (or rejects the Print Job).  The Print Service prints the Print Job and sends status info to the Print Status Service.   Federated printing also work quit well with this model.

 

Glen

 


--
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
Permalink | Reply | 0 comments |
headers
Kennedy, Smith (Wireless Architect | 3 Apr 2012 02:50
Picon
Favicon

Re: IPP and HTTP/1.1 pipelining - thoughts or positions?

Thanks as always for your quick replies and help, Mike!

Smith

On 2012-03-30, at 5:22 PM, Michael Sweet wrote:

> Smith,
> 
> On Mar 30, 2012, at 3:07 PM, Kennedy, Smith (Wireless Architect) wrote:
>> ...
>> RFC 2616 section 9.1.2 says that the POST method is non-idempotent, for understandable reasons.  But in
the context of IPP, it seems to me that the idempotency of the IPP operation, not the HTTP request method,
that should be considered.  For instance, the Get-Job-Status or Get-Job-Supported-Values operations,
and even the Set-Printer-Attributes operation as well, are all idempotent as far as the Printer, Job and
Subscription objects are concerned.
> 
> Because IPP is layered over HTTP and uses POST operations, all of the issues with HTTP request processing
apply whether the corresponding IPP operation is idempotent or not.  You just can't safely pipeline
multiple IPP request messages to an IPP printer since any one of those requests may fail and close the HTTP
connection (particularly for things like authentication) or otherwise return an error that you cannot
(reliably) link to a particular request.  And speaking of authentication, all IPP clients should be using
the HTTP Expect header to elicit a 100 (continue), 401 (unauthorized), 403 (forbidden), or 426 (upgrade)
response before the IPP request message and document data is sent - that also prevents pipelining from
being used.
> 
> But back to your original question, we might be able to define (in IPP terms, not HTTP) certain IPP
operations (like Get-Job-Attributes, Get-Printer-Supported-Values) as idempotent, but others
(like Set-Printer-Attributes) specifically have side-effects that make them non-idempotent.  This is
one of the reasons RFC 2616 talks about HTML forms and GET vs. POST - query forms using GET are OK, but forms
that cause something to change/happen have to use POST because they are not idempotent.
> 
>> Is there an official position on pipelining for IPP that overrides the recommendations for HTTP/1.1
laid out in RFC 2616 Section 8.1.2.2?
> 
> 
> You'll find an errata to RFC 3196 (IPP Implementers Guide) on this; basically, pipelining of and early
responses to POST requests are not allowed, per RFC 2616.
> 
> ________________________________________________________________________
> 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
Permalink | Reply | 0 comments |
headers
larryupthegrove | 3 Apr 2012 07:12
Picon

RE: A different function model for discuss

ftp://ftp.pwg.org/pub/pwg/cloud/wd/wd-cloudmodel10-20120330.docx

 

Is the document we were discussing.  Other discussion notes are in the meeting minutes and BOF presentations at http://www.pwg.org/cloud/index.html

 

 

Larry Upthegrove

 

From: Nishino，Tetsuya(西野徹也) [mailto:tetsuya.nishino <at> dc.kyocera.com]
Sent: Monday, April 02, 2012 9:25 PM
To: larryupthegrove; 'Petrie, Glen'; ipp <at> pwg.org
Subject: RE: [IPP] A different function model for discuss

 

Hi All,

 

Can someone send me a link so that I can understand the diagram with the print manager, the cloud printer, printers and so on?

 

Thanks,

Tetsu

 

=========================================================
KYOCERA Document Solutions Inc.
R&D Department 63, Software 1 R&D Division, Corporate Software R&D  Division

Tetsuya Nishino

2-14-9, Tamagawadai, Setagaya-ward, Tokyo, 158-8610 Japan
Tel:+81-03-3708-3846 / Fax:+81-03-3708-0423
(tetsuya.nishino <at> dc.kyocera.com)
http://www.kyoceradocumentsolutions.com
=========================================================
New Document Solutions for your Business.
"KYOCERA Document Solutions Inc." reborn on April 1.

"KYOCERA MITA Corporation" is now called " KYOCERA Document Solutions Inc."
-----------------------------------------------------------------------------

From: ipp-bounces <at> pwg.org [mailto:ipp-bounces <at> pwg.org] On Behalf Of larryupthegrove
Sent: Tuesday, April 03, 2012 9:39 AM
To: 'Petrie, Glen'; ipp <at> pwg.org
Subject: RE: [IPP] A different function model for discuss

 

All,

 

The reason I see for having a “Print Manager” is for the purpose of having a standard for connecting a printer (logical or physical) to the cloud provider.

 

So the simplest implementation would reflect just a user connecting to the cloud provider.  The cloud provider “owns” the printers, so there isn’t any outgoing connection to model.

Examples would be Staples, Mimeo.com, Vistaprint.com

 

Second implementation would be devices not owned by the cloud provider.  Current implementations include mail protocols, FTP, IPP, route via Dropbox, Box, Google cloud print, etc.  So a standard should address a common solution that works for a variety of implementations.  So having a cloud print manager at , or as part of, each device makes sense to me.

 

The third implementation would be a more robust print manager, which would control multiple devices off of a single connection.  My example would be IBM InfoPrint manager or similar output manager.

 

So I see two parts to this, one between the user and the cloud provider, and one between the cloud provider and some common point that works for multiple implementations.  Since in a large number of cases the print data has to transverse into a private network, that common point should be capable of being hosted within a private network.

 

Just my thoughts…

 

Larry

 

 

From: ipp-bounces <at> pwg.org [mailto:ipp-bounces <at> pwg.org] On Behalf Of Petrie, Glen
Sent: Monday, April 02, 2012 3:38 PM
To: ipp <at> pwg.org
Subject: [IPP] A different function model for discuss

 

All,

 

After today’s meeting, I thought I would try to draw a slightly different representation of the functional model diagram than what is in the current model document.  In the current model it is very unclear what and where the “Cloud Print Manager” is (is in its own cloud or is it proxy (so not really a cloud service) or in the printer (so not really a cloud service)).   Why does the (Print) Client “register” with the Cloud Provider instead of just using the Cloud Print Provider.

 

In the functional model attached, I propose the more cloud centric model which places service, security and other functionality in the Cloud. The model is not specifically concerned with interfaces such as using IPP; it is meant to be more a very top level view.  In the attached model the Client uses or accesses the Cloud Provider for printing services.  The User interacts with the Cloud Print Provider to select a Print Service associated with the User.  The Cloud Print Provider then sends Capability information (which likely has no secure information) to the Client.  The Print Client creates Print Job Ticket (with a Print Content reference) which is sent to the Print Service (or Print Service Manager) for printing.  The Print Service accepts (or rejects the Print Job).  The Print Service prints the Print Job and sends status info to the Print Status Service.   Federated printing also work quit well with this model.

 

Glen

 


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


--
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
Permalink | Reply | 0 comments |
headers
Ira McDonald | 4 Apr 2012 02:23
Picon

LDAP Printer Schema (3 April 2012)

Hi,

Pat - we'll review this version briefly next week at the PWG IPP teleconference
at 3-5pm EDT Monday 9 April 2012 and in more detail at the PWG/Open Printing
Summit during the IPP WG session 1-5pm PDT 25 April 2012.  We're still not
assigning OIDs to the few new attributes, because we're waiting for the chosen
set to stabilize (at April PWG/OPS meeting).
 
I've just posted a second Internet-Draft of LDAP Schema for Printer Services to:

 ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ldap-printer-schema-01-20120403.txt
 - plaintext Internet-Draft format (warning - contains explicit formfeed characters)

 ftp://ftp.pwg.org/pub/pwg/ipp/wd/draft-mcdonald-ldap-printer-schema-01-20120403.pdf
 - line numbered PDF of plaintext - use this version for review, please

This document has already been accepted and posted to the IETF I-D repository.

This document was created by revising the original LDAP Schema for Printer
Services [RFC3712].

This version adds new IPP directory attributes proposed in Table 1 of section 4.1
Printer Description Attributes Used in Discovery in the latest draft of PWG IPP
Everywhere 1.0.

Cheers,
- Ira

---------------------------------------
Change History:

   3 April 2012 - draft-mcdonald-ldap-printer-schema-01.txt
   - Second draft - for IEEE-ISTO PWG IPP Everywhere project

   - Global - changed [IPPEVE1] to [PWG5100.EVE] and [IPPJPS3] to
   [PWG5100.JPS3], per IEEE-ISTO PWG IPP WG review. 

   - Revised section 1.1, to add printer-charge-info-uri and
   printer-uuid to discussion of URI syntax, per IEEE-ISTO PWG IPP WG
   review. 

   - Revised section 1.2 and section 1.3, to add printer-device-id to
   discussions of equality and substring matching, per IEEE-ISTO PWG IPP
   WG review. 

   - Revised section 3.2, section 4, and section 7.2, to delete
   redundant printer-organization and printer-organizational-unit
   (already covered by 'O' and 'OU'), per IEEE-ISTO PWG IPP WG review. 

   - Revised section 3.2, section 4, and section 7.2, to add missing
   printer-charge-info, per IEEE-ISTO PWG IPP WG review. 

   - Revised section 3.5, section 4, and section 7.2, to rename
   printer-ipp-extensions-supported to printer-ipp-features-supported,
   per IEEE-ISTO PWG IPP WG review. 

   - Revised numerous section 4 subsections, to add references to
   [IANAIPP] or [RFC3805] as appropriate for enumerations and keywords,
   per IEEE-ISTO PWG IPP WG review. 

   - Revised section 4.2, to add 'negotiate' as value for 'auth' and
   references to [PWG5100.JPS3], [RFC4559], and [IANAIPP], per IEEE-ISTO
   PWG IPP WG review. 

   - Revised section 4.2, to use 'example.com' for all DNS names, per
   IEEE-ISTO PWG IPP WG review. 

   - Revised section 4.22 and section 4.23, to add normative reference
   to PWG Media Standardized Names [PWG5101.1], per IEEE-ISTO PWG IPP WG
   review. 

   - Revised section 4.24, to divide notes into two separate paragraphs,
   per IEEE-ISTO PWG IPP WG review. 

   - Revised section 4.31, section 4.32, and section 4.33, to change
   'Values ...  include' to 'Values ...  are' (i.e., closed set), per
   IEEE-ISTO PWG IPP WG review. 

   - Revised section 4.35 printer-device-id, to add warning about
   ordering of required key/value pairs (first) and truncation only at
   key/value pair boundaries for interoperability, per IEEE-ISTO PWG IPP
   WG review. 

   - Revised section 4, to add printer-charge-info from [PWG5100.JPS3],
   per IEEE-ISTO PWG IPP WG review. 

   - Revised section 4.38 printer-geo-location, to change 'should' to
   'must' for conformance to [RFC5870], per IEEE-ISTO PWG IPP WG review.

   - Revised section 4.39, to change printer-ipp-extensions-supported to
   printer-ipp-features-supported per [PWG5100.JPS3] and add examples,
   per IEEE-ISTO PWG IPP WG review. 

   - Revised section 4 subsection printer-uuid, to change 'should' to
   'must' for conformance to [RFC4122], per IEEE-ISTO PWG IPP WG review.

   - Revised section 10 References, to update out-of-date references. 


--
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
Permalink | Reply | 0 comments |
headers
Michael Sweet | 6 Apr 2012 17:17
Picon
Favicon

Prototype experience for JPS3

All,

This is Apple's notice of prototyping of the current draft of the IPP Job and Printer Extensions - Set 3 (JPS3) specification as posted here:


Apple has prototyped all of the proposed extensions and has shipped many of them since CUPS 1.4. The only implementation issue not directly addressed by the current JPS3 specification is how printers and clients interpret colorant values ("colorantname") in the printer-supply attribute. This issue was identified during the original discussions for printer-supply (vs. the CUPS marker-xxx implementation) and can be addressed by referencing PWG 5101.1 (MSN1) for colorantname values, including the proposed additions from the current MSN2 draft, and finishing the update of 5101.1 (MSN2) to support a full set of reference color names and vendor colors.

__________________________________________________
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
Permalink | Reply | 0 comments |
headers
Michael Sweet | 6 Apr 2012 17:25
Picon
Favicon

Re: WS-discovery binding for IPP Everywhere

Justin,

Can you provide a schema file that I can put up on the PWG web site?  The namespace should be "http://www.pwg.org/schemas/2012/4/ipp-everywhere" to match the form we use for Semantic Model schema.

Thanks!

On Feb 10, 2012, at 10:20 AM, Justin Hutchings <justhu <at> microsoft.com> wrote:

All,

Per the discussion at this week’s face to face, I mocked up an example of how to do discovery of an IPP endpoint using ws-discovery. Since WS-discovery doesn’t especially care what matching semantic model is used, I would propose that we just reuse the LDAP model to simplify the development experience for people. The only unique descriptions we’ll need are to establish some keywords that describe the different IPP protocols, like IPP Everywhere print, scan, fax, etc. That should be pretty trivial, as we just need to name them and publish a schema.

 

How does this look?

 

Thanks!

Justin

 

Example probe message:

<s:Envelope

   <s:Header>

     <a:Action>

     </a:Action>

     <a:MessageID>

       uuid:0a6dc791-2be6-4991-9af1-454778a1917a

     </a:MessageID>

     <a:To>urn:schemas-xmlsoap-org:ws:2005:04:discovery</a:To>

   </s:Header>

   <s:Body>   

     <d:Probe>

       <d:Types>ippe:Print</d:Types>

       <d:Scopes

       </d:Scopes>

     </d:Probe>

   </s:Body>

 </s:Envelope>

 

 

 

 

Justin Hutchings | Program Manager | Windows\DNT\DeviceConnectivity::Printing and Imaging

 


-- 
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, 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
Permalink | Reply | 1 comment |
headers
Petrie, Glen | 6 Apr 2012 17:34

Where is the Cloud Print Manager in the PWG: Cloud Model

Ira, Pete,

 

I believe it was stated in the last conference call that the Cloud Print Manager in the cloud model diagram “is not in the cloud”.   Is this true?  If so, where is it “located”? 

 

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
Permalink | Reply | 10 comments |
headers
Michael Sweet | 6 Apr 2012 18:00
Picon
Favicon

Re: Where is the Cloud Print Manager in the PWG: Cloud Model

[Adding cloud <at> pwg.org since this is a cloud discussion]

Glen,

In the original BOF-generated functional model, the Cloud Print Manager is either located in the Printer or attached to the Printer (e.g. in the local print server).  The Cloud Print Manager manages communications between the lower-level printer interface and the Cloud Print Provider.

Based on our last telecon, we have introduced a Cloud Print Service into the model which is the service in/under the Cloud Print Provider (which acts as a System Control Service in the Semantic Model sense) that manages the jobs/queue in the cloud for the Cloud Print Manager.  The rough ASCII art diagram in my mind looks like this:


                   Cloud Print Provider
    Client  <--->  Cloud Print Service  <--->  Cloud Print Manager <---> Printer(s)

Thus, Clients and Cloud Print Managers talk directly to the Cloud Print Provider and corresponding Cloud Print Service, but never directly to each other, and only the Cloud Print Manager actually talks directly with the Printer(s) (physical or logical) it is registering/sharing with the Cloud Print Provider/Service.

There can potentially be multiple logical or physical printers behind the Cloud Print Manager (think traditional fan-out configurations and reprographic services) and those printers *may* be addressable using the IPP/SM output device attributes/elements, but there is only a single Cloud Print Service per Cloud Print Manager and to the Client it will appear to be a single "queue" with one or more output devices associated with it.


On Apr 6, 2012, at 8:34 AM, "Petrie, Glen" <glen.petrie <at> eitc.epson.com> wrote:

Ira, Pete,

 

I believe it was stated in the last conference call that the Cloud Print Manager in the cloud model diagram “is not in the cloud”.   Is this true?  If so, where is it “located”? 

 

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, 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
Permalink | Reply | 9 comments |

Gmane