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