---------- Forwarded message ---------- From: Richard Jones <rich...@oneoverzero.com> Date: 20 January 2011 02:30 Subject: Re: Key Changes and Justifications To: rsander...@lanl.gov Cc: techadvisorypa...@swordapp.org
Hi Folks, > * Content Negotiating for Package Formats > > RFC2533 seems massive overkill, and very different from HTTP content > negotiation. > > Could you set out the requirements that cannot be fulfilled by accept > headers? My understanding is that the packaging format and the wrapped > media format should be separately negotiable, but that can be handled with > just a single new Accept- header that handles the wrapped data's format. > [As the packaging is the outermost layer, it goes into Accept] > > If RFC2533 is the way you decide to go, then you should follow RFC2295 > Section 6, which discusses a Accept-Features. Note in RFC 2616 (HTTP) > defined after 2533/2295, it doesn't mention Accept-Features. However, > 2295 defines a different syntax than 2533, and 2533 doesn't appear to > officially update 2295. Transparent Content Negotiation from 2295 is very > poorly implemented, and 2533 doesn't appear to be implemented at all. > > Basically, ... don't do it. Whatever the problem is, 2295 + 2533 is not > the solution. Regarding this, perhaps the easiest thing to do is share my first stab at an internet draft for the various HTTP headers that look relevant to SWORD 2.0. http://sword-app.svn.sourceforge.net/viewvc/sword-app/spec/trunk/PackagedContentDelivery.txt?revision=226&view=markup Feel free to mock my first attempt at writing anything of this nature - I've hacked it together from a variety of example sources, and hope that it's the right sort of thing, but any hints as to how to make it better would be great. The main point, though, is that it describes briefly the Accept-Media-Formats header with its constrained contents, which will hopefully clarify what we're trying to achieve. I originally discarded Accept-Features, because the definition of it seemed to concern the features of the request, rather than any content negotiation (in Section 8.2 of RFC2295): "The Accept-Features request header can be used by a user agent to give information about the presence or absence of certain features in the feature set of the current request." Must be I'm reading that wrong. The more we discuss it the more I'm leaning towards a lazy approach of having a separate Accept-Packaging header, and some clearly stated rules as to the way in which servers should interpret the combination of Accept and Accept-Packaging. This issue must arise in other types of content negotiation, for example with Accept-Language where not all content-types are available in all languages, so perhaps there are some resources on that that we can learn from. Cheers, Richard ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Sword-app-techadvisorypanel mailing list Sword-app-techadvisorypanel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sword-app-techadvisorypanel
