Re: [search-ws] ResponseType parm and Accept header are equivalent (and some implications of that)

["Ray Denenberg, Library of Congress" <rden@loc.gov>]

Thanks Andy and Jeff; I'm sure nobody was offended. I think we're just 
trying to figure out whether it's a good idea to distinguish a class of SRU 
parameters in the manner suggested, and my initial thought is that it is a 
good idea.  We need to kick it around a bit.

--Ray

----- Original Message ----- 
From: "Houghton,Andrew" <houghtoa@oclc.org>
To: "Young,Jeff (OR)" <jyoung@oclc.org>; "LeVan,Ralph" <levan@oclc.org>; 
"Ray Denenberg, Library of Congress" <rden@loc.gov>; 
<search-ws@lists.oasis-open.org>
Sent: Thursday, January 22, 2009 12:12 PM
Subject: RE: [search-ws] ResponseType parm and Accept header are equivalent 
(and some implications of that)


Jeff got the intent of my message exactly correct.  I apologize about the 
wording of my message I should probably not been so terse and I didn't mean 
to offend or upset anybody.

Andy.

> -----Original Message-----
> From: Young,Jeff (OR)
> Sent: Thursday, January 22, 2009 12:08 PM
> To: LeVan,Ralph; Houghton,Andrew; 'Ray Denenberg, Library of Congress';
> 'search-ws@lists.oasis-open.org'
> Subject: RE: [search-ws] ResponseType parm and Accept header are
> equivalent (and some implications of that)
>
> I could be wrong, but I assume that Andy is suggesting that the '$'
> indicates information that normally would be obtained from HTTP
> headers. The labels, then should presumably match those headers. Even
> though this is a novel idea, it is easily and usefully generalized
> beyond SRU.
>
> Jeff
>
> > -----Original Message-----
> > From: LeVan,Ralph
> > Sent: Thursday, January 22, 2009 11:43 AM
> > To: Houghton,Andrew; 'Ray Denenberg, Library of Congress'; 'search-
> > ws@lists.oasis-open.org'
> > Cc: Young,Jeff (OR)
> > Subject: RE: [search-ws] ResponseType parm and Accept header are
> > equivalent (and some implications of that)
> >
> > I would never have guessed that ‘$’ was a legal character in a URL.
> I
> > have no problem with that suggestion, but take some exception to the
> > phrase “distinguishes them from SRU specific query parameters”.
> These are
> > definitely SRU specific parameters.  They are not parameters commonly
> > accepted in other URLs.  Nor are they parameters specific to SRU
> queries.
> >
> >
> >
> > But, $accept does help reflect the more global implication of the
> parm.
> >
> >
> >
> > Ralph
> >
> >
> >
> > From: Houghton,Andrew
> > Sent: Thursday, January 22, 2009 11:36 AM
> > To: Ray Denenberg, Library of Congress; LeVan,Ralph; search-
> > ws@lists.oasis-open.org
> > Cc: Young,Jeff (OR)
> > Subject: RE: [search-ws] ResponseType parm and Accept header are
> > equivalent (and some implications of that)
> >
> >
> >
> > My only suggestion here would be consider prefixing these types of
> content
> > negotiation query parameter with something that distinguishes them
> from
> > SRU specific query parameters.  For example use $accept, $accept-
> charset,
> > $accept-language, $accept-encoding, etc.  There are also additional
> > implications in regard to HTTP status codes and responses.  If
> someone
> > adds $accept=application/rss+xml to the SRU query parameters and the
> SRU
> > server only supports Atom, application/atom+xml, then the SRU server
> > should respond with HTTP 406 Not Acceptable.
> >
> >
> >
> > Andy.
> >
> >
> >
> > From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
> > Sent: Thursday, January 22, 2009 11:00 AM
> > To: LeVan,Ralph; search-ws@lists.oasis-open.org
> > Cc: Young,Jeff (OR); Houghton,Andrew
> > Subject: Re: [search-ws] ResponseType parm and Accept header are
> > equivalent (and some implications of that)
> >
> >
> >
> > I finally got around to this as well as the earlier message, sorry
> for the
> > delay.
> >
> >
> >
> >  I agree with Ralph (to the extent that I understand it).
> >
> >
> >
> > Thanks Ralph.
> >
> >
> >
> > --Ray
> >
> > ----- Original Message -----
> >
> > From: LeVan,Ralph <mailto:levan@oclc.org>
> >
> > To: search-ws@lists.oasis-open.org
> >
> > Cc: Young,Jeff (OR) <mailto:jyoung@oclc.org>  ; Houghton,Andrew
> > <mailto:houghtoa@oclc.org>
> >
> > Sent: Monday, January 19, 2009 2:59 PM
> >
> > Subject: [search-ws] ResponseType parm and Accept header are
> > equivalent (and some implications of that)
> >
> >
> >
> > I claim that our new responseType parameter is equivalent to an
> HTTP
> > Accept header.  The purpose of the parameter is to allow the client
> to be
> > able to specify the mime type of the response.  (As a provocative
> aside, I
> > further claim that current SRU servers could deliver non-SRU
> responses to
> > SRU requests today on the basis of Accept headers.  All we’re doing
> in our
> > standards work is agreeing on how to express that Accept header in
> our
> > URLs.)
> >
> >
> >
> > I propose that we change the name of the responseType parameter
> to
> > “accept”.  There is no reason for us to invent a new name for
> something
> > that has well-understood semantics.  (My co-workers suspect that
> there are
> > other HTTP headers that we may also want to represent in our URLs,
> but
> > we’ll leave them for the day when we have a real use case.)
> >
> >
> >
> > I’ve been discussing this topic with some of my co-workers and
> there
> > are some implications of this recognition that our parameter is an
> > alternative to an Accept header.
> >
> >
> >
> > I believe our current documentation says that the mime-type of an
> > SRU response is text/xml.  We need to change that to application/x-
> sru+xml
> > and need to start the process of registering our mime-type with IANA
> so we
> > can get rid of the x- part.
> >
> >
> >
> > If an SRU server supports multiple mime types and uses content
> > negotiation to determine the mime-type of the response, then the
> server
> > should proved a URL in the Content-Location header of the response
> > pointing directly to the response in that mime-type.  For instance,
> if the
> > client had sent the URL http://example.org/sru?query=dog with an
> Accept
> > header of “application/rss+xml”, then the server should return a
> Content-
> > Location value of
> > http://example.org/sru?query=dog&accept=application/rss+xml.  This
> > Content-Header is returned along with the content itself, presumably
> in
> > the application/rss+xml format.  It would also be acceptable to have
> > returned a redirect to that URL instead, but that behavior is not
> > encouraged as it is inefficient.
> >
> >
> >
> > Even in the absence of an Accept header, this behavior becomes
> > important.  If there was no Accept header or an Accept header of “*”
> and a
> > URL of http://example.org/sru?query=dog,  our standard says that the
> > response should be of the mime-type application/x-sru+xml.  That
> means
> > that there was, in fact, content negotiation going on and a Content-
> > Location header of
> http://example.org/sru?query=dog&accept=application/x-
> > sru+xml should be returned with the response.
> >
> >
> >
> > I believe that this behavior needs to be documented as part of
> the
> > change to accept the accept parameter.
> >
> >
> >
> > Ralph