Subject: Re: [spfbis] #28: i18n for EAI compatibility

From: S Moonesamy <[email-masked]>
Date: Wed, 22 Aug 2012 14:10:37 -0700

Hi Scott,

What was the text change to address Issue #28?  The message about the 
issue is at http://www.ietf.org/mail-archive/web/spfbis/current/msg01085.html

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 22 Aug 2012 18:22:36 -0400

On Wednesday, August 22, 2012 02:10:37 PM S Moonesamy wrote:
> issue is at
> http://www.ietf.org/mail-archive/web/spfbis/current/msg01085.html

It was the addition of this to Section 4.3:

 	Properly formed domains are fully qualified email domains as	
	described in [RFC5321] Section 2.3.5. Internationalized domain names	
	MUST be encoded as A-labels, as described in Section 2.3 of	
	[RFC5890].

There was some discussion about changes relative to local-part macros, but in 
the end I believe we converged on not making any change for that (and this is 
what the current draft reflects) because there wasn't a way to be more broadly 
compatible with IDN local-parts and maintain backward compatibility.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Wed, 22 Aug 2012 15:48:24 -0700

Hi Scott,
>         MUST be encoded as A-labels, as described in Section 2.3 of

I'll close the ticket if I do not hear any objections to the above.

>compatible with IDN local-parts and maintain backward compatibility.

Thanks.

There is a "MUST" in the text that was added.  It may affect existing 
RFC 4408 implementations.  I'll leave this to the Responsible AD to decide.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 23 Aug 2012 00:34:46 -0400

On Wednesday, August 22, 2012 03:48:24 PM S Moonesamy wrote:
> >         described in [RFC5321] Section 2.3.5. Internationalized
> > 
> > domain names
> > 
> >There was some discussion about changes relative to local-part macros, but
> >in the end I believe we converged on not making any change for that (and
> >this is what the current draft reflects) because there wasn't a way to be
> >more broadly

This is a good point.  Upon reflection, perhaps it would be better put like 
this:

        Properly formed domains are fully qualified email domains as    
        described in [RFC5321] Section 2.3.5. For implementations that 
        support Internationalized domain names, such domains MUST be
        encoded as A-labels, as described in Section 2.3 of  [RFC5890].

I think that might be more appropriate.  I don't think 4408bis is the right 
document to be mandating IDN support in MTAs.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Wed, 22 Aug 2012 22:23:33 -0700

Hi Scott,
>document to be mandating IDN support in MTAs.

I have not discussed about this with Andrew.  There are different 
ways to tackle the issue.  In my humble opinion the text suggested 
above may be flagged during external review or it may generate a 
DISCUSS.  I suggest leaving the text as it is for now unless the 
working group agrees on the text suggested above or any other text.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 23 Aug 2012 10:34:44 -0400

>working group agrees on the text suggested above or any other text.
OK.  I'll put it back.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Thu, 23 Aug 2012 09:36:20 -0700

Hello,

I am closing the ticket for Issue #28.

As a reminder, open tickets are listed at 
http://trac.tools.ietf.org/wg/spfbis/trac/report/1

Regards,
S. Moonesamy

---

From: "John Levine" <[email-masked]>
Date: 24 Aug 2012 17:09:48 -0000

>        encoded as A-labels, as described in Section 2.3 of  [RFC5890].

In case it's not obvious, you don't need to support EAI to use A-label
domains.  It's reasonable advice to everyone to note that non-ASCII
domains must be encoded as A-labels in DNS queries.

On the other hand, since EAI is now on the standards track, I'm a
little confused about why we wouldn't want to add the two sentences
needed to say how to support it.  (Domains are turned into A-labels
whenever used for DNS lookups.  Local parts are what they are and can
cause surprises, same as now.)

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Aug 2012 13:54:18 -0400

> domains must be encoded as A-labels in DNS queries.

No hat:

It's flat-out false that non-ASCII domains must be encoded as A-labels
in DNS queries, so I don't see why we ought to start advising that.
What _is_ true is that the specification for SPF says the "character
content of the record is encoded as US-ASCII".

If what you want to say is that SPF is defined only for DNS names
conforming to the preferred syntax of section 2.3.1 of RFC 1035 or
section 3.5 of RFC 1034 (or both), say that.

In general, I think we should restrict ourselves narrowly to the
protocol itself (i.e. the publication and interpretation of SPF
records) and leave alone other things, such how to publish or look
stuff up in the DNS, what to do with a mail when you've done SPF
processing, and so on.
 
> needed to say how to support it.

Speaking as chair, we wouldn't want to do that because it doesn't fall
under any of the restrictions in our charter:

        Changes to the SPF specification will be limited to the correction
        of errors, removal of unused features, addition of any enhancements
        that have already gained widespread support, and addition of
        clarifying language.

also

        Specifically out-of-scope for this working group:
[…]
        * Extensions to the SPF protocols.

If there are enhancements to be developed, we should put them on a
TODO list so that they can be considered in case the WG wants to
recharter to take them on.  

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 24 Aug 2012 20:12:47 -0000

>in DNS queries, so I don't see why we ought to start advising that.

Aw, come on.  While it is certainly true that the wire-level DNS
protocol allows names to contain arbitrary octets, I am reasonably
sure that every TLD requires non-ASCII 2LDs to be encoded as A-labels,
and application software such as web browsers that handle non-ASCII
domains turns it all into A-labels before looking them up.

Right now I exchange some mail with people whose addresses are in the
form ascii@xn--stuff.  (Not a whole lot, but more than none.) Anyone
who tried to handle non-ASCII domains any other way would be doomed to
eternal incompatibility pain.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Aug 2012 16:28:50 -0400

No hat.

> sure that every TLD requires non-ASCII 2LDs to be encoded as A-labels,

That's irrelevant.  Every TLD I know of prevents underscore labels,
but we use them all the time further down the tree, just as a handy
example.

> domains turns it all into A-labels before looking them up.

No, actually.  At least one web browser that is still in (fortunately
declining) use dumps UTF-8 -- or sometimes, I've been led to believe,
UCS-2 with BOM -- on the wire.  And browsers that automatically try to
turn everything in to A-labels are going to fail completely with mDNS,
which explicitly says that it uses UTF-8.  I've been attempting to
make this very point over in homenet.  So some client software will
for sure have unpredictable behaviour with respect to labels that
might be domain name labels.  

> eternal incompatibility pain.

Yes.  But this WG is not chartered to tell you how to run your domain,
or your mail server, in a sane manner.  If we start adding advice to
the document about all the ways things probably won't work if you do
stuff wrong, we'll never finish.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 26 Aug 2012 01:30 -0400

> working group agrees on the text suggested above or any other text.

Reverts as you said to do, but I think that the now current text:

          Internationalized domain names MUST be encoded as A-labels, as
          described in Section 2.3 of <xref target="RFC5890"/>.on 2.3
          of <xref target="RFC5890"/>.

is outside the scope of our charter since this is a new requirement and it's 
not related to a widely deployed extension of SPF, so we need to address it.

It may simply be a matter of acknowledging that since SPF records are ASCII, 
this is the only way to do it.  Suggestions?

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Sun, 26 Aug 2012 00:13:27 -0700

>not related to a widely deployed extension of SPF, so we need to address it.

Yes.

>this is the only way to do it.  Suggestions?

Suggestions from WG participants are welcome.

Regards,
S. Moonesamy