Subject: Sweet Lord, call me on my cell!

From: Alexandra <[email-masked]>
Date: Sun, 31 Jan 2010 10:58:04 -0800 (PST)

Hello my sweet kitty - do you completely forgot about my Russian pussy?
"Come to my site - I have there new photos as well as video from my home web camera - and you have a web camera now?"
I want to talk to you almost live -- and if possible meet.

[ Click here ]

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0U9tsQH055141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Jan 2010 02:55:54 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o0U9tsia055140; Sat, 30 Jan 2010 02:55:54 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from 27.mail-out.ovh.net (27.mail-out.ovh.net [91.121.30.210]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id o0U9tqpU055134 for ; Sat, 30 Jan 2010 02:55:53 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 4211 invoked by uid 503); 30 Jan 2010 09:56:20 -0000
Received: from b7.ovh.net (HELO mail190.ha.ovh.net) (213.186.33.57) by 27.mail-out.ovh.net with SMTP; 30 Jan 2010 09:56:19 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 30 Jan 2010 09:55:51 -0000
Received: from aaubervilliers-151-1-9-10.w83-114.abo.wanadoo.fr (HELO Iulius) ([email-masked]) by ns0.ovh.net with SMTP; 30 Jan 2010 09:55:50 -0000
Message-ID: <8DE48CBBBE4F4FD9A8281CEB8D57090F@Iulius>
From: =?UTF-8?Q?Julien_=C3=89LIE?=
To: "Usefor WG" ,
Subject: UTF-8 newsgroup name feedback
Date: Sat, 30 Jan 2010 10:55:50 +0100
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6002.18005
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005
X-Ovh-Tracer-Id: 154811237497896377
X-Ovh-Remote: 83.114.8.10 (aaubervilliers-151-1-9-10.w83-114.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hi all,

For they who are interested, I have just sent a newgroup
control article for local.test.Ï…Ï„Ï†8 so that you could
retrieve it and eventually process it (changing "local"
to whatever you want):

Note for inn-workers
--------------------
I confirm it works fine with INN provided that we remove
the check for [^a-z0-9+_\-] in a newsgroup name (enforced
by controlchan). I suggest that we remove it in INN 2.5.2.
We can reintegrate a better check with allowed UTF-8 values
in future versions of INN.

Note for USEFOR
---------------
In case someone wants to see what the result is, you can use
news.trigofacile.com on port 119.
The trigofacile.test.Ï…Ï„Ï†8 newsgroup has been created in UTF-8.
It is readable by everyone.

If you want to post, authenticate with user "test" and password
"test".

The group properly shows up in LIST ACTIVE and LIST NEWSGROUPS.

Unfortunately, Windows Mail is unable to post to it... It says
the group does not exist and refuses to send my post.
Well, let's crosspost then to trigofacile.test.Ï…Ï„Ï†8 and trigofacile.test.

And what does Windows Mail send to the server?

Newsgroups: =?UTF-8?Q?trigofacile.test.=CF=85=CF=84=CF=868=2Ctrigofacil?=\r\n
\t=?UTF-8?Q?e.test?=\r\n
Followup-To: =?UTF-8?Q?trigofacile.test.=CF=85=CF=84=CF=868?=\r\n

Gosh, that's not a success at all for Windows Mail :-/

--
Julien Ã‰LIE

Â« Cinq millions et demi de conducteurs franÃ§ais
ont une mauvaise vue. Heureusement, leur nombre diminue
de jour en jour. Â» (Coluche)

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0U9YZMN053852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Jan 2010 02:34:35 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o0U9YZ5t053851; Sat, 30 Jan 2010 02:34:35 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from 27.mail-out.ovh.net (27.mail-out.ovh.net [91.121.30.210]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id o0U9YXHQ053844 for ; Sat, 30 Jan 2010 02:34:34 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 19150 invoked by uid 503); 30 Jan 2010 09:35:00 -0000
Received: from b7.ovh.net (HELO mail190.ha.ovh.net) (213.186.33.57) by 27.mail-out.ovh.net with SMTP; 30 Jan 2010 09:35:00 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 30 Jan 2010 09:34:31 -0000
Received: from aaubervilliers-151-1-9-10.w83-114.abo.wanadoo.fr (HELO Iulius) ([email-masked]) by ns0.ovh.net with SMTP; 30 Jan 2010 09:34:29 -0000
Message-ID: <64D287C0C5AA4A9C9FB13D5BF0ABF168@Iulius>
From: =?UTF-8?Q?Julien_=C3=89LIE?=
To: "Usefor WG"
Subject: Tr: DNews and newsgoups in UTF-8
Date: Sat, 30 Jan 2010 10:34:29 +0100
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6002.18005
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005
X-Ovh-Tracer-Id: 18240985867401690553
X-Ovh-Remote: 83.114.8.10 (aaubervilliers-151-1-9-10.w83-114.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hi all,

I've just asked in fr.usenet.8bits and fr.usenet.forums.evolution whether
we could create in fr.* a testing UTF-8 newsgroup name.

Michel Guillou reports that DNews fails to use such names:

New group {neottia.test.υτφ8}, Modflag {y}, Creator {MG}
Description {Local, pour les tests dans un forum Ã  nom UTF8.}
Group creation failed, check ME feed in newsfeeds.conf and max_groups
setting (examine dnews.log too)

The corresponding newsgroup is:

neottia.test.Ï…Ï„Ï†8

--
Julien Ã‰LIE

Â« Ne crains pas d'avancer lentement, crains seulement de t'arrÃªter. Â» (proverbe
chinois)

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0JN4ShI095089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 16:04:28 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o0JN4SqS095088; Tue, 19 Jan 2010 16:04:28 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from 66.mail-out.ovh.net (66.mail-out.ovh.net [91.121.185.67]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id o0JN4Qn1095080 for ; Tue, 19 Jan 2010 16:04:27 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 7307 invoked by uid 503); 19 Jan 2010 23:02:45 -0000
Received: from 42.mail-out.ovh.net (213.251.189.42) by 66.mail-out.ovh.net with SMTP; 19 Jan 2010 23:02:45 -0000
Received: (qmail 8431 invoked by uid 503); 19 Jan 2010 23:04:44 -0000
Received: from b9.ovh.net (HELO mail416.ha.ovh.net) (213.186.33.59) by 42.mail-out.ovh.net with SMTP; 19 Jan 2010 23:04:44 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 19 Jan 2010 23:04:25 -0000
Received: from aaubervilliers-151-1-66-216.w81-48.abo.wanadoo.fr (HELO Iulius) ([email-masked]) by ns0.ovh.net with SMTP; 19 Jan 2010 23:04:23 -0000
Message-ID: <29384DB80730422893402BE3A77E45ED@Iulius>
From: =?iso-8859-1?Q?Julien_=C9LIE?=
To: "Lisa Dusseault"
Cc: , , , , , , ,
References:
In-Reply-To:
Subject: Re: Errata for RFC 5536 and 5537
Date: Wed, 20 Jan 2010 00:04:27 +0100
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6002.18005
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005
X-Ovh-Tracer-Id: 4212835977094495625
X-Ovh-Remote: 81.48.9.216 (aaubervilliers-151-1-66-216.w81-48.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.500114/N
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hi Lisa,

> I appended your re-correction of the corrected text, rather than
> replace, since you were not the reporter, introduced by "Julian Elie
> suggests the corrected text: ". Since the errata is held for document
> update, the authors of the next version of the document can analyse
> all the suggestions and can surely correct for formatting.

Buy is it a reason for not having errata of quality?

Well, if it is what you want, I can do nothing more.
I'm not going to argue more on that subject on which I have already
spent far too much time.

I will only say that:
* the erratum mentions that I "suggest the corrected text", which is wrong
because it is not my suggestion (the formatting I provided was better);
* the erratum is inconsistent;
* the process is inconsistent (no append for erratum 1787 for instance);
* my first name has been mispelled in the edited text: it is Julien,
and not Julian.

But well, after all, I don't mind. I just wanted to give some help
and review to have proper errata on rfc-editor.org but it appears that
it is not what people expect from rfc-editor.org; so be it that way.

I thought that people reading errata would be more pleased to have
detailed, complete information of good quality about an erratum.

Anyway, thanks for your work on RFCs and errata. I know you are also
writing RFCs (I already read your PATCH method and your guidance about
draft standards). That's great work, and it requires time and energy.
I also understand that editing errata can be exhausting and is not
quite fun.

All the best for the future,

--
Julien ÉLIE

« Ex nihilo nihil. » (Perse)

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0JMMXe3093027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 15:22:33 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o0JMMXlK093026; Tue, 19 Jan 2010 15:22:33 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.149]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0JMMVJc093016 for ; Tue, 19 Jan 2010 15:22:31 -0700 (MST) (envelope-from [email-masked])
Received: by qw-out-1920.google.com with SMTP id 5so69714qwf.28 for ; Tue, 19 Jan 2010 14:22:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=L6u81LwjwgMPoZxwzHbGUmErjzgd7shdDpfh4Im4P8k=; b=nhQhUo1OaNX4zp8YjVtgAa9II5w8r+kE865chtl0GfLlzZOMo/am7+zbRTMiJ75XXe TRcg0zntOoEr/TLxPvQjvVyohXKrcsxlgegRRvJeur2IGTAvI9A75mzP78F0340B/OY3 k4IWUaw2TjW/g6GPStu22FOYP/RS4BlgO0DLI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cOzGawkylfyW5RYdBO10/iOwJDFxdoIMV5NEpiv7y/Fow5msWmY4zEU++Oj+WYsGio 66OPBF9bjUrVCFvUdXtV6UvjsuUF2C2iTgDqHAuUmcObEPWKr/uNEdMrLQc5x3cVC6Vw lbD220rYfIpuNhyucwZyNXRW4cUq6hyJ7LZQc=
MIME-Version: 1.0
Received: by 10.220.125.20 with SMTP id w20mr2463092vcr.2.1263939750493; Tue, 19 Jan 2010 14:22:30 -0800 (PST)
In-Reply-To:
References:
Date: Tue, 19 Jan 2010 14:22:30 -0800
Message-ID:
Subject: Re: Errata for RFC 5536 and 5537
From: Lisa Dusseault
To: =?ISO-8859-1?Q?Julien_=C9LIE?=
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hi Julien,

I appended your re-correction of the corrected text, rather than
replace, since you were not the reporter, introduced by "Julian Elie
suggests the corrected text: ". Since the errata is held for document
update, the authors of the next version of the document can analyse
all the suggestions and can surely correct for formatting.

Lisa

On Tue, Jan 19, 2010 at 1:10 PM, Julien =C9LIE wro=
te:
> Hi Lisa,
>
>> Done. =A0The editorial ones I marked "hold for document update" because
>> the terminology issues won't affect an implementation's correctness,
>> and I do not like making implementers wade through terminology
>> corrections looking for technical errata.
>
> OK, thanks!
>
>
>> 1980 -> it should be reworded as follows, and VERIFIED.
>
> http://www.rfc-editor.org/errata_search.php?eid=3D1980
>
> The correction is inconsistent and wrong.
>
> I do not understand why we have:
>
> ---------------------------------------------------
> Throughout the document, when it says:
>
> (a) =A0Section 3.1, last paragraph:
>
> | =A0 =A0 =A0 =A0... trace headers ...
>
> (b) =A0Section 3.4.4, second paragraph:
>
> | =A0 =A0 =A0 =A0... a References header, ...
>
> (c) =A0Section 3.5, numbered processing steps:
> ---------------------------------------------------
> It should say:
>
> (a) =A0Section 3.1, last paragraph:
>
> | =A0 =A0 =A0 ... trace header fields ...
>
> (b) =A0Section 3.4.4, second paragraph:
>
> | =A0 =A0 =A0 =A0... a References header field, ...
>
> (c) =A0Section 3.5, numbered processing steps:
>
>
> Julian Elie suggests the corrected text:
>
> Corrected Text
> --------------
> (a) =A0Section 3.1, last paragraph:
>
> | =A0 =A0 =A0 ... trace header fields ...
>
> (b) =A0Section 3.4, fourth paragraph:
>
> | =A0 =A0 =A0 ... an Injection-Date header field.
>
> (c) =A0Section 3.4.4, second paragraph:
> ---------------------------------------------------
>
> It does not match the letters (a), (b), (c), etc.
>
>
> I thought that the new original text I suggested was to be put
> instead of the previous original text. =A0And my corrected text
> instead of the previous corrected text. =A0And also my suggestion
> of note. =A0Otherwise, everything is inconsistent.
>
>
> Besides, the original text contains a typo:
>
>
> g) =A0Section 5.2.3, first paragraph:
> (
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0[...] =A0The syntax of
> | =A0its Control header field is:
>
>
>
> And all my corrected text is badly formatted. =A0It was not what
> I suggested at all!
> Missing leading spaces, (d) totally wrong...
>
> Could you please fix it?
>
> Thanks beforehand,
>
> --
> Julien =C9LIE
>
> =AB Ex nihilo nihil. =BB (Perse)
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0JLBvau089617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 14:11:57 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o0JLBv3B089616; Tue, 19 Jan 2010 14:11:57 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from 66.mail-out.ovh.net (66.mail-out.ovh.net [91.121.185.67]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id o0JLBspZ089607 for ; Tue, 19 Jan 2010 14:11:55 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 20165 invoked by uid 503); 19 Jan 2010 21:10:12 -0000
Received: from 42.mail-out.ovh.net (213.251.189.42) by 66.mail-out.ovh.net with SMTP; 19 Jan 2010 21:10:12 -0000
Received: (qmail 19808 invoked by uid 503); 19 Jan 2010 21:10:55 -0000
Received: from b9.ovh.net (HELO mail416.ha.ovh.net) (213.186.33.59) by 42.mail-out.ovh.net with SMTP; 19 Jan 2010 21:10:55 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 19 Jan 2010 21:10:34 -0000
Received: from aaubervilliers-151-1-66-216.w81-48.abo.wanadoo.fr (HELO Iulius) ([email-masked]) by ns0.ovh.net with SMTP; 19 Jan 2010 21:10:32 -0000
Message-ID:
From: =?iso-8859-1?Q?Julien_=C9LIE?=
To: "Lisa Dusseault"
Cc: , , , , , , ,
References:
In-Reply-To:
Subject: Re: Errata for RFC 5536 and 5537
Date: Tue, 19 Jan 2010 22:10:35 +0100
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6002.18005
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005
X-Ovh-Tracer-Id: 2290080411501067657
X-Ovh-Remote: 81.48.9.216 (aaubervilliers-151-1-66-216.w81-48.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hi Lisa,

> Done. The editorial ones I marked "hold for document update" because
> the terminology issues won't affect an implementation's correctness,
> and I do not like making implementers wade through terminology
> corrections looking for technical errata.

OK, thanks!

> 1980 -> it should be reworded as follows, and VERIFIED.

http://www.rfc-editor.org/errata_search.php?eid=1980

The correction is inconsistent and wrong.

I do not understand why we have:

---------------------------------------------------
Throughout the document, when it says:

(a) Section 3.1, last paragraph:

| ... trace headers ...

(b) Section 3.4.4, second paragraph:

| ... a References header, ...

(c) Section 3.5, numbered processing steps:
---------------------------------------------------
It should say:

(a) Section 3.1, last paragraph:

| ... trace header fields ...

(b) Section 3.4.4, second paragraph:

| ... a References header field, ...

(c) Section 3.5, numbered processing steps:

Julian Elie suggests the corrected text:

Corrected Text
--------------
(a) Section 3.1, last paragraph:

| ... trace header fields ...

(b) Section 3.4, fourth paragraph:

| ... an Injection-Date header field.

(c) Section 3.4.4, second paragraph:
---------------------------------------------------

It does not match the letters (a), (b), (c), etc.

I thought that the new original text I suggested was to be put
instead of the previous original text. And my corrected text
instead of the previous corrected text. And also my suggestion
of note. Otherwise, everything is inconsistent.

Besides, the original text contains a typo:

g) Section 5.2.3, first paragraph:
(
[...] The syntax of
| its Control header field is:

And all my corrected text is badly formatted. It was not what
I suggested at all!
Missing leading spaces, (d) totally wrong...

Could you please fix it?

Thanks beforehand,

--
Julien ÉLIE

« Ex nihilo nihil. » (Perse)

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0JKZ8pr087536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2010 13:35:08 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o0JKZ8At087535; Tue, 19 Jan 2010 13:35:08 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-qy0-f190.google.com (mail-qy0-f190.google.com [209.85.221.190]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0JKZ5nU087529 for ; Tue, 19 Jan 2010 13:35:05 -0700 (MST) (envelope-from [email-masked])
Received: by qyk28 with SMTP id 28so2804260qyk.28 for ; Tue, 19 Jan 2010 12:35:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jfm1lP6OT+72FkXsg3AtJlPHkVFAhNZ6V3BNHF1bdx4=; b=jwV0mYkWVao6ls5dxxoVM16nZ0n9ZWr3k00RNruSBi5VKlH1IfPrePXFd53tPPWMcE JE5K1Z8gOnaVzmXhjM2Xhsnvt7z27BwiA5K8ZkXSBKaY3LF7oEYQZ+ubca7/BP9CHwOx FYa11d32E5iOGw/WLmigA2jUoQ3++GP4J6pI8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fLwGVv+VdD9O9h9FK6nEvmwqruP2gGYm91tvBAhkKp/bkGiGLP70x6iitWpJ6Q8KQv jgNOcSU1vYBvC1J0dfNBI9dR5w3bqlq5pGPpnMcL3JCgMRpFmM+w12T/YwLw6fR6nBHa UPgigPRG5bA9XSW8ZB9HilpcrD+37Lg85kCsM=
MIME-Version: 1.0
Received: by 10.220.123.12 with SMTP id n12mr406525vcr.45.1263933303964; Tue, 19 Jan 2010 12:35:03 -0800 (PST)
In-Reply-To:
References:
Date: Tue, 19 Jan 2010 12:35:03 -0800
Message-ID:
Subject: Re: Errata for RFC 5536 and 5537
From: Lisa Dusseault
To: =?ISO-8859-1?Q?Julien_=C9LIE?=
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Done. The editorial ones I marked "hold for document update" because
the terminology issues won't affect an implementation's correctness,
and I do not like making implementers wade through terminology
corrections looking for technical errata.

Thanks,
Lisa

On Fri, Jan 15, 2010 at 2:55 PM, Julien =C9LIE wro=
te:
> Hi,
>
> According to previous discussion on the mailing-list, I reckon that
> the statuses of current open errata for RFCs 5536 and 5537 are:
>
> 1979 -> still no validation, though I believe it should be VERIFIED.
> =A0 =A0 =A0 Can someone confirm?
>
> 1980 -> it should be reworded as follows, and VERIFIED.
>
> 1981 -> it should be VERIFIED.
>
> 1982 -> I don't know; the original text is right and reads better.
> =A0 =A0 =A0 Should it be VERIFIED or REJECTED? =A0(with a note added to
> =A0 =A0 =A0 say that both forms are correct English)
>
> 1983 -> it should be VERIFIED.
>
> 1993 -> it should be VERIFIED.
>
>
> --
> Julien
>
>
> -----------------------------------------------------------------------
> RFC 5537 - Erratum 1980
> -----------------------------------------------------------------------
>
> It should be VERIFIED.
>
> The following sections should be changed (with line breaks removed
> in the notes section only, because they are otherwise put at wrong
> places in the web version):
>
>
> Original Text
> -------------
> (a) =A0Section 3.1, last paragraph:
>
> | =A0 =A0 =A0 ... trace headers ...
>
> (b) =A0Section 3.4, fourth paragraph:
>
> | =A0 =A0 =A0 ... an Injection-Date header.
>
> (c) =A0Section 3.4.4, second paragraph:
>
> | =A0 =A0 =A0 ... a References header, ...
>
> (d) =A0Section 3.5, numbered processing steps:
> =A0 =A0 4. =A0[...]
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0... in the Newsgroups
> | =A0 =A0 =A0 header is valid.
>
> =A0 [...]
>
> =A0 6. =A0[...]
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[...] =A0It
> =A0 =A0 =A0 MAY add other header fields not already provided by the poste=
r,
> =A0 =A0 =A0 but injecting agents are encouraged to use the Injection-Info
> | =A0 =A0 =A0 header for such information and to minimize the addition of
> | =A0 =A0 =A0 other headers. =A0[...]
> =A0| =A0 7. =A0If the Newsgroups header contains one or more moderated gr=
oups
> =A0 =A0 =A0 and the proto-article does not contain an Approved header fie=
ld,
> =A0 =A0 =A0 the injecting agent MUST either forward it to a moderator as
> =A0 =A0 =A0 specified in Section 3.5.1 or, if that is not possible, rejec=
t
> =A0 =A0 =A0 it. =A0This forwarding MUST be done after adding the Message-=
ID
> | =A0 =A0 =A0 and Date headers if required, and before adding the Injecti=
on-
> | =A0 =A0 =A0 Info and Injection-Date headers.
> =A0 =A0 =A0 =A0(e) =A0Section 3.6, first paragraph
>
> | =A0 =A0 =A0 ... forgery of Path and Injection-Info headers, ...
>
> (f) =A0Section 5.2.1, first paragraph:
>
> =A0The newgroup control message requests that the specified group be
> =A0created or, if already existing, that its moderation status or
> | =A0description be changed. =A0The syntax of its Control header field is=
:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0control-command =A0 =A0 =3D/ Newgroup-comm=
and
> =A0 =A0 =A0 =A0Newgroup-command =A0 =A0=3D "newgroup" Newgroup-arguments
> =A0 =A0 =A0 =A0[...]
>
> (g) =A0Section 5.2.2, first paragraph:
>
> =A0The rmgroup control message requests that the specified group be
> =A0removed from a news server's list of valid groups. =A0The syntax of it=
s
> | =A0Control header field is:
>
> (h) =A0Section 5.2.3, first paragraph:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0[...] =A0The syntax of
> | =A0its Control header field is:
>
> (i) =A0Section 5.2.3, last paragraph:
>
> =A0The body of the message is an entity of type application/
> =A0news-checkgroups. =A0It SHOULD be declared as such with appropriate
> | =A0MIME headers, but news servers SHOULD interpret checkgroups messages
> | =A0that lack the appropriate MIME headers as if the body were of type
> =A0application/news-checkgroups for backward compatibility.
>
> (j) =A0Section 5.3, first paragraph:
>
> =A0The cancel control message requests that a target article be
> =A0withdrawn from circulation and access. =A0The syntax of its Control
> | =A0header field is:
>
> (k) =A0Section 5.5, second paragraph:
>
> =A0ihave and sendme control messages share similar syntax for their
> | =A0Control header fields and bodies:
>
> (l) =A0Appendix A, first bullet:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 [...] =A0Folding of the
> | =A0 =A0 Path header is permitted.
>
>
>
>
>
> Corrected Text
> --------------
> (a) =A0Section 3.1, last paragraph:
>
> | =A0 =A0 =A0 ... trace header fields ...
>
> (b) =A0Section 3.4, fourth paragraph:
>
> | =A0 =A0 =A0 ... an Injection-Date header field.
>
> (c) =A0Section 3.4.4, second paragraph:
>
> | =A0 =A0 =A0 ... a References header field, ...
>
> (d) =A0Section 3.5, numbered processing steps:
>
> =A0 4. =A0[...]
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0... in the Newsgroups
> | =A0 =A0 =A0 header field is valid.
>
> =A0 [...]
>
> =A0 6. =A0[...]
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[...] =A0It
> =A0 =A0 =A0 MAY add other header fields not already provided by the poste=
r,
> =A0 =A0 =A0 but injecting agents are encouraged to use the Injection-Info
> | =A0 =A0 =A0 header field for such information and to minimize the addit=
ion |
> =A0 of other header fields. =A0[...]
> =A0| =A07. =A0 If the Newsgroups header field contains one or more modera=
ted
> =A0 =A0 =A0 groups and the proto-article does not contain an Approved hea=
der
> =A0 =A0 =A0 field, the injecting agent MUST either forward it to a modera=
tor
> =A0 =A0 =A0 as specified in Section 3.5.1 or, if that is not possible,
> =A0 =A0 =A0 reject it. =A0This forwarding MUST be done after adding the
> | =A0 =A0 =A0 Message-ID and Date header fields if required, and before a=
dding
> | =A0 =A0 =A0 the Injection-Info and Injection-Date header fields.
>
> (e) =A0Section 3.6, first paragraph
>
> | =A0 =A0 =A0 ... forgery of Path and Injection-Info header fields, ...
>
> (f) =A0Section 5.2.1, first paragraph:
>
> =A0The newgroup control message requests that the specified group be
> =A0created or, if already existing, that its moderation status or
> | =A0description be changed. =A0The syntax of its Control header field
> | =A0body is:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0control-command =A0 =A0 =3D/ Newgroup-comm=
and
> =A0 =A0 =A0 =A0Newgroup-command =A0 =A0=3D "newgroup" Newgroup-arguments
> =A0 =A0 =A0 =A0[...]
>
> (g) =A0Section 5.2.2, first paragraph:
>
> =A0The rmgroup control message requests that the specified group be
> =A0removed from a news server's list of valid groups. =A0The syntax of it=
s
> | =A0Control header field body is:
>
> (h) =A0Section 5.2.3, first paragraph:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0[...] =A0The syntax of
> | =A0its Control header field value is:
>
> (i) =A0Section 5.2.3, last paragraph:
>
> =A0The body of the message is an entity of type application/
> =A0news-checkgroups. =A0It SHOULD be declared as such with appropriate
> | =A0MIME header fields, but news servers SHOULD interpret checkgroups
> | =A0messages that lack the appropriate MIME header fields as if the body
> =A0were of type application/news-checkgroups for backward compatibility.
>
> (j) =A0Section 5.3, first paragraph:
>
> =A0The cancel control message requests that a target article be
> =A0withdrawn from circulation and access. =A0The syntax of its Control
> | =A0header field body is:
>
> (k) =A0Section 5.5, second paragraph:
>
> =A0ihave and sendme control messages share similar syntax for their
> | =A0Control header field bodies and message bodies:
>
> (l) =A0Appendix A, first bullet:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 [...] =A0Folding of the
> | =A0 =A0 Path header field is permitted.
>
>
> Notes
> -----
> Rationale:
> Contrary to its companion document, RFC 5536, this RFC mixes precise
> IETF terminology for protocol elements and colloquial abuse of it in
> various places. =A0For clarity and consistency, it should also
> inequivocally make use of the standard terminology; the fields
> of the "header" that a protocol layer or sub-layer adds to its
> payload are "header fields", not "headers" in itself.
> Similarly, denoting as "header field" a "header field body" is
> confusing -- items (f), (g), (h), (j), and (k) above.
>
>

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0GHGcss012506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Jan 2010 10:16:38 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o0GHGcZ8012505; Sat, 16 Jan 2010 10:16:38 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from 27.mail-out.ovh.net (27.mail-out.ovh.net [91.121.30.210]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id o0GHGaA1012495 for ; Sat, 16 Jan 2010 10:16:37 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 5484 invoked by uid 503); 16 Jan 2010 18:26:26 -0000
Received: from b9.ovh.net (HELO mail425.ha.ovh.net) (213.186.33.59) by 27.mail-out.ovh.net with SMTP; 16 Jan 2010 18:26:26 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 16 Jan 2010 17:16:35 -0000
Received: from aaubervilliers-151-1-66-216.w81-48.abo.wanadoo.fr (HELO Iulius) ([email-masked]) by ns0.ovh.net with SMTP; 16 Jan 2010 17:16:34 -0000
Message-ID:
From: =?UTF-8?Q?Julien_=C3=89LIE?=
To: "Usefor WG"
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Subject: Re: Number of occurrences of headers
Date: Sat, 16 Jan 2010 18:16:33 +0100
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6002.18005
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005
X-Ovh-Tracer-Id: 17614141094422052281
X-Ovh-Remote: 81.48.9.216 (aaubervilliers-151-1-66-216.w81-48.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

>> As far as I understand, every field defined in these RFCs can be used 0
>> or 1 time in an article, except for Comments: and Original-Sender:
>> which can be used an unlimited number of times.
>
> I haven't checked RFC 5322 for the headers defined there, but that sounds
> right.
>
>> Regarding Original-Sender:, isn't one time enough?
>
> Normally, yes, but it wouldn't be in pathological gatewaying situations
> where an article was gatewayed multiple times.

OK, thanks Russ. I have just implemented the required change in the
latest development version of INN so as not to mention these two headers
(otherwise, multiple occurrences are not allowed).

--
Julien Ã‰LIE

Â« Rien ni personne n'a tout Ã  fait tort : mÃªme une horloge
arrÃªtÃ©e a raison deux fois par jour. Â» (John Steinbeck)

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0FMtrLY046775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Jan 2010 15:55:53 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o0FMtrDX046774; Fri, 15 Jan 2010 15:55:53 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from 30.mail-out.ovh.net (30.mail-out.ovh.net [213.186.62.213]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id o0FMtm8i046765 for ; Fri, 15 Jan 2010 15:55:49 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 32199 invoked by uid 503); 15 Jan 2010 22:55:34 -0000
Received: from b9.ovh.net (HELO mail623.ha.ovh.net) (213.186.33.59) by 30.mail-out.ovh.net with SMTP; 15 Jan 2010 22:55:34 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 15 Jan 2010 22:56:14 -0000
Received: from aaubervilliers-151-1-66-216.w81-48.abo.wanadoo.fr (HELO Iulius) ([email-masked]) by ns0.ovh.net with SMTP; 15 Jan 2010 22:56:13 -0000
Message-ID:
From: =?iso-8859-15?Q?Julien_=C9LIE?=
To: , , , , ,
Cc: , ,
Subject: Errata for RFC 5536 and 5537
Date: Fri, 15 Jan 2010 23:55:44 +0100
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-15"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6002.18005
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005
X-Ovh-Tracer-Id: 17477344255869189504
X-Ovh-Remote: 81.48.9.216 (aaubervilliers-151-1-66-216.w81-48.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hi,

According to previous discussion on the mailing-list, I reckon that
the statuses of current open errata for RFCs 5536 and 5537 are:

1979 -> still no validation, though I believe it should be VERIFIED.
Can someone confirm?

1980 -> it should be reworded as follows, and VERIFIED.

1981 -> it should be VERIFIED.

1982 -> I don't know; the original text is right and reads better.
Should it be VERIFIED or REJECTED? (with a note added to
say that both forms are correct English)

1983 -> it should be VERIFIED.

1993 -> it should be VERIFIED.

--
Julien

-----------------------------------------------------------------------
RFC 5537 - Erratum 1980
-----------------------------------------------------------------------

It should be VERIFIED.

The following sections should be changed (with line breaks removed
in the notes section only, because they are otherwise put at wrong
places in the web version):

Original Text
-------------
(a) Section 3.1, last paragraph:

| ... trace headers ...

(b) Section 3.4, fourth paragraph:

| ... an Injection-Date header.

(c) Section 3.4.4, second paragraph:

| ... a References header, ...

(d) Section 3.5, numbered processing steps:

4. [...]
... in the Newsgroups
| header is valid.

[...]

6. [...]
[...] It
MAY add other header fields not already provided by the poster,
but injecting agents are encouraged to use the Injection-Info
| header for such information and to minimize the addition of
| other headers. [...]

| 7. If the Newsgroups header contains one or more moderated groups
and the proto-article does not contain an Approved header field,
the injecting agent MUST either forward it to a moderator as
specified in Section 3.5.1 or, if that is not possible, reject
it. This forwarding MUST be done after adding the Message-ID
| and Date headers if required, and before adding the Injection-
| Info and Injection-Date headers.

(e) Section 3.6, first paragraph

| ... forgery of Path and Injection-Info headers, ...

(f) Section 5.2.1, first paragraph:

The newgroup control message requests that the specified group be
created or, if already existing, that its moderation status or
| description be changed. The syntax of its Control header field is:

control-command =/ Newgroup-command
Newgroup-command = "newgroup" Newgroup-arguments
[...]

(g) Section 5.2.2, first paragraph:

The rmgroup control message requests that the specified group be
removed from a news server's list of valid groups. The syntax of its
| Control header field is:

(h) Section 5.2.3, first paragraph:

[...] The syntax of
| its Control header field is:

(i) Section 5.2.3, last paragraph:

The body of the message is an entity of type application/
news-checkgroups. It SHOULD be declared as such with appropriate
| MIME headers, but news servers SHOULD interpret checkgroups messages
| that lack the appropriate MIME headers as if the body were of type
application/news-checkgroups for backward compatibility.

(j) Section 5.3, first paragraph:

The cancel control message requests that a target article be
withdrawn from circulation and access. The syntax of its Control
| header field is:

(k) Section 5.5, second paragraph:

ihave and sendme control messages share similar syntax for their
| Control header fields and bodies:

(l) Appendix A, first bullet:

[...] Folding of the
| Path header is permitted.

Corrected Text
--------------
(a) Section 3.1, last paragraph:

| ... trace header fields ...

(b) Section 3.4, fourth paragraph:

| ... an Injection-Date header field.

(c) Section 3.4.4, second paragraph:

| ... a References header field, ...

(d) Section 3.5, numbered processing steps:

4. [...]
... in the Newsgroups
| header field is valid.

[...]

6. [...]
[...] It
MAY add other header fields not already provided by the poster,
but injecting agents are encouraged to use the Injection-Info
| header field for such information and to minimize the addition
| of other header fields. [...]

| 7. If the Newsgroups header field contains one or more moderated
groups and the proto-article does not contain an Approved header
field, the injecting agent MUST either forward it to a moderator
as specified in Section 3.5.1 or, if that is not possible,
reject it. This forwarding MUST be done after adding the
| Message-ID and Date header fields if required, and before adding
| the Injection-Info and Injection-Date header fields.

(e) Section 3.6, first paragraph

| ... forgery of Path and Injection-Info header fields, ...

(f) Section 5.2.1, first paragraph:

The newgroup control message requests that the specified group be
created or, if already existing, that its moderation status or
| description be changed. The syntax of its Control header field
| body is:

control-command =/ Newgroup-command
Newgroup-command = "newgroup" Newgroup-arguments
[...]

(g) Section 5.2.2, first paragraph:

The rmgroup control message requests that the specified group be
removed from a news server's list of valid groups. The syntax of its
| Control header field body is:

(h) Section 5.2.3, first paragraph:

[...] The syntax of
| its Control header field value is:

(i) Section 5.2.3, last paragraph:

The body of the message is an entity of type application/
news-checkgroups. It SHOULD be declared as such with appropriate
| MIME header fields, but news servers SHOULD interpret checkgroups
| messages that lack the appropriate MIME header fields as if the body
were of type application/news-checkgroups for backward compatibility.

(j) Section 5.3, first paragraph:

The cancel control message requests that a target article be
withdrawn from circulation and access. The syntax of its Control
| header field body is:

(k) Section 5.5, second paragraph:

ihave and sendme control messages share similar syntax for their
| Control header field bodies and message bodies:

(l) Appendix A, first bullet:

[...] Folding of the
| Path header field is permitted.

Notes
-----
Rationale:
Contrary to its companion document, RFC 5536, this RFC mixes precise
IETF terminology for protocol elements and colloquial abuse of it in
various places. For clarity and consistency, it should also
inequivocally make use of the standard terminology; the fields
of the "header" that a protocol layer or sub-layer adds to its
payload are "header fields", not "headers" in itself.
Similarly, denoting as "header field" a "header field body" is
confusing -- items (f), (g), (h), (j), and (k) above.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0BMIDrs067908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jan 2010 15:18:13 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o0BMIDo0067907; Mon, 11 Jan 2010 15:18:13 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from 42.mail-out.ovh.net (42.mail-out.ovh.net [213.251.189.42]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id o0BMIBNW067901 for ; Mon, 11 Jan 2010 15:18:12 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 15932 invoked by uid 503); 11 Jan 2010 22:18:28 -0000
Received: from b9.ovh.net (HELO mail440.ha.ovh.net) (213.186.33.59) by 42.mail-out.ovh.net with SMTP; 11 Jan 2010 22:18:28 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 11 Jan 2010 22:18:10 -0000
Received: from aaubervilliers-151-1-8-94.w83-114.abo.wanadoo.fr (HELO Iulius) ([email-masked]) by ns0.ovh.net with SMTP; 11 Jan 2010 22:18:08 -0000
Message-ID: <391DD6216B904DAF8D4EB50AAE2027DB@Iulius>
From: =?iso-8859-1?Q?Julien_=C9LIE?=
To: "Usefor WG"
References: <3F6C660203CE4751A068B86CD382864E@Iulius> <[email-masked]> <7FDA90361E9E4C85A22D79FA9014E5C0@Iulius>
In-Reply-To:
Subject: Re: Parsing the Injection-Info: header field
Date: Mon, 11 Jan 2010 23:18:10 +0100
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6002.18005
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005
X-Ovh-Tracer-Id: 11790423825214275001
X-Ovh-Remote: 83.114.7.94 (aaubervilliers-151-1-8-94.w83-114.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hi Charles,

>>I understand that RFC 2045 now extends the syntax of RFC 5322 (instead
>>of RFC 822).
>
> How can that possibly be so, since it was written umpteen years earlier?
> Anything that "extended RFC 5322 would have to be written _after_ that.

A misunderstanding of mine.
I thought that if an article was to comply with RFC 5322, then the syntax
of extended fields (defined by MIME), was to be restricted to what RFC 5322
allows. But that does not seem to be the case.

Thanks, Antti-Juhani and Charles, for having explained what should be
done for MIME.

> RFC 2045, and its relations, provides syntax for many new header fields.
> From reading RFC 2045 and RFC 822, you can deduce *exactly* where CFWS is
> allowed. If RFC were to be re-written (a highly desirable thing BTW), then
> if would redefine its syntax with explicite CFWS, presumably in exactly
> the same places as now, unless it chose to declare some of them to be
> obsolete as 5322 has done.
>
> It is clear that, according to RFC 2045, CFWS is allowed on both sides of
> the '=' in a (and why shouldn't it?). And, just to make sure, I
> checked my interpretation with Keith Moore before writing the original
> version of the paragraph which you quoted.

Yeah, no problem. Sorry for the disturbance of my thread.

For what it is worth, I also had an answer from the YAM group meanwhile:

http://www.ietf.org/mail-archive/web/yam/current/msg00279.html

[Ned Freed]
"RFCs 2045 and 2046 were written before DRUMS and RFCs
2821/2822/5321/5322 and therefore used the syntactic convensions of RFC 822,
where LWSP is implicitly allowed between tokens. The fact that DRUMS opted to
make the places where LWSP is allowed explicit rather than implicit doesn't
change the syntax rules for 2045 and 2046 in any way. shape or form.

I also note that had RFC 5322 had any effect on MIME syntax, the header of the
document would show that it updates RFCs 2045 and 2046. The document header
says no such thing.

P.S. When revised MIME specifications come out they will probably switch to the
explicit LWSP approach since it seems that's the preferred way to do it now."

--
Julien ÉLIE

« Cela n'a rien de remarquable. Il suffit d'appuyer
sur la bonne touche au bon moment et l'instrument
joue tout seul. » (J.-S. Bach)

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0BHCD0c048887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Jan 2010 10:12:14 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o0BHCBiS048885; Mon, 11 Jan 2010 10:12:11 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from v-smtp-auth-relay-1.gradwell.net (v-smtp-auth-relay-1.gradwell.net [79.135.125.40]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0BHC77P048875 for ; Mon, 11 Jan 2010 10:12:10 -0700 (MST) (envelope-from [email-masked])
Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3$clerew#man$ac$uk) by v-smtp-auth-relay-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4b4b5be5.3c64.358 for [email-masked]; Mon, 11 Jan 2010 17:12:05 +0000 (envelope-sender )
Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id o0BHC28j028339 for ; Mon, 11 Jan 2010 17:12:02 GMT
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id o0BHC1Ex028334 for [email-masked]; Mon, 11 Jan 2010 17:12:01 GMT
To: [email-masked]
Xref: clerew local.usefor:25226
Path: clerew!chl
From: "Charles Lindsey"
Subject: Re: Parsing the Injection-Info: header field
Content-Type: text/plain; charset=iso-8859-1
Message-ID:
Content-Transfer-Encoding: 8bit
X-Newsreader: NN version 6.5.2 (NOV)
References: <3F6C660203CE4751A068B86CD382864E@Iulius> <[email-masked]> <7FDA90361E9E4C85A22D79FA9014E5C0@Iulius>
Mime-Version: 1.0
Date: Mon, 11 Jan 2010 13:02:37 GMT
Lines: 30
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

In <7FDA90361E9E4C85A22D79FA9014E5C0@Iulius> Julien ÉLIE writes:

>I understand that RFC 2045 now extends the syntax of RFC 5322 (instead
>of RFC 822).

How can that possibly be so, since it was written umpteen years earlier?
Anything that "extended RFC 5322 would have to be written _after_ that.

RFC 2045, and its relations, provides syntax for many new header fields.
>From reading RFC 2045 and RFC 822, you can deduce *exactly* where CFWS is
allowed. If RFC were to be re-written (a highly desirable thing BTW), then
if would redefine its syntax with explicite CFWS, presumably in exactly
the same places as now, unless it chose to declare some of them to be
obsolete as 5322 has done.

It is clear that, according to RFC 2045, CFWS is allowed on both sides of
the '=' in a (and why shouldn't it?). And, just to make sure, I
checked my interpretation with Keith Moore before writing the original
version of the paragraph which you quoted.

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked] Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0B6sDqO004940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Jan 2010 23:54:14 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o0B6sD6v004939; Sun, 10 Jan 2010 23:54:13 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from flowerpot.kaijanaho.fi (flowerpot.kaijanaho.fi [80.68.88.155]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0B6sAk2004928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 10 Jan 2010 23:54:12 -0700 (MST) (envelope-from [email-masked])
Received: from kukkaseppele.kaijanaho.fi (a91-156-170-97.elisa-laajakaista.fi [91.156.170.97]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ajk) by flowerpot.kaijanaho.fi (Postfix) with ESMTPSA id 317BA29000B for ; Mon, 11 Jan 2010 08:54:08 +0200 (EET)
Received: by kukkaseppele.kaijanaho.fi (Postfix, from userid 1000) id E2D3F85422E; Mon, 11 Jan 2010 08:54:07 +0200 (EET)
Date: Mon, 11 Jan 2010 08:54:07 +0200
From: Antti-Juhani Kaijanaho
To: Usefor WG
Subject: Re: Parsing the Injection-Info: header field
Message-ID: <[email-masked]>
References: <3F6C660203CE4751A068B86CD382864E@Iulius> <[email-masked]> <7FDA90361E9E4C85A22D79FA9014E5C0@Iulius> <[email-masked]> <2D103F28D3464F1889E46392A914CF05@Iulius>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2D103F28D3464F1889E46392A914CF05@Iulius>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Sun, Jan 10, 2010 at 04:10:03PM +0100, Julien ÉLIE wrote:
>
> Hi Antti-Juhani,
>
> >>I understand that RFC 2045 now extends the syntax of RFC 5322 (instead
> >>of RFC 822).
> >
> >That interpretation would mean that suddenly CFWS beciame forbidden in MIME
> >constructs when RFC 2822 was published. I don't think that was the intent,
> >especially when "those mechanisms are outside of the scope".
>
> CFWS is not forbidden by RFC 2822/5322. It just became obsolete syntax:

On RFC 822, and in specifications based on it, CFWS is *implicitly allowed* in
structured field bodies. That means that in such specifications, CFWS was not
included in the grammar, but it still was allowed. What 2822 did was, among
other things, reweite the syntax to make CFWS explicit.

Thus, if we are to believe, as you argue, that all 822-based specifications
(and specifically the MIME specifications) became 2822-based when 2822 was
accepted, then CFWS that was implicitly allowed under 822 rules became suddenly
forbidden (since no CFWS constructs or obs- productions magically appear in old
specs), not just obsolete.

For example, in RFC 2045:

content := "Content-Type" ":" type "/" subtype
*(";" parameter)

Under 822 rules, CFWS is implicitly allowed between all the symbols after ":".
Under 2822 rules, no CFWS is allowed here (even as obsolete syntax), since no
CFWS symbol, or an obs-content symbol, is included in this production (and,
equivalently, in the productions of "type", "subtype" and "parameter").

> 4. Obsolete Syntax

I know; it's also irrelevant here.

> It is normal that an RFC-5322-compliant article does not use obsolete
> syntax.

I don't have a problem with not using obsolete syntax. My point is that
pre-2822 specs effectively used a different grammar formalism than post-2822
specs, and trying to say "just use 2822 rules" is doomed to fail. The specs,
and their grammar, need a rewrite.

--
Antti-Juhani Kaijanaho, Jyväskylä, Finland
http://antti-juhani.kaijanaho.fi/newblog/
http://www.flickr.com/photos/antti-juhani/

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0AFAFtN057097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Jan 2010 08:10:15 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o0AFAD9C057095; Sun, 10 Jan 2010 08:10:13 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from 27.mail-out.ovh.net (27.mail-out.ovh.net [91.121.30.210]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id o0AFA4aX057087 for ; Sun, 10 Jan 2010 08:10:05 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 2381 invoked by uid 503); 10 Jan 2010 16:15:21 -0000
Received: from b6.ovh.net (HELO mail93.ha.ovh.net) (213.186.33.56) by 27.mail-out.ovh.net with SMTP; 10 Jan 2010 16:15:21 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 10 Jan 2010 15:10:03 -0000
Received: from aaubervilliers-151-1-8-94.w83-114.abo.wanadoo.fr (HELO Iulius) ([email-masked]) by ns0.ovh.net with SMTP; 10 Jan 2010 15:10:01 -0000
Message-ID: <2D103F28D3464F1889E46392A914CF05@Iulius>
From: =?iso-8859-1?Q?Julien_=C9LIE?=
To: "Usefor WG"
References: <3F6C660203CE4751A068B86CD382864E@Iulius> <[email-masked]> <7FDA90361E9E4C85A22D79FA9014E5C0@Iulius> <[email-masked]>
In-Reply-To: <[email-masked]>
Subject: Re: Parsing the Injection-Info: header field
Date: Sun, 10 Jan 2010 16:10:03 +0100
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6002.18005
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005
X-Ovh-Tracer-Id: 17134226259348028857
X-Ovh-Remote: 83.114.7.94 (aaubervilliers-151-1-8-94.w83-114.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hi Antti-Juhani,

>> I understand that RFC 2045 now extends the syntax of RFC 5322 (instead
>> of RFC 822).
>
> That interpretation would mean that suddenly CFWS beciame forbidden in MIME
> constructs when RFC 2822 was published. I don't think that was the intent,
> especially when "those mechanisms are outside of the scope".

CFWS is not forbidden by RFC 2822/5322. It just became obsolete syntax:

4. Obsolete Syntax

Earlier versions of this specification allowed for different (usually
more liberal) syntax than is allowed in this version.

[...]

Though these syntactic
forms MUST NOT be generated according to the grammar in section 3,
they MUST be accepted and parsed by a conformant receiver.

[...]

One important difference between the obsolete (interpreting) and the
current (generating) syntax is that in structured header field bodies
(i.e., between the colon and the CRLF of any structured header
field), white space characters, including folding white space, and
comments could be freely inserted between any syntactic tokens. This
allowed many complex forms that have proven difficult for some
implementations to parse.

That's why I find weird that RFC 5536 still encourages an obsolete syntax
(with the posting-host example) that MUST NOT be generated.

I believe the interpretation of the fact that RFC 2045 now extends the
syntax of RFC 5322 is that:

* for RFC-5322-compliant implementation, RFC 2045 MUST comply with the
general syntax of RFC 5322;

* for RFC-822-compliant implementation, RFC 2045 uses the general syntax
described in RFC 822.

> That paragraph is a bit unfortunately worded, though.

I don't think so.
It is normal that an RFC-5322-compliant article does not use obsolete
syntax. That's what RFC 5322 mentions: if MIME is to be used in compliance
with RFC 5322, then the allowed syntax is restricted to the one of RFC 5322.

I'm trying to write to the IETF YAM group to ask, but I don't manage to
(the same way I still do not manage to write to the W3C URI group!).

--
Julien ÉLIE

« Rubor, tumor, dolor, calor et functio laesa. »

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o09CMHPj079294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Jan 2010 05:22:18 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o09CMFKw079293; Sat, 9 Jan 2010 05:22:15 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from flowerpot.kaijanaho.fi (flowerpot.kaijanaho.fi [80.68.88.155]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o09CMCOP079286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 9 Jan 2010 05:22:14 -0700 (MST) (envelope-from [email-masked])
Received: from kukkaseppele.kaijanaho.fi (a91-156-170-97.elisa-laajakaista.fi [91.156.170.97]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ajk) by flowerpot.kaijanaho.fi (Postfix) with ESMTPSA id C5A8629000B for ; Sat, 9 Jan 2010 14:22:10 +0200 (EET)
Received: by kukkaseppele.kaijanaho.fi (Postfix, from userid 1000) id B519C85408F; Sat, 9 Jan 2010 14:22:10 +0200 (EET)
Date: Sat, 9 Jan 2010 14:22:10 +0200
From: Antti-Juhani Kaijanaho
To: Usefor WG
Subject: Re: Parsing the Injection-Info: header field
Message-ID: <[email-masked]>
References: <3F6C660203CE4751A068B86CD382864E@Iulius> <[email-masked]> <7FDA90361E9E4C85A22D79FA9014E5C0@Iulius>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <7FDA90361E9E4C85A22D79FA9014E5C0@Iulius>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Sat, Jan 09, 2010 at 11:22:45AM +0100, Julien ÉLIE wrote:
> Yet, RFC 5322 mentions in its introduction:
>
> This document specifies a syntax only for text messages. In
> particular, it makes no provision for the transmission of images,
> audio, or other sorts of structured data in electronic mail messages.
> There are several extensions published, such as the MIME document
> series ([RFC2045], [RFC2046], [RFC2049]), which describe mechanisms
> for the transmission of such data through electronic mail, either by
> extending the syntax provided here or by structuring such messages to
> conform to this syntax. Those mechanisms are outside of the scope of
> this specification.
>
> I understand that RFC 2045 now extends the syntax of RFC 5322 (instead
> of RFC 822).

That interpretation would mean that suddenly CFWS beciame forbidden in MIME
constructs when RFC 2822 was published. I don't think that was the intent,
especially when "those mechanisms are outside of the scope".

That paragraph is a bit unfortunately worded, though.

--
Antti-Juhani Kaijanaho, Jyväskylä, Finland
http://antti-juhani.kaijanaho.fi/newblog/
http://www.flickr.com/photos/antti-juhani/

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o09AMr4U071364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Jan 2010 03:22:53 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o09AMqeH071363; Sat, 9 Jan 2010 03:22:52 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from 42.mail-out.ovh.net (42.mail-out.ovh.net [213.251.189.42]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id o09AMlHc071354 for ; Sat, 9 Jan 2010 03:22:48 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 13124 invoked by uid 503); 9 Jan 2010 10:23:03 -0000
Received: from b6.ovh.net (HELO mail639.ha.ovh.net) (213.186.33.56) by 42.mail-out.ovh.net with SMTP; 9 Jan 2010 10:23:03 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 9 Jan 2010 10:23:43 -0000
Received: from aaubervilliers-151-1-8-94.w83-114.abo.wanadoo.fr (HELO Iulius) ([email-masked]) by ns0.ovh.net with SMTP; 9 Jan 2010 10:23:41 -0000
Message-ID: <7FDA90361E9E4C85A22D79FA9014E5C0@Iulius>
From: =?iso-8859-1?Q?Julien_=C9LIE?=
To: "Usefor WG"
References: <3F6C660203CE4751A068B86CD382864E@Iulius> <[email-masked]>
In-Reply-To: <[email-masked]>
Subject: Re: Parsing the Injection-Info: header field
Date: Sat, 9 Jan 2010 11:22:45 +0100
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6002.18005
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005
X-Ovh-Tracer-Id: 6425792244394753465
X-Ovh-Remote: 83.114.7.94 (aaubervilliers-151-1-8-94.w83-114.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hi Antti-Juhani,

>> Why should RFC 822 be followed here?
>
> This is how I understand it:
>
> Because RFC 2231 is what defines , and RFC 2231 is written in the
> context of RFC 822 ABNF, not RFC 5322 (or RFC 2822) ABNF. Thus, the implicit
> CFWS semantics of RFC 822 must be applied to the definition of ,
> even though the rest of RFC 5536 follows RFC 5322 in not having implicit CFWS.

Yet, RFC 5322 mentions in its introduction:

This document specifies a syntax only for text messages. In
particular, it makes no provision for the transmission of images,
audio, or other sorts of structured data in electronic mail messages.
There are several extensions published, such as the MIME document
series ([RFC2045], [RFC2046], [RFC2049]), which describe mechanisms
for the transmission of such data through electronic mail, either by
extending the syntax provided here or by structuring such messages to
conform to this syntax. Those mechanisms are outside of the scope of
this specification.

I understand that RFC 2045 now extends the syntax of RFC 5322 (instead
of RFC 822).

RFC 2231 extends the syntax of RFC 2045 so it is normally currently
based on RFC 5322.

>> So it shows that a space is allowed before "=".
>> Isn't it a difference with RFC 5322 that ought to be mentioned in appendix C?
>
> What difference is that? RFC 5322 does not define .

Sure, but USEFOR is said to comply with RFC 5322 which specifies that RFC 2045
syntax is now based upon RFC 5322 (or that RFC 2045 is to structure messages
to conform to RFC 5322 -- which is basically the same for now unauthorized
folding rules).

> This confusion is caused by that the MIME specs have not (yet?) been updated to
> match RFC 5322.

It depends on whether a software is compliant to RFC 822 or not.
When a software complies with RFC 2822 or 5322, the new syntax is to be used
since MIME specs are said to extend these new RFCs instead of the obsoleted
RFC 822.

Is RFC 5322 to be read in another way when it speaks about RFC 2045?

--
Julien ÉLIE

« -- Essayons d'interroger ce garde habilement sans éveiller ses soupçons...
-- Hep ! Où est enfermé Assurancetourix ? » (Astérix)

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o097VSFw062967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Jan 2010 00:31:30 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o097VOwM062965; Sat, 9 Jan 2010 00:31:24 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from flowerpot.kaijanaho.fi (flowerpot.kaijanaho.fi [80.68.88.155]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o097VLdc062955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 9 Jan 2010 00:31:23 -0700 (MST) (envelope-from [email-masked])
Received: from kukkaseppele.kaijanaho.fi (a91-156-170-97.elisa-laajakaista.fi [91.156.170.97]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ajk) by flowerpot.kaijanaho.fi (Postfix) with ESMTPSA id 54F9329000B for ; Sat, 9 Jan 2010 09:31:19 +0200 (EET)
Received: by kukkaseppele.kaijanaho.fi (Postfix, from userid 1000) id 84F4285408F; Sat, 9 Jan 2010 09:31:19 +0200 (EET)
Date: Sat, 9 Jan 2010 09:31:19 +0200
From: Antti-Juhani Kaijanaho
To: Usefor WG
Subject: Re: Parsing the Injection-Info: header field
Message-ID: <[email-masked]>
References: <3F6C660203CE4751A068B86CD382864E@Iulius>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3F6C660203CE4751A068B86CD382864E@Iulius>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Sat, Jan 09, 2010 at 12:21:42AM +0100, Julien ÉLIE wrote:
>
> Hi,
>
> I follow a discussion that was initiated in news.software.nntp:
>
> http://groups.google.fr/group/news.software.nntp/browse_frm/thread/c704d0859dd84d38
>
>
>
> According to Section 3.2.8 of RFC 5536:
>
>
> injection-info = "Injection-Info:" SP [CFWS] path-identity
> [CFWS] *( ";" [CFWS] parameter ) [CFWS] CRLF
>
> NOTE: The syntax of (Section 5.1 of [RFC2045], as
> amended by [RFC2231]), taken in conjunction with the folding rules
> of [RFC0822] (note: not [RFC2822] or [RFC5322]), effectively
> allows [CFWS] to occur on either side of the "=" inside a
> .
>
>
> I do not understand well that point.
> Does it mean that CFWS is allowed both before and after the "="?

I believe so, yes.

> Why should RFC 822 be followed here?

This is how I understand it:

Because RFC 2231 is what defines , and RFC 2231 is written in the
context of RFC 822 ABNF, not RFC 5322 (or RFC 2822) ABNF. Thus, the implicit
CFWS semantics of RFC 822 must be applied to the definition of ,
even though the rest of RFC 5536 follows RFC 5322 in not having implicit CFWS.

I suspect the same note applies to all other nonterminals imported from the
MIME specs (token, value, attribute).

This confusion is caused by that the MIME specs have not (yet?) been updated to
match RFC 5322. The yam (Yet Another Mail) working group is, AFAICT, the place
where any decision to do that would be initially made.

> And why doesn't RFC 5322 mention that?

Why would it?

> So it shows that a space is allowed before "=".
> Isn't it a difference with RFC 5322 that ought to be mentioned in appendix C?

What difference is that? RFC 5322 does not define .

--
Antti-Juhani Kaijanaho, Jyväskylä, Finland
http://antti-juhani.kaijanaho.fi/newblog/
http://www.flickr.com/photos/antti-juhani/

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o08NLo74042947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jan 2010 16:21:51 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o08NLoit042946; Fri, 8 Jan 2010 16:21:50 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from 30.mail-out.ovh.net (30.mail-out.ovh.net [213.186.62.213]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id o08NLj8x042936 for ; Fri, 8 Jan 2010 16:21:46 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 22174 invoked by uid 503); 8 Jan 2010 23:21:31 -0000
Received: from b9.ovh.net (HELO mail26.ha.ovh.net) (213.186.33.59) by 30.mail-out.ovh.net with SMTP; 8 Jan 2010 23:21:31 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 8 Jan 2010 23:21:43 -0000
Received: from aaubervilliers-151-1-8-94.w83-114.abo.wanadoo.fr (HELO Iulius) ([email-masked]) by ns0.ovh.net with SMTP; 8 Jan 2010 23:21:42 -0000
Message-ID: <3F6C660203CE4751A068B86CD382864E@Iulius>
From: =?iso-8859-15?Q?Julien_=C9LIE?=
To: "Usefor WG"
Subject: Parsing the Injection-Info: header field
Date: Sat, 9 Jan 2010 00:21:42 +0100
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-15"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6002.18005
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005
X-Ovh-Tracer-Id: 13692631717180014009
X-Ovh-Remote: 83.114.7.94 (aaubervilliers-151-1-8-94.w83-114.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hi,

I follow a discussion that was initiated in news.software.nntp:

http://groups.google.fr/group/news.software.nntp/browse_frm/thread/c704d0859dd84d38

According to Section 3.2.8 of RFC 5536:

injection-info = "Injection-Info:" SP [CFWS] path-identity
[CFWS] *( ";" [CFWS] parameter ) [CFWS] CRLF

NOTE: The syntax of (Section 5.1 of [RFC2045], as
amended by [RFC2231]), taken in conjunction with the folding rules
of [RFC0822] (note: not [RFC2822] or [RFC5322]), effectively
allows [CFWS] to occur on either side of the "=" inside a
.

I do not understand well that point.
Does it mean that CFWS is allowed both before and after the "="?
Why should RFC 822 be followed here? And why doesn't RFC 5322 mention
that?

I thought that RFC 5536 was based upon RFC 5322 and therefore would
not allow a space before "=", and would allow a space after "=" only
if is a quoted-string.

Just afterwards:

format of
-------------------- -----------------
"posting-host" a
"posting-account" any
"logging-data" any
"mail-complaints-to" an

NOTE: Since any such or also has to be
a syntactically correct , it will usually be necessary to
encapsulate it as a , for example:

posting-host = "posting.example.com:192.0.2.1"

So it shows that a space is allowed before "=".
Isn't it a difference with RFC 5322 that ought to be mentioned in appendix C?

When it is said that is encapsulated as a , does
it mean that:

posting-host = "pos\ting.example.com"
posting-host = (Comment) "posting.example.com" (Comment)

are two valid values for this parameter? (Both being "posting.example.com".)

Incidentally, I do not know how to parse

posting-host="20bd:20bd::1"

It could be the IPv6 address "20bd:20bd::1" or the host name "20bd" associated
with the IPv6 address "20bd::1"!

--
Julien ÉLIE

« En vérité, le chemin importe peu, la volonté d'arriver suffit à tout. »

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o07JAQmx050249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2010 12:10:28 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o07JALtx050247; Thu, 7 Jan 2010 12:10:22 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp.stanford.edu (smtp5.Stanford.EDU [171.67.219.85]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o07JAFvX050232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 Jan 2010 12:10:16 -0700 (MST) (envelope-from [email-masked])
Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0100418FC86 for ; Thu, 7 Jan 2010 11:10:13 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) by smtp.stanford.edu (Postfix) with ESMTP id 4DB2518FA93 for ; Thu, 7 Jan 2010 11:10:12 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 48C212589A; Thu, 7 Jan 2010 11:10:12 -0800 (PST)
From: Russ Allbery
To: [email-masked]
Subject: Re: Syntax validation of articles by injecting agents
In-Reply-To: <[email-masked]> (Seth's message of "Thu, 7 Jan 2010 12:59:26 -0500 (EST)")
Organization: The Eyrie
References: <35100640C1C848E4A3267B6B4FD3B9ED@Iulius> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Date: Thu, 07 Jan 2010 11:10:12 -0800
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Seth writes:
> "Charles Lindsey" wrote:

>> Well that implies, to me, that if the message contains nothing that
>> purports to be "composed in compliance with this document", then there
>> is no obligation to inlcude the MIME-Version.

> Even if it is composed in compliance with the document, there is no
> obligation to *assert* that fact.

Actually, yes, there is. I really don't see how RFC 2049 could possibly
be any clearer.

| A mail user agent that is MIME-conformant MUST:
|
| (1) Always generate a "MIME-Version: 1.0" header field in
| any message it creates.

I don't think there's much need to go farther afield into other MIME
documents when RFC 2049 is as clear as crystal and when we explicitly
stated in RFC 5536 that all user agents complying with RFC 5536 MUST meet
the definition of MIME conformance in RFC 2049.

(This does not, as pointed out elsewhere in the thread, imply that servers
have to reject messages generated by non-conformant user agents.)

--
Russ Allbery ([email-masked])

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o07HxTrV045768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2010 10:59:29 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o07HxSmc045766; Thu, 7 Jan 2010 10:59:28 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o07HxQ9O045759 for ; Thu, 7 Jan 2010 10:59:27 -0700 (MST) (envelope-from [email-masked])
Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail1.panix.com (Postfix) with ESMTP id 3502A1F096 for ; Thu, 7 Jan 2010 12:59:26 -0500 (EST)
Received: by panix5.panix.com (Postfix, from userid 756) id 38C6A24232; Thu, 7 Jan 2010 12:59:26 -0500 (EST)
From: Seth
To: [email-masked]
In-reply-to: ([email-masked])
Subject: Re: Syntax validation of articles by injecting agents
References: <35100640C1C848E4A3267B6B4FD3B9ED@Iulius> <[email-masked]> <[email-masked]> <[email-masked]>
Message-Id: <[email-masked]>
Date: Thu, 7 Jan 2010 12:59:26 -0500 (EST)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

"Charles Lindsey" wrote:
> In
> =?Windows-1252?Q?Julien_=C9LIE?= writes:
> (quotes)

>> MIME-Version: 1.0
>
>> The presence of this header field is an assertion that the message
>> has been composed in compliance with this document.
>
> Well that implies, to me, that if the message contains nothing that
> purports to be "composed in compliance with this document", then there is
> no obligation to inlcude the MIME-Version.

Even if it is composed in compliance with the document, there is no
obligation to *assert* that fact.

Seth

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o07CC8Zr024345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2010 05:12:10 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o07CC7rc024343; Thu, 7 Jan 2010 05:12:07 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from v-smtp-auth-relay-4.gradwell.net (v-smtp-auth-relay-4.gradwell.net [79.135.125.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o07CC51e024336 for ; Thu, 7 Jan 2010 05:12:06 -0700 (MST) (envelope-from [email-masked])
Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3&clerew#man$ac*uk) by v-smtp-auth-relay-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4b45cf93.4c8d.71 for [email-masked]; Thu, 7 Jan 2010 12:12:03 +0000 (envelope-sender )
Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id o07CC28a014870 for ; Thu, 7 Jan 2010 12:12:02 GMT
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id o07CC2i3014865 for [email-masked]; Thu, 7 Jan 2010 12:12:02 GMT
To: [email-masked]
Xref: clerew local.usefor:25217
Path: clerew!chl
From: "Charles Lindsey"
Subject: Re: Syntax validation of articles by injecting agents
Message-ID:
X-Newsreader: NN version 6.5.2 (NOV)
References: <35100640C1C848E4A3267B6B4FD3B9ED@Iulius> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Thu, 7 Jan 2010 11:30:44 GMT
Lines: 30
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

In =?Windows-1252?Q?Julien_=C9LIE?= writes:

>If not, see Section 4 of RFC 2045:

> Therefore, this document defines a new header field, "MIME-Version",
> which is to be used to declare the version of the Internet message
> body format standard in use.

> Messages composed in accordance with this document MUST include such
> a header field, with the following verbatim text:

> MIME-Version: 1.0

> The presence of this header field is an assertion that the message
> has been composed in compliance with this document.

Well that implies, to me, that if the message contains nothing that
purports to be "composed in compliance with this document", then there is
no obligation to inlcude the MIME-Version.

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked] Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o06IbZrD062366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jan 2010 11:37:36 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o06IbZKi062365; Wed, 6 Jan 2010 11:37:35 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from lon1-post-3.mail.demon.net (lon1-post-3.mail.demon.net [195.173.77.150]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o06IbYV1062359 for ; Wed, 6 Jan 2010 11:37:34 -0700 (MST) (envelope-from [email-masked])
Received: from gti.noc.demon.net ([195.11.55.101] helo=happyday.al.cl.cam.ac.uk) by lon1-post-3.mail.demon.net with esmtp (Exim 4.69) id 1NSalA-0000Tc-fb; Wed, 06 Jan 2010 18:37:33 +0000
Message-ID: <[email-masked]>
Date: Wed, 6 Jan 2010 18:35:35 +0000
To: Charles Lindsey
Cc: [email-masked]
From: Richard Clayton
Subject: Re: Syntax validation of articles by injecting agents
References: <35100640C1C848E4A3267B6B4FD3B9ED@Iulius> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.03 M <$by$+7C377v8lMKLGma+dujYlD>
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message , Charles Lindsey
writes
>
>In <[email-masked]> Richard Clayton
>writes:
>
>>In message , Charles Lindsey
>> writes
>
>>>But I don't think RFC 2049 ever intended to imply that MIME-Version was
>>>needed for a message that did not actually use any of the MIME features.
>
>>Hardly on topic for this list, but yes that's exactly what it means, and
>>what it was intended to mean. It's no big deal for a client to generate
>>the header field, so it's hardly onerous! (see this message for an
>>example of a compliant client)
>
>Then how do you account for the option of not including in in RFC 2047?

I think it's saying that you must expect MUAs to parse encoded words
without checking if the Mime-Version: header field is or is not present
(and giving permission for MUAs to be optimised that way)

- --
richard Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBS0TX95oAxkTY1oPiEQJQKwCcCIDpyKdf3Jl15oCKm1qgafnF62YAoIGp
mZY5jS4zDoSY65KkQPnbRlUu
=tMPv
-----END PGP SIGNATURE-----

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o06IKK8d061114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jan 2010 11:20:20 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o06IKKQd061113; Wed, 6 Jan 2010 11:20:20 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from 27.mail-out.ovh.net (27.mail-out.ovh.net [91.121.30.210]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id o06IKFNV061105 for ; Wed, 6 Jan 2010 11:20:16 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 12395 invoked by uid 503); 6 Jan 2010 19:22:38 -0000
Received: from b7.ovh.net (HELO mail94.ha.ovh.net) (213.186.33.57) by 27.mail-out.ovh.net with SMTP; 6 Jan 2010 19:22:38 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 6 Jan 2010 18:20:14 -0000
Received: from aaubervilliers-151-1-8-94.w83-114.abo.wanadoo.fr (HELO Iulius) ([email-masked]) by ns0.ovh.net with SMTP; 6 Jan 2010 18:20:14 -0000
Message-ID: <6171D662B9B54EEC9A72F2AC42BDB3C9@Iulius>
From: =?ISO-8859-15?Q?Julien_=C9LIE?=
To: "Usefor WG"
References: <35100640C1C848E4A3267B6B4FD3B9ED@Iulius> <[email-masked]>
In-Reply-To: <[email-masked]>
Subject: Re: Syntax validation of articles by injecting agents
Date: Wed, 6 Jan 2010 19:20:18 +0100
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="ISO-8859-15"; reply-type=response
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6002.18005
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005
X-Ovh-Tracer-Id: 15302668583880818105
X-Ovh-Remote: 83.114.7.94 (aaubervilliers-151-1-8-94.w83-114.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hi Harald,

> I think the *important* part of all that conformance is that Just-Send-8 messages are strictly illegal, and that if you use MIME,
> 2047 or 2231, you have to use it correctly.

Yes, I agree with that.

And unfortunately, there are still posts in the French hierarchy fr.*
that either have no MIME headers or that have Content-Type: without
any MIME-Version: header field.
They contain 8-bit chars.

Examples of such readers: Xnews, MacSOUP, lots of malconfigured Outlook
Express...

So I believe it would be currently too harmful to reject posts with illegal
8-bit chars... Such articles are not valid.

--
Julien ÉLIE

« Medicus dedit qui temporis morbo curam,
Is plus remedii quam cutis sector dedit. »

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o06HqIGl059143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jan 2010 10:52:19 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o06HqEew059139; Wed, 6 Jan 2010 10:52:14 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from 27.mail-out.ovh.net (27.mail-out.ovh.net [91.121.30.210]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id o06HqCs6059132 for ; Wed, 6 Jan 2010 10:52:13 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 15811 invoked by uid 503); 6 Jan 2010 18:54:33 -0000
Received: from b7.ovh.net (HELO mail94.ha.ovh.net) (213.186.33.57) by 27.mail-out.ovh.net with SMTP; 6 Jan 2010 18:54:33 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 6 Jan 2010 17:52:11 -0000
Received: from aaubervilliers-151-1-8-94.w83-114.abo.wanadoo.fr (HELO Iulius) ([email-masked]) by ns0.ovh.net with SMTP; 6 Jan 2010 17:52:09 -0000
Message-ID:
From: =?Windows-1252?Q?Julien_=C9LIE?=
To: "Usefor WG"
References: <35100640C1C848E4A3267B6B4FD3B9ED@Iulius> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
Subject: Re: Syntax validation of articles by injecting agents
Date: Wed, 6 Jan 2010 18:52:14 +0100
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6002.18005
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005
X-Ovh-Tracer-Id: 14828383249045126585
X-Ovh-Remote: 83.114.7.94 (aaubervilliers-151-1-8-94.w83-114.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hi Charles,

>>>But I don't think RFC 2049 ever intended to imply that MIME-Version was
>>>needed for a message that did not actually use any of the MIME features.
>
>>Hardly on topic for this list, but yes that's exactly what it means, and
>>what it was intended to mean. It's no big deal for a client to generate
>>the header field, so it's hardly onerous! (see this message for an
>>example of a compliant client)
>
> Then how do you account for the option of not including in in RFC 2047?

The Section 6.1 you quote in RFC 2047 only specifies how a MIME-compliant
reader MUST parse any messages.
The fact that a MIME-Version: header field is not required to be present
for s to be interpreted according to the specification
only means, to my mind, that a MIME-compliant reader should properly decode
s of broken agents.

This way, a MIME-compliant agent will not write
=?iso-8859-1?q?this=20is=20some=20text?=
to the user if the MIME-Version: header field is missing! It will try
to decode it and properly display "this is some text".

Another reason is given by RFC 2047:

One reason for this is that the mail reader is
not expected to parse the entire message header before displaying
lines that may contain 'encoded-word's.

It then allows a MIME-compliant reader that decodes headers as soon as
it receives it, not to wait for the MIME-Version: header field in order
to properly decode headers. It will not have to decode them twice
for instance.

Aren't these two reasons enough to say that RFC 2047 does not stipulate
that a MIME-Version: header field is optional?

If not, see Section 4 of RFC 2045:

Therefore, this document defines a new header field, "MIME-Version",
which is to be used to declare the version of the Internet message
body format standard in use.

Messages composed in accordance with this document MUST include such
a header field, with the following verbatim text:

MIME-Version: 1.0

The presence of this header field is an assertion that the message
has been composed in compliance with this document.

Regarding RFC 2045:

This initial document specifies the various headers used to describe
the structure of MIME messages. The second document, RFC 2046,
defines the general structure of the MIME media typing system and
defines an initial set of media types. The third document, RFC 2047,
describes extensions to RFC 822 to allow non-US-ASCII text data in
Internet mail header fields. The fourth document, RFC 2048, specifies
various IANA registration procedures for MIME-related facilities. The
fifth and final document, RFC 2049, describes MIME conformance
criteria as well as providing some illustrative examples of MIME
message formats, acknowledgements, and the bibliography.

--
Julien ÉLIE

« Medicus dedit qui temporis morbo curam,
Is plus remedii quam cutis sector dedit. »

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o06HC8Zr056665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jan 2010 10:12:08 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o06HC8GF056664; Wed, 6 Jan 2010 10:12:08 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from v-smtp-auth-relay-4.gradwell.net (v-smtp-auth-relay-4.gradwell.net [79.135.125.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o06HC6bA056657 for ; Wed, 6 Jan 2010 10:12:07 -0700 (MST) (envelope-from [email-masked])
Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3$clerew&man&ac$uk) by v-smtp-auth-relay-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4b44c464.55c3.152 for [email-masked]; Wed, 6 Jan 2010 17:12:04 +0000 (envelope-sender )
Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id o06HC1E4017108 for ; Wed, 6 Jan 2010 17:12:01 GMT
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id o06HC18Z017104 for [email-masked]; Wed, 6 Jan 2010 17:12:01 GMT
To: [email-masked]
Xref: clerew local.usefor:25212
Path: clerew!chl
From: "Charles Lindsey"
Subject: Re: Syntax validation of articles by injecting agents
Message-ID:
X-Newsreader: NN version 6.5.2 (NOV)
References: <35100640C1C848E4A3267B6B4FD3B9ED@Iulius> <[email-masked]> <[email-masked]> <[email-masked]>
Date: Wed, 6 Jan 2010 16:37:05 GMT
Lines: 25
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

In <[email-masked]> Richard Clayton writes:

>In message , Charles Lindsey
> writes

>>But I don't think RFC 2049 ever intended to imply that MIME-Version was
>>needed for a message that did not actually use any of the MIME features.

>Hardly on topic for this list, but yes that's exactly what it means, and
>what it was intended to mean. It's no big deal for a client to generate
>the header field, so it's hardly onerous! (see this message for an
>example of a compliant client)

Then how do you account for the option of not including in in RFC 2047?

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked] Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o06EuvC2048164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jan 2010 07:56:57 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o06EuuXX048162; Wed, 6 Jan 2010 07:56:56 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o06Eusgr048156 for ; Wed, 6 Jan 2010 07:56:55 -0700 (MST) (envelope-from [email-masked])
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C5A6D39E255; Wed, 6 Jan 2010 15:56:27 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlqNQI0TAbi2; Wed, 6 Jan 2010 15:56:27 +0100 (CET)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 6715939E165; Wed, 6 Jan 2010 15:56:27 +0100 (CET)
Message-ID: <[email-masked]>
Date: Wed, 06 Jan 2010 15:56:52 +0100
From: Harald Alvestrand
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: =?ISO-8859-15?Q?Julien_=C9LIE?=
CC: Usefor WG
Subject: Re: Syntax validation of articles by injecting agents
References: <35100640C1C848E4A3267B6B4FD3B9ED@Iulius>
In-Reply-To: <35100640C1C848E4A3267B6B4FD3B9ED@Iulius>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Julien =C9LIE wrote:
>
> Hi,
>
> RFC 5537 mentions that an injecting agent MUST reject any proto-article=

> that is not syntactically valid as defined by RFC 5536.
RFC 5536 says about articles:

An article is said to be conformant to this specification if it
conforms to the format specified in Section 3 of [RFC5322] and to the
additional requirements of this specification.

This doesn't require MIME.
It says about agents:

User agents MUST meet the definition of MIME conformance in [RFC2049]
and MUST also support [RFC2231]. This level of MIME conformance
provides support for internationalization and multimedia in message
bodies [RFC2045], [RFC2046], and [RFC2231], and support for
internationalization of header fields [RFC2047] and [RFC2231]. Note
that [Errata] currently exist for [RFC2045], [RFC2046], [RFC2047] and
[RFC2231].

Yes, that requires that user agents conforming to RFC 5536 must add=20
MIME-version headers.

I think the *important* part of all that conformance is that Just-Send-8 =

messages are strictly illegal, and that if you use MIME, 2047 or 2231,=20
you have to use it correctly.

Harald

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o05CZA5V058376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jan 2010 05:35:11 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o05CZAPR058375; Tue, 5 Jan 2010 05:35:10 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from anchor-post-3.mail.demon.net (anchor-post-3.mail.demon.net [195.173.77.134]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o05CZ7Il058366 for ; Tue, 5 Jan 2010 05:35:08 -0700 (MST) (envelope-from [email-masked])
Received: from gti.noc.demon.net ([195.11.55.101] helo=happyday.al.cl.cam.ac.uk) by anchor-post-3.mail.demon.net with esmtp (Exim 4.69) id 1NS8cs-0000P8-pM; Tue, 05 Jan 2010 12:35:06 +0000
Message-ID: <[email-masked]>
Date: Tue, 5 Jan 2010 12:33:41 +0000
To: Charles Lindsey
Cc: [email-masked]
From: Richard Clayton
Subject: Re: Syntax validation of articles by injecting agents
References: <35100640C1C848E4A3267B6B4FD3B9ED@Iulius> <[email-masked]> <[email-masked]>
In-Reply-To:
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.03 M
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message , Charles Lindsey
writes

>But I don't think RFC 2049 ever intended to imply that MIME-Version was
>needed for a message that did not actually use any of the MIME features.

Hardly on topic for this list, but yes that's exactly what it means, and
what it was intended to mean. It's no big deal for a client to generate
the header field, so it's hardly onerous! (see this message for an
example of a compliant client)

What it does for you is to ensure that if you are corresponding with
someone whose client is MIME compatible, you learn that is so "for free"

You might note that adding "MIME-Version: 1.0" to a message that is
otherwise "not MIME" (but correctly eschews the use of "non-ASCII"
characters etc), will make no difference to its interpretation.

- --
richard @ highwayman . com "Nothing seems the same
Still you never see the change from day to day
And no-one notices the customs slip away"

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBS0MxpZoAxkTY1oPiEQJUGQCfRqeDzYfcvXyaHt8NG7EbXvrQXAcAoLEk
XwrlvutbAIoRqe0rHNle6qp4
=+F9+
-----END PGP SIGNATURE-----

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o05CC6Dq056765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jan 2010 05:12:06 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o05CC6Ht056764; Tue, 5 Jan 2010 05:12:06 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from v-smtp-auth-relay-4.gradwell.net (v-smtp-auth-relay-4.gradwell.net [79.135.125.43]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o05CC4kY056758 for ; Tue, 5 Jan 2010 05:12:05 -0700 (MST) (envelope-from [email-masked])
Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3#clerew&man$ac&uk) by v-smtp-auth-relay-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4b432c91.340d.74 for [email-masked]; Tue, 5 Jan 2010 12:12:01 +0000 (envelope-sender )
Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id o05CC3eJ020687 for ; Tue, 5 Jan 2010 12:12:03 GMT
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id o05CC3Au020681 for [email-masked]; Tue, 5 Jan 2010 12:12:03 GMT
To: [email-masked]
Xref: clerew local.usefor:25210
Path: clerew!chl
From: "Charles Lindsey"
Subject: Re: Syntax validation of articles by injecting agents
Message-ID:
X-Newsreader: NN version 6.5.2 (NOV)
References: <35100640C1C848E4A3267B6B4FD3B9ED@Iulius> <[email-masked]> <[email-masked]>
Date: Tue, 5 Jan 2010 11:56:36 GMT
Lines: 60
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

In <[email-masked]> Russ Allbery writes:

>"Charles Lindsey" writes:

>> Eh? How does it imply that? If there are no Content-* headers, then
>> there is no requirement for MIME-Version.

>See Julien's post:

>| NN for instance does not generate MIME-Version: header fields
>| although "user agents MUST meet the definition of MIME conformance"
>| ("a mail user agent that is MIME-conformant MUST always generate
>| a "MIME-Version: 1.0" header field in any message it creates").
>| I believe this sentence applies to news user agents too, otherwise
>| a reference to MIME is useless.

>The first quoted statement is from RFC 5536 section 2.3, with an
>accompanying reference to RFC 2049. The second quoted statement is from
>RFC 2049 section 2.

But I don't think RFC 2049 ever intended to imply that MIME-Version was
needed for a message that did not actually use any of the MIME features.
As evidence of that, I can cite RFC 2047, which states:

(4) A MIME-Version header field is NOT required to be present for
'encoded-word's to be interpreted according to this
specification. One reason for this is that the mail reader is
not expected to parse the entire message header before displaying
lines that may contain 'encoded-word's.

>Now that I think about it, though, this only places a requirement on the
>user agent. It doesn't require that the server reject the message, so I
>think the original problem isn't actually that significant of a problem.
>MIME-compliant agents, such as injecting agents, are allowed to accept
>non-MIME messages.

Exactly.

>> But aren't injecting agents allowed to remove a Path header that is
>> received?

>Injecting agents are specifically discouraged (SHOULD NOT) from fixing or
>remove any header fieldss other than Path.

Which is fair enough, but gives leeway for Paths to be removed, which
copes with the particular problem that was raised. For sure, many
injecting agents DO remove it regardless, because they regard it as an
"infringement of their rights" :-) .

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked] Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o052CfN6020566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Jan 2010 19:12:41 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o052CfQ0020565; Mon, 4 Jan 2010 19:12:41 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp.stanford.edu (smtp4.Stanford.EDU [171.67.219.84]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o052Cene020557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 Jan 2010 19:12:40 -0700 (MST) (envelope-from [email-masked])
Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DFFCEC6D1 for ; Mon, 4 Jan 2010 18:12:39 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) by smtp.stanford.edu (Postfix) with ESMTP id 47318C6CD for ; Mon, 4 Jan 2010 18:12:39 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 3D3582F4D0; Mon, 4 Jan 2010 18:12:39 -0800 (PST)
From: Russ Allbery
To: [email-masked]
Subject: Re: Syntax validation of articles by injecting agents
In-Reply-To: (Charles Lindsey's message of "Mon, 4 Jan 2010 12:27:19 GMT")
Organization: The Eyrie
References: <35100640C1C848E4A3267B6B4FD3B9ED@Iulius> <[email-masked]>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Date: Mon, 04 Jan 2010 18:12:39 -0800
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

"Charles Lindsey" writes:

> Eh? How does it imply that? If there are no Content-* headers, then
> there is no requirement for MIME-Version.

See Julien's post:

| NN for instance does not generate MIME-Version: header fields
| although "user agents MUST meet the definition of MIME conformance"
| ("a mail user agent that is MIME-conformant MUST always generate
| a "MIME-Version: 1.0" header field in any message it creates").
| I believe this sentence applies to news user agents too, otherwise
| a reference to MIME is useless.

The first quoted statement is from RFC 5536 section 2.3, with an
accompanying reference to RFC 2049. The second quoted statement is from
RFC 2049 section 2.

Now that I think about it, though, this only places a requirement on the
user agent. It doesn't require that the server reject the message, so I
think the original problem isn't actually that significant of a problem.
MIME-compliant agents, such as injecting agents, are allowed to accept
non-MIME messages.

> But aren't injecting agents allowed to remove a Path header that is
> received?

See point 2 in Duties of an Injecting Agent in RFC 5537, which requires a
syntax check on the Path header.

> For sure, many of them routinely do. In any case, fixing (or removing) a
> broken header is always a way out of the problem.

Injecting agents are specifically discouraged (SHOULD NOT) from fixing or
remove any header fieldss other than Path.

--
Russ Allbery ([email-masked])

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o051REt5018508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Jan 2010 18:27:14 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o051REXO018506; Mon, 4 Jan 2010 18:27:14 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from smtp.stanford.edu (smtp2.Stanford.EDU [171.67.219.82]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o051RCEN018481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 Jan 2010 18:27:12 -0700 (MST) (envelope-from [email-masked])
Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 40E0F1709A6 for ; Mon, 4 Jan 2010 17:27:12 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) by smtp.stanford.edu (Postfix) with ESMTP id C2F7617031C for ; Mon, 4 Jan 2010 17:27:11 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id BE700257BA; Mon, 4 Jan 2010 17:27:11 -0800 (PST)
From: Russ Allbery
To: "Usefor WG"
Subject: Re: External complaints about the deprecated Lines: header
In-Reply-To: <35D817A499104492B30A6C30C4B5210F@Iulius> ("Julien =?utf-8?Q?=C3=89LIE=22's?= message of "Mon, 4 Jan 2010 21:23:50 +0100")
Organization: The Eyrie
References: <35D817A499104492B30A6C30C4B5210F@Iulius>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Date: Mon, 04 Jan 2010 17:27:11 -0800
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Julien =C3=89LIE writes:

> * LOTS of news servers generate a wrong lines count in their overview.

> This last issue is the most annoying.
> Diablo, Highlands servers, INN (< 2.5), amongst others, return that an ar=
ticle
> has 0 line in its overview data when no Lines: header is present. It is =
the
> implemented behaviour of XOVER.
> That breaks things (especially filtering based on headers, before downloa=
ding
> articles).

Yeah, this has been a problem for years. It's just becoming more
noticable now that new versions of INN don't generate the header, but some
servers haven't generated the header for quite some time and I see
supposedly 0-line articles all the time on old servers.

As you say, the only real solution is for people to upgrade their
software. The Lines header was always rather broken.

--=20
Russ Allbery ([email-masked])

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o04KNq1A004349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Jan 2010 13:23:52 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o04KNqOT004348; Mon, 4 Jan 2010 13:23:52 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from 42.mail-out.ovh.net (42.mail-out.ovh.net [213.251.189.42]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id o04KNooD004341 for ; Mon, 4 Jan 2010 13:23:51 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 5002 invoked by uid 503); 4 Jan 2010 20:24:04 -0000
Received: from b6.ovh.net (HELO mail414.ha.ovh.net) (213.186.33.56) by 42.mail-out.ovh.net with SMTP; 4 Jan 2010 20:24:04 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 4 Jan 2010 20:23:48 -0000
Received: from aaubervilliers-151-1-48-213.w83-114.abo.wanadoo.fr (HELO Iulius) ([email-masked]) by ns0.ovh.net with SMTP; 4 Jan 2010 20:23:47 -0000
Message-ID: <35D817A499104492B30A6C30C4B5210F@Iulius>
From: =?iso-8859-15?Q?Julien_=C9LIE?=
To: "Usefor WG"
References:
In-Reply-To:
Subject: Re: External complaints about the deprecated Lines: header
Date: Mon, 4 Jan 2010 21:23:50 +0100
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-15"; reply-type=response
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6002.18005
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005
X-Ovh-Tracer-Id: 5643854758752550329
X-Ovh-Remote: 83.114.132.213 (aaubervilliers-151-1-48-213.w83-114.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hi all,

> Ray, the administrator of news.eternal-september.org, is currently having issues
> with his users; they complain about the fact that a news server is no longer
> required to generate a Lines: header.

Reading the whole thread, the problem comes from the fact that:

* some users use filters against the Lines: header;

Well, they should not. Scoring should be done on the overview data (which is
for instance available with slrn).

* some news readers use the Lines: header to show the number of lines;

It appears that newer versions of these readers use the overview data.
So upgrading usually solves the issue.

* LOTS of news servers generate a wrong lines count in their overview.

This last issue is the most annoying.
Diablo, Highlands servers, INN (< 2.5), amongst others, return that an article
has 0 line in its overview data when no Lines: header is present. It is the
implemented behaviour of XOVER.
That breaks things (especially filtering based on headers, before downloading
articles).

Note that INN 2.5 returns the real number of lines with XOVER (and of course
OVER).

So the real problem comes from the NNTP protocol itself (with XOVER) and
not the article format.
I hope that impacted users will manage to solve their problem -- it is harder
when it is at the server side...

We can't do much for that, unfortunately.

--
Julien ÉLIE

« Les mathématiques peuvent être définies comme une science
dans laquelle on ne sait jamais de quoi on parle, ni si ce qu'on dit
est vrai. » (Bertrand Russell)

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o04HC8ks093500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Jan 2010 10:12:08 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o04HC8NQ093499; Mon, 4 Jan 2010 10:12:08 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from v-smtp-auth-relay-6.gradwell.net (v-smtp-auth-relay-6.gradwell.net [79.135.125.112]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o04HC6cM093493 for ; Mon, 4 Jan 2010 10:12:07 -0700 (MST) (envelope-from [email-masked])
Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3^clerew&man^ac&uk) by v-smtp-auth-relay-6.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4b422165.706d.216 for [email-masked]; Mon, 4 Jan 2010 17:12:05 +0000 (envelope-sender )
Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id o04HC4Mj012275 for ; Mon, 4 Jan 2010 17:12:04 GMT
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id o04HC3cO012271 for [email-masked]; Mon, 4 Jan 2010 17:12:03 GMT
To: [email-masked]
Xref: clerew local.usefor:25206
Path: clerew!chl
From: "Charles Lindsey"
Subject: Re: Syntax validation of articles by injecting agents
Content-Type: text/plain; charset=iso-8859-1
Message-ID:
Content-Transfer-Encoding: 8bit
X-Newsreader: NN version 6.5.2 (NOV)
References: <35100640C1C848E4A3267B6B4FD3B9ED@Iulius> <[email-masked]>
Mime-Version: 1.0
Date: Mon, 4 Jan 2010 12:27:19 GMT
Lines: 57
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

In <[email-masked]> Russ Allbery writes:

>Julien Ã‰LIE writes:

>> RFC 5537 mentions that an injecting agent MUST reject any proto-article
>> that is not syntactically valid as defined by RFC 5536.

>In retrospect, I suspect that should either have been a SHOULD or it
>should have singled out the netnews-specific restrictions. I don't think
>anyone pointed out at the time that it would mean rejecting all non-MIME
>messages, and I suspect we would have changed it if we'd realized that as
>fairly impractical.

Eh? How does it imply that? If there are no Content-* headers, then there
is no requirement for MIME-Version.

>The point was more to reject messages with syntactically invalid
>Newsgroups headers and whatnot.

>> And what if a news reader generates an incorrect User-Agent: header
>> field? or if it always adds a tail-entry which is not a path-nodot
>> in Path:? All its posts will be rejected by a RFC-compliant injecting
>> agent...
>> It it the intention?

>I wonder how many user agents generate invalid Path headers. Hm.

But aren't injecting agents allowed to remove a Path header that is
received? For sure, many of them routinely do. In any case, fixing (or
removing) a broken header is always a way out of the problem.

>I have a hard time justifying rejecting articles on the basis of syntactic
>problems in purely informational headers like User-Agent.

>> I quite understand that it would help to have better compliant
>> articles. For instance, rejecting articles with "all" in their
>> distribution list.

>That, at least, the user probably has some control over.

>> How can we handle that MUST without hurt?

Well any leniency should only apply to things the user cannot control. But
the world will not suddenly end if some implementation usees Common Sense
in cases that will do no practical harm.

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked] Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o047G3k0057868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Jan 2010 00:16:04 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o047G0vk057864; Mon, 4 Jan 2010 00:16:00 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from 30.mail-out.ovh.net (30.mail-out.ovh.net [213.186.62.213]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id o047FtLE057854 for ; Mon, 4 Jan 2010 00:15:56 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 23967 invoked by uid 503); 4 Jan 2010 07:15:38 -0000
Received: from b7.ovh.net (HELO mail628.ha.ovh.net) (213.186.33.57) by 30.mail-out.ovh.net with SMTP; 4 Jan 2010 07:15:38 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 4 Jan 2010 07:16:31 -0000
Received: from aaubervilliers-151-1-48-213.w83-114.abo.wanadoo.fr (HELO Iulius) ([email-masked]) by ns0.ovh.net with SMTP; 4 Jan 2010 07:16:29 -0000
Message-ID:
From: =?iso-8859-15?Q?Julien_=C9LIE?=
To: "Usefor WG"
Subject: External complaints about the deprecated Lines: header
Date: Mon, 4 Jan 2010 08:15:48 +0100
Organization: TrigoFACILE -- http://www.trigofacile.com/
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-15"; reply-type=original
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6002.18005
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005
X-Ovh-Tracer-Id: 10794283882258562489
X-Ovh-Remote: 83.114.132.213 (aaubervilliers-151-1-48-213.w83-114.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Hi,

Ray, the administrator of news.eternal-september.org, is currently having issues
with his users; they complain about the fact that a news server is no longer
required to generate a Lines: header.

Lots of news readers suddenly break...
Especially when they do not use the overview data for the :lines count but
only rely on the Lines: header.

Ray pointed me out to that thread in alt.free.newsservers:
http://groups.google.fr/group/alt.free.newsservers/browse_frm/thread/438e64aa1e740f3e

Just following here the issue (in case someone wants to participate).

--
Julien ÉLIE

« When a newly married couple smiles, everyone knows why.
When a ten-year married couple smiles, everyone wonders why. »