[Cloud] [IPP] Thoughts on static resource uploads

[Cloud] [IPP] Thoughts on static resource uploads

Michael Sweet msweet at apple.com
Wed Nov 5 19:15:31 UTC 2014


Smith,

> On 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?

The way I'm wording it for IPP INFRA is to require AAA (or IAA if you adopt the IDS acronym) to be the same for both IPP and HTTP/HTTPS:

Infrastructure Printers that provide storage and hosting of static resources MUST support the HTTP DELETE, GET, and PUT request methods [RFC7230] for the given URI prefix, MUST support the HTTP "If-Unmodified-Since" header [RFC7232], and MUST authenticate DELETE and PUT requests using the same scheme and authority/realm as the IPP URI. That is, if the Infrastructure Printer uses HTTP Basic authentication for the "Example" realm, any DELETE or PUT requests to the "printer-static-resource-directory-uri" URI MUST also use HTTP Basic authentication for the "Example" realm.

I'm not sure if we can make the same normative requirements in the abstract Semantic Model...


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

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20141105/e9f10842/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4798 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/cloud/attachments/20141105/e9f10842/attachment.p7s>


More information about the cloud mailing list