Subject: #314: realm parameter syntax

From: Julian Reschke <[email-masked]>
Date: Sun, 20 Nov 2011 17:51:39 +0100

Context:

   http://trac.tools.ietf.org/wg/httpbis/trac/ticket/314

and

   http://greenbytes.de/tech/tc/httpauth/#simplebasictok

Proposed Change:

Remove the parameter-specific ABNF and describe the syntax in prose; 
noting that many recipients accept token as well, thus new recipients 
may have to, as well.

The new description would read:

2.2.  Protection Space (Realm)

    The authentication parameter realm is reserved for use by
    authentication schemes that wish to indicate the scope of protection.

    A protection space is defined by the canonical root URI (the scheme
    and authority components of the effective request URI; see Section
    4.3 of [Part1]) of the server being accessed, in combination with the
    realm value if present.  These realms allow the protected resources
    on a server to be partitioned into a set of protection spaces, each
    with its own authentication scheme and/or authorization database.
    The realm value is a string, generally assigned by the origin server,
    which can have additional semantics specific to the authentication
    scheme.  Note that there can be multiple challenges with the same
    auth-scheme but different realms.

    The protection space determines the domain over which credentials can
    be automatically applied.  If a prior request has been authorized,
    the same credentials MAY be reused for all other requests within that
    protection space for a period of time determined by the
    authentication scheme, parameters, and/or user preference.  Unless
    otherwise defined by the authentication scheme, a single protection
    space cannot extend outside the scope of its server.

    For historical reasons, senders MUST only use the quoted-string
    syntax.  Recipients might have to support both token and quoted-
    string syntax as both have been accepted by common user-agents for
    many years.

See also: 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/314/314.diff>

Feedback appreciated, Julian

---

From: Yutaka OIWA <[email-masked]>
Date: Mon, 21 Nov 2011 03:15:31 +0900

Dear Julian,

I support the final conclusion, but am only against the reasoning text.
The fact that people did a "loose" thing does not mean
that the followers should do as well.
We have a direct reason to do so instead, doesn't we?

If there are any major "senders" which have been sent token realms
for a long time, it is much important than the current reason.
In this case, I propose the following:

> Recipients are RECOMMENDED to accept both token and quoted-
> string syntax as both have been sent by several HTTP servers
> (and successfully accepted by common user-agents) for many years.

# In this case, there should be an RFC2119 "RECOMMENDED", I think.

If not, my proposal is a much simpler clause as:

> Recipients might have to support both token and quoted-
> string syntax for maximum input tolerability (both have been
> accepted by common user-agents for many years).

# or, s/might have to support/might be better supporting/

Yes, input tolerability is a good thing (at least on this case).

--
Yutaka OIWA, Ph.D.                                       Research Scientist
                           Research Center for Information Security (RCIS)
   National Institute of Advanced Industrial Science and Technology (AIST)
                     Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: Julian Reschke <[email-masked]>
Date: Sun, 20 Nov 2011 19:29:50 +0100

> for a long time, it is much important than the current reason.

That's true; but I don't know whether this is the case. Do you?

> # In this case, there should be an RFC2119 "RECOMMENDED", I think.

RECOMMENDED==SHOULD. If we did this, I think it clearly would need to be 
MUST, because I can't think of any "valid reasons" not to.

> Yes, input tolerability is a good thing (at least on this case).

Or, maybe:

"Recipients might have to support both token and quoted-string syntax 
for maximum interoperability with existing clients that have been 
accepting both notations for a long time."

?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 25 Nov 2011 16:56:11 +0100

> That's true; but I don't know whether this is the case. Do you?

I think we don't know right now; if we find out in time, we can re-open 
the ticket.

> ...

As nobody else offered feedback, I went ahead and made this change; see 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1478>.

Best regards, Julian