Hi Pete,
Can you clarify this point, please?
Cheers,
- Ira
On Mon, Nov 24, 2014 at 7:22 PM, Ira McDonald <blueroofmusic at gmail.com>
wrote:
> Hi,
>> My original understanding was the the Template category was specifically
> for Job Template storage (i.e., unbound Job Tickets).
>> Pete - can you comment on this?
>> 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 Wed, Nov 19, 2014 at 4:51 PM, Michael Sweet <msweet at apple.com> wrote:
>>> Bill,
>>>> > On Nov 19, 2014, at 4:05 PM, William A Wagner <wamwagner at comcast.net>
>> wrote:
>> >
>> > 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?
>>>> No.
>>>> > Is it for the Infrastructure printer (Cloud Imaging System) to
>> have
>> > 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.
>>>> > 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?
>>>> The Infrastructure Printer is providing the storage, so it knows how much
>> storage space is still available.
>>>> > Shouldn't the proxy indicate how much (if any) resource storage is
>> > 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
>> > resources are stored?
>>>> Because we don't need to upload firmware/executables from the Proxy to
>> the Infrastructure Printer, and the template category is still undefined.
>>>> > 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?
>>>> 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.
>>>> _________________________________________________________
>> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>>> _______________________________________________
>> cloud mailing list
>>cloud at pwg.org>>https://www.pwg.org/mailman/listinfo/cloud>>>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20141210/af364bbb/attachment.html>