--On Tuesday, 06 September, 2005 17:22 -0400 Sam Hartman
<hartmans-ietf@xxxxxxx> wrote:
> It is possible to do many things. I was hoping that I could
> get you to make a concrete proposal for how you see this
> document advancing if we put it on the standards track.
Sorry, I may have misunderstood. Also, to some extent, I
thought I answered this question in my initial note, but may not
have been clear enough about it. And I deliberately avoided too
much detail as possibly not appropriate to a Last Call comment.
> Personally I think your comments are valuable even if you
> don't make such a proposal,but I think they would be more
> valuable if you or someone holding the same position would
> make it very clear what it would mean for this document to be
> on the standards track. My question is not motivated by a
> lack of imagination about what that could mean but rather all
> too many options I can think of.
Well, I think that the decisions here should be made, or at
least proposed and supported, by the WG and not by one of us.
I, too, can imagine many options. Let me suggest answers to
your questions below with the understanding that the WG may have
better answers, and then comment further if that appears to be
needed.
> Here are some questions it seems like the IETF community would
> need to answer in order to implement your proposed
> categorization:
>
> 1) What happens to the existing registry with these documents
> on the standards track but not BCPs?
Same thing that happens if they are adopted as BCPs. Or not.
The current documents propose to obsolete one registry and
replace it with another. It is at least as appropriate to do
that in a standards-track document as it is with a BCP.
Alternately, what I have anticipated (and intended my notes to
suggest) is that draft-ltru-registry and draft-ltru-matching
(and maybe some other things) end up on the standards track and
be supplemented by applicability statements that identify the
contexts in which they should be used and with which options. I
would hope that the number of them would be quite small, but one
could easily imagine an "LTRU matching options for use with MIME
and HTML" and an "LTRU matching options for use with XML in i18n
contexts" that might show some differences. Or not. In the
most general of cases, such documents might reference the new
registry and old (bit-identical and handwaving) matching rules
or the old registry and new matching rules.
As Addison points out, the entries permitted by the new registry
concept are sufficiently compatible with the entries in the old
registry that the above fine distinctions would probably not be
necessary. If so, any and all applicability statements would
apply to the new registry. One could separately direct IANA to
stop accepting registrations in the old registry. And that is
the most practical and plausible definition of deprecating/
obsoleting a registry: no protocols or applicability statements
utilize it and IANA does not accept new entries into it. To
simply say "don't use that one any more, use this one", is an
appeal to authority, not a demonstration that the old one is, in
fact, obsolete and superceded.
My problem with LTRU-registry (and LTRU-matching) in this regard
is that they mix up "specify a better registry and matching
model" with "get rid of 3066". At present, it is unproven
whether, in practice, the subtag registration model of
LTRU-registry, combined with LTRU-matching, is a sufficient
replacement for all of the uses to which 3066 may be put. We
need to remember that we have no way to know whether we have an
inclusive list of all of those uses. It is much safer, in the
environment in which we find ourselves, to write an A/S
("profile" to all intents and purposes) that _replicates_ the
tagging model and matching rules of 3066, excluding all of the
new subtag types that LTRU-registry permits, but that references
the new registry and not the old one, and let _it_ replace 3066.
Then one writes one or more additional A/S documents that
specify different applicability of the new registry with
LTRU-matching and let it complement or update the
3066-compatible A/S as appropriate.
> 2) How do we advance these documents on the standards track?
My apologies, but this is going to be a bit long because I think
we have gotten into a philosophical and procedural tangle
(through no fault of the LTRU WG).
We turn the question around, perhaps taking a trip back to when
BCPs actually represented "common practices" or even before we
had BCPs. Our colleagues at, e.g., ISO and the ITU, have
sometimes gone into the business of making lists: establishing
registries of things so that numbers or codes could be assigned
to them and standardized, independent of the actual applications
to which those lists might be put. Such lists can be evaluated
on internal quality (sometimes objectively, sometimes not), but
it is usually assumed to be unfair to evaluate them on their
success in supporting particular applications and types of
applications. Ultimately, a criticism of the relationship
between the list and some application is rejected on the basis
that the relevant committee or process just assigns code points
-- interpretation of those code points with regard to any
particular real-world problem is is out of the committee's scope.
Those efforts are often extremely worthwhile and extend across
broad classes of work --efforts related to character sets,
scripts, languages, and even country code identifiers are a tiny
fraction of the whole. Even when I complain about the "we just
assign code points" attitude, I recognize its validity and
importance.
_However_, as far as I can remember, the IETF has never
intentionally gone into that business. Instead, we create
registries in support of particular protocols or sets of
protocols. The success or failure of the "foo" registry is
not evaluated on how many foos we can put in to it, or its
comprehensiveness relative to some external foo-list, but on
whether it does the job that the foo-protocol (and maybe foo1,
foo2, etc.), requires. Normally, we don't even write a "create
the baz registry" document. Instead, we write a "baz protocol
specification" document and include a more or less long section
that instructs IANA to create the registry, what to put in it,
and how. We may make those registry/IANA specifications into
separate documents for a long series of good reasons, one of
which is "useful for several protocols, including some we don't
know about", but the evaluation criteria should not change: a
success evaluation is based primarily on the success of the
protocols that use the registry and its contents and the degree
to which the registry supports interoperability among
implementations of those protocols. Of course, if someone
could demonstrate that the registration and maintenance
procedures, as specified, don't work, that would also be a bar
to advancement on the standards track, just as demonstrated
inability to exercise IPR provisions would be, but it should not
be our primary focus.
That still leaves an issue that, if we have a base registry
specification that is not linked to applications of the registry
by either inclusion in the application specification or by
strict dependency (one application, one registry), but by a
collection of A/S, just how much of the registry needs to be
used and in what way to justify advancing the specification.
That isn't exactly a new issue, nor is it exclusive to registry
specifications. My personal recommendation is that the WG
should develop a recommendation on the subject -- either as part
of the registry and matching specifications or as part of one or
more of the A/S documents -- that we Last Call those provisions,
and, assuming community support, we accept that definition and
move on. The only requirement I would, personally, apply would
be that the recommendation include demonstrated utility and
interoperability support for at least one A/S and application.
But other rules are possible and I think such requirements are
best discussed in the WG and at Last Call, not turned into
attempts at developing general rules.
> In addition, it might be advisable for the IETF community to
> consider the question of what happens if we find this is not
> the right approach; that question is not required to implement
> your proposed reclassification but it seems advisable to
> consider.
I agree. See "footnote" below. But I suggest that it has
already been demonstrated that handling complex non-protocol
documents that have protocol (on the wire) implications by
identifying them as BCPs, even if there is no operational
experience with either the documents or any associated
protocols, is broken and causes other problems. So I think
that, like it or not, we have sort of a zero-base problem here:
my approach may or may not be the optimal one. But the status
quo has already proven inadequate so the alternative is "third
proposal" not "keep doing what we have been doing". Also, we do
have experience with the approach I'm suggesting with less
extensive registries: it occurs every time a registry is created
by an "IANA Considerations" section in a standards-track
document. Unlike the BCP approach, we have some
running-code-like evidence that approach works, at least in
those contexts.
> Let me throw something out to answer the questions I posed.
> We could keep the existing 3066 registry as the BCP registry
> and create a new registry for these documents. We could
> advance these documents when any single using protocol
> advances. Presumably that would mean that these documents
> could not advance until some protocol that normatively
> references them advances; that's probably OK. Clearly these
> are not the only answers to the questions I posed--I'm not
> even sure if they are good answers. They are presented only
> to illustrate that it is possible to answer the questions
> without huge effort. That in turn suggests to me at least
> that I'm not establishing an unreasonable requirement by
> asking the questions be answered.
Yes. And although I deliberately did not address this more
specific possible answer in writing the text above, you will
note that my strawman suggestion, including the suggested
requirement for at least one application to demonstrate
usability and functionality, and yours are consistent and
compatible.
best,
john
Footnote: those who are reading this and also following newtrk
should probably think about one of the implications of where I,
and possibly Sam, are headed. If we are going to stay with a
multiple-stage standards process, it might be useful to modify
the "advancement" rules in 2026 to provide that a document being
considered for Proposed Standard (or any other given maturity
level) may optionally include an explicit "conditions for
advancement" section. That section could be evaluated by the
community on Last Call (and earlier) to replace the more general
conditions (and handwaving) in 2026 for that particular document
or collection of documents. If approved, it wouldn't quite be
binding on the community in terms of advancement of the document
if those conditions were met: the advancement request would
still need an IETF Last Call and "experience shows that we got
those criteria wrong" could be an argument against automatic
acceptance/ advancement. But it would give us a much better way
to deal with peculiar and edge cases than saying "whoops, don't
see how the make the 2026 standards track rules apply exactly,
so let's make this a BCP". And it would mesh nicely with some
of the ideas Larry and others seem to be proposing about
implementation reports.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf