headers
Shawn Steele | 1 Mar 2012 23:22
Picon
Favicon

FW: Draft on IDN Tables in XML

Hmm, sort of an FYI:  if it's interesting for IDN Zone admins to declare the rules they use, maybe something
similar is interesting for email admins to declare how they assign EAI addresses?

-Shawn

-----Original Message-----
From: idna-update-bounces <at> alvestrand.no [mailto:idna-update-bounces <at> alvestrand.no] On Behalf Of
Kim Davies
Sent: Thursday, March 01, 2012 11:15 AM
To: vip <at> icann.org; idna-update <at> alvestrand.no
Subject: Draft on IDN Tables in XML

Colleagues,

I have posted a first draft regarding a format that could be used for representing IDN Tables in XML to the I-D Repository:

	https://datatracker.ietf.org/doc/draft-davies-idntables/

After discussion with a number of folks that felt this would be good work to undertake, I've put together a
first cut which is not comprehensive, but I think goes some way toward a potential format.

Unless there is interest in this being a more formal activity, my assumption is to aim to publish the final
result independently as an Informational RFC. However, the mechanism of publication is secondary to
coming up with something useful that would benefit TLD registries and other implementors. A list of
design goals, from the document, is as follows:

	* MUST be in a format that can be implemented in a reasonably straightforward manner in software;
	* The format SHOULD be able to be checked for formatting errors, such that common mistakes can be caught;
	* An IDN Table MUST be able to express the set of valid code points that are allowed for registration under a
specific zone administrator's policies;
(Continue reading)

Permalink | Reply | 2 comments |
headers
John C Klensin | 2 Mar 2012 16:02

Re: FW: Draft on IDN Tables in XML


--On Thursday, March 01, 2012 22:22 +0000 Shawn Steele
<Shawn.Steele <at> microsoft.com> wrote:

> Hmm, sort of an FYI:  if it's interesting for IDN Zone admins
> to declare the rules they use, maybe something similar is
> interesting for email admins to declare how they assign EAI
> addresses?

Maybe, although we have never tried to standardize that in 40
years or so.  Some people would undoubtedly consider disclosing
their assignment system as an invitation to attacks.  And,
perhaps worse, the assignment rule in many places has been
approximately FCFS with a few restrictions.  For example, how
would you describe the current assignment model for Hotmail?

    john
Permalink | Reply | 1 comment |
headers
Shawn Steele | 2 Mar 2012 16:51
Picon
Favicon

Re: FW: Draft on IDN Tables in XML

One could say the same about zones :)  I'm not for the idea, I just saw a possible correlation.  (I actually
don't see much need for it for IDN either, there's already a way to ask if someone else's name's valid: DNS,
so this seems limited to specialized apps).

-Shawn

-----Original Message-----
From: John C Klensin [mailto:klensin <at> jck.com] 
Sent: Friday, March 02, 2012 7:02 AM
To: Shawn Steele; ima <at> ietf.org
Subject: Re: [EAI] FW: Draft on IDN Tables in XML

--On Thursday, March 01, 2012 22:22 +0000 Shawn Steele <Shawn.Steele <at> microsoft.com> wrote:

> Hmm, sort of an FYI:  if it's interesting for IDN Zone admins to 
> declare the rules they use, maybe something similar is interesting for 
> email admins to declare how they assign EAI addresses?

Maybe, although we have never tried to standardize that in 40 years or so.  Some people would undoubtedly
consider disclosing their assignment system as an invitation to attacks.  And, perhaps worse, the
assignment rule in many places has been approximately FCFS with a few restrictions.  For example, how
would you describe the current assignment model for Hotmail?

    john
Permalink | Reply | 0 comments |
headers
Arnt Gulbrandsen | 2 Mar 2012 16:55
Picon
Favicon
Gravatar

draft-ietf-eai-simpledowngrade-00

Hi,

I cleaned up the protodraft I posted and Josepth just approved it, so
you should see a new WG draft in your next-door mirror very soon. Just
what you needed to start the weekend: The shortest, simplest draft
you've seen in weeks.

There's one open issue: How to explain the relationship between this
document and the two other alternatives.

One alternative is Fujiwara's draft. His draft is complex and provides a
high-fidelity rendering of EAI messages, at the cost of requiring much
implementation and testing. Mine is much simpler, requires little
testing, and provides only the most important information. Choosing
between those is really a matter of preference.

The other alternative is no downgrade at all, and this is where I have
problems.

I believe that no downgrading is harmful for two reasons. One is that
without downgrade, nervous admins might not want to enable EAI until
they know all clients work, and IMP and POP don't make gathering that
information simple. The other, and more important, reason is that once
an IMAP server has revealed the existence of a message, it cannot really
deny the user access to that message. So either it has to downgrade by
creating a monster (e.g. just-send-utf8 addresses, which hopefully will
not cause the MUA to misdirect an reply) or go to some effort to never
reveal the EAI messages, or deal with the possible infinite loops if it
suppresses the content of revealed messages.
(Continue reading)

Permalink | Reply | 23 comments |
headers
John C Klensin | 2 Mar 2012 17:28

Re: draft-ietf-eai-simpledowngrade-00


--On Friday, March 02, 2012 16:55 +0100 Arnt Gulbrandsen
<arnt <at> gulbrandsen.priv.no> wrote:

> Hi,
> 
> I cleaned up the protodraft I posted and Josepth just approved
> it, so you should see a new WG draft in your next-door mirror
> very soon. Just what you needed to start the weekend: The
> shortest, simplest draft you've seen in weeks.
> 
> There's one open issue: How to explain the relationship
> between this document and the two other alternatives.

Note that some discussion of this went into the most recent
version of draft-ietf-eai-popimap-downgrade.  I'm guilty of
supplying most of that text (if you don't like it, definitely
blame me and not Kazunori), but the decision about what to do
about it, and whether more or less should be said, belongs to
the WG.

> One alternative is Fujiwara's draft. His draft is complex and
> provides a high-fidelity rendering of EAI messages, at the
> cost of requiring much implementation and testing. Mine is
> much simpler, requires little testing, and provides only the
> most important information. Choosing between those is really a
> matter of preference.

> The other alternative is no downgrade at all, and this is
> where I have problems.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Arnt Gulbrandsen | 2 Mar 2012 17:33
Picon
Favicon
Gravatar

Re: draft-ietf-eai-simpledowngrade-00

On 03/02/2012 05:28 PM, John C Klensin wrote:
> 'm trying really hard to resist
> the feeling that we are going to need some sort of separate
> "downgrading tradeoffs and issues" document

RFC 1925, 6a
Permalink | Reply | 0 comments |
headers
John C Klensin | 2 Mar 2012 17:47

Status of the EAI effort

EAI participants,

As has already been mentioned on the list, the four "core"
documents are done and published as RFC 6530 - RFC 6533.  Unless
we can now make significant progress in moving other work
forward, we should conclude the the WG has run out of steam and
either suspend it until there is more experience or kill it and
recharter when appropriate (in practice, those two options
aren't different enough to worry about).  My personal preference
would be to get the two clusters of documents outlined below
done before we suspend/ shut down, but I can't either do the
work or supply the energy if the WG isn't able to show that it
is willing and able to put in the effort.

I believe that the current agenda for specifications is:

(1) Mailing lists.   

There has been substantially zero discussion of
draft-ietf-eai-mailinglistbis-01 since it was posted and not
much more discussion of its predecessor.   We need to get
reviews of this document and discussion of whether the WG is
ready to work on it and move it forward or whether we want to
try to devise an explanation for the IESG as to why it isn't
necessary at this point.  I think we are obligated to do one or
the other.  

As to the latter option, I think the only viable position is
that people should not try to use mailing lists with non-ASCII
addresses (the address to which mail for the list is sent) or
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arnt Gulbrandsen | 2 Mar 2012 17:51
Picon
Favicon
Gravatar

Re: draft-ietf-eai-simpledowngrade-00

There has been a little offlist discussion of what "no downgrade" might
mean in concrete terms. Here's one way which should work fairly well in
real life, except that the ALERT response code is frequently rerouted to
/dev/null by today's clients.

Personally I don't like this very much. It holds people's mail hostage.

Arnt

2. IMAP

When an IMAP server is required to send an EAI-specific response, it
sends nil in the relevant part of the response. For example

  C: a UID FETCH 42 ENVELOPE
  S: * 1 FETCH (UID 42 ENVELOPE NIL)

The IMAP server MUST send the ALERT response code along with the
command's tagged response. Continuing the previous example:

  S: a OK [ALERT] One or more messages requires internationalisation and
cannot be displayed

IMAP clients commonly request partial information about a message, so a
client may well ask for only ASCII information in an EAI message. The
server MAY send null responses even if this is the case for a particular
command.

An IMAP server MUST NOT set the \deleted flag or expunge an EAI message
when instructed to by a non-EAI client.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Newman | 2 Mar 2012 23:27
Picon
Favicon

Re: draft-ietf-eai-simpledowngrade-00

I have reviewed this document and I like this general approach, 
particularly the use of the .invalid TLD. I believe having a 
standards-compliant simple downgrade option like this will increase the 
odds that SMTPUTF8 will deploy successfully.

Some specific comments on this draft:

Section 2.1:

   Irregular email addresses (anything to which one cannot send mail,
   such as "unknown:;") are silently excised.

I suggest changing "are" to "MAY be". It's better usability to leave such 
things in the address list so they should only be excised if it makes the 
implementation simpler.

   The affected header fields are Bcc, Cc, From, ReplyTo, ResentBcc,
   ResentCc, ResentFrom, ResentSender, ResentTo, ReturnPath, Sender and
   To.  Any addresses present in other header fields are not regarded as
   addresses by this specification.

The "-" delimiters disappeared from this list, please fix (e.g. ReplyTo 
should be Reply-To, ReturnPath should be Return-Path, ResentTo should be 
Resent-To, etc). I was going to suggest adding Disposition-Notification-To 
to the list, then I realized it's actually better to omit it from the list.

Section 2.2:

   Any mime field (whether in the message header or a bodypart header)
   which cannot be presented as-is to the client is silently excised
(Continue reading)

Permalink | Reply | 19 comments |
headers
Arnt Gulbrandsen | 4 Mar 2012 16:53
Picon
Favicon
Gravatar

Re: draft-ietf-eai-simpledowngrade-00

Hi,

On 03/02/2012 11:27 PM, Chris Newman wrote:
> I have reviewed this document and I like this general approach,
> particularly the use of the .invalid TLD. I believe having a
> standards-compliant simple downgrade option like this will increase the
> odds that SMTPUTF8 will deploy successfully.
> 
> Some specific comments on this draft:
> 
> Section 2.1:
> 
>   Irregular email addresses (anything to which one cannot send mail,
>   such as "unknown:;") are silently excised.
> 
> I suggest changing "are" to "MAY be".

I deleted the parapgraph. The rule didn't really carry its load.

>   The affected header fields are Bcc, Cc, From, ReplyTo, ResentBcc,
>   ResentCc, ResentFrom, ResentSender, ResentTo, ReturnPath, Sender and
>   To.  Any addresses present in other header fields are not regarded as
>   addresses by this specification.
> 
> The "-" delimiters disappeared from this list,

Oh, search and destroy. Fixed.

> Section 2.2:
>
(Continue reading)

Permalink | Reply | 18 comments |

Gmane