Subject: [urn] Notes from the URNbis virtual meeting

From: Barry Leiba <[email-masked]>
Date: Fri, 8 Jul 2016 11:12:37 -0400

My apologies for having not posted this sooner; I wrote them up the
next day and got some review, but wasn't able to follow up until now.
I will figure out how to post these to the datatracker forthwith.

Barry, as chair

----------------------
29 June 2016

Start at 12:05 NY time

Attendance:
Alexey Melnikov (AD)
Andy Newton (chair)
Barry Leiba (chair)
Henry Thompson
John Klensin
Juha Hakala
Julian Reschke
Peter Saint-Andre
Sean Leonard

Semantics clarification
- meant to set the stage
- need to be sure we're on the same page with respect to it, and that's all
- not "update" 3986, but look at the principles that
semantics-clarification set out
- a bit of background on how s-c came about
- - maintain syntax compatibility for URNs, but not necessarily semantics
- - how are fragments interpreted in URNs?
- concern: we can't break generic URI processors
- claim: you still need to understand the URI scheme...
- - ...so any processor that doesn't understand the "urn:" scheme
can't process them anyway
- - ...and any processor that does will know what to do with it
- - comment that generic URI processing is basically limited to
generic parsing (which is all that 3986 talks about), and that any
further processing, including resolution, needs knowledge of the URI
scheme
- discussion of those points -- agreement so far
- discussion brings up an issue in 2141bis Section 4.3 ("URNs and
Relative References", text from April 2015) Need to work on that text,
but it's editorial, not a fundamental issue.  Henry is willing to work
with John and Peter on text.
- The document has served its purpose and will not have any further
major work.  The point is to make sure that 2141bis reflects the
principles outlined here.

2141bis Issues:

1. URN equivalence
- Sean is concerned that just "equivalence" is unclear and confusing
- Agreement that equivalence as specified here ends at the bytes in
the URN, and that "equivalence" such as "names the same document",
while a reasonable thing to consider, is out of scope here
- We're in agreement about what the document needs to say, but we need
to settle on terms to go with the definitions -- at minimum, putting
the hyphen back into "URN-equivalence".  Sean prefers "lexical
equivalence", but John is conccerned that that term creates new
ambiguities and that the document needs to distinguish among various
types of equivalence, two of which it addresses now and some that it
does not:
- 3986 baseline equivalence: octet-by-octet identity across the entire string.
- URN-equivalence: whatever it is that 2141bis specifies as
scheme-specific equivalence.
- Namespace-equivalence: whatever 2141bis should say about equivalence
within a specific namespace, which could be further specified in the
namespace definitions.
- Other forms of equivalence that depending on dereferencing or object
retrieval, which ought to be well out of scope here.

2. Usage of the term "urn" -- used for different things, and sloppily
(related to name and namespace)
- General cleanup will be done: Peter has already agreed to start that.
- Cleaning it up fully will probably take more than one pass, and will
require careful review.

3. Ordering of components, and the issue of "?=" or "?+" appearing in
a q-component
- Discussion of the advantages and disadvantages of flexible ordering
vs limiting the acceptable content of the components.
- Decision to require r-component to come before q-component, so that
the "?+" delimiter for r-component can't be confused as being part of
the query.
- Decision to remove restriction on "?=" and "?+" in q-component.  The
q-component will only end with "#" or end-of-string.

4. Discussion of f-component text (Section 2.3.3)
- Decision not to change that -- what's there was difficult to arrive
at, and we will stay with it.
- But see the comment above about the relative reference text in
Section 4.3, which will interact with this.
- CREF3 (at the beginning of 2.3.3) will be removed.

Chairs thank everyone for taking the time to attend; we were able to
resolve what we intended to.

End at 13:59 NY time

Steaming audio:
https://ietf.webex.com/ietf/ldr.php?RCID=201acf77f3c0b85c3dbb2522869314da
Download audio:
https://ietf.webex.com/ietf/lsr.php?RCID=0be6a5705f32a5c45f91ba3c7b772830
----------------------