Re: What is with the From field containing UTF-8 stuff?
- From: Peter J Ross <pjr@xxxxxxxxxxxxxxx>
- Date: 10 Sep 2007 18:27:20 GMT
In news.software.readers on Mon, 10 Sep 2007 09:51:17 -0300, Shmuel
(Seymour J.) Metz <spamtrap@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
In <slrnfea9tl.itq.pjr@xxxxxxxxxxxxxx>, on 09/10/2007
at 11:17 AM, Peter J Ross <pjr@xxxxxxxxxxxxxxx> said:
RFC 3977, from which I quote part of section 10.2, page 101:
That does not permit Google to use UTF-8 in headers; au contraire, it says
not to.
It rightly discourages Google, and the rest of us, from doing so, but
"SHOULD [NOT]" remains different from "MUST [NOT]".
Worse, that RFC relates to NNTP, not to article formats. The
actual rules are the more restrictive of those in RFC 3977 and RFC1036++.
RFC 1036 can be read as forbidding even MIME-encoded headers, which
you presumably don't want to do.
Incidentally, RFC 3977 doesn't recognise any standard for article
formats later than RFC 1036, so your reference to RFC 1036++ is
questionable. "Son-of-RFC-1036" and later drafts have no authority.
So UTF-8 is permitted to the extent that SHOULD and SHOULD NOT are more
permissive than MUST and MUST NOT.
FSVO permitted. Failure to use MUST NOT is not a grant of permission.
RFC 2119 states:
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
I don't think the loophole should be left open, and RFC 3977 certainly
envisages that a future replacement for RFC 1036 MAY close it but, at
present, if Google or anybody else wants to allow 8-bit header fields,
all they have to say is that they've "understood the implications" and
"weighed the case" before departing from the recommendation.
Anyway, I don't think you and I disagree about the fundamentals.
1. There was nothing technically wrong with the post quoted at the
beginning of this thread.
2. Any person or system that sends non-ASCII characters in Usenet
headers without encoding them into ASCII is likely to cause problems,
and should be discouraged from doing so.
All we disagree about is whether we can use the RFCs to support what
ought to be obvious even without consulting the RFCs.
Incidentally, where are your References: headers? Your replies to me
are starting new threads, which they used not to do.
--
PJR :-)
.
- Follow-Ups:
- Re: What is with the From field containing UTF-8 stuff?
- From: Blinky the Shark
- Re: What is with the From field containing UTF-8 stuff?
- References:
- Re: What is with the From field containing UTF-8 stuff?
- From: Shmuel (Seymour J.) Metz
- Re: What is with the From field containing UTF-8 stuff?
- Prev by Date: Re: Update: [slrn] NNTP-Posting-Host whois lookup macro
- Next by Date: Re: Xnews - blocking spammers etc - is it possible?
- Previous by thread: Re: What is with the From field containing UTF-8 stuff?
- Next by thread: Re: What is with the From field containing UTF-8 stuff?
- Index(es):
Relevant Pages
|
