http://permalink.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://permalink.gmane.org/gmane.ietf.usenet.format/32486 <pre> It looks like UTF-8 Message-IDs in mail will start to appear. They would "mostly work" in news it they happened to be encountered (and might well route around sites that did awkward things with them). So I suggest simply removing the check in INN would be a good idea - and likewise similar checks on other headers (but not Date:, I think). It is simply a matter of "being liberal in what you accept", which is a fine thing to do except when it is obviously going to lead to breakage. But I wouldn't do anything about normalization at this stage. That problem only arises if intermediate sites try to rewrite (or "improve") what they received, and that would likely do more harm than good. And, as the EAI standards seem about to become proposed standards, perhaps it is time to revive the idea of UTF-8 in Newsgroup names. There are some early Usefor drafts proposing how it should be done, and they DID contain severe restrictions on allowed characters and strict NFC normalization (but essentially to be en</pre> Charles Lindsey 2011-10-10T10:21:54 http://permalink.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.trigofac</pre> Julien ÉLIE 2011-10-09T19:27:16 http://permalink.gmane.org/gmane.ietf.usenet.format/32484 <pre> OK, I shall look at that Tuits permitting. But current thinking is that News should be extended with EAI (when that has settled down), so downgrading should only be needed when gatewaying to non-EAI email, at which point the Newsgroups header is only for information. But since newsgroup-names are case insensitive and pretty similar in appearance to domain names, then punycoding them should be pretty straightforward. But so long as newsgroups names remain within the netnews environment, vicious normalization will be essential, because they will be routed by the simplest of octet-for-octet comparisons. </pre> Charles Lindsey 2010-03-30T13:31:16 http://permalink.gmane.org/gmane.ietf.usenet.format/32483 <pre> Hi! 2010/3/24 Charles Lindsey &lt;chl&lt; at &gt;clerew.man.ac.uk&gt;: Thanks for posting this here. There's also a proposal for newsgroup names: http://www.ietf.org/internet-drafts/draft-teint-xidna-newsgroup-00.txt NT </pre> Nick Teint 2010-03-26T11:12:45 http://permalink.gmane.org/gmane.ietf.usenet.format/32482 <pre> I would hope we would insist on U+002E (full stop). The idea always was to insist on NFKC normalization, which I would expect to collapse all of those. BTW, http://www.ietf.org/internet-drafts/draft-teint-xidna-base-00.txt http://www.ietf.org/internet-drafts/draft-teint-xidna-email-00.txt have just been published, and if we do add EAI extensions to Netnews, then those mechanism might come in handy for downgrading the Newsgroups header when gatewaying to non-EAI mailing lists. </pre> Charles Lindsey 2010-03-24T11:59:33 http://permalink.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://permalink.gmane.org/gmane.ietf.usenet.format/32478 <pre> Hi Charles, I have just subscribed to news.dotsrc.org and created the dk.test.utf8-æøå (C3 A6 C3 B8 C3 A5 in hexadecimal) newsgroup on my news server. Amusingly, it is dk.test.utf8-ÊÞå on my ISO-8859-15 terminal (0xA6 and 0xB8 are ones of the few characters different between ISO-8859-1 and ISO-8859-15!). A good news is that the pullnews program works fine with dk.test.utf8-æøå so I could easily suck existing articles for them to show up on my news server (news.trigofacile.com). </pre> Julien ÉLIE 2010-02-08T20:17:10 http://permalink.gmane.org/gmane.ietf.usenet.format/32477 <pre> In &lt;220E6FECA0D44BC48B94BD47C438B522&lt; at &gt;Iulius&gt; =?UTF-8?Q?Julien_=C3=89LIE?= &lt;julien&lt; at &gt;trigofacile.com&gt; writes: It is available on news.dotsrc.org, so you either need to peer with them, or at least subscribe to them. </pre> Charles Lindsey 2010-02-08T12:18:41 http://permalink.gmane.org/gmane.ietf.usenet.format/32476 <pre> Hi Charles, I do not have many feeds (only a dozen) and I do not see the Danish UTF-8 group on them. So I doubt a post to dk.test.utf8-æøå (that is to say dk.test.utf8-æøå) on my news server will go far away... I don't mind creating their group, though. It is strange that Opera can read dk.test.utf8-æøå but not trigofacile.test.υτφ8... I believe the French hierarchy fr.* may be willing to participate in the experiment. Creation of newsgroups are asked in fr.usenet.forums.evolution (see "Noms de groupes en UTF-8" where one person is in favour -- nobody answered that he was against). </pre> Julien ÉLIE 2010-02-05T19:32:22 http://permalink.gmane.org/gmane.ietf.usenet.format/32475 <pre> In &lt;D599DB8FD691431D8E6C6E6B75B56400&lt; at &gt;Iulius&gt; Julien ÉLIE &lt;julien&lt; at &gt;trigofacile.com&gt; writes: Yes, there are various minor things that would need to be extended apart from the Newgroups header (including the newsgroups line and the checkgroups message). That is an interesting question, which would need dicussion, but does not look like a show stopper. It should be documented in the early archives of this list. Here is a typical Path for an article that reached news.dotsrc.org: Path: news.sunsite.dk!dotsrc.org!news.szn.dk!news.bunk.cc!pnx.dk! newsfeed101.telia.com!nf02.dk.telia.net!news.tele.dk! feed118.news.tele.dk!not-for-mail It is really a question of whether a server has it in its active file. If so, then there is no reason why it should not pass straight through it. The flooding algorithm will, as usual, find a way around any servers that don't participate, but is will simply be a configuration affair rather than any failure of implementation. The real difficulty will be in user ag</pre> Charles Lindsey 2010-02-05T14:54:14 http://permalink.gmane.org/gmane.ietf.usenet.format/32474 <pre> Hi Charles, I think it will also require to change the possible values for "argument" here: control = "Control:" SP *WSP control-command *WSP CRLF control-command = verb *( 1*WSP argument ) verb = token argument = 1*( %x21-7E ) We need to be able to use UTF-8 in "argument". Could it also be possible to extend dist-list to allow UTF-8 distributions? distribution = "Distribution:" SP dist-list CRLF dist-list = *WSP dist-name *( [FWS] "," [FWS] dist-name ) *WSP dist-name = ALPHA / DIGIT *( ALPHA / DIGIT / "+" / "-" / "_" ) Incidentally, may it exist hostnames in UTF-8 (for the Path: header field) or are they always canonized in ASCII? Is there any record of that? Which news servers (and versions) were tested? The last draft seems to be -09, Section 5.5: http://www.eyrie.org/~eagle/usefor/drafts/draft-ietf-usefor-article-09.txt </pre> Julien ÉLIE 2010-02-03T22:00:37 http://permalink.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 grou</pre> Charles Lindsey 2010-02-01T18:06:57 http://permalink.gmane.org/gmane.ietf.usenet.format/32472 <pre> Julien ÉLIE wrote: Thanks for those tests! It seems that you have demonstrated the existence of a large body of deployed software (including, but not limited to, Windows Mail and unmodified INN) that will not work with UTF-8 newsgroup names. That leads me to suggest that if we want to have UTF-8 newsgroup names, perhaps we need to have a capability signallling mechanism and some kind of block/downgrade mechanism (one could imagine simply not distributing or admitting the existence of UTF-8 newsgroups to anyone who does not signal support, or one could imagine more complex schemes. Harald </pre> Harald Alvestrand 2010-02-01T13:43:32 http://permalink.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</pre> Julien ÉLIE 2010-01-30T09:55:50 http://permalink.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://permalink.gmane.org/gmane.ietf.usenet.format/32469 <pre> Hi Lisa, Buy is it a reason for not having errata of quality? Well, if it is what you want, I can do nothing more. I'm not going to argue more on that subject on which I have already spent far too much time. I will only say that: * the erratum mentions that I "suggest the corrected text", which is wrong because it is not my suggestion (the formatting I provided was better); * the erratum is inconsistent; * the process is inconsistent (no append for erratum 1787 for instance); * my first name has been mispelled in the edited text: it is Julien, and not Julian. But well, after all, I don't mind. I just wanted to give some help and review to have proper errata on rfc-editor.org but it appears that it is not what people expect from rfc-editor.org; so be it that way. I thought that people reading errata would be more pleased to have detailed, complete information of good quality about an erratum. Anyway, thanks for your work on RFCs and errata. I know you are also writing RFCs (I already re</pre> Julien ÉLIE 2010-01-19T23:04:27 http://permalink.gmane.org/gmane.ietf.usenet.format/32468 <pre> Hi Julien, I appended your re-correction of the corrected text, rather than replace, since you were not the reporter, introduced by "Julian Elie suggests the corrected text: ". Since the errata is held for document update, the authors of the next version of the document can analyse all the suggestions and can surely correct for formatting. Lisa On Tue, Jan 19, 2010 at 1:10 PM, Julien ÉLIE &lt;julien&lt; at &gt;trigofacile.com&gt; wrote: </pre> Lisa Dusseault 2010-01-19T22:22:30 http://permalink.gmane.org/gmane.ietf.usenet.format/32467 <pre> Hi Lisa, OK, thanks! http://www.rfc-editor.org/errata_search.php?eid=1980 The correction is inconsistent and wrong. I do not understand why we have: --------------------------------------------------- Throughout the document, when it says: (a) Section 3.1, last paragraph: | ... trace headers ... (b) Section 3.4.4, second paragraph: | ... a References header, ... (c) Section 3.5, numbered processing steps: --------------------------------------------------- It should say: (a) Section 3.1, last paragraph: | ... trace header fields ... (b) Section 3.4.4, second paragraph: | ... a References header field, ... (c) Section 3.5, numbered processing steps: Julian Elie suggests the corrected text: Corrected Text -------------- (a) Section 3.1, last paragraph: | ... trace header fields ... (b) Section 3.4, fourth paragraph: | ... an Injection-Date header field. (c) Section 3.4.4, second paragraph: ------------------------------------------------</pre> Julien ÉLIE 2010-01-19T21:10:35 http://permalink.gmane.org/gmane.ietf.usenet.format/32466 <pre> Done. The editorial ones I marked "hold for document update" because the terminology issues won't affect an implementation's correctness, and I do not like making implementers wade through terminology corrections looking for technical errata. Thanks, Lisa On Fri, Jan 15, 2010 at 2:55 PM, Julien ÉLIE &lt;julien&lt; at &gt;trigofacile.com&gt; wrote: </pre> Lisa Dusseault 2010-01-19T20:35:03 http://permalink.gmane.org/gmane.ietf.usenet.format/32465 <pre> OK, thanks Russ. I have just implemented the required change in the latest development version of INN so as not to mention these two headers (otherwise, multiple occurrences are not allowed). </pre> Julien ÉLIE 2010-01-16T17:16:33 http://permalink.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 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.usenet.format