Subject: Re: Last Call: <draft-yevstifeyev-disclosure-relation-00.txt> (The 'disclosure' Link Relation Type) to Informational RFC

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 1 Jan 2012 10:25:42 +0200

Julian, all,

When I came to fixing the examples section per received comments, I
first began to refine the example on references to separate
disclosures, and what I got was:

   <html>
     ...
     Please visit
     <a rel="disclosure" href="http://example.org/ipr/meta-spec/">
     the IPR page</a> for the list of patent disclosures made with
     respect to this specification.
     ...
   </html>

(unchanged fragment of list) and, later,

    <a rel="disclosure"
     href="https://datatracker.ietf.org/ipr/1097/">IPR Disclosure
    #1097</a>

(this was fixed to suit real situation with RFC 5925).  And, after a
closer look, I realized that the separate-patent-disclosure semantics
and a list-thereof one are completely different.  That is a simple and
compelling reason, I think, to distinguish the semantics.

And that's why we have 'item' and 'collection' relations (now in LC)
defined as pair (actually, what my document defines may be considered
to be a special case of these in some way).

The only thing is that such proposed definition is different from the
current W3C's use of 'disclosure' relation, which is used as my
proposed 'disclosure-list', but once we have defined both, W3C will
migrate to a new, correct one (I hope).

All the best, and happy New Year,
Mykyta Yevstifeyev

2011/12/29 Julian Reschke <[email-masked]>:
> On 2011-12-27 07:52, Mykyta Yevstifeyev wrote:
>>
>> Hello,
>>
>> I'd like to seek consensus on separating the semantics of link
>> relation for separate disclosure and a list thereof, correspondingly
>> defining two link relations - 'disclosure' and 'disclosure-list'.  You
>> may see my edits made to Section 2 of the doc. below, which I'm
>> proposing:
>>
>> 2. 'disclosure' Link Relation Type
>>
>>    Whenever the 'disclosure' relation is defined, the target IRI
>>    [RFC5988] MUST refer to a particular patent disclosure made with
>>    respect to the material being referenced by context IRI.
>>
>> 3. 'disclosure-list' Link Relation Type
>>
>>    Whenever the 'disclosure' relation is defined, the target IRI MUST
>>    designate a list of patent disclosures made with respect to the
>>    material being referenced by context IRI.
>>
>> As the doc. is in Last Call now, in order not to initiate a new one,
>> please comment on these changes before January 6, so that I could know
>> which version I should submit for IESG evaluation.
>> ...
>
>
> I don't see a compelling reason to distinguish both.
>
> Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 01 Jan 2012 14:57:07 +0100

> All the best, and happy New Year,

Not convinced. I thought the purpose was to document an existing use? 
Now you're adding another one (post-LC), and it's (as far as I can tell) 
totally unclear what the W3C's take on this is. (they introduced the 
link relation, after all)

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 1 Jan 2012 16:04:01 +0200

Julian,

I'd be glad to describe current use, but as long as we want to
introduce a possibility to reference separate disclosures, we cannot
fit two separate semantic models in one relation type.  And the naming
'disclosure' suits separate instances of disclosures rather than a
list.  And, should there be no objections, the document may be
processed with the change without 2nd LC.

Mykyta Yevstifeyev

2012/1/1 Julian Reschke <[email-masked]>:
> Not convinced. I thought the purpose was to document an existing use? Now
> you're adding another one (post-LC), and it's (as far as I can tell) totally
> unclear what the W3C's take on this is. (they introduced the link relation,
> after all)
>
> Best regards, Julian

---

From: Thomas Roessler <[email-masked]>
Date: Sun, 1 Jan 2012 15:21:36 +0100

Mykyta,

thank you for working on this draft. Before you try to get a specification through Last Call that's possibly at odds with the current (and as far as I know original) use of the link relationship, it would perhaps be useful to talk to the current users of this particular link relationship, and request their review of the specification, and find out their views on the proposed change to its semantics.

A good place to reach many of the interested parties would be the [email-masked] mailing list.

Also, I'd recommend that you contact Ian Jacobs, W3C's head of communications; he's in charge of the detailed publication requirements for W3C specifications.

Before these steps have happened, it would appear premature to me to request publication of this document as an RFC.

Regards,
--
Thomas Roessler, W3C  <[email-masked]>  (@roessler)

On 2012-01-01, at 15:04 +0100, Mykyta Yevstifeyev wrote:

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 01 Jan 2012 15:51:01 +0100

* Thomas Roessler wrote:
>thank you for working on this draft. Before you try to get a
>specification through Last Call that's possibly at odds with the current
>(and as far as I know original) use of the link relationship, it would
>perhaps be useful to talk to the current users of this particular link
>relationship, and request their review of the specification, and find
>out their views on the proposed change to its semantics.
>
>Also, I'd recommend that you contact Ian Jacobs, W3C's head of
>communications; he's in charge of the detailed publication requirements
>for W3C specifications.
>
>Before these steps have happened, it would appear premature to me to
>request publication of this document as an RFC.

If Ian Jacobs is responsible for the things discussed on spec-prod, I'd
think he reads that mailing list, and the mailing list has been aware
of the draft since the first version has been published in October 2011,
<http://lists.w3.org/Archives/Public/spec-prod/2011OctDec/0008.html>.

What might be useful is to ask W3C's IETF Liaison what W3C's policy is
with respect to registration of link relations W3C makes up and uses on
its web site. The Internet Community shouldn't really have to clean up
after the W3C to ensure proper registration of link relations W3C uses.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Thomas Roessler <[email-masked]>
Date: Sun, 1 Jan 2012 16:04:50 +0100

On 2012-01-01, at 15:51 +0100, Bjoern Hoehrmann wrote:

> If Ian Jacobs is responsible for the things discussed on spec-prod, I'd think he reads that mailing list,  and the mailing list has been aware of the draft since the first version has been published in October 2011,

Neither the intention to last call the draft, nor the proposed incompatible change were announced to that list.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 01 Jan 2012 17:13:33 +0100

>Neither the intention to last call the draft, nor the proposed
>incompatible change were announced to that list.

So what is the point of order you are trying to raise? Registering the
link relation pretty much requires publication of the draft as RFC, so
the intent should be implicit, and given the length of the draft, and
my review comments, the timing should be rather clear to anyone who
cared aswell, so I don't see how the request for publication was prema-
ture.

If you only want to make sure interested parties are aware of the state
of the discussion around the document, you can just tell them, like I
did when I copied my review comments to spec-prod, or point this thread
out to W3C's IETF Liaison so they can spread the word for you.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Thomas Roessler <[email-masked]>
Date: Sun, 1 Jan 2012 18:06:20 +0100

Bjoern,

I'm not interested in a game of process nomics.

rel=disclosure has been in actual and continuous use in highly stable documents for almost 10 years now; a very quick search turns up early usage in late 2002.  As far as I can tell, it starts to show up as a "suggestion" in the W3C publication rules some time between April and September 2002. 

That predates the Web Linking spec (and its creation of the current relationship value registry) by about 8 years.

The draft before the IETF now started out as inspired by and documenting the existing usage.  That is a very welcome and useful thing to do.

The proposal is now — in last call — changing into "hey, let's actually redefine the usage of that link relationship, W3C will just follow."  I think that that is an unwise step unless you actually have buy-in from those who build the current W3C tool-chain, and from those who maintain the current set of documents.  The very least I'd expect is that those who propose the change make an effort to get in touch with the current users of the link relationship.  Posting an idea to [email-masked] is not a good way to do so.

Further, I think that it will be pretty unlikely that we'll make changes to Recommendations and other publications going back over 10 years to accommodate the proposed new usage.

Speaking personally, -1 to the proposed change of semantics.

Speaking as liaison, I've already pointed you at the appropriate people to ask for review.  This being an individual, informational draft, I think it's fair to expect the submitter to go and secure the appropriate review.

Regards,

---

From: John C Klensin <[email-masked]>
Date: Sun, 01 Jan 2012 12:11:03 -0500

FWIW, I strongly support Thomas's position.  This should either
be a narrow description of existing practice or should not be
approved by the IETF without review and buy-in from the
communities who actually use and support this mechanism.
   
    john

--On Sunday, January 01, 2012 18:06 +0100 Thomas Roessler
<[email-masked]> wrote:

