Message-Id: <6.1.2.0.2.20050406235147.0d8cc550@mail.jefsey.com>
Date: Thu, 07 Apr 2005 00:51:59 +0200
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>,
	"McDonald, Ira" <imcdonald@sharplabs.com>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: Re: Compatibility with existing use (LDAP) (RE: [Ltru] Re:
	Registry in record-jar format)
In-Reply-To: <6.2.1.2.0.20050406103739.05f45d60@mail.openldap.org>
References: <CFEE79A465B35C4385389BA5866BEDF00C7B2B@mailsrvnt02.enet.sharplabs.com>
	<6.2.1.2.0.20050406103739.05f45d60@mail.openldap.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: ltru@ietf.org
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

Kurt,
this suggestion is quite interesting. However as Addison documents it, the 
format does not make it as easy.

It would be really interesting if you could respond his objections using 
real langtags examples. Also if you could document a little more how you 
see the global LDAP system how imagine. I suppose that the DNS (along with 
STD 013) would be a simpler management system. But Randy's webdav and your 
LTAP ideas should certainly be investigated. CSV could also be 
discussed.  But there are not much difference between an LDAP meta system 
and a DNS based database system. All the more if coupled with an access 
engine. But I suppose LDAP could have a similar way to manage various formats.

jfc



At 20:12 06/04/2005, Kurt D. Zeilenga wrote:
>Ira, and other LTRU'ers:
>
>I am thinking that the LTRU effort should be considered
>more of a "replacement" effort than a "revision" effort,
>at least in its present form.  If you change the syntax
>and semantics of RFC 3066 tags, you will break everything
>that relies on them.  It would be better, in my opinion,
>to develop a new kind of tag which had a new syntax and
>semantics. That new kind of tag could be used in new
>things, possibly with support for existing RFC 3066 tags,
>but not in old things (at least not without revision of
>the old thing).
>
>I note that LDAP relies heavy on a number of aspects of
>RFC 3066 tags, most importantly that there is a
>well-defined syntactical tag hierarchy that doesn't
>require the implementation to know the tag's validity
>nor semantics to make use of tags in providing service.
>
>For instance, an LDAP server need not care if
>"FOO-BAR" is a valid tag to allow a client to add
>(a CN value tagged with "FOO-BAR"):
>         cn;lang-FOO-BAR: foo bar
>
>nor provide results a client requesting the return of all
>subtags of "FOO", e.g., (cn;lang-FOO-=*).
>
>The only requirement (and I believe its a SHOULD,
>not a MUST) is for the directory client adding values
>to use the most specific tag known to it and for
>requesting clients to use the least specific tag that
>will return acceptable (or desirable) stored values.
>It is noted that the client itself generally doesn't
>valid tags either, as tag (and range) knowledge
>generally comes from the user.
>
>So, not only does it concern me that these new tags
>don't follow the same syntactical hierarchy (and may
>require fuzzy matching), it concerns me that
>the new specification mandates that implementations
>be aware of what tags/subtags are registered (at
>some time).  That, to me, is like requiring SMTP
>implementations to know what MIME types are registered.
>Just as the SMTP is just a transport for MIME type
>information, protocols like LDAP are (primarily) just
>a transport for language information.  (LDAP also
>support lookups based on syntactical hierarchy, not
>the semantical hierarchy.)
>
>I think it unwise for protocols to, themselves,
>rely on value registries as this leads to fragile
>interoperability.  Registeries are better used to
>ensure that values in specifications are unique.
>
>Apologies for commenting without fully digesting
>the WG's draft in this area, or list archives, but
>it seems more appropriate for me to comment sooner
>than later.
>
>Kurt
>
>
>At 10:27 AM 4/6/2005, McDonald, Ira wrote:
> >Hi Kurt,
> >
> >Thanks very much - what LTRU is doing is rewriting
> >RFC 3066 and _greatly_ extending it to formally
> >address variants and scripts and other subtags.
> >
> >The nature and scope of the extensions breaks classic
> >left-to-right language tag matching completely.  The
> >phrase being used on the list for the replacement
> >is 'smart matching'.  Just how smart a piece of s/w
> >can be is the crux of the problem.  And there is no
> >concensus on the list about what algorithm should be
> >used for 'smart matching'.
> >
> >Also, LTRU is developing an IANA registry of EVERY
> >possible valid language tag.  Which is a noble ideal,
> >but...  (the logic is that this frees language tags
> >from dependency on possibly incompatible changes in
> >ISO 639-x and ISO 3166-x, which have in fact occurred)
> >
> >Cheers,
> >- Ira
> >
> >
> >Ira McDonald (Musician / Software Architect)
> >Blue Roof Music / High North Inc
> >PO Box 221  Grand Marais, MI  49839
> >phone: +1-906-494-2434
> >email: imcdonald@sharplabs.com
> >
> >-----Original Message-----
> >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> >Sent: Tuesday, April 05, 2005 3:40 PM
> >To: McDonald, Ira
> >Subject: RE: [Ltru] Re: Registry in record-jar format
> >
> >
> >Ira,
> >
> >I'm not in a position to comment on this thread as I haven't
> >caught up on what LTRU is or isn't trying to do to language
> >tags and language ranges.  I'm now subscribed to the LTRU
> >list and after I read up (not soon), I'll comment (likely
> >starting with a summary of how language tags and ranges
> >are used in LDAP, and why).
> >
> >Kurt
> >
> >At 02:17 PM 4/4/2005, you wrote:
> >>Hi,
> >>
> >>Relative to 'RFC 2616' matching rules below:
> >>
> >>It would be well to _explicitly_ address the impact of RFC3066bis
> >>matching rules on the recently published standards-track RFC 3866
> >>"Language Tags and Ranges in the LDAP" (July 2004).  If directory
> >>entries and/or directory attributes are returned 'incorrectly' by
> >>following RFC3066bis versus RFC3066, then this will have a visible
> >>impact on many enterprise applications.
> >>
> >>And to answer the immediate criticism, no I don't know the precise
> >>text to be added.  Perhaps Kurt Zeilenga (editor of RFC 3866) can
> >>comment?  I copied him on this reply.
> >>
> >>Cheers,
> >>- Ira
> >>
> >>Ira McDonald (Musician / Software Architect)
> >>Blue Roof Music / High North Inc
> >>PO Box 221  Grand Marais, MI  49839
> >>phone: +1-906-494-2434
> >>email: imcdonald@sharplabs.com
> >>
> >>-----Original Message-----
> >>From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]On
> >>Behalf Of Addison Phillips
> >>Sent: Monday, April 04, 2005 4:23 PM
> >>To: John Cowan
> >>Cc: ltru@ietf.org
> >>Subject: RE: [Ltru] Re: Registry in record-jar format
> >>
> >>
> >>See below.
> >>
> >>Addison P. Phillips
> >>Globalization Architect, Quest Software
> >>Chair, W3C Internationalization Core Working Group
> >>
> >>Internationalization is not a feature.
> >>It is an architecture.
> >>
> >>> -----Original Message-----
> >>> From: John Cowan [mailto:jcowan@reutershealth.com]
> >>> Sent: lundi 4 avril 2005 13:03
> >>> To: Addison Phillips
> >>> Cc: ltru@ietf.org
> >>> Subject: Re: [Ltru] Re: Registry in record-jar format
> >>>
> >>> Addison Phillips scripsit:
> >>>
> >>> > Answer: Yes, it is a problem, since users might have to specify two
> >>> > ranges or may get results inconsistent with their expectations. For
> >>> > example, the range "zh-TW" does not match the tag "zh-Hant-TW" using
> >>> > strict 3066 matching rules.
> >>>
> >>> Just a terminological note: I think these should be called HTTP or RFC
> >>> 2616
> >>> matching rules, since RFC 2616 is the true and authoritative source for
> >>> them.
> >>[Addison Phillips]
> >>
> >>Agreed.
> >>
> >>>
> >>> > i. "Extended Range Matching" is an extension of RFR in which "missing"
> >>> > subtags are considered to be (or are expanded to be) wildcards. So
> >>> > "de-1901" is expanded to "de-*-*-1901" and matches "de-Latn-1901" and
> >>> > "de-AT-1901", not to mention "de-Latg-NA-1901".
> >>>
> >>> I think this should be mentioned in the matching I-D.
> >>[Addison Phillips]
> >>
> >>I believe it is, although not this specific example. See
> >>http://www.inter-locale.com/ID/draft-ietf-ltru-matching-00.html#extrange
> >>
> >>>
> >>> > NB> Probably we need to extend this scheme to allow users to specify
> >>> > that they do NOT want a specific field to be filled in. For example
> >>> > "de-!-1901" would match only "de-1901" and not a tag such as
> >>> > "de-Latn-1901".
> >>>
> >>> I'd like to see a use case for this (not involving boont).
> >>[Addison Phillips]
> >>
> >>Find all content in need of retagging with a script in my Traditional
> >>Chinese document using XPath:
> >>
> >>/*@[lang="zh-!-TW"]
> >>>
> >>> > ii. "Lookup" is the opposite of matching, in which subtags are removed
> >>> > from the tag rather than the range (i.e. locale-style) to fill in all
> >>> > slots in a dataset. This matches a very different content set.
> >>>
> >>> This too should be mentioned.
> >>[Addison Phillips]
> >>
> >>Being added. Mark supplied text that I haven't had time to insert.
> >>>
> >>> > iii. "Scored Matching" was proposed by John Cowan and produces content
> >>> > with a range of scores, allowing the content to be filtered by choosing
> >>> > a "quality level" (my words) for the match. The user can set a
> >threshold
> >>> > for matching, presumably.
> >>>
> >>> As should this.
> >>[Addison Phillips]
> >>
> >>Agreed.
> >>>
> >>> > The problem here is that matching cannot be as simple as it was under
> >>> > RFC 3066 and still capture all possible cases.
> >>>
> >>> This is badly stated.  Only matching of predefined tags in RFC 3066
> >>> captures
> >>> all cases.
> >>[Addison Phillips]
> >>
> >>It is badly stated. But I'm not sure your version captures the nuances
> >>either. Perhaps:
> >>
> >>Only generative tags in RFC 3066 (i.e. those with only two possible
> >subtags)
> >>are guaranteed to work with RFC 2616 defined matching.
> >>>
> >>> --
> >>> Deshil Holles eamus.  Deshil Holles eamus.  Deshil Holles eamus.
> >>> Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x)
> >>> Hoopsa, boyaboy, hoopsa!  Hoopsa, boyaboy, hoopsa!  Hoopsa, boyaboy,
> >>> hoopsa!
> >>>   -- Joyce, Ulysses, "Oxen of the Sun"       jcowan@reutershealth.com
> >>
> >>
> >>_______________________________________________
> >>Ltru mailing list
> >>Ltru@lists.ietf.org
> >>https://www1.ietf.org/mailman/listinfo/ltru
>
>
>_______________________________________________
>Ltru mailing list
>Ltru@lists.ietf.org
>https://www1.ietf.org/mailman/listinfo/ltru


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru