[IPP] Thoughts on static resource uploads

[IPP] Thoughts on static resource uploads

Ira McDonald blueroofmusic at gmail.com
Wed Nov 5 19:22:51 UTC 2014


Hi,

I agree with Mike's suggested SM Service / IPP Printer resource
storage elements/attributes and the auto-mapping of the HTTP
PUT (by the MFP to the Resource object attributes (also, certainly
we should add the Static type of MessageCatalog).

Smith - the thing about the access control is the MFD *itself*
(or it's IPP Proxy) is the only one that can store resources in
the Infrastructure/Cloud Printer.  The ordinary end user at the
IPP Client can only read the data (e.g., icon) according to the
type (e.g., you can't read a font, just it's metadata) but can that
ordinary end use can *never* modify or delete any of the resource
metadata or data.

And see Mike's note about the HTTP access for the MFD while
I was writing 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 5, 2014 at 1:30 PM, Kennedy, Smith (Wireless Architect) <
smith.kennedy at hp.com> wrote:

> Hi Mike,
>
> Would consideration at this level for access control / permissions be
> needed?
>
> Smith
>
>
>
> > On 2014-11-04, at 8:57 PM, Michael Sweet <msweet at apple.com> wrote:
> >
> > All,
> >
> > OK, so based on the discussions in today's joint IPP/Cloud sessions I'd
> like to propose the following new Semantic Model ServiceDescription
> elements (IPP Printer Description attributes in parenthesis):
> >
> >  - ServiceStaticResourceDirectoryUri
> ("printer-static-resource-directory-uri (uri)") - directory URI for HTTP
> PUT requests (to create resources) and HTTP DELETE requests (to cancel
> resources)
> >
> >  - ServiceStaticResourceKOctetsReady
> ("printer-static-resource-k-octets-ready (integer(0:MAX))") - Available
> storage capacity in K octets (1024 octets).
> >
> >  - ServiceStaticResourceKOctetsSupported
> ("printer-static-resource-k-octets-supported (integer(0:MAX))") - Maximum
> storage capacity in K octets (1024 octets).
> >
> > Resources are created using HTTP PUT requests and canceled using HTTP
> DELETE requests.  Doing a PUT to
> "ServiceStaticResourceDirectoryUri/filename.ext" does the equivalent of the
> CreateResource (formerly DeleteResource) operation with the following
> elements:
> >
> >  ResourceCategory=Static
> >  ResourceCreatorUserName=<HTTP authenticated user name>
> >  ResourceName=<path component of URI without leading slash>
> >  ResourceType=<mapped from Content-Type - Image, ICCProfile, or
> *MessageCatalog*>
> >  ResourceFormat=<Content-Type value>
> >  *ResourceUri*=<URI of PUT>
> >
> >  (*foo* is a new value or element)
> >
> > If the PUT request includes the conditional request header
> If-Unmodified-Since, then the service does an atomic combination of a
> CancelResource (formerly DeleteResource) followed by a CreateResource if
> the destination resource is older than the specified date.
> >
> > Doing a DELETE to "ServiceStaticResourceDirectoryUri/filename.ext" does
> the equivalent of the CancelResource operation for the matching ResourceUri.
> >
> > Thoughts?
> >
> > _________________________________________________________
> > Michael Sweet, Senior Printing System Engineer, PWG Chair
> >
> > _______________________________________________
> > ipp mailing list
> > ipp at pwg.org
> > https://www.pwg.org/mailman/listinfo/ipp
>
>
> _______________________________________________
> ipp mailing list
> ipp at pwg.org
> https://www.pwg.org/mailman/listinfo/ipp
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20141105/1ddb96c0/attachment.html>


More information about the ipp mailing list