I generally agree with many of the observations about what the IETF process
should probably be.
I also observe that there is a process for individual submissions, which Mark
and I have scrupulously followed. We ask that the IETF community consider our
work on its merits, not just on its pedigree (or lack thereof). It is right to
be conservative about what becomes a BCP, but not to the point of excluding
good work, and we feel that our work is not a proprietary submission seeking to
subvert the standards process. In fact we feel that we've been very considerate
and open in the development of this draft in the language tagging community and
continue to be open to comments and criticism, no matter the source.
In this case we have developed an I-D which would like to obsolete an existing
BCP which itself obsoletes a BCP. The I-D was developed using the exact same
process, procedures, small-"c" community, and so forth that its predecessors
used. I will not argue the subjective issues of whether the community working
on this was large enough or the right one nor the procedural issue of whether
enough notice was given to others. After that work has progressed for nearly a
year and a half, though, we find ourselves in a Last Call. Certainly those
individuals and groups not involved in the cut-and-thrust of this draft's
development are entitled to an opportunity to consider and comment on our
choices, including the requirements we chose to address and the suitability and
compatibility of our solution.
Procedural questions about how this should have happened are interesting and
important to the IETF at large, but given the specific details of our draft's
development, wouldn't it be responsible to separate the two discussions and
focus on the draft at hand? I feel that the technical comments about our draft
to date have mostly been related to compatibility with specific existing
protocols or implementations. I feel that we have suitable ways to address
these concerns (either via persuasion or via modifications to the draft).
Neither Mark nor I are wild-eyed zealots or starry-eyed purists: we are willing
to make adjustments and modifications that make sense in order to achieve the
necessary consensus or revise or abandon aspects of the document that raise
valid issues.
I would like the community at large to consider this specific I-D--both the
requirements for it and the technical merits of our solution--attempt to
understand our choices and provide (objective) feedback that will allow us to
achieve consensus for or against it (or a slight revision thereof). We are
trying to work within the confines of the IETF's process to achieve what we see
as the necessary progress on this issue.
So.... what do we need to do to address (a) concerns about requirements for the
draft and (b) concerns about technical objections?
If we use the ietf-languages list to discuss the these sets of issues, then
perhaps we can demonstrate the maturity of the draft and progress to BCP.
Best Regards,
Addison
Addison P. Phillips
Director, Globalization Architecture
http://www.webMethods.com
Chair, W3C Internationalization Core Working Group
http://www.w3.org/International
Internationalization is an architecture.
It is not a feature.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf