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

[ned.freed at mrochek.com]

> > From: ietf-languages-bounces at alvestrand.no [mailto:ietf-languages-
> > bounces at alvestrand.no] On Behalf Of ned.freed at mrochek.com


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

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

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

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

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf