headers
Jeff Yeh | 3 Jul 2006 11:53
Picon

Re: [EAI] Comments on draft--eai-utf8headers-00

Thank you for your precious comment.
I will fix the editorial change.
And some response below.

Jeff

Charles Lindsey wrote:
>    Sending MUAs that follow this protocol MUST create all header fields
>    encoded in UTF-8.  No other direct encodings are allowed.
>
> I don't see why stuff encoded by RFC 2047 should not be allowed. Not 
> particularly sensible if UTF8 is available, but you might, for 
> example, be replying to a message which already had RFC 2047 in its 
> Subject, and the easiest thing to do is just stick "Re:" on the front 
> of it (or maybe not even that).
Here we said "direct encoding" is some local encoding like Big5.
And I agree there's no bad for using RFC 2047. But, why use 2047 stuff 
if it can handle UTF8 natively?
FWIW, it will be good to have pure UTF8 mail environment in the future.
I'll put some note about RFC 2047 on this section.
>
> 5.  Identification of internationalized email
>
>    i-Email: 1.0
>
>    [Note in draft: There should be more useful information can be place
>    in the new header field. ]
>
> Yes indeed. I have suggested the following syntax:
>
(Continue reading)

Permalink | Reply | 8 comments |
headers
Xiaodong Lee | 3 Jul 2006 13:46
Picon

Re: [EAI] List of EAI internet-drafts, as of today

hi,Authors,

Please prepare an presentation for your draft in Montreal meeting.

Regards!

-- 
-- Xiaodong LEE [The best answer is doing]
   +86-10-58813020 
   mailto:lee <at> cnnic.cn
   http://www.lixiaodong.cn

Harald Alvestrand wrote:
> I believe the flurry of I-D announcements has largely subsided, so 
> it's likely that we have all the documents we will have before Montreal.
> The current list is:
>
> May 12 10:01 draft-ietf-eai-smtpext-00.txt
> May 31 11:32 draft-ietf-eai-imap-utf8-00.txt
> Jun  5 11:34 draft-ietf-eai-utf8headers-00.txt
> Jun 22 11:58 draft-ietf-eai-mailinglist-00.txt
> Jun 26 12:43 draft-ietf-eai-framework-01.txt
> Jun 28 12:54 draft-ietf-eai-pop-00.txt
> Jun 29 06:58 draft-ietf-eai-scenarios-01.txt
> Jun 29 07:54 draft-ietf-eai-downgrade-01.txt
>
> Happy reviewing!
>
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Lindsey | 3 Jul 2006 15:42
Picon
Picon

Re: [EAI] Comments on draft--eai-utf8headers-00

On Mon, 03 Jul 2006 10:53:01 +0100, Jeff Yeh <jeff <at> twnic.net.tw> wrote:

> Charles Lindsey wrote:
>>    Sending MUAs that follow this protocol MUST create all header fields
>>    encoded in UTF-8.  No other direct encodings are allowed.
>>
>> I don't see why stuff encoded by RFC 2047 should not be allowed. Not  
>> particularly sensible if UTF8 is available, but you might, for example,  
>> be replying to a message which already had RFC 2047 in its Subject, and  
>> the easiest thing to do is just stick "Re:" on the front of it (or  
>> maybe not even that).
> Here we said "direct encoding" is some local encoding like Big5.
> And I agree there's no bad for using RFC 2047. But, why use 2047 stuff  
> if it can handle UTF8 natively?

Ah! I had missed the significance of that word "direct". Sure, it would be  
stupid to use RFC 2047 when UTF-8 is available, but since when did people  
not do stupid things? They might be very attached to Big 5 :-).

