Subject: Re: [ldapext] [Fwd: I-D ACTION:draft-hall-ldap-idn-00.txt]

From: John McMeeking <[email-masked]>
Date: Wed, 2 Jul 2003 08:51:36 -0500

I'm not too familiar with IDNs, but I'll offer some initial questions (I
hesitate to call them informed comments).

If we require storing UTF-8 IDNs, does this require that clients be able to
convert the IDN to the ASCII compatible sequence?  It seems like this could
present problems, as it requires application changes, whereas the ASCII
compatible sequence, while not "pretty" is at least usable without
application changes (true?).  We might allow, rather than require, UTF-8
IDNs; its pretty easy to tell that a string contains UTF-8 and process
accordingly if necessary, but the argument used above suggests it might not
be a good idea until the applications are ready.  Also, I suspect that most
applications would have to convert from UTF-8 to something else (local code
page?) anyway, but some LDAP clients do that for all string data already.
Converting from ASCII compatible to desired form should not be a problem.

With respect to the schema, hmm...  I'm not too fond of the idea of having
a dual set of objectclasses and attributes that applications must use.  But
I recognize that changing an IA5 String attribute to Directory String may
not be palletable to standards bodies, and requires work on the part of
implementations (schema updates, at least, possibly data migration, other
changes).

idc/inetDomainComponent - Could we drop the alias?  Aliases cause problems.
Defining an alias, while at the same time saying that systems MUST NOT use
the alias... seems a bit contradictory at best.

John  McMeeking

                      "Eric A. Hall"                                                                                      
                      <[email-masked]>        To:       [email-masked]                                                 
                      Sent by:                 cc:                                                                        
                      ldapext-admin@iet        Subject:  Re: [ldapext] [Fwd: I-D ACTION:draft-hall-ldap-idn-00.txt]       
                      f.org                                                                                               

                      07/02/2003 08:15                                                                                    
                      AM                                                                                                  

Any comments on this?

on 6/26/2003 7:08 AM Eric A. Hall wrote:
> FYI. Feedback appreciated.
>
> I really believe that something like this is needed to fully accomodate
> IDNs in LDAP. The use of client-side transformations are extremely
fragile
> and prone to errors (eg, copying the data from one LDAP application and
> pasting it in with another). I also think that nobody here really wants
to
> see codec output embedded in the namespace for years to come, but that's
> the only predictable outcome from using client transformations. We need
to
> have UTF-8 elements for IDNs in order for them to work reliably.
>
> The following issues in particular are still unresolved.
>
>   7.      Open Issues
>
>      Should a structured domain name sequence be formally defined, with
>      the inetDomainComponent and inetEmail attributes formally
>      incorporating that sequence?
>
>      Should the inetEmail attribute be formally defined as structured,
>      with the appropriate ASN.1?
>
>      Should there be extensible matching filters that accept non-
>      normalized input, normalize it, and then search for matching
>      elements and/or attributes?
>
> Thanks
>
>
>
> ------------------------------------------------------------------------
>
> Subject: I-D ACTION:draft-hall-ldap-idn-00.txt
> From: [email-masked]
> Date: Wed, 25 Jun 2003 10:52:10 -0400
> To: IETF-Announce: ;
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
>            Title                         : LDAP Schema Extensions for
Internationalized Domain
>                           Names
>            Author(s)         : E. Hall
>            Filename          : draft-hall-ldap-idn-00.txt
>            Pages                         : 16
>            Date                    : 2003-6-24
>
> This document defines schema and behavioral rules which are
> necessary to fully accommodate the use of internationalized domain
> names as UTF-8 sequences in LDAP. Specifically, this document
> defines an internationalized domain component attribute, email
> address attribute, URI syntax, and several related object classes,
> and also discusses their usage considerations.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hall-ldap-idn-00.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the
message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>            "get draft-hall-ldap-idn-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>            [email-masked].
> In the body type:
>            "FILE /internet-drafts/draft-hall-ldap-idn-00.txt".
>
> NOTE:            The mail server at ietf.org can return the document in
>            MIME-encoded form by using the "mpack" utility.  To use this
>            feature, insert the command "ENCODING mime" before the "FILE"
>            command.  To decode the response(s), you will need "munpack"
or
>            a MIME-compliant mail reader.  Different MIME-compliant mail
readers
>            exhibit different behavior, especially when dealing with
>            "multipart" MIME messages (i.e. documents which have been
split
>            up into multiple messages), so check your local documentation
on
>            how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

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

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 02 Jul 2003 09:00:21 -0500

on 7/2/2003 8:51 AM John McMeeking wrote:

> If we require storing UTF-8 IDNs, does this require that clients be
> able to convert the IDN to the ASCII compatible sequence?

Only if the client does some kind of active DC<->DNS mapping. In practice,
there are very few applications which do this right now (although more are
coming, and it would be a good idea to specify the use of IDNs sooner
rather than later). Of those few applications, most of them can be handled
through some of the workarounds described in the draft (eg, using
referrals to point the dc searchbase to an idc naming context).

> With respect to the schema, hmm...  I'm not too fond of the idea of
> having a dual set of objectclasses and attributes that applications
> must use.  But I recognize that changing an IA5 String attribute to
> Directory String may not be palletable to standards bodies, and
> requires work on the part of implementations (schema updates, at least,
> possibly data migration, other changes).

I modelled after the domainComponent draft but I'm not married to it.

> idc/inetDomainComponent - Could we drop the alias?  Aliases cause
> problems. Defining an alias, while at the same time saying that systems
> MUST NOT use the alias... seems a bit contradictory at best.

I was trying to be "complete" by allocating the long form of the name, but
I'm not married to it.