[occi-wg] Fwd: New Version Notification - draft-dusseault-http-patch-15.txt
Gary Mazz
garymazzaferro at gmail.com
Mon Oct 19 01:40:18 CDT 2009
Sam Johnston wrote:
> Gary,
>
> As you well know I'm all about transparency so if you're going to talk
> about things that should be on the list then expect them to end up
> there (deidentified if need be, as was the case this time at least
> until you claimed ownership). I don't mind if people contacting us
> privately to conceal their identity for whatever reason (there are a
> number of vendors doing this and/or working through intermediaries)
> but private threads about fundamental design decisions are not on.
>
> Working through your mail:
> - what RESTful principles are we diverting from exactly?
I went back to Fielding's original document . Here in chapter 5
/5.2.1.2 Representations/
/REST components perform actions on a resource by using a
representation to capture the current or intended state of
that resource and transferring that representation between
components. *" A representation is a sequence of bytes, plus
representation metadata to describe those bytes." * Other
commonly used but less precise names for a representation
include: document, file, and HTTP message entity, instance,
or variant./
/A representation consists of data, metadata describing the
data, and, on occasion, metadata to describe the metadata
(usually for the purpose of verifying message integrity).
Metadata is in the form of name-value pairs, where the name
corresponds to a standard that defines the value's structure
and semantics. Response messages may include both
representation metadata and resource metadata: information
about the resource that is not specific to the supplied
representation./
In this chapter Fielding specifically calls out that all ReST
represented data must has a key value pair and must be in an document,
file, HTTP message entity , instance, or variant. I can completely
understand this position, it places data in a position available to web
cache logic.
Moving the OCCI key value pairs into HTTP headers does not align with
the Fielding requirement.
> - what "portions" of REST should be applied? pursuing a goal of being
> RESTful only to deliberately reject certain tenets doesn't really make
> sense - you are or you're not.
I'm not saying deliberately reject any of it, I challenge its
applicability to the use models. For example, "code-on-demand " is a
ReST feature, albeit optional, we are not implementing that feature
today. Maybe there will be a requirement for it in the future, but today
we are deliberately not supporting it. Does it really make sense to
include it ? Which of the "certain tenets"
> - data _is_ cacheable, just not by untrusted intermediaries as it's
> encrypted with SSL. what would you have us do - disable encryption for
> cacheability? how do you figure this is this "in opposition to some of
> those principles"?
We to comply with Fielding paper on cache see below
/5.1.4 Cache
In order to improve network efficiency, we add cache constraints to
form the client-cache-stateless-server style of Section 3.4.4
(Figure 5-4). Cache constraints require that the data within a
response to a request be implicitly or explicitly labeled as
cacheable or non-cacheable. If a response is cacheable, then a
client cache is given the right to reuse that response data for
later, equivalent requests.
/
We currently do not specify any cache constraints for OCCI response
data. Since most providers are using the public internet, secure OCCI
APIs are required. Public web caches will not cache SSL or vpn HTTP
response data. This needs to be implemented, addressed and disclosed in
either the specification or though adjunct documentation. Not complying
with 5.1.4 is in conflict with ReST criteria.
> - we do need to represent actions and are doing a pretty good job of
> avoiding creating an RPC-style interface. how do you figure this is
> this "in opposition to some of those principles"?
I believe that statement to be true, until recently.
> - how do you figure HTTP verbs which effectively perform a series of
> RESTful actions are not themselves RESTful?
The only verbs I've found commonly agreed to represent ReST are CRUD
operations. Additional actions, without the support of the "ReST"
community via consensus should not be considered ReST complaint. It
would be similar to a third party cloud working group adopting OCCI,
adding new verbs and calling these new verbs OCCI compliant. Those new
verbs would only be compliant after the OCCI-wg approves them. The same
is true for ReST. That also is the reason for my suggestion to reexamine
ReST and maybe call for a ReSTMgt supporting new verbs for OCCI and
other management actions.
> - the "definition of REST as it applies to OCCI" is here:
> http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
> <http://www.ics.uci.edu/%7Efielding/pubs/dissertation/top.htm>
This is the doc I'm looking at...
> - your opinion on ReST for management applications is exactly that -
> an opinion... it's lacking any justification so if you have a better
> alternative then present it and explain clearly why it's technically
> superior so as we can assess it on its merits
My justifications are above.
> - I said this was not a forum for religious debates about
> $methodology, nothing more
>
> Finally, being as close as possible to HTTP as the "universal
> interface" means we're already compatible with most systems and, more
> importantly, developers feel at home with OCCI without needing to
> retool. I've (fortunately) not heard anyone seriously suggesting that
> we should target binary RPCs, SOAP, CORBA or SNMPv2 thus far and I
> would say that to do so would be a fairly significant deviation from
> what we're trying to achieve.
No one is calling for a retool, like the one that occurred a week before
OGF 27. Now, that you pressed the issue, I'll be calling for a reexam
and review for parity to mission and goals with better definition of
ReST requirements with respect to the project and close out all these
loose ends.. Asking for a review, better requirements and statement of
execution, for ReST, is not asking to rewrite the interface...
AS for HTTP being a "universal interface", that is not true for all
industries.
-gary
>
> Sam
>
> On Sun, Oct 18, 2009 at 3:14 PM, Gary Mazz <garymazzaferro at gmail.com
> <mailto:garymazzaferro at gmail.com>> wrote:
>
> Sam,
>
> I'm not "attacking" the api, I'm pointing out OCCI seems to be a
> diverting from the majority of ReSTful principals as many
> understand them.
>
> Note my first line: "As we move closer to practical working set
> of management actions, it appears we are moving further away from
> ReSTful principals."
>
> This needs examination and OCCI should clarify what portions of
> ReST will be applied and where. I'm finding under current writings
> about ReST, by creating new actions, and making data uncachable
> (by design or otherwise) is in opposition to some of those
> principals. I agree that OCCI optimizations are non-ReSTful, the
> reason for the email. I don't agree these are all performance
> optimizations, most are functions that make using OCCI practical
> and the API more intuitive.
>
> I think we need better definition of ReST as it applies to OCCI.
> And if the resource addressing scheme is the only applicable
> portion, we should qualify that.
>
> As for my opinion on ReST for management applications, I think it
> is "snake oil' and most don't understand the impacts to management
> applications. I've been looking for an analysis of protocol
> strategies pertaining to ReST and small data payloads, can't seem
> to find one. ReST does have its place in the world, but for
> practical management applications that need to operate securely on
> the public internet, IHO, most of ReST is just not a good fit as
> defined. After ten years, it may be time to revisit ReST, we may
> need a ReSTMgt for OCCI like applications.
>
> This is not addressing anything in "religious' context. My
> comments were not directed at any specific contributors, just the
> type of comments pertaining to ReST. Its a social phenomenon where
> questions and challenges to ReST's applicability illicits
> irrationally emotional responses about the subject. Its not even a
> technology, its a set of goals with a "recommended" nondescript
> addressing scheme. Second.... I didn't post my comments on ReST to
> this forum, you did. Don't think its a little odd you post my
> "private" email to a public forum and then say it not the proper
> place for this discussion ?
>
> As for technical merits, I'll be hitting those on multiple levels
> later this week. :-)
> I'm glad you brought up point of RPCs, I'm not an advocate of RPCs
> or state transfer methods. As long as they meet the goals and
> requirements of the project and are implementable. SO what's wrong
> with binary RCPs or SOAP or any other method like CORBA ? Your
> comments seem to indicate you have a strong opinion against using
> these technologies. The reason why there was strong advocacy, on
> my part, to support multiple interface implementations was to
> increase the usefulness of OCCI to cloud communities and create
> opportunities for OCCI adoption. IMO, it would be a good thing of
> someone adapted OCCI to a non-ReST interface like WEBM. That would
> provide direct integration to tools like nagios, tivoli, Openview
> and MS management console maybe increasing OCCI's value to the
> communities. I'd like to see an SNMPV2 version of the interface
> for the holdouts. Supporting multiple non-ReST interfaces is an
> advantage to OCCI, not a drawback!!.
> cheers,
> gary
>
>
> 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 OCCI.
>
> 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>>
> <mailto: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>>
> <mailto: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>>
> <mailto: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>>
> <mailto: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 <mailto:occi-wg at ogf.org>
> http://www.ogf.org/mailman/listinfo/occi-wg
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20091019/80c23885/attachment.html
More information about the occi-wg
mailing list