>> I think it is usually a bad idea for intermediate MTAs to try to  
>> "correct" perceived mistakes in messages passing through them. If the  
>> mistake is bad enough to break the system, then bounce it; othersise  
>> pass it on. Experience with News suggested that systems which tried to  
>> "correct" errors usually introduced more errors than they removed :-( .
> In general case, MTA send what they got. Since sending MUA put the new  
> header on when sending EAI messages.

There is a general prohibition of multiple copies on the same header in  
RFC 2822, except for a very few exceptions (e.g. Keywords:). That should  
be maintained, but if some poor implementation breaks it, then it is
(Continue reading)

Permalink | Reply | 7 comments |
headers
Jeff Yeh | 4 Jul 2006 09:54
Picon

[EAI] alt-separator on utf8header

This was discussed on previous thread 
http://www1.ietf.org/mail-archive/web/ima/current/msg00432.html. But I'd 
like to here other people's opinion.

In the utf8header document right now, we use ',' as the alt-separator. 
TWNIC is recently working on EAI testbed implementation.We found that 
"," leads more complexity on the mailbox parsing. And also "|" leads 
some potential confuse to pipe, some mail account are directly pipe to 
some shell script. The ":" is the separator of header name and header 
body, also possible to raise more complexity on parsing. So, we are 
thinking about using "{", "}" to represent alt-address/atomic 
information. This will look like,
- "DISPLAY-NAME" <UTF8 <at> UTF8 {ASCII <at> ASCII}> #EAI with ALT-ADDRESS
- "DISPLAY-NAME" <UTF8 <at> UTF8 {ATOMIC}> #EAI with ATOMIC option
There are a few benefit I can see:
o not in RFC 2822 section 3.2.1 "specials" token
o making no confuse
o easier for program parsing
o can also be used in mailing list

There is another thing we though about, we use SMTP extension and new 
parameter on SMTP protocol.
That looks like (SMTP protocol):
MAIL FROM: <葉士豪 <at> 台網中心.tw> EAI-PARAMETER=jeff <at> twnic.net.tw
This is pretty much different to mail headers (2822 header). And make 
the whole EAI solution more complex to implement due to various 
representation of "addr-spec".
What if we use:
MAIL FORM: <葉士豪 <at> 台網中心.tw {jeff <at> twnic.net.tw}>
We had try this on our testing server, works good.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Tony Finch | 4 Jul 2006 13:57
Picon
Favicon

Re: [EAI] alt-separator on utf8header

On Tue, 4 Jul 2006, Jeff Yeh wrote:
>
> In the utf8header document right now, we use ',' as the alt-separator.
> TWNIC is recently working on EAI testbed implementation. We found that
> "," leads more complexity on the mailbox parsing. And also "|" leads
> some potential confuse to pipe, some mail account are directly pipe to
> some shell script. The ":" is the separator of header name and header
> body, also possible to raise more complexity on parsing.

: is also used in header field bodies, in addres groups (which are
outside addr-specs) and in source routes (inside addr-specs). 822
parsing is already quite complicated :-)

> So, we are thinking about using "{", "}" to represent
> alt-address/atomic information. This will look like,
> - "DISPLAY-NAME" <UTF8 <at> UTF8 {ASCII <at> ASCII}> #EAI with ALT-ADDRESS
> - "DISPLAY-NAME" <UTF8 <at> UTF8 {ATOMIC}> #EAI with ATOMIC option
> There are a few benefit I can see:
> o not in RFC 2822 section 3.2.1 "specials" token

I think this is not a benefit, because the whole point of the special
characters is that they are used for this kind of thing! Non-special
characters are supposed to have no special syntactic meaning.

> MAIL FROM: <葉士豪 <at> 台網中心.tw> EAI-PARAMETER=jeff <at> twnic.net.tw
> This is pretty much different to mail headers (2822 header). And make the
> whole EAI solution more complex to implement due to various representation of
> "addr-spec".
> What if we use:
> MAIL FORM: <葉士豪 <at> 台網中心.tw {jeff <at> twnic.net.tw}>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Lindsey | 4 Jul 2006 15:21
Picon
Picon

Re: [EAI] alt-separator on utf8header

On Tue, 04 Jul 2006 08:54:18 +0100, Jeff Yeh <jeff <at> twnic.net.tw> wrote:

> - "DISPLAY-NAME" <UTF8 <at> UTF8 {ASCII <at> ASCII}> #EAI with ALT-ADDRESS
> - "DISPLAY-NAME" <UTF8 <at> UTF8 {ATOMIC}> #EAI with ATOMIC option
> There are a few benefit I can see:
> o not in RFC 2822 section 3.2.1 "specials" token
> o making no confuse
> o easier for program parsing
> o can also be used in mailing list

And you can add to that:

   o doesn't need any [FWS] around it to make it stand out (like '|' might  
have done).

> What if we use:
> MAIL FORM: <葉士豪 <at> 台網中心.tw {jeff <at> twnic.net.tw}>

Much to my surprise, my MUA rendered those chinese characters (at double  
width). The only problem was that the ' <at> ' in the middle got lost (looked  
just like another chinese character) :-( .

> We had try this on our testing server, works good.

I think the only problem with this is that it breaks the current RFC 2821  
syntax for parameters to commands. So you will have to fight John on that  
one.

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
(Continue reading)

Permalink | Reply | 4 comments |
headers
Tony Finch | 4 Jul 2006 18:23
Picon
Favicon

Re: [EAI] alt-separator on utf8header

On Tue, 4 Jul 2006, Charles Lindsey wrote:
>
> I think the only problem with this is that it breaks the current RFC 2821
> syntax for parameters to commands. So you will have to fight John on that one.

And IMAs don't?!

Tony.
--

-- 
f.a.n.finch  <dot <at> dotat.at>  http://dotat.at/
DOVER WIGHT PORTLAND PLYMOUTH: VARIABLE BECOMING SOUTHWEST 3 OR 4. THUNDERY
SHOWERS. MODERATE OR GOOD WITH FOG PATCHES IN PLYMOUTH.
Permalink | Reply | 3 comments |
headers
Charles Lindsey | 4 Jul 2006 18:45
Picon
Picon

Re: [EAI] alt-separator on utf8header

On Tue, 04 Jul 2006 17:23:23 +0100, Tony Finch <dot <at> dotat.at> wrote:

> On Tue, 4 Jul 2006, Charles Lindsey wrote:
>>
>> I think the only problem with this is that it breaks the current RFC  
>> 2821
>> syntax for parameters to commands. So you will have to fight John on  
>> that one.
>
> And IMAs don't?!

Not in the same way. The present proposal still fits within the basic  
syntax of RFC 2821 commands (just widens the character set a little). John  
tends to be a little protective of RFC 2821 (quite naturally :-).

I would have no problem with the change, but then I am not particularly au  
fait with the finer points of 2821.

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: chl <at> 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
Permalink | Reply | 2 comments |
headers
John C Klensin | 4 Jul 2006 23:24

Re: [EAI] IMA representation in envelope and header


--On Monday, 26 June, 2006 15:42 +0100 Tony Finch <dot <at> dotat.at>
wrote:

> draft-klensin-emailaddr-i18n-03 says:
> 
>    4.  If internationalization is to be plausible, it is
> critical that        addressing information be represented in
> essentially the same way        in the message envelope (i.e.,
> the SMTP command structure) and        the message body (i.e.,
> both message headers and, where feasible,        message
> text).  Different encodings in different places,
> especially ones that are copied  back and forth, will make both
>        mail system maintainers and operators and end users
> very unhappy.
> 
> We currently have the beginnings of a syntax for i14ed
> addresses with downgrade information in the message header,
> which is different from the representation in the message
> envelope. I suggest that the forward-path and reverse-path
> parts of MAIL and RCPT commands should include the downgrade
> information using essentially the same syntax as in the message
> header, instead of separating it into extension parameters.

Tony,

This may or may not be a good idea -- see note to be posted in a
few minutes -- but don't cite draft-klensin-emailadder-i18n as
justification.  First, it has been replaced by other drafts, is
not on the WGs agenda or authoritative in any other way.
(Continue reading)

Permalink | Reply | 0 comments |
headers
John C Klensin | 4 Jul 2006 23:36

Re: [EAI] alt-separator on utf8header


--On Tuesday, 04 July, 2006 17:45 +0100 Charles Lindsey
<chl <at> clerew.man.ac.uk> wrote:

> On Tue, 04 Jul 2006 17:23:23 +0100, Tony Finch <dot <at> dotat.at>
> wrote:
> 
>> On Tue, 4 Jul 2006, Charles Lindsey wrote:
>>> 
>>> I think the only problem with this is that it breaks the
>>> current RFC   2821
>>> syntax for parameters to commands. So you will have to fight
>>> John on   that one.
>> 
>> And IMAs don't?!
> 
> Not in the same way. The present proposal still fits within
> the basic  syntax of RFC 2821 commands (just widens the
> character set a little). John  tends to be a little protective
> of RFC 2821 (quite naturally :-).
> 
> I would have no problem with the change, but then I am not
> particularly au  fait with the finer points of 2821.

I am really less protective of 2821 than I am about the edge
conditions encountered with existing systems and parsers.  2821
is deliberately very specific about the possible syntax of
extensions in order to permit implementations to lexically
analyze/ tokenize SMTP commands without (prior to) establishing
state via whatever options have been offered or accepted.  Note,
(Continue reading)

Permalink | Reply | 1 comment |

Gmane