http://blog.gmane.org/gmane.ietf.usenet.format hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.usenet.format/32485 <pre> Hi all, In the IETF working group for IMA (Internationalized eMail Address), there is a current thread about UTF-8 in message-IDs: http://www.ietf.org/mail-archive/web/ima/current/threads.html#04330 Quick references in the thread: http://www.ietf.org/mail-archive/web/ima/current/msg04430.html http://www.ietf.org/mail-archive/web/ima/current/msg04344.html http://www.ietf.org/mail-archive/web/ima/current/msg04345.html http://www.ietf.org/mail-archive/web/ima/current/msg04420.html http://www.ietf.org/mail-archive/web/ima/current/msg04422.html RFC 5536 (USEFOR) currently allows only ASCII characters in message-IDs. INN 2.4 and INN 2.5 have always rejected message-IDs containing non-ASCII chars. (I have not looked at INN 2.3 and before.) When a message-ID is not valid per RFC 850/1036/... and now 5536, the article is rejected. 200 news.trigofacile.com InterNetNews server INN 2.6.0 (20110908 prerelease) ready (transit mode) IHAVE &lt;©&lt; at &gt;fr&gt; 435 Syntax error in message-ID MODE READER 200 news.trigofacile.com InterNetNews NNRP server INN 2.6.0 (20111003 prerelease) ready (posting ok) ARTICLE &lt;©&lt; at &gt;test&gt; 501 Syntax error in message-ID QUIT 205 Bye! (Note that 435 is answered to IHAVE for legacy reasons; 501 should be the real response code per RFC 3977.) My question is: should we try right now to relax the check so as to allow UTF-8 in message-IDs? If yes, is there something else to enforce? (NFC normalization?) Of course, other requirements from RFC 5536 will remain (that is to say no comments in the Message-ID: header field, and no "&gt;" or WSP). U+00A0 (&amp;nbsp; in HTML) and other spaces encoded in UTF-8 are allowed, aren't they? We plan on releasing INN 2.5.3 soon, so perhaps we can relax the check starting from INN 2.5.3. I will ask in the INN workers mailing-list, if naturally there is no complaints in this USEFOR mailing-list against going this way. </pre> Julien ÉLIE 2011-10-09T19:27:16 http://comments.gmane.org/gmane.ietf.usenet.format/32481 <pre> Hi all, When specifying internationalized newsgroup names, will other separators than the usual dot between newsgroup components be considered? RFC 3490 (Internationalizing Domain Names in Applications) mentions: 1) Whenever dots are used as label separators, the following characters MUST be recognized as dots: U+002E (full stop), U+3002 (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61 (halfwidth ideographic full stop). Of course, newsgroup names can go on using only the usual full stop. Anyway, it would perhaps be interesting to allow other kind of full stops. DNS uses them (but e-mail does not allow them). It was just a suggestion. Maybe silly... </pre> Julien ÉLIE 2010-03-23T20:48:31 http://comments.gmane.org/gmane.ietf.usenet.format/32473 <pre> There is now an experimental protocol for UTF-8 headers in Email (RFC5335 and its relations). This was the product of the IMA WG. There has been recent discussion of applying this to Netnews, and the conclusion seems to be that the IMA WG is not the place to do this, and that a private draft would be the way to do this. However, this list would be a reasonable place to discuss it. Essentially, under this protocol, UTF-8 may be freely used in Email headers, but a downgrading mechanism is needed whenever mail passes to a server that does not advertise the UTF8SMTP capability. This is much what the USEFOR WG wanted to do in its earlier days, but the decision was then taken to postpone it until the base documents were complete, and then to bring it up again as an Experimental protocol. So maybe now is the time to embark on it. It is much easier with Netnews than with Email, since the underlying transport (whether NNTP or UUCP) is already 8-bit clean. I would not expect it to become the norm on the Big-8 groups for quite some time, but it would be very useful for National hierarchies, such as the Scandinavian ones where the inability to have Newsgroup Names with their own special characters in them is a right pain (apparently). So the experimental protocol would start off with the extensions allowed by RFC5535, and then add UTF-8 in the Newsgroups header. It would be up to individual hierarchies to encourage deployment of the experiment within their groups. It has already been established that the existing transport mechanisms will move such articles around without problem. No downgrading is envisaged except at gateways to email (at which point the mechanisms already agreed for EAI/IMA would apply). But existing servers would cope fairly well without modification, at least until UTF-8 newsgroup-names were introduced. Clearly, anyone expecting to read such articles would need a suitable client. Some clients will already display them (Opera, for example). otherwise, it would be up to people to install suitable user agents if they wanted to see these articles properly (existing agents might display such headers in a garbled form (which might be good enough in languages which wers based on Latin alphabets). Bodies would still expect to be covered by a Content-Type: test/plain; charset=utf-8. With utf-8 newsgroup-names, again people who wanted to subscribe to such groups would need suitable clients, but existing servers would serve them once they had been persuaded to store them in their active lists. That would require control messages that created such groups to be accepted, and also articles submitted to moderated groups to be forwarded, so in practice people who wanted to subscribe to such groups would need to connect to servers which had been upgraded to cope. But the important point is that articles would still propagate correctly through non-upgraded servers. Some early USEFOR drafts show how the Newsgroups header was to be extended. In particular, it required some very strict normalization, so that a simple byte-by-byte comparison of newsgroup-names would always work. Note that an experimental group dk.test.utf8-æøå (which should show up in UTF-8 clients properly, althoug this message is somposed in iso-8859-1) already exists on several servers, notably on news.dotsrc.org, and this message is crossposted there, and if a thread develops there, then well and good. But people on that list might do better to subscribe to the usefor mailing list (see http://www.imc.org/ietf-usefor/index.html). </pre> Charles Lindsey 2010-02-01T18:06:57 http://comments.gmane.org/gmane.ietf.usenet.format/32471 <pre> Hi all, For they who are interested, I have just sent a newgroup control article for local.test.υτφ8 so that you could retrieve it and eventually process it (changing "local" to whatever you want): &lt;news:newgroup-local-test-utf8-1264843277&lt; at &gt;news.trigofacile.com&gt; Note for inn-workers -------------------- I confirm it works fine with INN provided that we remove the check for [^a-z0-9+_\-] in a newsgroup name (enforced by controlchan). I suggest that we remove it in INN 2.5.2. We can reintegrate a better check with allowed UTF-8 values in future versions of INN. Note for USEFOR --------------- In case someone wants to see what the result is, you can use news.trigofacile.com on port 119. The trigofacile.test.υτφ8 newsgroup has been created in UTF-8. It is readable by everyone. If you want to post, authenticate with user "test" and password "test". The group properly shows up in LIST ACTIVE and LIST NEWSGROUPS. Unfortunately, Windows Mail is unable to post to it... It says the group does not exist and refuses to send my post. Well, let's crosspost then to trigofacile.test.υτφ8 and trigofacile.test. And what does Windows Mail send to the server? Newsgroups: =?UTF-8?Q?trigofacile.test.=CF=85=CF=84=CF=868=2Ctrigofacil?=\r\n \t=?UTF-8?Q?e.test?=\r\n Followup-To: =?UTF-8?Q?trigofacile.test.=CF=85=CF=84=CF=868?=\r\n Gosh, that's not a success at all for Windows Mail :-/ </pre> Julien ÉLIE 2010-01-30T09:55:50 http://comments.gmane.org/gmane.ietf.usenet.format/32470 <pre> Hi all, I've just asked in fr.usenet.8bits and fr.usenet.forums.evolution whether we could create in fr.* a testing UTF-8 newsgroup name. Michel Guillou reports that DNews fails to use such names: &lt;news:2jt6m5tsg8arj09lbhd266rd96p9s2qeqs&lt; at &gt;meta.neottia.net&gt; New group {neottia.test.&amp;#965;&amp;#964;&amp;#966;8}, Modflag {y}, Creator {MG} Description {Local, pour les tests dans un forum à nom UTF8.} Group creation failed, check ME feed in newsfeeds.conf and max_groups setting (examine dnews.log too) The corresponding newsgroup is: neottia.test.υτφ8 </pre> Julien ÉLIE 2010-01-30T09:34:29 http://comments.gmane.org/gmane.ietf.usenet.format/32464 <pre> Hi, According to previous discussion on the mailing-list, I reckon that the statuses of current open errata for RFCs 5536 and 5537 are: 1979 -&gt; still no validation, though I believe it should be VERIFIED. Can someone confirm? 1980 -&gt; it should be reworded as follows, and VERIFIED. 1981 -&gt; it should be VERIFIED. 1982 -&gt; I don't know; the original text is right and reads better. Should it be VERIFIED or REJECTED? (with a note added to say that both forms are correct English) 1983 -&gt; it should be VERIFIED. 1993 -&gt; it should be VERIFIED. </pre> Julien ÉLIE 2010-01-15T22:55:44 http://comments.gmane.org/gmane.ietf.usenet.format/32456 <pre> Hi, I follow a discussion that was initiated in news.software.nntp: http://groups.google.fr/group/news.software.nntp/browse_frm/thread/c704d0859dd84d38 &lt;news:slrnhjcc9b.u40.steve&lt; at &gt;news.mixmin.net&gt; According to Section 3.2.8 of RFC 5536: injection-info = "Injection-Info:" SP [CFWS] path-identity [CFWS] *( ";" [CFWS] parameter ) [CFWS] CRLF NOTE: The syntax of &lt;parameter&gt; (Section 5.1 of [RFC2045], as amended by [RFC2231]), taken in conjunction with the folding rules of [RFC0822] (note: not [RFC2822] or [RFC5322]), effectively allows [CFWS] to occur on either side of the "=" inside a &lt;parameter&gt;. I do not understand well that point. Does it mean that CFWS is allowed both before and after the "="? Why should RFC 822 be followed here? And why doesn't RFC 5322 mention that? I thought that RFC 5536 was based upon RFC 5322 and therefore would not allow a space before "=", and would allow a space after "=" only if &lt;value&gt; is a quoted-string. Just afterwards: &lt;attribute&gt; format of &lt;value&gt; -------------------- ----------------- "posting-host" a &lt;host-value&gt; "posting-account" any &lt;value&gt; "logging-data" any &lt;value&gt; "mail-complaints-to" an &lt;address-list&gt; NOTE: Since any such &lt;host-value&gt; or &lt;address-list&gt; also has to be a syntactically correct &lt;value&gt;, it will usually be necessary to encapsulate it as a &lt;quoted-string&gt;, for example: posting-host = "posting.example.com:192.0.2.1" So it shows that a space is allowed before "=". Isn't it a difference with RFC 5322 that ought to be mentioned in appendix C? When it is said that &lt;host-value&gt; is encapsulated as a &lt;quoted-string&gt;, does it mean that: posting-host = "pos\ting.example.com" posting-host = (Comment) "posting.example.com" (Comment) are two valid values for this parameter? (Both being "posting.example.com".) Incidentally, I do not know how to parse posting-host="20bd:20bd::1" It could be the IPv6 address "20bd:20bd::1" or the host name "20bd" associated with the IPv6 address "20bd::1"! </pre> Julien ÉLIE 2010-01-08T23:21:42 http://comments.gmane.org/gmane.ietf.usenet.format/32441 <pre> Hi, Ray, the administrator of news.eternal-september.org, is currently having issues with his users; they complain about the fact that a news server is no longer required to generate a Lines: header. Lots of news readers suddenly break... Especially when they do not use the overview data for the :lines count but only rely on the Lines: header. Ray pointed me out to that thread in alt.free.newsservers: http://groups.google.fr/group/alt.free.newsservers/browse_frm/thread/438e64aa1e740f3e Just following here the issue (in case someone wants to participate). </pre> Julien ÉLIE 2010-01-04T07:15:48 http://comments.gmane.org/gmane.ietf.usenet.format/32438 <pre> 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? </pre> Julien ÉLIE 2009-12-31T16:31:46 http://comments.gmane.org/gmane.ietf.usenet.format/32428 <pre> 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&amp;eid=1993 -------------------------------------- Type: Technical Reported by: Julien Élie &lt;julien&lt; at &gt;trigofacile.com&gt; Section: 5.2.1.1 Original Text ------------- A newgroup control message requesting creation of the moderated newsgroup example.admin.info. From: "example.* Administrator" &lt;admin&lt; at &gt;noc.example&gt; Newsgroups: example.admin.info Date: 27 Feb 2002 12:50:22 +0200 Subject: cmsg newgroup example.admin.info moderated Approved: admin&lt; at &gt;noc.example Control: newgroup example.admin.info moderated Message-ID: &lt;ng-example.admin.info-20020227&lt; at &gt;noc.example&gt; 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" &lt;admin&lt; at &gt;noc.example&gt; Newsgroups: example.admin.info Date: 27 Feb 2002 12:50:22 +0200 Subject: cmsg newgroup example.admin.info moderated Approved: admin&lt; at &gt;noc.example Control: newgroup example.admin.info moderated Message-ID: &lt;ng-example.admin.info-20020227&lt; at &gt;noc.example&gt; 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 </pre> RFC Errata System 2009-12-28T20:02:10 http://comments.gmane.org/gmane.ietf.usenet.format/32423 <pre> 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&amp;eid=1983 -------------------------------------- Type: Technical Reported by: Alfred Hoenes &lt;ah&lt; at &gt;TR-Sys.de&gt; 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 </pre> RFC Errata System 2009-12-28T13:43:17 http://comments.gmane.org/gmane.ietf.usenet.format/32422 <pre> 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&amp;eid=1981 -------------------------------------- Type: Technical Reported by: Alfred Hoenes &lt;ah&lt; at &gt;TR-Sys.de&gt; 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 </pre> RFC Errata System 2009-12-28T13:06:05 http://comments.gmane.org/gmane.ietf.usenet.format/32421 <pre> 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&amp;eid=1982 -------------------------------------- Type: Editorial Reported by: Alfred Hoenes &lt;ah&lt; at &gt;TR-Sys.de&gt; 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 </pre> RFC Errata System 2009-12-28T13:09:59 http://comments.gmane.org/gmane.ietf.usenet.format/32420 <pre> 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&amp;eid=1980 -------------------------------------- Type: Editorial Reported by: Alfred Hoenes &lt;ah&lt; at &gt;TR-Sys.de&gt; 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 </pre> RFC Errata System 2009-12-28T12:59:22 http://comments.gmane.org/gmane.ietf.usenet.format/32419 <pre> 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&amp;eid=1979 -------------------------------------- Type: Editorial Reported by: Alfred Hoenes &lt;ah&lt; at &gt;TR-Sys.de&gt; 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 </pre> RFC Errata System 2009-12-28T12:10:50 http://comments.gmane.org/gmane.ietf.usenet.format/32417 <pre> 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? </pre> Julien ÉLIE 2009-12-23T16:25:06 http://comments.gmane.org/gmane.ietf.usenet.format/32416 <pre> 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 </pre> Julien ÉLIE 2009-12-22T19:38:05 http://comments.gmane.org/gmane.ietf.usenet.format/32414 <pre> 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. </pre> Julien ÉLIE 2009-12-19T10:31:59 http://comments.gmane.org/gmane.ietf.usenet.format/32406 <pre> Hi, In USEPRO, we have: 4.2. application/news-groupinfo newsgroups-line = newsgroup-name [ 1*HTAB newsgroup-description ] [ *WSP moderation-flag ] newsgroup-description = eightbit-utext *( *WSP eightbit-utext ) moderation-flag = SP "(" %x4D.6F.64.65.72.61.74.65.64 ")" ; SPACE + case sensitive "(Moderated)" eightbit-utext = utext / %d127-255 So we can have checkgroups (or newgroup control articles) with: fr.test fr.test.y\tA description. fr.test.m\tA description. (Moderated) fr.test.m.without.desc (Moderated) I do not believe the last one is valid. And even though USEPRO states that "this unusual format is backward-compatible", I think the last one will be considered as an unmoderated newsgroup whose description is "(Moderated)". Isn't it a problem? Empty descriptions are explicitly allowed by the syntax. But when a newsgroup is moderated, I do not see well how to handle empty descriptions in a backward-compatible way, except if a description is mandatory in that case. Incidentally: 3.10.3. Original-Sender Header Field The content syntax makes use of syntax defined in [RFC5536] and [RFC5322]. header =/ Original-Sender-header Original-Sender-header = "Original-Sender" ":" SP Original-Sender-content Original-Sender-content = mailbox But shouldn't it be, with USEFOR [RFC5536] syntax: fields =/ *Original-Sender-header Original-Sender-header = "Original-Sender" ":" SP Original-Sender-content CRLF Original-Sender-content = mailbox </pre> Julien ÉLIE 2009-11-27T21:36:04 http://comments.gmane.org/gmane.ietf.usenet.format/32405 <pre> Does anyone know how to contact Frank Ellermann? It seems that the RFC-Editor has been unable to contact him by email regarding the AUTH48 of RFC 5538 (the News/Nntp URI). He has vanished from this List, on which he used to be a prolific contributor, and his Blog has not been updated since August 2008. </pre> Charles Lindsey 2009-11-26T11:34:41 http://comments.gmane.org/gmane.ietf.usenet.format/32402 <pre> Hi, Section 7.2 of USEAGE mentions that a newsgroup name is limited to 66 characters. Section 3 of RFC 3696 mentions that the local part of an e-mail address is limited to 64 characters. Yet, section 3.5.1 of USEPRO has this note: 3.5.1. Forwarding Messages to a Moderator NOTE: Deriving the email address of the moderator of a group is outside the scope of this document. It is worth mentioning, however, that a common method is to use a forwarding service that handles submissions for many moderated groups. For maximum compatibility with existing news servers, such forwarding services generally form the submission address for a moderated group by replacing each "." in the &lt;newsgroup-name&gt; with "-" and then using that value as the &lt;local-part&gt; of a &lt;mailbox&gt; formed by appending a set domain. Shouldn't a warning be put here? Because the compatibility is not optimum with mailers when a moderated newsgroup contains 65 or 66 characters. Or will it be handled by USEAGE? </pre> Julien ÉLIE 2009-11-20T19:41:08 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.usenet.format