Re: [urn] Meeting in Prague for IETF 80

On 2011/03/09 13:51, Peter Saint-Andre wrote:
> <hat type='individual'/>
>
> On 3/8/11 5:52 PM, Andrew Newton wrote:
>> All,
>>
>> Our session for IETF 80 will be on Thursday, 31 March from 1300-1500
>> (Afternoon Session I).
>>
>> I will be putting together an agenda for our session soon. If you have
>> any requests for agenda time, please send me a message. My inclination
>> is to structure our session for as much high-bandwidth, face-to-face
>> discussion as possible and save consensus calls and as much
>> administrative work as possible strictly for the mailing list.
>
> Always a good policy. :)
>
> It seems to me that we could spend quite a bit of time on the issues the
> big issues that Juha mentioned the other day:
>
>     As regards the URN syntax, the key issue - at least from my point of
>     view - that should be discussed more widely is the usage of
>     <fragment>  and<query>  in the way suggested in RFC2141bis.

I haven't exactly been able to figure out what RFC2141bis is proposing 
for fragment identifiers. One reason is that as it is currently written, 
it contains way too much meta stuff explicitly discussing changes to its 
predecessor, rather than just new stuff. Noting issues in an ID can 
sometimes be extremely helpful, but going as far as to point out 
explicit and obvious clerical errors in the previous version rather than 
just fix them seems overkill.

Anyway, from a higher-up view, RFC2141bis is defining the "urn:" URI 
scheme, and URI scheme definitions in general are supposed to say 
nothing (or just a little in some exceptional cases) on fragment 
identifiers. The reason for this is that fragment identifiers are 
defined per MIME Media Type, not per URI scheme.

So if I have something like "urn:foo:bar:baz#here", then the urn spec 
only has to say what "urn:foo:bar:baz" is supposed to mean, the meaning 
of "here" is defined by whatever format I might get back when resolving 
"urn:foo:bar:baz". If I have a browser that resolves (some) urns (I 
don't know one, but there should be some), this is what already happens, 
and it shouldn't and won't change. RFC2141bis doesn't have to say 
anything for this to work.

In case RFC2141bis tries to do anything else than the above, that would 
be a very bad idea, and should be fixed quickly.

That's quite different from the query part; if the urn spec wants to 
allow a "?" and some following stuff, it can do so, and it can put on 
the syntactic restrictions (as long as they are within the bounds of the 
URI spec) and semantic restrictions the WG deems appropriate.

Regards,   Martin.

>     The
>     reason why it is vital to make firm decisions concerning these
>     features is that there are projects that intend to use both of them,
>     and must have explicit permission and guidelines for doing that.
>
> But his entire message is worth pondering:
>
> http://www.ietf.org/mail-archive/web/urn/current/msg01507.html
>
> Peter
>
>
>
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp