Find a better name for the specification

[jandrieu]

The "controller" document is a bit of a challenge to understand.

We should consider other names that better describe what it actually does.

[selfissued]

Yes, it's an opaque name but it's a name that's been in use. Unless a clearly better name is found, I think we are where we are.

[iherman]

The issue was discussed in a meeting on 2024-09-27

• no resolutions were taken

View the transcript

#### 3.9. Find another name (issue controller-document#100) _See github issue [controller-document#100](https://github.com/w3c/controller-document/issues/100)._ **Brent Zundel:** I will queue up the conversation, we are stopping at 12:30, folks can continue to talk about it over lunch. … this conversation is strictly time boxed to 6 minutes. **Joe Andrieu:** just want to say that a lot of my confusions around what a DID document has or should have was clarified when I understood how verification methods and relationships worked, so why not verification document. **Manu Sporny:** that's a good candidate. We are potentially going to add services into this, modulo concerns, if we do that it is about engaging with an entity, so an option is an "engagement document", verification methods and services. I am not saying we do this, but someone could use this for expressing their social media accounts, things like that. "How to get in touch with and authenticate an entity". **Gabe Cohen:** would make sense to call it an "identifier document". All these docs have identifiers, seems like an obvious name. **Brent Zundel:** I added myself to talk a bit about the services thing. Controller document as we conceived of it came from ??? specs which were taken from the DID specs, there was a question around "where are our services", the assumption during the DID call was that there was a common document, after thinking about it I think that services should not be pulled up into controller document. **Ivan Herman:** two things, what you just said, from a general POV, is the same as what I was saying in my comment on a technical POV, and I don't want to go into the details now but would also favor not to have the services. The other point is that, for you guys certain crypto things are natural, that is not true for outsiders. For me, the fact that you have a document that can combine crypto information with identifiers is a central element that an outsider understands. The crypto element is central to the whole thing, and I would like that to be reflected in the title. **Pierre-Antoine Champin:** I don't like "engagement document", maybe "entity document"? > *Wesley Smith:* [general laughing]. > *Ted Thibodeau Jr.:* "cryptomogriphication document". > *Brian McManus:* With that we're done (Joe gets the last word) =).

[msporny]

What about "interaction documents" -- they contain ways in which one can interact with an entity that is identified by the identifier in the id field?

Here's how we'd change the abstract with the new name:

An interaction document provides information that enables a software system to engage with an entity identified in the document. An interaction document contains data to aid in the interaction such as public cryptographic keys that can be used for secured communication and services that can be used to interact with software acting on behalf of the entity identified in the interaction document.

It's not perfect, but is it better than "controller document"?

[iherman]

It's not perfect, but is it better than "controller document"?

I agree with both statements :-)

But... what is the usage of that document without public crypto keys? I have the impression that most of the properties are related to "verification", the data types that we define are related to keys, etc. So the "such as" in the description seems to underplay the role of crypto for my taste.

I believe the presence of crypto keys are an essential feature of the document, and this should be reflected in the name...

[msporny]

I believe the presence of crypto keys are an essential feature of the document, and this should be reflected in the name.

It's an essential feature today, but it's not absolutely necessary for some use cases. I know this is going a bit far afield into the Social Web space, but that is one of the driving "next generation" use cases for DID Documents.

But... what is the usage of that document without public crypto keys?

You can list services, such as ActivityPub inbox, pseudonymous email address, DID Comm endpoint, or other URLs that the entity identified by the id property has listed as ways of interacting with them. For example, if I just want to drop a message to you, I could HTTP POST to one of those endpoints, authenticating myself in the process (if necessary).

[TallTed]

But... what is the usage of that document without public crypto keys?

A direct-dial phone number might be another useful and reasonable inclusion. Possibly through a location-blurring reflector like Google Voice. No crypto keys required, unless you're on some kind of secure line, which case you're probably not using GV but you might be using a No Such Agency reflector.

[decentralgabe]

I continue to like Identifier Document.

Since the main impetus (I think) was to move from just a DID Document to other types of identifier-based documents, cutting off decentralized is a simple and consistent change.

[filip26]

I'm sorry, I could not resist adding another proposal identity manifest even though I'm quite cool with controller documents :)

[iherman]

The issue was discussed in a meeting on 2024-10-09

• no resolutions were taken

View the transcript

