Subject: [EAI] Status of issues, Framework document

From: Harald Alvestrand <[email-masked]>
Date: Tue, 07 Nov 2006 08:39:53 -0800

Here's the status of the issues so far, to the extent that I think I 
understand where they stand.
If someone feels that this status is erroneous, please speak up.

Note that I have "resolution not clear" on #1393 and #1397. Others should 
be OK.

1387 Framework 1.3 - i18mail user clarification
  Editorial, accepted
1388 Framework -3 - Missing MIME considerations
  Note that –headers needs to address MIME issues
1389 Framework 4.1 - term "bounce" vs "reject"
  Remove term "bounce"
1390 Framework 4.1 - "POP"
  Editorial, accepted
1391 Framework 5 - delivery to final delivery MTA
  Being wordsmithed
1392 Framework 6 - delete i18n section
  Accepted
1393 Framework 7 - missing local part abuses as label
  Resolution not clear
1394 Framework 10 - too long
  Wordsmithing, but no changes
1395 Framework 13 – nits
  Editorial, accepted
1396 Framework 7.1 - title change IRI -> URI
  Accepted
1397 Framework 10 - UTF-8
  Resolution not clear

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

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 07 Nov 2006 18:56:48 +0100

> 1393 Framework 7 - missing local part abuses as label

That apparently boiled down to "there are some interesting uses
of local parts working for a proper subset of US-ASCII known as
LDH, and these uses won't work with UTF-8 as is".  Or in other
words you can IMO mark 1393 as "no change/rejected" or similar.

> 1397 Framework 10 - UTF-8

Starting my "special" browser for the critical ietf:ietf cases,
because I don't recall what 1397 was...

...it's a special point also covered by 1394.  Maybe the part...

| and, potentially, some issues with UTF-8 canonicalization,
| discussed in [RFC3629].  The latter is also part of the subject
| of ongoing work discussed in [Net-Unicode].

...could be replaced.  For an unrelated draft I tried this:

| well-known Unicode and UTF-8 security considerations are not
| listed below.  For an overview see [UTR36] and [RFC3629].

The most exciting part is to create a <reference> element for
UTR #36.  John has this in RFC 4690.  The last date I've seen
was August 2006.

Frank