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.
(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).
(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.
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.
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