headers
Andrew Sullivan | 4 Aug 2008 20:08
Favicon

Some confusion about policy application and its effects

Dear colleagues,

I am starting to think that part of the problem I'm having with the
current proposals has to do with policy application and where it can
get done.  What follows is an outline of what I think my confusion
is.  Perhaps someone can point out to me where I've got this wrong.
Note that in what follows I have tried to avoid the "standard terms"
we've been using in the discussion, because I have a feeling that some
of them may be getting in the way of my understanding.

In IDNA2003 use, we have applications that call for resolution using a
specially-formatted name that otherwise does not perturb the
traditional use of DNS at all.  There are restrictions on what may go
into the DNS, in the sense that there are rules about characters, and
possibly labels when taken as a whole.  There may also be a number of
equivalence rules.  All of these restrictions, however, are rules that
are imposed at the registration side.  Applications still just get a
result back, and use that.  For convenience and consistency, the
application may just use Unicode and expect the transformations to be
supplied by some underlying library that's "bolted onto the front" of
the traditional resolver.  In some sense, though, we could regard that
approach as logically equivalent to having the library "bolted onto
the back" of the application.  The key is that rules about what counts
as a "legal domain name" under IDNA2003 (and under traditional DNS)
are applied at the registration end of the DNS.  You get a local error
if you don't have an input label that can be successfully transformed
according to IDNA2003 rules; but that's not really different from a
typo where you include a "/" in your ASCII-only domain name.

IDNA2008 takes a different approach, though, because local
(Continue reading)

Permalink | Reply | 6 comments |
headers
Paul Hoffman | 4 Aug 2008 21:00
Picon

Re: Some confusion about policy application and its effects

At 2:08 PM -0400 8/4/08, Andrew Sullivan wrote:
>In my reading, in traditional ASCII-only DNS resolution, two clients
>C1 and C2 will both get the same result to the same query for a name N
>when querying the same server at the same time.  Under IDNA2003,
>that's also true.  While the scope of N might be different, an
>IDNA2003-compliant client will perform the same transformation to the
>"Unicode labels" each time.  The display of the result will be the
>same, too (as long as both C1 and C2 are both IDNA-aware).  As near as
>I can tell, however, the same is _not_ true for IDNA2008, because
>local mappings may change both the input to the transformation
>function and the displayed output after the answer is returned.  If C1
>and C2 have different policies (different locales, for instance?),
>then at least the meaning of "same query" is not clear to me.

That is all correct.

>If I'm right about the above, I wonder whether it is a (new) layering
>violation; and if so, whether it's an acceptable one in the face of
>the alternatives.

Can you specify which layers you think are being violated?
Permalink | Reply | 3 comments |
headers
Andrew Sullivan | 4 Aug 2008 21:28
Favicon

Re: Some confusion about policy application and its effects

On Mon, Aug 04, 2008 at 12:00:35PM -0700, Paul Hoffman wrote:

> >If I'm right about the above, I wonder whether it is a (new) layering
> >violation; and if so, whether it's an acceptable one in the face of
> >the alternatives.
> 
> Can you specify which layers you think are being violated?

I'm sorry I'm not being terribly coherent about this; I think the
problem is partly that I really am confused.  Perhaps "layering
violation" is the wrong way to think about it.  It's more like a leak
in between the application and presentation layers: whether a "unicode
label" is "allowed" seems almost to be an emergent property of the
interaction among whatever the local policy is, IDNA itself, and the
policies that determine registration rules at the registration end of
the DNS.  (Maybe this is exactly what Mark Davis has been getting at
in his expressed worries about stable mappings, and I'm just
expressing it half as well because of a poorer understanding?)

A  

--

-- 
Andrew Sullivan
ajs <at> commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/
Permalink | Reply | 2 comments |
headers
Erik van der Poel | 4 Aug 2008 23:19
Picon
Favicon

Re: Some confusion about policy application and its effects

On Mon, Aug 4, 2008 at 8:08 PM, Andrew Sullivan <ajs <at> commandprompt.com> wrote:
> In IDNA2003 use, we have applications that call for resolution using a
> specially-formatted name that otherwise does not perturb the
> traditional use of DNS at all.  There are restrictions on what may go
> into the DNS, in the sense that there are rules about characters, and
> possibly labels when taken as a whole.  There may also be a number of
> equivalence rules.  All of these restrictions, however, are rules that
> are imposed at the registration side.  Applications still just get a
> result back, and use that.  For convenience and consistency, the
> application may just use Unicode and expect the transformations to be
> supplied by some underlying library that's "bolted onto the front" of
> the traditional resolver.  In some sense, though, we could regard that
> approach as logically equivalent to having the library "bolted onto
> the back" of the application.  The key is that rules about what counts
> as a "legal domain name" under IDNA2003 (and under traditional DNS)
> are applied at the registration end of the DNS.  You get a local error

IDNA2003 seems to say that client applications must check for
prohibited characters and must not use the domain name if ToASCII
fails.

> if you don't have an input label that can be successfully transformed
> according to IDNA2003 rules; but that's not really different from a
> typo where you include a "/" in your ASCII-only domain name.
>
> IDNA2008 takes a different approach, though, because local
> mappings are allowed.  This means that there is policy at the
> registration/DNS side of DNS operation, _but also_ on the client end
> of the transaction.  I understand the motivation for this innovation.
> But I think it probably breaks the "lookup and use" model that
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vint Cerf | 4 Aug 2008 23:27
Picon
Favicon

Re: Some confusion about policy application and its effects

Thanks Erik and Andrew. It would seem that there has to be a sort of  
balance on the subject of local mappings. Plainly, they can lead to  
idiosyncracies. On the other hand, the introduction of such a broad  
range of new scripts in the context of many languages not expressible  
in limited Latin character sets and keyboards does push the DNS in  
the direction of broader scope and somewhat less convenient reliance  
on a limited character set. The "LDH" limitations had many benefits  
including a convenient "compatbility" with the protocol strings  
associated with email addresses, host names, URLs and other WWW  
elements, etc. I think Erik's remarks suggest that there might grow  
up some conventions around particular scripts (if not languages) that  
might become widely practiced. It's an interesting question whether,  
when and how one might codify such conventions.

vint

On Aug 4, 2008, at 5:19 PM, Erik van der Poel wrote:

> On Mon, Aug 4, 2008 at 8:08 PM, Andrew Sullivan  
> <ajs <at> commandprompt.com> wrote:
>> In IDNA2003 use, we have applications that call for resolution  
>> using a
>> specially-formatted name that otherwise does not perturb the
>> traditional use of DNS at all.  There are restrictions on what may go
>> into the DNS, in the sense that there are rules about characters, and
>> possibly labels when taken as a whole.  There may also be a number of
>> equivalence rules.  All of these restrictions, however, are rules  
>> that
>> are imposed at the registration side.  Applications still just get a
>> result back, and use that.  For convenience and consistency, the
(Continue reading)

Permalink | Reply | 0 comments |
headers
John C Klensin | 5 Aug 2008 00:15

Re: Some confusion about policy application and its effects


--On Monday, 04 August, 2008 15:28 -0400 Andrew Sullivan
<ajs <at> commandprompt.com> wrote:

> I'm sorry I'm not being terribly coherent about this; I think
> the problem is partly that I really am confused.  Perhaps
> "layering violation" is the wrong way to think about it.  It's
> more like a leak in between the application and presentation
> layers: whether a "unicode label" is "allowed" seems almost to
> be an emergent property of the interaction among whatever the
> local policy is, IDNA itself, and the policies that determine
> registration rules at the registration end of the DNS.  (Maybe
> this is exactly what Mark Davis has been getting at in his
> expressed worries about stable mappings, and I'm just
> expressing it half as well because of a poorer understanding?)

Andrew,

At least part of the source of your confusion is that I wrote
the relevant text badly, in a way that makes it sound much more
permissive than I intended.  I'm working on that now; you should
expect updated drafts of both Protocol and Rationale later this
week.

