[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] [Fwd: I-D ACTION:draft-hall-ldap-idn-00.txt]
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"
<ehall@ehsco.com> To: ldapext@ietf.org
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: Internet-Drafts@ietf.org
> 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:
> mailserv@ietf.org.
> 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
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext