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

From: Bruce Lilly <[email-masked]>
Date: Wed, 5 Jan 2005 14:27:38 -0500

>  Date: 2005-01-05 10:33
>  From: [email-masked]

> > Section 2.5 (2.4.1 in the draft) states the matching rule in a succinct
> > fashion.  Everything in 2.4.2 is a non-normative elaboration of this.
> 
> ??? Which in no way refutes my assertion that no matching rule algorithm
> was given in RFC 3066!

I believe that John meant sect. 2.5 of RFC 3066, which does indeed
mention a matching algorithm.  However, the proposed changes in the
structure of tags interact badly with that algorithm.

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

---

From: John Cowan <[email-masked]>
Date: Wed, 5 Jan 2005 16:02:31 -0500

Bruce Lilly scripsit:

> mention a matching algorithm.

Yes.

> However, the proposed changes in the

It just makes the algorithm imperfect; however, it was imperfect before as well.

-- 
John Cowan    http://www.ccil.org/~cowan   <[email-masked]>
    "Any legal document draws most of its meaning from context.  A telegram
    that says 'SELL HUNDRED THOUSAND SHARES IBM SHORT' (only 190 bits in
    5-bit Baudot code plus appropriate headers) is as good a legal document
    as any, even sans digital signature." --me

---

From: [email-masked]
Date: Thu, 06 Jan 2005 06:24:09 -0800 (PST)

> structure of tags interact badly with that algorithm.

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.

				Ned

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 06 Jan 2005 16:27:22 +0100

--On 6. januar 2005 06:24 -0800 [email-masked] wrote:

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

I lifted that stuff from RFC 2616 (HTTP/1.1), which is at Draft. The reason 
for putting it in 3066 was that people wanted to refer to it without having 
a normative dependency on HTTP.
The fact that it doesn't call itself an algorithm is probably mostly an 
effect of the writing styles of the various authors involved.

If we were splitting 3066 into a standards-track format specification and a 
BCP registration procedure, this should certainly go into the format 
specification - but I would argue that the RFC 3066 section 2.3 algorithm 
has sufficient interoperability experience and Internet-scale deployment 
that the correct status for it is Standard, not Proposed.

                   Harald