Hi -
After carefully reviewing the extensive postings on the question
of how to procede with the registry draft and the initial registry,
here is how I'd like to procede, followed by a brief rationale for
this recommendation.
Modulo the edits already agreed:
On the initial registry, I think there is rough consensus to:
1) recommend publication as an Informational RFC
2) add a note to the RFC editor at the beginning of
section 3, requesting that the rest of that section
be deleted, and replaced with a note saying where the
current registry is to be found (or a pointer to
the registry RFC, which in turn says where the registry is)
On the registry document, I do not see a clear consensus, so my own
judgment colors this proposed recommendation to the IESG:
1) recommend publication as BCP
2) obsoletes 3066. The pain with splitting out the matching
stuff is similar with what we've gone through with RFC 1213
being exploded into a zillion pieces. If it's necessary
to hold publication until the matching document is ready, I think
that's a worthwhile tradeoff to avoid any ambiguity that
would result from an "Updates 3066".
Looking ahead, I believe we are where we always were with respect
to the matching document:
1) recommending Proposed Standard when it is ready.
2) obsoletes 3066. (see above)
Brief rationale:
Several alternatives were presented, each with pros and cons.
Ultimately, I found the arguments unpersuasive that this document
could, at least in part, be considered a protocol specification.
Though the BCP designation is a bit of a catch-all, it still
appears to be the best fit, is in keeping with what we were
instructed to produce, and would result in the least disruption
when specifications that currently reference 3066 or 1766 are updated,
particularly in view of the pains the WG has taken to maintain
syntactic compatibility.
When one looks at the specifications that reference 1766 and 3066,
for example RFC 2640 or 2070, they often provide their own
ABNF or other description of language tag syntax in that protocol.
We've already decided to move matching into a separate, standards-track
document. Negotiation is clearly application protocol specific, and
is not covered by either the registry or matching drafts. Consequently,
when I look at the references to the predecessor specifications,
I'm left with a clear sense that what's being referenced is not a
protocol specification, but rather the registry description, which,in
order to describe registry operation, had to spell out some syntactic
constraints. Now I'm not claiming that I've been able to review every
reference everywhere, but I've seen enough to be reasonably confident
of a pattern. I conclude that the document is a registry document, and
that the syntax specification is for the operation of the registry,
and does not constitute a protocol specification any more than any other
formal registry specification would.
Now, I'm not going to ask whether we're all happy with this recommendation,
but is this at least something we can live with, recognizing that the IESG
will probably have its own views as well?
Randy, ltru co-chair
_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www1.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.