Subject: Re: [idn] I-D ACTION:draft-ietf-idn-idna-10.txt

From: Erik Nordmark <[email-masked]>
Date: Wed, 3 Jul 2002 10:28:51 +0200 (CEST)

>  |  2. Perform the steps specified in [NAMEPREP] and fail if there is
>  |     an error. The AllowUnassigned flag is used in [NAMEPREP].
> 
> "allowunassigned" does not appear in draft-ietf-idn-nameprep-11.txt

Searching for "unassigned" in nameprep-11 results in:
	7. Unassigned Code Points in Internationalized Domain Names

	If the processing in [IDNA] specifies that a list of unassigned code
	npoints be used, the system uses table A.1 from [STRINGPREP] as its list
	of unassigned code points.

What is the problem?

> Is this the intended mechanism for allowing alternative profiles to be
> encoded in IDNA? I see that section 1.1 says that nameprep is mandatory:
> 
>  | IDNA requires that implementations process input strings with
>  | Nameprep [NAMEPREP], which is a profile of Stringprep [STRINGPREP],
>  | and then with Punycode [PUNYCODE]. Implementations of IDNA MUST
>  | fully implement Nameprep and Punycode; neither Nameprep nor Punycode
>  | are optional.
> 
> Collectively this means that nameprep is still the gatekeeper, and that
> profiles other than nameprep cannot be encoded with IDNA.

When there are additional profiles for domain names, it might 
makes sense to have a standards track RFC that either updates the IDNA RFC
to say when the new profile can be used, or (depending on how different
things would be for the new usage) it might make sense to
have a standards track RFC which uses "newprep" plus punycode.
But such a future doesn't mean that IDNA can bypass the requirement that
nameprep applies today - removing that requirement might lead folks to believe
they can do non-standard prep and still be compliant with IDNA. That would lead
to non-interoperability as far as I can tell.

  Erik

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 03 Jul 2002 09:37:43 -0500

> What is the problem?

Anal types like me see StudlyCapped functions and flags and expect to find
them documented. Other than that, none I suppose.

>> Collectively this means that nameprep is still the gatekeeper, and
>> that profiles other than nameprep cannot be encoded with IDNA.
>
> When there are additional profiles for domain names, [...]

There are already profiles described for iSCSI names and Kerberos realms.

> it might makes
> sense to have a standards track RFC that either updates the IDNA RFC to
> say when the new profile can be used, or (depending on how different
> things would be for the new usage) it might make sense to have a
> standards track RFC which uses "newprep" plus punycode.

Requiring new codecs for new profiles is all cost and zero benefit. What
possible value is there in forcing applications to define new codecs with
different outputs for their alternative names?

> But such a
> future doesn't mean that IDNA can bypass the requirement that nameprep
> applies today - removing that requirement might lead folks to believe
> they can do non-standard prep and still be compliant with IDNA.

Being "compliant" with IDNA is a matter of surviving a trip through
ToASCII and back. As far as I can tell, any standards-track stringprep
profile which uses label sequences can meet this requirement.

> That would lead to non-interoperability as far as I can tell.

If an organization starts using kerberos-prep for zone delegation or
addressing purposes then yes, there would be interoperability problems
with the applications that decode the sequences. In fact there would be so
many problems that one is left to wonder how anybody would willfully do
something that stupid.

On the other hand, requiring new profiles to develop new codecs imposes
its own interoperability problems. EG, all forms of network data are
guaranteed to be opaque to everybody until all of the codecs have been
installed on every machine on the planet. You can't encode/decode Kerberos
names into a local text file until you've got the codec...

This would be a significant negative development towards the notion of
transparency. One codec for all domain name-like profiles of stringprep
should be enough.

I thought we had settled this argument a couple of weeks ago.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: John C Klensin <[email-masked]>
Date: Wed, 03 Jul 2002 19:01:29 -0400

--On Wednesday, 03 July, 2002 10:28 +0200 Erik Nordmark
<[email-masked]> wrote:

Erik,

Let me try to explain what I think Eric is trying to get at,
since I think we may be suffering from a rather basic
disconnect, not about what should be done, but about how
standards are defined.   I also think a couple of separate
issues are getting intertwined, adding to the confusion.

You wrote...

> makes sense to have a standards track RFC that either updates
> the IDNA RFC to say when the new profile can be used, or
> (depending on how different things would be for the new usage)
> it might make sense to have a standards track RFC which uses
> "newprep" plus punycode. But such a future doesn't mean that
> IDNA can bypass the requirement that nameprep applies today -
> removing that requirement might lead folks to believe they can
> do non-standard prep and still be compliant with IDNA. That
> would lead to non-interoperability as far as I can tell.

First, to repeat something I tried to say some time ago, and
which I think Dave Crocker and Eric have also tried to say,
although from other perspectives and in different language:

	* we have had fairly good success with standards whose
	extensibility model is "for Case X, do Y; any other
	cases are prohibited entirely without standards-track
	action"
	
	* we have had repeated bad experiences when the model is
	"always do Y" on the assumption that we can change that
	into "always do Y unless the following case arises, then
	do Z" with a later document.  Someone always comes along
	and claims it is an incompatible change that will wreck
	his environment, since he assumed that the language
	meant what it said, which is that the method applies to
	all cases, forever.

Please observe that, for Case X, these two definitions are
identical: the requirement is to "do Y", without alternatives,
defaults, options, etc.  In either case, the text has to be
reasonably clear to avoid unintentional "creative"
interpretations (and to make clear that someone who applies such
an interpretation is in the wrong).  But there is no difference
in the requirement that, for whatever names we apply IDNA today
(i.e., "Case X"), nameprep is required.  Properly written, the
question is only about whether we can use a different profile if
and when "Case Y" is adequately defined and justified.

I suggest that this difference in definitional model applies
equally to the "this applies to all RRs in all Classes" language
we discussed a week or so ago as it does to the "profiles with
IDNA" issue that prompted this thread.   The issue is the same,
and my recommendation is that, in both cases, we define the
cases which we require and understand and the actions for them,
that we prohibit any action at all in other cases, and that we
specify the mechanism (e.g., our usual handwaving about
"standards track documents") by which the prohibition may be
relaxed.

>> Is this the intended mechanism for allowing alternative
>> profiles to be encoded in IDNA? I see that section 1.1 says
>> that nameprep is mandatory:
>> 
>>  | IDNA requires that implementations process input strings
>>...
>> Collectively this means that nameprep is still the
>> gatekeeper, and that profiles other than nameprep cannot be
>> encoded with IDNA.

This is the other issue, and it is almost separate.  I think
what Eric is trying to suggest is that IDNA specifies a general
mechanism that could reasonably be used with other stringprep
profiles for other circumstances.  Perhaps he is right --e.g.,
it might be useful for some "directory layer" approaches-- or
perhaps not.  But it is almost certainly useful to avoid having
two nearly-identical documents at early maturity levels on the
standards track: if we discover something wrong, we would have
to make synchronous changes to both.   As a user and
sometime-implementor, I hate such things; as an AD who might end
up having to coordinate the changes, I would assume you might
hate it even more.

I can think of two ways to accomodate Eric's objective.  The
first is to put language into IDNA similar to what I've
suggested above (e.g., "use nameprep for this specific list of
cases, all other cases are prohibited unless this section is
updated by standards-track action").  The required language
might, in practice, be a little convoluted and, if you are
having a problem with the probable convolutions, perhaps the
other alternative would be more attractive (although I think it
involves more work, which I'm reluctant to call for at this
stage).

That other alternative says that we define, by copying most of
idn-idna-11, a new protocol document.  Let's call it ur-IDNA for
the time being, with a title like "A Framework for
Internationalizing Names in Applications".  For this purpose, it
makes no assertions at all about nameprep.  Instead, where
nameprep is invoked today, it would say something like "apply a
stringprep profile as specified by the relevant applicability
document".  And we slice out the DNS-specific text as well:
ur-IDNA becomes simply and purely a model for taking strings in
Unicode form and making them into a canonical ASCII-based
encoding (and vice versa) by applying a specific set of steps.

Then we create a new document, IDNAbis, from what is left over.
IDNAbis defines how to handle DNS hostnames -- labels for a
specific set of RRs in Class=IN.  In principle, it ought to be
pretty short, since its essence should be "execute ur-IDNA,
using the nameprep profile" along with a specification of its
applicability.  It would be somewhat longer and more complicated
than that in practice, since it would need to define FQDN
decomposition rules.  Or, to translate where I think Dan's
suggestions have been heading into this context, it might invoke
a decomposition profile by a separate reference.

Now, while I personally don't think it would be necessary (a
brief flash of optimism), if we were worried about "creativity",
ur-IDNA could contain an explicit statement that the thing is
application-specific and that its use for _anything_ is
prohibited without an application-specific, standards-track,
profile and applicability statement.  That would presumably
avoid any loose ends.

These two (or three) documents would provide a somewhat
different decomposition than the split Dave recommended.
Combining both splitting models, if desired, would presumably
create a lot of documents.  But I wonder whether the right
approach for now would be to slip the prohibition and "standards
track expansion" language into idn-idna-XX, and then sort this
out into a better form when the docs come up for Draft.   If, of
course, IESG decides to advance this work at all.

Is that helpful in at least clarifying the issue?

     john

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 4 Jul 2002 16:37:14 +0200 (CEST)

> There are already profiles described for iSCSI names and Kerberos realms.

Correct me if I am wrong, ut I didn't think they were going to use IDNA; 
neither iSCSI names or kerberos realms are domain names (they have
different syntactic restrictions as far as I knpw) and IDNA is
about domain names. Thus they might use punycode if they need an
ASCII encoding, but not IDNA.

> different outputs for their alternative names?

The "codec" is punycode, right?
If not, what is your definition of "codec"?

   Erik

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 04 Jul 2002 17:04:59 +0200

> ASCII encoding, but not IDNA.

They have done their own profiles of stringprep.

See for example draft-ietf-ips-iscsi-string-prep-02.txt.

   paf

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 04 Jul 2002 10:15:13 -0500

> Correct me if I am wrong, ut I didn't think they were going to use
> IDNA; neither iSCSI names or kerberos realms are domain names (they
> have different syntactic restrictions as far as I knpw) and IDNA is
> about domain names.

I don't know about iSCSI but Kerberos can be used with a new RR quite
effectively. Google for draft-ietf-krb-wg-krb-dns-locate-02.txt for an
example of how they were using TXT RRs to determine the realm associated
with a domain. Although they use TXT (this was to avoid compression which
would cause case-conversion, and is avoidable through other means) but it
is still a domain name and gets used to seed subsequent lookups.

As to whether or not these are valid domain names, sure they are. A domain
name is any series of labels that can be exchanged in a DNS message
(resulting in either a referral, an answer or an error). Certainly these
are more valid than the pseudo names generated with TKEY and TSIG.

As to your comment that these are not domain names since they are not
defined by nameprep, my position is that nameprep is misdefined. In its
current form, IDNA is about i18n hostnames, and there are other kinds of
domain names which can be exchanged but which cannot be represented with
nameprep (see the TKEY and TSIG logical domain names again).

>> Requiring new codecs for new profiles is all cost and zero benefit.
>> What possible value is there in forcing applications to define new
>> codecs with different outputs for their alternative names?
>
> The "codec" is punycode, right? If not, what is your definition of
> "codec"?

The IDNA codec is punycode with the IDNA prefix identifier. Without the
identifier, the data is not IDNA.

It's really simple: IDNA should just be a codec that generates IDNA label
output from UCS input (and vice-versa) and which supports any Stringprep
profile, while Nameprep should just define the i18n hostname profile. I've
been saying this for two years now.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 4 Jul 2002 18:30:15 +0200 (CEST)

> with a domain. 

Thanks for the pointer - I could only find draft-ietf-ips-iscsi-string-prep

