[occi-wg] Fwd: New Version Notification - draft-dusseault-http-patch-15.txt

Michael Behrens michael.behrens at r2ad.com
Sun Oct 18 15:35:56 CDT 2009

FYI: In looking around for a list of HTTP verbs with specification 
mappings....I found this one (is there a better one?):

Sam Johnston wrote:
> [moving this off-list discussion to the list where it belongs]
> On Sun, Oct 18, 2009 at 12:40 PM, <AC> wrote:
>     As we move closer to practical working set of management actions,
>     it appears we are moving further away from ReSTful principals.
>     Now, we have 4 additional actions HEAD, OPTIONS,  MOVE, and PATCH
>     over the ReST CRUD. We haven't even begun to here from user
>     wanting CHECKPOINT, COPY and CLONE (a live checkpoint copy).
> All of these verbs are useful and none of them are particularly 
> non-RESTful - in fact they're effectively performance optimisations:
>  - HEAD allows one to retrieve metadata without the entire (possibly 
> large) representation
>  - OPTIONS allows you to "look before you leap"
>  - COPY allows a remote client to request a resource be transferred 
> (short for GET followed by PUT, only allows e.g. EDGE connected 
> iPhones to participate)
>  - MOVE is like COPY, only it's short for GET-PUT-DELETE (again 
> avoiding the need to transfer the whole lot via the client)
>  - PATCH is like PUT, only it doesn't require the entire entity to be 
> transferred (rather just the changes in e.g. diff format)
> Without these optimised HTTP verbs it would be literally impossible 
> to, for example, migrate a virtual machine from one cloud to another 
> from a client sitting on a "slow" connection like 3G/EDGE/GPRS, or 
> even ADSL. Note also that they have all been standardised at some 
> point by the IETF, either in HTTP itself or WebDAV.
> Nobody's talking about introducing our own non-standard HTTP verbs for 
>     Using SSL and other secure protocols, we eliminate any possibility
>     to leverage existing document cache infrastructures.
> No, we eliminate the possibility for *untrusted intermediaries* to 
> cache, which is by design.
>     As OCCI continues to mature towards practical design,  many
>     aspects of ReST seems to be incompatible with real world
>     management applications.  Outside of the resource addressing
>     scheme, which is very similar to SNMP and CMIP/CMOT in concept,
>     ReST provides very little to guide the direction of our technical
>     decisions. In fact, the more I think of it, the more it looks like
>     "snake oil". It appears to have a large following of "devotees",
>     drinking that koolaid and blindly chant a ReST mantra. The scary
>     part is, most don't have a clue of impacts or its proper application.
> Attacking an API for being RESTful after it's been written (based on a 
> clear consensus to be RESTful no less) is not what I would call 
> "constructive criticism", especially when framed as a religious debate 
> when it's not. There are plenty of forums for such "discussion" but 
> this isn't one of them - we're assessing all the options on technical 
> merit with a view to reaching a rough consensus and producing running 
> code (even if we're not the ones writing it).
> If you insist on having this discussion then I would suggest focusing 
> on the content rather than the contributors, for example by 
> highlighting specific instances where REST fails to deliver _and_ 
> where RPC would have done a better job. Good luck with that.
> Sam
>     -<AC>
>     Sam Johnston wrote:
>         On Fri, Oct 16, 2009 at 7:32 PM, <AC> wrote:
>            And, how does this impact the implementation of ReSTful
>         principals
>            as called out in the last draft of the occi specification ?
>         It doesn't. It just provides a shortcut for someone who wants
>         to make a minor change (e.g. the number of compute cores) to a
>         large representation (e.g. OVF for an entire cluster).
>         Sam
>            On Fri, Oct 16, 2009 at 4:09 AM, Sam Johnston
>         <samj at samj.net <mailto:samj at samj.net>
>         <mailto:samj at samj.net <mailto:samj at samj.net>>> wrote:
>                Afternoon all,
>                The HTTP PATCH verb is interesting in that it allows you to
>                update a representation without having to transfer the
>         entire
>                thing. It's a space-time tradeoff in that it's a smaller
>                transfer but you then have to generate and apply the patch,
>                but for large/complex representations and remote (e.g.
>         iPhone)
>                users it could provide significant benefit. I wouldn't
>         suggest
>                that it be required at this time given lack of
>         implementation
>                (e.g. Apache) support but I've added a reference to it
>         to OCCI
>                as it will be useful for some applications and I'd rather
>                provide the functionality than have people invent it.
>                It's worth noting that PATCH first made an appearance
>         (along
>                with LINK and UNLINK) in the first HTTP RFCs but wasn't
>                included in more recent releases due to lack of
>         implementations.
>                Sam
>                ---------- Forwarded message ----------
>                From: *Mark Nottingham* <mnot at mnot.net
>         <mailto:mnot at mnot.net> <mailto:mnot at mnot.net
>         <mailto:mnot at mnot.net>>>
>                Date: Fri, Oct 16, 2009 at 1:48 AM
>                Subject: Fwd: New Version Notification -
>                draft-dusseault-http-patch-15.txt
>                To: HTTP Working Group <ietf-http-wg at w3.org
>         <mailto:ietf-http-wg at w3.org>
>         <mailto:ietf-http-wg at w3.org <mailto:ietf-http-wg at w3.org>>>
>                    New version (-15) has been submitted for
>                    draft-dusseault-http-patch-15.txt.
>         http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-15.txt
>                    Sub state has been changed to AD Follow up from New
>         Id Needed
>                    Diff from previous version:
>         http://tools.ietf.org/rfcdiff?url2=draft-dusseault-http-patch-15
>                    IETF Secretariat.
>                --
>                Mark Nottingham http://www.mnot.net/
>                _______________________________________________
>                occi-wg mailing list
>         occi-wg at ogf.org <mailto:occi-wg at ogf.org>
>         <mailto:occi-wg at ogf.org <mailto:occi-wg at ogf.org>>
>         http://www.ogf.org/mailman/listinfo/occi-wg
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg

Michael Behrens
(571) 594-3008 (cell)
(703) 714-0442 (land)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20091018/21657e61/attachment.html 

More information about the occi-wg mailing list