Subject: [EAI] Deciding what to do with IRIs in List-* headers

From: Harald Alvestrand <[email-masked]>
Date: Tue, 19 Aug 2008 09:45:48 +0200

Hello,

at our Dublin meeting, the issue of how to handle headers with URLs that 
contain non-ASCII characters (that is, they are IRIs in an URI slot) 
came up - in the context of List-* headers.

I see two possible ways forward:

1 - Don't address the issue at this time. Let such headers be turned 
into Downgraded-* headers, effectively hidden from the user's MUA. Add a 
comment that this will happen. This is the fastest path to getting 
-downgrade submitted.

2 - Add a new mechanism to -downgrade section 5

The mechanism would look something like this:
-------------------------------------------
Section 5 new paragraph:

IRI downgrading: If the header field has an element that is an IRI (that 
is, it follows the syntax described in RFC 3987 section 2.2, which 
allows for non-ASCII characters), it is processed with the algorithm 
specified in RFC 3987 section 3.1 for converting an IRI to an equvalent 
URI, [choosing the option of converting the hostname portion of an IRI 
using the IDNA encoding rather than percent encoding?]

Section 5.1 new paragraph:

o IRIs in header values

    List-Help
    List-Unsubscribe
    List-Subscribe
    List-Post
    List-Owner
    List-Archive

For all these headers, the values between < > may be considered IRIs if 
they contain non-ASCII characters, and converted accordingly.
-------------------------------------

What does the WG think?

                           Harald

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

---

From: Ted Hardie <[email-masked]>
Date: Tue, 19 Aug 2008 09:02:15 -0700

>using the IDNA encoding rather than percent encoding?]

I note that if you are going to go down this route, then you should
simply apply the process in RFC 3987 to all the elements in these
header fields.  At least if I read this text right:

  The above mapping from IRIs to URIs produces URIs fully conforming to
   [RFC3986].  The mapping is also an identity transformation for URIs
   and is idempotent;  applying the mapping a second time will not
   change anything.  Every URI is by definition an IRI.

applying it to the ones which are URIs but not IRIs is harmless.

That said, I would personally recommend Downgrade headers at
this time.  The reason for that goes back to Section 3.1., step one
of which is:  Generate a UCS character sequence from the original IRI format.
Since the IRI docs presume that some of these may be on the side
of a bus, it recognizes that you may have to first make a UCS character
sequence *before* applying this transform.  I suspect that folks
following this will, however, start with Step 1c, presuming that
they are dealing with UTF-8.   They will be right so often that the
times they're wrong will be unfixed essentially forever.

To spend the second penny of my two cents, my preferred order
for going beyond downgrade here would be:

1) Get the update IRI spec out with full community comment.

2) Get a mailto that is IRI-native out.

3) Adjust these headers to match the (new) IRI-native format,
possibly by creating new headers and continuing to downgrade
the old ones.  If we don't do that, any later introduction of new
syntax in here wil have 3 possible interpretations, which isn't
pretty.

Just my opinion,
			regards,
				Ted

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 19 Aug 2008 20:42:44 +0200

Harald Alvestrand wrote:

> [choosing the option of converting the hostname portion of
>  an IRI using the IDNA encoding rather than percent encoding?]

!

A percent-encoded <reg-name> is useless, the burden to figure
out DNS A-labels would be still on the wrong (= weaker) side.

And we are not going to mandate "get a percent-encoded UTF-8 
CNAME for each A-label (just in case, and because DNS allows
it)".  I think that is an issue in RFC 3986 + 3987, they try
to thell their story as far as possible independent of DNS.  

But DNS could in theory do what I've done in
http://hmdmhdfmhdjmzdtjmzdtzktdkztdjz.googlepages.com/IDN-XML-test.htm

In that case killing the W3C validator, Martin and I disagree
whose fault that is, I say 3987, he says validator, therefore
I reported it as validator bug (adding my doubts as comment).

 Frank

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 19 Aug 2008 22:22:30 +0200

> applying it to the ones which are URIs but not IRIs is harmless.
should be no problem in doing that, not doing it is just an optimized 
way of implementing an operation that causes no change....
> times they're wrong will be unfixed essentially forever.
Any time they're wrong, it's also a protocol violation; just as we don't 
propose extensions to deal with 8859-1 text in Subject:, we may want to 
overlook this one too.....
> syntax in here wil have 3 possible interpretations, which isn't
actually the List-* header spec doesn't limit itself in any way to 
mailto: - it is allowed to use any URI, and we can't treat a mailto: IRI 
differently from any other IRI.

By the time we can have a new mailto: spec out, I'm afraid that there 
will already be an installed base that doesn't do IRI->URI 
downconversion on these headers, and we may have UAs that expect the 
Downgraded-List-* headers.

That said, I am in two minds (at least) about this, and the promise of a 
new IRI spec is an excellent excuse to dither until the next revision. 
When is that expected?

                         Harald

---

From: [email-masked]
Date: Wed, 20 Aug 2008 17:47:01 +0900 (JST)

> From: Harald Alvestrand <[email-masked]>
> at our Dublin meeting, the issue of how to handle headers with URLs that contain non-ASCII characters (that is, they are IRIs in an URI slot) came up - in the context of List-* headers.
> 
> 1 - Don't address the issue at this time. Let such headers be turned into Downgraded-* headers, effectively hidden from the user's MUA. Add a comment that this will happen. This is the fastest path to getting -downgrade submitted.
> 

Does draft-ietf-eai-utf8headers-12 allow IRIs in List-* header fields ?

If "no", option 1 
If "yes", option 2

> From: Harald Tveit Alvestrand <[email-masked]>
> By the time we can have a new mailto: spec out, I'm afraid that there will already be an installed base that doesn't do IRI->URI downconversion on these headers, and we may have UAs that expect the Downgraded-List-* headers.

Current EAI document sets are in EXPERIMENTAL,
there are no such problems, I think.

Regards,

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 20 Aug 2008 10:24:53 +0100

> 2 - Add a new mechanism to -downgrade section 5

Hold on! The first step is to decide whether and what usage of UTF-8 in  
List-* headers is to be permitted, and what such headers might _mean_.  
Only then would it be sensible to discuss how to downgrade them (since the  
downgrade mechanism might depend on the answer to the first part).

So if we want to take a 'wait and see' approach whilst IRI-bis and  
mailto-bis are fixed, then the best method would be not to produce any EAI  
document for List-* headers at all (note, then when such a document _did_  
get produced, it would specify both the extended headers and how to  
downgrade them at the same time).

Having said that, I would be surprised if the eventual document did not  
include downgrading IRIs to URIs as part of its mechanisms.

In the meantime, a holding statement in our downgrade draft wold not be  
out of order.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
IMA mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ima