Re: Tr: WG Review: Internationalized Resource Identifiers (iri)

["Charles Lindsey" <[e-mail]>]

In <562428FED2024818B7E01DC05DD4086D@Iulius> Julien ÉLIE <[e-mail]> writes:

>Hi,

>Don't we have to do something for news: and nntp: as for
>internationalized resource identifiers?
>It would be about internationalized newsgroup names...

Well first of all one needs to invent internationalized newsgroup names.
We did a lot of work on this once, but it got shelved. But essentially, we
just wanted to let them be in UTF-8. But you need some clear rules as to
exactly what characters are allowed where.

But in the meantime the EAI extensions to allow UTF-8 in email headers
have been published as an experimental RFC, so the proper way to proceed
would be to extend EAI to cover Netnews as well.

So the first question is whether this group should do it, ot whether we
hand it over to the EAI group and let them do it (we would participate
there, or course). I think we need to hear some views from Harald on that.
And we would also need to bring in some of the Scandinavians who were
active on this group at that time.

But when we have internationalized newsgroup names, then indeed IRIs would
need to be thought about (though that too arises on the EAI WG).


-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone]            Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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 o015CAYY066116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Dec 2009 22:12:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id o015CAaC066115; Thu, 31 Dec 2009 22:12:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from v-smtp-auth-relay-5.gradwell.net (v-smtp-auth-relay-5.gradwell.net [79.135.125.99]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o015C8uu066108 for <[e-mail]>; Thu, 31 Dec 2009 22:12:09 -0700 (MST) (envelope-from [e-mail])
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-5.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.290) id 4b3d8427.66b8.28 for [e-mail]; Fri,  1 Jan 2010 05:12:07 +0000 (envelope-sender <[e-mail]>)
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 o015C3rg011419 for <[e-mail]>; Fri, 1 Jan 2010 05:12:04 GMT
Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id o015C3QF011416 for [e-mail]; Fri, 1 Jan 2010 05:12:03 GMT
To: [e-mail]
Xref: clerew local.usefor:25202
Path: clerew!chl
From: "Charles Lindsey" <[e-mail]>
Subject: Re: Tr: WG Review: Internationalized Resource Identifiers (iri)
Content-Type: text/plain; charset=iso-8859-1
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-Newsreader: NN version 6.5.2 (NOV)
References: <562428FED2024818B7E01DC05DD4086D@Iulius>
Mime-Version: 1.0
Date: Thu, 31 Dec 2009 17:43:31 GMT
Lines: 37
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

In <562428FED2024818B7E01DC05DD4086D@Iulius> Julien ÉLIE <[e-mail]> writes:

>Hi,

>Don't we have to do something for news: and nntp: as for
>internationalized resource identifiers?
>It would be about internationalized newsgroup names...

Well first of all one needs to invent internationalized newsgroup names.
We did a lot of work on this once, but it got shelved. But essentially, we
just wanted to let them be in UTF-8. But you need some clear rules as to
exactly what characters are allowed where.

But in the meantime the EAI extensions to allow UTF-8 in email headers
have been published as an experimental RFC, so the proper way to proceed
would be to extend EAI to cover Netnews as well.

So the first question is whether this group should do it, ot whether we
hand it over to the EAI group and let them do it (we would participate
there, or course). I think we need to hear some views from Harald on that.
And we would also need to bring in some of the Scandinavians who were
active on this group at that time.

But when we have internationalized newsgroup names, then indeed IRIs would
need to be thought about (though that too arises on the EAI WG).


