Subject: [EAI] Issues

From: Shawn Steele <[email-masked]>
Date: Tue, 14 Jun 2011 19:42:23 +0000

> On 6/13/2011 1:22 PM, Joseph Yee wrote:
> > As co-chair, I ruled this topic closed and need no further discussion, unless new issues provided.

> Excellent.  Thanks!

Is there a list of outstanding things that might be preventing the docs from being submitted?  I'm not sure I know where we're at.

Thanks,
Shawn

---

From: Joseph Yee <[email-masked]>
Date: Thu, 16 Jun 2011 11:26:59 -0400

The current revision (-10) has adopted a new ABNF model and so far the discussion/review is close to none.  I would like to ask everyone in WG to review, and provide feedbacks.  

Simply saying "read and support" (did I hear that somewhere?) is not enough. There are discussions on several fields like forward path and others,  I would like to ask all to review, and write their thoughts on current ABNF.

(See conversations: "The scenario favoring 'uMailbox' and Trace fiedls)

Best
Joseph

On 2011-06-14, at 3:42 PM, Shawn Steele wrote:

> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima

---

From: Yangwoo Ko <[email-masked]>
Date: Mon, 20 Jun 2011 16:39:39 +0900

I have read current version and am quite satisfied with it.

As far as ABNF issue (and update or extend issue) is concerned, it
accomodates suggested modifications well.

Regarding trace fields issue, the approach included in the current
version is sort of a compromize among (backward?)
deliverability/cleanness/readability/... I have not found any profound
new issue that requires us to reopen this issue though I prefer a
different approach.

For "favoring uMailbox" issue, I think that it is useful to mention
how an implementation should handle such a case. However, I don't
think that part is particularly necessary for this document to be
wrapped up. So, I'd rather suggest to put aside such materials into a
separate I-D.

Very very minor editorial issues;

At section 3.2, "If and only if the EAI-aware SMTP client (sender) is
a Message Submission Agent ("MSA") [RFC4409] [RFC5598], MSA may choose
its"

--> ..., it may choose its

A few lines below, "But the detailed specification of this process and
its results is outside the"

--> its results are outside...

At section 3.3, "This document will make <Mailbox> to support
non-ASCII characters."

--> ... support non-ASCII characters as well.

All occurreces of "importted" should be relaced with "imported".

-- 
a human known as [email-masked] @ gtalk

---

From: Shawn Steele <[email-masked]>
Date: Mon, 20 Jun 2011 15:42:29 +0000

>> At section 3.3, "This document will make <Mailbox> to support non-ASCII characters."

"This document will allow <Mailbox> to support non-ASCII characters."

-Shawn

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 20 Jun 2011 11:31:28 -0700

On 6/20/2011 8:42 AM, Shawn Steele wrote:
>
>>> At section 3.3, "This document will make<Mailbox>  to support non-ASCII characters."
>
> "This document will allow<Mailbox>  to support non-ASCII characters."

The change /extends/ the set of characters.  That is, it is adding characters 
rather than defining the entire set.  (The "as well" implied "in addition" 
whereas Shawn's language might leave the point ambiguous.)

So perhaps the language should say that explicitly, along the lines of:

    This document extends <Mailbox> to add support of non-ASCII characters.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Jiankang Yao" <[email-masked]>
Date: Fri, 24 Jun 2011 16:49:11 +0800

----- Original Message ----- 
From: "Joseph Yee" <[email-masked]>
To: "Shawn Steele" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, June 16, 2011 11:26 PM
Subject: [EAI] (Re: Issues) on current RFC5336bis-10

> Simply saying "read and support" (did I hear that somewhere?) is not enough. There are discussions on several fields like forward path and others,  I would like to ask all to review, and write thei…

I plan to submit the new version on 29 June.

If you have any more comments, pls let me know before 29 June.

I hope that we can announce that the core documents are ready to go to IESG during the next IETF meeting.

Is this aim reasonable?

Jiankang Yao

---

From: John C Klensin <[email-masked]>
Date: Sat, 25 Jun 2011 15:27:15 -0400

<co-chair hat on>

--On Friday, 24 June, 2011 16:49 +0800 Jiankang Yao
<[email-masked]> wrote:

>...

I assume this will include the improvement about extending
<Mailbox> syntax suggested by Yangwoo and tuned by Shawn and
Dave as well as Yangwoo's other suggestions.

If others have comments, now is the time to speak up.

> I hope that we can announce that the core documents are ready
> to go to IESG during the next IETF meeting.

I assume that Joseph will issue a WG Last Call on this document
immediately after it is posted.  For those who are anxious to
get finished (a category that I hope includes everyone on the
list), it would be much better to get fixes into that 29 June
draft than to complain during WG Last Call.  The latter would
almost certainly result in delays in moving to IETF Last Call.

> Is this aim reasonable?

I hope so.

</co-chair hat off>

    john