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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf