- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 25 Nov 2011 16:56:11 +0100
- To: Yutaka OIWA <y.oiwa@aist.go.jp>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
On 2011-11-20 19:29, Julian Reschke wrote: > On 2011-11-20 19:15, Yutaka OIWA wrote: >> 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. > > 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. >> 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. > > 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. > >> 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). > > 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." > > ? > ... 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
Received on Friday, 25 November 2011 15:56:45 UTC