Subject: [EAI] Open issues on the EAI documents

From: Harald Alvestrand <[email-masked]>
Date: Tue, 25 Apr 2006 11:12:12 +0200

Here's a rough list of what I think are open issues on the EAI documents.
It's based on a list that Pete Resnick recorded at the Dallas meeting
(thanks, Pete!)
I've attempted to add clarifications, and to add some issues from the list.

Please remind me what I missed/forgot!

Framework document:
Issue: Paul: Mandatory to implement should be clarified
Issue: Dave: Clarify that MUST bounce if the next hop doesn't support,
and address can't be  converted

822-headers (Yeh document):
Issue: Dave/Chris: Comma in address fields as an alternative to separate
parameter?
Issue: Chris: Internationalized comment, especially after date, needed
Issue: Paul: Canonicalization issues (PKIX/DKIM)
Issue: Pete: Clean separation (or explanation) of what is message format
and what is SMTP
Issue: Phil: UTF-8 in MIME Content-* fields
Issue: Marcos: remove "UTF-8" from this document - just say "unicode
characters"?

SMTP extension (Yao document):
Issue: Pete: Do we allow UTF-8 in quoted-string?

Downgrade document:
Issue: Chris: MUST is too strong for preserving all info - "gateways
lose information"
Issue: Harald/Chris/Paul: Use case for upgrade needs to be added to
scenarios doc, or "upgrade" should be removed from this document
Issue: Pete: Split upgrade between SMTP upgrades and content upgrades
Possible consensus: No upgrading of content in the transport system -
may upgrade on  recipient system
Issue: Need for/syntax of ATOMIC (ATOMIC=NO seems an important signal to
send)

POP Document:
Issue: Randy: TOP8 command (I believe consensus is that it should be added)
Issue: Chris: Maybe just have an 8-bit switch, instead of separate
commands  (I believe consensus is "no")
Issue: Paul: Right-to-left issues should be looked at

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

---

From: John C Klensin <[email-masked]>
Date: Sat, 29 Apr 2006 12:45:12 -0400

Harald,

In the hope of reaching some closure, I've tried to annotate
your list, ask some additional questions, and request that we
see if we can get some of these issues closed.

> Please remind me what I missed/forgot!

--------------------------------
> Issue: Dave: Clarify that MUST bounce if the next hop doesn't
> support, and address can't be  converted

Both incorporated into the working version of
draft-ietf-eai-framework-00 that I am sending within the next
few minutes to YangWoo.  I'm not positive that this is the right
thing to do for the longer term, but it was easy to add text to
see if we can agree on what we are talking about and then decide
whether to include it.  A good deal of terminology in the
framework doc also needed cleaning up; I hope at least most of
that has been done.

---------------------------------
> 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.

> Issue: Pete: Clean separation (or explanation) of what is
> message format and what is SMTP

Pete, could you explain this further?  The problem has plagued
us since we started putting transport trace information into the
headers, if not longer.  Do you expect to settle it here?  Or
was this a plea to not make it worse, with which I clearly agree.

> Issue: Marcos: remove "UTF-8" from this document - just say
> "unicode characters"?

I think this is a dead issue.  Does anyone other than Marcos
want to make a strong case for it?

--------------------------------

> Downgrade document:
> Issue: Chris: MUST is too strong for preserving all info -
> "gateways lose information"
> Issue: Harald/Chris/Paul: Use case for upgrade needs to be
> added to scenarios doc, or "upgrade" should be removed from
this
> document 
> Possible consensus: No upgrading of content in the transport
> system - may upgrade on  recipient system

And, drawing from some recent mailing list discussion, in the
submission system (where that includes both the sending MUA and
any mail submission server that might be involved).  I hope this
is correct because the framework doc has been tentatively
changed to say it.

> Issue: Need for/syntax of ATOMIC (ATOMIC=NO seems an important
> signal to send)

--------------------------------

> Issue: Randy: TOP8 command (I believe consensus is that it

That is my understanding.  Could you issue a call and formalize
that understanding?

> Issue: Chris: Maybe just have an 8-bit switch, instead of
> separate commands  (I believe consensus is "no")

--------------------------------

We still need an IMAP document and several other things that the
framework document refers to (or those should be removed).
Volunteers should start stepping forward.

     john