> 3) In my opinion, the specification contains a number of methods
> and features which are currently not sufficiently clearly defined.
> I would guess that few, if any, have been implemented, and would
> further guess that at least a few are of dubious utility (after
> all, if they were truly needed, someone would be implemented them - look
> how quickly ISMAP spread.)
I think it's a good idea to have the future mapped out so people don't
invent square wheels when someone has already figured out how to make
round ones. If you remove them then people will implement alternative
solutions that don't fit the model. This is already a problem as
it stands.
Of course, the official RFC is a different story. For that I agree with you.
> Don't get me wrong - I am eager to see some of these become part
> of the spec, particularly the authorization stuff.
There are already implementations of the authorization stuff.
> Re: ACCEPT 1.7.2 Is the order of content types significant? I
> hope so.
No, the ranking is done with the `q' attribute.
> Re: Accept-Language 1.7.4 Why not use the encoding used in Language
> (2.4.12)? Also, there must be a way to specify the "q" factor for
> a language, just as for Accept. Finally, there must be a specification
> of how the q from Content Type and the q from Language interact.
> (Multiplied?)
This is why I voted that Accept-language was the wrong approach. It
should be an attribute associated with the Accept content-type like all
the other client-profile information is.
--sanders