---------- Forwarded message ----------
From: Graham Triggs <grahamtri...@gmail.com>
Date: 11 January 2011 04:40
Subject: Re: content negotiating for package formats
To: Richard Jones <rich...@oneoverzero.com>
Cc: techadvisorypa...@swordapp.org


On 7 January 2011 17:36, Richard Jones <rich...@oneoverzero.com> wrote:
>
> 1/ Use the Accept-Encoding header in some way.  Does anyone have any 
> experience with this header and could tell us whether this seems like a 
> reasonable usage of it?
>
> 2/ Define an extension to the application/zip mimetype which allows us to 
> specify the package format as a parameter. So we could, for example, specify 
> a parameter "swordpackage" which can take the URI of a package format, and 
> construct mimetypes like
>
> application/zip;swordpackage=uri:METSDSpaceSIP
>
> (see http://tools.ietf.org/html/draft-ietf-atompub-typeparam-00)
>
> The questions here are: is this a legitimate extension/approach, would this 
> break anything else on the web in general, and is it naive to assume that all 
> packages have the top level mimetype of application/zip?
>
>

More generally, the HTTP specification defines the accept headers as:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Which means using Accept-Encoding in this way is potentially
problematic, but Accept does have provision that would make this use
legitimate. Whether that breaks things is going to depend on how
closely they follow the standards.
I think there is a more interesting practical question - for any given
media type (ie. application/zip), there may be multiple packaging
formats (METSDSpaceSIP, etc.). How would you plan on encoding those
that are applicable:
application/zip;format=METSDSpaceSIP, applization/zip;format=OtherSIP
or
application/zip;format="METSDSpaceSIP,OtherSIP"
On the possibility of having multiple formats, the additional header
seems worthwhile. Then again, what if you have multiple media types in
your and the formats that you accept don't apply to all of them? That
might not sound like a problem to begin with, but imagine the case of
a client implemented now to say:
Accept-Encoding: application/atom+xml, application/zip
X-packaging: AtomSIP
X-packaging: METSDspaceSIP
At the time the client is written, then the only implementations of a
service only respond to Atom as AtomSIP and Zip as METSDspaceSIP. What
happens when the server gets upgraded, and there is a way of providing
METSDspaceSIP as atom (or AtomSIP in a zip)? There is no way the
server can determine which packaging formats are valid for which media
types - and may well respond with something the (older) client doesn't
understand.
G

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

Reply via email to