Re: [urn] Finalizing items from IETF 83

Julian Reschke <julian.reschke@gmx.de> Tue, 03 July 2012 19:40 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F6611E81EE for <urn@ietfa.amsl.com>; Tue, 3 Jul 2012 12:40:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.959
X-Spam-Level:
X-Spam-Status: No, score=-104.959 tagged_above=-999 required=5 tests=[AWL=-2.360, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxvTiHAYkaBf for <urn@ietfa.amsl.com>; Tue, 3 Jul 2012 12:40:05 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 67DF911E81EB for <urn@ietf.org>; Tue, 3 Jul 2012 12:40:05 -0700 (PDT)
Received: (qmail invoked by alias); 03 Jul 2012 19:40:12 -0000
Received: from p5DD96484.dip.t-dialin.net (EHLO [192.168.178.36]) [93.217.100.132] by mail.gmx.net (mp039) with SMTP; 03 Jul 2012 21:40:12 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/+/qA/K3j+RuwASeqvwFqGFge0L6xCl5tQPc8pDU MYtRle+1p0X74U
Message-ID: <4FF34A98.1030304@gmx.de>
Date: Tue, 03 Jul 2012 21:40:08 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
References: <234FA8E3-C00D-4DA9-AD6C-41A3AC2548E4@hxr.us> <4FEBF708.9030604@helsinki.fi> <24637769D123E644A105A0AF0E1F92EF246915EE@dnbf-ex1.AD.DDB.DE> <4FEC2B8C.4070604@gmx.de> <4FF344A9.9090501@stpeter.im> <4FF345F5.5080300@gmx.de> <4FF34748.3010202@stpeter.im>
In-Reply-To: <4FF34748.3010202@stpeter.im>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: "urn@ietf.org" <urn@ietf.org>
Subject: Re: [urn] Finalizing items from IETF 83
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jul 2012 19:40:07 -0000

On 2012-07-03 21:26, Peter Saint-Andre wrote:
> On 7/3/12 1:20 PM, Julian Reschke wrote:
>> On 2012-07-03 21:14, Peter Saint-Andre wrote:
>>> On 6/28/12 4:01 AM, Julian Reschke wrote:
>>>> On 2012-06-28 11:42, Svensson, Lars wrote:
>>>>> Juha wrote:
>>>>>
>>>>>> But
>>>>>> I hope that RFC2141bis will say at least that fragments are not
>>>>>> part of
>>>>>> the NSS but they can be used in those namespaces which specifically
>>>>>> allow that.
>>>>>
>>>>> I'll second that RFC 2141bis says that fragment identifiers are
>>>>> allowed in URNs but that they are not part of the NSS. Further, RFCs
>>>>> for new namespaces must specify if they allow the use of fragment
>>>>> identifiers or not but I guess that is something for RFC 3406bis.
>>>>
>>>> No.
>>>>
>>>> Namespace specifications define the namespace-specific part; nothing
>>>> else. Fragment syntax and semantics are defined by RFC 3986.
>>>>
>>>> A spec *can* point out that the URN does not identify something from
>>>> which a payload + media type can be retrieved, in which fragment
>>>> identifiers are not applicable. But that's different from disallowing
>>>> them.
>>>
>>> Julian, by "spec" here do you mean a specification for a particular
>>> namespace identifier? ...
>>
>> Yes
>>
>>> ...(And would one result be that each NID spec would
>>> need to specify whether URNs issued within that NID identify entities
>>> from which a payload + media type can be retrieved?)
>>
>> I'd prefer those specification to be simply silent on the issue, or
>> alternatively that the URN spec contains a clarification the NID
>> specifications can simply reference.
>
> And what do you think that clarification would say? Perhaps something
> like "unless a particular URN namespace explicitly specifies otherwise,
> applications ought to assume that no payload or media type can be
> retrieved from the entity associated with a URN"?

"URNs in general can not be used to retrieve a payload with an 
associated media type, thus URI fragment identifiers can not be used. 
However, they can become resolvable, in which case fragment identifiers 
will behave exactly the same way as for any other URL."

Or something like that...