Re: [Ltru] Issue 181, was: Issue 113 (language tag matching (Accept-Language) vs RFC4647), was: Proposed resolution for Issue 13 (language tags)

["Phillips, Addison" <[e-mail]>]

> 
> Phillips, Addison scripsit:
> 
> > I tend to think that HTTP's requirements are most like what the
> > Lookup algorithm provides. That is, you can (and must) return
> > exactly one result for a given request.
> 
> Actually, no; that's an oversimplification of HTTP.  

Well... what I was trying to say was "HTTP is most commonly used in a way that I think works better with Lookup". That is, most typically, HTTP is used to return a single resource at the end of a URI. I'm well aware that there are other cases, including the 300 case, which is why I went on to say the rest of what I said :-). 

This is also why I didn't suggest that we merely replace filtering with lookup. I do think that the most common use of HTTP involves returning a single information object for a single request and, in the case where language negotiation is done at all, these typically fit Lookup more closely than Basic Filtering. A significant subset fit Basic Filtering better. And a different significant subset happen to use Basic Filtering (even if Lookup would have been a better choice) simply because 2616 said to.

> 
> The question is, then, what to do if there is no resource that
> specifies
> those minimum requirements.  Apache in this case applies the lookup
> algorithm
> to loosen the client requirement in hopes of finding something
> usable.
> 

Yes, and this is neither "Basic Filtering" nor "Lookup". Similarly, implementations sometimes make use of outside information (Mark Davis's example of Breton falling back to French, for example). And so forth. The problem, as I see it, is that over-specificity in HTTPbis might lead implementers astray and we really need a more comprehensive treatment of language negotiation so that folks can choose wisely.

Addison