headers
Xiaodong(Sheldon) Lee | 1 May 2006 15:34
Picon

[EAI] EAI WG Interim Meeting

Dear All,

The EAI Working Group plan to hold a interim meeting. The main purpose
of this interim meeting
is to prompt the process of this working group.

The meeting need to get the approval of AD.

The intending meeting time is in June 1-2, one day or two days meeting
in Beijing.

Detailed things will be published later, just send this message to this
list, so you can prepare
your schedule firstly.

Anyone who plans to attend meeting, you can send a message to the WG
co-chairs.

Affirmatory agenda will be sent later.

Regards!

xiaodong

--

-- 
-- [The best answer is doing]
   +86-10-58813020 
   http://www.lixiaodong.cn
   mailto:mail <at> lixiaodong.cn
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Newman | 1 May 2006 19:59
Picon

Re: [EAI] help to define Ucharacter and sub-domain by ABNF

It occurs to me that "Uatext" might be a better name for the ABNF rule.  It's 
not a general purpose character.

                - Chris

YAO Jiankang, ima <at> ietf.org wrote on 4/28/06 19:31 -0700:

> This ABNF should work:
>
>   Ucharacter = atext / UTF8-2 / UTF8-3 / UTF8-4
>
> Where "atext" is defined in RFC 2822 and UTF8-2, UTF8-3, UTF8-4 are defined
> in RFC 3629.
>
>                 - Chris
>
> YAO Jiankang wrote on 4/28/06 11:14 +0800:
>
>>
>> Dear all,
>>
>>     Could some kind experts help to refine the below definition of Ucharacter
>> and sub-domain by ABNF in the IMA SMTP extension document?
>>    It seems  not easy to find a very good appropriate definition.
>>
>>   thanks a lot.
>>
>>
>> --------------------------------------------------------------------------
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
fujiwara | 2 May 2006 06:25
Picon
Favicon

Re: [EAI] Comments on Downgrading

> From: Harald Alvestrand <harald <at> alvestrand.no>
> >>>* Section 3.1: "SMTP client detects UTF-8 is included in SMTP envelope or 
> >>>mail headers". Haven't we introduced the i18n-header to avoid making this 
> >>>realtime, unreliable checks? And is it really meant "detects UTF-8" or it 
> >>>is rather meant "detects 8th bit set"?
> >>>      
> >>>
> >
> >Considering implementation costs, I want to use detecting 8th bit set
> >instead of UTF-8 check.
> >  
> >
> The implementation cost for a proper UTF-8 detector is rather small (you 
> check for the non-presence of the 13 forbidden bytes, and that sequences 
> are properly formed - all that can be done in a fairly small finite 
> state machine in one pass, and you still don't have to look at any byte 
> more than oce), and the cost of accepting ISO 8859-1 into processing 
> stages that expect properly formatted UTF-8 is that you have to do the 
> error checking for that condition *everywhere*.
> 
> If we want to have heuristic UTF-8 detection, I think we should 
> recommend UTF-8 detection, not the 8th bit check.

I agree.

> But if we go with the flag (i18n-header or otherwise), we have moved 
> heuristic UTF-8 detection into the realm of "handling nonconformant 
> data", which our standards leave out a lot of the time anyway.

I understand. I will rewrite to delete UTF-8 detection in downgrade draft.
(Continue reading)

Permalink | Reply | 0 comments |
headers
fujiwara | 2 May 2006 11:09
Picon
Favicon

[EAI] clarify Received header format

draft-yao-ima-smtpext-02.txt section 2.5.2.  Trace Fields is ambiguous.

  Addresses in "for" clauses need further examination and might be
  treated differently depending on [IMA-utf8header].  The reasoning
  in the introductory portion of [IMA-overview] strongly suggests
  that these addresses be in UTF-8 form, rather than some
  specialized encoding.

This Received header format may be defined in utf8header draft and
smtpext draft refer it.

Without clear Received header definition, implementation is impossible.

In my opinion, addresses in "for" clauses should be IMA itself and
should be UTF-8 encoded.

And more, I want to record ALT-ADDR, ATOMIC parameter information.

"i18n-email: 1.0" header may be added by MTA
as a result of adding Received header or IMA-Downgraded-* header.

--
Kazunori Fujiwara, JPRS
Permalink | Reply | 15 comments |
headers
John C Klensin | 2 May 2006 13:17

Re: [EAI] clarify Received header format


--On Tuesday, 02 May, 2006 18:09 +0900 fujiwara <at> jprs.co.jp wrote:

> draft-yao-ima-smtpext-02.txt section 2.5.2.  Trace Fields is
> ambiguous.
> 
>   Addresses in "for" clauses need further examination and
> might be   treated differently depending on [IMA-utf8header].
> The reasoning   in the introductory portion of [IMA-overview]
> strongly suggests   that these addresses be in UTF-8 form,
> rather than some   specialized encoding.
> 
> This Received header format may be defined in utf8header draft
> and smtpext draft refer it.
> 
> Without clear Received header definition, implementation is
> impossible.
> 
> In my opinion, addresses in "for" clauses should be IMA itself
> and should be UTF-8 encoded.

FWIW, this is my fault from a very early draft.  I started
working through the case analyses (not just my desires) and came
to the conclusion that the problem was hard and there was no
clear answer.  There are clear advantages to having the
in-transit MTA insert only pure-ASCII trace fields into the
headers.  For example, suppose a trace field containing UTF-8
information is to be inserted and we are to require a header
field that indicates that UTF-8 information is present. The MTA
must perform a header scan to determine whether that
(Continue reading)

Permalink | Reply | 1 comment |
headers
Charles Lindsey | 2 May 2006 20:20
Picon
Picon

Re: [EAI] clarify Received header format

On Tue, 02 May 2006 12:17:07 +0100, John C Klensin <klensin <at> jck.com> wrote:

> --On Tuesday, 02 May, 2006 18:09 +0900 fujiwara <at> jprs.co.jp wrote:

>> In my opinion, addresses in "for" clauses should be IMA itself
>> and should be UTF-8 encoded.
>
> FWIW, this is my fault from a very early draft.  I started
> working through the case analyses (not just my desires) and came
> to the conclusion that the problem was hard and there was no
> clear answer.  There are clear advantages to having the
> in-transit MTA insert only pure-ASCII trace fields into the
> headers.  For example, suppose a trace field containing UTF-8
> information is to be inserted and we are to require a header
> field that indicates that UTF-8 information is present. The MTA
> must perform a header scan to determine whether that
> UTF-8-indicating header is present and add it if it is not.  We
> generally try to avoid requiring MTAs to perform such header
> scans -- the historical model says that that, other than
> submission and delivery MTAs, they don't do it.   This is,
> incidentally, one of several reasons I've been reluctant to
> agree to the requirement for such a header field -- it does have
> side-effects.

I think an intermediate MTA that needs to know whether it is dealing with  
an extended email or not has a choice. Either it looks for the presence of  
the UTF-8-indicating header, or it looks for the presence of a bit-8 (or  
maybe it does a proper UTF-8 test, as we have been discussing).  
Implementor's choice.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles Lindsey | 2 May 2006 19:00
Picon
Picon

Re: [EAI] RFC 4409 Message Submission

On Fri, 28 Apr 2006 07:26:08 +0100, YAO Jiankang <yaojk <at> cnnic.cn> wrote:

>> Does 'smtpext' document need to describe Submission ?
>
> SMTP was defined as a message *transfer* protocol, that is, a means
>    to route (if needed) and deliver finished (complete) messages.

Not quite. When SMTP was defined (and even when RFC 2821 was written),  
"submission" was not regarded as a separate activity, and MUAs submitted  
their messages direct to SMTP servers on Port 25. Indeed, many MUAs still  
do that, so out smtpext needs to handle them sensibly (and I think it  
currently does).

> RFC 2476 is to deal with how to sumbit the message to the server.
> IMO, no need to describe the issues related with RFC 2476 in 'smtpext'  
> document

ISTM that submission agents (RFC 2476 or whatever has replaced it)  
therefore have to be able to do at least as much by way of  
downgrading/bouncing/etc as any other SMTP agent, in which case smtpext is  
the place to discuss it, as an extension to the RFC 2476(bis?) protocol.

That is not to say that we moght not propose some slightly different  
features for handling messages in submission  agents. For example, it  
might be more reasonable to bounce (rather than downgrade) messages in a  
submission agent, on the grounds that it is closer to the sender, and  
therefore easier to send it back to him for him to fix the problem himself.

--

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

Permalink | Reply | 1 comment |
headers
Charles Lindsey | 2 May 2006 19:14
Picon
Picon

Re: [EAI] Open issues on the EAI documents

On Sat, 29 Apr 2006 17:45:12 +0100, John C Klensin <klensin <at> jck.com> wrote:

> ---------------------------------
>> 822-headers (Yeh document):
>> Issue: Dave/Chris: Comma in address fields as an alternative
>> to separate parameter?
>
> Can we initiate some specific discussion on this and get it
> settled?  My impression was that we had dropped it due to other
> interactions, but I could easily be confused.

Clearly we need a separator, and clearly nobody particularly likes 'comma'  
even though it is the only obviously "free" character.

May I remind you that I pointed out some time back that '|' (which would  
look much better as the separator) would not be ambiguous *provided* we  
could assume that it would not occur in the domain portion of an address  
(i.e. after the ' <at> '). This is true of any domain allowed by RFC 2821  
(though theoretically it might arise in emails transported by other  
mechanisms - X.400 anybody?). So is it a serious contender for this  
separator?

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   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 | 0 comments |
headers
John C Klensin | 2 May 2006 20:48

Re: [EAI] RFC 4409 Message Submission


--On Tuesday, 02 May, 2006 18:00 +0100 Charles Lindsey
<chl <at> clerew.man.ac.uk> wrote:

>> RFC 2476 is to deal with how to sumbit the message to the
>> server. IMO, no need to describe the issues related with RFC
>> 2476 in 'smtpext'   document
> 
> ISTM that submission agents (RFC 2476 or whatever has replaced
> it)  therefore have to be able to do at least as much by way
> of  downgrading/bouncing/etc as any other SMTP agent, in which
> case smtpext is  the place to discuss it, as an extension to
> the RFC 2476(bis?) protocol.
> 
> That is not to say that we moght not propose some slightly
> different  features for handling messages in submission
> agents. For example, it  might be more reasonable to bounce
> (rather than downgrade) messages in a  submission agent, on
> the grounds that it is closer to the sender, and  therefore
> easier to send it back to him for him to fix the problem
> himself.

The submission agent might also have access to much more
information than a typical SMTP relay.  I could easily imagine
storing a table of i18nAddress <-> ASCII address equivalences in
such an agent, especially for backward (sender)-pointer
addresses so that the agent could do some downgrading without
the need for the user to supply ALT-ADDRESS or ATOMIC (or
equivalent) for each i18nAddress.
(Continue reading)

Permalink | Reply | 0 comments |
headers
John C Klensin | 3 May 2006 03:54

Re: [EAI] clarify Received header format


--On Tuesday, 02 May, 2006 19:20 +0100 Charles Lindsey
<chl <at> clerew.man.ac.uk> wrote:

> On Tue, 02 May 2006 12:17:07 +0100, John C Klensin
> <klensin <at> jck.com> wrote:
> 
>> --On Tuesday, 02 May, 2006 18:09 +0900 fujiwara <at> jprs.co.jp
>> wrote:
> 
>>> In my opinion, addresses in "for" clauses should be IMA
>>> itself and should be UTF-8 encoded.
>> 
>> FWIW, this is my fault from a very early draft.  I started
>> working through the case analyses (not just my desires) and
>> came to the conclusion that the problem was hard and there
>> was no clear answer.  There are clear advantages to having the
>> in-transit MTA insert only pure-ASCII trace fields into the
>> headers.  For example, suppose a trace field containing UTF-8
>> information is to be inserted and we are to require a header
>> field that indicates that UTF-8 information is present. The
>> MTA must perform a header scan to determine whether that
>> UTF-8-indicating header is present and add it if it is not.
>> We generally try to avoid requiring MTAs to perform such
>> header scans -- the historical model says that that, other
>> than submission and delivery MTAs, they don't do it.   This
>> is, incidentally, one of several reasons I've been reluctant
>> to agree to the requirement for such a header field -- it
>> does have side-effects.
>
(Continue reading)

Permalink | Reply | 1 comment |

Gmane