2012/1/1 John C Klensin <john-ietf@xxxxxxx>: > Hi. > > While I'm highly sympathetic to Thomas Roessler's position which > I interpret as this needing (as a matter of courtesy and > cooperation, if nothing else) affirmative signoff from the > relevant parties in W3C, I would settle for any clear set of > comments from them. > > But I think this also needs some examination in terms IETF > relationships and process independent of the W3C-related issues. > > It is, IMO, entirely appropriate to publish a specification as > Informational when it precisely describes some existing practice > for the information of the community. We have a long history of > doing that in what is now called the Independent and, when the > specification bears some direct relationship to other IETF work, > in the IETF stream. But this document, in the -00 version > circulated for Last Call, is not such a precise, factual, > description: it contains errors or misstatements (examples > below) and it contains extensions beyond the existing practice > that are not clearly identified and that, as far as I can tell, > have not been deployed or tested. While I see no reason why > they would not "work", experience is the proper test of whether > some particular approach or syntax is adequate. > > I believe that the IESG ought to take exceptional care with > individual submissions, precisely because they are published in > the IETF stream, requiring significant expertise or careful > reading to determine whether they actually represent informed > and competent IETF consensus. Against that test, this document > is not ready for approval and RFC publication. Specific > examples: > > (1) The second sentence of the Introduction begins "This > document specifies a new type of such relationship...". > But this is not "new": it has been around for years, as > the next paragraph (and comments on the IETF list) > indicate. It's "new" in context of being formally registered. > > (2) The last paragraph of the Introduction reads: "This > document is to formally register the 'disclosure' Link > Relation Type with IANA and provide a permanent record > on it for the Internet community. Additionally, it > expands the sphere of this relation type to allow its > use when referring to separate patent disclosures." So > it registers the type (good, IMO); makes a permanent and > public record --which the author believes W3C has failed > to do (good, IMO); documents the existing practice (also > good, IMO); and creates an untested extension (outside > the scope of Informational publication of an existing > practice, IMO). So do you propose dropping the semantics for separate disclosures and leaving the original W3C's? > > (3) There is no analysis at all of whether the compound > use of this relation identifier (within a <ul> element) > might confuse any existing implementations and, if so, > how that confusion would play itself out. For example, > we have learned the hard way in other areas that, when > multiple instances of the same information-label appear > with different values and without that being explicitly > provided for in the specification, some implementations > will use the first one and ignore the others, others > will pick the last one and ignore the others, some will > reject the construct entirely, and still others will try > to somehow combine the fields. If we know what would > happen here, the document doesn't say so. Without such > an analysis, the statement of true belief in Security > Considerations may be a little bit optimistic. > > (4) While it is not unusual for Acknowledgments sections > to be updated during or after Last Call, an entry of > <TBD> for the only contributors to the document make it > impossible for the community to verify that the BCP78 > requirements have been followed. <TBD> occurred because there were no comments received before LC; but now, I hope, this may be corrected. > > I think this document could be cleaned up and made ready for > publication by using any of the following three options: > > (i) Formally ask W3C if the document cited as "[W3C-PUBRULES]" > is an appropriate specification of this relation type or if some > other document exists or can be constructed within a reasonable > (and fixed) period of time. If so, reference it normatively, > producing an RFC only if the current state of the Link Relation > registry requires that. Forget about extensions except insofar > as they come through the process that produced this > specification. > > (ii) Prepare and publish an Informational RFC that strictly > describes the existing practice and says so. Publish a separate > document, probably as Experimental, that proposes and argues for > the extension. > > (iii) Modify this document to be _extremely_ clear about what is > existing practice and what is the author's suggestion about an > extension. For the latter, the change being made, the > justification for it, and a risk analysis should be present and > explicit. While that was me who proposed the change to semantics, I tend more and more to agree with documenting the existing practice; but let's wait a response from W3C community first to see what's their attitude towards the proposal. Mykyta Yevstifeyev > > If IETF publication as an RFC is anticipated for any of those > three options, the inconsistent language should be cleaned up; > the Acknowledgments section completed; and evidence that the > author, the shepherd, and/or the sponsoring AD were in a bit too > much of a hurry to get the document into Last Call as "<Document > Title>" in the page headers should be fixed. > > regards and happy new year to all, > john > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf