Subject: [IPP] Updated stable draft of IPP Shared Infrastructure Extensions (INFRA) posted

From: Michael Sweet <[email-masked]>
Date: Tue, 18 Nov 2014 16:11:35 -0500

All,

I have posted an updated stable draft of the IPP Shared Infrastructure Extensions (INFRA) to:

	http://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippinfra10-20141118.docx
	http://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippinfra10-20141118.pdf
	http://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippinfra10-20141118-rev.pdf

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: "William A Wagner" <[email-masked]>
Date: Wed, 19 Nov 2014 14:20:14 -0500

In including Cloud storage of Local Imaging System resources, It was unclear
to me why we are restricting this to Static Resources. I can see where
executable resources may be problematical, but might not Template category
types be usable?
Thanks,
Bill Wagner 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael
Sweet
Sent: Tuesday, November 18, 2014 4:12 PM
To: <[email-masked]>
Subject: [IPP] Updated stable draft of IPP Shared Infrastructure Extensions
(INFRA) posted

All,

I have posted an updated stable draft of the IPP Shared Infrastructure
Extensions (INFRA) to:

---

From: Michael Sweet <[email-masked]>
Date: Wed, 19 Nov 2014 15:44:15 -0500

Bill,

> On Nov 19, 2014, at 2:20 PM, William A Wagner <[email-masked]> wrote:
> 

Perhaps, however since we've never defined what any of these templates look like (format, etc.) or how to use them with the various services, I don't think we are in a place to define that now.

(but it would be interesting if we can come up with something in the SM 3.0 timeframe...)

---

From: "William A Wagner" <[email-masked]>
Date: Wed, 19 Nov 2014 16:05:06 -0500

OK. I thought I understood the Resource addition, but things are getting
foggy. Please correct or answer as appropriate

1. The Infrastructure printer (Cloud System) can provide a directory for the
Proxy to store the static resources in each registered output device (Local
Imaging System).
2. The infrastructure printer provides the URI, total capacity and free
capacity for this storage capability on output device registration. 
3. The proxy can store static resources, create new ones etc in this
directory on behalf of the output device (local Imaging System.

a. What is the purpose? 
	Is it just to provide more storage for the Proxy/Local system to
manage resources?
	Is it for the Infrastructure printer (Cloud Imaging System) to have
access to these resources?
	Is it for other Imaging systems to have access to the resources?

b. Is this directory written to just by the proxy? If so, 
	Why should the Infrastructure printer provide Kbytes free value?
Does it even know?
	Shouldn't the proxy indicate how much (if any) resource storage is
desired when registering the output device (local system)
	If this is just more storage, why do we restrict what category of
resources are stored?

c. Is the contents of the directory used by anything other than the Proxy
(on behalf of the output device)? If so,
	Shouldn't there be an index of what is in the directory?
	What controls what has access to the contents and for what purpose?
Thanks,
Bill Wagner

-----Original Message-----

All,

---

From: Michael Sweet <[email-masked]>
Date: Wed, 19 Nov 2014 16:51:43 -0500

Bill,

> On Nov 19, 2014, at 4:05 PM, William A Wagner <[email-masked]> wrote:
> 

No.

> access to these resources?

Yes.

> 	Is it for other Imaging systems to have access to the resources?

Perhaps, but the key is to be able to share/mirror the resources to the Infrastructure Printer, so that both the Infrastructure Printer and Clients have access to them.

> 	Why should the Infrastructure printer provide Kbytes free value?

The Infrastructure Printer is providing the storage, so it knows how much storage space is still available.

> desired when registering the output device (local system)

That might be a useful addition to the RegisterSystem operation (StaticResourceKOctetsRequested?) but probably isn't something we can add to IPP INFRA since we don't have a RegisterSystem equivalent.

> 	If this is just more storage, why do we restrict what category of

Because we don't need to upload firmware/executables from the Proxy to the Infrastructure Printer, and the template category is still undefined.

> 	Shouldn't there be an index of what is in the directory?

For IPP INFRA, you look at the printer-icc-profiles, printer-icons, and printer-strings-uri attributes.  (and conceptually the WebDAV PROPFIND method to list the full contents of the directory...)

> 	What controls what has access to the contents and for what purpose?

As specified in the current spec, PUT and DELETE requests need to be authenticated as the proxy user (same auth requirements as the Proxy operations). As for the contents and purpose, there is no explicit set of restrictions beyond the filename and storage limits.