Identify editor's notes that are just comments

[fimbault]

And close them.

[jricher]

Also, remove links to closed comments from the draft.

[fimbault]

The goal here is to make a fast cleanup and then concentrate on core issues. But please make sure you agree with the items to be closed (your opinion might differ).
(still need to go through the issues opened by Yaron - up to issue 27)

Here's the list of informational issues we could close directly (no action to be taken):
#36
#47 (it's more a reminder but no action is currently expected)
#64 (or detail what is expected from that issue)
#73
#81
#83 (already described in other issues)
#98 (speculative)

• if needed we could close but still tag them for reference when a specific subject is to be reviewed (see suggestion below)

Here's a list that needs a relatively simple decision or has been already extensively discussed in the WG:
#35
instance identifier #46 -> just validate there is consensus (important choice)
#66
#76
#82
#84 (just make sure we agree we keep hashes, or not)
#121 drop the mode
as well as the issues discussed during IETF109 #40 #44 #45 #59 #67 #122

We also need to iterate quickly on terminology related issues so that we can use it for the rest of the work.

For the rest, I still think it would be useful to be able to do triage in a more detailed way than Editorial and Design, so that we can have a clearer path forward. In particular there are often many small issues related to the same domain, so we might want to group them (especially to avoid incompatible choices).

Full suggestion (if there's agreement, I can do that):

• editorial/design (the only tag really mandatory)
• normative/informative/extension/idea (the last being for items we don't yet know if they should be included)
• per type of work : terminology, example, appendix, implementation
• per feature type : interact, request, response, assertion, errors, flags, keys, token, headers, etc.
• in relation to other projects : jose, openid, did, etc.

[jricher]

I think we can close #36 (resources by reference) as it relates to the polymorphism discussion.

I think #46 is similarly a note, even though it relates to the "client instance" terminology discussion.

The rest need to have a concrete decision on whether an item/feature is something we should support or not so I propose leaving them open for now. I agree that most of the decisions will be pretty short, but they should be explicit calls that we record in the issues and address the changes.

I agree that it would be beneficial to have a more in depth tagging system, but we need to make sure that we don't overdo it with too many tags lest we get lost in the detail!

[yaronf]

I don't think we should mix #36 with the polymorphism discussion. It is one thing to ask whether/when it's appropriate to use references instead of full values, and another to ask what should be the JSON representation for refs vs. values, i.e. whether/when to use polymorphism. The latter is an implementation detail of the former.

[fimbault]

@yaronf you're right, there's polymorphism and it's implementation. I would suggest we clarify that it is part of the objective of the polymorphic study (and refer #36 there), but I would tend to close issues which are too vague or when there is no specific/concrete action in sight.

[yaronf]

I agree that #36 is a bit vague and non-actionable. Maybe we need a "super-issue" to discuss references in general, such as the question raised in #19.