W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > December 2009

Re: [closed] Re: p:http-request: authentication concerns

From: Florent Georges <fgeorges@fgeorges.org>
Date: Thu, 17 Dec 2009 22:46:10 +0100
Message-ID: <ebaca5bf0912171346x17bee3d7v5f6a2ce6e6ddc5de@mail.gmail.com>
To: Norman Walsh <ndw@nwalsh.com>
Cc: public-xml-processing-model-comments@w3.org
2009/12/17 Norman Walsh wrote:


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


Florent Georges
Received on Thursday, 17 December 2009 21:46:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:28:27 UTC