Minutes for URNBIS at interim-2016-urnbis-01
minutes-interim-2016-urnbis-01-1

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

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

---------------------