#### 3.4. Find a better name for the specification (issue controller-document#100) _See github issue [controller-document#100](https://github.com/w3c/controller-document/issues/100)._ **Manu Sporny:** lastly, we need to be more specific about throwing an error if people try to claim keys that are not theirs. We will raise PRs over the next week or two to get that done. That's it for the TAG review. During W3C we raised an issue to rename the specification, so that is issue 100, this is very much a bikeshedding discussion, everyone has an opinion. One thing that kind of at least came to me and I suggested it in the issue is, we have been using controller document historically because the controller field can point to the document. It's about control over public keys and control over services, but one other name we could consider is that this is also about "interacting" with an identifier or an entity identified by an identifier. There is still disagreement about which we are doing, but it's about understanding how to interact with those things, whether in a decentralized way through crypto or through services like engaging with an email address. … One suggestion is to use the word "interaction document", it is definitely not perfect, but the question is whether it is better than "controller document". **Brent Zundel:** My intended procedure for this issue is, unless a proposal is made for a new name that everyone really likes, then we are not going to change it. If we cannot find something that is a clear winner among participants, we are going to stick with what we have. > *Dave Longley:* +1 to brent, not worth changing without a "big winner". **Brent Zundel:** It's unlikely that we will spend much group time on what a new name ought to be, if you have preferences and would like to make them known please engage on the issue. We can take a few minutes now if folks really want to voice their opinions, but without a clear winner we will make no change. **Manu Sporny:** can we take a quiet poll on what people would prefer between "controller document" and "interaction document"? > *Michael Jones:* Controller Document. > *Manu Sporny:* Interaction Document. > *Kevin Dean:* interaction document. > *Joe Andrieu:* verification document. > *Gabe Cohen:* identifier document. > *Phillip Long:* identifier document. > *Dave Longley:* controller document (despite its imperfections... because the others don't sway me enough to change it). **Brent Zundel:** not seeing clear consensus on this issue, the conversation is welcome to continue in the issue, however when everything else has been addressed to move to CR we will proceed forward with "controller document" if consensus not reached.

[jandrieu]

Seems like "identifier document" was the only new name to get more than one vote in the call.

After sitting on it, I would support that.

'Identifier Manifest' is also not bad, although I'm not a fan of 'identity manifest' given the challenges defining 'identity'.

[iherman]

I look at Example 2 in the DI document for the value of proof, and it is not clear how the term identifier document (or controller document for that matter) would characterize what is there. The properties used in proof constitute a set of data on the proof, which "identified" by a… blank node. Is that ok for an 'identifier document'? Not sure.

I am the culprit in this issue insofar as I raised the question at the F2F meeting in Anaheim. And I have to acknowledge that there is no name coming to the fore that would reflect a consensus of everyone around; so we may want to accept failure. 😞

[iherman]

As for 'document' vs. 'manifest': I would be fine with 'manifest' but, alas!, that term is tainted by the introduction of the Web Manifest Standard at W3C. If we used that term, we would be flooded by questions like "What is the difference with Web manifest?", "Can't you reuse the Web manifest", etc. (Saying this as a co-editor of a standard entitled "Publication Manifest".) I do not think we want to go there.

[filip26]

@iherman Do you mean W3C Web Application Manifest ? If yes, actually, thinking about it more, a clash leading to a discussion on how a Web Application Manifest is related to what is now called Controller Documents could be quite interesting and useful to clarify things. However, this is not the goal of this spec. 

Web Application Manifest Abstract

This specification defines a JSON-based file format that provides developers with a centralized place to put metadata associated with a web application. ...

Controller Documents Abstract

A controller document is a set of data that specifies one or more relationships between a controller and a set of data, such as a set of public cryptographic keys.

How would the abstract look like for a new name? Would it change, become more concrete, vague, etc?

-- A side note: there are more perspectives than just factual correctness, e.g. marketing, PR, a subjective perception, "coolness" :slightly_smiling_face:   ... 

[msporny]

@decentralgabe wrote:

I continue to like Identifier Document.

I'm starting to come around to this as well, I don't love it, but it feels more descriptive than Controller Document. The part of it that I don't like is "Document" and wonder if "Description" might be better?

"Identifier Descriptions v1.0" or "Identifier Description Documents v1.0"?

The document certainly contains a description of an identifier. I do get the parallel to "Decentralized Identifier Document", and for that reason wouldn't -1 "Identifier Documents v1.0"

