- From: Florent Georges <fgeorges@fgeorges.org>
- Date: Thu, 17 Dec 2009 22:46:10 +0100
- To: Norman Walsh <ndw@nwalsh.com>
- Cc: public-xml-processing-model-comments@w3.org
2009/12/17 Norman Walsh wrote: Hi, >> Furthermore, it is not said that the value of auth-method is >> case-insensitive (which I guess is the intention). > As far as I can tell, the values specified by RFC2617 *are* > case-sensitive. I think 1.2 says the opposite ("It uses an extensible, case- insensitive token to identify the authentication scheme") but I might be wrong. But actually, regardless of what is said in the RFC, I think the enumeration values in XProc are all lower-case, so it would be more consistent to have the same here (even if "digest" is defined in XProc to be "Digest" in HTTP). >> Last but not least, shouldn't we reserve the method "token" >> for the standardization-in-progress "HTTP Authentication: >> Token Access Authentication", the IETF standardization of the >> popular (and couting) OAuth method: >> http://xml.coverpages.org/draft-hammer-http-token-auth-00.txt > Not before that spec is finished. Not sure my comment was clear. I do not suggest to do anything explicit regarding this draft. But add something like "the auth method 'token' is reserved for potential future usage by this REC". If not, I bet some implementations will use it as an implementation-defined method (while other implementations will use the other consistent words for the same spec). Another solution would be to define the value of the auth-method to be a QName, and forbidding implementation-defined methods to be in no namespace. (for now, this attribute is defined to be a string, so the auth-method "ff .__+=1 1.%" is legal) Regards, -- Florent Georges http://www.fgeorges.org/
Received on Thursday, 17 December 2009 21:46:39 UTC