Original text:
the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preferences (such as a <del> configurable inactivity timeout).  Unless specifically allowed by the authentication scheme, a single protection space cannot extend outside the scope of its server. </del>  For historical reasons, a sender MUST only generate the quoted-string syntax.  Recipients might have to support both token and quoted-

Reviewer comments:
When the text suggests that credentials can be automatically applied to all requests made within a protection space, that begs the question: how do I know what requests are in the same protection space? The answer is "well, you don't really". Authentication schemes might define something, but otherwise you are left to guess. This PR says that as directly as I could manage. I considered adding another sentence here that says "In the absence of specific information about the extent of a protection space, clients &MAY; assume that the protection space extent is the origin of the server." I'd like thoughts on whether that is helpful. I think that it might be, as otherwise this isn't really implementable.
Please factor out whitespace changes...
Ugh, it's like picking up toys after children.
Neither of you have comments about saying what the extent of the protection scope is in the absence of information?
I'd rather leave that out.
AFAIU, it depends on the authentication scheme. At the end of the day, we can only document here what we inherited from earlier specs, and what is actually done in practice. If you have information on the latter which helps us making this better, great. Do you?
I proposed maybe adding: Which I believe matches what clients do when they produce credentials and the authentication scheme doesn't define a clear scope. Do you think that helps?
Not sure. What problem are we trying to solve here? Auth scheme definitions that fail to define the protection space? In which case, shouldn't we say something about this in the "Considerations for new schemes" section?
as: This says that it is a parameter, but does it appear on challenges or responses? only establishes that authentication parameters parameterize authentication schemes, there is no mention of how those relate to what is sent. I think that this first problem only requires a mention of WWW-Authenticate and Proxy-Authenticate. The second problem is in : Clients would seem to have no way of knowing whether reuse is likely to be successful. A protection space is defined as the tuple of origin and realm, but there is no acknowledgment that how a protection space might correspond to the URI space is only known to the server. (The next sentence, which I omitted from this quote acknowledges that the client needs special knowledge in order to understand that a protection space might span origins; that's very useful information.) I think that this requires only that the text acknowledge this uncertainty and note that clients could decide to provide authentication information on every request made to the origin, without knowledge of the extent of the protection space. It might also note that particular authentication schemes might define mechanisms that allow clients to decide where to use credentials. RFC 7616 defines , which allows for scoping; RFC 7617 has a section on .
re the first point: we are defining the framework here; whether a scheme uses realm, and how exactly it is used, is out of scope here. What we do is reserve the parameter name "realm", and say what it is for. Could an auth scheme use it in credentials? I believe the answer is "yes".
I think both aspects are up to the authentication scheme in question. Martin, do you feel strongly about this, or can we close?
As you say, it's kinda up for grabs. The main spec isn't very satisfactory though in that it doesn't specify, but doesn't really admit to why that is. Maybe if I can be given a chance to think of some text for this and you can see if you like it.

Revised text:
the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preferences (such as a  <ins> configurable inactivity timeout). The extent of a protection space, and therefore the requests to which credentials might be automatically applied, is not necessarily known to clients without additional information.  An authentication scheme might define parameters that describe the extent of a protection space.  Unless specifically allowed by the authentication scheme, a single protection space cannot extend outside the scope of its server. </ins> For historical reasons, a sender MUST only generate the quoted-string syntax.  Recipients might have to support both token and quoted-