However, I also think that your earlier note reflects a
misconception about the actual difference between IDNA2003 and
IDNA2003 in practice (as possibly distinct from "in theory if
everyone behaves themselves" or, even more important, "in theory
is everyone behaves with IDNA2003 but goes hog-wild with
IDNA2008".  The latter is where there is a real potential for
(Continue reading)

Permalink | Reply | 1 comment |
headers
JFC Morfin | 5 Aug 2008 01:42

Re: Some confusion about policy application and its effects

At 00:15 05/08/2008, John C Klensin wrote:
>If there is a layering violation, it is there in both IDNA2003 and 
>IDNA2008 although it is certainly more likely with the latter.

We know from the very begining that IDNA is a measured risk 
architectural protocol violation.  It is not end to end. Its is not 
an RFC 1958 technology wide solution. You perfectly described the 
fuzzyness of IDNA in some cases. So, it is restricted to areas where 
it is not fuzzy : this was made fully clear by the answers James Seng 
gave to my questions about IDNA ambitions, that Vint approved. The 
purpose of this WG is to publish a fully consistent IDN200X along its Charter.

This WG and AD decided that it is up to others organization to 
discuss and document interoperable or non-operable IDNA replacements 
in the areas as Andrew considers. They decided that they had to 
consider and to discuss interoperability with IAB. I regreted that, 
but IETF does not govern the Internet, it only strives to influence 
those who design, use and manage it (RFC 3935) so it works better. So 
it is up to ICANN to document their cons and pros, and to refer to 
them or not in their contracts depending on the situations. It is up 
to the TLD Managers and to the users to use them or not.

The best we can do is to clearly, urgently and precisely document the 
IDNA protocol and its applicability limitations in the security section.
jfc
Permalink | Reply | 0 comments |
headers
Frank Ellermann | 5 Aug 2008 18:20
Picon
Picon

Re: IDN example TLDs (2606bis)

Tina Dam wrote:

> while I am focused on the .test TLDs, you mention the SLDs.

Now also mentioned in the draft, reserving them as TLDs as
discussed off list:

<http://tools.ietf.org/html/draft-ellermann-idnabis-test-tlds>

This foray (*) in the realms of IDN depended on a single
RFC 20 octet to stay within the 72 columns limit for RFCs:

    ".xn--fdbk5d8ap9b8a8d" Yiddish       5d1 5f2 5b7 5e9 5e4 5bc 5d9 5dc
    ".xn--hxajbheg2az3al"  Greek 3c0 3b1 3c1 3ac 3b4 3b5 3b9 3b3 3bc 3b1
....5...10....5...20....5...30....5...40....5...50....5...60....5...70..

 Frank
--

-- 
*: http://omniplex.blogspot.com/2008/08/spf-eai-and-idn-tlds.html
Permalink | Reply | 0 comments |
headers
Frank Ellermann | 5 Aug 2008 19:30
Picon
Picon

Re: LDH-label terminology

John C Klensin wrote:

> I do expect some sort of answer.

I found the first part of an answer (quoted below,
AS = Andrew) in the (draft) DNSEXT minutes:

<http://article.gmane.org/gmane.ietf.dnsext/11993>

 Frank

~~~ cut ~~~
4.3 Clarification to RFC 1123
     http://www.ietf.org/proceedings/08jul/slides/dnsext-3.pdf

TLD labels are always alphabetic per RFC 1123. That needs to
be updated. One reason is the use of internationalized domain
names in top level domains.

Matt Larson & Lars-Johan Liman have volunteered to draft text.

Warnings were conveyed that there are issues both in the
protocol specification and in registration procedures (which
really belong with the IANA). It was also noted that old
implementation may have problems accommodating TLDs that don't
follow the old spec.

Alfred Hoenes noted that there is also a problem with
formal specifications of DNS labels, which often differ from
document to document.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Georg Ochsner | 8 Aug 2008 12:46

Eszett (Sharp-S) - 3 (was AW: Comments on idnabis-rationale-01)

> -----Ursprüngliche Nachricht-----
> Von: Marcos Sanz/Denic
> Gesendet: Donnerstag, 17. Juli 2008 09:51

> * Section 7.3: Just a naive question, no second meanings: what reasons
> speak at the moment *against* including the Eszett in the PVALID list
> under the category of exceptions? Thanks.

In my opinion if Denic agrees or just doesn't mind to add the sharp s
(Eszett), then it should be done.

Best regards
Georg
Permalink | Reply | 0 comments |

Gmane