Minutes for URNBIS at interim-2015-urnbis-1
minutes-interim-2015-urnbis-1-1

URNBIS Virtual Interim
17 April 2015
16:00 - 18:00 UTC (9am-11am PDT, 12pm-2pm EDT, 18:00-20:00 CET)

Chairs: Melinda Shore, Andy Newton
Scribe: Andy Newton, Petere Saint-Andre

Attendees:
    Andy Newton
    Melinda Shore
    Barry Leiba
    Peter Saint-Andre
    Keith Moore
    John Levine
    Julian Reschke
    Leslie Daigle
    Tony Hansen
    John Klensin
    Lars Svensson

Agenda:

1. 2141 status update
2. Open issues walkthrough

Melinda has opened the meeting. Noted the IETF Note Well. Also asked for
consent from all to record the meeting. No objections to recording the meeting.

John Klensin discussed the current status of 2141bis draft.  Issues with 2141

1. Where the components go - what's an instruction to a URN processor and
what's an instruction to a resource a. what is metadata about the resource /
object? b. what is information to be used by a processor or resolver

2. Which of those components do we want to permit?
Keith's argument seems to be that p-components are more trouble then they are
worth,

3. What are we going to do with fragments?
Some of the URL or HTTP oriented communities believe that anything we say here
is likely to be misguided

Keith: it's not just the syntax, it's also the use of relative references and
what that means w.r.t. RFC 3986 John: that might be a semantic problem as well,
that's probably issue #4

Andy: shall we talk about the three issues that John has identified?

Andy summarizes previous discussion from the WG around syntax vs. semantics

John: the idea about relative references seems to have been related to the idea
of a generic URI parser

Keith: relative references have an impact on queries and fragments, too (not
just p-components)

Julian: we know that some software tries to do relative resolution but don't
exactly follow RFC 3986 Julian: I don't think that relative resolution would be
all that helpful if it doesn't apply to all URI schemes Julian: better to say
that relative resolution applies to URN, but results might not be useful

Peter: the latter is what we say in Section 5 of 2141bis right now

Keith: if you navigate to a document via URN it would still be useful for
relative references to work

John: but how you navigate to a document is done through location information
(URLs), not directly URNs John: if URN resolution leads to a URL, then relative
references would work in the URL context

Keith: if that's our conclusion, then let's say that
Keith: not limited to URNs (if no base reference)
Keith: the other option is to say that p-components need to have enough
structure that things work

Andy summarizes (not captured)

John: internal document problem vs. general syntax problem

Barry: is this a "what if?" concern or a real problem?

Keith Moore: I think it's a real problem

Barry: if someone is going to generate a URN that violates the spec, do we need
to be responsible for that?

Keith: security issue

John: but the security issue is not limited to URNs

Barry: anyone can put anything into a URI resolver - the resolver needs to
handle the input in a careful way Barry: schemes can restrict what 3986 allows,
but not expand it

Leslie: we should examine the components of the syntax first and especially
figure out what to do about p-components

Keith: relative references do limit what we can do with p-components and
q-components Keith: are we going to overload the meaning of those components in
URN space?

Andy asks a question

Keith: if we follow the rule about relative references having meaning only in
the context of URLs, the component constraints are less onerous Keith: passing
information to a resource via q-components seems useful

Peter: I had thought we were going in the direction of sending information to
processor via q-component

Keith: would like to keep those separate

John: we need a way to pass information to a processor (cf. repeated comments
from Juha) John: I think it's important to note that whether information is
passed to a processor or a resource does not necessarily constrain syntax

Keith: I agree

John: we also have lots of running code to pass information to processors via
q-components, bundled with URNs

Keith: it's always a challenge to balance running code against usages that
aren't consistent with the spec

John: we are dealing with reasonable people so I would think we can figure out
how to move forward

Keith: it would be helpful to know what the existing running code is doing

Lars: we have running code in Germany where the q-component is specific to the
resolver service, not to the URN itself Lars: query component is sent when
sending a request to a resolver via HTTP (the URN is part of the HTTP URL, the
query is not part of the URN) Lars: I am not sure how things are implemented in
Finland

Keith: passing the query via HTTP is very different from bundling the query
with the URN

John: Juha has presented examples in which q-components would be bundled with
the URN, e.g. to use q-component to request metadata about an abstract object

Keith: whether anyone actually needs or wants p-components is unclear
Keith: might be easier to allow them (because this is our only chance to change
the URN syntax) but provide suitable caveats and constraints

Leslie: I'm not completely sold on p-components although John has provided a
rationale for why they *might* be useful Leslie: what is the permanent
identifier anyway? 2141bis is not explicit about the role of the p-component
Leslie: I think we need to spend some time making sure that things are clear

John: what do you find unclear? we now say that p-component is part of
assigned-name and therefore is part of equivalence checking

Leslie: having it part of assigned-name is in the right direction
Leslie: but I think it could be clearer (you're including an existing
hierarchical identifier, don't escape the slashes, etc.)

Peter summarizes where he thinks we are on p-components

Keith: if we say that relative references are relevant only in the context of
URLs and that removes some constraints on p-component usage

John comment (not captured)

Keith: but better to avoid using the same relative reference for both URN
context and URL context, that would be bad

Andy: what I hear is that we're going to allow p-components

Andy: what about fragments?

John: not only misguided by a violation of 3986

Keith: useful to refer to fragment and bundle with URN, means the same as with
a URL (evaluated with respect to the resource context, not interpreted by the
resolution service)

John: other way of saying that is if you attach fragment, pass it through to
the object

Lars: what if no resolution service?

John: it's handled by whatever does something with the URN (an unfortunate
answer, but I don't see a better option)

Keith: evaluated with respect to the resource context

John: I think fragments are just a pass-through object

Keith: I think we're on the same page, just a different in terminology

John: let's say we have a URN namespace for interesting people and there's a
fragment appended to the URN for "Keith Moore" - that fragment would have no
meaning in the context of a SIP URI but would have meaning in the context of an
HTTP URL (e.g., a biography)

John comment not captured

Andy question

John: 3986 talks about media types but that's a level below URIs
John: if the thing that results from URN processing is a URL then it's clear
what it means to pass the fragment through, but it what gets returned is
something else then it's less clear

(discussion about resolution and the universality of resolvers)

Andy: I haven't heard anything here that indicates we need namespace-specific
handling

Keith: maybe there is some hint that we might have namespace-specific handling
of q-components in the field today

Peter: how is this different from HTTP URLs?

John: we need a syntax distinction between what gets passed to resolver and
what gets passed to the object