-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: [phone]            Web: http://www.cs.man.ac.uk/~chl
Email: [e-mail]      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 nBVJhBPe046633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Dec 2009 12:43:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBVJhBHh046632; Thu, 31 Dec 2009 12:43:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 nBVJhAVM046626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 31 Dec 2009 12:43:10 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0D1C6C75E for <[e-mail]>; Thu, 31 Dec 2009 11:43:10 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) by smtp.stanford.edu (Postfix) with ESMTP id BD096C75B for <[e-mail]>; Thu, 31 Dec 2009 11:43:09 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id B84192F5B9; Thu, 31 Dec 2009 11:43:09 -0800 (PST)
From: Russ Allbery <[e-mail]>
To: "Usefor WG" <[e-mail]>
Subject: Re: Syntax validation of articles by injecting agents
In-Reply-To: <35100640C1C848E4A3267B6B4FD3B9ED@Iulius> ("Julien =?utf-8?Q?=C3=89LIE=22's?= message of "Thu, 31 Dec 2009 17:31:46 +0100")
Organization: The Eyrie
References: <35100640C1C848E4A3267B6B4FD3B9ED@Iulius>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Date: Thu, 31 Dec 2009 11:43:09 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Julien =C3=89LIE <[e-mail]> 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.

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.

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.

> But in some cases, people would need to upgrade their news
> readers...  (and maybe change their news readers if it is
> no longer maintained)
> Or news admins will not be willing to upgrade to a news server
> that is RFC-compliant.  (Unless syntax checks can be deactivated
> but then, news admins will deactivate them, and the duty of
> injecting agents will be useless -- "it bears much of the burden
> of diagnosing broken posting agents or communicating policy
> violations to posters".)

> How can we handle that MUST without hurt?

I'm guessing that server implementations will need to be selective about
what headers that it's applied to, unfortunately.  It would probably be
nice to have a picky mode that fully enforces the syntax, though, if for
no other reason than to serve as a testbed for posting agents.

--=20
Russ Allbery ([e-mail])             <http://www.eyrie.org/~eagle/>



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 nBVGVnvA037258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Dec 2009 09:31:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBVGVn9q037257; Thu, 31 Dec 2009 09:31:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 2.mail-out.ovh.net (2.mail-out.ovh.net [91.121.26.226]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id nBVGVlP6037250 for <[e-mail]>; Thu, 31 Dec 2009 09:31:48 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 2546 invoked by uid 503); 31 Dec 2009 17:52:42 -0000
Received: from b9.ovh.net (HELO mail176.ha.ovh.net) (213.186.33.59) by 2.mail-out.ovh.net with SMTP; 31 Dec 2009 17:52:42 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 31 Dec 2009 16:31:45 -0000
Received: from amontpellier-159-1-53-87.w83-197.abo.wanadoo.fr (HELO Iulius) (julien%trigofacile.com@83.197.12.87) by ns0.ovh.net with SMTP; 31 Dec 2009 16:31:43 -0000
Message-ID: <35100640C1C848E4A3267B6B4FD3B9ED@Iulius>
From: =?ISO-8859-15?Q?Julien_=C9LIE?= <[e-mail]>
To: "Usefor WG" <[e-mail]>
Subject: Syntax validation of articles by injecting agents
Date: Thu, 31 Dec 2009 17:31:46 +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: 15127309674382884281
X-Ovh-Remote: 83.197.12.87 (amontpellier-159-1-53-87.w83-197.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Hi,

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

What is the best way to do that then?
Is it safe to implement that requirement?  RFC 5536 is said to
"reflect current practice", but if we enforce that MUST, I believe
it will break lots of news readers.

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.


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 quite understand that it would help to have better compliant
articles.  For instance, rejecting articles with "all" in their
distribution list.

But in some cases, people would need to upgrade their news
readers...  (and maybe change their news readers if it is
no longer maintained)
Or news admins will not be willing to upgrade to a news server
that is RFC-compliant.  (Unless syntax checks can be deactivated
but then, news admins will deactivate them, and the duty of
injecting agents will be useless -- "it bears much of the burden
of diagnosing broken posting agents or communicating policy
violations to posters".)

How can we handle that MUST without hurt?

-- 
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 nBTIlxZS002282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Dec 2009 11:47:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBTIlxdn002281; Tue, 29 Dec 2009 11:47:59 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBTIlvKi002275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 29 Dec 2009 11:47:58 -0700 (MST) (envelope-from [e-mail])
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nBTIl686026308; Tue, 29 Dec 2009 10:47:07 -0800 (PST)
Received: (from rfc-ed@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id nBTIl5NC026297; Tue, 29 Dec 2009 10:47:05 -0800 (PST)
Date: Tue, 29 Dec 2009 10:47:05 -0800
From: RFC Editor <[e-mail]>
To: Russ Allbery <[e-mail]>
Cc: Julien ?LIE <[e-mail]>, Alfred H?nes <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], RFC Editor <[e-mail]>
Subject: Re: [Editorial Errata Reported] RFC5537 (1980)
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <06466FD87F5347558C8C6314998443E0@Iulius> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Russ,

In our opinion, it's better to ammend the existing errata report.  The
errata system was not meant to hold errata for errata entries or to
hold multpile errata entries for the same error, as it could be
confusing for readers.

Please note that the responsible AD has the ability to edit the entry
before verifying it. 

Please let us know if you have any questions.

Thank you.

RFC Editor/sg


On Tue, Dec 29, 2009 at 10:19:20AM -0800, Russ Allbery wrote:
> Julien ?LIE <[e-mail]> writes:
> 
> > Maybe I should re-ask, before the verification takes place...
> > Didn't the mails I sent for errata 1979, 1980 and 1982 reach you?
> 
> They did, yes.
> 
> >> Given this, I agree with all the changes you propose and think the
> >> errata should be verified in its entirety.
> 
> > If the erratum is to be verified, be sure to also include the fourth paragraph
> > of Section 3.4.  It should also be amended:
> 
> >    predating this specification do not add an Injection-Date header.
> 
> > "field" is missing.
> 
> I agree with this change.  I'm not sure how this process works -- whether
> it's better to amend the existing errata or add another one.
> 
> > Another thing:  why is it "header field value" and not "header field
> > body"?  RFCs 5322 and 5536 define "header field body" but not "header
> > field value".  Where is the terminology drawn?
> 
> This is a good point that I didn't check originally.  It does sound like
> header field body might be a better term to use.
> 
> -- 
> Russ Allbery ([e-mail])             <http://www.eyrie.org/~eagle/>



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 nBTIJQ0X000792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Dec 2009 11:19:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBTIJQl2000791; Tue, 29 Dec 2009 11:19:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.stanford.edu (smtp1.Stanford.EDU [171.67.219.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBTIJNWe000781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 29 Dec 2009 11:19:23 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 413DB178A46; Tue, 29 Dec 2009 10:19:23 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) by smtp.stanford.edu (Postfix) with ESMTP id 5DEBE178A5F; Tue, 29 Dec 2009 10:19:20 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 59DE92F5B9; Tue, 29 Dec 2009 10:19:20 -0800 (PST)
From: Russ Allbery <[e-mail]>
To: Julien =?utf-8?Q?=C3=89LIE?= <[e-mail]>
Cc: Alfred =?utf-8?Q?H=C3=B6nes?= <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: [Editorial Errata Reported] RFC5537 (1980)
In-Reply-To: <06466FD87F5347558C8C6314998443E0@Iulius> ("Julien =?utf-8?Q?=C3=89LIE=22's?= message of "Mon, 28 Dec 2009 21:42:38 +0100")
Organization: The Eyrie
References: <[e-mail]> <[e-mail]> <06466FD87F5347558C8C6314998443E0@Iulius>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Date: Tue, 29 Dec 2009 10:19:20 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Julien =C3=89LIE <[e-mail]> writes:

> Maybe I should re-ask, before the verification takes place...
> Didn't the mails I sent for errata 1979, 1980 and 1982 reach you?

They did, yes.

>> Given this, I agree with all the changes you propose and think the
>> errata should be verified in its entirety.

> If the erratum is to be verified, be sure to also include the fourth para=
graph
> of Section 3.4.  It should also be amended:

>    predating this specification do not add an Injection-Date header.

> "field" is missing.

I agree with this change.  I'm not sure how this process works -- whether
it's better to amend the existing errata or add another one.

> Another thing:  why is it "header field value" and not "header field
> body"?  RFCs 5322 and 5536 define "header field body" but not "header
> field value".  Where is the terminology drawn?

This is a good point that I didn't check originally.  It does sound like
header field body might be a better term to use.

--=20
Russ Allbery ([e-mail])             <http://www.eyrie.org/~eagle/>



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 nBT8e75n065446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Dec 2009 01:40:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBT8e772065445; Tue, 29 Dec 2009 01:40:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 39.mail-out.ovh.net (39.mail-out.ovh.net [213.251.138.60]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id nBT8e5w4065436 for <[e-mail]>; Tue, 29 Dec 2009 01:40:05 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 3154 invoked by uid 503); 28 Dec 2009 20:43:02 -0000
Received: from b7.ovh.net (HELO mail643.ha.ovh.net) (213.186.33.57) by 39.mail-out.ovh.net with SMTP; 28 Dec 2009 20:43:02 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 28 Dec 2009 20:42:28 -0000
Received: from amontpellier-159-1-14-25.w90-57.abo.wanadoo.fr (HELO Iulius) (julien%trigofacile.com@90.57.85.25) by ns0.ovh.net with SMTP; 28 Dec 2009 20:42:27 -0000
Message-ID: <06466FD87F5347558C8C6314998443E0@Iulius>
From: =?utf-8?Q?Julien_=C3=89LIE?= <[e-mail]>
To: "Russ Allbery" <[e-mail]>, =?utf-8?Q?Alfred_H=C3=B6nes?= <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: [Editorial Errata Reported] RFC5537 (1980)
Date: Mon, 28 Dec 2009 21:42:38 +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: 1743456007616658739
X-Ovh-Remote: 90.57.85.25 (amontpellier-159-1-14-25.w90-57.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Hi Russ,

Maybe I should re-ask, before the verification takes place...
Didn't the mails I sent for errata 1979, 1980 and 1982 reach you?


> Given this, I agree with all the changes you propose and think the errata
> should be verified in its entirety.

If the erratum is to be verified, be sure to also include the fourth paragraph
of Section 3.4.  It should also be amended:

    predating this specification do not add an Injection-Date header.

"field" is missing.


Another thing:  why is it "header field value" and not "header field body"?
RFCs 5322 and 5536 define "header field body" but not "header field value".
Where is the terminology drawn?

-- 
Julien ÉLIE

« Plus un ordinateur possède de RAM, plus vite il peut générer
  un message d'erreur. »



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 nBT7iQJe062766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Dec 2009 00:44:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBT7iQST062765; Tue, 29 Dec 2009 00:44:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 39.mail-out.ovh.net (39.mail-out.ovh.net [213.251.138.60]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id nBT7iOAU062759 for <[e-mail]>; Tue, 29 Dec 2009 00:44:25 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 7998 invoked by uid 503); 28 Dec 2009 19:31:24 -0000
Received: from b7.ovh.net (HELO mail643.ha.ovh.net) (213.186.33.57) by 39.mail-out.ovh.net with SMTP; 28 Dec 2009 19:31:24 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 28 Dec 2009 19:30:51 -0000
Received: from amontpellier-159-1-14-25.w90-57.abo.wanadoo.fr (HELO Iulius) (julien%trigofacile.com@90.57.85.25) by ns0.ovh.net with SMTP; 28 Dec 2009 19:30:49 -0000
Message-ID: <3829755AF3DA469EA732DBCEEA321146@Iulius>
From: =?Windows-1252?Q?Julien_=C9LIE?= <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: [Editorial Errata Reported] RFC5537 (1982)
Date: Mon, 28 Dec 2009 20:31:01 +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: 533958032667442483
X-Ovh-Remote: 90.57.85.25 (amontpellier-159-1-14-25.w90-57.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Hi Alfred,

> Section: 3.4.2, NOTE
>
> Original Text
> -------------
>       ... unintended repeat injection into the same network, ...
>                           ^
>
> Corrected Text
> --------------
>       ... unintended repeated injection into the same network, ...
>                           ^^^

I do not understand why "repeat" is wrong.
It is what grammars call an "attribute use of nouns" (or in French,
a « nom adjectivé »).

Examples of real uses:  repeat prescription, repeat performance,
repeat order...

-- 
Julien ÉLIE

« Plus un ordinateur possède de RAM, plus vite il peut générer
  un message d'erreur. » 



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 nBT7bpvA062557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Dec 2009 00:37:51 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBT7bpbr062556; Tue, 29 Dec 2009 00:37:51 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 39.mail-out.ovh.net (39.mail-out.ovh.net [213.251.138.60]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id nBT7bnOf062549 for <[e-mail]>; Tue, 29 Dec 2009 00:37:50 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 31864 invoked by uid 503); 28 Dec 2009 19:12:22 -0000
Received: from b7.ovh.net (HELO mail643.ha.ovh.net) (213.186.33.57) by 39.mail-out.ovh.net with SMTP; 28 Dec 2009 19:12:22 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 28 Dec 2009 19:11:48 -0000
Received: from amontpellier-159-1-14-25.w90-57.abo.wanadoo.fr (HELO Iulius) (julien%trigofacile.com@90.57.85.25) by ns0.ovh.net with SMTP; 28 Dec 2009 19:11:44 -0000
Message-ID: <A2AC86ED5CA747EE9275293A077DD3E4@Iulius>
From: =?Windows-1252?Q?Julien_=C9LIE?= <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: [Editorial Errata Reported] RFC5536 (1979)
Date: Mon, 28 Dec 2009 20:11:49 +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: 211106232643681664
X-Ovh-Remote: 90.57.85.25 (amontpellier-159-1-14-25.w90-57.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Hi Alfred,

> Rationale:
>  The whole RFC is precise in its use of the IETF standard terminology
>  as explained in Section 2.1.  This phrase is an exception; here as
>  well "header" should be "header field".

Is it really the case?

Section 2.1 of RFC 5536:

   This document follows the
   terminology in Section 2 of [RFC5322] in using the terms "line",
   "header field", "header field name", "header field body"

Section 2 of RFC 5322:

   Header fields are lines beginning with a field name, followed by a
   colon (":"), followed by a field body, and terminated by CRLF.



But a header field body in RFC 5536 seems to refer to what follows the
first SP of a header field body in RFC 5322.
See Section 2.2 of RFC 5536:

   o  All agents MUST generate header fields so that at least one space
      immediately follows the ':' separating the header field name and
      the header field body

It is not the IETF standard terminology you mention in your rationale.



Hmm...  And I now wonder how the wording you suggest in your erratum 1980
for RFC 5537 should be like...
For instance, Section 5.3 of RFC 5537:

    The syntax of its Control header field is:

         control-command     =/ Cancel-command
         Cancel-command      = "cancel" Cancel-arguments
         Cancel-arguments    = 1*WSP msg-id

And Section 3.2.3 of RFC 5536 gives:

   control         =  "Control:" SP *WSP control-command *WSP CRLF
   control-command =  verb *( 1*WSP argument )
   verb            =  token
   argument        =  1*( %x21-7E )


So in RFC 5537, it is not really the header field.  And not really
the header field body.  So the fix in erratum 1980 might not be correct...
Maybe it is better to leave the global "header field" terminology...

-- 
Julien ÉLIE

« Ne parlez jamais de vous, ni en bien, car on ne vous
  croirait pas, ni en mal car on ne vous croirait que trop. » (Confucius) 



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 nBT7Rbhr062081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Dec 2009 00:27:37 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBT7RbMg062079; Tue, 29 Dec 2009 00:27:37 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 39.mail-out.ovh.net (39.mail-out.ovh.net [213.251.138.60]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id nBT7RXYh062072 for <[e-mail]>; Tue, 29 Dec 2009 00:27:34 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 19155 invoked by uid 503); 28 Dec 2009 18:48:21 -0000
Received: from b7.ovh.net (HELO mail643.ha.ovh.net) (213.186.33.57) by 39.mail-out.ovh.net with SMTP; 28 Dec 2009 18:48:21 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 28 Dec 2009 18:47:48 -0000
Received: from amontpellier-159-1-14-25.w90-57.abo.wanadoo.fr (HELO Iulius) (julien%trigofacile.com@90.57.85.25) by ns0.ovh.net with SMTP; 28 Dec 2009 18:47:45 -0000
Message-ID: <4E0AAD5953E54641B28EF7EAAD8D7202@Iulius>
From: =?Windows-1252?Q?Julien_=C9LIE?= <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: [Editorial Errata Reported] RFC5537 (1980)
Date: Mon, 28 Dec 2009 19:47:57 +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: 18253370764769754553
X-Ovh-Remote: 90.57.85.25 (amontpellier-159-1-14-25.w90-57.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Hi Alfred,

I have two major remarks:

1/ If your report is verified, there is also Section 3.4, fourth paragraph,
to amend:

    predating this specification do not add an Injection-Date header.

"field" is missing.


2/ When you say:
>  Similarly, denoting as "header field" a "header field value" is
>  confusing -- items (e), (f), (g), (i), and (j) above.

Where do you draw the "header field value" terminology?
Isn't it "header field body"?  RFCs 5322 and 5536 define
"header field body" but not "header field value".




And also a few other points:

Note that when for instance we have in Section 6.1 of RFC 5537:

   To best ensure that it will be relayed to the same news servers as
   the original message, a cancel control message SHOULD have the same
   Newsgroups header field as the message it is cancelling.

or in 6.1:

   Cancel control messages are not required to have the same Newsgroups
   header field as the messages they are cancelling.  Since they are
   sometimes processed before the original message is received, it may
   not be possible to check that the Newsgroup header fields match.


of course it is not exactly the same header field because
   Newsgroups: group1,group2
and
   Newsgroups:    groups1,group2
are equivalent...  WSP and FWS should not be taken into account...

Should such terminology also be fixed?



And in Section 5.5:

   Contrary to [RFC1036], the relayer-name MUST be given as the last
   argument in the Control header field.

Wouldn't it be better to say it is the header body?



> 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.


Shouldn't RFC 3977 also be checked for that?

   The distrib.pats list is maintained by some NNTP servers to assist
   clients to choose a value for the content of the Distribution header
   of a news article being posted.

   Lines or Bytes header

and other similar terminology.  RFC 3977 defines headers this way:

   The headers of an article consist of one or more header lines.  Each
   header line consists of a header name, a colon, a space, the header
   content, and a CRLF, in that order.

-- 
Julien ÉLIE

« Ne parlez jamais de vous, ni en bien, car on ne vous
  croirait pas, ni en mal car on ne vous croirait que trop. » (Confucius) 



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 nBSKXNJP033089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Dec 2009 13:33:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBSKXN51033088; Mon, 28 Dec 2009 13:33:23 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 nBSKXMcF033081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 28 Dec 2009 13:33:22 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0F0D218FA5E; Mon, 28 Dec 2009 12:33:22 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) by smtp.stanford.edu (Postfix) with ESMTP id D70B418FA5C; Mon, 28 Dec 2009 12:33:21 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id D36B92F5B9; Mon, 28 Dec 2009 12:33:21 -0800 (PST)
From: Russ Allbery <[e-mail]>
To: Alfred =?utf-8?Q?H=C3=B6nes?= <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: [Editorial Errata Reported] RFC5537 (1980)
In-Reply-To: <[e-mail]> ("Alfred =?utf-8?Q?H=C3=B6n?= =?utf-8?Q?es=22's?= message of "Mon, 28 Dec 2009 21:24:25 +0100 (MEZ)")
Organization: The Eyrie
References: <[e-mail]>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Date: Mon, 28 Dec 2009 12:33:21 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Alfred H=C3=B6nes <[e-mail]> writes:

> Russ,
> thanks for your very quick responses.

> The Control syntax seems to be the single issue that needs elaboration.
> (I did not want to add too much stuff to the Errata note.)

> Quoting from RFC 5536, Section 3.2.3, on top of page 18:

>    control         =3D  "Control:" SP *WSP control-command *WSP CRLF

>    control-command =3D  verb *( 1*WSP argument )
>    verb            =3D  token
>    argument        =3D  1*( %x21-7E )

> These are the syntax rules for the entire header field, giving the
> header field name, "Control", the separating colon ":", and the general
> syntax of the header field value, essentially <control-command> plus
> enclosing optional whitespace.

[...]

> The syntax of the entire Control header field is still given by the
> <control> ABNF production from RFC 5536 (quoted above).  However, taking
> the RFC prose text literally,

>              ...   The syntax of its Control header field is:
>         control-command     =3D/ Newgroup-command
>         ...
> would pretend to indicate that the "Control:" part were dropped here!

Oh!  I understand now.

Given this, I agree with all the changes you propose and think the errata
should be verified in its entirety.

--=20
Russ Allbery ([e-mail])             <http://www.eyrie.org/~eagle/>



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 nBSKVPws033005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Dec 2009 13:31:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBSKVPpW033004; Mon, 28 Dec 2009 13:31:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 nBSKVOII032998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 28 Dec 2009 13:31:24 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CC2441707F5; Mon, 28 Dec 2009 12:31:23 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) by smtp.stanford.edu (Postfix) with ESMTP id 79B491707F2; Mon, 28 Dec 2009 12:31:21 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 76EF42F5B9; Mon, 28 Dec 2009 12:31:21 -0800 (PST)
From: Russ Allbery <[e-mail]>
To: RFC Errata System <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: [Technical Errata Reported] RFC5537 (1993)
In-Reply-To: <[e-mail]> (RFC Errata System's message of "Mon, 28 Dec 2009 12:02:10 -0800 (PST)")
Organization: The Eyrie
References: <[e-mail]>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Date: Mon, 28 Dec 2009 12:31:21 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

RFC Errata System <[e-mail]> writes:

> Type: Technical
> Reported by: Julien =C3=89lie <[e-mail]>

> Section: 5.2.1.1

> Original Text
> -------------
>   A newgroup control message requesting creation of the moderated
>   newsgroup example.admin.info.

>       From: "example.* Administrator" <[e-mail]>
>       Newsgroups: example.admin.info
>       Date: 27 Feb 2002 12:50:22 +0200
>       Subject: cmsg newgroup example.admin.info moderated
>       Approved: [e-mail]
>       Control: newgroup example.admin.info moderated
>       Message-ID: <[e-mail]>
>       MIME-Version: 1.0
>       Content-Type: multipart/mixed; boundary=3D"nxtprt"
>       Content-Transfer-Encoding: 8bit

> Corrected Text
> --------------
>   A newgroup control message requesting creation of the moderated
>   newsgroup example.admin.info.

> |     Path: not-for-mail
>       From: "example.* Administrator" <[e-mail]>
>       Newsgroups: example.admin.info
>       Date: 27 Feb 2002 12:50:22 +0200
>       Subject: cmsg newgroup example.admin.info moderated
>       Approved: [e-mail]
>       Control: newgroup example.admin.info moderated
>       Message-ID: <[e-mail]>
>       MIME-Version: 1.0
>       Content-Type: multipart/mixed; boundary=3D"nxtprt"
>       Content-Transfer-Encoding: 8bit

> Notes
> -----
> As the mandatory Path: header field is missing, this control message is
> only a proto-article.

> A control message is defined in Section 5 as an article which contains a
> Control: header field.  Therefore, a Path: header field should be added
> to the headers of this sample newgroup control article.

This change is correct.  Thanks!

--=20
Russ Allbery ([e-mail])             <http://www.eyrie.org/~eagle/>



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 nBSKOdRR032727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Dec 2009 13:24:39 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBSKOd1i032726; Mon, 28 Dec 2009 13:24:39 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBSKOYOw032708 for <[e-mail]>; Mon, 28 Dec 2009 13:24:37 -0700 (MST) (envelope-from [e-mail])
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA089951868; Mon, 28 Dec 2009 21:24:28 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA13636; Mon, 28 Dec 2009 21:24:25 +0100 (MEZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: [Editorial Errata Reported] RFC5537 (1980)
To: [e-mail]
Date: Mon, 28 Dec 2009 21:24:25 +0100 (MEZ)
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]> from Russ Allbery at Dec "28," 2009 "11:39:13" am
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

> RFC Errata System <[e-mail]> writes:
>
>> 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.
>
> Argh, I thought I caught all of these.  I'm sorry about that.  The
> corrections (a), (b), (c), (d), (h), and (k) are correct.
>
>>   Similarly, denoting as "header field" a "header field value" is
>>   confusing -- items (e), (f), (g), (i), and (j) above.
>
> I don't understand the rationale for this change.  I believe the current
> text for those items is already correct and this change should not be
> necessary.
>
> --
> Russ Allbery ([e-mail])             <http://www.eyrie.org/~eagle/>

Russ,
thanks for your very quick responses.

The Control syntax seems to be the single issue that needs elaboration.
(I did not want to add too much stuff to the Errata note.)

Quoting from RFC 5536, Section 3.2.3, on top of page 18:

   control         =  "Control:" SP *WSP control-command *WSP CRLF

   control-command =  verb *( 1*WSP argument )
   verb            =  token
   argument        =  1*( %x21-7E )

These are the syntax rules for the entire header field, giving
the header field name, "Control", the separating colon ":",
and the general syntax of the header field value, essentially
<control-command> plus enclosing optional whitespace.

RFC 5537 imports the <control-command> rule (cf. Section 1.4,
on page 4) and states in the second paragraph of Section 5
(please note the "of" in the first line here!):

   The <control-command> of a Control header field comprises a <verb>,
   which indicates the action to be taken, and one or more <argument>
   values, which supply the details.  For some control messages, the
   body of the article is also significant.  Each recognized <verb> (the
   control message type) is described in a separate section below. [...]

Hence, for instance for (e), the ABNF in Section 5.2.1 of RFC 5537,

        control-command     =/ Newgroup-command
        Newgroup-command    = "newgroup" Newgroup-arguments
        Newgroup-arguments  = 1*WSP newsgroup-name
                              [ 1*WSP newgroup-flag ]
        newgroup-flag       = "moderated"

augments the syntax rule for the Control header field *value*.

The syntax of the entire Control header field is still given
by the <control> ABNF production from RFC 5536 (quoted above).
However, taking the RFC prose text literally,

             ...   The syntax of its Control header field is:
        control-command     =/ Newgroup-command
        ...
would pretend to indicate that the "Control:" part were dropped here!

That's why the Errata note adjusts the text to say:
                                                         vvvvvvv
|            ...   The syntax of its Control header field value is:
        control-command     =/ Newgroup-command
        ...

Does that suffice for clarification?

The iterated instances in 5.2.2, 5.2.3, 5.3, and 5.5 are analogous.

Kind regards,
  Alfred HÎnes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+



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 nBSK3Yku031682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Dec 2009 13:03:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBSK3YaU031681; Mon, 28 Dec 2009 13:03:34 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBSK3XMc031673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 28 Dec 2009 13:03:33 -0700 (MST) (envelope-from [e-mail])
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nBSK2Bcg004972; Mon, 28 Dec 2009 12:02:12 -0800 (PST)
Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id nBSK2Afn004944; Mon, 28 Dec 2009 12:02:10 -0800 (PST)
Date: Mon, 28 Dec 2009 12:02:10 -0800 (PST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: [Technical Errata Reported] RFC5537 (1993)
From: RFC Errata System <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

The following errata report has been submitted for RFC5537,
"Netnews Architecture and Protocols".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5537&eid=1993

--------------------------------------
Type: Technical
Reported by: Julien Élie <[e-mail]>

Section: 5.2.1.1

Original Text
-------------
  A newgroup control message requesting creation of the moderated
  newsgroup example.admin.info.

      From: "example.* Administrator" <[e-mail]>
      Newsgroups: example.admin.info
      Date: 27 Feb 2002 12:50:22 +0200
      Subject: cmsg newgroup example.admin.info moderated
      Approved: [e-mail]
      Control: newgroup example.admin.info moderated
      Message-ID: <[e-mail]>
      MIME-Version: 1.0
      Content-Type: multipart/mixed; boundary="nxtprt"
      Content-Transfer-Encoding: 8bit

Corrected Text
--------------
  A newgroup control message requesting creation of the moderated
  newsgroup example.admin.info.

|     Path: not-for-mail
      From: "example.* Administrator" <[e-mail]>
      Newsgroups: example.admin.info
      Date: 27 Feb 2002 12:50:22 +0200
      Subject: cmsg newgroup example.admin.info moderated
      Approved: [e-mail]
      Control: newgroup example.admin.info moderated
      Message-ID: <[e-mail]>
      MIME-Version: 1.0
      Content-Type: multipart/mixed; boundary="nxtprt"
      Content-Transfer-Encoding: 8bit

Notes
-----
As the mandatory Path: header field is missing, this control message is only a proto-article.

A control message is defined in Section 5 as an article which contains a Control: header field.  Therefore, a Path: header field should be added to the headers of this sample newgroup control article.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5537 (draft-ietf-usefor-usepro-14)
--------------------------------------
Title               : Netnews Architecture and Protocols
Publication Date    : November 2009
Author(s)           : R. Allbery, Ed., C. Lindsey
Category            : PROPOSED STANDARD
Source              : Usenet Article Standard Update
Area                : Applications
Stream              : IETF
Verifying Party     : IESG



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 nBSJiEoZ030487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Dec 2009 12:44:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBSJiEUT030486; Mon, 28 Dec 2009 12:44:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 nBSJiDo7030479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 28 Dec 2009 12:44:14 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 86BA418F57C; Mon, 28 Dec 2009 11:44:13 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) by smtp.stanford.edu (Postfix) with ESMTP id 591CD18F577; Mon, 28 Dec 2009 11:44:13 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 2BD972F5B9; Mon, 28 Dec 2009 11:44:13 -0800 (PST)
From: Russ Allbery <[e-mail]>
To: RFC Errata System <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: [Technical Errata Reported] RFC5537 (1983)
In-Reply-To: <[e-mail]> (RFC Errata System's message of "Mon, 28 Dec 2009 05:43:17 -0800 (PST)")
Organization: The Eyrie
References: <[e-mail]>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Date: Mon, 28 Dec 2009 11:44:13 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

RFC Errata System <[e-mail]> writes:

> Notes
> -----
> Rationale:
>   RFC 5537 does not follow the IETF standard terminology reinforced
>   by RFC 4288 and does not properly use the media type registration
>   template from Section 10 of RFC 4288.
>   RFC 4288 clarifies that IETF media types (and subtypes) have
>   outgrown the Internet Email MIME environment and now are used
>   in non-email environments as well; for instance in the context
>   of Netnews (this RFC!).  Therefore, all mention of "MIME" in the
>   context of Internet media types must be avoided.  See Sections 1
>   through 3 of RFC 4288 for more rationale and Section 10 there for
>   the registration template to be used since RFC 4288, in 2005.

I missed this change when updating the document from RFC 2048 to RFC 4288.
It is correct.  Thank you!

-- 
Russ Allbery ([e-mail])             <http://www.eyrie.org/~eagle/>



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 nBSJfG31030261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Dec 2009 12:41:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBSJfGZ2030260; Mon, 28 Dec 2009 12:41:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 nBSJfF1u030244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 28 Dec 2009 12:41:16 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C863518F90E; Mon, 28 Dec 2009 11:41:15 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) by smtp.stanford.edu (Postfix) with ESMTP id A248418F5D9; Mon, 28 Dec 2009 11:41:15 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 9FEF52F5B9; Mon, 28 Dec 2009 11:41:15 -0800 (PST)
From: Russ Allbery <[e-mail]>
To: RFC Errata System <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: [Editorial Errata Reported] RFC5537 (1982)
In-Reply-To: <[e-mail]> (RFC Errata System's message of "Mon, 28 Dec 2009 05:09:59 -0800 (PST)")
Organization: The Eyrie
References: <[e-mail]>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Date: Mon, 28 Dec 2009 11:41:15 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

RFC Errata System <[e-mail]> writes:

> Type: Editorial
> Reported by: Alfred Hoenes <[e-mail]>

> Section: 3.4.2, NOTE

> Original Text
> -------------
>        ... unintended repeat injection into the same network, ...
>                            ^

> Corrected Text
> --------------
>        ... unintended repeated injection into the same network, ...
>                            ^^^

I have no real objections to making this change, but I believe either form
is correct English.  The first reads slightly better to me personally.

-- 
Russ Allbery ([e-mail])             <http://www.eyrie.org/~eagle/>



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 nBSJe1fw030175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Dec 2009 12:40:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBSJe1ka030174; Mon, 28 Dec 2009 12:40:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.stanford.edu (smtp1.Stanford.EDU [171.67.219.81]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBSJe0LL030168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 28 Dec 2009 12:40:01 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A7C231785BF; Mon, 28 Dec 2009 11:40:00 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) by smtp.stanford.edu (Postfix) with ESMTP id 25050178535; Mon, 28 Dec 2009 11:39:58 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 1FF822F5B9; Mon, 28 Dec 2009 11:39:58 -0800 (PST)
From: Russ Allbery <[e-mail]>
To: RFC Errata System <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: [Technical Errata Reported] RFC5537 (1981)
In-Reply-To: <[e-mail]> (RFC Errata System's message of "Mon, 28 Dec 2009 05:06:05 -0800 (PST)")
Organization: The Eyrie
References: <[e-mail]>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Date: Mon, 28 Dec 2009 11:39:58 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

RFC Errata System <[e-mail]> writes:

> Type: Technical
> Reported by: Alfred Hoenes <[e-mail]>

> Section: 3.2.1

> Original Text
> -------------
> ... first paragraph:

>    If a relaying or serving agent receives an article from an injecting
> |  or serving agent that is part of the same news server, it MAY leave
>       ^^^^^^^
>    the Path header field of the article unchanged.  [...]

> Corrected Text
> --------------
>    If a relaying or serving agent receives an article from an injecting
> |  or relaying agent that is part of the same news server, it MAY leave
>       ^^^^^^^^
>    the Path header field of the article unchanged.  [...]

> Notes
> -----
> Rationale:
>   Cf. the definition of agent roles presented in Section 1 and the
>   first paragraph of Section 3:
>   Serving agents only forward to reading agents, and in that step,
>   the articles are not modified in any way.

This change is correct.  Thank you!

-- 
Russ Allbery ([e-mail])             <http://www.eyrie.org/~eagle/>



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 nBSJdIRh030126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Dec 2009 12:39:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBSJdIUH030125; Mon, 28 Dec 2009 12:39:18 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 nBSJdHO5030116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 28 Dec 2009 12:39:17 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C94E618F57E; Mon, 28 Dec 2009 11:39:16 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) by smtp.stanford.edu (Postfix) with ESMTP id D0F9D18F479; Mon, 28 Dec 2009 11:39:13 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id CC8442F5B9; Mon, 28 Dec 2009 11:39:13 -0800 (PST)
From: Russ Allbery <[e-mail]>
To: RFC Errata System <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: [Editorial Errata Reported] RFC5537 (1980)
In-Reply-To: <[e-mail]> (RFC Errata System's message of "Mon, 28 Dec 2009 04:59:22 -0800 (PST)")
Organization: The Eyrie
References: <[e-mail]>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Date: Mon, 28 Dec 2009 11:39:13 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

RFC Errata System <[e-mail]> writes:

> 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.

Argh, I thought I caught all of these.  I'm sorry about that.  The
corrections (a), (b), (c), (d), (h), and (k) are correct.

>   Similarly, denoting as "header field" a "header field value" is
>   confusing -- items (e), (f), (g), (i), and (j) above.

I don't understand the rationale for this change.  I believe the current
text for those items is already correct and this change should not be
necessary.

-- 
Russ Allbery ([e-mail])             <http://www.eyrie.org/~eagle/>



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 nBSDjm2L009686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Dec 2009 06:45:48 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBSDjm7K009685; Mon, 28 Dec 2009 06:45:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBSDjjXA009677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 28 Dec 2009 06:45:45 -0700 (MST) (envelope-from [e-mail])
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nBSDhHKR018792; Mon, 28 Dec 2009 05:43:18 -0800 (PST)
Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id nBSDhHRJ018791; Mon, 28 Dec 2009 05:43:17 -0800 (PST)
Date: Mon, 28 Dec 2009 05:43:17 -0800 (PST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: [Technical Errata Reported] RFC5537 (1983)
From: RFC Errata System <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

The following errata report has been submitted for RFC5537,
"Netnews Architecture and Protocols".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5537&eid=1983

--------------------------------------
Type: Technical
Reported by: Alfred Hoenes <[e-mail]>

Section: GLOBAL

Original Text
-------------
(a)  Section 3.10, first paragraph:

   A gateway transforms an article into the native message format of
   another medium, or translates the messages of another medium into
   news articles, or transforms articles into proto-articles for
   injection into a separate Netnews network.  Encapsulation of a news
|  article into a message of MIME type application/news-transmission, or
   the subsequent undoing of that encapsulation, is not gatewaying since
   it involves no transformation of the article.


(b)  Section 4 (page 29):

|  The updated MIME media type definition of message/news is:

|    MIME type name:           message

|    MIME subtype name:        news
 
     Required parameters:      ...


(c)  Section 4.1 (bottom of page 30):

|  The MIME media type definition of application/news-transmission is:

|    MIME type name:           application

|    MIME subtype name:        news-transmission

     Required parameters:      ...


(d)  Section 4.2 (bottom of page 31 plus top of page 32):

|  The MIME media type definition of application/news-groupinfo is:

|     MIME type name:           application

|     MIME subtype name:        news-groupinfo

      Required parameters:      none

      Optional parameters:      charset, which MUST be a charset
|                               registered for use with MIME text types.
                                It has the same syntax as the parameter
                                defined for text/plain [RFC2046].  [...]


(e)   Section 4.3 (page 33):

|  The MIME media type definition of application/news-checkgroups is:

|     MIME type name:           application

|     MIME subtype name:        news-checkgroups

      Required parameters:      none

      Optional parameters:      charset, which MUST be a charset
|                               registered for use with MIME text types.
                                It has the same syntax as the parameter
                                defined for text/plain [RFC2046].


Corrected Text
--------------
(a)  Section 3.10, first paragraph:

   A gateway transforms an article into the native message format of
   another medium, or translates the messages of another medium into
   news articles, or transforms articles into proto-articles for
   injection into a separate Netnews network.  Encapsulation of a news
|  article into a message of media type application/news-transmission,
   or the subsequent undoing of that encapsulation, is not gatewaying
   since it involves no transformation of the article.


(b)  Section 4 (page 29):

|  The updated media type definition of message/news is:

|     Type name:                message

|     Subtype name:             news
 
      Required parameters:      ...


(c)  Section 4.1 (bottom of page 30):

|  The media type definition of application/news-transmission is:

|     Type name:                application

|     Subtype name:             news-transmission

      Required parameters:      ...


(d)  Section 4.2 (bottom of page 31 plus top of page 32):

|  The media type definition of application/news-groupinfo is:

|     Type name:                application

|     Subtype name:             news-groupinfo

      Required parameters:      none

      Optional parameters:      charset, which MUST be a charset
|                               registered for use with 'text' media
                                types.
                                It has the same syntax as the parameter
                                defined for text/plain [RFC2046].  [...]


(e)   Section 4.3 (page 33):

|  The media type definition of application/news-checkgroups is:

|     Type name:                application

|     Subtype name:             news-checkgroups

      Required parameters:      none

      Optional parameters:      charset, which MUST be a charset
|                               registered for use with 'text' media
                                types.
                                It has the same syntax as the parameter
                                defined for text/plain [RFC2046].



Notes
-----
Rationale:
  RFC 5537 does not follow the IETF standard terminology reinforced
  by RFC 4288 and does not properly use the media type registration
  template from Section 10 of RFC 4288.
  RFC 4288 clarifies that IETF media types (and subtypes) have
  outgrown the Internet Email MIME environment and now are used
  in non-email environments as well; for instance in the context
  of Netnews (this RFC!).  Therefore, all mention of "MIME" in the
  context of Internet media types must be avoided.  See Sections 1
  through 3 of RFC 4288 for more rationale and Section 10 there for
  the registration template to be used since RFC 4288, in 2005.

Editorial Note (keep for update):
  The structure of Section 4 would perhaps more reasonably have been
  split into a single-paragraph Section 4 and packing the remainder
  of 4. into a new subsection 4.1, "Obsolescence of message/news",
  with the remaining subsection numbers 4.* bumped accordingly.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5537 (draft-ietf-usefor-usepro-14)
--------------------------------------
Title               : Netnews Architecture and Protocols
Publication Date    : November 2009
Author(s)           : R. Allbery, Ed., C. Lindsey
Category            : PROPOSED STANDARD
Source              : Usenet Article Standard Update
Area                : Applications
Stream              : IETF
Verifying Party     : IESG



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 nBSDBQO2007490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Dec 2009 06:11:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBSDBQYP007489; Mon, 28 Dec 2009 06:11:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBSDBPFh007482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 28 Dec 2009 06:11:25 -0700 (MST) (envelope-from [e-mail])
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nBSD9xdn004475; Mon, 28 Dec 2009 05:10:00 -0800 (PST)
Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id nBSD9x2R004474; Mon, 28 Dec 2009 05:09:59 -0800 (PST)
Date: Mon, 28 Dec 2009 05:09:59 -0800 (PST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: [Editorial Errata Reported] RFC5537 (1982)
From: RFC Errata System <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

The following errata report has been submitted for RFC5537,
"Netnews Architecture and Protocols".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5537&eid=1982

--------------------------------------
Type: Editorial
Reported by: Alfred Hoenes <[e-mail]>

Section: 3.4.2, NOTE

Original Text
-------------
       ... unintended repeat injection into the same network, ...
                           ^

Corrected Text
--------------
       ... unintended repeated injection into the same network, ...
                           ^^^

Notes
-----


Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5537 (draft-ietf-usefor-usepro-14)
--------------------------------------
Title               : Netnews Architecture and Protocols
Publication Date    : November 2009
Author(s)           : R. Allbery, Ed., C. Lindsey
Category            : PROPOSED STANDARD
Source              : Usenet Article Standard Update
Area                : Applications
Stream              : IETF
Verifying Party     : IESG



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 nBSD7BGD007130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Dec 2009 06:07:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBSD7BmT007129; Mon, 28 Dec 2009 06:07:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBSD79wh007121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 28 Dec 2009 06:07:10 -0700 (MST) (envelope-from [e-mail])
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nBSD65ig003013; Mon, 28 Dec 2009 05:06:06 -0800 (PST)
Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id nBSD65XR003010; Mon, 28 Dec 2009 05:06:05 -0800 (PST)
Date: Mon, 28 Dec 2009 05:06:05 -0800 (PST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: [Technical Errata Reported] RFC5537 (1981)
From: RFC Errata System <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

The following errata report has been submitted for RFC5537,
"Netnews Architecture and Protocols".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5537&eid=1981

--------------------------------------
Type: Technical
Reported by: Alfred Hoenes <[e-mail]>

Section: 3.2.1

Original Text
-------------
... first paragraph:

   If a relaying or serving agent receives an article from an injecting
|  or serving agent that is part of the same news server, it MAY leave
      ^^^^^^^
   the Path header field of the article unchanged.  [...]

Corrected Text
--------------
   If a relaying or serving agent receives an article from an injecting
|  or relaying agent that is part of the same news server, it MAY leave
      ^^^^^^^^
   the Path header field of the article unchanged.  [...]

Notes
-----
Rationale:
  Cf. the definition of agent roles presented in Section 1 and the
  first paragraph of Section 3:
  Serving agents only forward to reading agents, and in that step,
  the articles are not modified in any way.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5537 (draft-ietf-usefor-usepro-14)
--------------------------------------
Title               : Netnews Architecture and Protocols
Publication Date    : November 2009
Author(s)           : R. Allbery, Ed., C. Lindsey
Category            : PROPOSED STANDARD
Source              : Usenet Article Standard Update
Area                : Applications
Stream              : IETF
Verifying Party     : IESG



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 nBSD0nDn006700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Dec 2009 06:00:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBSD0nYg006699; Mon, 28 Dec 2009 06:00:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBSD0m2X006690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 28 Dec 2009 06:00:48 -0700 (MST) (envelope-from [e-mail])
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nBSCxOqB000437; Mon, 28 Dec 2009 04:59:24 -0800 (PST)
Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id nBSCxM0x000430; Mon, 28 Dec 2009 04:59:22 -0800 (PST)
Date: Mon, 28 Dec 2009 04:59:22 -0800 (PST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: [Editorial Errata Reported] RFC5537 (1980)
From: RFC Errata System <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

The following errata report has been submitted for RFC5537,
"Netnews Architecture and Protocols".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5537&eid=1980

--------------------------------------
Type: Editorial
Reported by: Alfred Hoenes <[e-mail]>

Section: GLOBAL

Original Text
-------------
(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:
   
    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.
         
(d)  Section 3.6, first paragraph

|          ... forgery of Path and Injection-Info headers, ...
 
(e)  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
         [...]

(f)  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:

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

(h)  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.

(i)  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:

(j)  Section 5.5, second paragraph:

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

(k)  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.4, second paragraph:

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

(c)  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.

(d)  Section 3.6, first paragraph

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

(e)  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
|  value is:
         
         control-command     =/ Newgroup-command
         Newgroup-command    = "newgroup" Newgroup-arguments
         [...]

(f)  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 value is:

(g)  Section 5.2.3, first paragraph:

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

(h)  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.

(i)  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 value is:

(j)  Section 5.5, second paragraph:

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


(k)  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 value" is
  confusing -- items (e), (f), (g), (i), and (j) above.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5537 (draft-ietf-usefor-usepro-14)
--------------------------------------
Title               : Netnews Architecture and Protocols
Publication Date    : November 2009
Author(s)           : R. Allbery, Ed., C. Lindsey
Category            : PROPOSED STANDARD
Source              : Usenet Article Standard Update
Area                : Applications
Stream              : IETF
Verifying Party     : IESG



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 nBSCC7tt003573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Dec 2009 05:12:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBSCC71I003572; Mon, 28 Dec 2009 05:12:07 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id nBSCC3YA003564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 28 Dec 2009 05:12:03 -0700 (MST) (envelope-from [e-mail])
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id nBSCApMR010290; Mon, 28 Dec 2009 04:10:52 -0800 (PST)
Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id nBSCAox5010283; Mon, 28 Dec 2009 04:10:50 -0800 (PST)
Date: Mon, 28 Dec 2009 04:10:50 -0800 (PST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: [Editorial Errata Reported] RFC5536 (1979)
From: RFC Errata System <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

The following errata report has been submitted for RFC5536,
"Netnews Article Format".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5536&eid=1979

--------------------------------------
Type: Editorial
Reported by: Alfred Hoenes <[e-mail]>

Section: 3.2.7

Original Text
-------------
... in the 2nd paragraph:

   However, software that predates this standard does not use this
|  header, and therefore agents MUST accept articles without the
   Injection-Date header field.


Corrected Text
--------------
   However, software that predates this standard does not use this
|  header field, and therefore agents MUST accept articles without the
   Injection-Date header field.


Notes
-----
Rationale:
  The whole RFC is precise in its use of the IETF standard terminology
  as explained in Section 2.1.  This phrase is an exception; here as
  well "header" should be "header field".

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5536 (draft-ietf-usefor-usefor-12)
--------------------------------------
Title               : Netnews Article Format
Publication Date    : November 2009
Author(s)           : K. Murchison, Ed., C. Lindsey, D. Kohn
Category            : PROPOSED STANDARD
Source              : Usenet Article Standard Update
Area                : Applications
Stream              : IETF
Verifying Party     : IESG



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 nBNJDgwK084814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Dec 2009 12:13:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBNJDgVg084813; Wed, 23 Dec 2009 12:13:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 nBNJDeDZ084807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 23 Dec 2009 12:13:41 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3E204170D62 for <[e-mail]>; Wed, 23 Dec 2009 11:13:40 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) by smtp.stanford.edu (Postfix) with ESMTP id D03DB170D3E for <[e-mail]>; Wed, 23 Dec 2009 11:13:39 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id CA19B2F5B9; Wed, 23 Dec 2009 11:13:39 -0800 (PST)
From: Russ Allbery <[e-mail]>
To: "Usefor WG" <[e-mail]>
Subject: Re: Number of occurrences of headers
In-Reply-To: <F860E176B5CC4BA8A7BC475A7502604B@Iulius> ("Julien =?utf-8?Q?=C3=89LIE=22's?= message of "Wed, 23 Dec 2009 17:25:06 +0100")
Organization: The Eyrie
References: <F860E176B5CC4BA8A7BC475A7502604B@Iulius>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Date: Wed, 23 Dec 2009 11:13:39 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Julien =C3=89LIE <[e-mail]> writes:

> I am currently adding support for the new header fields defined in RFC 55=
36
> and 5537 in INN.

> 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.

--=20
Russ Allbery ([e-mail])             <http://www.eyrie.org/~eagle/>



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 nBNGP8Sk073552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Dec 2009 09:25:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBNGP8XP073551; Wed, 23 Dec 2009 09:25:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 nBNGP6QD073540 for <[e-mail]>; Wed, 23 Dec 2009 09:25:07 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 3886 invoked by uid 503); 23 Dec 2009 16:25:17 -0000
Received: from b7.ovh.net (HELO mail415.ha.ovh.net) (213.186.33.57) by 42.mail-out.ovh.net with SMTP; 23 Dec 2009 16:25:17 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 23 Dec 2009 16:25:04 -0000
Received: from amontpellier-159-1-21-3.w90-57.abo.wanadoo.fr (HELO Iulius) (julien%trigofacile.com@90.57.92.3) by ns0.ovh.net with SMTP; 23 Dec 2009 16:25:03 -0000
Message-ID: <F860E176B5CC4BA8A7BC475A7502604B@Iulius>
From: =?ISO-8859-15?Q?Julien_=C9LIE?= <[e-mail]>
To: "Usefor WG" <[e-mail]>
Subject: Number of occurrences of headers
Date: Wed, 23 Dec 2009 17:25:06 +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: 4926656519196704185
X-Ovh-Remote: 90.57.92.3 (amontpellier-159-1-21-3.w90-57.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Hi,

I am currently adding support for the new header fields defined in RFC 5536
and 5537 in INN.

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.

Regarding Original-Sender:, isn't one time enough?

-- 
Julien ÉLIE

« Être en vacances, c'est n'avoir rien à faire et avoir
  toute la journée pour le faire. » (Robert Orben)



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 nBMJcAN5003826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Dec 2009 12:38:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBMJcAHi003825; Tue, 22 Dec 2009 12:38:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from 2.mail-out.ovh.net (2.mail-out.ovh.net [91.121.26.226]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id nBMJc8f3003819 for <[e-mail]>; Tue, 22 Dec 2009 12:38:09 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 22002 invoked by uid 503); 22 Dec 2009 20:52:43 -0000
Received: from b7.ovh.net (HELO mail178.ha.ovh.net) (213.186.33.57) by 2.mail-out.ovh.net with SMTP; 22 Dec 2009 20:52:43 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 22 Dec 2009 19:38:07 -0000
Received: from amontpellier-159-1-21-3.w90-57.abo.wanadoo.fr (HELO Iulius) (julien%trigofacile.com@90.57.92.3) by ns0.ovh.net with SMTP; 22 Dec 2009 19:38:04 -0000
Message-ID: <562428FED2024818B7E01DC05DD4086D@Iulius>
From: =?iso-8859-1?Q?Julien_=C9LIE?= <[e-mail]>
To: "Usefor WG" <[e-mail]>
Subject: Tr: WG Review: Internationalized Resource Identifiers (iri)
Date: Tue, 22 Dec 2009 20:38:05 +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: 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: 2313724309224357305
X-Ovh-Remote: 90.57.92.3 (amontpellier-159-1-21-3.w90-57.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Hi,

Don't we have to do something for news: and nntp: as for
internationalized resource identifiers?
It would be about internationalized newsgroup names...

Julien

> Internationalized Resource Identifiers (iri)
> ---------------------------------------
> 
> Description of Working Group:
> 
> This working group will produce
> * A new version of RFC 3987: "Internationalized Resource
> Identifiers (IRIs)" using draft-duerst-iri-bis as the base
> * A new version of RFC 4395: "Guidelines and Registration
> Procedures for New URI Schemes"
> 
> The new version of RFC 3987 may be split into separate documents,
> if, in the opinion of the chair(s), it would facilitate distribution
> of the workload and allow more focused reviews. For example, the
> following breakdown has been suggested:
> 
> * Handling of Internationalized domain names in IRIs (BCP)
> * Internationalization Considerations in IRIs (guidelines
> for BIDI, character ranges to avoid, special considerations) (BCP)
> * Syntax, parsing, comparison of IRIs (Standards track)
> 
> The working group starts with a relatively mature update to
> RFC 3987 in preparation; the primary focus of the group
> is to resolve conflicting uses, requirements and best practices
> for internationalized URLs/URIs/IRIs and various other forms,
> among many specifications and committees, while moving toward
> consistent use of IRIs among the wide range of Internet
> applications that use them. In particular:
> 
> * The IRI specification(s) must (continue to) be suitable
> for normative reference with Web and XML standards from W3C
> specifications. The group should coordinate with the W3C working
> groups on HTML5, XML Core, and Internationalization, as well
> as with IETF HTTPBIS WG to ensure acceptability.
> * The IRI specification(s) should be follow best practices
> for domain names. The group should coordinate with the IETF
> IDNABIS working group and Unicode Consortium to assure acceptability.
> * Explicit review by experts on (and native speakers) of RTL
> languages, of the recommendations for BIDI languages,
> is required.
> 
> The Working Group will examine at least one and possibly more
> URI/IRI schemes to check that the new specification(s) are
> appropriate for existing schemes. Schemes suggested for
> review include http:, pop:, imap:, xmpp:, mailto:, and sip:.
> 
> Changes to RFC 3986 ("Uniform Resource Identifier (URI):
> Generic Syntax") are explicitly out of scope of this charter,
> and may only be considered with a charter update.
> 
> Goals and Milestones:
> 
> January 2010 Additional update of Internet drafts by editor(s)
> February 2010 Review of Internet Drafts, directions during W3C and IETF
> May 2010 Working group Last Call of all documents
> June 2010 Publish IRI documents as RFCs (BCP, standards track, as 
> appropriate)



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 nBJK2WxE074613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Dec 2009 13:02:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBJK2W59074612; Sat, 19 Dec 2009 13:02:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 nBJK2VRQ074605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 19 Dec 2009 13:02:31 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 093D218F984; Sat, 19 Dec 2009 12:02:31 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) by smtp.stanford.edu (Postfix) with ESMTP id A248018F980; Sat, 19 Dec 2009 12:02:30 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 8C073256F5; Sat, 19 Dec 2009 12:02:30 -0800 (PST)
From: Russ Allbery <[e-mail]>
To: Julien =?utf-8?Q?=C3=89LIE?= <[e-mail]>
Cc: "Usefor WG" <[e-mail]>
Subject: Re: Missing Path: header in USEPRO newgroup sample
In-Reply-To: <67DE5B56A95E48B09806454303154ACE@Iulius> ("Julien =?utf-8?Q?=C3=89LIE=22's?= message of "Sat, 19 Dec 2009 11:31:59 +0100")
Organization: The Eyrie
References: <67DE5B56A95E48B09806454303154ACE@Iulius>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Date: Sat, 19 Dec 2009 12:02:30 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Julien =C3=89LIE <[e-mail]> writes:

> In RFC 5537 (USEPRO), the newgroup control message example (=C2=A7 5.2.1.=
1)
> does not have the mandatory Path: header field.  It is only a
> proto-article here.

> A control message is defined in =C2=A7 5 as an article which contains a
> Control: header field, so I believe a Path: header field should be added
> in the sample.

Yes, you're right.  That's probably worth an erratum.

--=20
Russ Allbery ([e-mail])             <http://www.eyrie.org/~eagle/>



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 nBJAW53d045375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Dec 2009 03:32:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nBJAW5Da045374; Sat, 19 Dec 2009 03:32:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 nBJAW3qo045368 for <[e-mail]>; Sat, 19 Dec 2009 03:32:04 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 958 invoked by uid 503); 19 Dec 2009 11:20:41 -0000
Received: from b9.ovh.net (HELO mail620.ha.ovh.net) (213.186.33.59) by 27.mail-out.ovh.net with SMTP; 19 Dec 2009 11:20:41 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 19 Dec 2009 10:33:03 -0000
Received: from amontpellier-159-1-62-153.w83-197.abo.wanadoo.fr (HELO Iulius) (julien%trigofacile.com@83.197.141.153) by ns0.ovh.net with SMTP; 19 Dec 2009 10:33:02 -0000
Message-ID: <67DE5B56A95E48B09806454303154ACE@Iulius>
From: =?iso-8859-15?Q?Julien_=C9LIE?= <[e-mail]>
To: "Usefor WG" <[e-mail]>
Subject: Missing Path: header in USEPRO newgroup sample
Date: Sat, 19 Dec 2009 11:31:59 +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: 12384336027378908601
X-Ovh-Remote: 83.197.141.153 (amontpellier-159-1-62-153.w83-197.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Hi,

In RFC 5537 (USEPRO), the newgroup control message example (§ 5.2.1.1)
does not have the mandatory Path: header field.  It is only a proto-article
here.

A control message is defined in § 5 as an article which contains
a Control: header field, so I believe a Path: header field should be
added in the sample.

-- 
Julien ÉLIE

« -- Du potage : c'est tout ce que le cuisinier a pu faire !
  -- Ce blocus devient très horripilant !
  -- Blocus, c'est ton cuisinier ? » (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 nB5KwnHJ026356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Dec 2009 13:58:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nB5KwmLN026355; Sat, 5 Dec 2009 13:58:48 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 nB5KwkP3026347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Sat, 5 Dec 2009 13:58:48 -0700 (MST) (envelope-from [e-mail])
Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 77DCF18F93B for <[e-mail]>; Sat,  5 Dec 2009 12:58:46 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) by smtp.stanford.edu (Postfix) with ESMTP id 0919018F925 for <[e-mail]>; Sat,  5 Dec 2009 12:58:46 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id 03BF52F4E8; Sat,  5 Dec 2009 12:58:46 -0800 (PST)
From: Russ Allbery <[e-mail]>
To: "Usefor WG" <[e-mail]>
Subject: Re: Lines count in USEFOR
In-Reply-To: <AB85CBC60CDB466587588F8969B55181@Iulius> ("Julien =?utf-8?Q?=C3=89LIE=22's?= message of "Sat, 5 Dec 2009 13:27:47 +0100")
Organization: The Eyrie
References: <AB85CBC60CDB466587588F8969B55181@Iulius>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Date: Sat, 05 Dec 2009 12:58:45 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Julien =C3=89LIE <[e-mail]> writes:

> Hmm...
> And what happens to currently existing headers feeds?  (look at Diablo
> for instance)

> The Lines: header is still useful (and probably also the Bytes: one)
> to have an idea of the length of the body of the article.

I suspect the right thing to do there is to define the header feed as
providing the NNTP :lines and :bytes metadata as opposed to actual headers
from the article.

--=20
Russ Allbery ([e-mail])             <http://www.eyrie.org/~eagle/>



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 nB5CRvv7082194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Dec 2009 05:27:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id nB5CRuRj082192; Sat, 5 Dec 2009 05:27:56 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 nB5CRrRr082184 for <[e-mail]>; Sat, 5 Dec 2009 05:27:55 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 23945 invoked by uid 503); 5 Dec 2009 12:28:00 -0000
Received: from b6.ovh.net (HELO mail240.ha.ovh.net) (213.186.33.56) by 42.mail-out.ovh.net with SMTP; 5 Dec 2009 12:28:00 -0000
Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 5 Dec 2009 12:27:52 -0000
Received: from aaubervilliers-151-1-55-6.w83-112.abo.wanadoo.fr (HELO Iulius) (julien%trigofacile.com@83.112.28.6) by ns0.ovh.net with SMTP; 5 Dec 2009 12:27:50 -0000
Message-ID: <AB85CBC60CDB466587588F8969B55181@Iulius>
From: =?iso-8859-15?Q?Julien_=C9LIE?= <[e-mail]>
To: "Usefor WG" <[e-mail]>
Subject: Re: Lines count in USEFOR
Date: Sat, 5 Dec 2009 13:27:47 +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.6001.18000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.6001.18049
X-Ovh-Tracer-Id: 5892397163757764025
X-Ovh-Remote: 83.112.28.6 (aaubervilliers-151-1-55-6.w83-112.abo.wanadoo.fr)
X-Ovh-Local: 213.186.33.20 (ns0.ovh.net)
X-Spam-Check: DONE|U 0.5/N
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>

Hi,

> 3.3.1.  Lines
>
>   The Lines header field indicates the number of lines in the <body>
>   (as defined in [RFC5322]) of the article.
>
>   lines           =  "Lines:" SP *WSP 1*DIGIT *WSP CRLF
>
>   The line count is the number of CRLF separators in the <body>.
>
>   Historically, this header field was used by the NNTP [RFC3977]
>   overview facility, but its use for this purpose is now deprecated.
>   As a result, this header field is to be regarded as obsolescent, and
>   it is likely to be removed entirely in a future version of this
>   standard.  All agents SHOULD ignore it and SHOULD NOT generate it.

Hmm...
And what happens to currently existing headers feeds?  (look at Diablo
for instance)

The Lines: header is still useful (and probably also the Bytes: one)
to have an idea of the length of the body of the article.

-- 
Julien ÉLIE

« Pour défendre une cause, un avocat met sa robe. Une femme... l'enlève. »