Code change:
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> <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-

Related discussion:
text: 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.)