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