Subject: p7: editorial suggestions

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Apr 2013 13:48:02 +1000

* 2.1 "It uses an extensible, case-insensitive token..."  I know what's meant here, but the token itself isn't extensible; it's an extension point. Suggest: :It uses a case-insensitive token as a means to identify..."

* 2.1 "...based upon a challenge received from the server..." --> "...based upon a challenge received in a response"  ("from the server" implies that the next inbound server generated the challenge, which isn't always the case).

* 2.2 "Note that there can be multiple challenges with the same auth-scheme..." --> "Note that a response can have multiple challenges..."

* 2.2 "Unless otherwise defined by the authentication scheme,..." --> "Unless specifically allowed by the authentication scheme..."

* 2.3.1 "... can only be used once per challenge/credentials."  --> "...once in a challenge or credential."

* 2.3.1 needs references to p6 for cache-control directives it talks about.

* 3.1 "The client MAY repeat the request with a new or replaced Authorisation header field."  s/client/user agent/

* 4.1 'The "Authorization" header field allows a user agent to authenticate itself with a server..."   s/server/origin server/

* 4.3 "Its value consists of credentials containing the authentication information of the user agent for the proxy..."   s/user agent/client/

* 6.2 First paragraph - all instances of 'server' to 'origin server'

* 6.2 "This is of particular concern when a server hosts resources for multiple parties..."   s/server/origin server/

* 6.2 "...by using a different host name for each party."   s/host name/origin/   (or similar; i.e. you can do this with ports too)

--
Mark Nottingham   http://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Apr 2013 15:09:55 +1000

Also, the requirements and considerations for registries in our other parts are defined in the IANA Considerations section; here, they're defined in the main document (2.3). Why the difference?

---

From: Julian Reschke <[email-masked]>
Date: Sun, 28 Apr 2013 17:45:45 +0200

> * 6.2 "...by using a different host name for each party."   s/host name/origin/   (or similar; i.e. you can do this with ports too)

-> <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2229>

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 28 Apr 2013 17:49:05 +0200

On 2013-04-23 07:09, Mark Nottingham wrote:
> ...

This used to be consistent (in the main document), but it changed some 
time ago in P1, P2, P4 and P5.

P6 (Cache-Control Extensions) and P7 (Auth schemes) still have them in 
the main document.

Consistency would be good, yes. I personally *prefer* the original 
placement, because "IANA Considerations" is really *that* and nothing 
more; the considerations for extensions really are important completely 
independently of whether somethings gets registered with IANA or not.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 29 Apr 2013 12:28:15 +1000

Ok, makes sense. Consider that feedback for the other parts, then. 

Sent from my iPhone

On 29/04/2013, at 1:49 AM, Julian Reschke <[email-masked]> wrote:

> This used to be consistent (in the main document), but it changed some time ago in P1, P2, P4 and P5.
> 
> P6 (Cache-Control Extensions) and P7 (Auth schemes) still have them in the main document.
> 
> Consistency would be good, yes. I personally *prefer* the original placement, because "IANA Considerations" is really *that* and nothing more; the considerations for extensions really are important completely independently of whether somethings gets registered with IANA or not.
> 
> Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 30 Apr 2013 14:01:01 +0200

>> Consistency would be good, yes. I personally *prefer* the original placement, because "IANA Considerations" is really *that* and nothing more; the considerations for extensions really are importan…

OK, I have opened a separate ticket for this 
(<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/464>) and plan to 
move these sections to back where they were in the -20 drafts.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 1 May 2013 09:29:18 +1000

Let's move p6 and p7's sections, then.

On 01/05/2013, at 5:02 AM, Roy Fielding <[email-masked]> wrote:

> On Apr 30, 2013, at 5:01 AM, Julian Reschke wrote:
> 
> No, that would substantially harm the reading experience.  I moved
> them out because someone who is interested in learning the protocol
> has almost nothing in common with someone looking to invent
> a new protocol element, and the advice within those sections is
> really for the expert reviewers.
> 
> ....Roy
>