> rel=disclosure has been in actual and continuous use in highly
> stable documents for almost 10 years now; a very quick search
> turns up early usage in late 2002.  As far as I can tell, it
> starts to show up as a "suggestion" in the W3C publication
> rules some time between April and September 2002. 
> 
> That predates the Web Linking spec (and its creation of the
> current relationship value registry) by about 8 years.
> 
> The draft before the IETF now started out as inspired by and
> documenting the existing usage.  That is a very welcome and
> useful thing to do.
> 
> The proposal is now — in last call — changing into "hey,
> let's actually redefine the usage of that link relationship,
> W3C will just follow."  I think that that is an unwise step
> unless you actually have buy-in from those who build the
> current W3C tool-chain, and from those who maintain the
> current set of documents.  The very least I'd expect is that
> those who propose the change make an effort to get in touch
> with the current users of the link relationship.  Posting an
> idea to [email-masked] is not a good way to do so.
> 
> Further, I think that it will be pretty unlikely that we'll
> make changes to Recommendations and other publications going
> back over 10 years to accommodate the proposed new usage.
> 
> Speaking as liaison, I've already pointed you at the
> appropriate people to ask for review.  This being an
> individual, informational draft, I think it's fair to expect
> the submitter to go and secure the appropriate review.
> 
> Regards,
> --
>>>>> Before these steps have happened, it would appear
>>>>> premature to me to request publication of this document as
>>>>> an RFC.
>> 
>>> Neither the intention to last call the draft, nor the
>>> proposed incompatible change were announced to that list.
>> 
>> So what is the point of order you are trying to raise?
>> Registering the link relation pretty much requires
>> publication of the draft as RFC, so the intent should be
>> implicit, and given the length of the draft, and my review
>> comments, the timing should be rather clear to anyone who
>> cared aswell, so I don't see how the request for publication
>> was prema- ture.
>> 
>> If you only want to make sure interested parties are aware of
>> the state of the discussion around the document, you can just
>> tell them, like I did when I copied my review comments to
>> spec-prod, or point this thread out to W3C's IETF Liaison so
>> they can spread the word for you. -- 
>> Björn Höhrmann · mailto:[email-masked] ·
>> http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon:
>> +49(0)160/4415681 · http://www.bjoernsworld.de 25899
>> Dagebüll · PGP Pub. KeyID: 0xA4357E78 ·
>> http://www.websitedev.de/ 
>> 
>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 01 Jan 2012 19:13:24 +0100

>I'm not interested in a game of process nomics.

If you are not interested in discussing whether it was "premature ... to
request publication of this document as an RFC" then don't suggest that
it was? The IETF is currently discussing proper procedures for this kind
of third-party registration in various places like "happiana", you will
excuse that some of us are interested in finding suitable guidelines.

>Speaking as liaison, I've already pointed you at the appropriate people
>to ask for review.  This being an individual, informational draft, I
>think it's fair to expect the submitter to go and secure the appropriate
>review.

I think it's fair to expect you to keep people in the W3C apprised about
developments in the IETF relevant to their work, and I think it's fair
to dismiss your opinion in this matter given that you don't want to dis-
cuss it. Mykyta Yevstifeyev made a draft, interested parties were made
aware of the draft, and after some weeks with no comments from them, as
far as I am aware, Mykyta Yevstifeyev asked for publication of the draft
as RFC. I don't think there is anything wrong with that. If you disagree
perhaps you can find someone to argue your point on the "happiana" list
so we can give better guidance to our fellow community members.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Sun, 01 Jan 2012 19:28:47 +0100

> so we can give better guidance to our fellow community members.

Björn,

I'm almost with you.

However, changing the actual definition and adding an additional post LC 
would be kind of surprising, wouldn't it?

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 01 Jan 2012 19:31:07 +0100

>which version I should submit for IESG evaluation.

I do not think you should (be able to) make such a change without a new
Last Call, and I disagree with the separation. Reasons include that it's
unclear which relation you use if you have one disclosure where many
patents are disclosed; would that be "disclosure" because it's just one
disclosure, or would it be a "disclosure-list" because many patents are
disclosed? On the German Wikipedia people are even used to flamewars
concerning List articles that have no or just one item, where some ar-
gue that you need at least two items to have a list. In this sense you
could probably always use 'disclosure-list' in place of 'disclosure' if
you think empty and single item lists are meaningful concepts.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 01 Jan 2012 19:55:08 +0100

>would be kind of surprising, wouldn't it?

Among the goals of the Internet Standards Process are "openness" and
"fairness" and I would find these principles grossly violated if the
IESG would approve the document for publication with the proposed
changes applied but without another Last Call. With another Last Call
and if there is rough consensus in favour of the changes, and that'd
include running code, then that's fine with me, regardless of whether
an intention to publish an Internet-Draft as RFC is communicated to
some obscure W3C mailing list, or who communicates such an intention.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: John C Klensin <[email-masked]>
Date: Sun, 01 Jan 2012 14:22:07 -0500

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

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 2 Jan 2012 09:19:53 +0200

Thanks to everybody for discussion.

I've sent a note to spec-prod list, which you may find at
http://lists.w3.org/Archives/Public/spec-prod/2012JanMar/0000.html,
and I'll notify you of the responses that I expect to receive before
Thursday.

Mykyta Yevstifeyev

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 2 Jan 2012 09:27:31 +0200