> Although they use TXT (this was to avoid compression which

The RDATA of the TXT record is a kerberos realm name according to the draft.
 
> are more valid than the pseudo names generated with TKEY and TSIG.

The QNAME is clearly a domain name. The RDATA in the text record is not - it
is a case sensitive realm name.
Thus QNAME would be subject to nameprep when IDNA is used.
TXT records are not domain name slots thus IDNA does not apply.

[Note that I don't think that the use of _kerberos.<domain> names and txt
records have been discussed on namedroppers, and nothing in this email
should be construed as I think this is a good idea.]

Thus the kerberos folks can choose to standardize I18N realm names
and define a new stringprep profile (or use an existing one) and specify
that this applies to their TXT records at _kerberos.<domain>
I wouldn't be surprised if they wanted a profile of stringprep that does not
do case folding.

> As to your comment that these are not domain names since they are not

What does "these" refer to? The NAME or the content of the TXT RDATA?

> nameprep (see the TKEY and TSIG logical domain names again).

SRV is a better example since it explicitly violates the STD3 host name rules
with the leading underscore. TKEY and TSIG doesn't require domain names
to be outside the host name rules, nor does it require that they follow the
host name rules.

> identifier, the data is not IDNA.

Then I don't understand why you claim that a new codec is needed for new
profiles. The IDNA prefix and punycode could be used for other profiles
as well.

> been saying this for two years now.

While I understand the need for different profiles of stringprep for different
types of names, identifiers, and protocol elements, I still don't see a clear
case where a different profile would be required for *textual domain names*.

The textual domain names that do not conform to the STD3 host name syntax
rules (such as the NAME for SRV records) can be accomodated by not
setting the UseSTD3ASCIIRules in IDNA.

I'm concerned that having a standard which leaves the door completely open
with "use any stringprep profile" is exactly the type of loose definitions
that have gotten us into trouble in the past.
Specifying different profiles for different usage doesn't have this problem.

  Erik

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 04 Jul 2002 12:22:22 -0500

on 7/4/2002 11:30 AM Erik Nordmark wrote:

>> Although they use TXT (this was to avoid compression which would
>> cause case-conversion, and is avoidable through other means) but it

From what I understand, the realm is sucked out of the TXT RR, and is then
used to generate the SRV lookups.

 | Overview - KDC location information
 |
 |   KDC location information is to be stored using the DNS SRV RR [RFC
 |   2052].  The format of this RR is as follows:
 |
 |   Service.Proto.Realm TTL Class SRV Priority Weight Port Target

 |   The Realm is the Kerberos realm that this record corresponds to.

This is a very problematic design on multiple fronts, but I bring it up to
demonstrate the point that people want to use Kerberos realm names as
domain names. By the same token, people will want to store NetBIOS names
in the DNS as well (see STD19). And so forth.

> The QNAME is clearly a domain name. The RDATA in the text record is not
> - it is a case sensitive realm name. Thus QNAME would be subject to
> nameprep when IDNA is used. TXT records are not domain name slots thus
> IDNA does not apply.

IDNA does not apply to this model *YET*, but if they go to a custom RRtype
that stored the realm then the question of using IDNA would apply.

As for the qname question, note that the STD13 model would preserve the
capitalization on subsequent queries, while the IDNA model will burn the
capitalization during mutation if IDNA always requires nameprep.

Furthermore, see draft-hall-dns-datatypes for an inventory of currently
registered RRs. There are several RRs which do not use hostnames for the
owner name. These kinds of uses have to be allowed for.

>> The IDNA codec is punycode with the IDNA prefix identifier. Without
>> the identifier, the data is not IDNA.
>
> Then I don't understand why you claim that a new codec is needed for
> new profiles. The IDNA prefix and punycode could be used for other
> profiles as well.

> I'm concerned that having a standard which leaves the door completely
> open with "use any stringprep profile" is exactly the type of loose
> definitions that have gotten us into trouble in the past. Specifying
> different profiles for different usage doesn't have this problem.

Under the current wording, only the nameprep profile is allowed.

I am strongly in favor of profiles. What I am specifically arguing against
is the restriction in IDNA which prohibits the use of the codec with
anything other than nameprep:

 |     an error.

 | IDNA requires that implementations process input strings with
 | Nameprep [NAMEPREP], which is a profile of Stringprep [STRINGPREP],
 | and then with Punycode [PUNYCODE].

Nameprep is the only profile which can be used with IDNA.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 5 Jul 2002 10:35:30 +0200 (CEST)

> used to generate the SRV lookups.

The kerberos client needs know the (case sensitive) realm name to use it
in the kerberos protocol. This must be what drives the requirement that the
RDATA of the TXT not be case folded.
In addition, the kerberos client can use it to form SRV lookups, but if
that was the only use there would be no requirement that the RDATA preserved
case.

Hence the RDATA is a realm name. The realm name can be usd to form a SRV
lookup.

> that stored the realm then the question of using IDNA would apply.

It the RDATA in such an RR said it was a domain name, then IDNA would
apply. If the RDATA in such an RR was specified to be a realm name, then IDNA
would not apply. Thus in the latter case (which is what would make sense
due to the sensitivity of the realm names) then the definition of such a record
could choose to whatever it wants (including use realmprep and punycode with
the IDNA prefix; or use realmprepped UTF-8).

> capitalization during mutation if IDNA always requires nameprep.

But IDNA (ToASCII) doesn't always require nameprep; it isn't required for
all-ASCII labels. So I don't understand the point about "if IDNA always
requires nameprep".

> owner name. These kinds of uses have to be allowed for.

Agreed. 
Which ones do not work with IDNA in practise as IDNA is currently defined?
As far as I can tell all textual labels work with IDNA and IDNA explicitly
does not apply to non-textual labels.

> Nameprep is the only profile which can be used with IDNA.

Perhaps you could suggest alternate wording.
I'd like to understand how you can state something different
without resorting to "anything goes" given that there aren't other 
standardized (or ready to standardize) profiles to which IDNA could have
a normative reference.

   Erik