Another possibility is "Cryptographic Identifiers v1.0"? Decentralized Identifiers are a type of Cryptographic Identifier?

[iherman]

@iherman Do you mean W3C Web Application Manifest ?

My apologies, I was not precise. Yes, that is the one I referred to.

If yes, actually, thinking about it more, a clash leading to a discussion on how a Web Application Manifest is related to what is now called Controller Documents could be quite interesting and useful to clarify things.

That discussion would easily become a time and energy sink. Issues that would become the subject of discussions are JSON-LD vs. "basic" JSON (knowing that there are experts in the WAM area that are fiercely opposed to -LD); is this document for Web Applications?; Is a VC part of a Web Application? etc.

I personally would like to avoid going there. It would derail the timeline along this document, which would drag down all VC specs.

-- A side note: there are more perspectives than just factual correctness, e.g. marketing, PR, a subjective perception, "coolness" 🙂   ...

+1

[iherman]

Another possibility is "Cryptographic Identifiers v1.0"? Decentralized Identifiers are a type of Cryptographic Identifier?

I always emphasized my feeling that a reference to crypto should be part of the name, so that sounds better to my ears.

That being said, my comments on the example in https://github.com/w3c/controller-document/issues/100#issuecomment-2408945838 still holds. However, my comment may fall under the remark of @filip26:

A side note: there are more perspectives than just factual correctness, e.g. marketing, PR, a subjective perception, "coolness" 🙂 ...

as an issue of "correctness"…

[dlongley]

The new (and significantly improved) introduction to the spec offered in PR #102 adds support that "controller document" isn't necessarily that bad of a name:

A [=controller document=] contains cryptographic material and service endpoints for the purposes of verifying proofs from, and interacting with, the [=controller=] of an identifier.

Each of the other names offered thus far have pros and cons -- and given that none of them, IMO, is overwhelmingly "better", I think we should stay the course with "controller document" and save the effort involved in changing the name and then defending it again from future changes.

EDIT: If we really are hard set on changing the name, I think this is a good combination of what I've heard here:

"Identifier Controller Document"

[iherman]

For the records, see also @David-Chadwick 's comment https://github.com/w3c/controller-document/pull/102#issuecomment-2410572163

[filip26]

For the records, see also @David-Chadwick 's comment #102 (comment)

I like having crypto in the name, unfortunately CID collides with Content IDentifiers - e.g. Bluesky uses CIDs in production alongside with DID documents.

https://github.com/multiformats/cid

[decentralgabe]

+1 to Cryptographic Identifiers

[David-Chadwick]

Cryptographic Identifiers would also work in the opening sentence, viz:

A Cryptographic Identifiers (CI) document contains cryptographic material and service endpoints for the purposes of verifying proofs from, and interacting with, the controller of an identifier."

Is the abbreviation CI acceptable?

[dlongley]

The name "Cryptographic Identifiers" still seems suboptimal to me -- as the identifiers aren't cryptographic and one of these documents may even contain no cryptographic material (e.g., services only).

[decentralgabe]

@dlongley you're correct, but why should that be allowed (I know why historically)? I can put a service in a document today, I don't need a spec for it. The introduction of cryptographic material is what makes these documents meaningful.

[dlongley]

@decentralgabe,

Another case is a document with a verification method that doesn't use cryptography (or may not express it publicly).

I disagree that the only value (or primary value) is in expressing cryptographic material. From my perspective, the value is in having a standard way to express information for verifying proofs created by the controller of an identifier and in finding ways to interact with the controller of an identifier. This, to me, puts an emphasis on the identifier and its controller, not elsewhere.

[filip26]

What about Controllable Identifiers ? i.e. identifiers that are under control via crypto, services, etc.

[decentralgabe]

I disagree that the only value (or primary value) is in expressing cryptographic material. From my perspective, the value is in having a standard way to express information for verifying proofs created by the controller of an identifier and in finding ways to interact with the controller of an identifier. This, to me, puts an emphasis on the identifier and its controller, not elsewhere.

We agree here—I missed some nuance. Verifying proofs requires cryptographic material. No matter what, interacting with a controller document requires some cryptographic material (I believe it should, anyway). Identification, control, and verifiability is the crux of the issue.

[iherman]

The issue was discussed in a meeting on 2024-10-16

• no resolutions were taken

View the transcript

#### 4.4. Find a better name for the specification (issue controller-document#100) _See github issue [controller-document#100](https://github.com/w3c/controller-document/issues/100)._ **Manu Sporny:** need to find a better name for the specification. We could run a rank poll on various naming options. … this usually provides good results. > *David Chadwick:* +1 to a poll for a better name. **Ivan Herman:** group can decide what sort of poll to use. **Manu Sporny:** there is a web site that does poll rankings for you. … this shows what the ranking is, and the group can then decide to accept this or not. **Gabe Cohen:** I will follow up with Brent after this call to create the poll. **Manu Sporny:** please make sure you have included all the name choices.

[msporny]

I'm going to run a Ranked Choice Vote poll for picking a name after the call today. The options will include (am I missing any?):

• Controller Documents
• Identifier Documents
• Identifier Controller Documents
• Cryptographic Identifiers (shortened to "crid" in discussions to avoid conflicting w/ IPFS "cid")
• Cryptographic Identifier Documents
• Controllable Identifiers
• Controllable Identifier Documents
• Identity Manifests
• Identifier Manifests
• Interaction Documents
• Verification Documents
• Cryptographic Information Documents

Are there other options that should be considered?

NOTE: I've updated the list based on comments below (up to https://github.com/w3c/controller-document/issues/100#issuecomment-2432735899)

[jandrieu]

Verification Documents

[TallTed]

• Cryptographic Identifiers (shortened to "crid" in discussions to avoid conflicting w/ IPFS "cid")

I'm so tempted to push for "cryptid" as the abbreviation because "a cryptid is an animal that is claimed to exist but has never been proven to do so". But I'll satisfy myself with voicing my temptation.

[David-Chadwick]

Please add Documents after the last entry, Cryptographic Information

[TallTed]

@msporny — @David-Chadwick requested addition of Documents to the last (i.e., make it Cryptographic Information Documents), and I think similar should probably apply to Controllable Identifiers ... and I think both Cryptographic Identifiers and Controllable Identifiers should be singular when followed by Documents (i.e., Cryptographic Identifier Documents and Controllable Identifier Documents).

[msporny]

The poll to gather WG preferences is now open here and will be open until our next WG call, at which point it will be closed.

https://opavote.com/en/vote/5169939384631296

[steatcal]

I see it's too late, but wanted to add a viewpoint form a less involved person's perspective and submit:

Identifier's Authentic Metadata Graph.

To shift the focus to the purpose of the Controller Document. In my view, I most value the properties that allow an RP/verifier to establish confidence about the authenticity of a claim to the identifier --over time-- and an asserted way to initiate communication with the claimant. It forms the basis by which an RP/verifier can establish confidence about the authenticity of the claimant in online interactions or authenticity and temper-evidence in data the claimant choses to originate (VC and beyond).

[msporny]

@steatcal wrote:

I see it's too late

It's not too late, we can always provide this other choice as a: "Here's all the data we have, and X seems to be in the lead... Stephan provided another option after the poll started, is there stronger support for that choice vs. the ones we have data for?" <-- that's typically what we do when we make the final decision (2 weeks from now).

[TallTed]

open until our next WG call

@msporny — Could you put an actual closing date on this, optimally also on the poll page? (and change the text quoted above to reference the VCWG, which I think is the WG controlling (cough) this document, maybe with a link to the WG calendar or even the specific meeting event?

[msporny]

Closing date is next Wednesday after the VCWG call.

I can't put it on the polling page w/o closing the poll (they don't want you to change instructions/dates/etc. mid-way through the poll, IIRC).

[TallTed]

So, 2024-11-13T12:00:00-0500

[iherman]

The issue was discussed in a meeting on 2024-11-13

• no resolutions were taken

View the transcript

#### 4.2. Find a better name for the specification (issue controller-document#100) _See github issue [controller-document#100](https://github.com/w3c/controller-document/issues/100)._ **Manu Sporny:** we ran a poll to rename the controller document. … we got good turn out. … I wish I could share my screen... … what we got as a result was fairly clear preference. … 129 for Identifier Document. … 113 for Controller Document. … 96 for Cryptographic Identifier Document. … and more beyond. … I'll collect the results and announce them later. … this was ranked choice voting. … mainly to show a preference in the group. … so, that's the data. … we said we'd run the poll and use that as input to a proposal. … brent it's up to you if you want to make the proposal now or later. **Brent Zundel:** with chair hat on, I don't think 129 vs. 113 is a strong preference...seems like a slight preference. … we can make a proposal, but if we were to do a poll on those two options what would emerge. **David Chadwick:** looking at those numbers and you take 129 and 96 together, there may be evidence of a preference for Identifier being in the name. > *Manu Sporny:* We also had someone suggest Identifier's Authentic Metadata Graph. **Brent Zundel:** not sure that's the right interpretation. **Ivan Herman:** I agree with brent...as the one who brought this up to begin with... … let's close this without any action. … because we didn't find a clear preference. **Joe Andrieu:** I sadly need to disagree. … we're not going to get more information by running another poll. … this is the conversation where we'll have the opportunity to discuss this. … and I think given we didn't get to discuss the name last time, we should follow the poll. **Brent Zundel:** there was a good deal of conversation around the name "Controller Document". … mostly on an issue, but also on call. **Joe Andrieu:** when we first came up with the name, it was a "let's use this for now". … I don't think it has merit to dismiss the poll. > *David Chadwick:* +1 JoeAndrieu. **Brent Zundel:** I don't think that's what's happening. **Manu Sporny:** I agree with JoeAndrieu as one of the people who named it initially, we did select it out of thin air...mostly. … I'm not a fan of "Controller Document". … the way ranked choice works isn't about the margin. … anything that comes out on top, is the clear preference, even if the margin is slim. … we sadly don't know who all voted. … I'm willing to make the change across the documents. … I think it was Gabe who made the "Identifier Document" which shows some of it's lineage to "Decentralized Identifier Document". … the poll does show a preference...however small. … could we run a poll for the top two? … and if there's still no consensus, we stay the course? **Brent Zundel:** before going to the queue, let me attempt to express my deeply felt apathy about this change. … I don't care. … we could call it the Poopy Pants Thingy Document. **Gabe Cohen:** I also do not care. Even as the person who proposed "Identifier Document". > **Proposed resolution: Rename Controller Document to Identifier Document.** *(Brent Zundel)* > *Manu Sporny:* +1. **Gabe Cohen:** I think there are better things to discuss. > *Joe Andrieu:* +1. > *Brent Zundel:* +0. > *Gabe Cohen:* +1. > *Benjamin Young:* +0. > *David Chadwick:* +1. > *Dave Longley:* -1 but would support Controllable Identifier Document. > *Ivan Herman:* +1. > *Jennie Meier:* +1. > *Ted Thibodeau Jr.:* -0.7. **Ted Thibodeau Jr.:** the problem with "identifier document" is that it holds both identifier and crypto material. … the crypto is not identifiers as currently defined. … if we want the name of this thing to communicate to people who find these, I think "identifier document" is the wrong name for it. **Dave Longley:** similar concerns from me. … there are many documents you could describe as "identifier documents". … these documents, however, are about controlling identifiers. … so we'd sadly be missing that key thing. … we'd be missing something if that's the only words in the name. **David Chadwick:** I wanted to propose something different. … is there anyone strongly against "Identifier Document"...that's how the poll went anyway. **Brent Zundel:** we sadly do not have consensus to change it. **Joe Andrieu:** I want to make the case that this document is about one identifier. … it then provides things related to that identifier. > *Dave Longley:* i don't care enough to block it. > *David Chadwick:* The voting shows a strong consensus to change the name. 5 for, 2 dont care, 1.7 against. > *Dave Longley:* -0. > *Ted Thibodeau Jr.:* "Identifier Interaction Methods [Document]"? > *Dave Longley:* would we get fully support for "Controllable Identifier Document"? > *Dave Longley:* full*. > *Brent Zundel:* bigbluehat: I also don't care. It may be about one identifier, but the document has more than than. I think Identifier Document is painfully broad. Controllable Identifier Document if kind of okay. > *Manu Sporny:* Controllable Identifier Document polled at 79, FWIW. > **Proposed resolution: Rename Controller Document to Controllable Identifier Document.** *(Brent Zundel)* > *Manu Sporny:* -1. > *Dave Longley:* +1. > *Gabe Cohen:* +0. > *Benjamin Young:* +0. > *Joe Andrieu:* +1. > *Ivan Herman:* 0. > *Ted Thibodeau Jr.:* -0.9. > *David Chadwick:* With dlongley's change of vote we have 5 for, 3 dont care, 0.7 against. **Brent Zundel:** the W3C process works on hard consensus. … so people not liking something, means we keep working on finding what works for everyone. **Manu Sporny:** k. everyone's sad. … let's move on. … it would've been easier if there was strong support for something. … I would have loved to change the name. … but it's not worth fighting for. … let this be a lesson to everyone to not arbitrarily name specs in the future. **Brent Zundel:** shoulda named it poopy pants. **Joe Andrieu:** clearly you do care brent. **Ivan Herman:** so we should close this issue. **Brent Zundel:** thanks everyone, that was the meeting. … let's talk again next week. ---

[iherman]

Closing per discussion on the last WG call.

[msporny]

Here are the results from the poll (for posterity):

... and the text-based breakdown:

OpaVote Election Results (https://opavote.com/)

A Poll to Rename the Controller Documents Specification

There are 12 candidates competing for 1 seats. The number of voters is 21 and
there were 21 valid votes and 0 empty votes.

Method Options:
    Ballot Completion -- Off

Counting votes using Borda Count.

                          Candidate | Count
===========================================
               Controller Documents |   113
               Identifier Documents |   129
    Identifier Controller Documents |    72
          Cryptographic Identifiers |    57
 Cryptographic Identifier Documents |    96
           Controllable Identifiers |    59
  Controllable Identifier Documents |    79
                 Identity Manifests |    41
               Identifier Manifests |    67
              Interaction Documents |    64
             Verification Documents |    52
Cryptographic Information Documents |    51
                          Exhausted |   506

Borda count totals.

Winner is Identifier Documents.

[sloops77]

@msporny can you easily run a rank choice vote so we only have two options left?

[msporny]

@msporny can you easily run a rank choice vote so we only have two options left?

I could re-tally as a variation of RCV, though Borda count was the more appropriate voting scheme for this particular choice:

https://opavote.com/methods/ranked-choice-voting

If we did many of the variations of RCV, the remaining two would be Identifier Documents and Controller Documents, w/ Identifier Documents winning in most (but not all) cases.

That said, there was weak support to change the name during the telecon with multiple parties claiming that they didn't care about the outcome. It became obvious that we couldn't get to strong consensus on the name change, so we closed the issue and moved on.

[David-Chadwick]

I dispute the fact that there was weak support to change the name. If you read the minutes there was overwhelming support for a name change, with only 0.7 against. With @dlongley's change to 0, we have 5 for, 3 dont care, 0.7 against

[brentzundel]

I dispute the fact that there was weak support to change the name. If you read the minutes there was overwhelming support for a name change, with only 0.7 against. With @dlongley's change to 0, we have 5 for, 3 dont care, 0.7 against

There was never a claim of weak support to change the name. There is very clearly strong support to change the name. Unfortunately, W3C process calls for more than strong support. It calls for unanimity where possible (everyone in favor), where that is not possible a chair can declare consensus as long as there aren't too many abstentions and there aren't any objectors. -0.7 isn't much, but it is still an objection and therefore we did not have consensus.

However, in light of the strong desire of some members of the group to continue working toward consensus on this issue, I will re-open it.

[selfissued]

I believe that changing the name would cause more confusion than benefit. I believe that @brentzundel already made the best call available to us.

[David-Chadwick]

@msporny "That said, there was weak support to change the name during the telecon" @brentzundel "There was never a claim of weak support to change the name. " Perhaps you guys could reconcile your opposing views?

[msporny]

@David-Chadwick

Perhaps you guys could reconcile your opposing views?

I'm conflicted about the resolution, and my view isn't necessarily in opposition to @brentzundel's call -- I think there was a judgement call that had to be made and the Chair made it. I accepted it and moved on; other's didn't. :)

I can see both sides of the argument. It is true that there wasn't strong consensus. It is also true that there weren't sustained objections that would lead to a formal objection. I both agree and disagree with both @brentzundel and @jandrieu :) -- it was a tough call. The resolution would have passed at IETF, it was not strong enough to pass at W3C.

But that's neither here nor there, the topic has been re-opened and will be discussed until we can move forward without a formal objection, or until it's clear that we can't do that.

When we open up the discussion again, it would be good to understand what we'd need to see in the data / proposal to know if the proposal passed or not (as horribly meta as that is).

There is one item that Dave Longley mentioned around "identifier document" being a mistake that we didn't have the time to discuss (could be considered "new information"). At the time, I didn't understand his point and that might help push other people one way or the other on their decision.

My biggest concern at this point is the extra time this is going to add to get to CR and beyond, as I'm sure that concern is shared by a fair number of people in the WG.