2012/1/1 Bjoern Hoehrmann <[email-masked]>:
> disclosed?

'disclosure', because the semantics concern the patent disclosure, not
the patent.

> On the German Wikipedia people are even used to flamewars

A list should be considered to be a list even if it is empty or has
one entry, so we can use 'disclosure-list' here.

Mykyta Yevstifeyev

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 2 Jan 2012 09:36:51 +0200

>        the next paragraph (and comments on the IETF list)

It's "new" in context of being formally registered.

>        the scope of Informational publication of an existing

So do you propose dropping the semantics for separate disclosures and
leaving the original W3C's?

>        requirements have been followed.

<TBD> occurred because there were no comments received before LC; but
now, I hope, this may be corrected.

> justification for it, and a risk analysis should be present and

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

---

From: John C Klensin <[email-masked]>
Date: Sun, 01 Jan 2012 18:13:27 -0500

--On Sunday, January 01, 2012 19:55 +0100 Bjoern Hoehrmann
<[email-masked]> wrote:

> Among the goals of the Internet Standards Process are
> "openness" and "fairness" and I would find these principles
> grossly violated if the IESG would approve the document for
> publication with the proposed changes applied but without
> another Last Call. With another Last Call and if there is
> rough consensus in favour of the changes, and that'd include
> running code, then that's fine with me, regardless of whether
> an intention to publish an Internet-Draft as RFC is
> communicated to some obscure W3C mailing list, or who
> communicates such an intention.

Björn,

For better or worse, the IETF tries to maintain close working
relationships with a number of other SDOs.   While there are
exceptions, those relationships work best when we are willing to
go out of our way to be sure that everyone stays informed and,
in particular, that we don't appropriate their standards or
conventions and start making changes to them... and when they
reciprocate.    

While different ADs handle it differently, we have also
traditionally made the assumption that authors requesting
individual submission publication have to take most of the
responsibility for making sure all of the ducks are lined up.
They cannot, for example, rely on a WG to do that (since there
isn't one) nor on IETF Last Call to spot everything that they,
who are presumably expert enough to have constructed the
document in the first place, should have spotted.

That said, I basically agree with what you have written above,
tempered by the understanding that I think it is in the IETF's
best interest (as well as just plain polite) to go to W3C and
say, repeatedly if necessary, "do you really, really, not have
anything to say about this?"  We certainly expect the same from
other SDOs we work with and W3C has give us that courtesy on
some occasions when we have been slow to respond.

    john

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 03 Jan 2012 15:19:07 -0700

<hat type='AD'/>

Mykyta,

You have not yet submitted a revised I-D. Currently the document under
consideration is draft-yevstifeyev-disclosure-relation-00. If you want
to make fundamental changes to the spec, please do so by submitting a
revised I-D.

In the meantime, I have deferred the document to the January 19 telechat
while you decide how you want to proceed.

If you decide that you want to define two link relations instead of one,
you will need to submit a revised I-D, which will need to undergo
another review on the [email-masked] list and then another IETF
Last Call.

There is no need to waste IESG and general IETF attention on this
specification if the author can't make up his mind about his own intentions.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: John C Klensin <[email-masked]>
Date: Tue, 03 Jan 2012 21:21:41 -0500

--On Monday, January 02, 2012 09:36 +0200 Mykyta Yevstifeyev
<[email-masked]> wrote:

>> individual submissions, precisely because they are published
>> in the IETF stream, requiring significant expertise or careful
>> 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.
> 

Then say that it specifies a registration for something that has
been around for a while, not that it is "new".

>>        (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    
>>        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?

I propose that you figure out what you want to do, that you be
very explicit about what (if anything) is new and what is
existing practice, and that you get out a new I-D that says
whatever you intend.   If you are asking me the substantive
question, I think that, if you are going to propose an
extension, you are obligated to be very clear what the extension
is and to do a careful review of what issues might arise with
it.  I'm not sure I have an opinion about whether the extension
is a good idea -- I need that information to figure it out and I
think it is your obligation to supply it.

I think what I'm saying here is consistent in general
principles, if not in detail, with Peter's recent note -- making
what you are proposing clear is your responsibility.  Please
don't ask the community to spend time on review until you have a
very specific and clear proposal with which you are satisfied.

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

Then get a new I-D posted (see Peter's note).

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

Documenting the existing spec would work for me (but so would
doing so and adding a well-vetted and well-documented
extension).  I do suggest that you not "wait" for a response
from W3C but that you try to actively engage with them, seeking
help from Thomas, Julian, Mark, or others as appropriate.

best,
    john