Re: [urn] Talking about fragments in URNs

"Hakala, Juha E" <juha.hakala@helsinki.fi> Wed, 29 June 2016 07:56 UTC

Return-Path: <juha.hakala@helsinki.fi>
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 8536212D1D7 for <urn@ietfa.amsl.com>; Wed, 29 Jun 2016 00:56:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level:
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=helsinkifi.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QO2PGxIWvrwg for <urn@ietfa.amsl.com>; Wed, 29 Jun 2016 00:56:53 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0134.outbound.protection.outlook.com [104.47.1.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEB4612B078 for <urn@ietf.org>; Wed, 29 Jun 2016 00:56:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HelsinkiFI.onmicrosoft.com; s=selector1-helsinki-fi; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SU9sklLRaPB8GPY1jXzPLvJQmp1FYgvkEXUEu42+gCY=; b=eAwK98iyLfKq2xdKDTLTJ1Nk1KLcvjVaMURL3eIAk5L2Nmso+HOMx1/2j6VIINfnoGCFy0MxVjSqCIYblZ/vRWBYX6377mYGwCA+0M5VOXb9PbfcFUN7uRH1io9t1WrATnxe3GbUrkpOprY3GsBDfIgFLxuN9ABytrwk2lTmjZY=
Received: from VI1PR07MB1727.eurprd07.prod.outlook.com (10.166.143.23) by VI1PR07MB1726.eurprd07.prod.outlook.com (10.166.143.22) with Microsoft SMTP Server (TLS) id 15.1.528.16; Wed, 29 Jun 2016 07:56:49 +0000
Received: from VI1PR07MB1727.eurprd07.prod.outlook.com ([10.166.143.23]) by VI1PR07MB1727.eurprd07.prod.outlook.com ([10.166.143.23]) with mapi id 15.01.0528.017; Wed, 29 Jun 2016 07:56:49 +0000
From: "Hakala, Juha E" <juha.hakala@helsinki.fi>
To: Sean Leonard <dev+ietf@seantek.com>, "urn@ietf.org" <urn@ietf.org>
Thread-Topic: [urn] Talking about fragments in URNs
Thread-Index: AQHRvalqNaNE0A+SzUWjMkV0DJvCfZ/YJFqAgCeWzwCAAAkJgIAAOgoQgAAsloCAAAcXoA==
Date: Wed, 29 Jun 2016 07:56:49 +0000
Message-ID: <VI1PR07MB1727D9CC015A1C1A34AD6A35FA230@VI1PR07MB1727.eurprd07.prod.outlook.com>
References: <CALaySJ+NpCY9dMhuz+yyP4N0x6cO7D+iHVvaeAhoV2QxNvDPXQ@mail.gmail.com> <aae7f6bf-b42f-3063-4422-ba139b6eb974@seantek.com> <d6528125-0f16-70c6-7048-5d29e53b427e@stpeter.im> <4839DC906BA288B105BFE29F@JcK-HP8200> <VI1PR07MB1727935B40F4047972F7A163FA230@VI1PR07MB1727.eurprd07.prod.outlook.com> <efc6b6cc-fd83-0acf-15a3-2598e41a90df@seantek.com>
In-Reply-To: <efc6b6cc-fd83-0acf-15a3-2598e41a90df@seantek.com>
Accept-Language: fi-FI, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=juha.hakala@helsinki.fi;
x-originating-ip: [128.214.71.222]
x-ms-office365-filtering-correlation-id: 50f19e55-87d2-489e-74e5-08d39ff2ece6
x-microsoft-exchange-diagnostics: 1; VI1PR07MB1726; 6:oAVKUEVhd64gw11CWpjD0Q5cBvv0ps/gL5y0pPzB8oSgacheOtEpQOwbafUxMTTLFbeZFdn3KeEqw/MlhmLtjxaDiR00EvhUmbjhkVRBzqpqhYxFmVX5G1KMJCDroJClaGvrT6SVzGxv020nKI1lhIYnTF8Xc0nZPWAo9AwbMTr5MCZ6ybnfAs4642uILMwT79GdYWE6eFavWc4FeG7pZGa1XY40OFFnRd2XBhA4PD/RCnJC1wYGl+1DTyNeDsSVnTaJdVPf1tPGe3M2sHLXFIvpbBH2tcNY+d+iAzfLtEs=; 5:3tSQf8DlnWA/kQCh3BgG1eYL3flRCTq9xipVKJjU6Zi8w99l7DjMknunAZk6gICc9jgXomwt12JFwtDe4Mz223SCYIistTljI/h12HPMbX0hLW9IUbPL3muSRsuIZQ2gw9snLY6bZ0A4ZhEhgID2zw==; 24:9UqLv6G7Pnf2XjayhWugI88Eyi1C5d8404o+tVFfs4mpm/Rxps0wt/aJUqGMUz9pwRqZdwC+euktybgxw+kln+SpuxRagdDQFJ/14z7ka2I=; 7:U5wj11NwleLRYRbmtPQu4FNANt4gvYg/Mi0G7ujGcJha2F5Zf8iSaQw7x69PorsOzs3TszijyNFP74XntEFq1vdzF0WVuMFYmDE2ht3HtXb9UCwXsw6W9essyP4+sydalQv0v6FFI6D3gwOqvSl0CncjmEufTRNhpVBXQjz3KYb77y6+Ob6glqOZv20trgquE5UmGbEyA17Q6YdmQKEHRiQY0xmrvkLdx713mlQOQJm7E8V3gDvu7oDJ06mBUrVt
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1726;
x-microsoft-antispam-prvs: <VI1PR07MB1726D3352F18431E6EDC8E53FA230@VI1PR07MB1726.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:VI1PR07MB1726; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1726;
x-forefront-prvs: 09888BC01D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(199003)(377454003)(24454002)(189002)(7696003)(586003)(5003600100003)(19580405001)(19580395003)(7846002)(3660700001)(10400500002)(122556002)(2501003)(101416001)(33656002)(92566002)(81166006)(9686002)(7736002)(8676002)(189998001)(2950100001)(87936001)(102836003)(68736007)(74482002)(76576001)(2900100001)(81156014)(2906002)(31430400001)(6116002)(5001770100001)(3846002)(3280700002)(97736004)(77096005)(15975445007)(106356001)(106116001)(86362001)(105586002)(93886004)(50986999)(66066001)(76176999)(54356999)(107886002)(8936002)(5002640100001)(305945005)(11100500001)(74316001)(561944003); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1726; H:VI1PR07MB1727.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: helsinki.fi does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: helsinki.fi
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2016 07:56:49.2117 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1726
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/ZXypAld2w_Dm9bp1wAe9Ziml16Y>
Subject: Re: [urn] Talking about fragments in URNs
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 29 Jun 2016 07:56:58 -0000

Hello Sean; all, 

some comments below. 

> -----Original Message-----
> From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Sean Leonard
> Sent: 29. kesäkuuta 2016 9:54
> To: urn@ietf.org
> Subject: Re: [urn] Talking about fragments in URNs
> 
> On 6/28/2016 10:39 PM, Hakala, Juha E wrote:
> > Hello,
> >
> > there are at least four different aspects of equivalence or "naming the
> same thing".
> > [...]
> 
> Thank you, Juha, for that.
> 
> Upon reading the responses, I revise my proposal of "Name the Same
> Thing". It appears that "NtST" means or can be implied to mean "semantic
> equivalence", which is not what we are going for.

Yes. People who actually create URNs must pay attention to semantic equivalence and use the namespace specific rules when they do that. But it is beyond the URNBIS scope to try to tell namespaces what they should be doing. 
> 
> I read draft-ietf-urnbis-rfc2141bis-urn-17 and remain staunchly opposed to
> the term "URN equivalence". The term is confusing and adds little value.
> Even very intelligent people can't tell if the q-, r-, and f-components are
> supposed to be included in the comparison or not.

They are not, since then many namespaces would not be able to use them. Including f-component in the comparison would mean for instance an extension to the ISBN scope so that it could be used to identify component parts of books, which is not acceptable to the ISBN community. The problem can be bypassed simply by saying that fragment does not identify anything, which is not compliant with what at least some people think RFC 3986 requires. This dilemma has been solved by making URN palatable to the identifier systems.     

> Honestly, I don't see why we got away from the term used by Section 5 of
> RFC 2141, "lexical equivalence". Folks, that is what we have been talking
> about all along.

Lexical equivalence might be a better term than URN equivalence, since URN equivalence can be understood to be too broad a concept. For instance, some people may think that URNs based on ISBN-10 and ISBN-13 of the same book are equivalent in the RFC2141bis sense of the word since they identify the same resource. However, these URNs are lexically equivalent only if additional namespace specific rules are applied to detect the equivalence. RFC 2141bis guidelines alone would not be sufficient to detect the equivalence.  
 
> Lexical def.:
> http://www.dictionary.com/browse/lexical?s=t
> 1. of or relating to the words or vocabulary of a language, especially as
> distinguished from its grammatical and syntactical aspects.
> 2. of, relating to, or of the nature of a lexicon.
> => Lexicon def.:
> 1. a wordbook or dictionary, especially of Greek, Latin, or Hebrew.
> [...]
> 3. inventory or record.
> 
> ***
> That is what we are talking about. A namespace is an "inventory" (or
> "dictionary") of names. Each name is different. But some names can be
> written in a plurality of ways but still be the same name. Tomatoes and
> tomatos are the same fruits (tomato is a fruit, in case you were wondering).

OK, but in lexical analysis we would only be interested in one language at the time. We shall not try to determine anything across languages, for instance to determine if tomato and tomaatti mean the same thing.   

> It appears that the term "lexical" got dropped between draft-05 and
> draft-06:
> https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-urnbis-
> rfc2141bis-urn-06.txt
> 
> for reasons unbeknownst to me...but as Peter Saint-Andre and Ryan Moats
> were the editor/author at the time, I would like to ask (respectfully and
> politely), "why?"
> 
> Let's bring back "lexical equivalence", and call it a kind of scheme-specific
> comparison (Section 6.2 of RFC 3986).

OK, but in order to avoid misunderstandings we should say that lexical analysis is not namespace (identifier) specific but applies to all namespaces, and from RFC 3986 point of view it is scheme specific from URN point of view; not from the point of view of identifier schemes. 

We must also keep the last paragraph of 3.1 which says that namespace definitions may include additional rules for URN equivalence. These rules can be lexical or something else. For instance, ISBN standard says that hyphens must are not part of the ISBN and are only used to improve readability (simple lexical rule) but there is also a complex lexical rule concerning generation of ISBN-13 from ISBN-10, and semantic rules concerning identification of resources. 

Juha 

> Another verbal formulation is "two URNs have the same name" (HtSM).
> This formulation is interchangeable with "lexical equivalence", just in a
> different part of speech.
> 
> Regards,
> 
> Sean
> 
> 
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn