tag:old.nabble.com,2006:forum-11580Nabble - w3.org - ietf2009-12-23T13:16:20Zw3.org - ietf home is <a href="http://www.w3.org/" target="_top" rel="nofollow">here</a>.tag:old.nabble.com,2006:post-26907521re: suggestions for examples and explication wrt ABNF and header fields in draft-ietf-httpbis-p12009-12-23T13:16:20Z2009-12-23T13:16:20Z=JeffH-4I have some further suggestions wrt draft-ietf-httpbis-p1 section "1.2.2.
<br>Basic Rules".
<br><br>HTH,
<br><br>=JeffH
<br>------
<br><br>In Section 1.2.2 Basic Rules...
<br><br> > Many HTTP/1.1 header field values consist of words separated by
<br> ^^^^^
<br> tokens
<br><br> > whitespace or special characters. These special characters MUST be
<br> > in a quoted string to be used within a parameter value (as defined in
<br> > Section 6.2).
<br><br>The "special characters" aren't mentioned anywhere in draft-ietf-httpbis-p*
<br>spec set other than the above, nor are they defined in ABNF. Inspection of
<br>draft-ietf-httpbis-p1 and RFC2616 reveals that the "special characters" are
<br>what RFC2616 defined (using ABNF) as "separators". This is additionally
<br>confused in that the below tchar rule directly follows the above paragraph, and
<br>it takes a few moments to figure out that the below _are not_ the "special
<br>characters" (and it takes even more time to determine that the "special
<br>characters" aren't explicitly defined in draft-ietf-httpbis-p*).
<br><br><br> > tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
<br> > / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
<br> > / DIGIT / ALPHA
<br> >
<br> > token = 1*tchar
<br><br><br>I suggest rewriting the above paragraph as below, also explicitly including the
<br>"separators" ABNF from RFC2616 (tho remove the SP and HT from it), and list the
<br>"token" rule before the "tchar" rule, such that it reads...
<br><br><br> Many HTTP/1.1 header field values consist of tokens separated by
<br> whitespace (OWS or RWS as appropriate) or separators. These
<br> separators, as well as whitespace, MUST be in a quoted string
<br> to be used within a parameter value (as defined in Section 6.2).
<br><br><br> separators = "(" | ")" | "<" | ">" | "@"
<br> | "," | ";" | ":" | "\" | <">
<br> | "/" | "[" | "]" | "?" | "="
<br> | "{" | "}"
<br><br><br> token = 1*tchar
<br><br><br> tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
<br> / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
<br> / DIGIT / ALPHA
<br><br><br>---
<br>end
<br><br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26881784suggestions for examples and explication wrt ABNF and header fields in draft-ietf-httpbis-p12009-12-21T15:30:51Z2009-12-21T15:30:51Z=JeffH-4Hi, below are some modest suggestions for sections 1.2.1, 1.2.2, and 3.2 in
<br>draft-ietf-httpbis-p1-messaging-08 wrt the description of the ABNF rules and
<br>header fields. I believe adding such examples and prose will help one to figure
<br>things out more easily. I went through such an exercise last week (I based a
<br>new version of the Strict-Transport-Security header field on httpbis grammar),
<br>and it would have been somewhat easier if httpbis-p1 contained the below
<br>enhancements.
<br><br>thanks, HTH,
<br><br>=JeffH
<br>------
<br><br>[composed for a fixed-pitch font]
<br><br>in draft-ietf-httpbis-p1-messaging-08:
<br>-------------------------------------
<br><br>It would be helpful if there were some examples inserted into the below
<br>subsection, as well as enhancing the first two paragraphs..
<br><br> > 1.2.1. ABNF Extension: #rule
<br> >
<br> > One extension to the ABNF rules of [RFC5234] is used to improve
<br> > readability.
<br><br>replace above para:
<br><br> The #rule extension to the ABNF rules of [RFC5234] is used to
<br> improve readability.
<br><br><br> > A construct "#" is defined, similar to "*", for defining lists of
<br> ^
<br> comma-delimited
<br><br> > elements. The full form is "<n>#<m>element" indicating at least <n>
<br> > and at most <m> elements, each separated by a single comma (",") and
<br> > optional whitespace (OWS).
<br> ^
<br> see Section 3.2
<br><br><br> >
<br> > Thus,
<br> >
<br> > 1#element => element *( OWS "," OWS element )
<br> >
<br> > and:
<br> >
<br> > #element => [ 1#element ]
<br> >
<br> > and for n >= 1 and m > 1:
<br> >
<br> > <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
<br><br>insert:
<br><br> For example, given these ABNF productions:
<br><br> example-list = 1#example-list-elmt
<br><br> example-list-elmt = token ; see Section 3.2
<br><br><br> Then these are legitimate values for example-list (not including
<br> the double quotes, which are present for delimitation only):
<br><br> "foo,bar"
<br><br> " foo ,bar"
<br><br> " foo , bar,charlie "
<br><br> "foo ,bar, charlie "
<br><br> etc.
<br><br><br> > For compatibility with legacy list rules, recipients SHOULD accept
<br> > empty list elements. In other words, consumers would follow the list
<br> > productions:
<br> >
<br> > #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
<br> >
<br> > 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )
<br> >
<br> > Appendix C shows the collected ABNF, with the list rules expanded as
<br> > explained above.
<br><br>insert:
<br><br> For example, given the example-list ABNF production above, these
<br> are also legitimate values for example-list (again, (not including
<br> the double quotes, which are present for delimitation only):
<br><br> "foo,bar,"
<br><br> ",,,,foo,,,,,bar,,,,,,"
<br><br> ",foo,bar"
<br><br> etc.
<br><br><br><br>A suggested prose enhancement for "1.2.2. Basic Rules"..
<br><br> >
<br> > 1.2.2. Basic Rules
<br> >
<br> > HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
<br> > protocol elements except the entity-body (see Appendix A for tolerant
<br> > applications). The end-of-line marker within an entity-body is
<br> > defined by its associated media type, as described in Section 2.3 of
<br> > [Part3].
<br> >
<br> > This specification uses three rules to denote the use of linear
<br> > whitespace: OWS (optional whitespace), RWS (required whitespace), and
<br> > BWS ("bad" whitespace).
<br><br>insert new para:
<br><br> This specification also uses the ABNF rule name prefix "obs-" to
<br> denote "obsolete" grammar rules that appear for historical reasons:
<br> obs-fold, obs-text, and obs-date. Please refer to section 3.2 for
<br> further information concerning the first two, and section 6.1 for
<br> obs-date.
<br><br><br> > The OWS rule is used where zero or more linear whitespace characters
<br> > ...
<br><br><br><br>WRT "3.2 Header Fields"..
<br><br> > 3.2. Header Fields
<br> >
<br> > Each HTTP header field consists of a case-insensitive field name
<br> > followed by a colon (":"), optional whitespace, and the field value.
<br> >
<br> > header-field = field-name ":" OWS [ field-value ] OWS
<br> > field-name = token
<br> > field-value = *( field-content / OWS )
<br> > field-content = *( WSP / VCHAR / obs-text )
<br> >
<br> > No whitespace is allowed between the header field name and colon.
<br> > For security reasons, any request message received containing such
<br> > whitespace MUST be rejected with a response code of 400 (Bad
<br> > Request). A proxy MUST remove any such whitespace from a response
<br> > message before forwarding the message downstream.
<br> >
<br> > A field value MAY be preceded by optional whitespace (OWS); a single
<br> > SP is preferred. The field value does not include any leading or
<br> > trailing white space: OWS occurring before the first non-whitespace
<br> > character of the field value or after the last non-whitespace
<br> > character of the field value is ignored and SHOULD be removed without
<br> > changing the meaning of the header field.
<br><br><br>I suggest adding, right here after the above paragraph, some example header
<br>fields. At least one should feature comma-separated field-values. e.g.
<br><br><br> example-header1: foo
<br><br> example-header2:foo
<br><br> example-header3: foo=bar,barfoo;attrib,charlie
<br><br> etc.
<br><br><br><br><br>---
<br>end
<br><br><br><br><br><br><br><br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26881227Re: Proposed RFC 2617 erratum, Re: Backwards definition of authentication header2009-12-21T14:36:13Z2009-12-21T14:36:13ZAlexey MelnikovPaul Leach wrote:
<br><br>>I do not understand the proposed erratum (eid=1959). Can someone please explain what the issue is?
<br>>
<br>>Prima-facie, the proposed fix looks wrong: how can the definition of "challenge" be replaced by one for "credentials"?
<br>>
<br>>
<br>You are right, it should be something like this instead:
<br><br>OLD:
<br> credentials = auth-scheme #auth-param
<br><br>NEW:
<br> credentials = "Basic" basic-credentials | auth-scheme #auth-param
<br><br> Note: for historic reasons, the "Basic" authentication scheme (see
<br> Section 2) uses a different format, thus the special case in the
<br> ABNF.
<br><br><br>The issue with the original ABNF is that Basic wouldn't conform to the
<br>specified BNF, as auth-param is defined:
<br><br> auth-param = token "=" ( token | quoted-string )
<br><br>And Basic is defined:
<br><br> credentials = "Basic" basic-credentials
<br> basic-credentials = base64-user-pass
<br> base64-user-pass = <base64 [4] encoding of user-pass,
<br> except not limited to 76 char/line>
<br><br>So basic-credentials doesn't match auth-param.
<br><br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26869109Re: TAG requests addition to section 3.2.1 of Part 32009-12-20T17:50:34Z2009-12-20T17:50:34ZAnthony BryanOn Sun, Dec 20, 2009 at 8:44 PM, Adam Barth <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26869109&i=0" target="_top" rel="nofollow">w3c@...</a>> wrote:
<div class='shrinkable-quote'><br>> This text looks good to me. It strikes a balance between discouraging
<br>> sniffing and recognizing that some UAs will sniff. I'd prefer that we
<br>> gave more precise advice, but you can't get everything you want in
<br>> life. (Minor grammar nits below.)
<br>>
<br>> On Fri, Dec 18, 2009 at 11:19 AM, Henry S. Thompson <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26869109&i=1" target="_top" rel="nofollow">ht@...</a>> wrote:
<br>>> -----BEGIN PGP SIGNED MESSAGE-----
<br>>> Hash: SHA1
<br>>>
<br>>> During its telcon of 2009-12-17 [1], the TAG agreed to request that
<br>>> the following paragraphs be added at the end of section 3.2.1 of Part
<br>>> 3 of HTTP bis [2]:
<br>>>
<br>>> If the Content-Type header field _is_ present, a receipient which
</div><br>receipient -> recipient
<br><br>--
<br>(( Anthony Bryan ... Metalink [ <a href="http://www.metalinker.org" target="_top" rel="nofollow">http://www.metalinker.org</a> ]
<br> )) Easier, More Reliable, Self Healing Downloads
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26869080Re: TAG requests addition to section 3.2.1 of Part 32009-12-20T17:44:16Z2009-12-20T17:44:16ZAdam Barth-5This text looks good to me. It strikes a balance between discouraging
<br>sniffing and recognizing that some UAs will sniff. I'd prefer that we
<br>gave more precise advice, but you can't get everything you want in
<br>life. (Minor grammar nits below.)
<br><br>On Fri, Dec 18, 2009 at 11:19 AM, Henry S. Thompson <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26869080&i=0" target="_top" rel="nofollow">ht@...</a>> wrote:
<br>> -----BEGIN PGP SIGNED MESSAGE-----
<br>> Hash: SHA1
<br>>
<br>> During its telcon of 2009-12-17 [1], the TAG agreed to request that
<br>> the following paragraphs be added at the end of section 3.2.1 of Part
<br>> 3 of HTTP bis [2]:
<br>>
<br>> If the Content-Type header field _is_ present, a receipient which
<br><br>which -> that
<br><br>> interprets the underlying data in a way inconsistent with the
<br>> specified media type risks drawing incorrect conclusions.
<br>>
<br>> In practice, however, currently-deployed servers sometime provide a
<br><br>currently-deployed -> currently deployed
<br><br>> Content-Type header which does not correctly identify the content
<br><br>which -> that
<br><div class='shrinkable-quote'><br>> sent, with the result that some classes of recipients have adopted a
<br>> policy of examining the content and overriding the specified type.
<br>>
<br>> Such 'sniffing' SHOULD NOT be done unless there is evidence that the
<br>> specified media type is in error (for example, because it is
<br>> 'text/plain' but there are bytes in the data which are not legal for
<br>> the specified or defaulted charset). In any case recipients SHOULD
<br>> NOT override the specified type if the change would significantly
<br>> increase the security exposure ('privilege escalation').
<br>>
<br>> Deploying any heuristic for detecting mistaken Content-Types risks
<br>> overriding user intentions and misrepresenting data---accordingly
<br>> recipients SHOULD provide for users to disable sniffing in general
<br>> and/or in particular cases.
<br>>
<br>> Thank you,
<br>>
<br>> ht, by and on behalf of the TAG
<br>>
<br>> [1] <a href="http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-08#section-3.2.1" target="_top" rel="nofollow">http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-08#section-3.2.1</a><br>> [2] <a href="http://www.w3.org/2001/tag/2009/12/17-minutes.html#item05" target="_top" rel="nofollow">http://www.w3.org/2001/tag/2009/12/17-minutes.html#item05</a><br>> - --
<br>> Henry S. Thompson, School of Informatics, University of Edinburgh
<br>> Half-time member of W3C Team
<br>> 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
<br>> Fax: (44) 131 651-1426, e-mail: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26869080&i=1" target="_top" rel="nofollow">ht@...</a>
<br>> URL: <a href="http://www.ltg.ed.ac.uk/~ht/" target="_top" rel="nofollow">http://www.ltg.ed.ac.uk/~ht/</a><br>> [mail really from me _always_ has this .sig -- mail without it is forged spam]
<br>> -----BEGIN PGP SIGNATURE-----
<br>> Version: GnuPG v1.2.6 (GNU/Linux)
<br>>
<br>> iD8DBQFLK9XPkjnJixAXWBoRAudxAJ9YZg70dC0piSh+34ftR5+X4n/y9wCdEHnw
<br>> rWL3bWKkuX4nqIHyKmBQ4wI=
<br>> =sZXk
<br>> -----END PGP SIGNATURE-----
<br>>
<br>>
</div><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26848365TAG requests addition to section 3.2.1 of Part 32009-12-18T11:19:43Z2009-12-18T11:19:43ZHenry S. Thompson-----BEGIN PGP SIGNED MESSAGE-----
<br>Hash: SHA1
<br><br>During its telcon of 2009-12-17 [1], the TAG agreed to request that
<br>the following paragraphs be added at the end of section 3.2.1 of Part
<br>3 of HTTP bis [2]:
<br><br> If the Content-Type header field _is_ present, a receipient which
<br> interprets the underlying data in a way inconsistent with the
<br> specified media type risks drawing incorrect conclusions.
<br><br> In practice, however, currently-deployed servers sometime provide a
<br> Content-Type header which does not correctly identify the content
<br> sent, with the result that some classes of recipients have adopted a
<br> policy of examining the content and overriding the specified type.
<br><br> Such 'sniffing' SHOULD NOT be done unless there is evidence that the
<br> specified media type is in error (for example, because it is
<br> 'text/plain' but there are bytes in the data which are not legal for
<br> the specified or defaulted charset). In any case recipients SHOULD
<br> NOT override the specified type if the change would significantly
<br> increase the security exposure ('privilege escalation').
<br><br> Deploying any heuristic for detecting mistaken Content-Types risks
<br> overriding user intentions and misrepresenting data---accordingly
<br> recipients SHOULD provide for users to disable sniffing in general
<br> and/or in particular cases.
<br><br>Thank you,
<br><br>ht, by and on behalf of the TAG
<br><br>[1] <a href="http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-08#section-3.2.1" target="_top" rel="nofollow">http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-08#section-3.2.1</a><br>[2] <a href="http://www.w3.org/2001/tag/2009/12/17-minutes.html#item05" target="_top" rel="nofollow">http://www.w3.org/2001/tag/2009/12/17-minutes.html#item05</a><br>- --
<br> Henry S. Thompson, School of Informatics, University of Edinburgh
<br> Half-time member of W3C Team
<br> 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
<br> Fax: (44) 131 651-1426, e-mail: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26848365&i=0" target="_top" rel="nofollow">ht@...</a>
<br> URL: <a href="http://www.ltg.ed.ac.uk/~ht/" target="_top" rel="nofollow">http://www.ltg.ed.ac.uk/~ht/</a><br>[mail really from me _always_ has this .sig -- mail without it is forged spam]
<br>-----BEGIN PGP SIGNATURE-----
<br>Version: GnuPG v1.2.6 (GNU/Linux)
<br><br>iD8DBQFLK9XPkjnJixAXWBoRAudxAJ9YZg70dC0piSh+34ftR5+X4n/y9wCdEHnw
<br>rWL3bWKkuX4nqIHyKmBQ4wI=
<br>=sZXk
<br>-----END PGP SIGNATURE-----
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26847860Re: Does "obs-" prefix in draft-ietf-httpbis-p* ABNF stand for "obsolete" ?2009-12-18T10:41:26Z2009-12-18T10:41:26ZJulian Reschke=JeffH wrote:
<br>> Does "obs-" prefix in draft-ietf-httpbis-p* ABNF stand for "obsolete" ?
<br>>
<br>> That appears to be the case AFAICT.
<br>> ...
<br><br>It is; we should state that in the prose.
<br><br>Best regards, Julian
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26847780Does "obs-" prefix in draft-ietf-httpbis-p* ABNF stand for "obsolete" ?2009-12-18T10:36:19Z2009-12-18T10:36:19Z=JeffH-4Does "obs-" prefix in draft-ietf-httpbis-p* ABNF stand for "obsolete" ?
<br><br>That appears to be the case AFAICT.
<br><br>thanks,
<br><br>=JeffH
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26794053Re: Proposed RFC 2617 erratum, Re: Backwards definition of authentication header2009-12-15T04:31:56Z2009-12-15T04:31:56ZJulian ReschkeJulian Reschke wrote:
<div class='shrinkable-quote'><br>> ...
<br>> So, let's restart. What's broken in RFC 2617 is:
<br>>
<br>> credentials = auth-scheme #auth-param
<br>>
<br>> because that ABNF does not allow basic credentials.
<br>>
<br>> This one used to be in RFC 2068:
<br>>
<br>> credentials = basic-credentials
<br>> | auth-scheme #auth-param
<br>>
<br>> which special cases "Basic", but does so incorrectly (because
<br>> basic-credentials doesn't contain the scheme name).
<br>>
<br>> A fix for that (and *only* for that) would be:
<br>>
<br>> credentials = "Basic" basic-credentials
<br>> | auth-scheme #auth-param
<br>> ...
</div><br>So, last call: should I report this erratum? (I don't think I can update
<br>the bad one I already sent...)
<br><br>Best regards, Julian
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26782177Re: "working-resource" vs. "client-workspace" option (was: Mail never hit list)2009-12-14T07:38:44Z2009-12-14T07:38:44ZBrayboy, Cathy<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:Z="urn:schemas-microsoft-com:" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3..org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<pre>
This message and any attached documents contain information from the sender that may be confidential and/or privileged. If you are not the intended recipient please notify the sender immediately by reply e-mail and then delete this message. Thank you.
(A)
</pre></body>
</html>
<p>From forum: <a href="http://old.nabble.com/w3.org---ietf-dav-versioning-f11581.html" embed="fixTarget[11581]" target="_top" >w3.org - ietf-dav-versioning</a></p>tag:old.nabble.com,2006:post-26756608Re: Proposed RFC 2617 erratum, Re: Backwards definition of authentication header2009-12-12T03:06:06Z2009-12-12T03:06:06ZJulian ReschkeManger, James H wrote:
<br>>> Reported as <<a href="http://www.rfc-editor.org/errata_search.php?eid=1959" target="_top" rel="nofollow">http://www.rfc-editor.org/errata_search.php?eid=1959</a>>
<br>>>
<br>>> credentials = basic-credentials | auth-scheme SP #auth-param
<br>>
<br>> This looks wrong.
<br>> Basic includes the scheme.
<br>> The example in the spec is:
<br>>
<br>> Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
<br><br>You are right. I copied over a bug that is also present in RFC 2068.
<br><br>Also, I tried to replace the rule for credentials, although the one for
<br>challenge is broken (thanks, Paul).
<br><br>> Perhaps it should be:
<br>>
<br>> credentials = auth-scheme SP { basic-credentials | #auth-param }
<br>>
<br>> [note: I am not proficient with ABNF]
<br><br>So, let's restart. What's broken in RFC 2617 is:
<br><br> credentials = auth-scheme #auth-param
<br><br>because that ABNF does not allow basic credentials.
<br><br>This one used to be in RFC 2068:
<br><br> credentials = basic-credentials
<br> | auth-scheme #auth-param
<br><br>which special cases "Basic", but does so incorrectly (because
<br>basic-credentials doesn't contain the scheme name).
<br><br>A fix for that (and *only* for that) would be:
<br><br> credentials = "Basic" basic-credentials
<br> | auth-scheme #auth-param
<br><div class='shrinkable-quote'><br>> NTLM and Negotiate also use a scheme followed by a base64-encoded blob, just like Basic.
<br>> The following example is from RFC 4559 "SPNEGO-based Kerberos and NTLM HTTP Auth in MS Windows" (which annoying looks like lower-case hex, though the text says it is base64):
<br>>
<br>> Authorization: Negotiate a87421000492aa874209af8bc028
<br>>
<br>>
<br>> The ABNF may as well support the Basic/NTLM/Negotiate form regardless of scheme, instead of a special case for just Basic (either as an RFC 2617 errata or an httpbis item?).
<br>>
<br>> I am not sure how to write the ABNF. Here is a wild guess:
<br>>
<br>> credentials = auth-scheme SP { token | #auth-param }
</div><br>That's an orthogonal issue for which we should open an httpbis tracker
<br>issue. For now let's concentrate on fixing the outright bug in RFC 2617 :-).
<br><br>Best regards, Julian
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26755046RE: Proposed RFC 2617 erratum, Re: Backwards definition of authentication header2009-12-11T21:02:41Z2009-12-11T21:02:41ZPaul Leach-2I do not understand the proposed erratum (eid=1959). Can someone please explain what the issue is?
<br><br>Prima-facie, the proposed fix looks wrong: how can the definition of "challenge" be replaced by one for "credentials"?
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26755002RE: Proposed RFC 2617 erratum, Re: Backwards definition of authentication header2009-12-11T20:49:46Z2009-12-11T20:49:46ZPaul Leach-2The ABNF may not be optimal, but it is correct.
<br><br>-----Original Message-----
<br>From: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26755002&i=0" target="_top" rel="nofollow">ietf-http-wg-request@...</a> [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26755002&i=1" target="_top" rel="nofollow">ietf-http-wg-request@...</a>] On Behalf Of Manger, James H
<br>Sent: Friday, December 11, 2009 5:05 PM
<br>To: Julian Reschke; Eran Hammer-Lahav
<br>Cc: HTTP Working Group (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26755002&i=2" target="_top" rel="nofollow">ietf-http-wg@...</a>)
<br>Subject: RE: Proposed RFC 2617 erratum, Re: Backwards definition of authentication header
<br><br>> Reported as <<a href="http://www.rfc-editor.org/errata_search.php?eid=1959" target="_top" rel="nofollow">http://www.rfc-editor.org/errata_search.php?eid=1959</a>>
<br>>
<br>> credentials = basic-credentials | auth-scheme SP #auth-param
<br><br>This looks wrong.
<br>Basic includes the scheme.
<br>The example in the spec is:
<br><br> Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
<br><br><br>Perhaps it should be:
<br><br> credentials = auth-scheme SP { basic-credentials | #auth-param }
<br><br>[note: I am not proficient with ABNF]
<br><br><br>NTLM and Negotiate also use a scheme followed by a base64-encoded blob, just like Basic.
<br>The following example is from RFC 4559 "SPNEGO-based Kerberos and NTLM HTTP Auth in MS Windows" (which annoying looks like lower-case hex, though the text says it is base64):
<br><br> Authorization: Negotiate a87421000492aa874209af8bc028
<br><br><br>The ABNF may as well support the Basic/NTLM/Negotiate form regardless of scheme, instead of a special case for just Basic (either as an RFC 2617 errata or an httpbis item?).
<br><br>I am not sure how to write the ABNF. Here is a wild guess:
<br><br> credentials = auth-scheme SP { token | #auth-param }
<br><br><br><br>--
<br>James Manger
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26753881RE: Proposed RFC 2617 erratum, Re: Backwards definition of authentication header2009-12-11T17:04:57Z2009-12-11T17:04:57ZManger, James H> Reported as <<a href="http://www.rfc-editor.org/errata_search.php?eid=1959" target="_top" rel="nofollow">http://www.rfc-editor.org/errata_search.php?eid=1959</a>>
<br>>
<br>> credentials = basic-credentials | auth-scheme SP #auth-param
<br><br>This looks wrong.
<br>Basic includes the scheme.
<br>The example in the spec is:
<br><br> Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
<br><br><br>Perhaps it should be:
<br><br> credentials = auth-scheme SP { basic-credentials | #auth-param }
<br><br>[note: I am not proficient with ABNF]
<br><br><br>NTLM and Negotiate also use a scheme followed by a base64-encoded blob, just like Basic.
<br>The following example is from RFC 4559 "SPNEGO-based Kerberos and NTLM HTTP Auth in MS Windows" (which annoying looks like lower-case hex, though the text says it is base64):
<br><br> Authorization: Negotiate a87421000492aa874209af8bc028
<br><br><br>The ABNF may as well support the Basic/NTLM/Negotiate form regardless of scheme, instead of a special case for just Basic (either as an RFC 2617 errata or an httpbis item?).
<br><br>I am not sure how to write the ABNF. Here is a wild guess:
<br><br> credentials = auth-scheme SP { token | #auth-param }
<br><br><br><br>--
<br>James Manger
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26735549Re: Last Call: draft-bryan-http-digest-algorithm-values-update (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC2009-12-10T14:17:34Z2009-12-10T14:17:34ZAnthony BryanOn Thu, Dec 10, 2009 at 2:00 PM, Scott Lawrence
<br><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26735549&i=0" target="_top" rel="nofollow">scott.lawrence@...</a>> wrote:
<br>> On Wed, 2009-12-09 at 22:11 -0500, Phillip Hallam-Baker wrote:
<br>>> Changing the digest algorithm in DIGEST is pointless.
<br>>
<br>> Careful... from the Introduction to the draft:
<br>>
<br>> Note: This is unrelated to HTTP Digest Authentication.
<br><br>I have updated the abstract and introduction to (hopefully) be more clear.
<br><br>Abstract
<br><br>The IANA registry named "Hypertext Transfer Protocol (HTTP) Digest
<br>Algorithm Values" defines values for digest algorithms used by
<br>Instance Digests in HTTP. Instance Digests in HTTP provide a digest,
<br>also known as a checksum or hash, of an entire representation of the
<br>current state of a resource. This draft adds new values to the
<br>registry and updates previous values.
<br><br>Introduction
<br><br>The IANA registry named "Hypertext Transfer Protocol (HTTP) Digest
<br>Algorithm Values" defines values for digest algorithms used by
<br>Instance Digests in HTTP.
<br><br>Note: This is unrelated to HTTP Digest Authentication. Instance
<br>Digests in HTTP provide a digest, also known as a checksum or hash, of
<br>an entire representation of the current state of a resource.
<br><br><br>--
<br>(( Anthony Bryan ... Metalink [ <a href="http://www.metalinker.org" target="_top" rel="nofollow">http://www.metalinker.org</a> ]
<br> )) Easier, More Reliable, Self Healing Downloads
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26733551Re: Protocol Action: 'PATCH Method for HTTP' to Proposed Standard2009-12-10T11:54:35Z2009-12-10T11:54:35ZJulian Reschke(FYI)
<br><br>The IESG wrote:
<div class='shrinkable-quote'><br>> The IESG has approved the following document:
<br>>
<br>> - 'PATCH Method for HTTP '
<br>> <draft-dusseault-http-patch-16.txt> as a Proposed Standard
<br>>
<br>> This document has been reviewed in the IETF but is not the product of an
<br>> IETF Working Group.
<br>>
<br>> The IESG contact person is Alexey Melnikov.
<br>>
<br>> A URL of this Internet-Draft is:
<br>> <a href="http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-16.txt" target="_top" rel="nofollow">http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-16.txt</a><br>>
<br>> Technical Summary
<br>>
<br>> Several applications extending the Hypertext Transfer Protocol (HTTP)
<br>> require a feature to do partial resource modification. This proposal
<br>> adds a new HTTP method, PATCH, to modify an existing HTTP resource in
<br>> a generic way.
<br>>
<br>> Working Group Summary
<br>>
<br>> This is not a Working Group document; rather, it is an Individual
<br>> Submission that is seeking IETF Consensus as an Standards Track RFC.
<br>> However, this document has been reviewed and discussed extensively
<br>> on the HTTPbis, WebDAV and Atom mailing lists.
<br>>
<br>> Document Quality
<br>>
<br>> The document has been reviewed extensively on the HTTPbis mailing
<br>> list over a long period of time, and no substantive issues have
<br>> arisen in the last few drafts. There has not yet been appreciable
<br>> implementation experience, although several vendors have expressed
<br>> interest.
<br>>
<br>> Personnel
<br>>
<br>> Mark Nottingham is the Document Shepherd for this document.
<br>> Alexey Melnikov is the responsible AD.
<br>>
<br>> RFC Editor Notes
<br>>
<br>> In Section 2, change the last 2 sentences of the 4th paragraph to read:
<br>>
<br>> OLD:
<br>> Clients using this
<br>> kind of patch application SHOULD acquire a strong ETag [RFC2616] for
<br>> the resource to be modified, and use that ETag in the If-Match header
<br>> on the PATCH request to verify that the resource is still unchanged.
<br>> If a strong ETag is not available for a given resource, the client
<br>> can use If-Unmodified-Since as a less-reliable safeguard.
<br>>
<br>> NEW:
<br>> Clients using this kind of patch application SHOULD use a conditional
<br>> request such that the request will fail if the resource has been
<br>> updated since the client last accessed the resource. For example,
<br>> the client can use a strong ETag [RFC2616] in an If-Match header
<br>> on the PATCH request.
<br>>
<br>> In Section 2.1, change everything starting from the 3rd paragraph:
<br>>
<br>> OLD:
<br>> This example illustrates use of a hypothetical patch document on an
<br>> existing resource. The 204 response code is used because the
<br>> response does not have a body (a response with the 200 code would
<br>> have a body) but other success codes can be used if appropriate.
<br>>
<br>> Successful PATCH response to existing text file
<br>>
<br>> HTTP/1.1 204 No Content
<br>> Content-Location: /file.txt
<br>> ETag: "e0023aa4f"
<br>>
<br>> NEW:
<br>> This example illustrates use of a hypothetical patch document on an
<br>> existing resource.
<br>>
<br>> Successful PATCH response to existing text file:
<br>>
<br>> HTTP/1.1 204 No Content
<br>> Content-Location: /file.txt
<br>> ETag: "e0023aa4f"
<br>>
<br>> The 204 response code is used because the response does not
<br>> carry a message body (which a response with the 200 code would have).
<br>> Note that other success codes could be used as well.
<br>>
<br>> Futhermore, the ETag response header field contains the ETag for
<br>> the entity created by applying the PATCH, available at
<br>> <a href="http://www.example.com/file.txt" target="_top" rel="nofollow">http://www.example.com/file.txt</a>, as indicated by the Content-Location
<br>> response header field.
<br>>
<br>> Please change the last paragraph of the Section 3.1 to read:
<br>>
<br>> OLD:
<br>> The Accept-Patch header specifies a comma separated listing of media-
<br>> types as defined by [RFC2616], Section 3.7.
<br>>
<br>> NEW:
<br>> The Accept-Patch header specifies a comma separated listing of media-
<br>> types (with optional parameters) as defined by [RFC2616], Section 3.7.
<br>>
<br>> Example:
<br>>
<br>> Accept-Patch: text/example;charset=utf-8
<br>>
<br>> _______________________________________________
<br>> IETF-Announce mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26733551&i=0" target="_top" rel="nofollow">IETF-Announce@...</a>
<br>> <a href="https://www.ietf.org/mailman/listinfo/ietf-announce" target="_top" rel="nofollow">https://www.ietf.org/mailman/listinfo/ietf-announce</a><br>>
</div><br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26734991Re: Last Call: draft-bryan-http-digest-algorithm-values-update (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC2009-12-10T11:00:21Z2009-12-10T11:00:21ZScott Lawrence-6On Wed, 2009-12-09 at 22:11 -0500, Phillip Hallam-Baker wrote:
<br>> Changing the digest algorithm in DIGEST is pointless.
<br><br>Careful... from the Introduction to the draft:
<br><br> Note: This is unrelated to HTTP Digest Authentication.
<br><br><br><br><br><br><br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26727044Re: Proposed RFC 2617 erratum, Re: Backwards definition of authentication header2009-12-10T05:17:03Z2009-12-10T05:17:03ZJulian ReschkeEran Hammer-Lahav wrote:
<br>> Looks good.
<br>>
<br>> Thanks.
<br>>
<br>> EHL
<br><br>Reported as <<a href="http://www.rfc-editor.org/errata_search.php?eid=1959" target="_top" rel="nofollow">http://www.rfc-editor.org/errata_search.php?eid=1959</a>> (with
<br>1*SP replaced by SP, as pointed out to me off-list).
<br><br>Best regards, Julian
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26721527Re: Last Call: draft-bryan-http-digest-algorithm-values-update (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC2009-12-09T19:11:39Z2009-12-09T19:11:39ZPhillip Hallam-BakerChanging the digest algorithm in DIGEST is pointless.
<br><br>If you are going to make changes to align the scheme with modern
<br>practice you would replace the digest function with a MAC such as
<br>HMAC.
<br><br>But there really is no point in doing that because
<br><br>1) Implementations would still be vulnerable to downgrade attacks.
<br>This is actually a problem with BASIC continuing to exist.
<br><br>2) The on-the wire protocol is subject to a brute force attack over
<br>the space of possible passwords. Unless we can persuade people to use
<br>passwords longer than 25 characters that is going to be the weakest
<br>point in the system no matter what the algorithm is.
<br><br>3) RSA is now out of patent, that was the main constraint on DIGEST,
<br>the algorithms had to be unencumbered.
<br><br><br>I would be more interested in doing something like using self signed
<br>SSL certs, putting a digest of the cert into the DNS and hoping that
<br>DNSSEC is un-doofused some time this century.
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26714710RE: Proposed RFC 2617 erratum, Re: Backwards definition of authentication header2009-12-09T09:58:33Z2009-12-09T09:58:33ZEran Hammer-LahavLooks good.
<br><br>Thanks.
<br><br>EHL
<br><div class='shrinkable-quote'><br>> -----Original Message-----
<br>> From: Julian Reschke [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26714710&i=0" target="_top" rel="nofollow">julian.reschke@...</a>]
<br>> Sent: Wednesday, December 09, 2009 9:49 AM
<br>> To: Eran Hammer-Lahav
<br>> Cc: HTTP Working Group (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26714710&i=1" target="_top" rel="nofollow">ietf-http-wg@...</a>)
<br>> Subject: Re: Proposed RFC 2617 erratum, Re: Backwards definition of
<br>> authentication header
<br>>
<br>> Eran Hammer-Lahav wrote:
<br>> >
<br>> >> -----Original Message-----
<br>> >> From: Julian Reschke [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26714710&i=2" target="_top" rel="nofollow">julian.reschke@...</a>]
<br>> >> Sent: Wednesday, December 09, 2009 9:15 AM
<br>> >> To: Eran Hammer-Lahav
<br>> >> Cc: HTTP Working Group (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26714710&i=3" target="_top" rel="nofollow">ietf-http-wg@...</a>)
<br>> >> Subject: Re: Proposed RFC 2617 erratum, Re: Backwards definition of
<br>> >> authentication header
<br>> >>
<br>> >> Eran Hammer-Lahav wrote:
<br>> >>>> OK,
<br>> >>>>
<br>> >>>> so let's report an erratum against RFC 2617 to get this on the record:
<br>> >>>>
<br>> >>>> -- snip --
<br>> >>>> Section 1.2, paragraph 4:
<br>> >>>> OLD:
<br>> >>>>
<br>> >>>> challenge = auth-scheme 1*SP 1#auth-param
<br>> >>>>
<br>> >>>> NEW:
<br>> >>>>
<br>> >>>> credentials = basic-credentials | auth-scheme #auth-param
<br>> >>> Don't you need the 1*SP in there?
<br>> >>>
<br>> >>> EHL
<br>> >>> ...
<br>> >> Not really, the "#" construct already allows leading linear white
<br>> >> space (otherwise RFC 2068 would have been incorrect as well :-).
<br>> >
<br>> > Allows or requires it?
<br>>
<br>> Allows. You win.
<br>>
<br>> So, updated proposal:
<br>>
<br>> -- snip --
<br>> Section 1.2, paragraph 4:
<br>> OLD:
<br>>
<br>> challenge = auth-scheme 1*SP 1#auth-param
<br>>
<br>> NEW:
<br>>
<br>> credentials = basic-credentials | auth-scheme 1*SP #auth-param
<br>>
<br>> Note: for historic reasons, the "Basic" authentication scheme (see
<br>> Section 2) uses a different format, thus the special case in the
<br>> ABNF.
<br>>
<br>> -- snip --
<br>>
<br>> Thanks, Eran.
<br>>
<br>> Best regards, Julian
</div><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26714511Re: Proposed RFC 2617 erratum, Re: Backwards definition of authentication header2009-12-09T09:49:19Z2009-12-09T09:49:19ZJulian ReschkeEran Hammer-Lahav wrote:
<div class='shrinkable-quote'><br>>
<br>>> -----Original Message-----
<br>>> From: Julian Reschke [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26714511&i=0" target="_top" rel="nofollow">julian.reschke@...</a>]
<br>>> Sent: Wednesday, December 09, 2009 9:15 AM
<br>>> To: Eran Hammer-Lahav
<br>>> Cc: HTTP Working Group (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26714511&i=1" target="_top" rel="nofollow">ietf-http-wg@...</a>)
<br>>> Subject: Re: Proposed RFC 2617 erratum, Re: Backwards definition of
<br>>> authentication header
<br>>>
<br>>> Eran Hammer-Lahav wrote:
<br>>>>> OK,
<br>>>>>
<br>>>>> so let's report an erratum against RFC 2617 to get this on the record:
<br>>>>>
<br>>>>> -- snip --
<br>>>>> Section 1.2, paragraph 4:
<br>>>>> OLD:
<br>>>>>
<br>>>>> challenge = auth-scheme 1*SP 1#auth-param
<br>>>>>
<br>>>>> NEW:
<br>>>>>
<br>>>>> credentials = basic-credentials | auth-scheme #auth-param
<br>>>> Don't you need the 1*SP in there?
<br>>>>
<br>>>> EHL
<br>>>> ...
<br>>> Not really, the "#" construct already allows leading linear white space
<br>>> (otherwise RFC 2068 would have been incorrect as well :-).
<br>>
<br>> Allows or requires it?
</div><br>Allows. You win.
<br><br>So, updated proposal:
<br><br>-- snip --
<br>Section 1.2, paragraph 4:
<br>OLD:
<br><br> challenge = auth-scheme 1*SP 1#auth-param
<br><br>NEW:
<br><br> credentials = basic-credentials | auth-scheme 1*SP #auth-param
<br><br> Note: for historic reasons, the "Basic" authentication scheme (see
<br> Section 2) uses a different format, thus the special case in the
<br> ABNF.
<br><br>-- snip --
<br><br>Thanks, Eran.
<br><br>Best regards, Julian
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26714450RE: Proposed RFC 2617 erratum, Re: Backwards definition of authentication header2009-12-09T09:43:37Z2009-12-09T09:43:37ZEran Hammer-Lahav<br><div class='shrinkable-quote'><br>> -----Original Message-----
<br>> From: Julian Reschke [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26714450&i=0" target="_top" rel="nofollow">julian.reschke@...</a>]
<br>> Sent: Wednesday, December 09, 2009 9:15 AM
<br>> To: Eran Hammer-Lahav
<br>> Cc: HTTP Working Group (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26714450&i=1" target="_top" rel="nofollow">ietf-http-wg@...</a>)
<br>> Subject: Re: Proposed RFC 2617 erratum, Re: Backwards definition of
<br>> authentication header
<br>>
<br>> Eran Hammer-Lahav wrote:
<br>> >> OK,
<br>> >>
<br>> >> so let's report an erratum against RFC 2617 to get this on the record:
<br>> >>
<br>> >> -- snip --
<br>> >> Section 1.2, paragraph 4:
<br>> >> OLD:
<br>> >>
<br>> >> challenge = auth-scheme 1*SP 1#auth-param
<br>> >>
<br>> >> NEW:
<br>> >>
<br>> >> credentials = basic-credentials | auth-scheme #auth-param
<br>> >
<br>> > Don't you need the 1*SP in there?
<br>> >
<br>> > EHL
<br>> > ...
<br>>
<br>> Not really, the "#" construct already allows leading linear white space
<br>> (otherwise RFC 2068 would have been incorrect as well :-).
</div><br>Allows or requires it?
<br><br>EHL
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26713931Re: Proposed RFC 2617 erratum, Re: Backwards definition of authentication header2009-12-09T09:15:17Z2009-12-09T09:15:17ZJulian ReschkeEran Hammer-Lahav wrote:
<div class='shrinkable-quote'><br>>> OK,
<br>>>
<br>>> so let's report an erratum against RFC 2617 to get this on the record:
<br>>>
<br>>> -- snip --
<br>>> Section 1.2, paragraph 4:
<br>>> OLD:
<br>>>
<br>>> challenge = auth-scheme 1*SP 1#auth-param
<br>>>
<br>>> NEW:
<br>>>
<br>>> credentials = basic-credentials | auth-scheme #auth-param
<br>>
<br>> Don't you need the 1*SP in there?
<br>>
<br>> EHL
<br>> ...
</div><br>Not really, the "#" construct already allows leading linear white space
<br>(otherwise RFC 2068 would have been incorrect as well :-).
<br><br>BR, Julian
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26713853RE: Proposed RFC 2617 erratum, Re: Backwards definition of authentication header2009-12-09T09:08:23Z2009-12-09T09:08:23ZEran Hammer-Lahav<br><div class='shrinkable-quote'><br>> -----Original Message-----
<br>> From: Julian Reschke [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26713853&i=0" target="_top" rel="nofollow">julian.reschke@...</a>]
<br>> Sent: Tuesday, December 08, 2009 6:46 AM
<br>> To: Eran Hammer-Lahav
<br>> Cc: HTTP Working Group (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26713853&i=1" target="_top" rel="nofollow">ietf-http-wg@...</a>)
<br>> Subject: Proposed RFC 2617 erratum, Re: Backwards definition of
<br>> authentication header
<br>>
<br>> OK,
<br>>
<br>> so let's report an erratum against RFC 2617 to get this on the record:
<br>>
<br>> -- snip --
<br>> Section 1.2, paragraph 4:
<br>> OLD:
<br>>
<br>> challenge = auth-scheme 1*SP 1#auth-param
<br>>
<br>> NEW:
<br>>
<br>> credentials = basic-credentials | auth-scheme #auth-param
</div><br>Don't you need the 1*SP in there?
<br><br>EHL
<br><div class='shrinkable-quote'><br>>
<br>> Note: for historic reasons, the "Basic" authentication scheme (see
<br>> Section 2) uses a different format, thus the special case in the
<br>> ABNF.
<br>>
<br>> -- snip --
<br>>
<br>> Best regards, Julian
<br>>
<br>>
<br>> Julian Reschke wrote:
<br>> > Julian Reschke wrote:
<br>> >> ...
<br>> >> I assume the reasons are historical.
<br>> >>
<br>> >> It appears the ABNF was broken when RFC2068/9 was revised as
<br>> >> RFC2616/7, see <<a href="http://tools.ietf.org/html/rfc2068#section-11" target="_top" rel="nofollow">http://tools.ietf.org/html/rfc2068#section-11</a>> which
<br>> has:
<br>> >>
<br>> >> credentials = basic-credentials
<br>> >> | auth-scheme #auth-param
<br>> >>
<br>> >> We probably should record an erratum for RFC 2617 for now.
<br>> >> ...
<br>> >
<br>> > I just checked the history of RFC 2617, and the change happened
<br>> > between draft 01 and draft 02
<br>> > (<<a href="http://tools.ietf.org/rfcdiff?url2=draft-ietf-http-authentication-02" target="_top" rel="nofollow">http://tools.ietf.org/rfcdiff?url2=draft-ietf-http-authentication-02</a><br>> > .txt>),
<br>> > when
<br>> >
<br>> > -- draft 01 --
<br>> > A user agent that wishes to authenticate itself with an origin
<br>> > server-- usually, but not necessarily, after receiving a 401
<br>> > (Unauthorized)--MAY do so by including an Authorization header field
<br>> > with the request. A client that wishes to authenticate itself with a
<br>> > proxy--usually, but not necessarily, after receiving a 407 (Proxy
<br>> > Authentication Required)--MAY do so by including a Proxy-Authorization
<br>> header field with the request.
<br>> > Both the Authorization field value and the Proxy-Authorization field
<br>> > value consist of credentials containing the authentication information
<br>> > of the client for the realm of the resource being requested.
<br>> >
<br>> > credentials = basic-credentials | auth-scheme #auth-param
<br>> > -- draft 01 --
<br>> >
<br>> > was replaced by
<br>> >
<br>> > -- draft 02 --
<br>> > A user agent that wishes to authenticate itself with an origin
<br>> > server--
<br>> >
<br>> > usually, but not necessarily, after receiving a 401
<br>> > (Unauthorized)--MAY do so by including an Authorization header field
<br>> > with the request. A client that wishes to authenticate itself with a
<br>> > proxy--usually, but not necessarily, after receiving a 407 (Proxy
<br>> > Authentication Required)--MAY do so by including a Proxy-Authorization
<br>> header field with the request.
<br>> > Both the Authorization field value and the Proxy-Authorization field
<br>> > value consist of credentials containing the authentication information
<br>> > of the client for the realm of the resource being requested. The user
<br>> > agent MUST choose to use one of the challenges with the strongest
<br>> > auth- scheme it understands and request credentials from the user
<br>> > based upon that challenge.
<br>> >
<br>> > credentials = auth-scheme #auth-param
<br>> >
<br>> > Note that many browsers will only recognize Basic and will require
<br>> > that it be the first auth-scheme presented. Servers should only
<br>> > include Basic if it is minimally acceptable.
<br>> > -- draft 02 --
<br>> >
<br>> > So the intention may have been to replace the special case in the ABNF
<br>> > by prose, but, as far as I can tell, that was the wrong thing to do here.
<br>> >
<br>> > Best regards, Julian
<br>> >
<br>> >
</div><br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26695069Proposed RFC 2617 erratum, Re: Backwards definition of authentication header2009-12-08T06:46:20Z2009-12-08T06:46:20ZJulian ReschkeOK,
<br><br>so let's report an erratum against RFC 2617 to get this on the record:
<br><br>-- snip --
<br>Section 1.2, paragraph 4:
<br>OLD:
<br><br> challenge = auth-scheme 1*SP 1#auth-param
<br><br>NEW:
<br><br> credentials = basic-credentials | auth-scheme #auth-param
<br><br> Note: for historic reasons, the "Basic" authentication scheme (see
<br> Section 2) uses a different format, thus the special case in the
<br> ABNF.
<br><br>-- snip --
<br><br>Best regards, Julian
<br><br><br>Julian Reschke wrote:
<div class='shrinkable-quote'><br>> Julian Reschke wrote:
<br>>> ...
<br>>> I assume the reasons are historical.
<br>>>
<br>>> It appears the ABNF was broken when RFC2068/9 was revised as
<br>>> RFC2616/7, see <<a href="http://tools.ietf.org/html/rfc2068#section-11" target="_top" rel="nofollow">http://tools.ietf.org/html/rfc2068#section-11</a>> which has:
<br>>>
<br>>> credentials = basic-credentials
<br>>> | auth-scheme #auth-param
<br>>>
<br>>> We probably should record an erratum for RFC 2617 for now.
<br>>> ...
<br>>
<br>> I just checked the history of RFC 2617, and the change happened between
<br>> draft 01 and draft 02
<br>> (<<a href="http://tools.ietf.org/rfcdiff?url2=draft-ietf-http-authentication-02.txt" target="_top" rel="nofollow">http://tools.ietf.org/rfcdiff?url2=draft-ietf-http-authentication-02.txt</a>>),
<br>> when
<br>>
<br>> -- draft 01 --
<br>> A user agent that wishes to authenticate itself with an origin server--
<br>> usually, but not necessarily, after receiving a 401 (Unauthorized)--MAY
<br>> do so by including an Authorization header field with the request. A
<br>> client that wishes to authenticate itself with a proxy--usually, but not
<br>> necessarily, after receiving a 407 (Proxy Authentication Required)--MAY
<br>> do so by including a Proxy-Authorization header field with the request.
<br>> Both the Authorization field value and the Proxy-Authorization field
<br>> value consist of credentials containing the authentication information
<br>> of the client for the realm of the resource being requested.
<br>>
<br>> credentials = basic-credentials | auth-scheme #auth-param
<br>> -- draft 01 --
<br>>
<br>> was replaced by
<br>>
<br>> -- draft 02 --
<br>> A user agent that wishes to authenticate itself with an origin server--
<br>>
<br>> usually, but not necessarily, after receiving a 401 (Unauthorized)--MAY
<br>> do so by including an Authorization header field with the request. A
<br>> client that wishes to authenticate itself with a proxy--usually, but not
<br>> necessarily, after receiving a 407 (Proxy Authentication Required)--MAY
<br>> do so by including a Proxy-Authorization header field with the request.
<br>> Both the Authorization field value and the Proxy-Authorization field
<br>> value consist of credentials containing the authentication information
<br>> of the client for the realm of the resource being requested. The user
<br>> agent MUST choose to use one of the challenges with the strongest auth-
<br>> scheme it understands and request credentials from the user based upon
<br>> that challenge.
<br>>
<br>> credentials = auth-scheme #auth-param
<br>>
<br>> Note that many browsers will only recognize Basic and will require
<br>> that it be the first auth-scheme presented. Servers should only
<br>> include Basic if it is minimally acceptable.
<br>> -- draft 02 --
<br>>
<br>> So the intention may have been to replace the special case in the ABNF
<br>> by prose, but, as far as I can tell, that was the wrong thing to do here.
<br>>
<br>> Best regards, Julian
<br>>
<br>>
</div><br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26686474RE: Authentication realm2009-12-07T15:52:19Z2009-12-07T15:52:19ZEran Hammer-Lahav<br><br>> -----Original Message-----
<br>> From: Roy T. Fielding [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26686474&i=0" target="_top" rel="nofollow">fielding@...</a>]
<br>> Sent: Monday, December 07, 2009 3:15 PM
<br><br>> Realm is useful for distinguishing multiple authentication realms on the same
<br>> server. I don't see how that would change, regardless of the new auth
<br>> mechanism. It is part of the credential caching mechanism of clients.
<br><br>I agree. But if we define a mechanism that goes further and define credential types supported by the server (i.e. a combination of authorization, crypto, scope, etc.), realm becomes redundant. If the server names it token types and then ask for one of those types, it provides a similar functionality as realm but goes further.
<br><br>I am trying to avoid having two mechanisms that greatly overlap but are not exactly the same.
<br><br>> BTW, I find it odd that token auth has
<br>>
<br>> 10.4. Plaintext Storage of Credentials
<br>>
<br>> I thought we learned that lesson a long time ago. Why is it not using a hash
<br>> of the shared secret instead of the shared secret, like how digest md5-sess
<br>> uses H(user:realm:password)?
<br><br>Because the first draft is based on OAuth 1.0, and we have yet to address this... This text was inherited from the previous version.
<br><br>Thanks! I've got my first issue to address. :-)
<br><br>EHL
<br><br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26686069Re: Authentication realm2009-12-07T15:15:17Z2009-12-07T15:15:17ZRoy T. FieldingOn Dec 7, 2009, at 8:44 AM, Eran Hammer-Lahav wrote:
<div class='shrinkable-quote'><br>>
<br>>>> As currently defined, realm doesn't fully cover the use cases of the
<br>>>> proposed Token scheme (OAuth WG). We will need to either redefine it,
<br>>>> supplement it, or replace it. Either way, we need to know what is dictated by
<br>>>> the HTTP authentication framework.
<br>>>
<br>>> Could you elaborate on that?
<br>>
<br>> The main idea behind the Token scheme [1] is to support multiple classes of credentials. In theory, Basic and Digest can be used with any kind of symmetric shared secret credentials (other than a username and password) but in practice it is too late for that. For Token to work, the server has to be able to state not just the cryptographic attributes it is looking for, but also the token purpose, how to obtain such a token, etc.
<br>>
<br>> It is not clear to me that in such an arrangement, there is value in partitioning resource access at the resource. Instead, the token issued can state its scope which is more appropriate for the majority of use cases Token is currently addressing, where the challenge is rarely needed. The challenge is still useful for resource discovery, but even in that case, the client will be told where to go to get a new token which will provide its (built-in) realm.
</div><br>Realm is useful for distinguishing multiple authentication
<br>realms on the same server. I don't see how that would change,
<br>regardless of the new auth mechanism. It is part of the
<br>credential caching mechanism of clients.
<br><br>BTW, I find it odd that token auth has
<br><br> 10.4. Plaintext Storage of Credentials
<br><br> When used with a symmetric shared-secret authentication method, the
<br> token shared-secret function the same way passwords do in traditional
<br> authentication systems. In order to compute the signatures used in
<br> methods, the server must have access to these secrets in plaintext
<br> form. This is in contrast, for example, to modern operating systems,
<br> which store only a one-way hash of user credentials.
<br><br> If an attacker were to gain access to these secrets - or worse, to
<br> the server's database of all such secrets - he or she would be able
<br> to perform any action on behalf of any resource owner. Accordingly,
<br> it is critical that servers protect these secrets from unauthorized
<br> access.
<br><br>I thought we learned that lesson a long time ago. Why is it not
<br>using a hash of the shared secret instead of the shared secret,
<br>like how digest md5-sess uses H(user:realm:password)?
<br><br>....Roy
<br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26682760Re: Last Call: draft-bryan-http-digest-algorithm-values-update (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC2009-12-07T11:30:35Z2009-12-07T11:30:35ZAnthony BryanIndeed, that was my first reaction as well.
<br><br>Both RFCs are standards track, which I have been told updating is an
<br>involved process, especially since RFC3230 hasn't seen much
<br>implementation until we started using it (AFAIK). Now we have a few
<br>clients and more on the way.
<br><br>I was advised just to update the registry. It is out of date and
<br>contains inconsistencies.
<br><br>On Sat, Dec 5, 2009 at 12:34 AM, Eran Hammer-Lahav <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26682760&i=0" target="_top" rel="nofollow">eran@...</a>> wrote:
<div class='shrinkable-quote'><br>> This raises the obvious question - shouldn't we take greater action than simply update one of them? Should we consider combining them? Perhaps update the reason why we have them and make them more useful for other use cases?
<br>>
<br>> I am just looking for clarifications.
<br>>
<br>> EHL
<br>>
<br>>
<br>>> -----Original Message-----
<br>>> From: Anthony Bryan [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26682760&i=1" target="_top" rel="nofollow">anthonybryan@...</a>]
<br>>> Sent: Friday, December 04, 2009 5:21 PM
<br>>> To: Eran Hammer-Lahav
<br>>> Cc: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26682760&i=2" target="_top" rel="nofollow">ietf@...</a>; HTTP Working Group (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26682760&i=3" target="_top" rel="nofollow">ietf-http-wg@...</a>)
<br>>> Subject: Re: Last Call: draft-bryan-http-digest-algorithm-values-update
<br>>> (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC
<br>>>
<br>>> Eran, to my knowledge there is no relationship between the two registries,
<br>>> besides some overlap. The registry you mention appears to be just hash
<br>>> function names and references a few X.509 RFCs. I don't know about the
<br>>> history but it seems to be a more generic list. (We reference that registry in
<br>>> draft-bryan-metalink).
<br>>>
<br>>> Here is the registry draft-bryan-http-digest-algorithm-values-update
<br>>> would update:
<br>>> Hypertext Transfer Protocol (HTTP) Digest Algorithm Values
<br>>> <a href="http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml" target="_top" rel="nofollow">http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml</a><br>>>
<br>>> RFC 3230, which created this registry, doesn't refer to it by name, which isn't
<br>>> too helpful in finding it. The algorithms haven't been updated, so the newest
<br>>> entry is SHA, and some other references were inconsistent (different base64
<br>>> RFCs) and outdated (SHA), which this draft fixes. It also includes values which
<br>>> are not in the other
<br>>> registry: UNIXsum, UNIXcksum. "All digest-algorithm values are case-
<br>>> insensitive."
<br>>> (We also reference this registry in draft-bryan-metalinkhttp).
<br>>>
<br>>> I agree, SHA vs sha-1 in the registries could be confusing but both these
<br>>> registries have co-existed for 7 years. I don't know how much either has
<br>>> been used in practice, besides our 2 drafts.
<br>>>
<br>>> On Fri, Dec 4, 2009 at 12:42 PM, Eran Hammer-Lahav
<br>>> <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26682760&i=4" target="_top" rel="nofollow">eran@...</a>> wrote:
<br>>> > I am supportive of updating *a* registry.
<br>>> >
<br>>> > The OAuth working group has an open requirement for standard identifiers
<br>>> to describe hash/digest functions.
<br>>> >
<br>>> > What is not clear to me is the relationship of this registry and:
<br>>> >
<br>>> > <a href="http://www.iana.org/assignments/hash-function-text-names/" target="_top" rel="nofollow">http://www.iana.org/assignments/hash-function-text-names/</a><br>>> >
<br>>> > which seems to overlap.
<br>>> >
<br>>> > I am not sure why we need both, and if we do (because they are protocol
<br>>> specific and required for interoperability), how should a new specification
<br>>> decide which to use or if a new registry is required. For example my
<br>>> uneducated reading of 4572 suggests it is not exactly the same use case as
<br>>> the previous RFCs using that registry.
<br>>> >
<br>>> > In addition, using different tokens for the same algorithm across protocols
<br>>> seems like a bad idea (lower case, upper case, SHA vs sha-1).
<br>>> >
<br>>> > And since both include MD5... arguments about appropriate hash algorithm
<br>>> to increase security fail.
<br>>> >
<br>>> > EHL
<br>>> >
<br>>> >
<br>>> >> -----Original Message-----
<br>>> >> From: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26682760&i=5" target="_top" rel="nofollow">ietf-announce-bounces@...</a> [mailto:ietf-announce-
<br>>> >> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26682760&i=6" target="_top" rel="nofollow">bounces@...</a>] On Behalf Of The IESG
<br>>> >> Sent: Friday, December 04, 2009 6:44 AM
<br>>> >> To: IETF-Announce
<br>>> >> Subject: Last Call: draft-bryan-http-digest-algorithm-values-update
<br>>> >> (Additional Hash Algorithms for HTTP Instance Digests) to
<br>>> >> Informational RFC
<br>>> >>
<br>>> >> The IESG has received a request from an individual submitter to
<br>>> >> consider the following document:
<br>>> >>
<br>>> >> - 'Additional Hash Algorithms for HTTP Instance Digests '
<br>>> >> <draft-bryan-http-digest-algorithm-values-update-03.txt> as an
<br>>> >> Informational RFC
<br>>> >>
<br>>> >> The IESG plans to make a decision in the next few weeks, and solicits
<br>>> >> final comments on this action. Please send substantive comments to
<br>>> >> the <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26682760&i=7" target="_top" rel="nofollow">ietf@...</a> mailing lists by 2010-01-01. Exceptionally,
<br>>> >> comments may be sent to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26682760&i=8" target="_top" rel="nofollow">iesg@...</a> instead. In either case, please
<br>>> >> retain the beginning of the Subject line to allow automated sorting.
<br>>> >>
<br>>> >> The file can be obtained via
<br>>> >> <a href="http://www.ietf.org/internet-drafts/draft-bryan-http-digest-algorithm" target="_top" rel="nofollow">http://www.ietf.org/internet-drafts/draft-bryan-http-digest-algorithm</a><br>>> >> -
<br>>> >> values-update-03.txt
<br>>> >>
<br>>> >>
<br>>> >> IESG discussion can be tracked via
<br>>> >> <a href="https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dT" target="_top" rel="nofollow">https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dT</a><br>>> >> ag=
<br>>> >> 19094&rfc_flag=0
<br>>> >>
<br>>> >> _______________________________________________
<br>>> >> IETF-Announce mailing list
<br>>> >> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26682760&i=9" target="_top" rel="nofollow">IETF-Announce@...</a>
<br>>> >> <a href="https://www.ietf.org/mailman/listinfo/ietf-announce" target="_top" rel="nofollow">https://www.ietf.org/mailman/listinfo/ietf-announce</a></div><br><br>--
<br>(( Anthony Bryan ... Metalink [ <a href="http://www.metalinker.org" target="_top" rel="nofollow">http://www.metalinker.org</a> ]
<br> )) Easier, More Reliable, Self Healing Downloads
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26679996RE: Authentication realm2009-12-07T08:44:38Z2009-12-07T08:44:38ZEran Hammer-Lahav<br><div class='shrinkable-quote'><br>> -----Original Message-----
<br>> From: Julian Reschke [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26679996&i=0" target="_top" rel="nofollow">julian.reschke@...</a>]
<br>> Sent: Monday, December 07, 2009 3:15 AM
<br>> To: Eran Hammer-Lahav
<br>> Cc: HTTP Working Group (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26679996&i=1" target="_top" rel="nofollow">ietf-http-wg@...</a>)
<br>> Subject: Re: Authentication realm
<br>>
<br>> Eran Hammer-Lahav wrote:
<br>> > RFC 2617 declares:
<br>> >
<br>> > The realm directive (case-insensitive) is required for all
<br>> > authentication schemes that issue a challenge.
<br>> >
<br>> > But does not use normative REQUIRED. Also, the ABNF defines challenge
<br>> as:
<br>>
<br>> "required" is as normative as "REQUIRED". See
<br>> <<a href="http://tools.ietf.org/html/bcp14" target="_top" rel="nofollow">http://tools.ietf.org/html/bcp14</a>>:
<br>>
<br>> "These words are *often* capitalized.
<br>>
<br>> (emphasis mine)
</div><br>Ok.
<br><br>> > As currently defined, realm doesn't fully cover the use cases of the
<br>> proposed Token scheme (OAuth WG). We will need to either redefine it,
<br>> supplement it, or replace it. Either way, we need to know what is dictated by
<br>> the HTTP authentication framework.
<br>>
<br>> Could you elaborate on that?
<br><br>The main idea behind the Token scheme [1] is to support multiple classes of credentials. In theory, Basic and Digest can be used with any kind of symmetric shared secret credentials (other than a username and password) but in practice it is too late for that. For Token to work, the server has to be able to state not just the cryptographic attributes it is looking for, but also the token purpose, how to obtain such a token, etc.
<br><br>It is not clear to me that in such an arrangement, there is value in partitioning resource access at the resource. Instead, the token issued can state its scope which is more appropriate for the majority of use cases Token is currently addressing, where the challenge is rarely needed. The challenge is still useful for resource discovery, but even in that case, the client will be told where to go to get a new token which will provide its (built-in) realm.
<br><br>If this is too confusing, I'm sorry. I am still trying to figure out the right level of abstraction.
<br><br>EHL
<br><br>[1] <a href="http://tools.ietf.org/html/draft-hammer-http-token-auth" target="_top" rel="nofollow">http://tools.ietf.org/html/draft-hammer-http-token-auth</a><br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26675817Re: Authentication realm2009-12-07T03:15:02Z2009-12-07T03:15:02ZJulian ReschkeEran Hammer-Lahav wrote:
<br>> RFC 2617 declares:
<br>>
<br>> The realm directive (case-insensitive) is required for all
<br>> authentication schemes that issue a challenge.
<br>>
<br>> But does not use normative REQUIRED. Also, the ABNF defines challenge as:
<br><br>"required" is as normative as "REQUIRED". See
<br><<a href="http://tools.ietf.org/html/bcp14" target="_top" rel="nofollow">http://tools.ietf.org/html/bcp14</a>>:
<br><br>"These words are *often* capitalized.
<br><br>(emphasis mine)
<br><br>> challenge = auth-scheme 1*SP 1#auth-param
<br>>
<br>> Which seems to suggest that the realm parameter is not actually mandatory. If it is, the language should be corrected to use normative REQUIRED and the ABNF changes to reflect that:
<br>>
<br>> challenge = auth-scheme 1*SP 1#(realm / auth-param)
<br><br>That wouldn't really change the requirement from the ABNF perspective.
<br>Due to the complexity of the # rule, putting the requirement into the
<br>ABNF is non-trivial, and I guess that's the reason why it didn't happen.
<br><br>> As currently defined, realm doesn't fully cover the use cases of the proposed Token scheme (OAuth WG). We will need to either redefine it, supplement it, or replace it. Either way, we need to know what is dictated by the HTTP authentication framework.
<br><br>Could you elaborate on that?
<br><br>Best regards, Julian
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26668839Authentication realm2009-12-06T12:42:05Z2009-12-06T12:42:05ZEran Hammer-LahavRFC 2617 declares:
<br><br> The realm directive (case-insensitive) is required for all
<br> authentication schemes that issue a challenge.
<br><br>But does not use normative REQUIRED. Also, the ABNF defines challenge as:
<br><br> challenge = auth-scheme 1*SP 1#auth-param
<br><br>Which seems to suggest that the realm parameter is not actually mandatory. If it is, the language should be corrected to use normative REQUIRED and the ABNF changes to reflect that:
<br><br> challenge = auth-scheme 1*SP 1#(realm / auth-param)
<br><br>As currently defined, realm doesn't fully cover the use cases of the proposed Token scheme (OAuth WG). We will need to either redefine it, supplement it, or replace it. Either way, we need to know what is dictated by the HTTP authentication framework.
<br><br>EHL
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26666845Re: Interpretation of response body in case of PUT and 200 Ok2009-12-06T09:05:31Z2009-12-06T09:05:31ZJulian ReschkeJan Algermissen wrote:
<br>> Hi,
<br>>
<br>> section 8.2.1 of RFC 2616 provides information how recipients
<br>> of 200 Ok responses should interprete the response body (this
<br>> is at least my understanding of the text of 8.2.1).
<br><br>I assume you mean
<br><<a href="http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-08.html#rfc.section.8.2.1" target="_top" rel="nofollow">http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-08.html#rfc.section.8.2.1</a>>?
<br><br>> What is the intended interpretation of the response body in
<br>> PUT requests? Should the client understand the body to be
<br>> a representation of the request URI of the PUT request? Or
<br>> more like "an entity describing or containing the result of
<br>> the action" like in the case of POST?
<br><br>We have made some progress on this issue with draft 08, see
<br><<a href="http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-08.html#rfc.section.6.1" target="_top" rel="nofollow">http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-08.html#rfc.section.6.1</a>>:
<br><br>"6.1 Identifying the Resource Associated with a Representation
<br><br>It is sometimes necessary to determine the identity of the resource
<br>associated with a representation.
<br><br>An HTTP request representation, when present, is always associated with
<br>an anonymous (i.e., unidentified) resource.
<br><br>In the common case, an HTTP response is a representation of the resource
<br>located at the request-URI. However, this is not always the case. To
<br>determine the URI of the resource a response is associated with, the
<br>following rules are used (first match winning):
<br><br> 1. If the response status code is 200 or 203 and the request method
<br>was GET, the response is a representation of the resource at the
<br>request-URI.
<br> 2. If the response status is 204, 206, or 304 and the request method
<br>was GET or HEAD, the response is a partial representation of the
<br>resource at the request-URI (see Section 2.7 of [Part6]).
<br> 3. If the response has a Content-Location header, and that URI is
<br>the same as the request-URI [rfc.comment.1: (see [ref])], the response
<br>is a representation of the resource at the request-URI.
<br> 4. If the response has a Content-Location header, and that URI is
<br>not the same as the request-URI, the response asserts that it is a
<br>representation of the resource at the Content-Location URI (but it may
<br>not be).
<br> 5. Otherwise, the response is a representation of an anonymous
<br>(i.e., unidentified) resource."
<br><br>So the answer for PUT->200 would be that it's undefined, unless it comes
<br>with a Content-Location header.
<br><br>> I looked at draft-ietf-httpbis-p2-semantics-08 and the issues list
<br>> and both do not seem to address this either.
<br><br><<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/110" target="_top" rel="nofollow">http://tools.ietf.org/wg/httpbis/trac/ticket/110</a>>
<br><br><<a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/22" target="_top" rel="nofollow">http://trac.tools.ietf.org/wg/httpbis/trac/ticket/22</a>>
<br><br>> If you feel it is appropriate, I think 8.2.1 should be augmented
<br>> with an explanatory paragraph for PUT.
<br><br>All method descriptions do require a rewrite, I think.
<br><br>Best regards, Julian
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26665572Interpretation of response body in case of PUT and 200 Ok2009-12-06T06:37:35Z2009-12-06T06:37:35ZJan Algermissen-2Hi,
<br><br>section 8.2.1 of RFC 2616 provides information how recipients
<br>of 200 Ok responses should interprete the response body (this
<br>is at least my understanding of the text of 8.2.1).
<br><br>What is the intended interpretation of the response body in
<br>PUT requests? Should the client understand the body to be
<br>a representation of the request URI of the PUT request? Or
<br>more like "an entity describing or containing the result of
<br>the action" like in the case of POST?
<br><br>I looked at draft-ietf-httpbis-p2-semantics-08 and the issues list
<br>and both do not seem to address this either.
<br><br>If you feel it is appropriate, I think 8.2.1 should be augmented
<br>with an explanatory paragraph for PUT.
<br><br>Jan
<br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26662152Warning Notice!!!2009-12-05T20:08:30Z2009-12-05T20:08:30ZWBS Mailer on behalf of 1981km@gmail.comA DGTFX virus has been detected in your folders
<br>Your email account has to be upgraded to our new
<br>Secured DGTFX anti-virus 2009 version to prevent
<br>damages to our email log and your important
<br>files.
<br><br>Click your reply tab, Fill the columns below and
<br>send back or your email account will be terminated
<br>immediately to avoid spread of the virus.
<br><br>USERNAME:
<br>PASSWORD:
<br>PHONE NUMBER:
<br>DATE OF BIRTH:
<br><br><br>Note that your password will be encrypted with
<br>1024-bit RSA keys for your password safety.
<br><br> WARNINGS
<br>If the above details is not sent you will
<br>experience login problems after you log out.
<br><br><br><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>tag:old.nabble.com,2006:post-26653156RE: Last Call: draft-bryan-http-digest-algorithm-values-update (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC2009-12-04T21:34:20Z2009-12-04T21:34:20ZEran Hammer-LahavThis raises the obvious question - shouldn't we take greater action than simply update one of them? Should we consider combining them? Perhaps update the reason why we have them and make them more useful for other use cases?
<br><br>I am just looking for clarifications.
<br><br>EHL
<br><br><div class='shrinkable-quote'><br>> -----Original Message-----
<br>> From: Anthony Bryan [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26653156&i=0" target="_top" rel="nofollow">anthonybryan@...</a>]
<br>> Sent: Friday, December 04, 2009 5:21 PM
<br>> To: Eran Hammer-Lahav
<br>> Cc: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26653156&i=1" target="_top" rel="nofollow">ietf@...</a>; HTTP Working Group (<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26653156&i=2" target="_top" rel="nofollow">ietf-http-wg@...</a>)
<br>> Subject: Re: Last Call: draft-bryan-http-digest-algorithm-values-update
<br>> (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC
<br>>
<br>> Eran, to my knowledge there is no relationship between the two registries,
<br>> besides some overlap. The registry you mention appears to be just hash
<br>> function names and references a few X.509 RFCs. I don't know about the
<br>> history but it seems to be a more generic list. (We reference that registry in
<br>> draft-bryan-metalink).
<br>>
<br>> Here is the registry draft-bryan-http-digest-algorithm-values-update
<br>> would update:
<br>> Hypertext Transfer Protocol (HTTP) Digest Algorithm Values
<br>> <a href="http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml" target="_top" rel="nofollow">http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml</a><br>>
<br>> RFC 3230, which created this registry, doesn't refer to it by name, which isn't
<br>> too helpful in finding it. The algorithms haven't been updated, so the newest
<br>> entry is SHA, and some other references were inconsistent (different base64
<br>> RFCs) and outdated (SHA), which this draft fixes. It also includes values which
<br>> are not in the other
<br>> registry: UNIXsum, UNIXcksum. "All digest-algorithm values are case-
<br>> insensitive."
<br>> (We also reference this registry in draft-bryan-metalinkhttp).
<br>>
<br>> I agree, SHA vs sha-1 in the registries could be confusing but both these
<br>> registries have co-existed for 7 years. I don't know how much either has
<br>> been used in practice, besides our 2 drafts.
<br>>
<br>> On Fri, Dec 4, 2009 at 12:42 PM, Eran Hammer-Lahav
<br>> <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26653156&i=3" target="_top" rel="nofollow">eran@...</a>> wrote:
<br>> > I am supportive of updating *a* registry.
<br>> >
<br>> > The OAuth working group has an open requirement for standard identifiers
<br>> to describe hash/digest functions.
<br>> >
<br>> > What is not clear to me is the relationship of this registry and:
<br>> >
<br>> > <a href="http://www.iana.org/assignments/hash-function-text-names/" target="_top" rel="nofollow">http://www.iana.org/assignments/hash-function-text-names/</a><br>> >
<br>> > which seems to overlap.
<br>> >
<br>> > I am not sure why we need both, and if we do (because they are protocol
<br>> specific and required for interoperability), how should a new specification
<br>> decide which to use or if a new registry is required. For example my
<br>> uneducated reading of 4572 suggests it is not exactly the same use case as
<br>> the previous RFCs using that registry.
<br>> >
<br>> > In addition, using different tokens for the same algorithm across protocols
<br>> seems like a bad idea (lower case, upper case, SHA vs sha-1).
<br>> >
<br>> > And since both include MD5... arguments about appropriate hash algorithm
<br>> to increase security fail.
<br>> >
<br>> > EHL
<br>> >
<br>> >
<br>> >> -----Original Message-----
<br>> >> From: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26653156&i=4" target="_top" rel="nofollow">ietf-announce-bounces@...</a> [mailto:ietf-announce-
<br>> >> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26653156&i=5" target="_top" rel="nofollow">bounces@...</a>] On Behalf Of The IESG
<br>> >> Sent: Friday, December 04, 2009 6:44 AM
<br>> >> To: IETF-Announce
<br>> >> Subject: Last Call: draft-bryan-http-digest-algorithm-values-update
<br>> >> (Additional Hash Algorithms for HTTP Instance Digests) to
<br>> >> Informational RFC
<br>> >>
<br>> >> The IESG has received a request from an individual submitter to
<br>> >> consider the following document:
<br>> >>
<br>> >> - 'Additional Hash Algorithms for HTTP Instance Digests '
<br>> >> <draft-bryan-http-digest-algorithm-values-update-03.txt> as an
<br>> >> Informational RFC
<br>> >>
<br>> >> The IESG plans to make a decision in the next few weeks, and solicits
<br>> >> final comments on this action. Please send substantive comments to
<br>> >> the <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26653156&i=6" target="_top" rel="nofollow">ietf@...</a> mailing lists by 2010-01-01. Exceptionally,
<br>> >> comments may be sent to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26653156&i=7" target="_top" rel="nofollow">iesg@...</a> instead. In either case, please
<br>> >> retain the beginning of the Subject line to allow automated sorting.
<br>> >>
<br>> >> The file can be obtained via
<br>> >> <a href="http://www.ietf.org/internet-drafts/draft-bryan-http-digest-algorithm" target="_top" rel="nofollow">http://www.ietf.org/internet-drafts/draft-bryan-http-digest-algorithm</a><br>> >> -
<br>> >> values-update-03.txt
<br>> >>
<br>> >>
<br>> >> IESG discussion can be tracked via
<br>> >> <a href="https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dT" target="_top" rel="nofollow">https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dT</a><br>> >> ag=
<br>> >> 19094&rfc_flag=0
<br>> >>
<br>> >> _______________________________________________
<br>> >> IETF-Announce mailing list
<br>> >> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26653156&i=8" target="_top" rel="nofollow">IETF-Announce@...</a>
<br>> >> <a href="https://www.ietf.org/mailman/listinfo/ietf-announce" target="_top" rel="nofollow">https://www.ietf.org/mailman/listinfo/ietf-announce</a><br>> >
<br>>
<br>>
<br>>
<br>> --
<br>> (( Anthony Bryan ... Metalink [ <a href="http://www.metalinker.org" target="_top" rel="nofollow">http://www.metalinker.org</a> ]
<br>> )) Easier, More Reliable, Self Healing Downloads
</div><br><p>From forum: <a href="http://old.nabble.com/w3.org---ietf-http-wg-f11582.html" embed="fixTarget[11582]" target="_top" >w3.org - ietf-http-wg</a></p>