On Mon, 15 Aug 2011 16:19:44 +0100, <ned+ima@mrochek.com> wrote:

>> On Sat, 13 Aug 2011 23:08:48 +0100, <ned+ima@mrochek.com> wrote:

>> Yes, but you have to consider all the other protocols using mail-like
>> formats and their use of the Message-ID.
>
> These protocols don't make use of email addresses?

Some do some don't. In Netnews they are not used except to reply to the  
author or an article by email.

>> For exmaple, if EAI were to be
>> carried over into Netnews (quite a likely development) it would NOT be
>> regarded as a "new message format" since the transport paths for Netnews
>> are already 8-bit clean and it would simply be necessary for those who
>> wish to take advantage of the new facilities to ensure that their user
>> agents were suitably upgraded. There will never be a need for
>> "downgrading" except at gateways back into the email system.
>
> And all netnews applications properly handle the construction and  
> display of
> utf-8 addresses in message headers? Just as one example, netnews already
> suports the proper form of Unicode normalization on input for this.  
> Right?

No. If you want to participate in newsgroups where strange characters are  
likely to be used, then you need to ensure your MUA has the necessary  
capability. That's your problem.
>
> An 8-bit clean transport is nowhere near sufficient to accomodate the  
> other
> changes to the format we're making here. Message ids are actually the  
> least of
> it since they are machine generated.

It is sufficient for the existing Netnews transport to deliver articles  
with utf-8 headers to participants; its their problem to get them  
displayed. The only two headers that are necessary in the transport layer  
are the Newsgroups header and the Message-ID. It has already been  
demonstrated that a Newsgroups header with utf-8 will be delivered  
correctly, but a standard would be needed to ensure proper normalization.  
The Message-ID is crucial to the correct operation of the Netnews  
transport, and the effect of using utf-8 in it has not been investigated  
(but should be). It is expected that some ancient transport agents might  
not like it but even that might not be a show stopper, since Netnews is  
very good at navigating around such obstacles.

> I'm sorry, but the entire approach of this WG is to define a format that  
> is NOT
> downgradeable to previous formats without substantial information loss.

Utter rubbish!

We are not designing a protocol that goes out of its way to make  
downgrading impossible. We are designing a protocol in which downgrading  
is not REQUIRED to be possible, but we should still avoid putting  
unnecessary obstacles in its way.

And, as I have said, in Netnews downgrading is not an issue (except at  
gateways out of Netnews).

Returning now to email, the Message-ID is only important when used in the  
References and In-Reply-To headers, where is is generally used by MUAs for  
threading purposes. So the worst that can happen if Message-IDs get  
garbled in transport is that threading fails to work.

My suggestion is that we retain a requirement that Message-ID remain in  
pure ASCII but add a remark that this position is likely to be reviewed in  
a future version of the standard.

If then, as is likely, they start to appear, then we will see how they  
cope and decide how best to regulate them in a future standard. In the  
meantime, they will do little harm. But when that future standard comes,  
it have to pay attention to exactly what sorts of things can appear in  
them (as indeed 5322 places quite a lot of restrictions) and, in addition,  
it will have to pay careful attention to normalization if threading it to  
continue to work.

And I don't think we want to go into that sort of detail at this present  
stage of our work.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: chl@clerew.man.ac.uk      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