> > From: ietf-languages-bounces@xxxxxxxxxxxxx [mailto:ietf-languages- > > bounces@xxxxxxxxxxxxx] On Behalf Of ned.freed@xxxxxxxxxxx > > 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf