[urn] Summary of WG decisions Re: Feedback on draft-ietf-urnbis-semantics-clarif-03

[Sean Leonard <[e-mail]>]

On 5/17/2016 9:10 AM, Julian Reschke wrote:
> On 2016-05-17 17:38, Andrew Newton wrote:
>>
>> Which hasn't changed. The group previously decided to go down the
>> "syntax only" path. This has been discussed in documents and several
>> working group sessions. And I don't think we should reopen the issue
>> as it was a pivotal decision that has been a prerequisite for the
>> progress made so far.
>> ...
>
> WG consensus isn't IETF consensus. If this WG wants to update a 
> standards track document, it will have to be able to answer the 
> questions that I asked.
>
> I hear from you and John: "RFC 3986 syntax, but not semantics", as if 
> there was agreement about what parts of RFC 3986 are which (or is 
> there?).
>
> So, once again, if we say "updates: 3986" we need to be able to 
> explain *precisely* which parts of RFC 3986 are affected (and why, fwiw).

I agree with Julian that these sorts of questions need to be answered.

Given the low & declining engagement on this list, we need a place to 
record WG decisions that newcomers or people who only have a time budget 
to participate occasionally, can get up to speed and (re-)engaged. The 
document(s) itself/themselves have not been a useful guide to the 
proceedings of this WG.

I strongly advocate that we use some new tools to track and record WG 
decisions that the co-chairs and ADs have declared to be the rough 
consensus (or going-forward) positions. Specifically, I recommend that 
we use the IETF urnbis wiki. I have already created a basic wiki page 
for this purpose:

https://tools.ietf.org/wg/urnbis/trac/wiki/WGDecisions

We have some people saying "oh, the WG decided that, I'm not going to 
re-open that issue", when there is material technical disagreement about 
whether some decision is doable, or there is historical disagreement 
about what decision was actually made.

Two examples:
(1) I recall specifically that this WG decided that URN syntax shall 
conform to RFC 3986 URI syntax. (I cannot find a specific e-mail 
reference for it.) That much I can work with. There is material 
disagreement about whether, and to what extent, URN "semantics" either 
need to--or must not--conform to RFC 3986 URI "semantics". I have 
searched and can find no record of decision on this point. A lot of 
recent objections / elliptical decisions on things like "what is a 
resource?" and so on, have been fueled because people are throwing up 
arguments about what has been decided, when the semantics issue has 
(apparently) not been decided.

My take on this, is that URN syntax === URI syntax. Whether and to what 
extent URN semantics == URI semantics, is not a decided WG issue. 
Therefore saying "oh, the WG decided syntax but not semantics" is 
inaccurate.

Actually the semantics issue has been misunderstood. RFC 3986 pretty 
much says that a "resource" is anything that can be identified by a URI, 
so it's a circular definition. If you can name it, you can claim it. The 
end. An RFC 3986 "representation", in contrast, is an actual concrete 
computable thing, and could be (for example) a content with a media 
type. This really is a debate about nomenclature in the documents. This 
WG can repurpose the term "resource" in a URN to mean something other 
than RFC 3986, but it's confusing if we are not updating RFC 3986.

(I do recall specifically that a chair or AD stepped in a couple of 
years back and declared updates to RFC 3986 to be out of scope of this 
WG. I cannot find the reference.)

(2) RFC 2141 says that NSS is UTF-8 encoded. RFC 5198 (NETUNICODE) says 
that updated stuff SHOULD use Unicode/UTF-8. This WG is technically 
constrained to follow UTF-8 percent-encoding for NSS, and SHOULD nail 
down UTF-8 for the other parts in its purview (i.e., the query 
production). I do not believe that this WG finally made a decision on 
the point; however, the predecessor WG obviously made a decision, so we 
should consider that pretty weighty in terms of what to follow, clearly 
decide if there is a need to deviate, and be done with it.


I have set up the wiki so that existing participants and newcomers alike 
can adhere to the decisions made, with documented evidence. I hope that 
we can use this tool, or a similar tool like it.

Regards,

Sean