Subject: RE: draft-phillips-langtags-08, process, specifications, "stability", and extensions

From: "Peter Constable" <[email-masked]>
Date: Thu, 6 Jan 2005 06:48:03 -0800

> From: [email-masked] [mailto:ietf-languages-
> [email-masked]] On Behalf Of [email-masked]

> My reading of that text is that it goes out of its way to try and
avoid
> direct
> discussion of a matching algorithm, talking instead about "rules" and
> "constructs". I no longer recall the circumstances behind this, but my
> guess
> would be that talking about algorithms directly moved this
specification a
> bit
> too close to implementation work, which in turn would argue for the
normal
> standards track and its ability to assess interop status, not BCP.
> 
> This present yet another problem for the current draft, BTW.

You say that it avoids direct discussion of an algorithm, but then imply
that it talks directly about algorithms. Which is it?

If it talks about principles that may be used in processing tags in a
general sense, but not a specific algorithm, then I don't see that there
is any problem. All that it is doing is giving guidance regarding the
semantic relationships that may exist between tags of different types,
and pointing out what processes may or should not change about a tag to
preserve it's well-formedness and preferred ('canonical') structure, all
things within the scope of a BCP that doesn't specify any specific
matching algorithms.

Peter Constable

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

---

From: [email-masked]
Date: Thu, 06 Jan 2005 07:29:19 -0800 (PST)

> that it talks directly about algorithms. Which is it?

Sorry, I should have said "would have moved" instead of just "moved".

> is any problem.

The problem is that as this stuff has gotten more complex the need for an
explicit algorithm specification (or more than one, or one with a  bunch of
parameters, or whatever) has increased, in order to insure inteoperability
between different implementations processing language tags. You have
addressed this by having a more explicit description of how to match
these things than 3066 did.

Whether or not this is sufficient, and whether or not it has moved
close enough to an algorithm description for it to be an issue for a BCP
is the IESG's call. I'm merely pointing out that this is yet another
potential issue with the direction this work has gone.

				Ned