Subject: Re: [EAI] Proposed resolution of List-* and downgrade- Issues

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 04 Aug 2008 12:10:18 +0100

On Thu, 31 Jul 2008 16:44:35 +0100, Frank Ellermann  
<[email-masked]> wrote:

> Charles Lindsey wrote:
>
>> What we would want to write is
>>    Archived-At: <http://archive.mañana.com>
>> which is an IRI (using UTF-8, as always with IRIs)
>
> JFTR, s/as always with IRIs/as always with EAI/
>
> EAI always uses UTF-8, while IRIs can be in any charset
> determined by the context.  And for EAI that context is
> of course UTF-8.  But in a KOI8-R document it's KOI8-R:

Not quite. It the IRI appears in a document written in KO18-R, then:
1. You convert the KO18-R into unicode
2. You convert the unicode into UTF-8
3. You %-encode the UTF-8
4. Now you have the proper URI

Of course if the context is headers within a UTF8SMTP message, then steps  
1 and 2 are redundant.

>> which, upon conversion to a URI, would simply %-encode
>> that 'ñ'.
>
> For an <ipath>, <iquery>, or an <ifragment>.  But your
> example has the ñ in the <ihost>, and there you would
> use IDNA(bis) rules to convert this into an URL:
>
> Archived-At: <http://archive.xn--maana-pta.com/>

RFC 3987 says you MAY (possibily even SHOULD) convert to punycode in this  
case, but you also MAY just %-encode it and hope whatever comes next knows  
how to punycode it before doing any DNS lookup.

OTOH, IRIs are not currently allowed in the 'http' scheme, so it would  
need an explicit EAI extension (plus downgrade) to permit the Archived-At  
header field to use IRIs. Likewise for any List-* header fields.

Likewise for the 'mailto' scheme unless and until mailto-bis tells us  
otherwise. I think we really need Martin to publish a mailto-bis draft  
before we can proceed much further with List-* headers.

> Mailto-bis IRIs on a KOI8-R page would be interesting:
>
> If they are transformed to UTF-8 (the first step in a
> IRI to URI conversion) they might work with EAI UTF-8.

The rule is clear that you first apply the 4 steps I gave above. before  
you try interpreting them further.

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 4 Aug 2008 17:21:28 +0200

>> JFTR, s/as always with IRIs/as always with EAI/
[...]

> Of course if the context is headers within a UTF8SMTP
> message, then steps 1 and 2 are redundant.

Yes, that's what I meant.  And depending on the charset
steps 1 and 2 could be combined, KOI8-R is an example
where that works - it works for all SBCS with US-ASCII
as propoer subset.
  
>> you would use IDNA(bis) rules to convert this into
>> an URL:

> RFC 3987 says you MAY (possibily even SHOULD) convert
> to punycode in this case, but you also MAY just %-encode
> it and hope whatever comes next knows how to punycode it
> before doing any DNS lookup.

The goal is to get a <reg-name> for DNS in many relevant
contexts:

| A registered name intended for lookup in the DNS uses
| the syntax defined in Section 3.5 of [RFC1034] and
| Section 2.1 of [RFC1123].

 [Digression, this remark in RFC 3986 kills hypothetical
  IDN TLDs again, until RFC 1123 section 2.1 is updated.]

| Such a name consists of a sequence of domain labels
| separated by ".",  each domain label starting and ending
| with an alphanumeric character and possibly also
| containing "-" characters.

Clearly no "percent" characters in a <reg-name> for DNS.

That is as it should be, DNS won't do the punycode magic,
legacy applications (i.e. almost all applications minus
some modern browsers, xmpp, or similar) also won't do it,
but RFC 3987 behind a barrage of MAY and SHOULD weasel
words "does" it.  Where it doesn't it cannot work, there
is no archive.ma%c3%B1ana.com in DNS.

Hopefully, nobody knows what this could be if it exists,
I'd bet on all possible malicious purposes.

But you are right - any serious 3987bis proposal has to
fix this strange "MAY or SHOULD" to a simple "MUST" wrt
DNS.  Nobody is going to register %-encoded raw UTF-8
CNAMEs for all IDN A-labels.  Only the opposition might
try that where it sees a potential profit.

> IRIs are not currently allowed in the 'http' scheme

Why do you think that http-IRIs are not allowed ?  My
assumption is that all URI-schemes can be also used as
IRI-schemes, in theory, down to 'mailto' as worst case.

But some document formats, notably HTML 4, XHTML 1, and
message/rfc822 header fields, allow only URIs.  And no
oddities with "percent" characters in a <reg-name> if
this is about the registry known as DNS.  

 Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 05 Aug 2008 10:38:18 +0100

> try that where it sees a potential profit.

Well draft-duerst-iri-bis-04.txt, published within the last day or so, has  
changed nothing in that area AFAICS.
> Why do you think that http-IRIs are not allowed ?

Because it says so in RFC 3987, and still seems to say it in  
draft-duerst-iri-bis-04.txt.
> ...  My

Not unless the document defining the scheme says so, apparently.