headers
Eric A. Hall | 3 Jul 16:37

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


on 7/3/2002 3:28 AM Erik Nordmark wrote:
>> |  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

> 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
(Continue reading)

Permalink | Reply |
headers
Erik Nordmark | 4 Jul 16:37
Picon

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

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

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

   Erik
Permalink | Reply |
headers
Eric A. Hall | 4 Jul 17:15

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


on 7/4/2002 9:37 AM Erik Nordmark wrote:
>> 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.

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
(Continue reading)

Permalink | Reply |
headers
Erik Nordmark | 4 Jul 18:30
Picon

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


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

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

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

The RDATA of the TXT record is a kerberos realm name according to the draft.

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

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
(Continue reading)

Permalink | Reply |
headers
Eric A. Hall | 4 Jul 19:22

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


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
>> is still a domain name and gets used to seed subsequent lookups.
>
> The RDATA of the TXT record is a kerberos realm name according to the
> draft.

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
(Continue reading)

Permalink | Reply |
headers
Erik Nordmark | 5 Jul 10:35
Picon

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

> From what I understand, the realm is sucked out of the TXT RR, and is then
> 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.

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

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

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

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".
(Continue reading)

Permalink | Reply |
headers
Patrik Fältström | 4 Jul 17:04
Picon
Favicon

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

--On 2002-07-04 16.37 +0200 Erik Nordmark <Erik.Nordmark <at> sun.com> wrote:

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

They have done their own profiles of stringprep.

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

   paf
Permalink | Reply |

Gmane