From nobody Thu Jul 3 01:49:41 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC88F1B27B4 for ; Thu, 3 Jul 2014 01:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 aKCmPG1ZIiPe for ; Thu, 3 Jul 2014 01:49:36 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99F721B2796 for ; Thu, 3 Jul 2014 01:49:35 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s638nFh9025566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 3 Jul 2014 11:49:18 +0300 Message-ID: <53B5190B.8030602@helsinki.fi> Date: Thu, 03 Jul 2014 11:49:15 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Svensson, Lars" , John C Klensin , "Dale R. Worley" References: <24637769D123E644A105A0AF0E1F92EFA445FD34@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA445FD34@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/zdIOfmOrVwAVkprf5VqytxtVpDQ Cc: "urn@ietf.org" Subject: Re: [urn] urn:ietf:rfc X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 08:49:39 -0000 Hello, Some comments below. On 30.6.2014 21:54, Svensson, Lars wrote: > John, > >> >>>> Some comments below, mostly to clarify my earlier note to >>>> which both of you partially responded. First, and most >>>> important, please understand that, while I have biases and >>>> opinions about URNs and their proper definition and use, I'm >>>> trying to be completely pragmatic about this. That means I >>>> am putting three strategic principles ahead of declarations >>>> about what is or is not correct from some perspective. Those >>>> pragmatic principles are >>>> >>>> -- try to accommodate all of those who think URNs are >>>> necessary, i.e., that they are distinct from URLs. >>> Well, of course they are. >> Unless I've misunderstood a number of remarks, your "of course" >> view is not universally shared. Outside the persistent identifier community (people using Handles, DOIs, URNs and ARKs) it is not uncommon to think that URI replaces both URL and URN, and that "a URI may be a a name and a locator at the same time" (see http://en.wikipedia.org/wiki/Uniform_resource_name). I find the word "may" in the quote interesting, since that allows URNs and URLs to be distinct. But the image showing relations of URIs, URLs and URNs in the Wikipedia page quoted above is not correct. RFC 3986 says that every URI is a name (identifier) and in addition URI can also be locator (but not a location). So term URL refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource. See http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.html for more information about this. PID community does not share the view of RFC 3986 that every URI is a name (identifier). But folks using e.g. DOIs have no problems with RFC 3986, since URI Generic Syntax is only explicitly attacking URNs, not other PIDs. > My reading of the discussion is rather that we (== "the community") don't differ on the necessity of URNs. To me the big question is if we can say URI==URL. I say it's not. There are names and there are locators. In some settings, it makes sense to use a locator as a name (and sometimes it doesn't). In my eyes that doesn't make all URIs URLs (but perhaps I live in a parallel universe...). RFC 3986 puts it other way: sometimes it makes sense to use a name as a locator. To me, the real issue is that introducing URIs in RFC 3986 has made things more confused, especially for the PID community in general, and URN users in particular (since of all PIDs, URN is bearing the brunt of the attack). But as the DOI community points out (see http://www.doi.org/factsheets/DOIIdentifierSpecs.html), replacing URN and URL with URI has generic harmful practical implications. > > > The difficulty > is that we don't have a URI syntax definition that is ultimately: > > Method: > > Instead, we have a lot of Method-dependent stuff that affects > how the rest of the URI (whatever that means) is parsed and > interpreted. In some (most?) URN namespaces, NSS syntax is well defined and an application parsing the namespace specific string will know where the identifier ends. It may also be possible to find out with check sum if the identifier is well formed. This parsing would of course cover just the NSS, not the fragment or query (if present). > >>> This seems to be the place where we need to find a common view >>> on things. My reading is that URIs (as defined by 3986) are >>> _always_ identifiers and that _some_ URIs (depending on their >>> scheme) are also locators. Yes, this is what RFC 3986 says. So according to the URI Generic Syntax, my email address juha.hakala@helsinki.fi identifies me (or my mail box in the Helsinki University mail system, or both), even though email addresses are not locators. For anyone who has had any real involvement with identification of people and / or their public identities, the idea of using email address as the identifier for a person is a bad joke. There are situations when email address, alongside the name, can help us to tell apart two people with the same name. But people usually have multiple email addresses, and their emails change. Proper identifiers should be persistent and unique, and there are a lot of URIs out there which are neither. The authors of RFC 3986 could not take a qualified approach and say that only some URIs are identifiers because then they would have been left with what they started from: URLs. And of course RFC 3986 does not require uniqueness and persistence, since that requires (for instance) a well managed URN namespace. >>> To the "pure identifiers" I count >>> e. g. geo:, xcon: and crid: (and urn:), while e. g. http:, >>> ftp: and smtp: would be locators as well. So in my view, we >>> cannot generalise URLs into URIs, which would allow us to keep >>> URNs as a subclass of URIs. >> As I've tried to say before, I think that a philosophical debate >> about the precise proper usage of the term "identifier" is >> extremely interesting but doesn't lead us anywhere on which >> agreement is likely in the foreseeable future. That makes one >> important question whether we are willing to delay any progress >> on URNs until we do agree. In RFC 3986 the scope of the term identifier is completely different from what e.g. libraries and publishers are used to. This semantic difference has also massive practical implications. Assigning social security number to a person, or ISNI / ORCID to a public identity of that person, is very different process than getting an email address from Gmail. The latter has nothing to do with identification. >> >> However, "we cannot generalise URLs into URIs,..." is a >> statement with which I've come to agree. RFC 3986 is precisely >> a generalization of URLs into URI. Yet another view of it is >> that it attempted the impossible (or contradictory) and failed. >> So where does that leave us? Had RFC 3986 been successful, usage of URNs and other persistent identifiers would be diminishing. But during the last decade 100 million DOIs (and much more Handles and URNs) have been assigned, because significant communities out there don't think that a locator is an acceptable name. What is happening is that important digital resources (proper publications, scientific data sets, applications) made available in the Web very often get persistent identifiers which are resolved to URLs. The cool URI philosophy underlying RFC 3986 is being ignored by libraries, publishers, universities and others who own or host significant digital resources and / or must preserve them in the long term. These communities may take PID standardization in their own hands if they don't get from IETF what they want. Handle system and DOI are already being maintained elsewhere (ITU and ISO, respectively), and if URNBIS gets completely bogged in philosophical debates, it will also be hosted by other, less theoretical organizations in the future. Basically we just want to make our existing identifiers actionable in the Web, and it is rather frustrating that achieving this has turned out to be complicated because (among other things) there is something wrong with URI Generic Syntax. Juha -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Thu Jul 3 04:44:10 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCA81B28ED for ; Thu, 3 Jul 2014 04:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.353 X-Spam-Level: X-Spam-Status: No, score=-1.353 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, GB_SUMOF=1, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 YiJBaEb0B6wc for ; Thu, 3 Jul 2014 04:44:04 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A41A1B2906 for ; Thu, 3 Jul 2014 04:43:49 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s63BhZbO031763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 3 Jul 2014 14:43:36 +0300 Message-ID: <53B541E7.9060205@helsinki.fi> Date: Thu, 03 Jul 2014 14:43:35 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Svensson, Lars" , John C Klensin , "Dale R. Worley" References: <24637769D123E644A105A0AF0E1F92EFA445F063@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA445F063@dnbf-ex1.AD.DDB.DE> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/HJjTKWWSMtW7a7l-tDeBEsnjUdU Cc: "urn@ietf.org" Subject: Re: [urn] urn:ietf:rfc X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 11:44:08 -0000 Hello, More comments. > >>> OK. RFC 2483 defines a handful of these keywords and services, >>> but not nearly enough. >> Another example of what I'm trying to avoid. I am certain your >> statement above is true. I am equally certain the trying to >> define (or even adequately characterize) the others will bog us >> down for a very long time and lead us to Plan C or D [2]. So >> I'm trying to push that problem away by making those services >> and keywords a per-NID matter. If it turns out that we can >> later make groups of NIDs into categories that share some set of >> services and keywords, that would be great. But, if we make >> doing so, or even proving that we can do so, a condition for >> URNs, then we will be back to where we were when I first killed >> the URI WG. URNBIS should not even try to specify the missing resolution services and parameters (if any). Creating an exhaustive list would require a lot of time, and after a few years, the list would no longer be complete because new / enhanced applications (digital archives, repositories etc.) will enable more services by then. Trying to specify all these services per-NID is not an optimal solution, since many namespaces will support the same services. Moreover, other persistent identifiers such as Handles and DOIs can use the same services and service parameters. Trying to locate a relevant service from 40+ NID-specific service lists would be time consuming. The solution I've been promoting is that RFC2483bis should specify a mechanism (such as IANA registry) via which the list of resolution services is maintained. Writing a new RFC every time a new service is needed is not a practical solution, but adding a new service into a registry maintained by IANA should not be too burdensome. > Does this imply that we should not try to update 2483 at all but instead make the service description (keywords etc.) part of the NID registration process? NID registrations can include a list of services supported. But such lists are not and will not be stable. So any listing will become outdated shortly, and it is not practical to demand a revision of namespace registration each time a new service becomes available. So the value of this information in namespace registrations is bound to diminish over time. > >>>>> ComparisonIndicator tells something trying to compare a pair >>>>> of URNs for identity whether that particular ServiceRequest >>>>> counts or should be ignored. >>> I am not sure I understand the need for ComparisonIndicator. >> It is a trick to avoid having to resolve the question of whether >> a particular Service Request --or Service Requests in general-- >> are "part of the NSS". I called it "ComparisonIndicator" >> because I believe that, absent the question of comparing a pair >> of URNs for equality, the "part of the NSS" question doesn't >> need a precise answer and might be a distraction. > I think I understand what you are aiming at, but do you think you could provide an example or two just for clarity? (No, I won't nail you down on syntax...). To me, the question of whether service requests are part of the NSS does not really exist. A priori they are not, since the namespace specific string should only contain the identifier. > >>>>> ServiceTarget identifies where the >>>>> ServiceRequest is to be sent and, depending on the >>>>> ServiceType, may be a keyword indicator or, at the risk of >>>>> descending into recursion hell, a URL or URN. >>> Including ServiceTarget into ServiceRequest may not be >>> necessary. URN resolver appropriate for the namespace in >>> question should know which server is able to cater for >>> ServiceRequests of given type. For instance, if a user wants >>> full metadata about an academid dissertation, the resolver >>> "knows" that the national bibliography should be able to >>> fulfill the request. But if the document itself is requested, >>> open repository (using Fedora, DSpace or some other such >>> application) is better choice. >> In the language I've used, what you have just said is "for all >> NIDs, it should be possible to specify the ServiceTarget as part >> of the definition/ registration, thereby not requiring it to >> appear in the ServiceRequest associated with a URN and probably >> prohibiting it there". If that is true, it is wonderful. But >> I'm trying to avoid a requirement to prove such statements about >> "all NIDs" rather than particular NIDs or, e.g., NIDs that might >> sensibly be used in the library community. At least up to now, if URNs in a namespace X are resolvable, then the namespace registration request for X must explain how the resolution takes place in practice. If the identifier is dumb (non-semantic), the explanation is simple - there can only be one resolver. ISSN is an example of this. If the identifier is semantic, then there can be 1-n resolution services. In these identifiers, NSS contains a hint which will assist Resolver Discovery Service to locate the correct resolver. For instance, any NBN starting with fi: will be resolved in Finland; likewise for any ISBN-13 starting by 978-951 or 978-952. For the time being, ServiceTarget is hardcoded in HTTP URIs: http://urn.fi/URN:ISBN:978-952-10-9989-2 but when RDS is implemented, the beginning of the ISBN will indicate the location of the ServiceTarget. However, there are at least two valid use cases for ServiceTarget: dumb identifiers with multiple resolvers, and need to override the default ServiceTarget. For instance, URN:ISNI (International Standard Name Identifier) will normally be resolved in the ISNI database (http://isni.oclc.nl), but if there is a need to resolve an ISNI in the national authority database, that can be achieved by ServiceTarget, which could be an additional parameter in query (or whatever the ServiceRequest is called). >>>> Two URNs should be considered to be equivalent if they >>>> identify the same thing. >>> Yes, and this depends on your definition of "thing"... >> Indeed. And I'm essentially suggesting that, in the general >> case, we don't know how to define "thing" except on a >> per-namespace (NID-dependent) basis. In DOI context, they call the thing "referent"; particular object identified by a DOI name. Object is an entity within the scope of the DOI system that can be digital, physical or abstract. Likewise, we can say that "thing" is a resource identified by a URN. And the resource is a digital, physical or abstract entity within a scope of a URN namespace (for instance, a book which is in the scope of the ISBN namespace). Abstract entities are for instance works like Shakespeare's "Hamlet". We can of course invent our own definitions to "thing", but IMO different persistent identifier systems should not become too diverse in this respect, because that would have a negative impact on interoperability. There is a chance that DOIs will be expressed as URNs in a future (or vice versa). >> I believe there may be >> categories of namespeaces (and NIDs) that would share >> thing-definitions but we haven't even begun to talk about such >> categories, much less their definitions and properties. >> However, I think we can demonstrate that the differences exist >> just by looking at the differences in starting point, language, >> and assumptions between Juha and Dale -- both of whom, I'm >> convinced are acting in good faith and with a good understanding >> to the problems they need to solve for their communities. I hope that the differences can be overcome by making the definition abstract enough. Since in the end of the day the scope of the URN system is the sum of the scopes of all URN namespaces, we need to make sure that the definition does not become a Procrustean bed. >> >>> ... >>>> ...because neither fragment nor query are part of the NSS. >>> In my eyes, that is not a strong enough argument since that is >>> obvious from the syntax urn:nid:nss?query#fragment. We need an >>> explicit statement that says that "for identification >>> purposes, the URN ends after the last character of the NSS. >>> This implies that while a generic URI parser would consider >>> the two URIs urn:example:foo and urn:example:foo?bar#baz two >>> different URIs and thus -- without further knowledge -- >>> identifying two different resources, a URN parser would treat >>> them as equivalent." (Or something along those lines, which I >>> cannot find in 2141bis). I also suggest that rfc 2141bis adds >>> some examples with queries and fragments to §6.1. Yes, it is important to make it absolutely clear that although according to RFC 3986 the two URIs above identify different things, then from URN point of view the resource they identify is the same, although resolving them may provide different results. Juha -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Thu Jul 3 11:54:32 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB30E1B2983 for ; Thu, 3 Jul 2014 11:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham 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 WB7XU_yOnDRP for ; Thu, 3 Jul 2014 11:54:28 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 45AF11A0359 for ; Thu, 3 Jul 2014 11:54:27 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta13.westchester.pa.mail.comcast.net with comcast id MtyT1o0020cZkys5DuuSaK; Thu, 03 Jul 2014 18:54:26 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta10.westchester.pa.mail.comcast.net with comcast id MuuR1o0091KKtkw3WuuR8U; Thu, 03 Jul 2014 18:54:26 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s63IrIYR027925 for ; Thu, 3 Jul 2014 14:53:18 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s63IrIWC027924; Thu, 3 Jul 2014 14:53:18 -0400 Date: Thu, 3 Jul 2014 14:53:18 -0400 Message-Id: <201407031853.s63IrIWC027924@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: urn@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1404413666; bh=GHCDiLRxGivCYO4NBFvr4VS4GLVl2k/hs8jscqLOyFA=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=lmJh8V2r5MBvVXrdCSAh0E53kX27JDlJYXsGOiR2Ya3zJuomlJqg3alAMuykpA0uE CllJzIIfwSKHnS0vp6QnDVKdXuDXcRpKrDftR5qFKwzmzqa+22c1vN//yR3NXbZLtw /i3BVi/BFXJDNI5jFsc9Vg32YWt5IsiKxvgABahh3rQXxrfS5O5VTNn4lnz12RddLE 1tBfF8sKrvPh4WGgtHf4W7PdKiznN6lvU7SG8JCf/aiMHnEWusaZdf8bOgrCtKJcy3 tr1rrxfL+5YULdj16Q8RWsP/8gpSAJ0m53Tt8LF6ivgAnxQ9fkzgSyvmzyohrisGtn HqPYSQHd+AESg== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/vjFJaDKQLr3c2krkhFffVbugQvc Subject: [urn] Some observations to add to the discussion X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 18:54:30 -0000 I was thinking about the question of "fragments" and URNs and realized that we already use them: Dante's Inferno, Canto XXV As was stated in that W3C document that someone referred to, what makes this work as a fragment reference is that all manifestations of the resource resolve the fragment identifier to the semantically equivalent "part" of the resource. (Regardless of what language it has been translated to!) Which led me back to realizing that we now identify parts of scholarly works by page numbers because of printing -- the work exists in a vast number of copies that place the words on the pages in the same way. Back in the manuscript era, a page number was not consistent from copy to copy, only chapter and section identifiers. In fact, with printing, we get to the point where we don't give names to individual copies; we only give ISBNs to entire editions of a work, because the individual copies are interchangeable for almost all purposes. In regard to rebuilld the syntax of URNs from scratch, I can understand why one would want to do that. But there is no reason we can't embed URNngs as a NID of URNs (assuming that they're a sequence of Unicode characters) by generous use of %-escapes: urn:ng:%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx. That doesn't provide anything other than making them "syntactically interoperable" with existing URIs, but syntactic interoperability is a desirable feature. Dale From nobody Thu Jul 3 23:34:56 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45D01B2C01; Thu, 3 Jul 2014 23:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 3CebZzWHKjv4; Thu, 3 Jul 2014 23:34:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FF91B2BB6; Thu, 3 Jul 2014 23:34:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704063452.22636.71023.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 23:34:52 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/IWA1PZc6tcUSm4MHbq4j4ycy0Ow Cc: urn@ietf.org Subject: [urn] I-D Action: draft-ietf-urnbis-urns-are-not-uris-01.txt X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 06:34:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names, Revised Working Group of the IETF. Title : Names are Not Locators and URNs are Not URIs Author : John C Klensin Filename : draft-ietf-urnbis-urns-are-not-uris-01.txt Pages : 12 Date : 2014-07-03 Abstract: Experience has shown that identifiers associated with persistent names are quite different from identifiers associated with the locations of objects. This is especially true when such names are are expected to be stable for a very long time or when they identify large and complex entities. In order to allow Uniform Resource Names (URNs) to evolve to meet the needs of the Informational Sciences community and other users, this specification separates the syntax for URNs from the generic syntax for Uniform Resource Identifiers (URIs) specified in RFC 3986, updating the latter specification accordingly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-urns-are-not-uris/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-urnbis-urns-are-not-uris-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-urns-are-not-uris-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 3 23:41:46 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25A71B2C01 for ; Thu, 3 Jul 2014 23:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 2yJHG1NmwCnu for ; Thu, 3 Jul 2014 23:41:36 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC96E1B2C07 for ; Thu, 3 Jul 2014 23:41:30 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1X2x8T-0007vS-Qn for urn@ietf.org; Fri, 04 Jul 2014 02:38:17 -0400 Date: Fri, 04 Jul 2014 02:41:21 -0400 From: John C Klensin To: urn@ietf.org Message-ID: <0A6681C7A656E38E8CCFF8A4@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/tT1bg0bB7rGUYvoDd-YVauvj32s Subject: [urn] New urns-are-not-uris draft X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 06:41:41 -0000 Hi. I just posted a new version of draft-ietf-urnbis-urns-are-not-uris. Changes are listed in Appendix C of the draft but, basically, there is nothing new in it that has not already been discussed on-list. Considerable text (including Appendices A and B) and a new Section 2 have been copied from list discussions (and lightly edited) in the hope of drawing material together and helping to focus discussion in Toronto. Much of that material should come back out, as indicated in the text, so it is probably not worthwhile to spend time wordsmithing it unless that is needed to improve clarity of discussions. john p.s. Don't bother reporting "Appendix Appendix A" (or "B") if you happen to notice it. XML2RFC ticket #266. From nobody Fri Jul 4 03:38:07 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780511B2CD7 for ; Fri, 4 Jul 2014 03:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 p58zy25lPQkW for ; Fri, 4 Jul 2014 03:38:02 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F5AF1B2CF8 for ; Fri, 4 Jul 2014 03:37:56 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s64Abreu024993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 4 Jul 2014 13:37:54 +0300 Message-ID: <53B68401.1070601@helsinki.fi> Date: Fri, 04 Jul 2014 13:37:53 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: urn@ietf.org References: <201407031853.s63IrIWC027924@hobgoblin.ariadne.com> In-Reply-To: <201407031853.s63IrIWC027924@hobgoblin.ariadne.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/znOAEGBjQ5i_8yTMy0aB2l79CMQ Subject: Re: [urn] Some observations to add to the discussion X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 10:38:04 -0000 Hi, On 3.7.2014 21:53, Dale R. Worley wrote: > I was thinking about the question of "fragments" and URNs and realized > that we already use them: > > Dante's Inferno, Canto XXV These are what we have called logical fragment in the URNBIS (and component parts in libraries). We have agreed earlier that URN namespaces may have their own principles of identification regarding the logical fragments. For instance, ISBN system allows assignment of ISBNs to logical fragments if they are for sale inedividually. Physical fragments (encoding of the document) may or may not have anything to do with the logical structure of the document. Inferno can be published as text file with no structure in it (see http://www.gutenberg.org/files/1001/1001-h/1001-h.htm). Component parts are essential in description of e.g. music and journals. And there can be more than two levels. A journal has volumes, issues and articles, and articles may have e.g. images that should be described independently. > > As was stated in that W3C document that someone referred to, what makes > this work as a fragment reference is that all manifestations of the > resource resolve the fragment identifier to the semantically > equivalent "part" of the resource. (Regardless of what language it > has been translated to!) > > Which led me back to realizing that we now identify parts of scholarly > works by page numbers because of printing -- the work exists in a vast > number of copies that place the words on the pages in the same way. > Back in the manuscript era, a page number was not consistent from copy > to copy, only chapter and section identifiers. The Bible (or Quran) are also good examples of resources where page numbers are still not used in references. There are so many editions and translations that my pages most likely would not be the same as yours. So far, many e-books are faithful copies of printed ones in PDF or some other suitable file format. But new formats like EPUB 3 - in which layout will change depending on whether the reader uses a PC, tablet, mobile or something else - mean that before long it may not make sense to talk about pages any more, and it may be necessary to go back to the old practice of encoding the logical structure of the work into the document itself in much greater detail that we have been doing lately. > > In fact, with printing, we get to the point where we don't give names > to individual copies; we only give ISBNs to entire editions of a work, > because the individual copies are interchangeable for almost all > purposes. Actually, ISO TC 46 is currently developing International Standard Item Identifier, because sometimes it is important to identify a single copy (or, in library slang, item). A library may own for instance the copy of Arithmetica containing Pierre Fermat's comment about The Last Theorem (alas, that copy has small margins). There is definitely a need to be able to identify that copy from any other copy of the book even though the actual proof of the theorem is not included and was only provided by Andrew Wiles a few years after Fermat made his remark. Old books are often unique in the sense that all copies are different. When libraries, Google, Microsoft etc. digitize them, it is a good idea to indicate which copy has been used as the source. Juha > > In regard to rebuilld the syntax of URNs from scratch, I can > understand why one would want to do that. But there is no reason we > can't embed URNngs as a NID of URNs (assuming that they're a sequence > of Unicode characters) by generous use of %-escapes: > urn:ng:%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx. That doesn't provide > anything other than making them "syntactically interoperable" with > existing URIs, but syntactic interoperability is a desirable feature. > > Dale > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Sat Jul 5 19:14:47 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7012F1A0108 for ; Sat, 5 Jul 2014 19:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 NObHnjJAXfZe for ; Sat, 5 Jul 2014 19:14:44 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (dns-bn1lp0143.outbound.protection.outlook.com [207.46.163.143]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C23E51A00B9 for ; Sat, 5 Jul 2014 19:14:43 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) with Microsoft SMTP Server (TLS) id 15.0.980.8; Sun, 6 Jul 2014 02:14:40 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0980.000; Sun, 6 Jul 2014 02:14:40 +0000 From: Larry Masinter To: John C Klensin , "urn@ietf.org" Thread-Topic: [urn] New urns-are-not-uris draft Thread-Index: AQHPl1MjyKv2cugJgUCi8Vr0hrOvBZuSDqUQ Date: Sun, 6 Jul 2014 02:14:38 +0000 Message-ID: <6cedc3e56c534419a34fc516f732adb0@BL2PR02MB307.namprd02.prod.outlook.com> References: <0A6681C7A656E38E8CCFF8A4@JcK-HP8200.jck.com> In-Reply-To: <0A6681C7A656E38E8CCFF8A4@JcK-HP8200.jck.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0264FEA5C3 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(33646001)(561944003)(83322001)(81342001)(66066001)(50986999)(74502001)(74316001)(101416001)(54356999)(64706001)(76176999)(76576001)(2656002)(74662001)(86362001)(31966008)(92566001)(87936001)(81542001)(4396001)(107046002)(107886001)(85306003)(106116001)(106356001)(99286002)(77982001)(79102001)(95666004)(20776003)(83072002)(85852003)(46102001)(99396002)(80022001)(21056001)(105586002)(76482001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB307; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/urn/59VaT83We77qeFDWQMSdn6Hl4O4 Subject: Re: [urn] New urns-are-not-uris draft X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 02:14:46 -0000 Right now, we have the category of strings that are URIs, which start with = something:, of which some start with 'urn:' and some don't. The ones that s= tart with 'urn:' we say are URNs. The ones that start with 'something-else:= ' we say are URLs. The proposal is to secede from this union and say "no, no more unifying", s= ome strings are URNs (and start with 'urn:'? ) and other strings are URLs. But there are existing systems that accept either -- XML namespaces are dep= loyed that use 'urn:' URNs and others use 'http:" URLs. We'd have to make u= p a new kind of union category 'either URN OR URL'. If you called that union 'URI' we'd be back where we started. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D It isn't true that ISBN numbers never change. They change rarely, perhaps. = A primary use of ISBN was as bookstore stock and pricing unique key. So if= a book is printed with multiple color covers, they might use the same ISBN= number. New printing, perhaps a minor printing flaw fixed, ditto. The perm= anence and meaning of this kind of identification for documents will change= even further. Not every blog post gets its own identifier, with many infor= mation tools, 'location' is meaningless. You may think this is a minor poin= t or these are corner cases, but I think they're central. The well-ordered = world wished for isn't there. The document consistently attributes to "all URIs" properties that are only= true of a few URI schemes. There are plenty of name-like URLs that are not= URNs, tag:, data:, uuid: and many others. Comments linked to the text: # 1. Introduction The names of categories of identifiers "name-type" and "location-based" are= design concept ideas and not properties of the identifiers themselves.=20 # "Impractical to constrain URNs to syntax and high-level semantics of URLs= "=20 What constraints there are can changed without seceding URNs from the URI = union. As far as I can tell, the only syntactic changes wanted is to allow = "#" for fragments and "/" for hierarchy. If this is necessary it might requ= ire an update. # "Generalization ... has failed ..." I don't see any use cases where splitting URNs from URIs reduces failure. I= f there are failures, they are intrinsic. # "... are simply different creatures ..."=20 The boundary between locator and name is completely blurred and there are e= ndless examples where the pun is a fundamental feature: that the same URI f= unctions as a name in some contexts and a location in others. XML namespac= es are a clear instance where both http and urn URIs are used uniformly. # Giving location information a role in identification ...force libraries t= o adopt different policies for printed and digital material Digital material is massless. Of course libraries need different policies. = This has nothing to do with URNs. BTW, this is the first mention of libraries, what do you mean by the term, = where did they come from, and what are their requirements? # "Let us assume that ten people independently upload a copy # of an electronic book into different locations in the Web. Are all # these ten URLs valid identifiers of the book?" If you ask "is A an accurate identifier for B" the answer is "no": the only= accurate identifier for what B identifies is B, everything else is identif= ies differently.=20 If you asked "can any of these ten URLs be used as an identifier for B", ye= s, can be. If you want a system of generating IDs and embedding them into digital mate= rial,=20 I'd recommend looking at XMP (eXtensible Metadata Platform) which embeds=20 a GUID-based InstanceID and DocumentID in each file or compound file collec= tion as an example of locationless identifier. Ten people generate online material from a paper book: then all are differe= nt, related Documents, they're not interchangeable for all document purposes. Relation to ISBN and other info such as title? The ordinary one, ISBN, titl= e, etc Are additional metadata, linked by a wide variety of mechanisms.=20 1. ".. managed process .. A user cannot determine whether some URI is relia= ble or not" You need clarify what you mean for a URI/URL/URN to be "reliable". URNs ca= n fail (even National Libraries can fail when nations fail), URLs can be very long lived ("data:"). From nobody Sat Jul 5 20:11:53 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD951A0145 for ; Sat, 5 Jul 2014 20:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no 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 7tmrZcINiw4s for ; Sat, 5 Jul 2014 20:11:49 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F15A71A0140 for ; Sat, 5 Jul 2014 20:11:48 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB308.namprd02.prod.outlook.com (10.141.91.24) with Microsoft SMTP Server (TLS) id 15.0.954.9; Sun, 6 Jul 2014 03:11:47 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0980.000; Sun, 6 Jul 2014 03:11:47 +0000 From: Larry Masinter To: "Svensson, Lars" , John C Klensin , "Dale R. Worley" , =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= Thread-Topic: RE: IETF does protocol design, not philosophy Thread-Index: Ac+QewoGNASAjxrCRXyJB3v4Nyx7GgISATdA Date: Sun, 6 Jul 2014 03:11:45 +0000 Message-ID: <033582c898b345bfba1e66d1df72a4c7@BL2PR02MB307.namprd02.prod.outlook.com> References: <24637769D123E644A105A0AF0E1F92EFA445E4C5@dnbf-ex1.AD.DDB.DE> In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA445E4C5@dnbf-ex1.AD.DDB.DE> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0264FEA5C3 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51704005)(199002)(189002)(92566001)(99286002)(83072002)(54356999)(81542001)(86362001)(74662001)(74502001)(66066001)(80022001)(31966008)(551934003)(83322001)(64706001)(81342001)(105586002)(79102001)(21056001)(4396001)(76176999)(85306003)(2656002)(20776003)(77982001)(95666004)(99396002)(46102001)(107046002)(50986999)(74316001)(85852003)(101416001)(76482001)(106356001)(33646001)(87936001)(76576001)(2171001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB308; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/urn/lnOTFX6uVigz2imlaRY_SU5VIEc Cc: "urn@ietf.org" Subject: Re: [urn] IETF does protocol design, not philosophy X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 03:11:51 -0000 > > I meant "protocol" in the broad sense. I can't think of > > any use cases that do not involve protocols. UR*'s > > are strings to be used in protocols, and any use > > that doesn't involve a communication is out of scope: > > for discussion of UR* uses, for this working group, for > > the IETF. > My reading of this is that a URI (in the sense of a string conforming to > the URI syntax as specified in RFC 3986 *and* using one of the registered > URI schemes [1]) can be used as both an 'indicator' and 'for retrieval', > but that you say that if you cannot use it 'for retrieval', it should be = out > of scope for IETF. Have I understood that correctly? Not what I meant. I just meant that you should use Shanon=20 information theory terminology rather than philosophy of language when talking about 'identifiers', if you're writing for the IETF. It's a terminology and perspective issue. > > My point is that the answer is the same whether the context > > is English email or HTML or any other protocol: no one can > > know for certain what Alice intended by the UR*, the > > ambiguity is intrinsic, no amount of words in RFCs will > > change that. If there is to be any disambiguation, it has > > to be carried out of band or elsewhere in the protocol. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > But there are plenty of examples of registered URI schemes that are not > specifying resolution or usage in protocols. Some examples: > 1) geo: (RFC 5870) explicitly says that I think you missed the point. Where is a 'geo:' URI *used*. Every URI Is used in a context. The context might be this Restaurant Review Protocol conversation: Q1: "tell me about restaurants in Toronto" A2: "Here's a good one XX" Q3: "Where is XX?" A4: "Here it is 'geo:blahblah' Now, why are they using 'geo:blahblah' instead of 'blahblah'? Presumably because at step A4 could could have a pointer to some other way of describing where the restaurant was. =20 > Data contained in a 'geo' URI identifies a physical resource: a > spatial location identified by the geographic coordinates and the CRS > encoded in the URI. (=A73.4) Sure, that's fine. The reason you leave the flexibility in the space. But you don't have to solve philosophical questions ("do geo locations track plate tectonics") unless they're important for reliable working of the protocols that use them. > 3) data: (RFC 2397) (I invented this one) =20 > To me, this seems very similar to the URN scenario, where the resolution > protocol is not part of the UR* scheme, but we rely on external > resolution services that may or may not be authoritative. There's some kind of conflict between saying that you rely on a service but the service is not 'authoritative'. I think because I think 'authoritative' must always come with a 'to whom'. If you rely on the service, it is authoritative to you. If you use it but don't trust it completely, then it's not any more authoritative than a HTTP proxy cache. =20 > > > In particular, Alice may want > > > to inquire whether a URN with a particular NID and NSS exists in > > > some data structure or transaction and then take an action on > > > that basis that is indicated by the URN but that has nothing to > > > do with communicating the URN to Bob or otherwise executing or > > > resolving it. > > > > I don't understand. How did Alice get the URN? And how > > did the creator of the data structure or transaction > > get the URN? >=20 > A colleague of hers sent her an email with an attachment. The > attachment turned out to be a document and on the first page of that > document a URN identifying that document was printed. So the URN has been communicated to Alice in the context That the document author intended people who retrieved the document and printed it would see the URN. The communicating parties are the document author and Alice's colleague and Alice.=20 > > I'd say that if there is no communication path that passes > > the UR* as an opaque string, then you don't have a URI or > > URL or URN, you just have a string that looks like one and > > we have nothing to say because it doesn't matter what > > we say. >=20 > Of course we cannot know if urn:uuid:6e8bc430-9c3a-11d9-9669- > 0800200c9a66 actually is a URN, but since it starts with urn:, a qualifie= d > guess would be that it is one and a user with knowledge of that would > try to use it as such. I agree, the question 'is this actually a URN' is meaningless.=20 > Can you please elaborate a bit on which part the link types would play in > a URN resolution scenario? I admit I don't quite grasp that... I think the scenario is prior to 'URN resolution'. You are given a UR* (urn, url, uri). You ask 'is this for retrieval or is it for identity without retrieval'. Put the answer in a 'link type'. The other possible link types will also be useful. From nobody Sun Jul 6 09:44:02 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545B51A0643 for ; Sun, 6 Jul 2014 09:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.796 X-Spam-Level: X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 jLre7gUMPCJE for ; Sun, 6 Jul 2014 09:43:58 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E401E1A0640 for ; Sun, 6 Jul 2014 09:43:57 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1X3pUP-000DXS-B3; Sun, 06 Jul 2014 12:40:33 -0400 Date: Sun, 06 Jul 2014 12:43:53 -0400 From: John C Klensin To: Larry Masinter , urn@ietf.org Message-ID: <11D4E145F435FE3C28C30408@[192.168.1.128]> In-Reply-To: <6cedc3e56c534419a34fc516f732adb0@BL2PR02MB307.namprd02.prod.outlook.com> References: <0A6681C7A656E38E8CCFF8A4@JcK-HP8200.jck.com> <6cedc3e56c534419a34fc516f732adb0@BL2PR02MB307.namprd02.prod.outlook.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/uf9rX8lfEAij1HPjaKVgU8a8W8c Subject: Re: [urn] New urns-are-not-uris draft X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 16:44:00 -0000 --On Sunday, 06 July, 2014 02:14 +0000 Larry Masinter wrote: > Right now, we have the category of strings that are URIs, > which start with something:, of which some start with 'urn:' > and some don't. The ones that start with 'urn:' we say are > URNs. The ones that start with 'something-else:' we say are > URLs. Some say they are URLs. Others say that, e.g., strings that start with "SIP:" are just a different type of URI -- neither URNs nor URLs. I note that the RFCs are written in a way that doesn't make "SIP:..." a URL; they just leave the question open. The separation draft doesn't change that. > The proposal is to secede from this union and say "no, no more > unifying", some strings are URNs (and start with 'urn:'? ) and > other strings are URLs. (or still "generic URIs".) > But there are existing systems that accept either -- XML > namespaces are deployed that use 'urn:' URNs and others use > 'http:" URLs. We'd have to make up a new kind of union > category 'either URN OR URL'. If the code doesn't change, nothing else changes either. "Have to" is a little bit of a strange term in this context. If, in practice, their code implemented PHB's definition of a URI, i.e., method: rather than the 3986 definition, then nothing would change. If the code really understood only "http:" URLs and 2141 URNs, then "SIP:" doesn't work and any replacement to 2141 would involve changing the code. > If you called that union 'URI' we'd be back where we started. No, we wouldn't, and that is exactly the point. If one had that situation and called the union of "http:" URLs, other kinds of USLs, other kinds of what are now called URIs, and URNs "URI", we'd be an a state where the semantics (and syntax, but that is a tad less important) of 3986 didn't constrain non-HTTP URIs. We would _just_ have a generic term. Let me a bit more clear about one thing. I really don't like kludges like Dale's proposal for extensive use of %. I think they are ugly, hard to understand and debug, and an invitation to future trouble especially in the absence of _very_ careful implementations. But, if 3986 were free of explicit and implicit semantic constraints, I'd probably be arguing to living with it just to avoid making disruptive changes. However, those semantic constraints and terminology are in place and _something_ is needed to allow the perceived needs of legitimate and experience communities to be accommodated. Since some changes --starting with either a separation or, as Lars effectively suggested, revising and updating 3986 to take the semantics and over-specific terminology out -- are needed, I think it is worth at least asking the question of whether we can create a URN specification that is kludge-free and that, consequently, has a better expectation for a long lifetime than it might otherwise. > =============== > It isn't true that ISBN numbers never change. They change > rarely, perhaps. A primary use of ISBN was as bookstore stock > and pricing unique key. So if a book is printed with multiple > color covers, they might use the same ISBN number. New > printing, perhaps a minor printing flaw fixed, ditto. The > permanence and meaning of this kind of identification for > documents will change even further. Based on reading the standard (have you done that?) and a few discussions with the registration agency, I think your interpretation above is wrong or at least misleading. But that is not an area where I claim expertise so I'll let others debate it with you if they are so inclined. A few of your comments below been elided. I hope others with more in-depth expertise will respond to them, especially if they believe the topics have not been adequately covered already. In particular, your excerpts from what is now Section 3 are about text for which Juha provided that starting point and that has been, IMO, extensively discussed on-list. If he tells me that I misinterpreted his intent, I will be happy to revise as needed (also, of course, if Andrew tells me the WG consensus is different). But, unless you are ready to engage with his position, and, IMO, do so with equal experience and authority, repetition of the same assertions this just leads us in circles. > Not every blog post gets > its own identifier, with many information tools, 'location' is > meaningless. You may think this is a minor point or these are > corner cases, but I think they're central. The well-ordered > world wished for isn't there. I think that may be true but is certainly irrelevant. See above... and Juha's repeated comments about managed processes. > The document consistently attributes to "all URIs" properties > that are only true of a few URI schemes. There are plenty of > name-like URLs that are not URNs, tag:, data:, uuid: and many > others. The "all URIs" problem is a consequence of the language of 3986 (on which I note your name appears) and not the present document. > Comments linked to the text: > ># 1. Introduction > The names of categories of identifiers "name-type" and > "location-based" are design concept ideas and not properties > of the identifiers themselves. > ># "Impractical to constrain URNs to syntax and high-level ># semantics of URLs" > What constraints there are can changed without seceding URNs > from the URI union. As far as I can tell, the only syntactic > changes wanted is to allow "#" for fragments and "/" for > hierarchy. If this is necessary it might require an update. Other changes may be needed - see the document at -01 and the correspondence on the list. More important, my opinion (perhaps wrong) and that of Barry and Pete (unless I've misunderstood) is that there is insufficient energy in the IETF to undertake a 3986bis, or even a substantive and detailed update, and more it to completion in a reasonable amount of time. The separation model is just a pragmatic way to work around that problem without holding the work of the URN WG up for an additional extended period -- and allowing the odds of a fork in the standard by another body that doesn't need to debate these niceties of definition to rise considerably. ># "Generalization ... has failed ..." > I don't see any use cases where splitting URNs from URIs > reduces failure. If there are failures, they are intrinsic. The failure is to come up with a syntax and set of semantics for URNs that meet the perceived needs of the important parts of the URN community without violating the constraints of 3986. I thought that was clear; if not, I apologize and will make another pass through the draft. ># "... are simply different creatures ..." > The boundary between locator and name is completely blurred > and there are endless examples where the pun is a fundamental > feature: that the same URI functions as a name in some > contexts and a location in others. XML namespaces are a clear > instance where both http and urn URIs are used uniformly. See prior comments (above and on the list) about the perceived needs of legitimate and experienced communities. You, of course, get to disagree, but that doesn't seem to affect their perceptions. And, again, the IETF gets to either adapt or risk (I believe "guarantee", but could be wrong) an externally-forked standard. This is not an instance where the IETF gets to say "no, you shouldn't do that, or believe that, so don't" and expect an established community with centuries of experience to pay any attention. >... best, john From nobody Sun Jul 6 12:30:53 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4F91A0A86 for ; Sun, 6 Jul 2014 12:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 Gku_R3uWqfFv for ; Sun, 6 Jul 2014 12:30:49 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75EA31A0A84 for ; Sun, 6 Jul 2014 12:30:49 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) with Microsoft SMTP Server (TLS) id 15.0.980.8; Sun, 6 Jul 2014 19:30:47 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0980.000; Sun, 6 Jul 2014 19:30:47 +0000 From: Larry Masinter To: John C Klensin , "urn@ietf.org" Thread-Topic: credentials Thread-Index: Ac+ZT0q2AiLERSzDSp2SA2oCYCa3bg== Date: Sun, 6 Jul 2014 19:30:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0264FEA5C3 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(243025005)(189002)(199002)(77982001)(99286002)(79102001)(106356001)(20776003)(95666004)(4396001)(229853001)(107046002)(107886001)(85306003)(105586002)(76482001)(21056001)(46102001)(74502001)(83072002)(80022001)(85852003)(99396002)(74316001)(50986999)(64706001)(54356999)(76576001)(101416001)(221733001)(33646001)(83322001)(15975445006)(81342001)(19580395003)(66066001)(86362001)(81542001)(31966008)(74662001)(92566001)(87936001)(15202345003)(2656002)(166393001)(108616002)(24736002)(220243001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB307; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/urn/UOVk8K9McrB-mZEBWfGdPdXxYJg Subject: [urn] credentials X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 19:30:52 -0000 V2UgZG9uJ3QgdXN1YWxseSBnaXZlIGNyZWRlbnRpYWxzIGluIElFVEYgZGlzY3Vzc2lvbnMsICBp ZGVhcyBzaG91bGQgc3RhbmQgb24gdGhlaXIgb3duLg0KDQpTb21lIHJlbGV2YW50IHBhc3Qgd3Jp dGluZ3MgaW4gRGlnaXRhbCBMaWJyYXJ5IGlkZW50aWZpZXJzOg0KDQpTZXB0ZW1iZXIgMTk5OCB0 dXRvcmlhbHMgb24gd2ViIHRlY2hub2xvZ3kgYXQgZGlnaXRhbCBsaWJyYXJ5IGNvbmZlcmVuY2UN Cmh0dHA6Ly9sYXJyeS5tYXNpbnRlci5uZXQvZXVkbC8NCmluY2x1ZGluZyBzb21lIGRpc2N1c3Np b24gb2YgVVJOcw0KaHR0cDovL2xhcnJ5Lm1hc2ludGVyLm5ldC9ldWRsL2V1ZGwtcGFydDNiLnBk ZiNwYWdlPTgyDQpkaXNjdXNzaW9uIGluIDE5OTUgcGFwZXIgZm9yIElORVQnOTUgZGlzY3Vzc2lv biBvZiBpZGVudGlmaWVycw0KaHR0cDovL2xhcnJ5Lm1hc2ludGVyLm5ldC9kb2N3ZWJsaWIuaHRt bCNkb2NpZHMNCg0KRm9yIHRoaXMgZGlzY3Vzc2lvbiwgSSBzdGlsbCBsaWtlIGV3aGF0IEkgc2Fp ZCBpbiAxOTk5DQoiUHJvYmxlbXMgVVJJcyBEb24ndCBTb2x2ZSoNCiogYnV0IHBlb3BsZSB0aGlu ayB0aGV5IHNob3VsZCINCg0KaHR0cDovL2xhcnJ5Lm1hc2ludGVyLm5ldC85OTA5LXR3aXN0LnBk Zg0KDQpJIGhhdmUgYSBmZXcgb3RoZXIgZGlnaXRhbCBsaWJyYXJ5IHBhcGVycyB3aGljaCBzaG91 bGQgZ2l2ZSBtZSBzdWZmaWNpZW50IGNyZWRlbnRpYWxzIHRvIGJlIGFibGUgdG8gYXQgbGVhc3Qg YmUgdGFrZW4gc2VyaW91c2x5IHdoZW4gZGlzY3Vzc2luZyB0aGUgdG9waWNzIG9mIHdoYXQgbGli cmFyaWFucyBkbyBvciBkb24ndCBuZWVkLCBpbiBhIGRpc2N1c3Npb24gb2Ygd2hldGhlciBJRVRG IHNob3VsZCBjaGFuZ2UgaXRzIHN0YW5kYXJkcyB0byBtZWV0IHRob3NlIG5lZWRzLg0KDQpMYXJy eQ0KLS0NCmh0dHA6Ly9sYXJyeS5tYXNpbnRlci5uZXQNCg0K From nobody Sun Jul 6 13:13:39 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BCD1A0A9A for ; Sun, 6 Jul 2014 13:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.796 X-Spam-Level: X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=no 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 Gv8N8HUIbwSc for ; Sun, 6 Jul 2014 13:13:35 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B4D81A0A95 for ; Sun, 6 Jul 2014 13:13:35 -0700 (PDT) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1X3slH-000Dsw-Bg; Sun, 06 Jul 2014 16:10:11 -0400 Date: Sun, 06 Jul 2014 16:13:32 -0400 From: John C Klensin To: Larry Masinter , urn@ietf.org Message-ID: <78D776B5A39D58B5A4216942@[192.168.1.128]> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/JtkO9qzfDdzvCCcsXwJBYXd-uCA Subject: Re: [urn] credentials X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jul 2014 20:13:37 -0000 --On Sunday, 06 July, 2014 19:30 +0000 Larry Masinter wrote: > We don't usually give credentials in IETF discussions, ideas > should stand on their own. > > Some relevant past writings in Digital Library identifiers: > > September 1998 tutorials on web technology at digital library > conference http://larry.masinter.net/eudl/ > including some discussion of URNs > http://larry.masinter.net/eudl/eudl-part3b.pdf#page=82 > discussion in 1995 paper for INET'95 discussion of identifiers > http://larry.masinter.net/docweblib.html#docids >... Larry, I wasn't (and am not) trying to start a credentials fight. At the same time, I've trying really hard to avoid getting bogged down in discussions that start from "I have an idea and, because I have it, it is at least as valid as your idea" and go downhill from there. As I said in Appendix A of the draft (which I hope you have, or will, read), what is ultimately at issue here is not whether you, or Juha (or the community from which he comes) are "correct". The issue is whether, based on their experience, their perceived needs should be accommodated. I started to say "are entitled to be accommodated", but that isn't ultimately the point either. Instead, if they feel strongly enough about those needs --and the WG has heard from far more than Juha, with people and institutions of multiple varieties based on multiple countries (and I've heard even more) to at least entertain a strong hypothesis that they do-- will they move off to create a standard of their own if the IETF says, e.g., "no, we, based on the ideas of Larry or others, don't believe you need to do that". I'm convinced that they will and am a bit surprised they haven't done so already (Juha and others have been exerting superhuman efforts to avoid that outcome). YMMD, but I'm convinced that the costs of two inconsistent definitions of "URN" would be sufficiently high that it trumps the claimed advantages of trying to preserve an overarching RFC 3986. While the issues are completely separate from the URN one, the view that preservation of 3986 and its current definitions across the whole range of whatever people choose to call URIs is not worth shedding blood over (or even further constraining URNs or slowing URNbis over) is somewhat reinforced by efforts in W3C and WHATWG to change the URL definition in ways that, to me, also look incompatible with 3986. best, john From nobody Mon Jul 7 01:15:48 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F341B279F for ; Mon, 7 Jul 2014 01:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.457 X-Spam-Level: * X-Spam-Status: No, score=1.457 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=no 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 Iejx9sT_xaId for ; Mon, 7 Jul 2014 01:15:45 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id D050C1B27A6 for ; Mon, 7 Jul 2014 01:15:44 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id CCE6932E02B; Mon, 7 Jul 2014 17:15:40 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 1a6e_9993_4d01cdb7_7c82_47d7_9ba9_8db2c82ea1f7; Mon, 07 Jul 2014 17:15:40 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 0AD51BF4E7; Mon, 7 Jul 2014 17:15:40 +0900 (JST) Message-ID: <53BA571B.9080909@it.aoyama.ac.jp> Date: Mon, 07 Jul 2014 17:15:23 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Dale R. Worley" , urn@ietf.org References: <201407031853.s63IrIWC027924@hobgoblin.ariadne.com> In-Reply-To: <201407031853.s63IrIWC027924@hobgoblin.ariadne.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/vzHGB2GMR-Qpyn7Fxtw1MG2mDtY Subject: Re: [urn] Some observations to add to the discussion X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 08:15:46 -0000 Hello Dale, On 2014/07/04 03:53, Dale R. Worley wrote: > In regard to rebuilld the syntax of URNs from scratch, I can > understand why one would want to do that. But there is no reason we > can't embed URNngs as a NID of URNs (assuming that they're a sequence > of Unicode characters) by generous use of %-escapes: > urn:ng:%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx. That doesn't provide > anything other than making them "syntactically interoperable" with > existing URIs, but syntactic interoperability is a desirable feature. Can you give a more specific example? Some people seem to get scared when they see that many % signs. Of course in URI form, non-ASCII characters will have to be escaped with %HH. But I don't see a need to do that for US-ASCII characters or in an IRI form. Regards, Martin. From nobody Mon Jul 7 02:05:10 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487A31B27F5 for ; Mon, 7 Jul 2014 02:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.958 X-Spam-Level: X-Spam-Status: No, score=0.958 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=no 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 3GBIC7VHTaYn for ; Mon, 7 Jul 2014 02:05:08 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 60E3D1B27F4 for ; Mon, 7 Jul 2014 02:05:08 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 7E36832E53B; Mon, 7 Jul 2014 18:05:07 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 1a6e_b131_97d55de0_1efe_4282_9096_fbb97ef08423; Mon, 07 Jul 2014 18:05:06 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id A4ADFBF537; Mon, 7 Jul 2014 18:05:06 +0900 (JST) Message-ID: <53BA62B1.3090206@it.aoyama.ac.jp> Date: Mon, 07 Jul 2014 18:04:49 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Juha Hakala , "Svensson, Lars" , John C Klensin , "Dale R. Worley" References: <24637769D123E644A105A0AF0E1F92EFA445E513@dnbf-ex1.AD.DDB.DE> <53ABD826.20606@helsinki.fi> In-Reply-To: <53ABD826.20606@helsinki.fi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/JHNSudQtT1ziuVp047Pv1R2nqKY Cc: "urn@ietf.org" Subject: [urn] Queries and service requests (was: Re: urn:ietf:rfc) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 09:05:09 -0000 Hello Juha, On 2014/06/26 17:21, Juha Hakala wrote: > Using URI query for passing ServiceRequests looks like an attractive > option with minimal technical overhead. Whether this kind of use of > query would be confusing, and whether using some other mechanism would > make things more clear I can't tell, before seeing more detailed > proposal on how to proceed. Very good point. I would indeed also like to see more specific proposals. Are there any around? > Like Lars, I wonder if the intention is to > drop just the word query, or the syntax as well. Who's intention are you speaking about? According to John, it's people like you who know what they need, so what would be your preference? Regards, Martin. From nobody Mon Jul 7 04:11:56 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2421D1B2823 for ; Mon, 7 Jul 2014 04:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.258 X-Spam-Level: ** X-Spam-Status: No, score=2.258 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=no 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 Eoe5yf5hBXRg for ; Mon, 7 Jul 2014 04:11:53 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6FF1B2822 for ; Mon, 7 Jul 2014 04:11:53 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 65AA432E02B; Mon, 7 Jul 2014 20:11:51 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 1a68_8c10_8446486e_a753_4163_8583_492dd3599973; Mon, 07 Jul 2014 20:11:50 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 6F994BFF77; Mon, 7 Jul 2014 20:11:50 +0900 (JST) Message-ID: <53BA8065.1040609@it.aoyama.ac.jp> Date: Mon, 07 Jul 2014 20:11:33 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Juha Hakala , urn@ietf.org References: <201407031853.s63IrIWC027924@hobgoblin.ariadne.com> <53B68401.1070601@helsinki.fi> In-Reply-To: <53B68401.1070601@helsinki.fi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/FoKXTE_GVxKUMUzBjuLPKYOmrZ0 Subject: Re: [urn] Some observations to add to the discussion X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 11:11:55 -0000 On 2014/07/04 19:37, Juha Hakala wrote: > So far, many e-books are faithful copies of printed ones in PDF or some > other suitable file format. But new formats like EPUB 3 - in which > layout will change depending on whether the reader uses a PC, tablet, > mobile or something else - mean that before long it may not make sense > to talk about pages any more, and it may be necessary to go back to the > old practice of encoding the logical structure of the work into the > document itself in much greater detail that we have been doing lately. My understanding is that *most* ebook formats these days don't show pages the same way they are printed in books, but that some of them have features indicating the page numbers of "real pages", which may be in the middle of a displayed page. One reason is that e-ink doesn't yet have such a high resolution. Regards, Martin. From nobody Mon Jul 7 04:23:13 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71951B2824 for ; Mon, 7 Jul 2014 04:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 1_7utGsW4onZ for ; Mon, 7 Jul 2014 04:23:08 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97A001B2815 for ; Mon, 7 Jul 2014 04:23:08 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) with Microsoft SMTP Server (TLS) id 15.0.980.8; Mon, 7 Jul 2014 11:23:06 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0980.000; Mon, 7 Jul 2014 11:23:06 +0000 From: Larry Masinter To: John C Klensin , "urn@ietf.org" Thread-Topic: draft-ietf-urnbis-urns-are-not-uris Thread-Index: Ac+ZzyfxHiJEAU+/QRWHcs/czVl5ng== Date: Mon, 7 Jul 2014 11:23:06 +0000 Message-ID: <63b1c5b67c0f4ea3bfc7b7e873945809@BL2PR02MB307.namprd02.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02652BD10A x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(79102001)(95666004)(99286002)(77982001)(21056001)(83072002)(20776003)(107046002)(107886001)(85306003)(4396001)(106356001)(76482001)(105586002)(85852003)(46102001)(99396002)(74502001)(80022001)(74316001)(50986999)(64706001)(54356999)(76576001)(101416001)(561944003)(33646001)(83322001)(15975445006)(81342001)(19580395003)(66066001)(86362001)(81542001)(87936001)(2656002)(15202345003)(19625735002)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB307; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/urn/eDoxzYgi1dl1vSxOBSS3LccVR7A Subject: [urn] draft-ietf-urnbis-urns-are-not-uris X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 11:23:11 -0000 aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FwcHMtZGlzY3Vzcy9jdXJyZW50 L21zZzEyMDcwLmh0bWwNCiJ3ZSdkIGxpa2UgdGhlIGRpc2N1c3Npb24gaW4gVG9yb250byB0byBi ZSB0aGUgcmVzb2x1dGlvbiwNCiBub3QgdGhlIHN0YXJ0IG9mIHRoZSBjb252ZXJzYXRpb24uIg0K DQpUaGUgZG9jdW1lbnQgZG9lcyBub3QgZGVzY3JpYmUgdGhlIHByb2JsZW0gZm9yIHdoaWNoIHRo ZQ0KcHJvcG9zYWwgaXMgdGhlIHNvbHV0aW9uLiBJIGJlbGlldmUgdGhlcmUgYXJlIHByb2JsZW1z IHRoYXQgdXJuJ3MNCmFuZCB1cmkncyBkb24ndCBzb2x2ZSwgSSBhY2tub3dsZWRnZSB0aGVyZSBh cmUgcGVvcGxlIGZvcg0Kd2hvbSB0aGVzZSBwcm9ibGVtcyBhcmUgaW1wb3J0YW50LiBJIGFtIG5v dCBjb252aW5jZWQNCnRoYXQgdGhlcmUgYXJlIG5ldyBwcm9ibGVtcyB3ZSBkaWRuJ3QgdGhpbmsg YWJvdXQgMjAgeWVhcnMNCmFnbywgb3IgdGhhdCB0aGUgcHJvcG9zYWwgaXMgZWl0aGVyIG5lY2Vz c2FyeSBvciBzdWZmaWNpZW50IHRvIHNvbHZlDQphbnkgb2YgdGhlbS4gSSdtIG5vdCBzdXJlLCB0 aG91Z2g7IHRoZSBkb2MgZG9lcyBub3Qgc3VwcGx5IA0Kc3VmZmljaWVudCBkZXRhaWwuDQoNCldl IGFscmVhZHkgaGF2ZSBhIGZvcmtlZCBzcGVjaWZpY2F0aW9uLCB0aGUgT0FTSVMgWFJJLg0KaHR0 cDovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9FeHRlbnNpYmxlX3Jlc291cmNlX2lkZW50aWZpZXIN CmluaXRpYXRlZCBmb3Igc2ltaWxhciBjb25jZXJucy4gSXQgc2VlbXMgcXVpdGUgYSBiaXQgbW9y ZSB0aG91Z2h0DQpvdXQgdGhhbiB0aGUgdXJuYmlzIHByb3Bvc2FsIGFuZCBkb2Vzbid0IHNlZW0g dG8gcmVxdWlyZSANCmFueSBjaGFuZ2UgdG8gMzk4Ni4NCg0KMzk4NiBmcmFnbWVudHMgaGF2ZSBw cm9ibGVtcyBiZXlvbmQgdGhvc2UgaW4NCiBodHRwOi8vd3d3LnczLm9yZy8yMDAxL3RhZy9kb2Mv bWltZVR5cGVzQW5kRnJhZ2lkcw0KQW5kIEkgdGhpbmsgbGV0dGluZyB0aGUgZnJhZ21lbnQgZGVw ZW5kIG9uIHRoZSBzY2hlbWUgZmlyc3QNCih3aXRoIHRoZSBkZWZhdWx0IGRlcGVuZGluZyBvbiBy ZXRyaWV2ZWQgbWVkaWEgdHlwZSkNCndvdWxkIGFsbG93ICd1cm46JyB0byBkZWZpbmUgZnJhZ21l bnRzIChhbmQgeHJpIHRvbykuDQoNCkkgdGhpbmsgSSd2ZSBwcm92aWRlZCBldmlkZW5jZSB0aGF0 IHRoZSBuZWVkcyBvZiB0aGUNCmxpYnJhcnkgY29tbXVuaXR5IHdlcmUgd2VsbC1jb25zaWRlcmVk IGF0IHRoZSB0aW1lDQp3aGVuIFVSTnMgd2VyZSBzcGVjaWZpZWQuIEkgaGF2ZW4ndCBzZWVuIGFu eQ0KZXZpZGVuY2Ugb2YgbmV3IHJlcXVpcmVtZW50cyBhcmlzaW5nIG9yIGRpc2NvdmVyZWQNCmlu IHRoZSBpbnRlcnZlbmluZyAyMCB5ZWFycy4NCkkgaGF2ZW4ndCBzZWVuIGFueSBuZXcgc29sdXRp b25zIHRvIHJlcXVpcmVtZW50cw0KZm9yIHdoaWNoIHNwbGl0dGluZyBVUk4gZnJvbSBVUkkgd291 bGQgaGVscC4NCg0KSW4gMTk5OCANCmh0dHA6Ly9sYXJyeS5tYXNpbnRlci5uZXQvZXVkbC9ldWRs LXBhcnQzYi5wZGYjcGFnZT03DQoiSW50ZXJuZXQgVGVjaG5vbG9naWVzIGZvciBEaWdpdGFsIExp YnJhcmllcyIgIG5vdGVzDQp0aGUgcXVlc3Rpb24gb2YgVVJMICBzeW50YXggY29uc3RyYWluaW5n IFVSTiBzeW50YXguDQoNClRoZSAyMDAxIGRvY3VtZW50DQoiIFVSSXMsIFVSTHMsIGFuZCBVUk5z OiBDbGFyaWZpY2F0aW9ucyBhbmQgUmVjb21tZW5kYXRpb25zIDEuMA0KUmVwb3J0IGZyb20gdGhl IGpvaW50IFczQy9JRVRGIFVSSSBQbGFubmluZyBJbnRlcmVzdCBHcm91cA0KVzNDIE5vdGUgMjEg U2VwdGVtYmVyIDIwMDEiDQpodHRwOi8vd3d3LnczLm9yZy9UUi91cmktY2xhcmlmaWNhdGlvbi8N CnNob3VsZCBhbHNvIGJlIGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZSBhbmQgcmVzcG9uZGVkDQp0 by4NCg0KDQo+IFRoZSBpc3N1ZSBpcyB3aGV0aGVyLCBiYXNlZCBvbiB0aGVpciBleHBlcmllbmNl LCB0aGVpciBwZXJjZWl2ZWQNCj4gbmVlZHMgc2hvdWxkIGJlIGFjY29tbW9kYXRlZC4gLiAgICBJ IHN0YXJ0ZWQgdG8gc2F5ICJhcmUgZW50aXRsZWQNCj4gdG8gYmUgYWNjb21tb2RhdGVkIiwgYnV0 IHRoYXQgaXNuJ3QgdWx0aW1hdGVseSB0aGUgcG9pbnQgZWl0aGVyLg0KDQpTdXJlLCBuZWVkcyBh cmUgZW50aXRsZWQuDQoNCj4gSW5zdGVhZCwgaWYgdGhleSBmZWVsIHN0cm9uZ2x5IGVub3VnaCBh Ym91dCB0aG9zZSBuZWVkcyAtLWFuZA0KPiB0aGUgV0cgaGFzIGhlYXJkIGZyb20gZmFyIG1vcmUg dGhhbiBKdWhhLCB3aXRoIHBlb3BsZSBhbmQNCj4gaW5zdGl0dXRpb25zIG9mIG11bHRpcGxlIHZh cmlldGllcyBiYXNlZCBvbiBtdWx0aXBsZSBjb3VudHJpZXMNCj4gKGFuZCBJJ3ZlIGhlYXJkIGV2 ZW4gbW9yZSkgdG8gYXQgbGVhc3QgZW50ZXJ0YWluIGEgc3Ryb25nDQo+IGh5cG90aGVzaXMgdGhh dCB0aGV5IGRvLS0gd2lsbCB0aGV5IG1vdmUgb2ZmIHRvIGNyZWF0ZSBhDQo+IHN0YW5kYXJkIG9m IHRoZWlyIG93biBpZiB0aGUgSUVURiBzYXlzLCBlLmcuLCAibm8sIHdlLCBiYXNlZCBvbg0KPiB0 aGUgaWRlYXMgb2YgTGFycnkgb3Igb3RoZXJzLCBkb24ndCBiZWxpZXZlIHlvdSBuZWVkIHRvIGRv DQo+IHRoYXQiDQoNCkl0IGFscmVhZHkgaGFwcGVuZWQgd2l0aCBYUkksIGRvaSwgeG1wLmRpZCwg DQogKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY5MjAgKSBhbmQgemlsbGlvbnMNCm9m IG90aGVyICB3YXlzIG9mIGludmVudGVkIHRvIG5hbWluZy4gTmFtaW5nIGlzDQpwb3dlcmZ1bCBh bmQgdmFsdWFibGUuDQoNCj4gSSdtIGNvbnZpbmNlZCB0aGF0IHRoZXkgd2lsbCBhbmQgYW0gYSBi aXQgc3VycHJpc2VkIHRoZXkgaGF2ZW4ndA0KPiBkb25lIHNvIGFscmVhZHkgKEp1aGEgYW5kIG90 aGVycyBoYXZlIGJlZW4gZXhlcnRpbmcgc3VwZXJodW1hbg0KPiBlZmZvcnRzIHRvIGF2b2lkIHRo YXQgb3V0Y29tZSkuICBZTU1ELCBidXQgSSdtIGNvbnZpbmNlZCB0aGF0DQo+IHRoZSBjb3N0cyBv ZiB0d28gaW5jb25zaXN0ZW50IGRlZmluaXRpb25zIG9mICJVUk4iIHdvdWxkIGJlDQo+IHN1ZmZp Y2llbnRseSBoaWdoIHRoYXQgaXQgdHJ1bXBzIHRoZSBjbGFpbWVkIGFkdmFudGFnZXMgb2YNCj4g dHJ5aW5nIHRvIHByZXNlcnZlIGFuIG92ZXJhcmNoaW5nIFJGQyAzOTg2LiANCg0KSXQncyBmaW5l IHRvIGludmVudCBhIG5ldyB3YXkgb2YgbmFtaW5nIHRoaW5ncywgYnV0IGNhbGxpbmcgeW91cg0K bmV3IHdheSAidXJuOiIgaXMganVzdCBydWRlIGFuZCB1bm5lY2Vzc2FyeS4gDQoNCiA+IFdoaWxl IHRoZSBpc3N1ZXMNCj4gYXJlIGNvbXBsZXRlbHkgc2VwYXJhdGUgZnJvbSB0aGUgVVJOIG9uZSwg dGhlIHZpZXcgdGhhdA0KPiBwcmVzZXJ2YXRpb24gb2YgMzk4NiBhbmQgaXRzIGN1cnJlbnQgZGVm aW5pdGlvbnMgYWNyb3NzIHRoZQ0KPiB3aG9sZSByYW5nZSBvZiB3aGF0ZXZlciBwZW9wbGUgY2hv b3NlIHRvIGNhbGwgVVJJcyBpcyBub3Qgd29ydGgNCj4gc2hlZGRpbmcgYmxvb2Qgb3ZlciAob3Ig ZXZlbiBmdXJ0aGVyIGNvbnN0cmFpbmluZyBVUk5zIG9yDQo+IHNsb3dpbmcgVVJOYmlzIG92ZXIp IGlzIHNvbWV3aGF0IHJlaW5mb3JjZWQgYnkgZWZmb3J0cyBpbiBXM0MNCj4gYW5kIFdIQVRXRyB0 byBjaGFuZ2UgdGhlIFVSTCBkZWZpbml0aW9uIGluIHdheXMgdGhhdCwgdG8gbWUsDQo+IGFsc28g bG9vayBpbmNvbXBhdGlibGUgd2l0aCAzOTg2Lg0KDQpTb2x2aW5nIHRoZSBXSEFUV0cgLyBXM0Mg LyBJRVRGIC8gVW5pY29kZSBjb25zb3J0aXVtIC8gDQpJQ0FOTiAvIElETiBjb29yZGluYXRpb24g aXNzdWUgb3ZlciB0aGluZ3MgVVIqIGlzIGEgcHJvYmxlbSANCmFzIHdvcnRoeSAoZGFyZSBJIHNh eSwgZXZlbiBNT1JFIHdvcnRoeSkgb2YgdGFraW5nIG9uLCANCmJ1dCBJJ20gbm90IGF0IGFsbCBj b252aW5jZWQgdGhhdCAgY2xlYXZpbmcgVVJOIG91dCBvZiBVUkkNCmlzIHBhcnQgb2YgdGhlIHNv bHV0aW9uLiBUaGUgbWFpbiBwcm9ibGVtIGlzIHR1cmYsIHdoaWNoDQp0ZWNobm9sb2d5IGNhbm5v dCBzb2x2ZSBieSBpdHNlbGYuIA0KDQpMYXJyeQ0KLS0NCmh0dHA6Ly9sYXJyeS5tYXNpbnRlci5u ZXQNCg0K From nobody Mon Jul 7 06:02:46 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670B01A040C for ; Mon, 7 Jul 2014 06:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no 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 G14eL9nXmrJv for ; Mon, 7 Jul 2014 06:02:38 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75E641A0406 for ; Mon, 7 Jul 2014 06:02:33 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s67D2UcS019798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 7 Jul 2014 16:02:30 +0300 Message-ID: <53BA9A65.3060207@helsinki.fi> Date: Mon, 07 Jul 2014 16:02:29 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: urn@ietf.org References: <0A6681C7A656E38E8CCFF8A4@JcK-HP8200.jck.com> <6cedc3e56c534419a34fc516f732adb0@BL2PR02MB307.namprd02.prod.outlook.com> <11D4E145F435FE3C28C30408@[192.168.1.128]> In-Reply-To: <11D4E145F435FE3C28C30408@[192.168.1.128]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/gOoc8mwRqfTAplrPmvnbzn8Os3g Subject: Re: [urn] New urns-are-not-uris draft X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 13:02:41 -0000 Hello, On 6.7.2014 19:43, John C Klensin wrote: > > --On Sunday, 06 July, 2014 02:14 +0000 Larry Masinter > wrote: > > >> =============== >> It isn't true that ISBN numbers never change. They change >> rarely, perhaps. A primary use of ISBN was as bookstore stock >> and pricing unique key. So if a book is printed with multiple >> color covers, they might use the same ISBN number. New >> printing, perhaps a minor printing flaw fixed, ditto. The >> permanence and meaning of this kind of identification for >> documents will change even further. > Based on reading the standard (have you done that?) and a few > discussions with the registration agency, I think your > interpretation above is wrong or at least misleading. But that > is not an area where I claim expertise so I'll let others debate > it with you if they are so inclined. A few of your comments > below been elided. I hope others with more in-depth expertise > will respond to them, especially if they believe the topics have > not been adequately covered already. I was a member in the working group which wrote the current version of the standard. ISBN Manual (https://www.isbn-international.org/sites/default/files/ISBN%20Manual%202012%20-corr.pdf) and the standard itself provide detailed guidelines on how to apply ISBNs. Every well managed identifier system should have published guidelines document. An ISBN which has been assigned to a book will never change. The ISBN of Food composition data interchange handbook published by United Nations University in 1992 is and will always be 92-808-0774-9. This ISBN will never be reused (assigned to another book) and this version of the handbook will never get another ISBN. Chapter 5 of the ISBN manual (Application of ISBN) says that if there are no changes to the content and physical form (or if just some misprints are fixed), the same ISBN can still be used for reprint. But if there are substantial changes to the intellectual content, new ISBN is required. ISBNs are usually accompanied with detailed metadata which describes the difference between two editions (e.g. 2nd, revised ed.). Had the Food composition data interchange handbook been published in different formats (hardback, paperback, PDF and so forth) each one of them would have received its own ISBN. ISBN community, like other communities using traditional identifiers, does not need URNs to extend the scope of the existing identifier system or to change its current identifier assignment policy. URNs are needed mainly in order to make the existing identifier systems actionable in the Internet. Theoretical discussion in this list on the principles of naming / identification has therefore not been particularly helpful. Whether the current principles for assigning ISBNs are correct from IETF point of view (whatever that means), or the fact that it is possible to misuse ISBNs (some publishers especially in the U.S.A. would like to give the same ISBN to all digital versions of a book) is, IMO, not something that needs to be discussed in URNBIS / IETF. IETF does not have a mandate to change the policy of ISBN assignment. And there are other URN namespaces out there which are more problematic than URN:ISBN from management point of view. > > In particular, your excerpts from what is now Section 3 are > about text for which Juha provided that starting point and that > has been, IMO, extensively discussed on-list. If he tells me > that I misinterpreted his intent, I will be happy to revise as > needed (also, of course, if Andrew tells me the WG consensus is > different). No, John has interpreted my intent correctly. > But, unless you are ready to engage with his > position, and, IMO, do so with equal experience and authority, > repetition of the same assertions this just leads us in circles. > >> Not every blog post gets >> its own identifier, with many information tools, 'location' is >> meaningless. You may think this is a minor point or these are >> corner cases, but I think they're central. The well-ordered >> world wished for isn't there. > I think that may be true but is certainly irrelevant. See > above... and Juha's repeated comments about managed processes. The world as a whole is not well-ordered, but there are parts of it which are reasonably well managed and orderly. And it is in these well managed parts of the world where URNs and other persistent identifiers are most urgently needed. If there is no requirement to preserve a document for long term (beyond the life time of technologies such as HTTP) then even protocol dependent and un-managed "identifiers" may be sufficient. A blog post in the web is not persistent, but a blog post harvested into the national library's web archive will be preserved for long term, and is likely to receive a persistent identifier as well. Juha > >> The document consistently attributes to "all URIs" properties >> that are only true of a few URI schemes. There are plenty of >> name-like URLs that are not URNs, tag:, data:, uuid: and many >> others. > The "all URIs" problem is a consequence of the language of 3986 > (on which I note your name appears) and not the present document. > >> Comments linked to the text: >> >> # 1. Introduction >> The names of categories of identifiers "name-type" and >> "location-based" are design concept ideas and not properties >> of the identifiers themselves. >> >> # "Impractical to constrain URNs to syntax and high-level >> # semantics of URLs" >> What constraints there are can changed without seceding URNs >> from the URI union. As far as I can tell, the only syntactic >> changes wanted is to allow "#" for fragments and "/" for >> hierarchy. If this is necessary it might require an update. > Other changes may be needed - see the document at -01 and the > correspondence on the list. More important, my opinion (perhaps > wrong) and that of Barry and Pete (unless I've misunderstood) is > that there is insufficient energy in the IETF to undertake a > 3986bis, or even a substantive and detailed update, and more it > to completion in a reasonable amount of time. The separation > model is just a pragmatic way to work around that problem > without holding the work of the URN WG up for an additional > extended period -- and allowing the odds of a fork in the > standard by another body that doesn't need to debate these > niceties of definition to rise considerably. > >> # "Generalization ... has failed ..." >> I don't see any use cases where splitting URNs from URIs >> reduces failure. If there are failures, they are intrinsic. > The failure is to come up with a syntax and set of semantics for > URNs that meet the perceived needs of the important parts of the > URN community without violating the constraints of 3986. I > thought that was clear; if not, I apologize and will make > another pass through the draft. > >> # "... are simply different creatures ..." >> The boundary between locator and name is completely blurred >> and there are endless examples where the pun is a fundamental >> feature: that the same URI functions as a name in some >> contexts and a location in others. XML namespaces are a clear >> instance where both http and urn URIs are used uniformly. > See prior comments (above and on the list) about the perceived > needs of legitimate and experienced communities. You, of > course, get to disagree, but that doesn't seem to affect their > perceptions. And, again, the IETF gets to either adapt or risk > (I believe "guarantee", but could be wrong) an externally-forked > standard. This is not an instance where the IETF gets to say > "no, you shouldn't do that, or believe that, so don't" and > expect an established community with centuries of experience to > pay any attention. > >> ... > best, > john > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Mon Jul 7 15:40:05 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEE91B28A5 for ; Mon, 7 Jul 2014 15:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3] autolearn=no 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 xaqlT0Ln54vr for ; Mon, 7 Jul 2014 15:40:02 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 83AE31B281C for ; Mon, 7 Jul 2014 15:40:02 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta01.westchester.pa.mail.comcast.net with comcast id PYot1o0041ap0As51ag2AS; Mon, 07 Jul 2014 22:40:02 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta22.westchester.pa.mail.comcast.net with comcast id Pag11o00A1KKtkw3iag1o5; Mon, 07 Jul 2014 22:40:02 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s67Me0va009696; Mon, 7 Jul 2014 18:40:00 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s67MdvwL009690; Mon, 7 Jul 2014 18:39:57 -0400 Date: Mon, 7 Jul 2014 18:39:57 -0400 Message-Id: <201407072239.s67MdvwL009690@hobgoblin.ariadne.com> From: worley@alum.mit.edu (Dale R. Worley) Sender: worley@alum.mit.edu (Dale R. Worley) To: =?utf-8?Q?Martin_J=2E_D=C3=BCrst?= In-reply-to: <53BA571B.9080909@it.aoyama.ac.jp> (duerst@it.aoyama.ac.jp) References: <201407031853.s63IrIWC027924@hobgoblin.ariadne.com> <53BA571B.9080909@it.aoyama.ac.jp> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1404772802; bh=3PouiPcKVsCZVbeLzqQoHubz1ntoDFARF6DV3IrBwCs=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject:MIME-version:Content-type; b=O+/wGfUPpEyAde0wIl0TJvdCwjW+/yXBrFFmAzsr3h98Rjr5DG2FW3c+CpV9J8OFQ mSpLiE1eB7SFtkVgvt4GYqoW5crKD4Ki9OXXR81KzTlcmXGo9LoRTgfpUZgSRhDrMN fYu6FMPQYqULbKHD8sfft/nNciWxuHxZUm2hcvzMheEklEHvTN/QLrHWLcB74nsvk6 ZmHVc5IFeOmqkRX2Y8JPWx4v7qRso1NrTFMuZk3S2cn38oKSLM5VlgbM/wLvo+STRV KBBK9i2uHjQ+SFx7buefHLHzVusQtLDCDXVfWAuWFh9M5rslyzygubgUNIIbmJZ8QA JP9jAVXU5+oGQ== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/Mv5vv8gg4v04dPZkr7nB3G_8GEM Cc: urn@ietf.org Subject: Re: [urn] Some observations to add to the discussion X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 22:40:04 -0000 > From: "Martin J. Dĵrst" > > > In regard to rebuilld the syntax of URNs from scratch, I can > > understand why one would want to do that. But there is no reason we > > can't embed URNngs as a NID of URNs (assuming that they're a sequence > > of Unicode characters) by generous use of %-escapes: > > urn:ng:%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx. That doesn't provide > > anything other than making them "syntactically interoperable" with > > existing URIs, but syntactic interoperability is a desirable feature. > > Can you give a more specific example? Some people seem to get scared > when they see that many % signs. > > Of course in URI form, non-ASCII characters will have to be escaped with > %HH. But I don't see a need to do that for US-ASCII characters or in an > IRI form. Here's what I mean, or rather, some examples of what I mean: Suppose we decide to create a "URNng", and the appropriate authorities decide that the string "Dante's Inferno" should be a URNng for the book. As a matter of syntactic embedding, we can create a URN NID named "ng" for the new URNng strings, and using %-encoding whenever necessary, represent the URNng as a URI: urn:ng:Dante%27s%20Inferno This isn't particularly pleasing to the eye, but that doesn't really matter -- the question is to achieve syntactic uniformity in protocol contexts where URIs are expected. If the "application" that deals with this URI knows or expects it to be a URNng, it can easily convert it to/from "Dante's Inferno" for the user's use. Now let us suppose that they decide to use "Canto XXV" as a fragment identifier in the sense of RFC 3986 (or its successor), then we can represent that as a URI: urn:ng:Dante%27s%20Inferno#Canto%20XXV However, if URNng uses different semantics for a "part", we'll retain the URNng "part" indicator character as a non-special character in the NSS. Assuming URNng uses U+2192 (RIGHTWARDS ARROW) to indicate the part, that can be represented as a URI: urn:ng:Dante%27s%20Inferno%e2%86%92Canto%20XXV (Assuming I have done the UTF-8 conversion correctly.) Again, not human-friendly, but the software can cover that up. Now, let's suppose that the string "ĉŽŒĉĦċ¸ĥäşşċ¸Ĥċ›˘é˜Ÿçš„ĉ–ıĉ³•â•ŸċŸıċ…ğ訓çğƒïĵŒĉş 通互ċŠ¨ïĵŒċ›˘éšŠĉ°›ċœçˆ„造ïĵŒĉż€ċ‹µèݏèĦ" is a URNng. (I don't have any idea what those characters mean; they were the name of a PDF file that was sent me as spam.) That can be represented as the NSS of a URI as: urn:ng:%e6%8e%8c%e6%8f%a1%e5%b8%b6%e4%ba%ba%e5%b8%a6%e5%9b%a2%e9%98%9f%e7%9a%84%e6%96%b9%e6%b3%95%e2%95%9f%e5%9f%b9%e5%85%bb%e8%a8%93%e7%bb%83%ef%bc%8c%e6%ba%9d%e9%80%9a%e4%ba%92%e5%8a%a8%ef%bc%8c%e5%9b%a2%e9%9a%8a%e6%b0%9b%e5%9c%8d%e7%88%84%e9%80%a0%ef%bc%8c%e6%bf%80%e5%8b%b5%e8%a9%8f%e8%ae%a1 Dale From nobody Mon Jul 7 20:45:18 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FB61A0AC0 for ; Mon, 7 Jul 2014 20:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 bLVslOexXuAz for ; Mon, 7 Jul 2014 20:45:12 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4511C1A0119 for ; Mon, 7 Jul 2014 20:45:12 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1X4MHm-000Gf9-1o; Mon, 07 Jul 2014 23:41:42 -0400 Date: Mon, 07 Jul 2014 23:45:03 -0400 From: John C Klensin To: "Dale R. Worley" , =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Message-ID: In-Reply-To: <201407072239.s67MdvwL009690@hobgoblin.ariadne.com> References: <201407031853.s63IrIWC027924@hobgoblin.ariadne.com> <53BA571B.9080909@it.aoyama.ac.jp> <201407072239.s67MdvwL009690@hobgoblin.ariadne.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/Ck33WLkfudygZXnTODJtKKr0D8E Cc: urn@ietf.org Subject: Re: [urn] Some observations to add to the discussion X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 03:45:16 -0000 --On Monday, July 07, 2014 18:39 -0400 "Dale R. Worley" wrote: >> From: "Martin J. D=C3=BCrst" >>=20 >> > In regard to rebuilld the syntax of URNs from scratch, I = can >> > understand why one would want to do that. But there is no >> > reason we can't embed URNngs as a NID of URNs (assuming >> > that they're a sequence of Unicode characters) by generous >> > use of %-escapes: >> > urn:ng:%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx%xx. That >> > doesn't provide anything other than making them >> > "syntactically interoperable" with existing URIs, but >> > syntactic interoperability is a desirable feature. >>=20 >> Can you give a more specific example? Some people seem to get >> scared when they see that many % signs. >>=20 >> Of course in URI form, non-ASCII characters will have to be >> escaped with %HH. But I don't see a need to do that for >> US-ASCII characters or in an IRI form. >=20 > Here's what I mean, or rather, some examples of what I mean: >=20 > Suppose we decide to create a "URNng", and the appropriate > authorities decide that the string "Dante's Inferno" should be > a URNng for the book. >=20 > As a matter of syntactic embedding, we can create a URN NID > named "ng" for the new URNng strings, and using %-encoding > whenever necessary, represent the URNng as a URI: >=20 > urn:ng:Dante%27s%20Inferno >=20 > This isn't particularly pleasing to the eye, but that doesn't > really matter -- the question is to achieve syntactic > uniformity in protocol contexts where URIs are expected. If > the "application" that deals with this URI knows or expects it > to be a URNng, it can easily convert it to/from "Dante's > Inferno" for the user's use. >=20 > Now let us suppose that they decide to use "Canto XXV" as a > fragment identifier in the sense of RFC 3986 (or its > successor), then we can represent that as a URI: >=20 > urn:ng:Dante%27s%20Inferno#Canto%20XXV >=20 > However, if URNng uses different semantics for a "part", we'll > retain the URNng "part" indicator character as a non-special > character in the NSS. Assuming URNng uses U+2192 (RIGHTWARDS > ARROW) to indicate the part, that can be represented as a URI: >=20 > urn:ng:Dante%27s%20Inferno%e2%86%92Canto%20XXV >=20 > (Assuming I have done the UTF-8 conversion correctly.) Again, > not human-friendly, but the software can cover that up. >=20 > Now, let's suppose that the string > = "=E6=8E=8C=E6=8F=A1=E5=B8=B6=E4=BA=BA=E5=B8=A6=E5=9B=A2=E9=98=9F=E7= =9A=84=E6=96=B9=E6=B3=95=E2=95=9F=E5=9F=B9=E5=85=BB=E8=A8=93=E7=BB= =83=EF=BC=8C=E6=BA=9D > = =E9=80=9A=E4=BA=92=E5=8A=A8=EF=BC=8C=E5=9B=A2=E9=9A=8A=E6=B0=9B=E5= =9C=8D=E7=88=84=E9=80=A0=EF=BC=8C=E6=BF=80=E5=8B=B5=E8=A9=8F=E8=AE= =A1" is a URNng. (I > don't have any idea what those characters mean; they were the > name of a PDF file that was sent me as spam.) That can be > represented as the NSS of a URI as: >=20 >=20 > urn:ng:%e6%8e%8c%e6%8f%a1%e5%b8%b6%e4%ba%ba%e5%b8%a6%e5%9b%a2% > e9%98%9f%e7%9a%84%e6%96%b9%e6%b3%95%e2%95%9f%e5%9f%b9%e5%85%bb > %e8%a8%93%e7%bb%83%ef%bc%8c%e6%ba%9d%e9%80%9a%e4%ba%92%e5%8a%a > 8%ef%bc%8c%e5%9b%a2%e9%9a%8a%e6%b0%9b%e5%9c%8d%e7%88%84%e9%80% > a0%ef%bc%8c%e6%bf%80%e5%8b%b5%e8%a9%8f%e8%ae%a1 Dale, I want to stress that what I'm about to say is just personal opinion -- I'm happy with whatever the WG converges on if it really meets the needs of relevant communities. That said, while I agree that the above could be made to work, I think experience predicts that it will be a disaster. In more detail: First, every time we've made the assumption that a UR* or other object identifier would not need to be seen by users, it has been a mistake. For the Internet the family of relevant incorrect assumptions goes back to "we can just number hosts and other hosts/systems will invent local nicknames and apply them as needed". I've been told that the original web design assumed that users would never actually have to look at a URL; certainly the Bush "As We May Think" paper does an impressive amount of handwaving about what links would actually look like and how they would function at a low level. =20 If users need to look at the things, much less read them and type them in (even if only for debugging and testing and history predicts it will be much more than that) I can't imagine the examples above, especially the Chinese one, getting a good reception. More important, strings like this that are not immediately obvious and lack good mnemonic value are exceptionally error-prone and cause typical users to glaze over sufficiently to create an attack vector and associated security problem. As an example, quickly and without overlaying the strings on each other or decoding them back to native characters, tell me whether the hypothetical string above and the one that follows are identical under the URN equivalency rules: urn:ng:%e6%8e%8c%e6%8f%a1%e5%b8%b6%e4%ba%bb%e5%b8%a6%e5%9b%a2%e9%= 98%9f%e7%9a%84%e6%96%b9%e6%b3%95%e2%95%9f%e5%9f%b9%e5%85%bb%e8%a8= %93%e7%bb%83%ef%bc%8c%e6%ba%9d%e9%80%9a%e4%ba%92%e5%8a%a8%ef%bc%8= c%e5%9b%a2%e9%9a%8a%e6%b0%9b%e5%9c%8d%e7%88%84%e9%80%a0%ef%bc%8c%= e6%bf%80%e5%8b%b5%e8%a9%8f%e8%ae%a1 My guess is that would be even more true, and hence more of an issue, for URNs than for URLs (or other generic URIs) because, well, we call them names and pretend that they are. Independent of the URI syntax rules and what needs to be escaped, any non-ASCII case takes us down the several URI/IRI-related rabbit holes as well, including claims that having to escape local characters but not basic Latin ones is discriminatory and the problem that, while U+NNNN code point escapes (and syntactic variations on them) are easily looked up in tables and, if seen as identifiers or a repertoire by its code points, are CCS and encoding form independent. "%nn" escapes, by contrast, are not only tied to Unicode in UTF-8 but require UTF-8 encoding and decoding software to use (very few of us can get to and from U+nnnn and its UTF-8 representation for code point values higher than around U+0300 in our heads). If your point was to illustrate that, if we considered preserving all of the syntax rules and general interpretations of 3986 and/or not extending from 2141 in the ways that its text clearly anticipates to be the dominant priority, I agree. We could quibble about the difference between UTF-8-based octet escapes and code point-based escapes (the latter would also require moving away from 3986), but the point is clear. My difficulty is that I don't accept that priority. I think URNs need to be reasonably readable and at least plausibly type-able in most cases. I expect them to be able to have mnemonic value in most (or many) cases. I'd rather see "no escapes" than a regime that requires that a very large fraction of NSS strings contain lots of them. And I think that, as we extend URNs beyond what 2141 allows and into what 2141 anticipates (and maybe beyond), we should consider kludges to be unattractive and to have costs that we should strive to avoid if doing so doesn't cause too much damage in other areas. =20 Obviously, "too much" is part of a delicate balance the WG needs to strike, noting that no one has suggested an approach that would violate the "Method:" super-generic syntax. But, at least to my design taste and human factors design experience, I think your examples are over the line. best, john >=20 > Dale >=20 > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Mon Jul 7 22:46:53 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B323B1B28F0 for ; Mon, 7 Jul 2014 22:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.152 X-Spam-Level: X-Spam-Status: No, score=-5.152 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 AGhyKhxBNBmX for ; Mon, 7 Jul 2014 22:46:49 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBCAD1A007C for ; Mon, 7 Jul 2014 22:46:48 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s685kVRp008708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 8 Jul 2014 08:46:33 +0300 Message-ID: <53BB85B6.8000904@helsinki.fi> Date: Tue, 08 Jul 2014 08:46:30 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , "Svensson, Lars" , John C Klensin , "Dale R. Worley" References: <24637769D123E644A105A0AF0E1F92EFA445E513@dnbf-ex1.AD.DDB.DE> <53ABD826.20606@helsinki.fi> <53BA62B1.3090206@it.aoyama.ac.jp> In-Reply-To: <53BA62B1.3090206@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/zizVcO6Rz6UeNOLZBp2-VEIybK8 Cc: "urn@ietf.org" Subject: Re: [urn] Queries and service requests X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 05:46:51 -0000 Hello Martin, On 7.7.2014 12:04, "Martin J. Dĵrst" wrote: > Hello Juha, > > On 2014/06/26 17:21, Juha Hakala wrote: > >> Using URI query for passing ServiceRequests looks like an attractive >> option with minimal technical overhead. Whether this kind of use of >> query would be confusing, and whether using some other mechanism would >> make things more clear I can't tell, before seeing more detailed >> proposal on how to proceed. > > Very good point. I would indeed also like to see more specific > proposals. Are there any around? The only specific proposal I have seen so far was the one Alfred Hoenes and myself included in RFC2141bis which was later replaced by one written by Peter which was less specific about how to use query. Any meaningful ServiceRequest spec must allow definition of both services and parameters related to them. For instance, it must be possible to retrieve metadata about the identified resource. RFC 2483 provides two services for this purpose, I2C (URI to URC) and I2CS (URI to URCs). Using these mnemonics and letter s to indicate service, we get query ?s=I2C. Unfortunately this is not enough, because RFC 2483 assumes that the metadata is in Uniform Resource Characteristics format, which IETF failed to develop. So there is a need to add a parameter for preferred metadata format. Assuming that letter p indicates parameter and DC is a parameter value for Dublin Core, we get ?s=I2C&p=DC. It might be useful to enable something like ?s=I2C&p=MARC21&p=F to indicate that the user wants a complete MARC 21 record. There are many other metadata formats which need to be specified. Page http://www.jiscdigitalmedia.ac.uk/guide/metadata-standards-and-interoperability gives a simplified idea of the situation. Services and service parameters must of course reflect the properties of systems which will respond to the requests, and protocols used in the system to system communication. If a user wants just metadata about the resource, SRU protocol (http://www.loc.gov/standards/sru/sru-2-0.html) can be used, and whoever specifies parameters for I2C service should be aware of what SRU servers can do. When a user demands all versions of the resource from a digital archive, SRU is not appropriate, but for instance MEDONA (http://www.archivesdefrance.culture.gouv.fr/seda/documentation/SEDA_description_standard_v1_0.pdf) can be used. And - just to give you another example - if there is a need to synchronize an identified resource between two systems, ResourceSync protocol (http://www.niso.org/workrooms/resourcesync/) is available for this purpose. ResourceSync is a brand new American national standard. MEDONA is a French standard which was published in February 2014, but its ISO standardization process of begun last May. It is likely that both of these protocols will be widely supported in digital archives and open repositories, so people who design the relevant ServiceRequests (in this case I2R and I2Rs, URI to resource(s), and synchronize the resource, which RFC 2483 knows nothing about) must take into account the properties of these two and other protocols (if any) which will be applied when these services are provided. In order to manage this complexity efficiently, there is a need for a(n IANA) registry where communities using URNs and possibly other persistent identifiers can register the URN/ATK/Handle resolution services and service parameters they support. Carving these things in stone just by extending RFC 2483 won't do, because even such extended specification will be outdated soon by new technologies such as ResourceSync. It is unfortunate that there is currently no widely implemented/approved means of making resolution related ServiceRequests. Because of this, different PID systems are busy re-inventing the wheel by specifying their own services and means (query based) to request them. For instance, if you add "?" into ARK (https://datatracker.ietf.org/doc/draft-kunze-ark/), you'll get simple metadata about the identified resource. And adding "??" enables the users to fetch the preservation commitment of the organization which is holding the identified digital document (this is of course one kind of metadata as well). If URNBIS cannot reach an agreement on how to use query (or an attractive alternative method) for passing ServiceRequests to PID resolvers, then the result is not just one fork, but many. Most likely one of them will apply to URNs. What is required is that - RFC2141bis allows the use of query in the URN syntax, and - RFC2483bis provides the necessary background for the (IANA) service registry to be established, and - the registry itself is created, using the services specified in RFC 2483 as the starting point, but refining them with parameters as needed IMO the service registry would not be need to be too different from the registry maintained for the namespace registrations. The two registries could be interconnected; namespace registration may - assuming that URNs in that namespace can be resolved - provide a list of resolution services and service parameters supported. But I am not sure how useful that is, because any such list will be outdated very soon, and keeping it up to date would be a burden. > > >> Like Lars, I wonder if the intention is to >> drop just the word query, or the syntax as well. > > Who's intention are you speaking about? According to John, it's people > like you who know what they need, so what would be your preference? My preference is to use URI query, because "things should be made as simple as possible, but not simpler", and other persistent identifier systems are using query already. But I am open to other suggestions, especially if there are obvious technical benefits that even I can understand. All the best, Juha > > Regards, Martin. -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 From nobody Tue Jul 8 06:32:47 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BA01B2A7A for ; Tue, 8 Jul 2014 06:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no 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 O20N-NJAolWv for ; Tue, 8 Jul 2014 06:32:44 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9E841B2841 for ; Tue, 8 Jul 2014 06:32:43 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) with Microsoft SMTP Server (TLS) id 15.0.980.8; Tue, 8 Jul 2014 13:32:41 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0980.000; Tue, 8 Jul 2014 13:32:41 +0000 From: Larry Masinter To: Juha Hakala , =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , "Svensson, Lars" , John C Klensin , "Dale R. Worley" Thread-Topic: [urn] Queries and service requests Thread-Index: AQHPmnAl/SaLb1Z33kiHFA0cfulHJpuWJhOw Date: Tue, 8 Jul 2014 13:32:41 +0000 Message-ID: <02071028cd8e4b6ba9f5cb2124ef195e@BL2PR02MB307.namprd02.prod.outlook.com> References: <24637769D123E644A105A0AF0E1F92EFA445E513@dnbf-ex1.AD.DDB.DE> <53ABD826.20606@helsinki.fi> <53BA62B1.3090206@it.aoyama.ac.jp> <53BB85B6.8000904@helsinki.fi> In-Reply-To: <53BB85B6.8000904@helsinki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0266491E90 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(20776003)(46102001)(95666004)(54356999)(74502001)(85852003)(83072002)(21056001)(107046002)(85306003)(79102001)(106356001)(106116001)(77982001)(99286002)(105586002)(76482001)(74316001)(99396002)(80022001)(50986999)(83322001)(33646001)(64706001)(15975445006)(81342001)(19580395003)(66066001)(86362001)(81542001)(31966008)(76176999)(92566001)(4396001)(87936001)(101416001)(76576001)(2656002)(74662001)(15202345003)(93886003)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB307; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/urn/YW5punlEoiPeV2gnBLWr65zYYMw Cc: "urn@ietf.org" Subject: Re: [urn] Queries and service requests X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 13:32:46 -0000 KiBJZiBib3RoIFVSTHMgaW4gV2hhdFdHIGFuZCBVUk5zIGFiYW5kb24gMzk4Niwgd2hhdCAgaXMg dGhlIHNjb3BlIG9mIDM5ODYgbGVmdCB3aXRoPw0KICAgVVJOcyB0aGF0IGRvbid0IGlkZW50aWZ5 IGRvY3VtZW50cywgYW5kIFVSTHMgdW5zdWl0YWJsZSBmb3IgZmV0Y2g/DQogICBPZiBjb3Vyc2Ug Mzk4NiBzaG91bGQgYmUgdXBkYXRlZCwgaW5jbHVkaW5nIGludGVncmF0aW5nIHRoZSBpMThuIHJl cXVpcmVtZW50cy4NCg0KKiBuYW1pbmcgYW5kIGxvY2F0aW5nIGFuZCBmZXRjaGluZyByZXByZXNl bnRhdGlvbnMgbWF5IGJlIGRpZmZlcmVudA0KICAgZW5vdWdoIGFjdGl2aXRpZXMgdG8gc2F5IHRo ZXkncmUgZGlmZmVyZW50IGFjdGl2aXRpZXMsIGJ1dCB0aGUgc2FtZQ0KICBzdHJpbmcgaXMgdXNl ZCBmb3IgYm90aC4gDQogIA0KKiBVUk5zIGFyZSB1c2VkIHRvIG5hbWUgdGhpbmdzIHRoYXQgYXJl bid0IGRvY3VtZW50cywgYnV0IHRoZXNlDQogICBzcGVjcyB3aXRoIGZyYWdtZW50cyBhbmQgcmV0 cmlldmFsIG1ldGhvZHMgYW5kIHF1ZXJ5IGNvbXBvbmVudHMNCiAgIGFyZSBwcmV0dHkgaXJyZWxl dmFudCBmb3Igbm9uLWRvY3VtZW50IGFwcGxpY2F0aW9ucy4gcmZjMzU1MyANCiAgIGZvciBleGFt cGxlLg0KDQoqIEkgd2Fzbid0IGpva2luZywgbG9vayBhdCBYUkkuIEluIHRoZSBlbmQsIEkgdGhp bmsgdGhleSBjYW1lIHRvIHRoZSBzZW5zaWJsZQ0KICAgY29uY2x1c2lvbiB0aGF0IHJlc291cmNl IGlkZW50aWZpY2F0aW9uIGNvdWxkIHVzZSBhIGRhdGEgc3RydWN0dXJlLCBpZiBvbmx5DQogICB0 byBtYWtlIHRoZSBlcXVpdmFsZW5jZSBhbGdvcml0aG0gbW9yZSBzZW5zaWJsZS4gWWVzLCB0aGV5 IGFsc28gZGVmaW5lZA0KICAgYSB3YXkgb2YgcGFja2luZyB0aGUgZGF0YSBzdHJ1Y3R1cmUgaW50 byBhbiAieHJpOiIgVVJJLCBidXQgdGhhdCdzIGp1c3QNCiAgcGFja2FnaW5nLiBZb3UgbWlnaHQg YXMgd2VsbCB1c2UgZGF0YTphcHBsaWNhdGlvbi94cmkreG1sLC4uLi4uLiAob3INCiAgZGF0YTph cHBsaWNhdGlvbi94cmkranNvbiwuLi4uIGlmIHlvdSB3YW50IHRvIGJlIG1vZGVybi4pDQoNCkxh cnJ5DQotLQ0KaHR0cDovL2xhcnJ5Lm1hc2ludGVyLm5ldA0KDQo= From nobody Tue Jul 8 07:36:35 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6203B1B2ADE for ; Tue, 8 Jul 2014 07:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham 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 NbxpiOBBrdkm for ; Tue, 8 Jul 2014 07:36:33 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id D278F1B2A74 for ; Tue, 8 Jul 2014 07:36:32 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta03.westchester.pa.mail.comcast.net with comcast id Pq8D1o0041ap0As53qcYzw; Tue, 08 Jul 2014 14:36:32 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta22.westchester.pa.mail.comcast.net with comcast id PqcX1o01Y1KKtkw3iqcYZz; Tue, 08 Jul 2014 14:36:32 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s68EaV7u015524; Tue, 8 Jul 2014 10:36:31 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s68EaVRx015522; Tue, 8 Jul 2014 10:36:31 -0400 Date: Tue, 8 Jul 2014 10:36:31 -0400 Message-Id: <201407081436.s68EaVRx015522@hobgoblin.ariadne.com> From: worley@alum.mit.edu (Dale R. Worley) Sender: worley@alum.mit.edu (Dale R. Worley) To: John C Klensin In-reply-to: (john-ietf@jck.com) References: <201407031853.s63IrIWC027924@hobgoblin.ariadne.com> <53BA571B.9080909@it.aoyama.ac.jp> <201407072239.s67MdvwL009690@hobgoblin.ariadne.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1404830192; bh=NDQc4qrLr9qNN8yL3+LRq4V6Zyr9hh9hB4+Ui70juoo=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject:MIME-version:Content-type; b=H3LaJeR5xU8RBge9Z6JjjbR7VWEDw4s2d+C1Tcqi+A6xm2n79C4+wY3Lp85pBkIyC QGG/B/YEALSobrF17o10+noVbSnNl7+uh21ovUzmgRCuwrc0rD+WYG3SNeB36HOEIC fZKvl6jwbD4cBHSWvqyc4jYtplz7zUMA1c/voIZNLFN/Ml/qSGhpmQDiUWrzlFbpyY 4a4qeQlesuayP7g1JVUw0WiXgZTVTc1UdPgjQnM3IuJ783b39ZkZY9+lIobnoKd047 9CvB1upQnh3Zg6lN3gsZ9kTz653Bf95D/UIlJrM348MWi4WFKRsOGc9gNbk9GCDvTb 6LFIgKaReH2Jg== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/-bLkm9z5xgIPgGCHBTXxGOuFs_E Cc: urn@ietf.org Subject: Re: [urn] Some observations to add to the discussion X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 14:36:34 -0000 > From: John C Klensin > I've been told that the original web design assumed that users would > never actually have to look at a URL; That's a point, but it's one that cuts both ways: While it is assumed now that people will both type and look at URLs, my browser will accept a wide range of URL-like strings and (either visibly or invisibly) translate them into strings that conform to the URL syntax. So it does not seem to me to be an unreasonable expectation that user interfaces will accept from the user, say: urn:ng:ĉŽŒĉĦċ¸ĥäşşċ¸Ĥċ›˘é˜Ÿçš„ĉ–ıĉ³•â•ŸċŸıċ…ğ訓çğƒïĵŒĉş but actually put on the wire > urn:ng:%e6%8e%8c%e6%8f%a1%e5%b8%b6%e4%ba%ba%e5%b8%a6%e5%9b%a2% > e9%98%9f%e7%9a%84%e6%96%b9%e6%b3%95%e2%95%9f%e5%9f%b9%e5%85%bb > %e8%a8%93%e7%bb%83%ef%bc%8c%e6%ba%9d%e9%80%9a%e4%ba%92%e5%8a%a > 8%ef%bc%8c%e5%9b%a2%e9%9a%8a%e6%b0%9b%e5%9c%8d%e7%88%84%e9%80% > a0%ef%bc%8c%e6%bf%80%e5%8b%b5%e8%a9%8f%e8%ae%a1 and vice-versa. However, at this point I think we need more concrete input, as the remaining devils are in the details; first, people who work daily with identifiers, and second, people who build user interfaces for people of the first type. Dale From nobody Tue Jul 8 08:37:25 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D051B2B11 for ; Tue, 8 Jul 2014 08:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 Cq0-MFYkUHHz for ; Tue, 8 Jul 2014 08:37:21 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632C81A020B for ; Tue, 8 Jul 2014 08:37:21 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB308.namprd02.prod.outlook.com (10.141.91.24) with Microsoft SMTP Server (TLS) id 15.0.954.9; Tue, 8 Jul 2014 15:37:20 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0980.000; Tue, 8 Jul 2014 15:37:20 +0000 From: Larry Masinter To: "Dale R. Worley" , John C Klensin Thread-Topic: [urn] Some observations to add to the discussion Thread-Index: AQHPlvBWiRB3eNRkGkmdWWwh4LJ2/JuUSVKAgADx0kCAAFT7gIAAtkdEgAAEjkA= Date: Tue, 8 Jul 2014 15:37:19 +0000 Message-ID: References: <201407031853.s63IrIWC027924@hobgoblin.ariadne.com> <53BA571B.9080909@it.aoyama.ac.jp> <201407072239.s67MdvwL009690@hobgoblin.ariadne.com> <201407081436.s68EaVRx015522@hobgoblin.ariadne.com> In-Reply-To: <201407081436.s68EaVRx015522@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0266491E90 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(51704005)(74316001)(85852003)(20776003)(74662001)(74502001)(106116001)(50986999)(107046002)(99396002)(46102001)(33646001)(87936001)(2171001)(15202345003)(76482001)(106356001)(101416001)(19580395003)(83322001)(86362001)(15975445006)(76576001)(81542001)(92566001)(80022001)(54356999)(99286002)(83072002)(21056001)(76176999)(79102001)(77982001)(2656002)(4396001)(93886003)(85306003)(31966008)(81342001)(105586002)(95666004)(64706001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB308; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/urn/FPFiW0cxLCcggOBIBNPsj73pNVQ Cc: "urn@ietf.org" Subject: Re: [urn] Some observations to add to the discussion X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 15:37:23 -0000 PiA+IEkndmUgYmVlbiB0b2xkIHRoYXQgdGhlIG9yaWdpbmFsIHdlYiBkZXNpZ24gYXNzdW1lZCB0 aGF0IHVzZXJzIHdvdWxkDQo+ID4gbmV2ZXIgYWN0dWFsbHkgaGF2ZSB0byBsb29rIGF0IGEgVVJM Ow0KDQpodHRwOi8vd3d3LmlldGYub3JnL3JmYy9yZmMxNjMwIGlzbid0IHRoZSBlYXJsaWVzdCBk b2N1bWVudCwgYnV0IA0KaXQncyBjbG9zZSBlbm91Z2guIE5vdGhpbmcgaW4gdGhlcmUgbWFrZXMg YW55IGFzc3VtcHRpb24gdGhhdA0KInVzZXJzIHdvdWxkIG5ldmVyIGFjdHVhbGx5IGhhdmUgdG8g bG9vayBhdCBhIFVSTCIuDQoNCkl0IGV4cGxpY2l0bHkgbWFrZXMgYSByZXF1aXJlbWVudCANCg0K ICAgICBQcmludGFibGUgICAgICAgICAgICAgICBJdCBpcyBwb3NzaWJsZSB0byBleHByZXNzIGFu eSBVUkkgdXNpbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDctYml0IEFTQ0lJIGNo YXJhY3RlcnMgc28gdGhhdCBVUklzIG1heSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGlmIG5lY2Vzc2FyeSwgYmUgcGFzc2VkIHVzaW5nIHBlbiBhbmQgaW5rLg0KDQp0aGUgZG9jdW1l bnRzIGFib3V0IHRoZSBvcmlnaW5hbCBkZXNpZ24gb2YgdGhlIHdlYiBhcmUgcmVhZGlseSBhdmFp bGFibGUNCg0K From nobody Wed Jul 9 03:20:43 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9C51A03E2 for ; Wed, 9 Jul 2014 03:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=no 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 73Bmps26P58D for ; Wed, 9 Jul 2014 03:20:41 -0700 (PDT) Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2771A03BE for ; Wed, 9 Jul 2014 03:20:40 -0700 (PDT) Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 62C6732E586; Wed, 9 Jul 2014 19:20:39 +0900 (JST) Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 1588_4b0b_6e521bae_4853_4e0f_8e11_4c0436fe70a1; Wed, 09 Jul 2014 19:20:38 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 5A00EBF4BA; Wed, 9 Jul 2014 19:20:38 +0900 (JST) Message-ID: <53BD1767.5010206@it.aoyama.ac.jp> Date: Wed, 09 Jul 2014 19:20:23 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Larry Masinter , "Dale R. Worley" , John C Klensin References: <201407031853.s63IrIWC027924@hobgoblin.ariadne.com> <53BA571B.9080909@it.aoyama.ac.jp> <201407072239.s67MdvwL009690@hobgoblin.ariadne.com> <201407081436.s68EaVRx015522@hobgoblin.ariadne.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/urn/Xb08cg9jXKi4mr1CnkeuLAMCom8 Cc: "urn@ietf.org" Subject: [urn] Users and URIs (was: Re: Some observations to add to the discussion) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 10:20:42 -0000 On 2014/07/09 00:37, Larry Masinter wrote: >>> I've been told that the original web design assumed that users would >>> never actually have to look at a URL; > > http://www.ietf.org/rfc/rfc1630 isn't the earliest document, but > it's close enough. Nothing in there makes any assumption that > "users would never actually have to look at a URL". > > It explicitly makes a requirement > > Printable It is possible to express any URI using > 7-bit ASCII characters so that URIs may, > if necessary, be passed using pen and ink. > > the documents about the original design of the web are readily available I think the situation isn't black and white: Good Web stuff is designed so that you never have to look at an URI/IRI if you don't want, but you always can if you need. [1] Good Web stuff is designed so that those URIs/IRIs that have a high chance of being used on napkins,... and in user's heads are short and easily memorable, and others aren't unnecessarily lengthy. There are many ways to get to what one wants (e.g. a document), only some of which go through URIs/IRIs. And only a part of the later require keyboarding or similar manual work. Clicking on links in mails, copypasting, and so on are often sufficient. US-ASCII is a good lowest common denominator, but it is lower for some (roughly the Western Hemisphere) than for others, and if the 'others' are the main users, then it makes sense to inconvenience some very few with %-encoding if that lowers the bar for the main user group(s). Long sequences of %-encoding are definitely not what you want to deal with on average [2]. But even a simple ISBN is 10 or 13 digits, often without spaces, and difficult to type in correctly. With respect to URNs and libraries, I would expect neither the average library user nor the technical expert librarian to have to look at URNs and input them except in very rare cases. Regards, Martin. [1] People on this list might not believe it, but there are occasionally Web applications where all documents in the system have the same URI. The official system to publish documents for lectures,... at our University is such a system, it's a corporate product and a big pain... Fortunately I run my own server/system with some open source, which doesn't have these problems. [2] My students often use (Japanese) Wikipedia as a reference in some of their reports. Since about two years, I request that they use IRIs rather than URIs, because it's immediately clear to me what the article is referring to in the former, whereas the later is mostly just a long list of %-escaping. From nobody Wed Jul 9 06:05:37 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D55C1A063F for ; Wed, 9 Jul 2014 06:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.25 X-Spam-Level: X-Spam-Status: No, score=-6.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 gAC3HREek5fz for ; Wed, 9 Jul 2014 06:05:31 -0700 (PDT) Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 27ACB1A063B for ; Wed, 9 Jul 2014 06:05:31 -0700 (PDT) Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id 126B27EEE2; Wed, 9 Jul 2014 15:05:30 +0200 (CEST) From: "Svensson, Lars" To: =?Windows-1252?Q?=22Martin_J=2E_D=FCrst=22?= , Larry Masinter , "Dale R. Worley" , John C Klensin Thread-Topic: [urn] Users and URIs (was: Re: Some observations to add to the discussion) Thread-Index: Ac+bdnL2uBs+W6SrQ6OdB7SGjbnSFw== Date: Wed, 9 Jul 2014 13:05:28 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EFA44639BE@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.53] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/Xrq2evgAExiV-A9tglr8c18clf4 Cc: "urn@ietf.org" Subject: Re: [urn] Users and URIs (was: Re: Some observations to add to the discussion) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 13:05:35 -0000 > >>> I've been told that the original web design assumed that users would > >>> never actually have to look at a URL; > > > > http://www.ietf.org/rfc/rfc1630 isn't the earliest document, but > > it's close enough. Nothing in there makes any assumption that > > "users would never actually have to look at a URL". > > > > It explicitly makes a requirement > > > > Printable It is possible to express any URI using > > 7-bit ASCII characters so that URIs may, > > if necessary, be passed using pen and in= k. > > > > the documents about the original design of the web are readily availabl= e >=20 [...] > Good Web stuff is designed so that those URIs/IRIs that have a high > chance of being used on napkins,... and in user's heads are short and > easily memorable, and others aren't unnecessarily lengthy. =20 > Long sequences of %-encoding are definitely not what you want to deal > with on average [2]. But even a simple ISBN is 10 or 13 digits, often > without spaces, and difficult to type in correctly. >=20 > With respect to URNs and libraries, I would expect neither the average > library user nor the technical expert librarian to have to look at URNs > and input them except in very rare cases. In many settings we (the German National Library) encourage authors to regi= ster a URN _before_ they deliver the digital publication to us for long ter= m preservation, so that they can print it on the title page (or in the impr= int or somewhere else in the publication). The use case is, that even if th= e resolver should be unavailable at some future date, someone who has found= a reference with a URN in it should have the possibility to go to a genera= l-purpose search engine and enter the urn string in order to find a copy of= the publication since the URN will indexed. In our catalogue, we present the URN to end users, cf. [1]. I have not yet = heard of any users who found it confusing. [1] http://d-nb.info/1045320641 Best, Lars From nobody Wed Jul 9 08:44:15 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C621A0AF9 for ; Wed, 9 Jul 2014 08:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 ne2-78Zwqcs5 for ; Wed, 9 Jul 2014 08:44:11 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E991A0AF4 for ; Wed, 9 Jul 2014 08:44:11 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1X4tz4-000K4S-TN; Wed, 09 Jul 2014 11:40:38 -0400 Date: Wed, 09 Jul 2014 11:44:05 -0400 From: John C Klensin To: "Dale R. Worley" Message-ID: In-Reply-To: <201407081436.s68EaVRx015522@hobgoblin.ariadne.com> References: <201407031853.s63IrIWC027924@hobgoblin.ariadne.com> <53BA571B.9080909@it.aoyama.ac.jp> <201407072239.s67MdvwL009690@hobgoblin.ariadne.com> <201407081436.s68EaVRx015522@hobgoblin.ariadne.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/urn/8VorzuP0zNo0qxEjN88LQHPzJkw Cc: urn@ietf.org Subject: Re: [urn] Some observations to add to the discussion X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 15:44:14 -0000 --On Tuesday, July 08, 2014 10:36 -0400 "Dale R. Worley" wrote: >> From: John C Klensin >=20 >> I've been told that the original web design assumed that >> users would never actually have to look at a URL; >=20 > That's a point, but it's one that cuts both ways: While it is > assumed now that people will both type and look at URLs, my > browser will accept a wide range of URL-like strings and > (either visibly or invisibly) translate them into strings that > conform to the URL syntax. Yes. Many (or most) browsers will, and that is, if I understand correctly, part of time impetus to change the URL spec (and deviate from or obsolete 3986 in the process) so that the URL definition is more closely bound to what browsers will accept and translate. =20 I've actually got a lot of sympathy for that "make the standard conform to reality" approach, especially if it would result in all browsers doing the same thing with now-non-conforming strings: different browsers using different heuristics can create attack vectors that no one needs. At the same time, it is difficult to hear what sounds like "we've already violated the URI standard enough for the URL case that we get to change it unilaterally and move toward unilaterally repudiating it" and "URNs should be held strictly conformant to all details of the URI standard, to the point that providing needed functionality requires kludges" from almost the same direction. > So it does not seem to me to be an unreasonable expectation > that user interfaces will accept from the user, say: >=20 > = urn:ng:=E6=8E=8C=E6=8F=A1=E5=B8=B6=E4=BA=BA=E5=B8=A6=E5=9B=A2=E9=98= =9F=E7=9A=84=E6=96=B9=E6=B3=95=E2=95=9F=E5=9F=B9=E5=85=BB=E8=A8=93= =E7=BB=83=EF=BC=8C=E6=BA=9D >=20 > but actually put on the wire=20 >> = urn:ng:%e6%8e%8c%e6%8f%a1%e5%b8%b6%e4%ba%ba%e5%b8%a6%e5%9b%a2% >> = e9%98%9f%e7%9a%84%e6%96%b9%e6%b3%95%e2%95%9f%e5%9f%b9%e5%85%bb >> = %e8%a8%93%e7%bb%83%ef%bc%8c%e6%ba%9d%e9%80%9a%e4%ba%92%e5%8a%a >> = 8%ef%bc%8c%e5%9b%a2%e9%9a%8a%e6%b0%9b%e5%9c%8d%e7%88%84%e9%80% >> a0%ef%bc%8c%e6%bf%80%e5%8b%b5%e8%a9%8f%e8%ae%a1 >=20 > and vice-versa. Sure. But I would expect that, unless that conversion (in both directions) is a requirement (no IETF standard I know of today, including 3987, requires that) and that requirement is observed and implemented correctly by everyone, end users will end up either seeing the second string and making a botch of it, or seeing the first string and copying and pasting it in a way that doesn't quite work. =20 In that regard, I note that the native-character string above appears to contain an ASCII comma as the next-to-last character. It clearly is not. Unless the conversion tool I used failed, the coded sequence claims that it is U+8A4F, "=E8=A9=8F". It = clearly isn't that either, so, well, Q.E.D. I also note that a big deal has been made about what does and does not count when one is trying to consider whether two putative URNs (or URIs more generally) are equal to each other. By forcing everything into the NSS using encoding tricks, you completely preempt that discussion in favor of "everything counts in comparisons". > However, at this point I think we need more concrete input, as > the remaining devils are in the details; first, people who > work daily with identifiers, and second, people who build user > interfaces for people of the first type. Yes, but see several recent notes. john From nobody Wed Jul 9 13:32:44 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DD71ACAD6 for ; Wed, 9 Jul 2014 13:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 1TlIjGljcV6o for ; Wed, 9 Jul 2014 13:32:43 -0700 (PDT) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 880C81A0421 for ; Wed, 9 Jul 2014 13:32:43 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id lf12so8385162vcb.32 for ; Wed, 09 Jul 2014 13:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=M16xQxRD2qUT0DM12mlDKKoBV5Wm7UT+tIbRt6X0YoY=; b=d400OMGymAAXvmRqFFmNx+yY+E1FKLT8jsbsfMnegHqCb2hCAvzq0NlqdaVYUqZREf elHJCCrQE0T1qRtEZdweuNcgMY8AY/IEDRol4f6CgcHXOHeTSxW+AIS0CygQaDUbYIpK 8yJ7D2lwAoYw5vMH15QBv4eYP4CUTEKp7svZGoYwctI6egbqcQyN9IBJTHF+nNJPz7ZN n27Fzc28uDrRyE0wSXPXwQ/LyY86G8wKplmavugFsNdY7sxSBaTGCF9zNoq4O82m9YK9 cg7LRuHVjkrN16xo8q2ronfF+phBGtQnT8FzLKaLkMpXBGcsaVdmFA2BaffC+uc8iU27 V2/A== MIME-Version: 1.0 X-Received: by 10.58.247.167 with SMTP id yf7mr2138381vec.46.1404937962776; Wed, 09 Jul 2014 13:32:42 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.106.73 with HTTP; Wed, 9 Jul 2014 13:32:42 -0700 (PDT) Date: Wed, 9 Jul 2014 16:32:42 -0400 X-Google-Sender-Auth: XPjSrcra6rh4GvND5hhFtjQO4YY Message-ID: From: Barry Leiba To: "urn@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/urn/fOpVsd8gnJrku3FYIAzYIRsrCYs Subject: [urn] URNs, URIs, this working group's job, and some steering X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 20:32:44 -0000 Hey, all. I'd like to throw in an AD interrupt designed to steer the recent discussion a bit. What this working group needs to do is update the various URN specs, specifically taking into account the needs of the library community -- as we update the specs for ISBN and the others. We determined that we were getting stuck in some of the discussions by a disparity in the needs we were considering and the restrictions that RFC 3986 puts on URNs. Of course, there's an issue here: the URN specs all predate 3986, and 3986 said things about URNs with a different view and different needs in mind. John has proposed one way of dealing with this issue and allowing us to make the kinds of changes we need to make. As we discuss John's proposal we have to keep in mind what this working group's goal is, and work toward it. That means that it's valid to say that John's proposal isn't the right or best way, but that has to go with a technical discussion of an alternative proposal that can achieve our goals. We're at a point, I think, where we have to move ourselves out of what I call the "Grand Unified Theory of URIs", and think about the specific needs for URNs among a growing set of disparate communities that use them (I've processed at least seven documents dealing with URN namespaces in my 2.5 years as AD, so "growing" is quite accurate). If we hold on to an ideal that doesn't serve the needs of the users, no one wins. So let's please make sure that as we argue against anything that's proposed, we have an alternative proposal that keeps us moving in the right direction. Barry, Applications AD From nobody Thu Jul 10 00:01:57 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06BD1A0B17 for ; Thu, 10 Jul 2014 00:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 dOK4RUkrawj5 for ; Thu, 10 Jul 2014 00:01:49 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E631A0361 for ; Thu, 10 Jul 2014 00:01:49 -0700 (PDT) Received: from [192.168.1.106] ([93.217.89.248]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MZ7bs-1XJUsm1Hjg-00KzpW; Thu, 10 Jul 2014 09:01:44 +0200 Message-ID: <53BE3A55.3020806@gmx.de> Date: Thu, 10 Jul 2014 09:01:41 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Barry Leiba , "urn@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:u1VIYVDb3wqlp+seXU9hmWdxO1HqbY+jUPlngGrIr1w6SxJSJvD w/3WqQ5HQHNs2J3IIF3S1s/oPqpgRpkxqMOnb1eMHgzl5It8TEbe/pHz150K7AcUQmHOi3E InLhnf/Ug46Px8wt3RqI2hwu7KXUuNeggddZUnIdnxS4/SWsecWTKXha16gLeATBa+FFHu2 QSM0ODIA+8isvBqAGnC8A== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/1AFIYqQZmpaCMICxCb9TWlRTT_8 Subject: Re: [urn] URNs, URIs, this working group's job, and some steering X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 07:01:53 -0000 On 2014-07-09 22:32, Barry Leiba wrote: > Hey, all. > I'd like to throw in an AD interrupt designed to steer the recent > discussion a bit. > > What this working group needs to do is update the various URN specs, > specifically taking into account the needs of the library community -- > as we update the specs for ISBN and the others. > > We determined that we were getting stuck in some of the discussions by > a disparity in the needs we were considering and the restrictions that > RFC 3986 puts on URNs. Of course, there's an issue here: the URN > specs all predate 3986, and 3986 said things about URNs with a > different view and different needs in mind. > ... I believe what's needed is a *concise* explanation about what particular bits in RFC 3986 are considered a problem. Do we have that? (Pointers sufficient). Best regards, Julian From nobody Thu Jul 10 03:39:17 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDB11A03DB for ; Thu, 10 Jul 2014 03:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham 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 pOyF5QGsmQdy for ; Thu, 10 Jul 2014 03:39:11 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C4431B286F for ; Thu, 10 Jul 2014 03:39:09 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s6AAd6DP025683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 10 Jul 2014 13:39:07 +0300 Message-ID: <53BE6D4A.3050206@helsinki.fi> Date: Thu, 10 Jul 2014 13:39:06 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: urn@ietf.org References: <53BE3A55.3020806@gmx.de> In-Reply-To: <53BE3A55.3020806@gmx.de> Content-Type: multipart/alternative; boundary="------------000401090109060503000102" Archived-At: http://mailarchive.ietf.org/arch/msg/urn/HRoXEdHaHV_Pg9YYcmuhm1wlfcI Subject: Re: [urn] URNs, URIs, this working group's job, and some steering X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 10:39:15 -0000 This is a multi-part message in MIME format. --------------000401090109060503000102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, On 10.7.2014 10:01, Julian Reschke wrote: > On 2014-07-09 22:32, Barry Leiba wrote: >> Hey, all. >> I'd like to throw in an AD interrupt designed to steer the recent >> discussion a bit. >> >> What this working group needs to do is update the various URN specs, >> specifically taking into account the needs of the library community -- >> as we update the specs for ISBN and the others. >> >> We determined that we were getting stuck in some of the discussions by >> a disparity in the needs we were considering and the restrictions that >> RFC 3986 puts on URNs. Of course, there's an issue here: the URN >> specs all predate 3986, and 3986 said things about URNs with a >> different view and different needs in mind. >> ... > > I believe what's needed is a *concise* explanation about what > particular bits in RFC 3986 are considered a problem. Do we have that? > (Pointers sufficient). This issue has been discussed several times, but once more the main issues memory institutions have with the RFC 3986: 1. The general idea that every URI is an identifier, and the very loose specification of "identifier" built in into such a statement which does not match with the meaning the term identifier has in the URN context. Does juha.hakala@helsinki.fi identify me or my mail box or both? And if we agree that juha.hakala@helsinki.fi does identify me, is it good identifier in the URN sense of the word (unique and persistent)? To me my email address is neither unique (I have other email addresses) nor persistent (it won't work after I leave the university) and therefore it does not properly identify me, but it seems that those who endorse RFC 3986 disagree, or just ignore some consequences of the basic assumptions made in RFC 3986. 2. Regarding query, chapter RFC 3986 says: > The query component contains non-hierarchical data that, along with > data in the path component (Section 3.3), serves to identify a > resource within the scope of the URI's scheme and naming authority > (if any). It is difficult to tell what "within the scope of the URI's scheme and naming authority" means. Or, what happens if there is no naming authority. Obviously not all URIs with query are identifiers after all. And if query components do identify something, what would it be. For instance in this URI: http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve& query=dinosaur&maximumRecords=1&recordSchema=dc we might say that http://z39.50.loc.gov:7090 is an identifier of the Library of Congress OPAC. The SRU query changes the URI so that it becomes an identifier of a single record retrieved from that database. And that record would not remain the same; each time a new record with the word dinosaur in it is added to the database, it replaces the previous record. OK, we can say that the quote from RFC 3986 above applies, and the URI in the example is not an identifier at all in spite of being URI. But without precise guidelines on how to apply "within the scope of the URI's scheme and naming authority" we are left with the situation where any URI with query component may or may not identify something. In the URN context, NSS is stable and identifies the resource. Queries are attached to established URNs when necessary, depending on what resolution services the users want. But they do not have any role in identification, and they are not meant to be persistent since the technical infrastructure which provides services is changing. That is, a user may see a URN and tick a box saying "do you want metadata about this resource", and behind the screen the user interface app builds a valid query string and adds it to the URN. 3. RFC 3986 says the following about fragment in chapter 3.5: > The fragment identifier component of a URI allows indirect > identification of a secondary resource by reference to a primary > resource and additional identifying information. The identified > secondary resource may be some portion or subset of the primary > resource, some view on representations of the primary resource, or > some other resource defined or described by those representations. Technically there is no problem here. The entire resource is always retrieved, and fragment is only applied by the client such as a Web browser. So fragments have a priori nothing to do with the URN resolution. Typical use case is a researcher who cites a document, and adds a fragment to the URN so that readers who click the link are taken directly to the relevant location within the referred resource. The problem is that if fragments are identifiers, then anyone can identify any bits and pieces within resource that has previously been identified by URNs. Such expansion of the scope of e.g. ISBN is not possible; readers can not assign identifiers to chapters of books as they wish. But the whole problem vanishes if fragment is not an identifier in the URN context. Since RFC 3986 was published, people have invented all kinds of interesting usages for fragment. The more I know about them, the harder it is for me to see what fragments do identify. For instance, does this |http://example.com/document.txt#match=[rR][fF][cC] | identify every "rfc" and "RFC" in the target document? Or does it just find them? To sum up, probably the main challenge we are facing is that "to identify" means different things to different communities. Worse, identification in the URN context does not mean the same as it means in the URI context. In the latter, the meaning of the term has been expanded so that the communities which have a lot of experience about identification of resources such as libraries don't really agree with it anymore. URN definition of the term, on the other hand, is OK. Juha > > Best regards, Julian > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 --------------000401090109060503000102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello,

On 10.7.2014 10:01, Julian Reschke wrote:
On 2014-07-09 22:32, Barry Leiba wrote:
Hey, all.
I'd like to throw in an AD interrupt designed to steer the recent
discussion a bit.

What this working group needs to do is update the various URN specs,
specifically taking into account the needs of the library community --
as we update the specs for ISBN and the others.

We determined that we were getting stuck in some of the discussions by
a disparity in the needs we were considering and the restrictions that
RFC 3986 puts on URNs.  Of course, there's an issue here: the URN
specs all predate 3986, and 3986 said things about URNs with a
different view and different needs in mind.
...

I believe what's needed is a *concise* explanation about what particular bits in RFC 3986 are considered a problem. Do we have that? (Pointers sufficient).

This issue has been discussed several times, but once more the main issues memory institutions have with the RFC 3986:

1. The general idea that every URI is an identifier,  and the very loose specification of "identifier" built in into such a statement which does not match with the meaning the term identifier has in the URN context.

Does juha.hakala@helsinki.fi identify me or my mail box or both? And if we agree that juha.hakala@helsinki.fi does identify me, is it good identifier in the URN sense of the word (unique and persistent)? To me my email address is neither unique (I have other email addresses) nor persistent (it won't work after I leave the university) and therefore it does not properly identify me, but it seems that those who endorse RFC 3986 disagree, or just ignore some consequences of the basic assumptions made in RFC 3986.   

2. Regarding query, chapter RFC 3986 says: 

The query component contains non-hierarchical data that, along with
   data in the path component (Section 3.3), serves to identify a
   resource within the scope of the URI's scheme and naming authority
   (if any).

It is difficult to tell what "within the scope of the URI's scheme and naming authority" means. Or, what happens if there is no naming authority. Obviously not all URIs with query are identifiers after all.

And if query components do identify something, what would it be. For instance in this URI:

http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&
query=dinosaur&maximumRecords=1&recordSchema=dc

we might say that http://z39.50.loc.gov:7090 is an identifier of the Library of Congress OPAC. The SRU query changes the URI so that it becomes an identifier of a single record retrieved from that database. And that record would not remain the same; each time a new record with the word dinosaur in it is added to the database, it replaces the previous record.

OK, we can say that the quote from RFC 3986 above applies, and the URI in the example is not an identifier at all in spite of being URI. But without precise guidelines on how to apply "within the scope of the URI's scheme and naming authority" we are left with the situation where any URI with query component may or may not identify something.

In the URN context, NSS is stable and identifies the resource. Queries are attached to established URNs when necessary, depending on what resolution services the users want. But they do not have any role in identification, and they are not meant to be persistent since the technical infrastructure which provides services is changing. That is, a user may see a URN and tick a box saying "do you want metadata about this resource", and behind the screen the user interface app builds a valid query string and adds it to the URN.   

3. RFC 3986 says the following about fragment in chapter 3.5:

The fragment identifier component of a URI allows indirect
   identification of a secondary resource by reference to a primary
   resource and additional identifying information.  The identified
   secondary resource may be some portion or subset of the primary
   resource, some view on representations of the primary resource, or
   some other resource defined or described by those representations.

Technically there is no problem here. The entire resource is always retrieved, and fragment is only applied by the client such as a Web browser. So fragments have a priori nothing to do with the URN resolution.

Typical use case is a researcher who cites a document, and adds a fragment to the URN so that readers who click the link are taken directly to the relevant location within the referred resource.

The problem is that if fragments are identifiers, then anyone can identify any bits and pieces within resource that has previously been identified by URNs. Such expansion of the scope of e.g. ISBN is not possible; readers can not assign identifiers to chapters of books as they wish. But the whole problem vanishes if fragment is not an identifier in the URN context.

Since RFC 3986 was published, people have invented all kinds of interesting usages for fragment. The more I know about them, the harder it is for me to see what fragments do identify. For instance, does this

http://example.com/document.txt#match=[rR][fF][cC]

identify every "rfc" and "RFC" in the target document? Or does it just find them?

To sum up, probably the main challenge we are facing is that "to identify" means different things to different communities. Worse, identification in the URN context does not mean the same as it means in the URI context. In the latter, the meaning of the term has been expanded so that the communities which have a lot of experience about identification of resources such as libraries don't really agree with it anymore. URN definition of the term, on the other hand, is OK. 

Juha

 

Best regards, Julian

_______________________________________________
urn mailing list
urn@ietf.org
https://www.ietf.org/mailman/listinfo/urn 


-- 

 Juha Hakala
 Senior advisor

 The National Library of Finland
 Library Network Services 
 P.O.Box 26 (Teollisuuskatu 23)
 FIN-00014 Helsinki University
 Tel. +358 9 191 44293
 Mobile +358 50 3827678
--------------000401090109060503000102-- From nobody Thu Jul 10 06:01:16 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F15C1B28D2 for ; Thu, 10 Jul 2014 06:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham 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 vmS9-Llg-orM for ; Thu, 10 Jul 2014 06:01:11 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB90E1A0444 for ; Thu, 10 Jul 2014 06:01:10 -0700 (PDT) Received: from [192.168.1.106] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MDn8s-1WoDD018fu-00H5l5; Thu, 10 Jul 2014 15:01:08 +0200 Message-ID: <53BE8E91.1010406@gmx.de> Date: Thu, 10 Jul 2014 15:01:05 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Juha Hakala , urn@ietf.org References: <53BE3A55.3020806@gmx.de> <53BE6D4A.3050206@helsinki.fi> In-Reply-To: <53BE6D4A.3050206@helsinki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:zoGM48oFpMkRA44G9hogsscxU16kcsdQfmQtl6BnqhcPjIwiTPp GH9rDJ5FMN8mR4OwJIeJdMy26uUzYjLg4cjxHqX0cEZg9heQvcIzekYE9JFMgzdRo/kD2iP Z+qwTULuO79hmyz+DkHjxsCpWxCOnm10nNgO9KXQZiU5V+cb5cVgagO7qwqtMBUQXpAZ0v9 Iz3JoopN4iHwR3PeV7A2A== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/evIFWqDGTsUJFcJbAKVULHsa-Og Subject: Re: [urn] URNs, URIs, this working group's job, and some steering X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 13:01:14 -0000 Hi Juha, thanks for the feedback. > This issue has been discussed several times, but once more the main > issues memory institutions have with the RFC 3986: > > 1. The general idea that every URI is an identifier, and the very loose > specification of "identifier" built in into such a statement which does > not match with the meaning the term identifier has in the URN context. So that's a terminology problem. I think it's totally OK if the URI scheme "urn" has stronger requirements on a specific term, as long as it doesn't contradict RFC 3986. > Does juha.hakala@helsinki.fi identify me or my mail box or both? And if > we agree that juha.hakala@helsinki.fi does identify me, is it good > identifier in the URN sense of the word (unique and persistent)? To me > my email address is neither unique (I have other email addresses) nor > persistent (it won't work after I leave the university) and therefore it > does not properly identify me, but it seems that those who endorse RFC > 3986 disagree, or just ignore some consequences of the basic assumptions > made in RFC 3986. Assuming you mean "mailto:...". It is an identifier of a mailbox (as per ). Whether it is *your* mailbox (or even an in-use mailbox) can vary over time. I understand that the URN community isn't interested in identifiers that do not offer stability for your use cases, but that's hardly a defect of 3986. URNs are still URIs if you have a higher bar on identification. What would be a problem is the reverse case. > 2. Regarding query, chapter RFC 3986 says: > >> The query component contains non-hierarchical data that, along with >> data in the path component (Section 3.3), serves to identify a >> resource within the scope of the URI's scheme and naming authority >> (if any). > > It is difficult to tell what "within the scope of the URI's scheme and > naming authority" means. Or, what happens if there is no naming > authority. Obviously not all URIs with query are identifiers after all. No, that's not only not obvious, it's wrong. Any *URI* by definition is an identifier. I think this definition is pretty clear; do you have any specific proposed change that would make it work better for you? > And if query components do identify something, what would it be. For > instance in this URI: > > http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve& > query=dinosaur&maximumRecords=1&recordSchema=dc > > > we might say that http://z39.50.loc.gov:7090 is an identifier of the > Library of Congress OPAC. The SRU query changes the URI so that it > becomes an identifier of a single record retrieved from that database. > And that record would not remain the same; each time a new record with > the word dinosaur in it is added to the database, it replaces the > previous record. Yes. That's a feature. > OK, we can say that the quote from RFC 3986 above applies, and the URI > in the example is not an identifier at all in spite of being URI. But I don't see where RFC 3986 says that. > without precise guidelines on how to apply "within the scope of the > URI's scheme and naming authority" we are left with the situation where > any URI with query component may or may not identify something. They all identify something. The "scope of the URI's scheme and naming authority" is the hook where this WG, writing the spec for the "URN" scheme, and authors of NSS specs, can add additional semantics on top. > In the URN context, NSS is stable and identifies the resource. Queries > are attached to established URNs when necessary, depending on what > resolution services the users want. But they do not have any role in > identification, and they are not meant to be persistent since the > technical infrastructure which provides services is changing. That is, a > user may see a URN and tick a box saying "do you want metadata about > this resource", and behind the screen the user interface app builds a > valid query string and adds it to the URN. That's not a problem as long as the spec for the "URN" scheme says so. > 3. RFC 3986 says the following about fragment in chapter 3.5: > >> The fragment identifier component of a URI allows indirect >> identification of a secondary resource by reference to a primary >> resource and additional identifying information. The identified >> secondary resource may be some portion or subset of the primary >> resource, some view on representations of the primary resource, or >> some other resource defined or described by those representations. > > Technically there is no problem here. The entire resource is always > retrieved, and fragment is only applied by the client such as a Web > browser. So fragments have a priori nothing to do with the URN resolution. > > Typical use case is a researcher who cites a document, and adds a > fragment to the URN so that readers who click the link are taken > directly to the relevant location within the referred resource. > > The problem is that if fragments are identifiers, then anyone can > identify any bits and pieces within resource that has previously been > identified by URNs. Such expansion of the scope of e.g. ISBN is not > possible; readers can not assign identifiers to chapters of books as > they wish. But the whole problem vanishes if fragment is not an > identifier in the URN context. RFC 3986 goes on saying: "The semantics of a fragment identifier are defined by the set of representations that might result from a retrieval action on the primary resource. The fragment's format and resolution is therefore dependent on the media type [RFC2046] of a potentially retrieved representation, even though such a retrieval is only performed if the URI is dereferenced. If no such representation exists, then the semantics of the fragment are considered unknown and are effectively unconstrained. Fragment identifier semantics are independent of the URI scheme and thus cannot be redefined by scheme specifications." So essentially the semantics depend on the format you get on retrieval, and if there is no such thing, it's unknown. That sounds to me that unless you actually define a resolution service, you'd better not use fragments. > Since RFC 3986 was published, people have invented all kinds of > interesting usages for fragment. The more I know about them, the harder > it is for me to see what fragments do identify. For instance, does this > > |http://example.com/document.txt#match=[rR][fF][cC] > | > identify every "rfc" and "RFC" in the target document? Or does it just > find them? It depends on the media type and the fragment identifier semantics for that type. > To sum up, probably the main challenge we are facing is that "to > identify" means different things to different communities. Worse, > identification in the URN context does not mean the same as it means in > the URI context. In the latter, the meaning of the term has been > expanded so that the communities which have a lot of experience about > identification of resources such as libraries don't really agree with it > anymore. URN definition of the term, on the other hand, is OK. So we need to split URNs out of the URI space because URN's requirements for the term "identify" are stronger than those in RFC 3986? Seriously? After all, the spec for the "URN" scheme is free to redefine "identify" for URNs, as long as it's consistent with the looser definition in 3986. Best regards, Julian From nobody Thu Jul 10 09:56:45 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773101A0ABF for ; Thu, 10 Jul 2014 09:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham 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 jhfDEl-4Qu7C for ; Thu, 10 Jul 2014 09:56:42 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB8F11A0AA8 for ; Thu, 10 Jul 2014 09:56:41 -0700 (PDT) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB305.namprd02.prod.outlook.com (10.141.91.17) with Microsoft SMTP Server (TLS) id 15.0.980.8; Thu, 10 Jul 2014 16:56:40 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0980.000; Thu, 10 Jul 2014 16:56:39 +0000 From: Larry Masinter To: "julian.reschke@gmx.de" , Juha Hakala , "urn@ietf.org" Thread-Topic: [urn] URNs, URIs, this working group's job, and some steering Thread-Index: AQHPm7UORHpPXPfe2kqo257kMudT7puY4i+AgAA8vwCAACesgIAAI4Nw Date: Thu, 10 Jul 2014 16:56:39 +0000 Message-ID: References: <53BE3A55.3020806@gmx.de> <53BE6D4A.3050206@helsinki.fi> <53BE8E91.1010406@gmx.de> In-Reply-To: <53BE8E91.1010406@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0268246AE7 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(51444003)(24454002)(92566001)(33646001)(87936001)(93886003)(21056001)(15202345003)(66066001)(80022001)(46102001)(15975445006)(19580395003)(20776003)(85306003)(76482001)(561944003)(74502001)(76576001)(2656002)(83322001)(99396002)(64706001)(74662001)(99286002)(95666004)(81342001)(31966008)(81542001)(106356001)(107046002)(83072002)(85852003)(86362001)(77982001)(101416001)(79102001)(50986999)(76176999)(54356999)(74316001)(106116001)(105586002)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB305; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com Archived-At: http://mailarchive.ietf.org/arch/msg/urn/UYpgZ2Fo0Qh95Xzul2H-x8xZMpo Cc: "Dave Thaler \(dthaler@microsoft.com\)" Subject: Re: [urn] URNs, URIs, this working group's job, and some steering X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 16:56:44 -0000 KzEgdG8gSnVsaWFuJ3MgY29tbWVudHMsIGhvd2V2ZXI6DQoNCkJhcnJ5IExlaWJhIHdyb3RlOg0K PiBUaGF0IG1lYW5zIHRoYXQgaXQncyB2YWxpZCB0byBzYXkgdGhhdCBKb2huJ3MgcHJvcG9zYWwg aXNuJ3QgdGhlIHJpZ2h0DQo+IG9yIGJlc3Qgd2F5LCBidXQgdGhhdCBoYXMgdG8gZ28gd2l0aCBh IHRlY2huaWNhbCBkaXNjdXNzaW9uIG9mIGFuDQo+IGFsdGVybmF0aXZlIHByb3Bvc2FsIHRoYXQg Y2FuIGFjaGlldmUgb3VyIGdvYWxzLg0KDQpJbiB0aGF0IHNwaXJpdCwgaGVyZSBpcyBhbiBvdXRs aW5lIG9mIGFuIGFsdGVybmF0aXZlIHByb3Bvc2FsIHdoaWNoDQpJIHRoaW5rIHdvdWxkIGhlbHAg VVJOYmlzIHRvIGFjY29tcGxpc2ggaXRzIGdvYWxzLCBldmVuIGlmDQpub3QgYWJzb2x1dGVseSBu ZWNlc3NhcnkuDQoNCkkgdGhpbmsgdGhhdCB0aGVzZSB1cGRhdGVzIHRvIDM5ODYgd291bGQgYmUg DQpjb25zaXN0ZW50IHdpdGggcmVhbCBVUkkgdXNlLCBhbmQgZ2l2ZSB0aGUgVVJOYmlzDQp3b3Jr aW5nIGdyb3VwIG1vcmUgcm9wZSB0byBtYWtlIHRoZSBjaGFuZ2VzIHdhbnRlZCwNCmZvciB0aG9z ZSBVUk4gbmFtZXNwYWNlcyAgdXNlZCB0byBpZGVudGlmeSANCmxvY2F0aW9uLWluZGVwZW5kZW50 IHN0YXRpYyBkb2N1bWVudHMgaW4NCmRpZ2l0YWwgbGlicmFyeSBjb250ZXh0cywgYnV0IHdpdGhv dXQgc3RlcHBpbmcgb24gDQpvdGhlciBraW5kcyBvZiBVUk5zIGFuZCBhcHBsaWNhdGlvbnMgb2Yg dGhlbSwNCm9yIGFwcGVhcmluZyB0byBkaXNhbGxvdyBhIHVybiBpbiBjb250ZXh0cyB0aGF0DQpj dXJyZW50bHkgYWxsb3cgYSBVUkkgb3IgYW4gSVJJLg0KDQo9PT09PT09PT09PT09PT09PT09PT09 PT0NCjEuIEludGVncmF0ZSBJUkkgc28gdGhhdCB0aGUgc3VwcG9ydCBmb3Igbm9uLUFTQ0lJDQog ICAgVVJOcyBhcmUgY2xlYXJlci4gIA0KDQogICAgVVJOYmlzIGRvZXNuJ3QgbGlrZSAlLWhleCBl bmNvZGluZyBmb3Igbm9uLUFTQ0lJDQogICAgbmFtZXMsIHRoYXQncyBmaW5lLCBidXQgdGhlcmUn cyBubyBuZWVkIGlmIHVybg0KICAgIGlzIGRlZmluZWQgaW4gdGVybXMgb2YgSVJJLg0KDQogICAg Q291bGQgVVJOYmlzIHBsZWFzZSAocXVpY2tseSkgcmV2aWV3DQogICAgaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hcHBzYXdnLXVyaS1zY2hlbWUtcmVnDQogICAgYW5kIHNl ZSBpZiBpdCBpcyBzdWZmaWNpZW50IHRvIGFsbG93IHRoZSAidXJuOiIgVVJJDQogICAgIHNjaGVt ZSB0byBsZXQgbmFtaW5nIGF1dGhvcml0aWVzIGFzc2lnbiBuYW1lcw0KICAgIHdpdGggbm9uLUFT Q0lJIGNoYXJhY3RlcnM/DQoNCjIuIENsYXJpZnkgZXF1aXZhbGVuY2UgcmVsYXRpb25zaGlwcywg bWFraW5nIGl0IGNsZWFyDQogICAgdGhhdCBzY2hlbWVzIG1heSBkZWZpbmUgcGVyLXNjaGVtZSBl cXVpdmFsZW5jZQ0KICAgICByZWxhdGlvbnNoaXBzLg0KDQogICAgICBUaGlzIHdvdWxkIG1vcmUg Y2xlYXJseSBhbGxvdyBVUk5iaXMgdG8gZGVmaW5lDQogICAgICBhbiBlcXVpdmFsZW5jZSByZWxh dGlvbnNoaXAgZm9yIFVSTnMgd2hpY2gNCiAgICAgIGlnbm9yZWQgcXVlcnkgY29tcG9uZW50cyBm b3IgdGhlIHB1cnBvc2Ugb2YNCiAgICAgIGxpYnJhcnkgYXBwbGljYXRpb25zLCB3aGlsZSBsZXR0 aW5nIG90aGVyIGFwcGxpY2F0aW9ucw0KICAgICAgYW5kIHNjaGVtZXMgdXNlIG90aGVyIGVxdWl2 YWxlbmNlIHJlbGF0aW9uc2hpcHMuDQogICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWlyaS1jb21wYXJpc29uLTAyDQogICAgICB3YXMgYW4gYXR0ZW1wdCB0byBkbyBz bywgYW5kIGNvdWxkIGJlIGJyb3VnaHQNCiAgICAgIGZvcndhcmQuIFBsZWFzZSByZXZpZXcuDQoN CjMuIFVwZGF0ZSAjIGZyYWdtZW50IG1lYW5pbmcgYW5kIGxldCBpdCBiZQ0KICAgICBzY2hlbWUg ZGVwZW5kZW50Lg0KDQpJIHRoaW5rIGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gdXBkYXRlIHdoYXQg UkZDIDM5ODYNCnNheXMgYWJvdXQgIy1kZWxpbWl0ZWQgImZyYWdtZW50IGlkZW50aWZpZXJzIjoN Cg0KYSkgcG9pbnQgb3V0IHRoYXQgdGhlICJmcmFnbWVudCBpZGVudGlmaWVyIiBpcyB1c2VkDQog ICAgdG8gaW5kaWNhdGUgImluaXRpYWwgdmlldyIgb3IgInBlcnNwZWN0aXZlIiBvciANCiAgICAi c2NyaXB0IHBhcmFtZXRlcnMiLCBub3QganVzdCBhICJjb21wb25lbnQiLg0KYikgbGV0IHRoZSBp bnRlcnByZXRhdGlvbiBvZiBmcmFnbWVudHMgYmUgb3ZlcnJpZGRlbg0KICAgICBieSBzY2hlbWUg YW5kL29yIGNvbnRleHQgb2YgdXNlLCANCiAgICAgd2l0aCB0aGUgY3VycmVudCAnZGVmaW5lZCBi eSB0aGUgTUlNRSB0eXBlJyANCiAgICAgdGhlIGRlZmF1bHQsIGFwcGx5aW5nIHVubGVzcyBvdGhl cndpc2Ugc3BlY2lmaWVkDQogICAgdG8gYWxsIFVSSXMgdXNlZCBmb3IgcmV0cmlldmFsL2ZldGNo Lg0KYykgIExldCB0aGUgZGVmaW5pdGlvbiBvZiBmcmFnbWVudHMgZm9yIFVSTnMgDQogICAgIGJl IGRlbGVnYXRlZCB0byB0aGUgbmFtZXNwYWNlIGF1dGhvcml0eS4NCg0KDQo0LiBJIHdvdWxkIGFs c28gcHJvbW90ZSBvdGhlciBjaGFuZ2UgaW4gVVJOYmlzDQp0byBtb3JlIGNsZWFybHkgYXNzb2Np YXRlIFVSTnMgd2l0aCAibWFuYWdlZA0KcHJvY2Vzc2VzIiByYXRoZXIgdGhhbiAicGVybWFuZW50 IiwNCnNpbmNlIHBlcm1hbmVuY2UgaXMgbW9yZSBhIG1hdHRlciBvZiBpbnRlbnRpb24NCm9mIGFu ZCBmb3IgdGhlIG5hbWVzcGFjZSBhdXRob3JpdHksIGFuZCBnaXZlDQphIGJldHRlciBmcmFtZXdv cmsgZm9yIHRhbGtpbmcgYWJvdXQgdGhlIHVzZSBvZg0Kc2VydmljZXMgdGhhdCBvZmZlciB0byAn cmVzb2x2ZScgYSBVUk4gZXZlbiB3aGVuDQp0aGUgVVJOIGlzbid0IGRlZmluZWQgYXMgdGhlIHJl c3VsdCBvZiBhIHJlc29sdXRpb24NCnNlcnZpY2UgKHdoaWNoIG1vc3QgYXJlbuKAmXQuKQ0KDQpU aGlzIGlzbid0IGFic29sdXRlbHkgbmVjZXNzYXJ5IGJ1dCBpdCB3b3VsZA0KcmVkdWNlIG11Y2gg b2YgdGhlIGNvbmZ1c2lvbiBhYm91dCBVUk5zDQphbmQgdGhlaXIgJ2Z1bmRhbWVudGFsIGRpZmZl cmVuY2UnIGZyb20gVVJJcy4NCg0KTGFycnkNCi0tDQpodHRwOi8vbGFycnkubWFzaW50ZXIubmV0 DQoNCg== From nobody Thu Jul 10 13:50:15 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0481B2A00 for ; Thu, 10 Jul 2014 13:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham 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 yXedUKnOd9uz for ; Thu, 10 Jul 2014 13:50:08 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4991B2A02 for ; Thu, 10 Jul 2014 13:50:08 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta13.westchester.pa.mail.comcast.net with comcast id QjtK1o0060SCNGk5Dkq7qq; Thu, 10 Jul 2014 20:50:07 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta09.westchester.pa.mail.comcast.net with comcast id Qkq71o00B1KKtkw3Vkq7vM; Thu, 10 Jul 2014 20:50:07 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s6AKo5VO008756; Thu, 10 Jul 2014 16:50:05 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s6AKo5K9008755; Thu, 10 Jul 2014 16:50:05 -0400 Date: Thu, 10 Jul 2014 16:50:05 -0400 Message-Id: <201407102050.s6AKo5K9008755@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Juha Hakala In-reply-to: <53BE6D4A.3050206@helsinki.fi> (juha.hakala@helsinki.fi) References: <53BE3A55.3020806@gmx.de> <53BE6D4A.3050206@helsinki.fi> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405025407; bh=Y/K+yaa3HEyeDcIE5ZPi7VTOvRepcnpE8ELWfIJvNWQ=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=IkpaNqapjANvUuncgTOjGKMYXEKIxElrRNiI+mIuv51F9sDIr+XZ77W4ObPZew9Pn XHTjh4B5fjkzlNnFLecxYM2w38M6ccXto4DBeaPtEcIbb3Z/41icdlky49ekpiFZYh oiyeJJhHoQYLCcaM/HcmUvryCsTyOq62P1oS7Z3SbrLNjJPIA+K1xBOHo+0Ei9Y0z4 svrnxyzg4kfR5hgaannbpXtkUg2Cdozoll048k2o7coKxyRBwYablcey68R2svWI/h CDUeJ+I8CU2dekkiWp4HfpYseVbUc+oJuaDUwU6Rjxp5UkbgOs4jTyDh0QPce6GdUk ZRHVZiZlPKAIg== Archived-At: http://mailarchive.ietf.org/arch/msg/urn/cHzj-Ana_8SDqRva-F3VYbUuZIM Cc: urn@ietf.org Subject: Re: [urn] URNs, URIs, this working group's job, and some steering X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 20:50:12 -0000 > From: Juha Hakala > > I believe what's needed is a *concise* explanation about what > > particular bits in RFC 3986 are considered a problem. Do we have that? > > (Pointers sufficient). > > This issue has been discussed several times, but once more the main > issues memory institutions have with the RFC 3986: Many thanks for providing your summary! > 1. The general idea that every URI is an identifier, and the very loose > specification of "identifier" built in into such a statement which does > not match with the meaning the term identifier has in the URN context. My understanding is that a URI is intended to "identify" some "resource", in the broadest sense of both of the words in quotation marks. And I believe it to be understood that only the URIs that are called URNs (which at the moment, are exactly the same set as the ones whose scheme is "urn") have the sorts of properties that are characteristic of what are (on this mailing list) called "names". As far as I can tell, when you write "identifier" you are using much the same concept as when most of the rest of us write "name". In particular, we do not expect mailto:, http:, or sip: URIs to behave in ways that resemble "names", and we wouldn't expect a memory institution to use them as such. Or to turn that statement around, we expect memory institutions to be interested in only a small subset of the universe of URIs, the ones that are called URNs. Which means that the problem is: Does the set of URNs (current and potential) suffice for the needs of memory institutions? The fact that other URIs are not suitable for memory institutions is not important. I would summarize this point by saying that in regard to your analysis: > To sum up, probably the main challenge we are facing is that "to > identify" means different things to different communities. Worse, > identification in the URN context does not mean the same as it means in > the URI context. In the latter, the meaning of the term has been > expanded so that the communities which have a lot of experience about > identification of resources such as libraries don't really agree with it > anymore. URN definition of the term, on the other hand, is OK. For proper memory use, confine your attention to URNs. The other parts of the URI space won't work for memory (and aren't even intended to). > 2. Regarding query, chapter RFC 3986 says: > > > The query component contains non-hierarchical data that, along with > > data in the path component (Section 3.3), serves to identify a > > resource within the scope of the URI's scheme and naming authority > > (if any). > > It is difficult to tell what "within the scope of the URI's scheme and > naming authority" means. Or, what happens if there is no naming > authority. Obviously not all URIs with query are identifiers after all. > > And if query components do identify something, what would it be. For > instance in this URI: It seems to me that the key text is "within the scope of the URI's scheme and naming authority", that is, the query part can only be understood based on the definition of the scheme. The only schemes that I know of that define the use of "query" are the http:/https: and sip:/sips: schemes. And indeed, the generic urn: scheme syntax (RFC 2141) doesn't permit query components at all. So currently there is no defined meaning for query when used with names (identifiers, as you call them) and they are not to be used. An interesting question is whether amending RFC 2141 to permit query components in URNs would be useful to solve any existing problem. It seems that there have been proposals for using query to specify what particular sort of information is wanted about the named resource (usually in the way of providing a "metadata" alternative), and for specifying what (non-default) resolution service should be use for locating the resource. It seems to me that both of these could be accommodated within the framework of RFC 3986 by amending RFC 2141. > In the URN context, NSS is stable and identifies the resource. Queries > are attached to established URNs when necessary, depending on what > resolution services the users want. But they do not have any role in > identification, and they are not meant to be persistent since the > technical infrastructure which provides services is changing. That is, a > user may see a URN and tick a box saying "do you want metadata about > this resource", and behind the screen the user interface app builds a > valid query string and adds it to the URN. That would seem reasonable to me. And that is one reason to have a syntactically identifiable "query" part, or something like it: It is often convenient, when inserting a URI into an application, to be able to attach information to it that indicates some sort of non-default handling. If the application handles the URI "opaquely", that is, does not try to analyze the URI, the user can adjust the application's behavior by changing the query part. If the application wants to have more control, there is a standardized way for it to detach the "decoration" information from the more stable "identification" information. Of course, this is cheating on the definition of "name", but it is very useful in practice. For example, if we define the query part "metadata" to mean that one desires to retrieve the metadata about a book, rather than the contents of the book, then the name of the metadata is: urn:isbn:0-395-36341-1?metadata Strictly speaking, it is only the definition of the urn: scheme that would fix this use of the query part. But it would be a convenient convention, because it gives us a way to write a name for the metadata. In a philosophical way, we can consider the metadata to be part of the resource that is the book . OTOH, the "book" is only a mental construction; it designates a large set of nearly identical physical objects. But very conveniently, a human or application can easily extract the URN of the underlying "book" by deleting the query part to obtain: urn:isbn:0-395-36341-1 (This causes me to imagine a future retrieval device in a library, which when presented with delivers to the user a *physical book*. To obtain a digital representation, must be used ...) Another example: a human could present this quasi-name to an application: urn:isbn:0-395-36341-1?resolver=z3950.loc.gov because the human knows that the resolver at z3950.loc.gov is "better" in some way for this particular retrieval task. But if the application saves the URN and now or later discovers that the quasi-name is unusable because z3950.loc.gov no longer exists in DNS, the application can *algorithmicly* remove the query to obtain urn:isbn:0-395-36341-1 which can be assumed to be more semantically stable than the above URN (though it would have been less useful when the name was initially used). > 3. RFC 3986 says the following about fragment in chapter 3.5: > > > The fragment identifier component of a URI allows indirect > > identification of a secondary resource by reference to a primary > > resource and additional identifying information. The identified > > secondary resource may be some portion or subset of the primary > > resource, some view on representations of the primary resource, or > > some other resource defined or described by those representations. > > Technically there is no problem here. The entire resource is always > retrieved, and fragment is only applied by the client such as a Web > browser. So fragments have a priori nothing to do with the URN resolution. > > Typical use case is a researcher who cites a document, and adds a > fragment to the URN so that readers who click the link are taken > directly to the relevant location within the referred resource. I think everyone agrees with you on those points. > The problem is that if fragments are identifiers, then anyone can > identify any bits and pieces within resource that has previously been > identified by URNs. I don't think I understand you here. In most cases, the only fragment identifiers that can be used with a particular URN are the ones that are specifically defined within the body of the retrieved resource. (Exactly how the body specifies fragment identifiers is determined by the MIME media type of the body, but *not* the scheme of the URN.) The only person who can designate an identified fragment is the person who can alter the body of the resource to add a designation to it. (There is an exception in RFC 5147, which defines fragment identifiers for text/plain bodies. It uses character and line positions as a coordinate system for defining locations within the body. So in the case of text/plain bodies, anyone can identify any bit of the body that they please, without coordination with the author of the body.) > Since RFC 3986 was published, people have invented all kinds of > interesting usages for fragment. The more I know about them, the harder > it is for me to see what fragments do identify. For instance, does this > > |http://example.com/document.txt#match=[rR][fF][cC] > | > identify every "rfc" and "RFC" in the target document? Or does it just > find them? You can't tell without knowing the media type of the resource accessible via http://example.com/document.txt. My guess is that it would have media type text/plain, in which case fragment identifiers would be interpreted under RFC 5147, and 5147 does not provide for a fragment identifier containing "match=". In addition, there seem to me to be related issues involving: - internationalization URIs can only directly use a subset of US-ASCII, and URNs are thus limited in the same way. This is inconvenient for constructing URNs that reference any natural language than English. However, there is an escape mechanism that allows any Unicode character to be expressed in an awkward escaped way. That leads to: - user presentation Currently, the standards define only how URNs appear "on the wire". There is an assumption that whenever URNs have to be input by a user or displayed to a user, they will be presented in a form very close to the "wire" format. However, the limited character set of URNs is largely based on the desirability of embedding them in longer text strings, as that makes it easier to parse the longer string and extract the URN. "For example, please click on ." However, in may circumstances (e.g., GUIs), the URN string is "framed" in a way that is not inconvenienced by any character that the string might contain. (A similar phenomenon happens in file names. In Unix systems, file names are very often written in a "command line" context where the space character has a special meaning. That requires a space that is contained in a file name to be represented in an awkward "escaped" format. But in MS Windows systems, file names are almost always presented in a GUI context where space has no special meaning. Thus, file name entry in Windows rarely needs to treat the space character in a special way.) In this regard, we may want to standardize two different ways of presenting a URN: one which adheres to the current syntax and is to be used "on the wire", and one which allows direct expression of arbitrary linguistic text, but which depends on external framing. The latter format could be used for user interaction in situations where the interface provides framing. We could then standardize a mapping between the two formats. Dale From nobody Fri Jul 11 01:22:04 2014 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E9B1B2ABA for ; Fri, 11 Jul 2014 01:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 8yQJ8LCU350t for ; Fri, 11 Jul 2014 01:21:46 -0700 (PDT) Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46D461B2AB0 for ; Fri, 11 Jul 2014 01:21:17 -0700 (PDT) Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s6B8KuM2008879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 11 Jul 2014 11:20:57 +0300 Message-ID: <53BF9E68.2090207@helsinki.fi> Date: Fri, 11 Jul 2014 11:20:56 +0300 From: Juha Hakala User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Dale R. Worley" References: <53BE3A55.3020806@gmx.de> <53BE6D4A.3050206@helsinki.fi> <201407102050.s6AKo5K9008755@hobgoblin.ariadne.com> In-Reply-To: <201407102050.s6AKo5K9008755@hobgoblin.ariadne.com> Content-Type: multipart/alternative; boundary="------------050605050802070205040603" Archived-At: http://mailarchive.ietf.org/arch/msg/urn/fOiaCF0JD2MArb3GGwrZaO3RVeE Cc: urn@ietf.org Subject: Re: [urn] URNs, URIs, this working group's job, and some steering X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 08:21:59 -0000 This is a multi-part message in MIME format. --------------050605050802070205040603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Dale, On 10.7.2014 23:50, Dale R. Worley wrote: >> From: Juha Hakala >>> I believe what's needed is a *concise* explanation about what >>> particular bits in RFC 3986 are considered a problem. Do we have that? >>> (Pointers sufficient). >> This issue has been discussed several times, but once more the main >> issues memory institutions have with the RFC 3986: > Many thanks for providing your summary! Thanks; just keep in mind that it is my personal take on the situation, not something that has been endorsed by libraries, archives, museums, scientific publishers, universities etc. which routinely apply persistent identifiers since they have good reasons to believe that plain vanilla URIs (URLs) will meet their requirements. > >> 1. The general idea that every URI is an identifier, and the very loose >> specification of "identifier" built in into such a statement which does >> not match with the meaning the term identifier has in the URN context. > My understanding is that a URI is intended to "identify" some > "resource", in the broadest sense of both of the words in quotation > marks. And I believe it to be understood that only the URIs that are > called URNs (which at the moment, are exactly the same set as the ones > whose scheme is "urn") have the sorts of properties that are > characteristic of what are (on this mailing list) called "names". Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and extensible naming system". > > As far as I can tell, when you write "identifier" you are using much > the same concept as when most of the rest of us write "name". In > particular, we do not expect mailto:, http:, or sip: URIs to behave in > ways that resemble "names", and we wouldn't expect a memory > institution to use them as such. Section 1.1.3 of RFC 3986 says that: > An individual scheme does not have to be classified as being just one > of "name" or "locator". Instances of URIs from any given scheme may > have the characteristics of names or locators or both This allows the use of e.g. HTTP URIs as names. > > Or to turn that statement around, we expect memory institutions to be > interested in only a small subset of the universe of URIs, the ones > that are called URNs. Which means that the problem is: Does the set > of URNs (current and potential) suffice for the needs of memory > institutions? The fact that other URIs are not suitable for memory > institutions is not important. It seems to me that the problem URNBIS has in its collective hands is a bit more complicated than that. This quote from Wikipedia URN page illustrates the situation: > Defined in 1997 in RFC > 2141, URNs were > intended to serve as persistent > , > location-independent identifiers, allowing the simple mapping > of > namespaces into a single URN > namespace.^[1] > > The existence of such a URI does not imply availability of the > identified resource, but such URIs are required to remain globally > unique and persistent, even when the resource ceases to exist or > becomes unavailable.^[2] > > > > Since RFC 3986^[2] > > in 2005, the use of the term has been deprecated in favor of the > less-restrictive "URI", a view proposed by a joint working group > between the World Wide Web Consortium > (W3C) and > Internet Engineering Task Force > > (IETF).^[3] > > Both URNs and uniform resource locators > (URLs) are > URIs, and a particular URI may be a name and a locator at the same time. > If both URNs and URLs can be names, the question is whether URNs are somehow superior compared with URLs as names. Mainstream thinking - also present in RFC 3986 - is that persistence of an URI is an administrative issue, and that both URLs and URNs can be administered well enough. The communities which prefer URNs and other persistent identifiers do not subscribe to this. > > I would summarize this point by saying that in regard to your analysis: > >> To sum up, probably the main challenge we are facing is that "to >> identify" means different things to different communities. Worse, >> identification in the URN context does not mean the same as it means in >> the URI context. In the latter, the meaning of the term has been >> expanded so that the communities which have a lot of experience about >> identification of resources such as libraries don't really agree with it >> anymore. URN definition of the term, on the other hand, is OK. > For proper memory use, confine your attention to URNs. The other > parts of the URI space won't work for memory (and aren't even intended > to). Had we been able to concentrate on URN specifications only, we would have completed the new URN specifications long time ago. But there are things in URI syntax which "invade" the URN domain, starting from the general idea that the term URN can be deprecated in favour of URI, and that URLs are equally good as names as URNs. > The only schemes that I know of that define the use of "query" are the > http:/https: and sip:/sips: schemes. And indeed, the generic urn: > scheme syntax (RFC 2141) doesn't permit query components at all. So > currently there is no defined meaning for query when used with names > (identifiers, as you call them) and they are not to be used. Alas, there is a need to use query for passing resolution related information to URN resolvers. We have no viable alternative for query usage, and other PID systems (ARK, Handle and DOI) are already using query for this purpose. We might still be able to align all these identifiers, and thus increase interoperability. On the other hand, it is almost certain that even if RFC2141bis would not allow query, URN community will start using query in the near future. Then there will be two variants of URN, plain vanilla IETF one and an enriched version used by those communities who are actually using URNs for identification purposes. > >> In the URN context, NSS is stable and identifies the resource. Queries >> are attached to established URNs when necessary, depending on what >> resolution services the users want. But they do not have any role in >> identification, and they are not meant to be persistent since the >> technical infrastructure which provides services is changing. That is, a >> user may see a URN and tick a box saying "do you want metadata about >> this resource", and behind the screen the user interface app builds a >> valid query string and adds it to the URN. > That would seem reasonable to me. And that is one reason to have a > syntactically identifiable "query" part, or something like it: It is > often convenient, when inserting a URI into an application, to be able > to attach information to it that indicates some sort of non-default > handling. If the application handles the URI "opaquely", that is, > does not try to analyze the URI, the user can adjust the application's > behavior by changing the query part. If the application wants to have > more control, there is a standardized way for it to detach the > "decoration" information from the more stable "identification" > information. > > Of course, this is cheating on the definition of "name", but it is > very useful in practice. If we say that query is not part of the namespace specific string ("name") there is no cheating involved. This can be achieved by saying that in URN namespaces query does not identify a resource unless the naming authority registering that particular namespace says so in the registration request. RFC 3986 enables this kind of interpretation: The query component contains non-hierarchical data that, along with data in the path component (Section 3.3), serves to identify a resource within the scope of the URI's scheme and naming authority (if any). > > For example, if we define the query part "metadata" to mean that one > desires to retrieve the metadata about a book, rather than the > contents of the book, then the name of the metadata is: > > urn:isbn:0-395-36341-1?metadata Yes, this is a good example of how we want to use the query. However, in reality there are many different kinds of metadata, and it must be possible to specify what we want. Also, we need to be backwards compatible with RFC 2483. That's why I've used examples like urn:isbn:0-395-36341-1?s=URC&p=DC To me, this is not the name of the Dublin Core record of the book, but just a URI which is mapped by the URN resolver into e.g. a SRU search which is passed to the appropriate target. > > Strictly speaking, it is only the definition of the urn: scheme that > would fix this use of the query part. But it would be a convenient > convention, because it gives us a way to write a name for the > metadata. In a philosophical way, we can consider the metadata to be > part of the resource that is the book . OTOH, > the "book" is only a mental construction; it > designates a large set of nearly identical physical objects. Libraries, archives, museums etc. have well established practices on how they see their collections and objects in them. Existing identifiers and identifier assignment practices have evolved in this environment, and they are now being applied and adapted for digital collections. For us, there are two kinds of mental constructions: works (such as Gone with the wind) and expressions (Finnish translation of Gone with the wind). Then there are physical manifestations (1st edition of Gone with the wind) and items (copies of the 1st edition of the Gone with the wind). Identifiers are used in all these levels, although for items they do not need to be globally unique. Metadata (including these identifiers) enables the users to find and locate these materials. > > But very conveniently, a human or application can easily extract the > URN of the underlying "book" by deleting the query part to obtain: > > urn:isbn:0-395-36341-1 > > (This causes me to imagine a future retrieval device in a library, > which when presented with delivers to the > user a *physical book*. To obtain a digital representation, > must be used ...) Digital manifestation of the book must have a different ISBN than the printed one. So if the default service is the retrieval of the resource, mere urn:isbn: should do. But the user could use the identifier of the work to see all the available versions of the book, and pick the one - for instance a PDF instead of plain text version - that suits his requirements best. > > Another example: a human could present this quasi-name to an > application: > > urn:isbn:0-395-36341-1?resolver=z3950.loc.gov > > because the human knows that the resolver at z3950.loc.gov is "better" > in some way for this particular retrieval task. We do need to make URN resolvers smarter, and giving the users the possibility to select the server is something that needs to be considered. The easiest option for doing this is that the resolver is be aware of n different servers which can provide services for a given URN. For instance, for urn:isbn:0-395-36341-1 appropriate targets include Finnish national union catalogue, OCLC's WorldCat and Google Scholar, to name just a few. A library application could consult the URN resolver about the targets available, and then allow the user to select between them, or - as in Dale's example - even allow the user to choose a new target, and bypass the resolver. Alas, we can't allow the users just to specify at random a target to which the URN is to be passed. Users must also tell which service they want, unless there is globally supported default (for instance, URI to Resource). And, since the resolver does not know which protocols the server supports to deliver the service the user is asking for, the user should specify the protocol as well. In Dale's example, it would be Z39.50 to retrieve metadata. If the user does not know the protocol, the resolver can make a port scan to see if there is for instance an SRU server up and running on the target server. If a suitable server is found, the resolver should be able to convert the URN into a proper form, for instance into an SRU query with the NSS (e.g. ISBN) as a search term. The server would then send to the user metadata about the resource. > > But if the application saves the URN and now or later discovers that > the quasi-name is unusable because z3950.loc.gov no longer exists in > DNS, the application can *algorithmicly* remove the query to obtain > > urn:isbn:0-395-36341-1 > > which can be assumed to be more semantically stable than the above URN > (though it would have been less useful when the name was initially > used). Or, instead of using the server the user preferred, the URN resolver can utilize one of the pre-configured servers. And if the identifier is semantic, parsing the NSS will provide a hint on where to go. For instance, if the user is interested in a book which has an ISBN that has been assigned in New Zealand, the resolver may be able to locate the national bibliography of New Zealand, and pass the request there. As an aside, queries will definitely be less stable than namespace specific strings, since although a document may exist a very long time, services related to it will be more short lived. 100 years from now it may still be possible to retrieve an ancient PDF version of Ulysses (which by then will no longer be accessible without digital archaeology), but metadata formats will have changed so that getting a MARC 21 record would be challenge. Best regards, Juha > >> 3. RFC 3986 says the following about fragment in chapter 3.5: >> >>> The fragment identifier component of a URI allows indirect >>> identification of a secondary resource by reference to a primary >>> resource and additional identifying information. The identified >>> secondary resource may be some portion or subset of the primary >>> resource, some view on representations of the primary resource, or >>> some other resource defined or described by those representations. >> Technically there is no problem here. The entire resource is always >> retrieved, and fragment is only applied by the client such as a Web >> browser. So fragments have a priori nothing to do with the URN resolution. >> >> Typical use case is a researcher who cites a document, and adds a >> fragment to the URN so that readers who click the link are taken >> directly to the relevant location within the referred resource. > I think everyone agrees with you on those points. > >> The problem is that if fragments are identifiers, then anyone can >> identify any bits and pieces within resource that has previously been >> identified by URNs. >> I don't think I understand you here. In most cases, the only fragment >> identifiers that can be used with a particular URN are the ones that >> are specifically defined within the body of the retrieved resource. >> (Exactly how the body specifies fragment identifiers is determined by >> the MIME media type of the body, but *not* the scheme of the URN.) >> The only person who can designate an identified fragment is the person >> who can alter the body of the resource to add a designation to it. >> >> (There is an exception in RFC 5147, which defines fragment identifiers >> for text/plain bodies. It uses character and line positions as a >> coordinate system for defining locations within the body. So in the >> case of text/plain bodies, anyone can identify any bit of the body >> that they please, without coordination with the author of the body.) >> >> Since RFC 3986 was published, people have invented all kinds of >> interesting usages for fragment. The more I know about them, the harder >> it is for me to see what fragments do identify. For instance, does this >> >> |http://example.com/document.txt#match=[rR][fF][cC] >> | >> identify every "rfc" and "RFC" in the target document? Or does it just >> find them? > You can't tell without knowing the media type of the resource > accessible via http://example.com/document.txt. My guess is that it > would have media type text/plain, in which case fragment identifiers > would be interpreted under RFC 5147, and 5147 does not provide for a > fragment identifier containing "match=". > > In addition, there seem to me to be related issues involving: > > - internationalization > > URIs can only directly use a subset of US-ASCII, and URNs are thus > limited in the same way. This is inconvenient for constructing URNs > that reference any natural language than English. However, there is > an escape mechanism that allows any Unicode character to be expressed > in an awkward escaped way. That leads to: > > - user presentation > > Currently, the standards define only how URNs appear "on the wire". > There is an assumption that whenever URNs have to be input by a user > or displayed to a user, they will be presented in a form very close to > the "wire" format. > > However, the limited character set of URNs is largely based on the > desirability of embedding them in longer text strings, as that makes > it easier to parse the longer string and extract the URN. "For > example, please click on ." However, > in may circumstances (e.g., GUIs), the URN string is "framed" in a way > that is not inconvenienced by any character that the string might > contain. > > (A similar phenomenon happens in file names. In Unix systems, file > names are very often written in a "command line" context where the > space character has a special meaning. That requires a space that is > contained in a file name to be represented in an awkward "escaped" > format. But in MS Windows systems, file names are almost always > presented in a GUI context where space has no special meaning. Thus, > file name entry in Windows rarely needs to treat the space character > in a special way.) > > In this regard, we may want to standardize two different ways of > presenting a URN: one which adheres to the current syntax and is to > be used "on the wire", and one which allows direct expression of > arbitrary linguistic text, but which depends on external framing. The > latter format could be used for user interaction in situations where > the interface provides framing. We could then standardize a mapping > between the two formats. > > Dale -- Juha Hakala Senior advisor The National Library of Finland Library Network Services P.O.Box 26 (Teollisuuskatu 23) FIN-00014 Helsinki University Tel. +358 9 191 44293 Mobile +358 50 3827678 --------------050605050802070205040603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello Dale,

On 10.7.2014 23:50, Dale R. Worley wrote:
From: Juha Hakala <juha.hakala@helsinki.fi>


      

        

          
I believe what's needed is a *concise* explanation about what 
particular bits in RFC 3986 are considered a problem. Do we have that? 
(Pointers sufficient).


        

        
This issue has been discussed several times, but once more the main 
issues memory institutions have with the RFC 3986:


      

      
Many thanks for providing your summary!

    

    

    Thanks; just keep in mind that it is my personal take on the
    situation, not something that has been endorsed by libraries,
    archives, museums, scientific publishers, universities etc. which
    routinely apply persistent identifiers since they have good reasons
    to believe that plain vanilla URIs (URLs) will meet their
    requirements. 

    

    

      



      

        
1. The general idea that every URI is an identifier,  and the very loose 
specification of "identifier" built in into such a statement which does 
not match with the meaning the term identifier has in the URN context.


      

      
My understanding is that a URI is intended to "identify" some
"resource", in the broadest sense of both of the words in quotation
marks.  And I believe it to be understood that only the URIs that are
called URNs (which at the moment, are exactly the same set as the ones
whose scheme is "urn") have the sorts of properties that are
characteristic of what are (on this mailing list) called "names".

    

    

    Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and
    extensible naming system".  

    

      

As far as I can tell, when you write "identifier" you are using much
the same concept as when most of the rest of us write "name".  In
particular, we do not expect mailto:, http:, or sip: URIs to behave in
ways that resemble "names", and we wouldn't expect a memory
institution to use them as such.

    

    

    Section 1.1.3 of RFC 3986 says that:

    

    

      
An individual scheme does not have to be classified as being just one
   of "name" or "locator".  Instances of URIs from any given scheme may
   have the characteristics of names or locators or both

    

      

    This allows the use of e.g. HTTP URIs as names.   

    

      

Or to turn that statement around, we expect memory institutions to be
interested in only a small subset of the universe of URIs, the ones
that are called URNs.  Which means that the problem is:  Does the set
of URNs (current and potential) suffice for the needs of memory
institutions?  The fact that other URIs are not suitable for memory
institutions is not important.

    

    

    It seems to me that the problem URNBIS has in its collective hands
    is a bit more complicated than that. This quote from Wikipedia URN
    page illustrates the situation:

    

    

      
Defined in 1997 in RFC 2141, URNs were intended
        to serve as persistent,
        location-independent identifiers, allowing the simple mapping of namespaces into a single URN namespace.[1]
        The existence of such a URI does not imply availability of the
        identified resource, but such URIs are required to remain
        globally unique and persistent, even when the resource ceases to
        exist or becomes unavailable.[2]

      
Since RFC 3986[2]
        in 2005, the use of the term has been deprecated in favor of the
        less-restrictive "URI", a view proposed by a joint working group
        between the World Wide Web Consortium
        (W3C) and Internet Engineering
          Task Force (IETF).[3]
        Both URNs and uniform resource locators
        (URLs) are URIs, and a particular URI may be a name and a
        locator at the same time.

    

     

    If both URNs and URLs can be names, the question is whether URNs are
    somehow superior compared with URLs as names. Mainstream thinking -
    also present in RFC 3986 - is that persistence of an URI is an
    administrative issue, and that both URLs and URNs can be
    administered well enough. The communities which prefer URNs and
    other persistent identifiers do not subscribe to this.   

    

    

      

I would summarize this point by saying that in regard to your analysis:



      

        
To sum up, probably the main challenge we are facing is that "to 
identify" means different things to different communities. Worse, 
identification in the URN context does not mean the same as it means in 
the URI context. In the latter, the meaning of the term has been 
expanded so that the communities which have a lot of experience about 
identification of resources such as libraries don't really agree with it 
anymore. URN definition of the term, on the other hand, is OK.


      

      
For proper memory use, confine your attention to URNs.  The other
parts of the URI space won't work for memory (and aren't even intended
to).

    

    

    Had we been able to concentrate on URN specifications only, we would
    have completed the new URN specifications long time ago. But there
    are things in URI syntax which "invade" the URN domain, starting
    from the general idea that the term URN can be deprecated in favour
    of URI, and that URLs are equally good as names as URNs. 

    

    

      
The only schemes that I know of that define the use of "query" are the
http:/https: and sip:/sips: schemes.  And indeed, the generic urn:
scheme syntax (RFC 2141) doesn't permit query components at all.  So
currently there is no defined meaning for query when used with names
(identifiers, as you call them) and they are not to be used.

    

    

    Alas, there is a need to use query for passing resolution related
    information to URN resolvers. We have no viable alternative for
    query usage, and other PID systems (ARK, Handle and DOI) are already
    using query for this purpose. We might still be able to align all
    these identifiers, and thus increase interoperability. On the other
    hand, it is almost certain that even if RFC2141bis would not allow
    query, URN community will start using query in the near future. Then
    there will be two variants of URN, plain vanilla IETF one and an
    enriched version used by those communities who are actually using
    URNs for identification purposes.    

     

    

      



      

        
In the URN context, NSS is stable and identifies the resource. Queries 
are attached to established URNs when necessary, depending on what 
resolution services the users want. But they do not have any role in 
identification, and they are not meant to be persistent since the 
technical infrastructure which provides services is changing. That is, a 
user may see a URN and tick a box saying "do you want metadata about 
this resource", and behind the screen the user interface app builds a 
valid query string and adds it to the URN.


      

      
That would seem reasonable to me.  And that is one reason to have a
syntactically identifiable "query" part, or something like it:  It is
often convenient, when inserting a URI into an application, to be able
to attach information to it that indicates some sort of non-default
handling.  If the application handles the URI "opaquely", that is,
does not try to analyze the URI, the user can adjust the application's
behavior by changing the query part.  If the application wants to have
more control, there is a standardized way for it to detach the
"decoration" information from the more stable "identification"
information.

Of course, this is cheating on the definition of "name", but it is
very useful in practice.

    

    

    If we say that query is not part of the namespace specific string
    ("name") there is no cheating involved. 

    

    This can be achieved by saying that in URN namespaces query does not
    identify a resource unless the naming authority registering that
    particular namespace says so in the registration request. RFC 3986
    enables this kind of interpretation: 

     

    
The query component contains non-hierarchical data that, along with
   data in the path component (Section 3.3), serves to identify a
   resource within the scope of the URI's scheme and naming authority
   (if any).

    

      

For example, if we define the query part "metadata" to mean that one
desires to retrieve the metadata about a book, rather than the
contents of the book, then the name of the metadata is:

    urn:isbn:0-395-36341-1?metadata

    

    

    Yes, this is a good example of how we want to use the query.
    However, in reality there are many different kinds of metadata, and
    it must be possible to specify what we want. Also, we need to be
    backwards compatible with RFC 2483. That's why I've used examples
    like 

    

    urn:isbn:0-395-36341-1?s=URC&p=DC

    

    To me, this is not the name of the Dublin Core record of the book,
    but just a URI which is mapped by the URN resolver into e.g. a SRU
    search which is passed to the appropriate target. 

    

    

      

Strictly speaking, it is only the definition of the urn: scheme that
would fix this use of the query part.  But it would be a convenient
convention, because it gives us a way to write a name for the
metadata.  In a philosophical way, we can consider the metadata to be
part of the resource that is the book <urn:isbn:0-395-36341-1>.  OTOH,
the "book" <urn:isbn:0-395-36341-1> is only a mental construction; it
designates a large set of nearly identical physical objects.

    

    

    Libraries, archives, museums etc. have well established practices on
    how they see their collections and objects in them. Existing
    identifiers and identifier assignment practices have evolved in this
    environment, and they are now being applied and adapted for digital
    collections. 

    

    For us, there are two kinds of mental constructions: works (such as
    Gone with the wind) and expressions (Finnish translation of Gone
    with the wind). Then there are physical manifestations (1st edition
    of Gone with the wind) and items (copies of the 1st edition of the
    Gone with the wind). Identifiers are used in all these levels,
    although for items they do not need to be globally unique.  Metadata
    (including these identifiers) enables the users to find and locate
    these materials. 

     

    

      

But very conveniently, a human or application can easily extract the
URN of the underlying "book" by deleting the query part to obtain:

    urn:isbn:0-395-36341-1

(This causes me to imagine a future retrieval device in a library,
which when presented with <urn:isbn:0-395-36341-1> delivers to the
user a *physical book*.  To obtain a digital representation,
<urn:isbn:0-395-36341-1?data> must be used ...)

    

    

    Digital manifestation of the book must have a different ISBN than
    the printed one. So if the default service is the retrieval of the
    resource, mere urn:isbn:<isbn> should do. But the user could
    use the identifier of the work to see all the available versions of
    the book, and pick the one - for instance a PDF instead of plain
    text version - that suits his requirements best.  

    

    

    

      

Another example: a human could present this quasi-name to an
application:

    urn:isbn:0-395-36341-1?resolver=z3950.loc.gov

because the human knows that the resolver at z3950.loc.gov is "better"
in some way for this particular retrieval task.

    

    

    We do need to make URN resolvers smarter, and giving the users the
    possibility to select the server is something that needs to be
    considered. The easiest option for doing this is that the resolver
    is be aware of n different servers which can provide services for a
    given URN. For instance, for 

    
urn:isbn:0-395-36341-1


appropriate targets include Finnish national union catalogue, OCLC's WorldCat and Google Scholar, to name just a few. A library application could consult the URN resolver about the targets available, and then allow the user to select between them, or - as in Dale's example - even allow the user to choose a new target, and bypass the resolver. 

Alas, we can't allow the users just to specify at random a target to which the URN is to be passed. Users must also tell which service they want, unless there is globally supported default (for instance, URI to Resource). And, since the resolver does not know which protocols the server supports to deliver the service the user is asking for, the user should specify the protocol as well. In Dale's example, it would be Z39.50 to retrieve metadata. If the user does not know the protocol, the resolver can make a port scan to see if there is for instance an SRU server up and running on the target server. If a suitable server is found, the resolver should be able to convert the URN into a proper form, for instance into an SRU query with the NSS (e.g. ISBN) as a search term. The server would then send to the user metadata about the resource. 



    

      

But if the application saves the URN and now or later discovers that
the quasi-name is unusable because z3950.loc.gov no longer exists in
DNS, the application can *algorithmicly* remove the query to obtain

    urn:isbn:0-395-36341-1

which can be assumed to be more semantically stable than the above URN
(though it would have been less useful when the name was initially
used).

    

    

    Or, instead of using the server the user preferred, the URN resolver
    can utilize one of the pre-configured servers. And if the identifier
    is semantic, parsing the NSS will provide a hint on where to go. For
    instance, if the user is interested in a book which has an ISBN that
    has been assigned in New Zealand, the resolver may be able to locate
    the national bibliography of New Zealand, and pass the request
    there. 

    

    As an aside, queries will definitely be less stable than namespace
    specific strings, since although a document may exist a very long
    time, services related to it will be more short lived. 100 years
    from now it may still be possible to retrieve an ancient PDF version
    of Ulysses (which by then will no longer be accessible without
    digital archaeology), but metadata formats will have changed so that
    getting a MARC 21 record would be challenge. 

    

    Best regards,

    

    Juha

        

    

      



      

        
3. RFC 3986 says the following about fragment in chapter 3.5:



        

          
The fragment identifier component of a URI allows indirect
    identification of a secondary resource by reference to a primary
    resource and additional identifying information.  The identified
    secondary resource may be some portion or subset of the primary
    resource, some view on representations of the primary resource, or
    some other resource defined or described by those representations.


        

        
Technically there is no problem here. The entire resource is always 
retrieved, and fragment is only applied by the client such as a Web 
browser. So fragments have a priori nothing to do with the URN resolution.

Typical use case is a researcher who cites a document, and adds a 
fragment to the URN so that readers who click the link are taken 
directly to the relevant location within the referred resource.


      

      
I think everyone agrees with you on those points.



      

        
The problem is that if fragments are identifiers, then anyone can 
identify any bits and pieces within resource that has previously been 
identified by URNs.

      

    

    

    

    

    

      

        
I don't think I understand you here.  In most cases, the only fragment
identifiers that can be used with a particular URN are the ones that
are specifically defined within the body of the retrieved resource.
(Exactly how the body specifies fragment identifiers is determined by
the MIME media type of the body, but *not* the scheme of the URN.)
The only person who can designate an identified fragment is the person
who can alter the body of the resource to add a designation to it.

(There is an exception in RFC 5147, which defines fragment identifiers
for text/plain bodies.  It uses character and line positions as a
coordinate system for defining locations within the body.  So in the
case of text/plain bodies, anyone can identify any bit of the body
that they please, without coordination with the author of the body.)



      

      

        
Since RFC 3986 was published, people have invented all kinds of 
interesting usages for fragment. The more I know about them, the harder 
it is for me to see what fragments do identify. For instance, does this

|http://example.com/document.txt#match=[rR][fF][cC]
|
identify every "rfc" and "RFC" in the target document? Or does it just 
find them?


      

      
You can't tell without knowing the media type of the resource
accessible via http://example.com/document.txt.  My guess is that it
would have media type text/plain, in which case fragment identifiers
would be interpreted under RFC 5147, and 5147 does not provide for a
fragment identifier containing "match=".

In addition, there seem to me to be related issues involving:

- internationalization

URIs can only directly use a subset of US-ASCII, and URNs are thus
limited in the same way.  This is inconvenient for constructing URNs
that reference any natural language than English.  However, there is
an escape mechanism that allows any Unicode character to be expressed
in an awkward escaped way.  That leads to:

- user presentation

Currently, the standards define only how URNs appear "on the wire".
There is an assumption that whenever URNs have to be input by a user
or displayed to a user, they will be presented in a form very close to
the "wire" format.

However, the limited character set of URNs is largely based on the
desirability of embedding them in longer text strings, as that makes
it easier to parse the longer string and extract the URN.  "For
example, please click on <http://example.com/document.txt>."  However,
in may circumstances (e.g., GUIs), the URN string is "framed" in a way
that is not inconvenienced by any character that the string might
contain.

(A similar phenomenon happens in file names.  In Unix systems, file
names are very often written in a "command line" context where the
space character has a special meaning.  That requires a space that is
contained in a file name to be represented in an awkward "escaped"
format.  But in MS Windows systems, file names are almost always
presented in a GUI context where space has no special meaning.  Thus,
file name entry in Windows rarely needs to treat the space character
in a special way.)

In this regard, we may want to standardize two different ways of
presenting a URN:  one which adheres to the current syntax and is to
be used "on the wire", and one which allows direct expression of
arbitrary linguistic text, but which depends on external framing.  The
latter format could be used for user interaction in situations where
the interface provides framing.  We could then standardize a mapping
between the two formats.

Dale


    

    

    

    
-- 

 Juha Hakala
 Senior advisor

 The National Library of Finland
 Library Network Services 
 P.O.Box 26 (Teollisuuskatu 23)
 FIN-00014 Helsinki University
 Tel. +358 9 191 44293
 Mobile +358 50 3827678 




  


--------------050605050802070205040603--


From nobody Fri Jul 11 01:55:55 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885301A0453 for ; Fri, 11 Jul 2014 01:55:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 7XZeHvo9DJpZ for ; Fri, 11 Jul 2014 01:55:51 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DB631A0B17 for ; Fri, 11 Jul 2014 01:55:51 -0700 (PDT)
Received: from [192.168.1.106] ([217.91.35.233]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MV5tl-1X6PJu0kiT-00YTtD; Fri, 11 Jul 2014 10:55:43 +0200
Message-ID: <53BFA66D.3040704@gmx.de>
Date: Fri, 11 Jul 2014 10:55:09 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Juha Hakala ,  "Dale R. Worley" 
References:  <53BE3A55.3020806@gmx.de> <53BE6D4A.3050206@helsinki.fi> <201407102050.s6AKo5K9008755@hobgoblin.ariadne.com> <53BF9E68.2090207@helsinki.fi>
In-Reply-To: <53BF9E68.2090207@helsinki.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:H83LxdoDFwaMaCaA0CquW/jFvQehTe3nddsDE9v+ztozYyNCA7f zxHjbMzR2eniW1gNaEm6disKzxTnzThAXkJt0SzoONUlVlwL/eH/LPZaZiXUEHqL0zH12jC qJP+5xl0tNyJSEKNFdOTVcDHt5FFxwlhc8BWLoIIgdV+PW2EKZJant3F7hDO8vjYSwjFLNR 5evTqfTDrIA17NpyMv+3w==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/Zn8wS_GHkgmE7PcSe9FJUDSWY1Q
Cc: urn@ietf.org
Subject: Re: [urn] URNs, URIs, this working group's job, and some steering
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 08:55:53 -0000

Hi everybody,

I think it would be good if we could keep focused on "what is wrong with 
RFC 3986 from the URN community's point of view".

On 2014-07-11 10:20, Juha Hakala wrote:
> ...
> If both URNs and URLs can be names, the question is whether URNs are
> somehow superior compared with URLs as names. Mainstream thinking - also
> present in RFC 3986 - is that persistence of an URI is an administrative
> issue, and that both URLs and URNs can be administered well enough. The
> communities which prefer URNs and other persistent identifiers do not
> subscribe to this.
> ...

I don't see any action coming out of this :-)

> ...
> Had we been able to concentrate on URN specifications only, we would
> have completed the new URN specifications long time ago. But there are
> things in URI syntax which "invade" the URN domain, starting from the
> general idea that the term URN can be deprecated in favour of URI, and
> that URLs are equally good as names as URNs.

Also, it doesn't say that URLs "are equally good as names". What it 
*does* say is:

"An individual scheme does not have to be classified as being just one 
of "name" or "locator". Instances of URIs from any given scheme may have 
the characteristics of names or locators or both, often depending on the 
persistence and care in the assignment of identifiers by the naming 
authority, rather than on any quality of the scheme. Future 
specifications and related documentation should use the general term 
"URI" rather than the more restrictive terms "URL" and "URN" [RFC3305]."

If your concern is that RFC 3986 says "stop to say 'URN'" then we can 
think of relaxing that advice in an erratum.

> ...

So my understanding is that some people over here want to say that URNs 
are not URIs. I don't see how this can be discussed in a useful way 
*unless* somebody comes up with a concrete list of things that they 
believe to be "wrong" in RFC 3986.

Also I'll repeat what somebody else pointed out already: making this 
fork essentially means that those new URNs can not be used in places 
where we currently allow URIs in protocol elements, and that they may 
not be processed correctly by existing libraries that expect URIs. Is 
this really the intent?

Best regards, Julian



From nobody Fri Jul 11 05:00:37 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC331B2879 for ; Fri, 11 Jul 2014 05:00:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.251
X-Spam-Level: 
X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
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 lv8VYtMHG45Z for ; Fri, 11 Jul 2014 04:59:59 -0700 (PDT)
Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360921B2877 for ; Fri, 11 Jul 2014 04:59:57 -0700 (PDT)
Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s6BBxe8m007658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 11 Jul 2014 14:59:41 +0300
Message-ID: <53BFD1AC.8000707@helsinki.fi>
Date: Fri, 11 Jul 2014 14:59:40 +0300
From: Juha Hakala 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Julian Reschke , "Dale R. Worley" 
References:  <53BE3A55.3020806@gmx.de> <53BE6D4A.3050206@helsinki.fi> <201407102050.s6AKo5K9008755@hobgoblin.ariadne.com> <53BF9E68.2090207@helsinki.fi> <53BFA66D.3040704@gmx.de>
In-Reply-To: <53BFA66D.3040704@gmx.de>
Content-Type: multipart/alternative; boundary="------------080004020505020207030006"
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/5ZCOmYYoZSqu9AQdnGTcfbTRxT8
Cc: urn@ietf.org
Subject: Re: [urn] URNs, URIs, this working group's job, and some steering
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 12:00:12 -0000

This is a multi-part message in MIME format.
--------------080004020505020207030006
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Julian,

On 11.7.2014 11:55, Julian Reschke wrote:
>
>
>
> "An individual scheme does not have to be classified as being just one 
> of "name" or "locator". Instances of URIs from any given scheme may 
> have the characteristics of names or locators or both, often depending 
> on the persistence and care in the assignment of identifiers by the 
> naming authority, rather than on any quality of the scheme. Future 
> specifications and related documentation should use the general term 
> "URI" rather than the more restrictive terms "URL" and "URN" [RFC3305]."
>
> If your concern is that RFC 3986 says "stop to say 'URN'" then we can 
> think of relaxing that advice in an erratum.


That would be fine.

If the expectation was that as a result of RFC 3986 and promotion of 
cool URIs the usage of URNs and other persistent identifiers would 
gradually diminish, then that has definitely not happened. On the 
contrary, popularity of e.g. Handles and DOIs is increasing. Already 
more than 100 million of the latter have been minted, and it is likely 
that there are even more Handles around (but nobody knows how many).

So it seems that we shall have at least two different but complementary 
approaches to naming things in the Internet. Cool URIs like this

http://viaf.org/viaf/54202464


may be operational even for decades, but this name / identifier is not 
standard-based, it is dependent on technical infrastructure maintained 
by a OCLC, and it depends on HTTP and a domain registered by that firm. 
On the other hand, urn:isni:0000000109022386 refers to the same public 
identity than the HTTP URI above. As a standard identifier ISNI ID has 
stronger administrative basis that the VIAF ID, and it is not protocol 
dependent. Therefore ISNI-based URN is likely to have longer life time 
than VIAF-based HTTP URI. Alas, there is no way to make URNs in the 
URN:ISNI namespace actionable yet.

>
>> ...
>
> So my understanding is that some people over here want to say that 
> URNs are not URIs. I don't see how this can be discussed in a useful 
> way *unless* somebody comes up with a concrete list of things that 
> they believe to be "wrong" in RFC 3986.


On the basis of what you and Dale have written recently, would it be 
possible to a) relax the "stop to say URN" advice because there are 
communities which see a need for URNs and other persistent identifiers, 
and, related to that, b) make it more clear that from IETF point of view 
there are both identifiers and names, and to explain the difference 
between the two so that even the non-initiated ones can understand it? I 
had no problems grasping the difference between URLs and URNs, but 
sometimes I feel that it would be easier to grasp the holy Trinity than 
the combination URIs, URNs and URLs :-).


>
> Also I'll repeat what somebody else pointed out already: making this 
> fork essentially means that those new URNs can not be used in places 
> where we currently allow URIs in protocol elements, and that they may 
> not be processed correctly by existing libraries that expect URIs. Is 
> this really the intent?

No. Allowing the usage of queries in URNs should not cause any problems 
in systems that are able to process URIs. Organizations developing URN 
resolver applications need to modernize the existing tool packs so that 
the applications can deal with the resolution requests encoded in URI 
queries by rendering those URNs into appropriate HTTP URIs. But this 
should not have an impact to the rest of the Internet.

We all just have to live with the terminological differences between us 
and IETF / W3C. It is a bit late now to align the use of e.g. terms 
identifier and name in our respective communities. We just have to be 
aware of the complexities that follow from this terminological mismatch.

   All the best,

Juha
>
> Best regards, Julian
>
>


-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  Library Network Services
  P.O.Box 26 (Teollisuuskatu 23)
  FIN-00014 Helsinki University
  Tel. +358 9 191 44293
  Mobile +358 50 3827678



--------------080004020505020207030006
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Hi Julian,

      

      On 11.7.2014 11:55, Julian Reschke wrote:

    

    


       

      

      "An individual scheme does not have to be classified as being just
      one of "name" or "locator". Instances of URIs from any given
      scheme may have the characteristics of names or locators or both,
      often depending on the persistence and care in the assignment of
      identifiers by the naming authority, rather than on any quality of
      the scheme. Future specifications and related documentation should
      use the general term "URI" rather than the more restrictive terms
      "URL" and "URN" [RFC3305]."
      

      

      If your concern is that RFC 3986 says "stop to say 'URN'" then we
      can think of relaxing that advice in an erratum.
      

    

    

    

    That would be fine. 

    

    If the expectation was that as a result of RFC 3986 and promotion of
    cool URIs the usage of URNs and other persistent identifiers would
    gradually diminish, then that has definitely not happened. On the
    contrary, popularity of e.g. Handles and DOIs is increasing. Already
    more than 100 million of the latter have been minted, and it is
    likely that there are even more Handles around (but nobody knows how
    many). 

    

    So it seems that we shall have at least two different but
    complementary approaches to naming things in the Internet. Cool URIs
    like this 

    

     http://viaf.org/viaf/54202464

      

      

      may be operational even for decades, but this name / identifier is
      not standard-based, it is dependent on technical infrastructure
      maintained by a OCLC, and it depends on HTTP and a domain
      registered by that firm. On the other hand, urn:isni:0000000109022386
        refers to the same public identity than the HTTP URI above. As a
        standard identifier ISNI ID has stronger administrative basis
        that the VIAF ID, and it is not protocol dependent. Therefore
        ISNI-based URN is likely to have longer life time than
        VIAF-based HTTP URI. Alas, there is no way to make URNs in the
        URN:ISNI namespace actionable yet.  

    

    

      

      
...
        

      

      

      So my understanding is that some people over here want to say that
      URNs are not URIs. I don't see how this can be discussed in a
      useful way *unless* somebody comes up with a concrete list of
      things that they believe to be "wrong" in RFC 3986.
      

    

    

    

    On the basis of what you and Dale have written recently, would it be
    possible to a) relax the "stop to say URN" advice because there are
    communities which see a need for URNs and other persistent
    identifiers, and, related to that, b) make it more clear that from
    IETF point of view there are both identifiers and names, and to
    explain the difference between the two so that even the
    non-initiated ones can understand it? I had no problems grasping the
    difference between URLs and URNs, but sometimes I feel that it would
    be easier to grasp the holy Trinity than the combination URIs, URNs
    and URLs :-). 

    

    

    

      

      Also I'll repeat what somebody else pointed out already: making
      this fork essentially means that those new URNs can not be used in
      places where we currently allow URIs in protocol elements, and
      that they may not be processed correctly by existing libraries
      that expect URIs. Is this really the intent?
      

    

    

    No. Allowing the usage of queries in URNs should not cause any
    problems in systems that are able to process URIs. Organizations
    developing URN resolver applications need to modernize the existing
    tool packs so that the applications can deal with the resolution
    requests encoded in URI queries by rendering those URNs into
    appropriate HTTP URIs. But this should not have an impact to the
    rest of the Internet.  

    

    We all just have to live with the terminological differences between
    us and IETF / W3C. It is a bit late now to align the use of e.g.
    terms identifier and name in our respective communities. We just
    have to be aware of the complexities that follow from this
    terminological mismatch.  

    

      All the best,

    

    Juha

    

      

      Best regards, Julian
      

      

      

    

    

    

    
-- 

 Juha Hakala
 Senior advisor

 The National Library of Finland
 Library Network Services 
 P.O.Box 26 (Teollisuuskatu 23)
 FIN-00014 Helsinki University
 Tel. +358 9 191 44293
 Mobile +358 50 3827678 




  


--------------080004020505020207030006--


From nobody Fri Jul 11 08:56:29 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B591A0AB0 for ; Fri, 11 Jul 2014 08:56:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.555
X-Spam-Level: 
X-Spam-Status: No, score=0.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FRT_ADOBE2=2.455] autolearn=no
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 jErX9eIp-2My for ; Fri, 11 Jul 2014 08:56:25 -0700 (PDT)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 789171A0A8A for ; Fri, 11 Jul 2014 08:56:25 -0700 (PDT)
Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta08.westchester.pa.mail.comcast.net with comcast id R3qE1o0060SCNGk583wQvw; Fri, 11 Jul 2014 15:56:24 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta09.westchester.pa.mail.comcast.net with comcast id R3wQ1o00D1KKtkw3V3wQCo; Fri, 11 Jul 2014 15:56:24 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s6BFuOVo027278; Fri, 11 Jul 2014 11:56:24 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s6BFuNO8027277; Fri, 11 Jul 2014 11:56:23 -0400
Date: Fri, 11 Jul 2014 11:56:23 -0400
Message-Id: <201407111556.s6BFuNO8027277@hobgoblin.ariadne.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: Larry Masinter 
In-reply-to:  (masinter@adobe.com)
References:  <53BE3A55.3020806@gmx.de> <53BE6D4A.3050206@helsinki.fi> <53BE8E91.1010406@gmx.de> 
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405094184; bh=3D1ZROlPgn5243QYJgeUOj+lsTDGRHYyiPjPwq9FI1I=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=J2OM3RoQCvTjqi7ZFgBxaU0CnErcvx/NH+7I8giIOoS/sCnSPUolOK6bpwC+htGtB 0kyjEZuJ46FahlZhAflj0N4hutd3jRDWI3QlxqUbIZZVbORVsixSHpCFnktbSNMqS/ Ve1qbixNsi4nUuyfzgIAHOcC/rKgh6h6yhJk/e5ug/iBFfG9p7eZtGx2FW0rCJOpCO 4zCWwBKIVYBUB8gGKInSQJzML+lj25c7pYmilqm4c514L+WfJXMWjs1Z9GsN8aKEfS iKdmANNX39MI6yU2Vaya7Mg+qDjfdCmDDwRdPDJhOS9VJKiPVT/fb/z83Gi8KjxbN+ CuHYvrMXlcj7A==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/mpCXVOD9AMipfMCM1r7LySSIZP0
Cc: urn@ietf.org
Subject: Re: [urn] URNs, URIs, this working group's job, and some steering
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 15:56:26 -0000

> From: Larry Masinter 

> I think that these updates to 3986 would be 
> consistent with real URI use, and give the URNbis
> working group more rope to make the changes wanted,
> for those URN namespaces  used to identify 
> location-independent static documents in
> digital library contexts, but without stepping on 
> other kinds of URNs and applications of them,
> or appearing to disallow a urn in contexts that
> currently allow a URI or an IRI.

That paragraph seems to me to be a good start on the requirements for
this discussion!

> 1. Integrate IRI so that the support for non-ASCII
>     URNs are clearer.  
> 
>     URNbis doesn't like %-hex encoding for non-ASCII
>     names, that's fine, but there's no need if urn
>     is defined in terms of IRI.

I am not experienced in IRIs, but it appears to me that the fact that
there is a canonical mapping of IRIs into URIs (and the reverse) means
that IRIs and URIs used together are a solution to the conflict
between the needs of "display" and "on-the-wire" use.  This would seem
to solve many of the internationalization problems.

Dale


From nobody Fri Jul 11 10:19:04 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820BA1A0AEE for ; Fri, 11 Jul 2014 10:19:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_34=0.6] autolearn=no
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 qV21RPHpnNOX for ; Fri, 11 Jul 2014 10:18:59 -0700 (PDT)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 85B7D1A0AC1 for ; Fri, 11 Jul 2014 10:18:59 -0700 (PDT)
Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta10.westchester.pa.mail.comcast.net with comcast id R43g1o0030SCNGk5A5Jz2F; Fri, 11 Jul 2014 17:18:59 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta09.westchester.pa.mail.comcast.net with comcast id R5Jy1o00a1KKtkw3V5JyTi; Fri, 11 Jul 2014 17:18:59 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s6BHIwnK003310; Fri, 11 Jul 2014 13:18:58 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s6BHIvUm003308; Fri, 11 Jul 2014 13:18:57 -0400
Date: Fri, 11 Jul 2014 13:18:57 -0400
Message-Id: <201407111718.s6BHIvUm003308@hobgoblin.ariadne.com>
From: worley@alum.mit.edu (Dale R. Worley)
Sender: worley@alum.mit.edu (Dale R. Worley)
To: Juha Hakala 
In-reply-to: <53BF9E68.2090207@helsinki.fi> (juha.hakala@helsinki.fi)
References:  <53BE3A55.3020806@gmx.de> <53BE6D4A.3050206@helsinki.fi> <201407102050.s6AKo5K9008755@hobgoblin.ariadne.com> <53BF9E68.2090207@helsinki.fi>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405099139; bh=n+DSZrMk8kXvFiwYBf8yc7lbmZfFBBAumLDvuImSDc8=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=hY7tdFY4ESBOZ796T/rgReUde6ugQMNxBHTB029EZyh93oaJvIY3lF8DDC5TsJqOr 9lkFNKtfEjwYHhczbIJlBApwfSZHTEhxjw9kv7gEO8DlMb3WzI1EKk8ZNAli5+NbAx xrvJSCf0BhCrndkTIx5kyVevQdX8v8UHnkD6C+WM/8QGX65BBDOhKtSZ39EnQzojvc 071ESz6MxITg5+nCmYJLawceW34hK3ftmWIlMd3NKEZdHEle6zM3bAWQ8hPpwiviw5 8cTPnfIGUUU4hNPCXaWWVGOofNx9zxk0F71/Z/FBylmq8g1aFquz7J14iweqszvchy x4XLzav+cnmFg==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/cymXBo-OyR0noZCH9_I7IVF-dqw
Cc: urn@ietf.org
Subject: Re: [urn] URNs, URIs, this working group's job, and some steering
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 17:19:01 -0000

> Date: Fri, 11 Jul 2014 11:20:56 +0300
> From: Juha Hakala 

There seem to be a number of intertwined issues here, only some of
which have been directly addressed in the discussions that I have
seen.  I will attempt to address them in the order that makes
conceptual sense to me, rather that in the order in the original.  Of
course, my order is flavored by my background as an engineer.

I think everyone agrees on what "URI" means -- all the things defined
by RFC 3986.

The meaning of "URL" and "locator" is less well-defined.  It seems
that anything which can be used in a standardized way to retrieve a
resource is considered a "locator" and a URI that one expects to be
able to use as a locator is a URL.

So URIs with the http: scheme are URLs.

But now we run into one of those extension/intension things:  (
http://www.britannica.com/EBchecked/topic/289860/intension-and-extension
) Everyone expects that an http: URI can be used to retrieve something
via HTTP.  But of course, that need not be true for any particular
http: URI -- I once used an http: URI as the name of an XML schema,
and you couldn't use it to retrieve anything.  So it actually was a
name but not a locator, despite that it had the http: scheme.

So even though URIs with the http: scheme are considered URLs,
sometimes one of those URIs isn't really a URL.  But the definition of
the http: scheme makes it clear that the main, intended usage of the
scheme is for locators to be used with the HTTP and HTTPS protocols.

Currently, the meaning of "URN" is the URIs with the urn:  scheme.
The distinguishing feature of that scheme is that it is required to be
administered in a way that ensures that those URIs are high-quality
names.

This shows the general tendency to define/manage schemes so that each
scheme has an understood role, the URIs in a scheme can be
consistently used as generally as locators or names, and thus URIs in
those schemes are generally called URLs or URNs.  But as Juha notes,
this is explicitly not required generally:

And there are other sets of name identifiers, like DOIs and handles.
But they aren't URIs -- they are neither registered as such nor do
they conform to the URI syntax.

> Section 1.1.3 of RFC 3986 says that:
> 
> > An individual scheme does not have to be classified as being just one
> >     of "name" or "locator".  Instances of URIs from any given scheme may
> >     have the characteristics of names or locators or both

It does appear to me that people have not always used the term "name"
with exactly the same meaning.  Juha notes:

> Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and 
> extensible naming system".

But clearly that is using the term "name" in a way that we have not
been doing here, because many schemes are understood to have no
particular permanence properties.

Here, we've been using the term "name" to be identifiers whose meaning
is "permanent", at least to the point where the resource can be moved
to different physical or network locations without having to change
its name.

> This allows the use of e.g. HTTP URIs as names.
[...]
> If both URNs and URLs can be names, the question is whether URNs are 
> somehow superior compared with URLs as names. Mainstream thinking - also 
> present in RFC 3986 - is that persistence of an URI is an administrative 
> issue, and that both URLs and URNs can be administered well enough. The 
> communities which prefer URNs and other persistent identifiers do not 
> subscribe to this.

URNs are superior compared with URLs as names *by intension*, because
the standards for the urn: scheme require that their definition make
them high-quality names.

It seems to me that someone could define a group of http: URLs and
administer them with sufficient rigor that they would be high-quality
names.  This would make them names by extension but not by the
intension of their scheme.

Juha says "The communities which prefer URNs and other persistent
identifiers do not subscribe to" the idea that "both URLs and URNs can
be administered well enough" to be used as high-quality names.  I
think it is important to get a more thorough explanation of why they
do not think this is so.

> Had we been able to concentrate on URN specifications only, we would 
> have completed the new URN specifications long time ago. But there are 
> things in URI syntax which "invade" the URN domain, starting from the 
> general idea that the term URN can be deprecated in favour of URI, and 
> that URLs are equally good as names as URNs.

Neither of those objections stems from the *syntax* of URIs.  But they
do stem from the "URI community" and need to be addressed.

In regard to the first point, "the term URN can be deprecated in
favour of URI", Juha quotes Wikipedia ("Uniform resource name"):

    Since RFC 3986 in 2005, the use of the term has been deprecated in
    favor of the less-restrictive "URI", a view proposed by a joint
    working group between the World Wide Web Consortium and the IETF.

In RFC 3986 section 1.1.3, this is stated:

    Future specifications and related documentation should use the
    general term "URI" rather than the more restrictive terms "URL" and
    "URN" [RFC3305].

and that sentence seems to reference RFC 3305 section 2 (which I will
not quote whole).

But I don't see much in section 2 that is particularly important to
this discussion.  Its main import seems to be that people have used
"URL" (and possibly "URN") where they really mean "URI" (the universe
of all RFC 3986 identifiers) and they should use the generic "URI"
unless they mean a specific subset.  It does give this example about
URNs:

   "urn:" is also a URI scheme; it defines subspaces, called
   "namespaces".  For example, the set of URNs, of the form
   "urn:isbn:n-nn-nnnnnn-n", is a URN namespace.  ("isbn" is an URN
   namespace identifier.  It is not a "URN scheme", nor is it a "URI
   scheme.")

But that seems to me to be completely compatible with everything both
Juha and I have been saying -- "isbn" is a URN namespace, not a
scheme.

So I don't see anything in the documents which intends that "URN" has
been deprecated in favor of "URI" -- in situations where it is
intended to only consider identifiers that are URNs.  Looking at later
RFCs, there are a zillion that define new URN namespaces, but I
suppose those aren't true counterexamples.  But RFC 7255 ("Using the
International Mobile station Equipment Identity (IMEI) Uniform
Resource Name (URN) as an Instance ID") uses "URN" repeatedly, and it
was approved by the IESG.  I don't see that there is any attempt to
deprecate the term URN, when it is used properly.

In regard to the second point, "URLs are equally good as names as
URNs", I suppose it depends on intension vs. extension.  Clearly, the
*definition* of http: URLs does not require that they have name-like
properties.  But as long as one has administrative possession of a
group of http: URLs, one could *manage* them as names, their extension
would be names.

But of course, that sort of management has "intension" problems, as
the applicable standards don't require that they are managed, or that
they are names.  You can't tell by looking at it that it is a name
(and perhaps might be called a URN).

I don't see how any reformation of the URN *syntax* will eliminate
that problem, because people will always be able to get allocation of
some subset of URIs, manage them as names, and use them as names.  The
only way to avoid that would be if (1) there is an explicit separation
of URNs and URIs, and (2) there is bureaucratic enforcement that
nobody may use a URI as a name.  Then we could ensure that a string
used as a name would be a name by intension, that it would fall under
a standard that required its management as a name.

I don't see how the bureaucratic enforcement could ever be
implemented.

The remaining portion of Juha's message concerns the practical or
engineering aspects of using queries with (or as part of, depending on
how you define it) URNs.  And he's got more experience regarding that
than I do, so I will not comment.

> Date: Fri, 11 Jul 2014 14:59:40 +0300
> From: Juha Hakala 

> If the expectation was that as a result of RFC 3986 and promotion of 
> cool URIs the usage of URNs and other persistent identifiers would 
> gradually diminish, then that has definitely not happened. On the 
> contrary, popularity of e.g. Handles and DOIs is increasing. Already 
> more than 100 million of the latter have been minted, and it is likely 
> that there are even more Handles around (but nobody knows how many).

Which suggests that there are requirements that URN schemes do not
satisfy.  I would like to see a report from the communities that
developed these identifiers as to why they did not adopt URNs.  In the
case of DOIs, it appears that they have declined to even embed the DOI
space into the URN space as a namespace.

> So it seems that we shall have at least two different but complementary 
> approaches to naming things in the Internet. Cool URIs like this
> 
> http://viaf.org/viaf/54202464
> 
> may be operational even for decades, but this name / identifier is not 
> standard-based, it is dependent on technical infrastructure maintained 
> by a OCLC, and it depends on HTTP and a domain registered by that firm. 
> On the other hand, urn:isni:0000000109022386 refers to the same public 
> identity than the HTTP URI above. As a standard identifier ISNI ID has 
> stronger administrative basis that the VIAF ID, and it is not protocol 
> dependent. Therefore ISNI-based URN is likely to have longer life time 
> than VIAF-based HTTP URI. Alas, there is no way to make URNs in the 
> URN:ISNI namespace actionable yet.

That is a practical problem.  It seems that there was an idea to have
a uniform way to locate global resolver services for URNs, but it was
never broadly implemented.

I would not be surprised if that was because the developers of other
identifier systems had requirements for their resolvers that did not
fit under the proposed generic resolver services.

The great advantage of http-based "cool URLs" is that it requires no
new infrastructure in the client, which greatly eases introducing a
new resolution process.

> I had no problems grasping the difference between URLs and URNs, but
> sometimes I feel that it would be easier to grasp the holy Trinity
> than the combination URIs, URNs and URLs :-).

The sets are structured as follows.  Identifiers exist at all locations
marked "XXX".  (Or at least, they can exist.  I don't know if there
are any URIs which truly qualify both as URNs and URLs.)

    +----- URI (RFC 3986) "identifiers" ----------+
    |                                             |
    |  XXX                                        |  XXX
    |                                             |
    |  +---- URN (RFC 2141) "names" ----+         |
    |  |                                |         |
    |  |  XXX                           |         |
    |  |                                |         |
    |  |              +---- URL "locators" ----+  |
    |  |              |                 |      |  |
    |  |              |  XXX            |      |  |
    |  |              |                 |      |  |
    |  +--------------------------------+      |  |
    |                 |                        |  |
    |                 |  XXX                   |  |
    |                 |                        |  |
    |                 +------------------------+  |
    |                                             |
    |                                             |
    +---------------------------------------------+

> We all just have to live with the terminological differences between us 
> and IETF / W3C. It is a bit late now to align the use of e.g. terms 
> identifier and name in our respective communities. We just have to be 
> aware of the complexities that follow from this terminological mismatch.

Yes, that is often true.

Dale


From nobody Fri Jul 11 11:04:43 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B0F1B28E3 for ; Fri, 11 Jul 2014 11:04:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 TmQm3LFYDztA for ; Fri, 11 Jul 2014 11:04:40 -0700 (PDT)
Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id ACBD01A0B08 for ; Fri, 11 Jul 2014 11:04:40 -0700 (PDT)
Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id C51EF56547D; Fri, 11 Jul 2014 13:04:37 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id AA15EA0357; Fri, 11 Jul 2014 13:04:37 -0500 (CDT)
X-Virus-Scanned: amavisd-new at smtp-out-1.01.com
Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7thdRFbKHJh; Fri, 11 Jul 2014 13:04:37 -0500 (CDT)
Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 77EA8A034D; Fri, 11 Jul 2014 13:04:37 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 79BF5A0357; Fri, 11 Jul 2014 13:04:36 -0500 (CDT)
X-Virus-Scanned: amavisd-new at smtp-out-1.01.com
Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YfESoWXxi3ta; Fri, 11 Jul 2014 13:04:36 -0500 (CDT)
Received: from [192.168.0.108] (50-199-114-66-static.hfc.comcastbusiness.net [50.199.114.66]) by smtp-out-1.01.com (Postfix) with ESMTPSA id 15FCBA0383; Fri, 11 Jul 2014 13:04:35 -0500 (CDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Michael Mealling 
In-Reply-To: 
Date: Fri, 11 Jul 2014 14:04:31 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <53BE3A55.3020806@gmx.de> <53BE6D4A.3050206@helsinki.fi> <201407102050.s6AKo5K9008755@hobgoblin.ariadne.com> <53BF9E68.2090207@helsinki.fi> <201407111718.s6BHIvUm003308@hobgoblin.ariadne.com> 
To: "Dale R. Worley" 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/KZpmGdsqFEsulFfmV2iGjjnmvb4
Cc: urn@ietf.org
Subject: Re: [urn] URNs, URIs, this working group's job, and some steering
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 18:04:42 -0000

What Dale said below is where the rubber always met the road for me. The =
difference between a URN and any other URI scheme is the following:

Nothing found in RFC 2616 or elsewhere that defines the 'http' scheme =
tells my software whether=20
http://whitehouse.gov/=20
is maintained with sufficient rigor to qualify as "long lived" (the =
identifier, not the thing it identifies). If I make the assumption that =
it is and something changes at whitehouse.gov that violates my =
assumption then that is MY error. It is hard to design protocols based =
on assumptions.

BUT, in RFC 2141 there IS a statement that if I see
urn:isbn:whatever
that I can safely and correctly rely on that identifier being forever =
bound to the resource (whether that resource is physical, electronic, or =
metaphysical). If something violates that assumption then I can know =
that SOMEONE ELSE has made an error.=20

By using 'urn:' over 'http:' you are making an explicit statement about =
your intent as verified by the URN registration mechanism.

-MM

I'll go back to lurking now...

Michael Mealling
+1-678-640-6884	@mmealling

On Jul 11, 2014, at 1:18 PM, Dale R. Worley  wrote:

> It seems to me that someone could define a group of http: URLs and
> administer them with sufficient rigor that they would be high-quality
> names.  This would make them names by extension but not by the
> intension of their scheme.


From nobody Fri Jul 11 11:59:25 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF4D1A0400 for ; Fri, 11 Jul 2014 11:59:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 61pDsKiihdQK for ; Fri, 11 Jul 2014 11:59:22 -0700 (PDT)
Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B97B1A036A for ; Fri, 11 Jul 2014 11:59:22 -0700 (PDT)
Received: by mail-pa0-f47.google.com with SMTP id kx10so592789pab.6 for ; Fri, 11 Jul 2014 11:59:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=AQ+RwyG6dfAdoKQNmngaRaZcmdDMj2XUPE0uhOloZME=; b=HQV3EEzomwO61oSFUNwqk84hAIyO685rwf0+z87ypDlyp1YfhnXUObv32+wCAZZdea mXeAB9xwHXpCkJVjihG98jL5bm3aUTc89s2TlhkQ1sy2hatkOnzBo9yZ95LOQWMZIZtt tPu/w6YROeknEQ9EaMcwY4vpXg8i/G9eAURfKMbrdiwekr/VyEDpNJbUVZGIcDhs/srr p1/HFRbp+LXT1l+O/C1udf0RYPH8Hm8jVNMapc5jQI7Y0qKR+dfd3vzbY0tFpqZ8cTOm Y4aL0hn2oWpvgTOn9y2A0hSsvIDvK5/A0xjjKjyYxR0ECcIBnD/yCESgTaZwLipF0d2V F7og==
X-Gm-Message-State: ALoCoQnMBrzavg/ZdCT5Wv+tB9/zlLsHnZZmSkm85Wx1nyXr9EqwRjD/QD4tvT44ra3yK0TB3Uvm
MIME-Version: 1.0
X-Received: by 10.68.65.14 with SMTP id t14mr699782pbs.164.1405105161672; Fri, 11 Jul 2014 11:59:21 -0700 (PDT)
Received: by 10.66.9.2 with HTTP; Fri, 11 Jul 2014 11:59:21 -0700 (PDT)
X-Originating-IP: [192.149.252.11]
Date: Fri, 11 Jul 2014 14:59:21 -0400
Message-ID: 
From: Andrew Newton 
To: "urn@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/MuhqHgyg4Jhvy1keEvfPuxaRix0
Subject: [urn] Agenda for IETF 90
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 18:59:23 -0000

We are currently scheduled for Friday, July 25, 1150 - 1320.

1. Agenda Bashing

2. draft-ietf-urnbis-urns-are-not-uris
   John Klensin

NOTE: The purpose of this session is to discuss the important topic
of separating URNs from URIs. Of specific interest are the following
questions:
  1) Will allowing the use of the reserved characters ?=E2=80=99 and =E2=80=
=98#=E2=80=99 or
     other expansions of syntax cause URN interoperability problems?
  2) If there is no interoperability harm, is the approach to separate
     URNs from the URI framework the currently-known, least-bad
     approach?
  3) If URNs are to be separated from the URI framework then how
     should it be done?

3. Any Other Business


From nobody Fri Jul 11 12:02:12 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353531A059F for ; Fri, 11 Jul 2014 12:02:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 ZJ4CrkupOWaj for ; Fri, 11 Jul 2014 12:02:07 -0700 (PDT)
Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C0671B2C8C for ; Fri, 11 Jul 2014 12:02:03 -0700 (PDT)
Received: by mail-pd0-f169.google.com with SMTP id ft15so1863441pdb.0 for ; Fri, 11 Jul 2014 12:02:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=MwKWnonLD+SG+x4ndkFMKhtxQqkOIZZ2Lcu3yOOjUJc=; b=h/+p6vXSjyEaJK4Goib/XEXC79DxO4ETPgcdbhNUefJQONWneMHBbhqG0kMFFgprLF vmSs7N9NGOfyIzaDXPyOJSVnb9g9ODKyT14peHdBGNLPPrkkaqhbJbnEp7OYdQndakPH ANBhDCKqVj1J9R0RKE7YowYncwH3usOL/ttL3yiFAUxGlJlcTqg0QPE8p055i2rL6t8U Ionp03q2H6+rWFSU/nK20tBhyJ3zoNVjIWHibhD42rt7/issCxdyeR4+ZW7sMP7wvsc9 X/AXfier+RN9JBmjFBytKgIkhd4oAd1ue8iIFZk39KmErsq5Q3bpFMPYu0b1Ch/8F5zi zKvw==
X-Gm-Message-State: ALoCoQkXDU39HHXOIkeetds8IJGnyT2/vwD14w1ClWgptVU0lN1q1iLhxK7u4v2zaCspCPUxC89R
MIME-Version: 1.0
X-Received: by 10.67.2.34 with SMTP id bl2mr801263pad.58.1405105323131; Fri, 11 Jul 2014 12:02:03 -0700 (PDT)
Received: by 10.66.9.2 with HTTP; Fri, 11 Jul 2014 12:02:03 -0700 (PDT)
X-Originating-IP: [192.149.252.11]
In-Reply-To: 
References: 
Date: Fri, 11 Jul 2014 15:02:03 -0400
Message-ID: 
From: Andrew Newton 
To: "urn@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/o3Uy3h4ILumqytJG9Qkat782-gY
Subject: Re: [urn] Agenda for IETF 90
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 19:02:09 -0000

Also note, we would appreciate discussion on this mailing list prior
to the meeting on the following questions:

>   1) Will allowing the use of the reserved characters ?=E2=80=99 and =E2=
=80=98#=E2=80=99 or
>      other expansions of syntax cause URN interoperability problems?
>   2) If there is no interoperability harm, is the approach to separate
>      URNs from the URI framework the currently-known, least-bad
>      approach?
>   3) If URNs are to be separated from the URI framework then how
>      should it be done?

If you have a concrete (or at least solidifying) proposal for #3,
putting it on this list ahead of the session will be beneficial.

-andy


From nobody Fri Jul 11 14:55:46 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711B91B29CF for ; Fri, 11 Jul 2014 14:55:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham
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 sB0blkKNNVDK for ; Fri, 11 Jul 2014 14:55:42 -0700 (PDT)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id A345F1B29CD for ; Fri, 11 Jul 2014 14:55:42 -0700 (PDT)
Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta05.westchester.pa.mail.comcast.net with comcast id R9rv1o0050Fqzac559vicn; Fri, 11 Jul 2014 21:55:42 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta08.westchester.pa.mail.comcast.net with comcast id R9vh1o00N1KKtkw3U9viMd; Fri, 11 Jul 2014 21:55:42 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s6BLtfdr000683 for ; Fri, 11 Jul 2014 17:55:41 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s6BLtf3W000682; Fri, 11 Jul 2014 17:55:41 -0400
Date: Fri, 11 Jul 2014 17:55:41 -0400
Message-Id: <201407112155.s6BLtf3W000682@hobgoblin.ariadne.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: urn@ietf.org
In-reply-to:  (michael@refactored-networks.com)
References:  <53BE3A55.3020806@gmx.de> <53BE6D4A.3050206@helsinki.fi> <201407102050.s6AKo5K9008755@hobgoblin.ariadne.com> <53BF9E68.2090207@helsinki.fi> <201407111718.s6BHIvUm003308@hobgoblin.ariadne.com>  
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405115742; bh=MUWIaLm1Ymntn+5rCBPQWGder9gU3GK0sWAqiatIx7c=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=anmbhw5Pvp/2KnxvDJI477S9doSEDRD5RGr6/S+Kh9PhMdgMy0tWzfxhlvs4fvg2h w8f2EyvFG1K76gH3xZ5IVLAKpzE9sIs2/fVQUe9lwO8y5hy6TAIB3HKElcl0ddJM4J 8k/F1+3hh/ys95Feh2rP13EHGzbfREA+xRA1sS4LAOZBEBFOWrQsAtikTTbjSalPQm hB2/9iG7n0SXC/AhtXj7FhcXAJbHoZZZmE+ilFUGqhz4hwENhMyKMEyndRCsYNqzn2 5e751GpC/U4rv1txwd7uY9BZDjSUvO6T618pFEOzKTYu2oZTlZirEiECrD69lsEq7a 8jR98uFTMUuAg==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/oe_G6u0uiBGqwWnU4WJ6qjbFNiI
Subject: Re: [urn] URNs, URIs, this working group's job, and some steering
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jul 2014 21:55:44 -0000

Juha raises objections to "cool URLs" (great name!) like

    http://viaf.org/viaf/54202464

when

    urn:isni:0000000109022386

is more correct in a lot of ways.

But I notice that the URL is truly usable as a locator, and is in
practice usable as a name.  (Thus, it inhabits the magic realm of the
intersection of URLs and URNs.)

The URN, on the other hand, is a high-quality name in every way, but
in most situations it isn't usable as a locator, because there isn't a
default, generic resolution service for URNs.  If someone set up a
resolution service, that would help, but they'd also have to get the
users to each install the proper client software.

What happens in practice?  The technique that is easy to install and
use is adopted rather than the one that is technically best.

Dale


From nobody Fri Jul 11 22:34:50 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A841A0421 for ; Fri, 11 Jul 2014 22:34:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
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 UKx0hjxnGpQy for ; Fri, 11 Jul 2014 22:34:42 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75EB11A02E9 for ; Fri, 11 Jul 2014 22:34:42 -0700 (PDT)
Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB308.namprd02.prod.outlook.com (10.141.91.24) with Microsoft SMTP Server (TLS) id 15.0.985.8; Sat, 12 Jul 2014 05:34:39 +0000
Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0980.000; Sat, 12 Jul 2014 05:34:39 +0000
From: Larry Masinter 
To: "Dale R. Worley" , Juha Hakala 
Thread-Topic: [urn] URNs, URIs, this working group's job, and some steering
Thread-Index: AQHPm7UORHpPXPfe2kqo257kMudT7puY4i+AgAA8vwCAAKsLR4AAg1Nw
Date: Sat, 12 Jul 2014 05:34:37 +0000
Message-ID: <569a33f6b2e8401b9234a0058b937a6a@BL2PR02MB307.namprd02.prod.outlook.com>
References:  <53BE3A55.3020806@gmx.de> <53BE6D4A.3050206@helsinki.fi> <201407102050.s6AKo5K9008755@hobgoblin.ariadne.com>
In-Reply-To: <201407102050.s6AKo5K9008755@hobgoblin.ariadne.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [50.184.24.49]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 0270ED2845
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51704005)(199002)(189002)(2656002)(83072002)(20776003)(85852003)(46102001)(85306003)(93886003)(86362001)(101416001)(92566001)(80022001)(87936001)(83322001)(4396001)(76176999)(95666004)(15395725005)(19580395003)(79102001)(76482001)(74316001)(99286002)(106116001)(76576001)(81342001)(33646001)(74662001)(105586002)(77982001)(21056001)(66066001)(107046002)(74502001)(64706001)(15202345003)(54356999)(81542001)(50986999)(31966008)(106356001)(15975445006)(99396002)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB308; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/pv661FO08ArA3UyeOFRTsaCHOTE
Cc: "urn@ietf.org" 
Subject: Re: [urn] URNs, URIs, this working group's job, and some steering
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Jul 2014 05:34:46 -0000

VGhlIGZhY3QgdGhhdCBzb21lIGNvbW11bml0aWVzIGhhdmUgYSBkaWZmZXJlbnQgdXNlIG9mIHRo
ZQ0Kc2FtZSB0ZXJtcyBpcyBpbmV2aXRhYmxlLCBidXQgbm90IGdyb3VuZHMgZm9yIGNoYW5naW5n
DQp0aGUgc3BlY2lmaWNhdGlvbiwganVzdCBmb3IgYmVpbmcgY2FyZWZ1bCBlZGl0b3JpYWxseS4N
Cg0KTmFtZS9pZGVudGlmeS9sb2NhdGUgYXJlIHZlcmJzOyB3aGljaCBpcyBtb3JlDQphcHByb3By
aWF0ZSBkZXBlbmRzIG9uIHRoZSBhY3Rpb24gaW1wbGllZC4gDQpuYW1lL2lkZW50aWZpZXIvbG9j
YXRvciBhcmUgbm91bnMsIGFuZCwgYXMgcG9pbnRlZA0Kb3V0IGZyZXF1ZW50bHksIGRvIG5vdCBm
b3JtIGRpc3RpbmN0IGNhdGVnb3JpZXMsIA0KYmVjYXVzZSB0aGUgc2FtZSBJRCBjYW4gYmUgdXNl
ZCB0byBuYW1lIGFuZCB0byBsb2NhdGUuDQoNCkkgdGhpbmsgVVJOYmlzIG5lZWRzIHRvIHJlc2Vy
dmUgdXJuOiBuYW1lcyB0aGF0DQphcmUgYXNzaWduZWQgYW5kIGF1dGhvcml0YXRpdmVseSByZXNv
bHZlZCBieSBvcmdhbml6YXRpb25hbGx5IG1hbmFnZWQNCnByb2Nlc3Nlcy4gU29tZSBtYXkgaW5k
ZWVkIGludGVuZCB0byBiZSBhcm91bmQgImZvcmV2ZXIiIGJ1dA0KdGhlcmUgaXMgbm8gYXNzdXJh
bmNlLCBmb3IgZXhhbXBsZSB3aXRoIHByb3Zpc2lvbmFsIE5JRHMuDQoNClVSTmJpcyBzaG91bGQg
Zm9jdXMgb24gKHJlKWRlZmluaW5nICJ1cm46IiwgIGJlY2F1c2UgdGhhdCBpcyB3aGF0IGl0IA0K
aXMgY2hhcnRlcmVkIHRvIGRvLg0KDQo+IE9yIHRvIHR1cm4gdGhhdCBzdGF0ZW1lbnQgYXJvdW5k
LCB3ZSBleHBlY3QgbWVtb3J5IGluc3RpdHV0aW9ucyB0byBiZQ0KPiBpbnRlcmVzdGVkIGluIG9u
bHkgYSBzbWFsbCBzdWJzZXQgb2YgdGhlIHVuaXZlcnNlIG9mIFVSSXMsIHRoZSBvbmVzDQo+IHRo
YXQgYXJlIGNhbGxlZCBVUk5zLiANCg0KJ01lbW9yeSBpbnN0aXR1dGlvbnMnIHNob3VsZCBiZSBp
bnRlcmVzdGVkIGluIHByZXNlcnZpbmcgdGhlIG1lbW9yeQ0Kb2YgdGhlIGFjdHVhbCBmb2N1cyBv
ZiBjcmVhdGl2ZSB3b3JrcyB3aGljaCBhcmUgZGlmZmljdWx0IHRvIGlkZW50aWZ5DQphbmQgdGFs
ayBhYm91dCB1c2luZyB0aGUgb2xkZXIgbGlicmFyeSBwZXJzcGVjdGl2ZSBvZiBhbiBhcmNoaXZl
DQpjb25zaXN0aW5nIG9mIGFuIHVub3JkZXJlZCBjb2xsZWN0aW9uIG9mIG9iamVjdHMgd2l0aCBh
c3NvY2lhdGVkDQptZXRhZGF0YS4gIFRoZSBhcmNoaXRlY3R1cmUgKGlkZW50aWZpZXJzIGZvciB3
b3Jrcywgd29ya3Mgc2VsZi1jb250YWluZWQsIA0Kd29ya3MgcmV0cmlldmFibGUgYW5kIGZ1bmN0
aW9uYWxseSBpbmRlcGVuZGVudCkgd29yayBPSyBmb3INCmVsZWN0cm9uaWMgcHVibGljYXRpb25z
IHdoaWNoIHJlY2FwaXR1bGF0ZSB0aGUgYWZmb3JkYW5jZXMgb2YgcGh5c2ljYWwNCm1lZGlhLiBC
dXQgbW9yZSBhbmQgbW9yZSBjcmVhdGl2ZSB3b3JrcyBhcmUgbGlua2VkIG5lc3RzIG9mIGV4cGVy
aWVuY2VzDQp3aGljaCBkb24ndCBkZWNvbXBvc2UgZWFzaWx5IGludG8gaWRlbnRpZmlhYmxlIGNv
bXBvbmVudHMNCmluZGVwZW5kZW50bHkgZXhjaGFuZ2VhYmxlLiBUaGUgIGludHVpdGlvbnMgZnJv
bSBkZWNhZGVzIG9mIA0KZXhwZXJpZW5jZSBhcmUgaW5zdWZmaWNpZW50LiANCiANCj4gV2hpY2gg
bWVhbnMgdGhhdCB0aGUgcHJvYmxlbSBpczogIERvZXMgdGhlIHNldA0KPiBvZiBVUk5zIChjdXJy
ZW50IGFuZCBwb3RlbnRpYWwpIHN1ZmZpY2UgZm9yIHRoZSBuZWVkcyBvZiBtZW1vcnkNCj4gaW5z
dGl0dXRpb25zPyAgVGhlIGZhY3QgdGhhdCBvdGhlciBVUklzIGFyZSBub3Qgc3VpdGFibGUgZm9y
IG1lbW9yeQ0KPiBpbnN0aXR1dGlvbnMgaXMgbm90IGltcG9ydGFudC4NCg0KRXZlbiBmb3IgY3Vy
cmVudGx5IGRlcGxveWVkIGFuZCBhcmNoaXZlZCBjb250ZW50LCB0aGUgdHJhZGl0aW9uYWwNCklk
ZW50aWZpY2F0aW9uIG1ldGhvZHMgYXJlIGluYWRlcXVhdGUgdG8gZGVzY3JpYmUgbmV3IG1lZGlh
Lg0KRm9yIHRoaXMgYW5kIG90aGVyIHJlYXNvbnMsIEkgZG9uJ3QgdGhpbmsgInN1ZmZpY2llbnQg
Zm9yIHRoZSBuZWVkcw0Kb2YgbWVtb3J5IGluc3RpdHV0aW9ucyIgaXMgdGhlIHJpZ2h0IHN1ZmZp
Y2llbmN5IGNyaXRlcmlvbi4NCg0KQW5kIHRoZSBYUkkgc3BlY2lmaWNhdGlvbiBleHBvc2VzIHNl
dmVyYWwgcGVyY2VpdmVkIHJlcXVpcmVtZW50cw0Kb2YgbWVtb3J5IGluc3RpdHV0aW9ucyBmb3Ig
dHJhZGl0aW9uYWwgbWF0ZXJpYWwgdGhhdCB0aGUgVVJOIHByb3Bvc2Fscw0KZG9uJ3Qgc2VlbSB0
byBhZGRyZXNzLg0KIA0KPiBGb3IgcHJvcGVyIG1lbW9yeSB1c2UsIGNvbmZpbmUgeW91ciBhdHRl
bnRpb24gdG8gVVJOcy4gIFRoZSBvdGhlcg0KPiBwYXJ0cyBvZiB0aGUgVVJJIHNwYWNlIHdvbid0
IHdvcmsgZm9yIG1lbW9yeSAoYW5kIGFyZW4ndCBldmVuIGludGVuZGVkDQo+IHRvKS4NCg0KVGhl
IHN0cmluZ3MgYnkgdGhlbXNlbHZlcyBkbyBub3RoaW5nLCBpdCdzIHRoZSBzeXN0ZW1zIGFuZCBw
cm90b2NvbHMNCnRoYXQgdXNlIHRoZW0gdGhhdCBkbyB0aGUgd29yay4gUGVyaGFwcyBhbGxvd2lu
ZyBuYW1lc3BhY2UgDQphdXRob3JpdGllcyB0byBwdWJsaXNoIChpbiB0aGUgSUFOQSBOSUQgcmVn
aXN0cnkpIEFQSXMgb3IgcHJvdG9jb2xzIG9yDQpvdGhlciBtZXRob2RzIGZvciBuYW1lIGFzc2ln
bm1lbnQgYW5kIHJlc29sdXRpb24gd291bGQgYWxsb3cNCm1lbW9yeSBvcmdhbml6YXRpb25zIHRv
IGRlY2lkZSB3aGljaCBVUklzIHRoZXkgd2lsbCBvciB3aWxsIG5vdA0KYWNjZXB0IGFzIGF1dGhv
cml0YXRpdmUgYW5kIHdlbGwtbWFuYWdlZC4gDQoNClJlcGVhdCAneHJpJyBjb21tZW50Lg0KDQo+
ID4gMi4gUmVnYXJkaW5nIHF1ZXJ5LCBjaGFwdGVyIFJGQyAzOTg2IHNheXM6DQo+ID4NCj4gPiA+
IFRoZSBxdWVyeSBjb21wb25lbnQgY29udGFpbnMgbm9uLWhpZXJhcmNoaWNhbCBkYXRhIHRoYXQs
IGFsb25nIHdpdGgNCj4gPiA+ICBkYXRhIGluIHRoZSBwYXRoIGNvbXBvbmVudCAoU2VjdGlvbiAz
LjMpLCBzZXJ2ZXMgdG8gaWRlbnRpZnkgYQ0KPiA+ID4gIHJlc291cmNlIHdpdGhpbiB0aGUgc2Nv
cGUgb2YgdGhlIFVSSSdzIHNjaGVtZSBhbmQgbmFtaW5nIGF1dGhvcml0eQ0KPiA+ID4gIChpZiBh
bnkpLg0KDQoiY29udGFpbnMiIHNob3VsZCBoYXZlIGJlZW4gImdlbmVyYWxseSBjb250YWlucyIg
b3IgImlzIGludGVuZGVkIHRvDQpjb250YWluIiBvciAibWlnaHQgY29udGFpbiIsIHNpbmNlIHRo
ZXJlIGFyZSBsb3RzIG9mIHVzZXMgb2YgcXVlcmllcy4NCg0KPiA+IEl0IGlzIGRpZmZpY3VsdCB0
byB0ZWxsIHdoYXQgIndpdGhpbiB0aGUgc2NvcGUgb2YgdGhlIFVSSSdzIHNjaGVtZSBhbmQNCj4g
PiBuYW1pbmcgYXV0aG9yaXR5IiBtZWFucy4gT3IsIHdoYXQgaGFwcGVucyBpZiB0aGVyZSBpcyBu
byBuYW1pbmcNCj4gPiBhdXRob3JpdHkuIE9idmlvdXNseSBub3QgYWxsIFVSSXMgd2l0aCBxdWVy
eSBhcmUgaWRlbnRpZmllcnMgYWZ0ZXIgYWxsLg0KDQpJIHRoaW5rIHRoZXJlIGlzIHNvbWUgcHJv
YmxlbSB3aXRoIHRha2luZyB0aGVzZSBzZW50ZW5jZXMgb3V0DQpvZiBjb250ZXh0IGFuZCBzdGFy
aW5nIGF0IHRoZW0gdG9vIGhhcmQuIFRoaXMgIndpdGhpbiB0aGUgc2NvcGUiIHBocmFzZQ0KaXMg
ZWxhYm9yYXRlZCBpbiB0aGUgKGp1c3QgcHVibGlzaGVkKSBSRkM3MzIwL0JDUDE5MDogDQoNCiAg
ICAgICIgZm9yIGV4YW1wbGUsIGlmIGEgc3BlY2lmaWNhdGlvbiBkb2N1bWVudHMgdGhhdCB0aGUg
InNpZyINCiAgICAgICAgVVJJIHF1ZXJ5IHBhcmFtZXRlciBpbmRpY2F0ZXMgdGhhdCBpdHMgcGF5
bG9hZCBpcyBhIGNyeXB0b2dyYXBoaWMNCiAgICAgICAgc2lnbmF0dXJlIGZvciB0aGUgVVJJLCAs
IGl0IGNhbiBsZWFkIHRvIHVuZGVzaXJhYmxlIGJlaGF2aW9yLiINCg0KPiBUaGUgb25seSBzY2hl
bWVzIHRoYXQgSSBrbm93IG9mIHRoYXQgZGVmaW5lIHRoZSB1c2Ugb2YgInF1ZXJ5IiBhcmUgdGhl
DQo+IGh0dHA6L2h0dHBzOiBhbmQgc2lwOi9zaXBzOiBzY2hlbWVzLiAgDQoNCkFjdHVhbGx5LCBo
dHRwL2h0dHBzIGRvbid0IGRlZmluZSB0aGUgdXNlIG9mICJxdWVyeSIuIEhUTUwgaGFzIGENCmNv
bnZlbnRpb24gZm9yIHBhY2tpbmcgdGV4dCBmb3JtIGRhdGEgaW50byBhIEhUVFAgVVJMIGZvciBh
DQp3aG9zZSBtZXRob2QgaXMgR0VULiBCdXQgSFRUUCBpdHNlbGYgZG9lc24ndCBsb29rIGluIHRo
ZSBxdWVyeQ0Kb3IgYXNzaWduIGl0IGFueSBzZW1hbnRpY3Mgb3RoZXIgdGhhbiBzZW5kaW5nIHBh
dGggKyBxdWVyeSB0bw0KdGhlIHNlcnZlciAoc2VlIFJGQyA3MjMwKS4NCg0KJ21haWx0bycgZGVm
aW5lcyBxdWVyeSBwYXJhbWV0ZXJzIGZvciBwcmVsb2FkaW5nIG1haWwgaGVhZGVycw0KKHN1Ympl
Y3QsIGJvZHkpLiANCg0KPiBBbmQgaW5kZWVkLCB0aGUgZ2VuZXJpYyB1cm46DQo+IHNjaGVtZSBz
eW50YXggKFJGQyAyMTQxKSBkb2Vzbid0IHBlcm1pdCBxdWVyeSBjb21wb25lbnRzIGF0IGFsbC4g
IFNvDQo+IGN1cnJlbnRseSB0aGVyZSBpcyBubyBkZWZpbmVkIG1lYW5pbmcgZm9yIHF1ZXJ5IHdo
ZW4gdXNlZCB3aXRoIG5hbWVzDQo+IChpZGVudGlmaWVycywgYXMgeW91IGNhbGwgdGhlbSkgYW5k
IHRoZXkgYXJlIG5vdCB0byBiZSB1c2VkLg0KPiANCj4gQW4gaW50ZXJlc3RpbmcgcXVlc3Rpb24g
aXMgd2hldGhlciBhbWVuZGluZyBSRkMgMjE0MSB0byBwZXJtaXQgcXVlcnkNCj4gY29tcG9uZW50
cyBpbiBVUk5zIHdvdWxkIGJlIHVzZWZ1bCB0byBzb2x2ZSBhbnkgZXhpc3RpbmcgcHJvYmxlbS4g
IEl0DQo+IHNlZW1zIHRoYXQgdGhlcmUgaGF2ZSBiZWVuIHByb3Bvc2FscyBmb3IgdXNpbmcgcXVl
cnkgdG8gc3BlY2lmeSB3aGF0DQo+IHBhcnRpY3VsYXIgc29ydCBvZiBpbmZvcm1hdGlvbiBpcyB3
YW50ZWQgYWJvdXQgdGhlIG5hbWVkIHJlc291cmNlDQo+ICh1c3VhbGx5IGluIHRoZSB3YXkgb2Yg
cHJvdmlkaW5nIGEgIm1ldGFkYXRhIiBhbHRlcm5hdGl2ZSksIGFuZCBmb3INCj4gc3BlY2lmeWlu
ZyB3aGF0IChub24tZGVmYXVsdCkgcmVzb2x1dGlvbiBzZXJ2aWNlIHNob3VsZCBiZSB1c2UgZm9y
DQo+IGxvY2F0aW5nIHRoZSByZXNvdXJjZS4gIEl0IHNlZW1zIHRvIG1lIHRoYXQgYm90aCBvZiB0
aGVzZSBjb3VsZCBiZQ0KPiBhY2NvbW1vZGF0ZWQgd2l0aGluIHRoZSBmcmFtZXdvcmsgb2YgUkZD
IDM5ODYgYnkgYW1lbmRpbmcgUkZDDQo+IDIxNDEuDQoNCkkgZG9uJ3Qgc2VlIGhvdyBpbnRyb2R1
Y2luZyB0aGVzZSBmZWF0dXJlcyBmb3IgKmFsbCogVVJOcyBpcyBmZWFzaWJsZTsNCndoZXRoZXIg
dGhlIHJlc291cmNlIGlkZW50aWZpZWQgaGFzIG1ldGFkYXRhIG9yIGlzIGxvY2F0YWJsZSANCmRl
cGVuZHMgb24gdGhlIFVSTiBuYW1lc3BhY2UgYW5kIHRoZSBuYW1lIHdpdGhpbi4NCiANCj4gPiBJ
biB0aGUgVVJOIGNvbnRleHQsIE5TUyBpcyBzdGFibGUgYW5kIGlkZW50aWZpZXMgdGhlIHJlc291
cmNlLiBRdWVyaWVzDQo+ID4gYXJlIGF0dGFjaGVkIHRvIGVzdGFibGlzaGVkIFVSTnMgd2hlbiBu
ZWNlc3NhcnksIGRlcGVuZGluZyBvbiB3aGF0DQo+ID4gcmVzb2x1dGlvbiBzZXJ2aWNlcyB0aGUg
dXNlcnMgd2FudC4gIA0KDQpZb3UncmUgbWl4aW5nIGludG8gdGhlIFVSTi1mb3ItbmFtaW5nIHdo
aWNoIGhhcyBjZXJ0YWluIA0KbWFuYWdlZCBwcm9wZXJ0aWVzIHdpdGggdGhlIFVSTC1mb3ItcmV0
cmlldmluZywgd2hpY2ggaXMgDQptb3JlIHRyYW5zaWVudCB3aXRob3V0IG1hbmFnZWQgcHJvY2Vz
c2VzLiBGb3IgZXhhbXBsZSwNCnlvdSB3YW50IHRvIGFkZCBhIHF1ZXJ5IGludGVyZmFjZSBmb3Ig
b2J0YWluaW5nIG1ldGFkYXRhDQp3aXRob3V0IGFueSBtZXRob2QgZm9yIHJlc29sdmluZyBkaXNw
dXRlcyBhYm91dCB3aGF0DQptZXRhZGF0YSBhcHBsaWVzLCBvciBjaGFuZ2VzIGluIG1ldGFkYXRh
IG1lYW5pbmcsIHN5bnRheCwNCm9yIHNjb3BlLg0KDQo+IElmIHRoZSBhcHBsaWNhdGlvbiBoYW5k
bGVzIHRoZSBVUkkgIm9wYXF1ZWx5IiwgdGhhdCBpcywNCj4gZG9lcyBub3QgdHJ5IHRvIGFuYWx5
emUgdGhlIFVSSSwgdGhlIHVzZXIgY2FuIGFkanVzdCB0aGUgYXBwbGljYXRpb24ncw0KPiBiZWhh
dmlvciBieSBjaGFuZ2luZyB0aGUgcXVlcnkgcGFydC4gDQoNCkNoYW5naW5nIHRoZSBxdWVyeSBw
YXJ0IGlzbid0IGhhbmRsaW5nIHRoZSBVUkkgIm9wYXF1ZWx5Ii4NCg0KPiBGb3IgZXhhbXBsZSwg
aWYgd2UgZGVmaW5lIHRoZSBxdWVyeSBwYXJ0ICJtZXRhZGF0YSIgdG8gbWVhbiB0aGF0IG9uZQ0K
PiBkZXNpcmVzIHRvIHJldHJpZXZlIHRoZSBtZXRhZGF0YSBhYm91dCBhIGJvb2ssIHJhdGhlciB0
aGFuIHRoZQ0KPiBjb250ZW50cyBvZiB0aGUgYm9vaywgdGhlbiB0aGUgbmFtZSBvZiB0aGUgbWV0
YWRhdGEgaXM6DQo+IA0KPiAgICAgdXJuOmlzYm46MC0zOTUtMzYzNDEtMT9tZXRhZGF0YQ0KDQpU
aGlzIGlzIGJhY2t3YXJkcy4gIFRoZSAiP21ldGFkYXRhIiBkb2VzIG5vdCBleGhpYml0IGFueSBv
Zg0KdGhlIG1hbmFnZWQgcHJvY2VzcyBwcm9taXNlIG9mIHBlcm1hbmVuY2UuICBQcmVwZW5kaW5n
DQoiaHR0cDovL21ldGFkYXRhLm9yZy8iIGlzIG1vcmUgYXBwcm9wcmlhdGUgdGhhbiBhcHBlbmRp
bmcNCiI/bWV0YWRhdGEiLiANCg0KPiAgIEluIGEgcGhpbG9zb3BoaWNhbCB3YXksIHdlIGNhbiBj
b25zaWRlciB0aGUgbWV0YWRhdGEgdG8gYmUNCj4gcGFydCBvZiB0aGUgcmVzb3VyY2UgdGhhdCBp
cyB0aGUgYm9vayA8dXJuOmlzYm46MC0zOTUtMzYzNDEtMT4uIA0KDQpVbmxlc3MgdGhlIG1ldGFk
YXRhIGluY2x1ZGVzIGF0dHJpYnV0ZXMgbGlrZSAicHJpY2Ugb24gQW1hem9uIg0Kb3IgImNvbnRl
bnQgcmF0aW5nIiBvciAiY29weXJpZ2h0IGxpY2Vuc2Ugc3RhdHVzIi4gDQoNCj4gT1RPSCwNCj4g
dGhlICJib29rIiA8dXJuOmlzYm46MC0zOTUtMzYzNDEtMT4gaXMgb25seSBhIG1lbnRhbCBjb25z
dHJ1Y3Rpb247IGl0DQo+IGRlc2lnbmF0ZXMgYSBsYXJnZSBzZXQgb2YgbmVhcmx5IGlkZW50aWNh
bCBwaHlzaWNhbCBvYmplY3RzLg0KDQpJIGRvbid0IHVuZGVyc3RhbmQgaG93IHRoaXMgaWRlbnRp
ZmljYXRpb24gaXMgbW9yZSAib25seSBtZW50YWwiDQp0aGFuIGFueSBvdGhlciBVUkkuDQoNCj4g
QnV0IHZlcnkgY29udmVuaWVudGx5LCBhIGh1bWFuIG9yIGFwcGxpY2F0aW9uIGNhbiBlYXNpbHkg
ZXh0cmFjdCB0aGUNCj4gVVJOIG9mIHRoZSB1bmRlcmx5aW5nICJib29rIiBieSBkZWxldGluZyB0
aGUgcXVlcnkgcGFydCB0byBvYnRhaW46DQo+IA0KPiAgICAgdXJuOmlzYm46MC0zOTUtMzYzNDEt
MQ0KDQpSZW1vdmluZyBvcGFxdWVuZXNzLg0KDQo+IChUaGlzIGNhdXNlcyBtZSB0byBpbWFnaW5l
IGEgZnV0dXJlIHJldHJpZXZhbCBkZXZpY2UgaW4gYSBsaWJyYXJ5LA0KPiB3aGljaCB3aGVuIHBy
ZXNlbnRlZCB3aXRoIDx1cm46aXNibjowLTM5NS0zNjM0MS0xPiBkZWxpdmVycyB0byB0aGUNCj4g
dXNlciBhICpwaHlzaWNhbCBib29rKi4gIFRvIG9idGFpbiBhIGRpZ2l0YWwgcmVwcmVzZW50YXRp
b24sDQo+IDx1cm46aXNibjowLTM5NS0zNjM0MS0xP2RhdGE+IG11c3QgYmUgdXNlZCAuLi4pDQoN
Ck5vdCByZWFsbHkgcmVsZXZhbnQgYnV0IGluc3RydWN0aXZlLg0KDQo+IEFub3RoZXIgZXhhbXBs
ZTogYSBodW1hbiBjb3VsZCBwcmVzZW50IHRoaXMgcXVhc2ktbmFtZSB0byBhbg0KPiBhcHBsaWNh
dGlvbjoNCj4gDQo+ICAgICB1cm46aXNibjowLTM5NS0zNjM0MS0xP3Jlc29sdmVyPXozOTUwLmxv
Yy5nb3YNCg0Kb3INCiAgIHJlc29sdmU6Ly96Mzk1MC5sb2MuZ292L3Vybjppc2JuLTM5NS0zNjM0
MS0xDQoNCndvdWxkIGJlIGEgYmV0dGVyIFVSSS4gQWdhaW4sIHhyaSBkb2VzIHRoaXMsIGFsdGhv
dWdoIGluIGENCm1vcmUgcHJpbmNpcGxlZCB3YXkuDQoNCkknbGwgc2VuZCBhIHNlcGFyYXRlIG5v
dGUgYWJvdXQgdGhlIHByaXZhY3kgaW1wbGljYXRpb25zDQpvZiBkaXN0cmlidXRlZCBVUk4gcmVz
b2x1dGlvbi4NCg0KPiBiZWNhdXNlIHRoZSBodW1hbiBrbm93cyB0aGF0IHRoZSByZXNvbHZlciBh
dCB6Mzk1MC5sb2MuZ292IGlzICJiZXR0ZXIiDQo+IGluIHNvbWUgd2F5IGZvciB0aGlzIHBhcnRp
Y3VsYXIgcmV0cmlldmFsIHRhc2suDQoNClRoaXMgaXMgbW9yZSBsaWtlIGNob29zaW5nIHdoaWNo
IHByb3h5IHRvIGdvIHRvLg0KDQo+IEJ1dCBpZiB0aGUgYXBwbGljYXRpb24gc2F2ZXMgdGhlIFVS
TiBhbmQgbm93IG9yIGxhdGVyIGRpc2NvdmVycyB0aGF0DQo+IHRoZSBxdWFzaS1uYW1lIGlzIHVu
dXNhYmxlIGJlY2F1c2UgejM5NTAubG9jLmdvdiBubyBsb25nZXIgZXhpc3RzIGluDQo+IEROUywg
dGhlIGFwcGxpY2F0aW9uIGNhbiAqYWxnb3JpdGhtaWNseSogcmVtb3ZlIHRoZSBxdWVyeSB0byBv
YnRhaW4NCj4gDQo+ICAgICB1cm46aXNibjowLTM5NS0zNjM0MS0xDQoNClJlbW92aW5nIGEgJ3Jl
c29sdmU6Ly9ob3N0LycgcHJlZml4IGlzIGFzIGVhc3kgYXMgcmVtb3ZpbmcgYSAnP3Jlc29sdmVy
PScNCnN1ZmZpeCwgd2l0aG91dCBwb2xsdXRpbmcgZXhpc3RpbmcgVVJOcy4NCg0KPiB3aGljaCBj
YW4gYmUgYXNzdW1lZCB0byBiZSBtb3JlIHNlbWFudGljYWxseSBzdGFibGUgdGhhbiB0aGUgYWJv
dmUNCj4gVVJOICh0aG91Z2ggaXQgd291bGQgaGF2ZSBiZWVuIGxlc3MgdXNlZnVsIHdoZW4gdGhl
IG5hbWUgd2FzIGluaXRpYWxseQ0KPiB1c2VkKS4NCg0KcmVzb2x2ZTogb3IgeHJpOiBVUklzIGFy
ZSBzZW1hbnRpY2FsbHkgc3RhYmxlLg0KDQo+ID4gVHlwaWNhbCB1c2UgY2FzZSBpcyBhIHJlc2Vh
cmNoZXIgd2hvIGNpdGVzIGEgZG9jdW1lbnQsIGFuZCBhZGRzIGENCj4gPiBmcmFnbWVudCB0byB0
aGUgVVJOIHNvIHRoYXQgcmVhZGVycyB3aG8gY2xpY2sgdGhlIGxpbmsgYXJlIHRha2VuDQo+ID4g
ZGlyZWN0bHkgdG8gdGhlIHJlbGV2YW50IGxvY2F0aW9uIHdpdGhpbiB0aGUgcmVmZXJyZWQgcmVz
b3VyY2UuDQo+IA0KPiBJIHRoaW5rIGV2ZXJ5b25lIGFncmVlcyB3aXRoIHlvdSBvbiB0aG9zZSBw
b2ludHMuDQoNCkkgdGhpbmsgdGhlIHNjZW5hcmlvIGlzIHdpc2hmdWwgdGhpbmtpbmcsIGFuZCBu
byBjaGFuZ2UNCnRvIElFVEYgZG9jdW1lbnRzIHdpbGwgbWFrZSBpdCB3b3JrLg0KDQoNCj4gSW4g
YWRkaXRpb24sIHRoZXJlIHNlZW0gdG8gbWUgdG8gYmUgcmVsYXRlZCBpc3N1ZXMgaW52b2x2aW5n
Og0KPiANCj4gLSBpbnRlcm5hdGlvbmFsaXphdGlvbg0KPiANCj4gVVJJcyBjYW4gb25seSBkaXJl
Y3RseSB1c2UgYSBzdWJzZXQgb2YgVVMtQVNDSUksIGFuZCBVUk5zIGFyZSB0aHVzDQo+IGxpbWl0
ZWQgaW4gdGhlIHNhbWUgd2F5LiAgVGhpcyBpcyBpbmNvbnZlbmllbnQgZm9yIGNvbnN0cnVjdGlu
ZyBVUk5zDQo+IHRoYXQgcmVmZXJlbmNlIGFueSBuYXR1cmFsIGxhbmd1YWdlIHRoYW4gRW5nbGlz
aC4gIEhvd2V2ZXIsIHRoZXJlIGlzDQo+IGFuIGVzY2FwZSBtZWNoYW5pc20gdGhhdCBhbGxvd3Mg
YW55IFVuaWNvZGUgY2hhcmFjdGVyIHRvIGJlIGV4cHJlc3NlZA0KPiBpbiBhbiBhd2t3YXJkIGVz
Y2FwZWQgd2F5LiAgDQoNCk9mIGNvdXJzZSB5b3UgY291bGQgYWxsb3cgSVJJIHVybjogcy4gDQoN
Cj4gLSB1c2VyIHByZXNlbnRhdGlvbg0KPiANCj4gQ3VycmVudGx5LCB0aGUgc3RhbmRhcmRzIGRl
ZmluZSBvbmx5IGhvdyBVUk5zIGFwcGVhciAib24gdGhlIHdpcmUiLg0KPiBUaGVyZSBpcyBhbiBh
c3N1bXB0aW9uIHRoYXQgd2hlbmV2ZXIgVVJOcyBoYXZlIHRvIGJlIGlucHV0IGJ5IGEgdXNlcg0K
PiBvciBkaXNwbGF5ZWQgdG8gYSB1c2VyLCB0aGV5IHdpbGwgYmUgcHJlc2VudGVkIGluIGEgZm9y
bSB2ZXJ5IGNsb3NlIHRvDQo+IHRoZSAid2lyZSIgZm9ybWF0Lg0KPiANCj4gSG93ZXZlciwgdGhl
IGxpbWl0ZWQgY2hhcmFjdGVyIHNldCBvZiBVUk5zIGlzIGxhcmdlbHkgYmFzZWQgb24gdGhlDQo+
IGRlc2lyYWJpbGl0eSBvZiBlbWJlZGRpbmcgdGhlbSBpbiBsb25nZXIgdGV4dCBzdHJpbmdzLCBh
cyB0aGF0IG1ha2VzDQo+IGl0IGVhc2llciB0byBwYXJzZSB0aGUgbG9uZ2VyIHN0cmluZyBhbmQg
ZXh0cmFjdCB0aGUgVVJOLiAgIkZvcg0KPiBleGFtcGxlLCBwbGVhc2UgY2xpY2sgb24gPGh0dHA6
Ly9leGFtcGxlLmNvbS9kb2N1bWVudC50eHQ+LiINCj4gSG93ZXZlciwNCj4gaW4gbWF5IGNpcmN1
bXN0YW5jZXMgKGUuZy4sIEdVSXMpLCB0aGUgVVJOIHN0cmluZyBpcyAiZnJhbWVkIiBpbiBhIHdh
eQ0KPiB0aGF0IGlzIG5vdCBpbmNvbnZlbmllbmNlZCBieSBhbnkgY2hhcmFjdGVyIHRoYXQgdGhl
IHN0cmluZyBtaWdodA0KPiBjb250YWluLg0KDQpUaGlzIGlzc3VlIGlzIHJlc29sdmVkIGZvciBJ
UklzLCB3aGljaCB1cm4ncyBjb3VsZCBiZWNvbWUuDQoNCj4gKEEgc2ltaWxhciBwaGVub21lbm9u
IGhhcHBlbnMgaW4gZmlsZSBuYW1lcy4gIEluIFVuaXggc3lzdGVtcywgZmlsZQ0KPiBuYW1lcyBh
cmUgdmVyeSBvZnRlbiB3cml0dGVuIGluIGEgImNvbW1hbmQgbGluZSIgY29udGV4dCB3aGVyZSB0
aGUNCj4gc3BhY2UgY2hhcmFjdGVyIGhhcyBhIHNwZWNpYWwgbWVhbmluZy4gIFRoYXQgcmVxdWly
ZXMgYSBzcGFjZSB0aGF0IGlzDQo+IGNvbnRhaW5lZCBpbiBhIGZpbGUgbmFtZSB0byBiZSByZXBy
ZXNlbnRlZCBpbiBhbiBhd2t3YXJkICJlc2NhcGVkIg0KPiBmb3JtYXQuICBCdXQgaW4gTVMgV2lu
ZG93cyBzeXN0ZW1zLCBmaWxlIG5hbWVzIGFyZSBhbG1vc3QgYWx3YXlzDQo+IHByZXNlbnRlZCBp
biBhIEdVSSBjb250ZXh0IHdoZXJlIHNwYWNlIGhhcyBubyBzcGVjaWFsIG1lYW5pbmcuICBUaHVz
LA0KPiBmaWxlIG5hbWUgZW50cnkgaW4gV2luZG93cyByYXJlbHkgbmVlZHMgdG8gdHJlYXQgdGhl
IHNwYWNlIGNoYXJhY3Rlcg0KPiBpbiBhIHNwZWNpYWwgd2F5LikNCg0KVW50aWwgeW91IGdvIGlu
dG8gY21kIGFuZCB0eXBlIGNkLg0KDQo+IEluIHRoaXMgcmVnYXJkLCB3ZSBtYXkgd2FudCB0byBz
dGFuZGFyZGl6ZSB0d28gZGlmZmVyZW50IHdheXMgb2YNCj4gcHJlc2VudGluZyBhIFVSTjogIG9u
ZSB3aGljaCBhZGhlcmVzIHRvIHRoZSBjdXJyZW50IHN5bnRheCBhbmQgaXMgdG8NCj4gYmUgdXNl
ZCAib24gdGhlIHdpcmUiLCBhbmQgb25lIHdoaWNoIGFsbG93cyBkaXJlY3QgZXhwcmVzc2lvbiBv
Zg0KPiBhcmJpdHJhcnkgbGluZ3Vpc3RpYyB0ZXh0LCBidXQgd2hpY2ggZGVwZW5kcyBvbiBleHRl
cm5hbCBmcmFtaW5nLiAgVGhlDQo+IGxhdHRlciBmb3JtYXQgY291bGQgYmUgdXNlZCBmb3IgdXNl
ciBpbnRlcmFjdGlvbiBpbiBzaXR1YXRpb25zIHdoZXJlDQo+IHRoZSBpbnRlcmZhY2UgcHJvdmlk
ZXMgZnJhbWluZy4gIFdlIGNvdWxkIHRoZW4gc3RhbmRhcmRpemUgYSBtYXBwaW5nDQo+IGJldHdl
ZW4gdGhlIHR3byBmb3JtYXRzLg0KDQpJZiB5b3Ugc2F5IFVSTnMgYXJlIFVSSXMgdGhlbiB5b3Ug
Y2FuIHVzZSB0aGUgSVJJIG1hcHBpbmcgd2l0aG91dA0KaGF2aW5nIHRvIHJlZGVmaW5lIGFsbCBv
ZiB0aGUgbWVjaGFuaXNtcy4NCg0KDQoNCg==


From nobody Sun Jul 13 02:51:17 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8091B2A28 for ; Sun, 13 Jul 2014 02:51:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.442
X-Spam-Level: 
X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=no
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 40J2k8M4DH3G for ; Sun, 13 Jul 2014 02:51:14 -0700 (PDT)
Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 123CA1B2A23 for ; Sun, 13 Jul 2014 02:51:13 -0700 (PDT)
Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 0E50F32E579; Sun, 13 Jul 2014 18:51:12 +0900 (JST)
Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 3685_8fdc_aaba3793_76e2_49f3_ad39_708f998fbdeb; Sun, 13 Jul 2014 18:51:11 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 6EF0FC00D9; Sun, 13 Jul 2014 18:51:10 +0900 (JST)
Message-ID: <53C2567D.20202@it.aoyama.ac.jp>
Date: Sun, 13 Jul 2014 18:50:53 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Andrew Newton , "urn@ietf.org" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/fewVYKke2GyndAOdXfWXFle-Ypg
Subject: Re: [urn] Agenda for IETF 90
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Jul 2014 09:51:15 -0000

On 2014/07/12 03:59, Andrew Newton wrote:
> We are currently scheduled for Friday, July 25, 1150 - 1320.

I'm sorry I'll not be able to attend this session in person, and I'll=20
also not be able to attend remotely, because it's at a time of the day=20
where my body isn't useful for anything much else than sleeping :-(.

> 1. Agenda Bashing
>
> 2. draft-ietf-urnbis-urns-are-not-uris
>     John Klensin
>
> NOTE: The purpose of this session is to discuss the important topic
> of separating URNs from URIs.

Terminology differences don't get solved by splitting, only by clear=20
explanations. URIs are an extremely general concept, and URNs can easily=20
live within (and be much more restricted to address the needs of the=20
communities using them). There is therefore no need for a "split".

> Of specific interest are the following
> questions:
>    1) Will allowing the use of the reserved characters ?=E2=80=99 and =E2=
=80=98#=E2=80=99 or
>       other expansions of syntax cause URN interoperability problems?

This is a question completely unrelated to the "split". It is a very=20
good and important question, and I hope some useful information can be=20
gathered in Toronto and otherwise, but essentially:
- If the use of '?' or '#' causes interoperability problems, then that's
   a problem for URNs, and no "split" from URIs will solve it.
- If the use of '?' or '#' does not cause interoperability problems,
   then that's not a problem, because URI/IRI syntax allows '?' and '#'.

>    2) If there is no interoperability harm, is the approach to separate
>       URNs from the URI framework the currently-known, least-bad
>       approach?

No. There is no need for a "split". URNs fit very well into the URI=20
framework, because the URI framework is *extremely* general.

>    3) If URNs are to be separated from the URI framework then how
>       should it be done?

It shouldn't be done, so the question of how it should be done is=20
irrelevant.

> 3. Any Other Business

There are various proposals for how to use query parts, how to create=20
registries, and so on. These should be discussed in detail, so that some=20
progress can be made.

Regards,   Martin.


From nobody Mon Jul 14 00:52:28 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E231A0350 for ; Mon, 14 Jul 2014 00:52:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.442
X-Spam-Level: 
X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=no
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 2BK5Y2u49gCy for ; Mon, 14 Jul 2014 00:52:23 -0700 (PDT)
Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id DABE31A0349 for ; Mon, 14 Jul 2014 00:52:21 -0700 (PDT)
Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 4D26B32E590; Mon, 14 Jul 2014 16:52:20 +0900 (JST)
Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 3090_1b32_16559d76_3375_4635_8878_3161e08c1057; Mon, 14 Jul 2014 16:52:20 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 8C3DDC037E; Mon, 14 Jul 2014 16:52:19 +0900 (JST)
Message-ID: <53C38C23.7040205@it.aoyama.ac.jp>
Date: Mon, 14 Jul 2014 16:52:03 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Barry Leiba , "urn@ietf.org" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/soHYavod-9Ucc9-Edu0ZgI5j_gM
Subject: Re: [urn] URNs, URIs, this working group's job, and some steering
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Jul 2014 07:52:25 -0000

Hello Barry, others,

Sorry for the delay of my answer to your AD interrupt.

On 2014/07/10 05:32, Barry Leiba wrote:
> Hey, all.
> I'd like to throw in an AD interrupt designed to steer the recent
> discussion a bit.

Thanks for this!


> What this working group needs to do is update the various URN specs,
> specifically taking into account the needs of the library community --
> as we update the specs for ISBN and the others.

Very good. Let's do it.


> We determined that we were getting stuck in some of the discussions by
> a disparity in the needs we were considering and the restrictions that
> RFC 3986 puts on URNs.  Of course, there's an issue here: the URN
> specs all predate 3986, and 3986 said things about URNs with a
> different view and different needs in mind.

I don't understand why RFC 3986 wouldn't address the needs of URNs 
because the URN specs were written before RFC 3986. Wouldn't one assume 
that if RFC 3986 was written after the URN specs, it would have taken 
them into account? Wouldn't one assume that if this weren't the case, 
RFC 3986 wouldn't have passed IETF last call?

And that's pretty much the case. As others, in particular Julian, have 
already shown, neither syntax nor semantics in RFC 3986 in any way 
contradict what the URN specs currently say. As far as my (admittedly 
limited) understanding of the intended/planned 
extensions/additions/clarifications to the URN specs goes, there is also 
nothing in RFC 3986 that would contradict any such intentions/plans.

Granted, the terminology in RFC 3986 isn't exactly the terminology of 
the library community (because RFC 3986 was written for a much wider 
audience). But words are just words. If it turns out to be really 
heplful in the URN specs, there's nothing against e.g. writing "in this 
series of specifications, the term 'identifier'(*), in contrast to its 
meaning in RFC 3986, is defined as follows:". (*: replace with favorite 
term(s) of your own). I'm sure it wouldn't be the first RFC where 
something like this happened.


> John has proposed one way of dealing with this issue and allowing us
> to make the kinds of changes we need to make.  As we discuss John's
> proposal we have to keep in mind what this working group's goal is,
> and work toward it.

I just wanted to check on the goals, and for that I went to the charter. 
Among else, I found this interesting piece of text:

"There is a need to clarify that URNs are specific URIs (namely those
using the 'urn' URI scheme) and hence all general URI rules apply to URNs."

The charter also list the following items:
"For RFC 2141, this revision will include in particular:
- an update of the formal syntax specification in the light of the
URI Standard (STD 66, RFC 3986) using the ABNF from STD 68
(RFC 5234);
- a formal IANA registration for the 'urn' URI scheme using the
current template from BCP 35 (RFC 4395);"

These items are easy to complete quickly. There's no problem starting 
some general considerations with "URNs are specific URIs (namely those
using the 'urn' URI scheme) and hence all general URI rules apply to 
URNs." and then immediately continue with "However, URNs have a number 
of special properties not shared generally by other URIs...".

The syntax update and the registration are likewise just formalities.


> That means that it's valid to say that John's proposal isn't the right
> or best way,


John's proposal is neither the right nor the best way. It's actually 
just unnecessary, confusing, and distracting the WG from the necessary 
technical work.



> but that has to go with a technical discussion of an
> alternative proposal that can achieve our goals.  We're at a point, I
> think, where we have to move ourselves out of what I call the "Grand
> Unified Theory of URIs", and think about the specific needs for URNs
> among a growing set of disparate communities that use them (I've
> processed at least seven documents dealing with URN namespaces in my
> 2.5 years as AD, so "growing" is quite accurate).  If we hold on to an
> ideal that doesn't serve the needs of the users, no one wins.

Like others, I'm not seeing *any* conflict here whatsoever. The unified 
theory is indeed unified, but extremely loose. It's *on purpose* made 
lose enough to accommodate almost everybody and everything, including URNs.

What may be more of a problem (and you may be in a good position to tell 
us whether it is or not) is that the growing set of disparate 
communities comes with too disparate expectations for URN namespaces. 
But that would be a problem that would have to be solved *within* URNs.


To give some analogies for why splitting URIs and URNs is a bad idea, 
what would the average IETF participant say to a proposal to separate IP 
addresses for clients and for servers? Such a proposal would be 
completely natural for somebody used to dumb terminals or the French 
minitel system.

Or what about the idea that we need completely separate address formats 
for unicast and multicast communication? Or that we need separate IP 
protocols for UDP and TCP and SCTP and whatnot. And there are other, 
similar analogies.

These analogies all have a rather clear criterion for separation, but 
the benefits of an overall (loose!) unification are bigger in every 
case. And the overall loose unification doesn't preclude differentiation 
at the next level.


> So let's please make sure that as we argue against anything that's
> proposed, we have an alternative proposal that keeps us moving in the
> right direction.

My proposal is to do the actual technical work we are chartered to do, 
in true IETF fashion. (If we aren't clear about what that means, we 
might try to start with a requirements statement.)

I plan to send a mail (or split it up into a few mails) in a thread with 
Juha which I hope will contribute to the technical work. But owning to 
my day job, I won't be able to send more than one or two mails a day.

Regards,   Martin.


> Barry, Applications AD
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn
>


From nobody Mon Jul 14 07:19:41 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936771A04B8 for ; Mon, 14 Jul 2014 07:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level: 
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
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 fixcNyflwYfI for ; Mon, 14 Jul 2014 07:19:37 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93AFD1A0496 for ; Mon, 14 Jul 2014 07:19:37 -0700 (PDT)
Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB308.namprd02.prod.outlook.com (10.141.91.24) with Microsoft SMTP Server (TLS) id 15.0.985.8; Mon, 14 Jul 2014 14:19:36 +0000
Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0985.008; Mon, 14 Jul 2014 14:19:35 +0000
From: Larry Masinter 
To: =?iso-8859-1?Q?_Martin_J=2E_D=FCrst_?= 
Thread-Topic: [urn] URNs, URIs, this working group's job, and some steering
Thread-Index: AQHPm7UORHpPXPfe2kqo257kMudT7pufOZWAgABsRz8=
Date: Mon, 14 Jul 2014 14:19:35 +0000
Message-ID: <19FA6392-C4B8-4915-BC05-A04F906BD84D@adobe.com>
References: ,  <53C38C23.7040205@it.aoyama.ac.jp>
In-Reply-To: <53C38C23.7040205@it.aoyama.ac.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [97.94.246.70]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 02723F29C4
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(479174003)(24454002)(51704005)(199002)(189002)(21056001)(64706001)(50986999)(66066001)(105586002)(77982001)(82746002)(81342001)(74662001)(106356001)(36756003)(99396002)(54356999)(31966008)(81542001)(74502001)(107046002)(106116001)(86362001)(20776003)(83072002)(85852003)(2656002)(79102001)(19580405001)(110136001)(46102001)(85306003)(92726001)(92566001)(19580395003)(76482001)(83322001)(95666004)(80022001)(101416001)(87936001)(83716003)(99286002)(33656002)(76176999)(4396001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB308; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/HrmIfoeDba54oj3N7lq_9T5VDik
Cc: "urn@ietf.org" , Barry Leiba 
Subject: Re: [urn] URNs, URIs, this working group's job, and some steering
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Jul 2014 14:19:39 -0000

> On Jul 14, 2014, at 12:53 AM, "Martin J. D=FCrst"  wrote:
>=20
> Hello Barry, others,
>=20
> Sorry for the delay of my answer to your AD interrupt.
>=20
>> On 2014/07/10 05:32, Barry Leiba wrote:
>> Hey, all.
>> I'd like to throw in an AD interrupt designed to steer the recent
>> discussion a bit.
>=20
> Thanks for this!
>=20
>=20
>> What this working group needs to do is update the various URN specs,
>> specifically taking into account the needs of the library community --
>> as we update the specs for ISBN and the others.
>=20
> Very good. Let's do it.
>=20
>=20
>> We determined that we were getting stuck in some of the discussions by
>> a disparity in the needs we were considering and the restrictions that
>> RFC 3986 puts on URNs.  Of course, there's an issue here: the URN
>> specs all predate 3986, and 3986 said things about URNs with a
>> different view and different needs in mind.
>=20
> I don't understand why RFC 3986 wouldn't address the needs of URNs becaus=
e the URN specs were written before RFC 3986. Wouldn't one assume that if R=
FC 3986 was written after the URN specs, it would have taken them into acco=
unt? Wouldn't one assume that if this weren't the case, RFC 3986 wouldn't h=
ave passed IETF last call?
>=20
>=20


From nobody Mon Jul 14 12:29:43 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0681A007C for ; Mon, 14 Jul 2014 12:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham
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 vDTPdSBJpx25 for ; Mon, 14 Jul 2014 12:29:39 -0700 (PDT)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC2A1A008D for ; Mon, 14 Jul 2014 12:29:39 -0700 (PDT)
Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta04.westchester.pa.mail.comcast.net with comcast id SDr91o0091ap0As54KVfc1; Mon, 14 Jul 2014 19:29:39 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta22.westchester.pa.mail.comcast.net with comcast id SKVe1o00M1KKtkw3iKVeyi; Mon, 14 Jul 2014 19:29:39 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s6EJTcaj004581 for ; Mon, 14 Jul 2014 15:29:38 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s6EJTcoV004580; Mon, 14 Jul 2014 15:29:38 -0400
Date: Mon, 14 Jul 2014 15:29:38 -0400
Message-Id: <201407141929.s6EJTcoV004580@hobgoblin.ariadne.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: urn@ietf.org
In-reply-to: <19FA6392-C4B8-4915-BC05-A04F906BD84D@adobe.com> (masinter@adobe.com)
References: ,  <53C38C23.7040205@it.aoyama.ac.jp> <19FA6392-C4B8-4915-BC05-A04F906BD84D@adobe.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405366179; bh=dwLekeq9bEnWGlozBmLgasPUqqLQ6HE9q7DqVaaZLb0=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=sRt3UMAWEq6GK8V8JOmepd2EZCvACRIZUkj1i6gduAVTC/zHUqkmb4lONr74SlWio lc3Wa5hyI+RMQgftZqMULeG7/TEpRFS3swBzjDGbuBA1cqJYe6GnVIcXNcoe49fQGw bP/KyeC5uRBc7NBhVaK3aLaRZdurWAlencP1hi6JjxRlqdZMlRXvuLj9jRyWtZlge5 /cC1XQSKLPuVUG4IeU6sVKMDFQV8XTkcU146l9xpgSnk6koUfF7XiB832Kd5EzReuB gUFd4Mnb1Ez1ugJUB/2FefTIV7hSUssIXC6t134YUOFLUbr/QdMvTsNCGGRG9XjC+a 6cO6+O8tIWh0A==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/IiR9qKQe6G7KR2sKAggMIJMSRn8
Subject: [urn] Getting people to use proper URNs
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Jul 2014 19:29:42 -0000

If we really want to stop people from using "cool URLs" rather than
proper URNs (which are by standard subject to proper management
processes), we need to overcome the problem that there is no
easily-accessible resolution service for URNs.  And by
"easily-accessible resolution service", I mean "a resolution service
that someone can use without installing client software."

To that end, we could institute a redirector that behaves like this:

The user who is faced with the URN  enters
into his browser something like this:

    http://urn.ietf.org/urn:isni:0000000109022386

The redirector at urn.ietf.org returns a 302 response that is directed
to whatever the actual HTTP-accessible resolution service is, with the
request reformulated into the format that the resolution service
expects.  Of course, urn.ietf.org would have to be provided with a
proper map for how to handle the various NIDs, and that map would have
to be maintained.

Over time, this would allow browser makers to add a special rule that
when a URN is entered into the address field, it can be automagically
reformatted into a URL request.

At that point, there would be no loss to information publishers from
presenting their URNs in proper URN format, rather than as cool URLs",
because URNs would function as links.

Dale


From nobody Tue Jul 15 00:37:20 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1811A0322 for ; Tue, 15 Jul 2014 00:37:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.252
X-Spam-Level: 
X-Spam-Status: No, score=-6.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
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 tgMOdBUdVC6H for ; Tue, 15 Jul 2014 00:37:12 -0700 (PDT)
Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875B81A0320 for ; Tue, 15 Jul 2014 00:37:11 -0700 (PDT)
Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s6F7b8mv014228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 15 Jul 2014 10:37:09 +0300
Message-ID: <53C4DA23.2070503@helsinki.fi>
Date: Tue, 15 Jul 2014 10:37:07 +0300
From: Juha Hakala 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: urn@ietf.org
References:  <53C38C23.7040205@it.aoyama.ac.jp>
In-Reply-To: <53C38C23.7040205@it.aoyama.ac.jp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/iq4tR2eZIQaNS7YgB-3T5OXKiNo
Subject: Re: [urn] URNs, URIs, this working group's job, and some steering
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Jul 2014 07:37:18 -0000

Hello,

On 14.7.2014 10:52, "Martin J. Dürst" wrote:
>
> I don't understand why RFC 3986 wouldn't address the needs of URNs 
> because the URN specs were written before RFC 3986. Wouldn't one 
> assume that if RFC 3986 was written after the URN specs, it would have 
> taken them into account? Wouldn't one assume that if this weren't the 
> case, RFC 3986 wouldn't have passed IETF last call?

One of URNBIS objectives is to update the URN syntax. There are both 
practical and theoretical reasons why aligning RFC2141bis with the 
syntax specified RFC 3986 is important.

On the other hand, it would be problematic from the URN community point 
of view to endorse this:

> An individual scheme does not have to be classified as being just one
>     of "name" or "locator".  Instances of URIs from any given scheme may
>     have the characteristics of names or locators or both, often
>     depending on the persistence and care in the assignment of
>     identifiers by the naming authority, rather than on any quality of
>     the scheme.  Future specifications and related documentation should
>     use the general term "URI" rather than the more restrictive terms
>     "URL" and "URN"

Back when URLs and URNs (locators and names) had not been merged under 
URI umbrella, one could tell that for instance 
"https://www.w3.org/International/wiki/IRIStatus" was just a locator. 
But according to RFC 3986 it is definitely both an URI and a locator, 
and given the naming policy of W3C, also a name. This can be a little 
confusing at times, and IMO not fully aligned with this point of view 
from Functional requirements for URNs (http://www.ietf.org/rfc/rfc1737.txt):

> A URL identifies the location or a container for an
>     instance of a resource identified by a URN.  The resource identified
>     by a URN may reside in one or more locations at any given time, may
>     move, or may not be available at all.


 From the RFC 1737 point of view, names and locators are different:

> It is strongly recommended that there be a mapping between the
>       names generated by each naming authority and URLs.  At any specific
>       time there will be zero or more URLs into which a particular URN
>       can be mapped.  The naming authority itself need not provide the
>       mapping from URN to URL.

Try replacing all instances of URL and URN above with URI ;-).

While RFC 3986 did not obsolete RFC 1737, but it is not fully aligned 
with its requirements. Let's take a closer look on how the term 
identifier is defined. URI syntax specifies identifier like this:

> An identifier embodies the information required to distinguish
>        what is being identified from all other things within its scope of
>        identification.

RFC 3986 says that "in many cases, URIs are used to denote resources 
without any intention that they be accessed". RFC 1737 definition is 
different in this respect (and in some other ways as well):

> The purpose or function of a URN is to provide a globally unique,
>        persistent identifier used for recognition, for access to
>        characteristics of the resource or for access to the resource
>        itself.

This difference does not need to be a problem; we just need to be aware 
that the term identifier has a different meaning in RFC 3986 and in 
URN-related RFCs. It may be possible to fix this by e.g. using 
systematically the term name instead of identifier in RFC 1737bis and 
other URN documents.

If locators can be also names, how can humans / applications tell which 
locators actually do have this double role? As Michael Mealling said in 
a recent message to this list:

> The difference between a URN and any other URI scheme is the following:
>
> Nothing found in RFC 2616 or elsewhere that defines the 'http' scheme tells my software whether
> http://whitehouse.gov/  
> is maintained with sufficient rigor to qualify as "long lived" (the identifier, not the thing it identifies). If I make the assumption that it is and something changes at whitehouse.gov that violates my assumption then that is MY error. It is hard to design protocols based on assumptions.
>
> BUT, in RFC 2141 there IS a statement that if I see
> urn:isbn:whatever
> that I can safely and correctly rely on that identifier being forever bound to the resource (whether that resource is physical, electronic, or metaphysical). If something violates that assumption then I can know that SOMEONE ELSE has made an error.
>
> By using 'urn:' over 'http:' you are making an explicit statement about your intent as verified by the URN registration mechanism.


>
> And that's pretty much the case. As others, in particular Julian, have 
> already shown, neither syntax nor semantics in RFC 3986 in any way 
> contradict what the URN specs currently say. As far as my (admittedly 
> limited) understanding of the intended/planned 
> extensions/additions/clarifications to the URN specs goes, there is 
> also nothing in RFC 3986 that would contradict any such intentions/plans.


Syntax is OK, in that respect the problem is just that the RFC 2141 is 
outdated.

I am not sure what you mean by semantics. But if URI and URN 
specifications have to use for instance the same definition of 
identifier, RFC 1737 needs a face lift. And if the URN community must 
approve of the idea that locators can be names and that in the future we 
need just URIs instead of URNs and URLs, then IMO semantics is a 
problem. At least this statement

> Future specifications and related documentation should
>     use the general term "URI" rather than the more restrictive terms
>     "URL" and "URN" [RFC3305].

should be relaxed so that URNs still have a niche. For instance, it is 
possible to say that URNs are special names which cannot be mistaken to 
be locators (and locators cannot be mistaken to be URNs).

>
> Granted, the terminology in RFC 3986 isn't exactly the terminology of 
> the library community (because RFC 3986 was written for a much wider 
> audience). But words are just words. If it turns out to be really 
> heplful in the URN specs, there's nothing against e.g. writing "in 
> this series of specifications, the term 'identifier'(*), in contrast 
> to its meaning in RFC 3986, is defined as follows:". (*: replace with 
> favorite term(s) of your own). I'm sure it wouldn't be the first RFC 
> where something like this happened.


Words may be just words, but IMO what IETF currently has in its hands is 
confusing. In the past there were just URNs and URLs which had distinct 
roles and which humans and machines could easily tell apart. Now there 
are URIs, names and locators which have been specified in such a way 
that a URI can be just URI, URI and locator, or all three of these, and 
it is anybody's guess what the intention of the naming authority (if 
any) has been. And if the intention was that URI Generic Syntax is 
compliant with the spirit and letter of functional requirements / 
recommendations to URNs and URLs, the current situation does not seem to 
be fully satisfactory.

>
>
>> We're at a point, I
>> think, where we have to move ourselves out of what I call the "Grand
>> Unified Theory of URIs", and think about the specific needs for URNs
>> among a growing set of disparate communities that use them (I've
>> processed at least seven documents dealing with URN namespaces in my
>> 2.5 years as AD, so "growing" is quite accurate).  If we hold on to an
>> ideal that doesn't serve the needs of the users, no one wins.
>
> Like others, I'm not seeing *any* conflict here whatsoever. The 
> unified theory is indeed unified, but extremely loose. It's *on 
> purpose* made lose enough to accommodate almost everybody and 
> everything, including URNs.

Sorry, but I don't think that RFC 3986 accommodates URNs or other 
persistent identifiers too well. But since hundreds of millions of 
persistent identifiers have been assigned since RFC 3986 was written it 
is fair to say that there are plenty of communities out there which do 
not think that it is OK to use locators as names. But there are also a 
lot of communities who are minting plenty of URIs without making it 
clear what these URIs actually are.

A quote from a colleague who has been closely involved with linked data 
projects:

> Yes, the Linked Data world initially took the viewpoint that creating 
> lots of identifiers wasn't a problem, as we could just owl:sameAs them 
> together.  In practice that is a nightmare, of course and as the 
> library world could have told them!  Now there's a trend as far as I 
> can tell towards fewer, more well known identifiers when possible. 
> ISBNs are a great example of this. 


URI gives anyone a privilege to create identifiers, and it looks like 
they have been taken for names even when such assumption is not correct. 
The quote above indicates that in order to make the Web work better, it 
is better to have a small set of well managed identifiers for important 
stuff than plenty of badly managed identifiers for everything out there.

>
> What may be more of a problem (and you may be in a good position to 
> tell us whether it is or not) is that the growing set of disparate 
> communities comes with too disparate expectations for URN namespaces. 
> But that would be a problem that would have to be solved *within* URNs.

One of the strengths of URN is that it can accommodate very different 
communities. Having said that, there are some limits: I have a problem 
with a) namespaces in which the URN assignment is not a well managed 
process, and b) namespaces which do not intend to provide any resolution 
services. These namespaces undermine the value of the URNs as a whole.


>
>
> To give some analogies for why splitting URIs and URNs is a bad idea, 
> what would the average IETF participant say to a proposal to separate 
> IP addresses for clients and for servers? Such a proposal would be 
> completely natural for somebody used to dumb terminals or the French 
> minitel system.


We have not been talking about technical split. It is possible to 
disapprove the view that locators can be names, and create URNs which 
are fully compliant with the URI Generic Syntax.

>
> Or what about the idea that we need completely separate address 
> formats for unicast and multicast communication? Or that we need 
> separate IP protocols for UDP and TCP and SCTP and whatnot. And there 
> are other, similar analogies.
>
> These analogies all have a rather clear criterion for separation, but 
> the benefits of an overall (loose!) unification are bigger in every 
> case. And the overall loose unification doesn't preclude 
> differentiation at the next level.

I wish I could understand what the benefits of introducing URIs have 
been...


>
>
>> So let's please make sure that as we argue against anything that's
>> proposed, we have an alternative proposal that keeps us moving in the
>> right direction.
>
> My proposal is to do the actual technical work we are chartered to do, 
> in true IETF fashion. (If we aren't clear about what that means, we 
> might try to start with a requirements statement.)

I would not mind leaving the further development of URIs (if any) to 
IETF and future WGs. What both IETF and the persistent identifier 
community (which encompasses much more than just libraries) need from 
URNBIS is a URN syntax fully aligned with RFC 3986 (so that it is 
possible to use query and fragment), more efficient namespace 
registration process and a workable means for specifying resolution 
related services and service parameters. If URNBIS fails to deliver, 
there is a risk that URN specifications will be modernized elsewhere, 
and then IETF would no longer have any persistent identifier systems 
under its wing - unless a decision is made to endorse ARKs.

Juha


>
> I plan to send a mail (or split it up into a few mails) in a thread 
> with Juha which I hope will contribute to the technical work. But 
> owning to my day job, I won't be able to send more than one or two 
> mails a day.
>
> Regards,   Martin.
>
>
>> Barry, Applications AD
>>
>> _______________________________________________
>> urn mailing list
>> urn@ietf.org
>> https://www.ietf.org/mailman/listinfo/urn
>>
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn


-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  Library Network Services
  P.O.Box 26 (Teollisuuskatu 23)
  FIN-00014 Helsinki University
  Tel. +358 9 191 44293
  Mobile +358 50 3827678



From nobody Tue Jul 15 02:47:01 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488FA1B2789 for ; Tue, 15 Jul 2014 02:46:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.842
X-Spam-Level: 
X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_36=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 PRm4XNNhOciP for ; Tue, 15 Jul 2014 02:46:41 -0700 (PDT)
Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6F61A0379 for ; Tue, 15 Jul 2014 02:46:40 -0700 (PDT)
Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id BA4C932E579; Tue, 15 Jul 2014 18:46:39 +0900 (JST)
Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 2b09_43bc_6d30ab41_fd8a_4378_9bb8_c587698bf1fd; Tue, 15 Jul 2014 18:46:39 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id DDD95BF537; Tue, 15 Jul 2014 18:46:38 +0900 (JST)
Message-ID: <53C4F86D.5010300@it.aoyama.ac.jp>
Date: Tue, 15 Jul 2014 18:46:21 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Juha Hakala , urn@ietf.org
References:  <53C38C23.7040205@it.aoyama.ac.jp> <53C4DA23.2070503@helsinki.fi>
In-Reply-To: <53C4DA23.2070503@helsinki.fi>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/KJA6RZAEFC4jVTOSKZdjjdttMDE
Subject: Re: [urn] URNs, URIs, this working group's job, and some steering
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Jul 2014 09:46:46 -0000

Hello Juha, others,

On 2014/07/15 16:37, Juha Hakala wrote:
> Hello,
>
> On 14.7.2014 10:52, "Martin J. D=C3=BCrst" wrote:

> On the other hand, it would be problematic from the URN community point
> of view to endorse this:
>
>> An individual scheme does not have to be classified as being just one
>>     of "name" or "locator".  Instances of URIs from any given scheme m=
ay
>>     have the characteristics of names or locators or both, often
>>     depending on the persistence and care in the assignment of
>>     identifiers by the naming authority, rather than on any quality of
>>     the scheme.  Future specifications and related documentation shoul=
d
>>     use the general term "URI" rather than the more restrictive terms
>>     "URL" and "URN"
>
> Back when URLs and URNs (locators and names) had not been merged under
> URI umbrella, one could tell that for instance
> "https://www.w3.org/International/wiki/IRIStatus" was just a locator.
> But according to RFC 3986 it is definitely both an URI and a locator,
> and given the naming policy of W3C, also a name.

I'm not sure "https://www.w3.org/International/wiki/IRIStatus" is the=20
best example. I think a better example would be=20
http://www.w3.org/XML/1998/namespace, the URI of the xml: namespace.=20
This was already mentioned in previous mail. It is used in many contexts=20
where identification is crucial, but retrieval is secondary or=20
unnecessary. In the name/locator dichotomy, this gives it a lot of namene=
ss.

What is the problem with such URIs from the point of view of the URN=20
community? In my understanding, what the URN community needs is that=20
URNs work as "names", and that's the case currently and isn't changed in=20
any way by RFC 3986. It would be strange if the URN community would want=20
to prohibit other communities from experimenting, implementing, and=20
deploying various ways to combine properties of identifiers.


> This can be a little
> confusing at times, and IMO not fully aligned with this point of view
> from Functional requirements for URNs
> (http://www.ietf.org/rfc/rfc1737.txt):

This is a *very* old document, over 20 years old, from the very early=20
days of the Web. Fortunately, one of its authors (Larry) is on this=20
list, so maybe he can say some more about it.

Also, it is a requirements document. In the IETF, as far as my=20
understanding and experience goes, requirements documents are just used=20
as part of the development process, but do not carry any force=20
afterwards. As you can see, RFC 1737 is classified informational, which=20
I guess is true of most if not all requirements documents. If the actual=20
specs produced afterwards are different than the requirements document,=20
e.g. because it turned out that some of the requirements were too=20
ambitious, or that the WG or the IETF as a whole decided on a different=20
path, then that's just the way it is. At least in general, requirements=20
documents aren't revised or obsoleted or anything, they are just left=20
around as historic background.

>> A URL identifies the location or a container for an
>>     instance of a resource identified by a URN.  The resource identifi=
ed
>>     by a URN may reside in one or more locations at any given time, ma=
y
>>     move, or may not be available at all.
>
>
>  From the RFC 1737 point of view, names and locators are different:
>
>> It is strongly recommended that there be a mapping between the
>>       names generated by each naming authority and URLs.  At any speci=
fic
>>       time there will be zero or more URLs into which a particular URN
>>       can be mapped.  The naming authority itself need not provide the
>>       mapping from URN to URL.
>
> Try replacing all instances of URL and URN above with URI ;-).

That indeed doesn't work. But there's no problem translating this into=20
"modern" language. The short version might look something like this: "It=20
is strongly recommended that URNs can be mapped to resolvable URIs."


> While RFC 3986 did not obsolete RFC 1737, but it is not fully aligned
> with its requirements. Let's take a closer look on how the term
> identifier is defined. URI syntax specifies identifier like this:
>
>> An identifier embodies the information required to distinguish
>>        what is being identified from all other things within its scope=
 of
>>        identification.
>
> RFC 3986 says that "in many cases, URIs are used to denote resources
> without any intention that they be accessed". RFC 1737 definition is
> different in this respect (and in some other ways as well):
>
>> The purpose or function of a URN is to provide a globally unique,
>>        persistent identifier used for recognition, for access to
>>        characteristics of the resource or for access to the resource
>>        itself.
>
> This difference does not need to be a problem; we just need to be aware
> that the term identifier has a different meaning in RFC 3986 and in
> URN-related RFCs. It may be possible to fix this by e.g. using
> systematically the term name instead of identifier in RFC 1737bis and
> other URN documents.

Yes indeed. There are various different ways to deal with terminology,=20
and this is indeed one of the better ones.


> If locators can be also names, how can humans / applications tell which
> locators actually do have this double role?

Well, sometimes they can, sometimes they can't. Sometimes they will=20
care, some other times they won't. Let's look at the classical example=20
from Architecture of the World Wide Web, Volume One=20
(http://www.w3.org/TR/webarch/): http://weather.example.com/oaxaca. If=20
this serves today's weather in Oaxaca, then it's probably not something=20
the library community cares about, but to people using it daily, it's a=20
semi-permanent fixture in their lives, even if the actual weather it=20
shows will change a lot (as the weather has a tendency to do).


> As Michael Mealling said in
> a recent message to this list:
>
>> The difference between a URN and any other URI scheme is the following=
:
>>
>> Nothing found in RFC 2616 or elsewhere that defines the 'http' scheme
>> tells my software whether
>> http://whitehouse.gov/ is maintained with sufficient rigor to qualify
>> as "long lived" (the identifier, not the thing it identifies). If I
>> make the assumption that it is and something changes at whitehouse.gov
>> that violates my assumption then that is MY error. It is hard to
>> design protocols based on assumptions.
>>
>> BUT, in RFC 2141 there IS a statement that if I see
>> urn:isbn:whatever
>> that I can safely and correctly rely on that identifier being forever
>> bound to the resource (whether that resource is physical, electronic,
>> or metaphysical). If something violates that assumption then I can
>> know that SOMEONE ELSE has made an error.
>>
>> By using 'urn:' over 'http:' you are making an explicit statement
>> about your intent as verified by the URN registration mechanism.

That's just fine. By using http: over urn:, the White House isn't
making such a statement. Do they need to make such a statement?

By using http://www.w3.org/XML/1998/namespace, the W3C isn't taking=20
advantage of the urn: convention, but they still can promise to keep=20
this identifier permanent. Do they *need* to use urn:?



>> And that's pretty much the case. As others, in particular Julian, have
>> already shown, neither syntax nor semantics in RFC 3986 in any way
>> contradict what the URN specs currently say. As far as my (admittedly
>> limited) understanding of the intended/planned
>> extensions/additions/clarifications to the URN specs goes, there is
>> also nothing in RFC 3986 that would contradict any such intentions/pla=
ns.
>
>
> Syntax is OK, in that respect the problem is just that the RFC 2141 is
> outdated.

Okay, great.

> I am not sure what you mean by semantics. But if URI and URN
> specifications have to use for instance the same definition of
> identifier, RFC 1737 needs a face lift.

As I said above, requirements documents aren't updated in the IETF.

> And if the URN community must
> approve of the idea that locators can be names

Why do they need to approve? If something starting with http: is used as=20
a name, then isn't it just a name?

> and that in the future we
> need just URIs instead of URNs and URLs, then IMO semantics is a
> problem. At least this statement
>
>> Future specifications and related documentation should
>>     use the general term "URI" rather than the more restrictive terms
>>     "URL" and "URN" [RFC3305].
>
> should be relaxed so that URNs still have a niche. For instance, it is
> possible to say that URNs are special names which cannot be mistaken to
> be locators

The updated URN spec(s) can very well say something along these lines.

> (and locators cannot be mistaken to be URNs).

If URN means just things starting with urn:, then I think it's obvious=20
that schemes with other prefixes cannot be confused with urn:.


>> Granted, the terminology in RFC 3986 isn't exactly the terminology of
>> the library community (because RFC 3986 was written for a much wider
>> audience). But words are just words. If it turns out to be really
>> heplful in the URN specs, there's nothing against e.g. writing "in
>> this series of specifications, the term 'identifier'(*), in contrast
>> to its meaning in RFC 3986, is defined as follows:". (*: replace with
>> favorite term(s) of your own). I'm sure it wouldn't be the first RFC
>> where something like this happened.
>
>
> Words may be just words, but IMO what IETF currently has in its hands i=
s
> confusing. In the past there were just URNs and URLs which had distinct
> roles and which humans and machines could easily tell apart. Now there
> are URIs, names and locators which have been specified in such a way
> that a URI can be just URI, URI and locator, or all three of these, and
> it is anybody's guess what the intention of the naming authority (if
> any) has been. And if the intention was that URI Generic Syntax is
> compliant with the spirit and letter of functional requirements /
> recommendations to URNs and URLs, the current situation does not seem t=
o
> be fully satisfactory.

One of the main goals of IETF specs is to be in line with practice. The=20
observation leading up to RFC 3986 was that the boundary between names=20
and locators, although very clear in some cases (e.g. libraries), isn't=20
as clear cut in other cases. That doesn't mean that there can't be=20
scheme prefixes (urn: would be the classical example) where the boundary=20
is very visible and the position of the scheme is very clear.


>>> We're at a point, I
>>> think, where we have to move ourselves out of what I call the "Grand
>>> Unified Theory of URIs", and think about the specific needs for URNs
>>> among a growing set of disparate communities that use them (I've
>>> processed at least seven documents dealing with URN namespaces in my
>>> 2.5 years as AD, so "growing" is quite accurate).  If we hold on to a=
n
>>> ideal that doesn't serve the needs of the users, no one wins.
>>
>> Like others, I'm not seeing *any* conflict here whatsoever. The
>> unified theory is indeed unified, but extremely loose. It's *on
>> purpose* made lose enough to accommodate almost everybody and
>> everything, including URNs.
>
> Sorry, but I don't think that RFC 3986 accommodates URNs or other
> persistent identifiers too well.]

In the sense that it says that there can be all kinds of schemes and=20
identifiers that may have different degree of "nameness" or=20
"locatorness" or other properties, it doesn't give much of a special=20
place to URNs or the urn: scheme indeed.


> But since hundreds of millions of
> persistent identifiers have been assigned since RFC 3986 was written it
> is fair to say that there are plenty of communities out there which do
> not think that it is OK to use locators as names.

That's just okay. Nobody is telling anybody that they should mint http:=20
URIs as names if they don't want.


> But there are also a
> lot of communities who are minting plenty of URIs without making it
> clear what these URIs actually are.
>
> A quote from a colleague who has been closely involved with linked data
> projects:
>
>> Yes, the Linked Data world initially took the viewpoint that creating
>> lots of identifiers wasn't a problem, as we could just owl:sameAs them
>> together.  In practice that is a nightmare, of course and as the
>> library world could have told them!  Now there's a trend as far as I
>> can tell towards fewer, more well known identifiers when possible.
>> ISBNs are a great example of this.

That's probably just fine. RFC 3986 isn't inhibiting this in any way.


> URI gives anyone a privilege to create identifiers, and it looks like
> they have been taken for names even when such assumption is not correct=
.
> The quote above indicates that in order to make the Web work better, it
> is better to have a small set of well managed identifiers for important
> stuff than plenty of badly managed identifiers for everything out there=
.

Well, that's most probably true. But managing identifiers well is=20
expensive. For some purpose, this expense may not be justified.



> One of the strengths of URN is that it can accommodate very different
> communities. Having said that, there are some limits: I have a problem
> with a) namespaces in which the URN assignment is not a well managed
> process,

I guess that should go without saying.

> and b) namespaces which do not intend to provide any resolution
> services.

Well, first, up to now providing resolution services wasn't exactly=20
easy. Some specs existed, but not much in terms of actual technology. Of=20
course this may change. Second, there may indeed be URN namespaces that=20
from the beginning didn't intend to provide any resolution services, for=20
whatever reason. I don't think it would be possible to force them=20
retrospectively to provide such services.


>> To give some analogies for why splitting URIs and URNs is a bad idea,
>> what would the average IETF participant say to a proposal to separate
>> IP addresses for clients and for servers? Such a proposal would be
>> completely natural for somebody used to dumb terminals or the French
>> minitel system.
>
>
> We have not been talking about technical split.

If John's document isn't a technical split, then it would be good if it=20
clarified what kind of split it is. But that's probably for John to do,=20
not for you.

Regards,    Martin.


> It is possible to
> disapprove the view that locators can be names, and create URNs which
> are fully compliant with the URI Generic Syntax.
>
>>
>> Or what about the idea that we need completely separate address
>> formats for unicast and multicast communication? Or that we need
>> separate IP protocols for UDP and TCP and SCTP and whatnot. And there
>> are other, similar analogies.
>>
>> These analogies all have a rather clear criterion for separation, but
>> the benefits of an overall (loose!) unification are bigger in every
>> case. And the overall loose unification doesn't preclude
>> differentiation at the next level.
>
> I wish I could understand what the benefits of introducing URIs have
> been...
>
>
>>
>>
>>> So let's please make sure that as we argue against anything that's
>>> proposed, we have an alternative proposal that keeps us moving in the
>>> right direction.
>>
>> My proposal is to do the actual technical work we are chartered to do,
>> in true IETF fashion. (If we aren't clear about what that means, we
>> might try to start with a requirements statement.)
>
> I would not mind leaving the further development of URIs (if any) to
> IETF and future WGs. What both IETF and the persistent identifier
> community (which encompasses much more than just libraries) need from
> URNBIS is a URN syntax fully aligned with RFC 3986 (so that it is
> possible to use query and fragment), more efficient namespace
> registration process and a workable means for specifying resolution
> related services and service parameters. If URNBIS fails to deliver,
> there is a risk that URN specifications will be modernized elsewhere,
> and then IETF would no longer have any persistent identifier systems
> under its wing - unless a decision is made to endorse ARKs.
>
> Juha
>
>
>>
>> I plan to send a mail (or split it up into a few mails) in a thread
>> with Juha which I hope will contribute to the technical work. But
>> owning to my day job, I won't be able to send more than one or two
>> mails a day.
>>
>> Regards,   Martin.
>>
>>
>>> Barry, Applications AD
>>>
>>> _______________________________________________
>>> urn mailing list
>>> urn@ietf.org
>>> https://www.ietf.org/mailman/listinfo/urn
>>>
>>
>> _______________________________________________
>> urn mailing list
>> urn@ietf.org
>> https://www.ietf.org/mailman/listinfo/urn
>
>


From nobody Thu Jul 17 15:28:42 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A931A01C5 for ; Thu, 17 Jul 2014 15:28:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
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 IOrWDaCyGp1v for ; Thu, 17 Jul 2014 15:28:38 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 671AB1A00AF for ; Thu, 17 Jul 2014 15:28:38 -0700 (PDT)
Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB308.namprd02.prod.outlook.com (10.141.91.24) with Microsoft SMTP Server (TLS) id 15.0.990.7; Thu, 17 Jul 2014 22:28:30 +0000
Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0990.007; Thu, 17 Jul 2014 22:28:30 +0000
From: Larry Masinter 
To: "urn@ietf.org" 
Thread-Topic: [urn] URNs, URIs, this working group's job, and some steering
Thread-Index: AQHPm7UORHpPXPfe2kqo257kMudT7puY4i+AgAA8vwCAAKsLR4ALF8og
Date: Thu, 17 Jul 2014 22:28:29 +0000
Message-ID: <9c6dc1f783a1459f824cde09f33daa38@BL2PR02MB307.namprd02.prod.outlook.com>
References:  <53BE3A55.3020806@gmx.de> <53BE6D4A.3050206@helsinki.fi> <201407102050.s6AKo5K9008755@hobgoblin.ariadne.com>
In-Reply-To: <201407102050.s6AKo5K9008755@hobgoblin.ariadne.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [97.94.246.70]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 027578BB13
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(87936001)(2656002)(110136001)(76576001)(95666004)(99286002)(85306003)(101416001)(54356999)(76176999)(74316001)(99396002)(46102001)(50986999)(93886003)(81542001)(19580395003)(33646002)(79102001)(15975445006)(76482001)(77982001)(83072002)(74662001)(21056001)(4396001)(74502001)(107886001)(2351001)(107046002)(81342001)(105586002)(92566001)(15202345003)(106116001)(86362001)(106356001)(31966008)(85852003)(64706001)(20776003)(66066001)(80022001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB308; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/LSQ1HV4FOI_ahlE6WzG6hivIg3g
Subject: Re: [urn] URNs, URIs, this working group's job, and some steering
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Jul 2014 22:28:41 -0000

I wanted to summarize my position.

a) I don't think any changes to 3986 are actually necessary to
    allow URNbis to do what is requested, although some
    changes would be useful.

b) splitting URNs from URIs is harmful to many use cases.

c) what is being suggested (and motivating) -- adding query=20
     parameters -- is actively harmful for non-document
    applications of URNs

d) The threat that some other group will redefine URN
    for their own purposes has already happened, although
   they were polite enough to call it 'xri' and not 'urn'.

e) The privacy impact of the underlying system architecture --
   that URNs would be sent to a service which would provide
    location information for the name -- has terrible=20
    privacy implications.=20

f) The actual modern needs of 'memory institutions'=20
    for identification and as keys in indexing systems
    goes far beyond those represented here. The=20
   'systems' track of the annual IS&T Archiving conference
    http://www.imaging.org/ist/conferences/archiving/
    is a good source of reference for the range of=20
   identification issues that need solutions for which
   URNs are inadequate, no matter how tarted up.


From nobody Thu Jul 17 15:36:46 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA161A0251 for ; Thu, 17 Jul 2014 15:36:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
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 f9q1TzAFs03H for ; Thu, 17 Jul 2014 15:36:43 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FDCD1A0250 for ; Thu, 17 Jul 2014 15:36:43 -0700 (PDT)
Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB306.namprd02.prod.outlook.com (10.141.91.19) with Microsoft SMTP Server (TLS) id 15.0.990.7; Thu, 17 Jul 2014 22:36:41 +0000
Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0990.007; Thu, 17 Jul 2014 22:36:41 +0000
From: Larry Masinter 
To: "urn@ietf.org" 
Thread-Topic: [urn] URNs, URIs, this working group's job, and some steering
Thread-Index: AQHPm7UORHpPXPfe2kqo257kMudT7puY4i+AgAA8vwCAAKsLR4ALF8oggAAEsxA=
Date: Thu, 17 Jul 2014 22:36:41 +0000
Message-ID: <353845f4429c4a0b87efc500daf47dff@BL2PR02MB307.namprd02.prod.outlook.com>
References:  <53BE3A55.3020806@gmx.de> <53BE6D4A.3050206@helsinki.fi> <201407102050.s6AKo5K9008755@hobgoblin.ariadne.com> 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [97.94.246.70]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 027578BB13
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(106116001)(20776003)(77982001)(79102001)(106356001)(21056001)(95666004)(92566001)(66066001)(105586002)(80022001)(4396001)(76482001)(33646002)(64706001)(76576001)(46102001)(86362001)(99396002)(99286002)(101416001)(50986999)(110136001)(558084003)(76176999)(107046002)(54356999)(74662001)(74316001)(81342001)(2351001)(107886001)(85306003)(83072002)(93886003)(85852003)(74502001)(81542001)(87936001)(2656002)(31966008)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB306; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/oy0je5QyFjpxqsmbKjmc0XDlaWo
Subject: Re: [urn] URNs, URIs, this working group's job, and some steering
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Jul 2014 22:36:44 -0000

g) convincing people to use urns instead of 'Cool URLS' should not be a goa=
l.
    Yes, it adds a level of indirection, but the extra level doesn't buy mu=
ch
   and it adds another failure point.=20



From nobody Fri Jul 18 01:16:15 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DFC1A016A for ; Fri, 18 Jul 2014 01:16:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level: 
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 7APMDnB55bSM for ; Fri, 18 Jul 2014 01:16:07 -0700 (PDT)
Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69C171A00FA for ; Fri, 18 Jul 2014 01:16:04 -0700 (PDT)
Received: from [128.214.71.180] (lh2-kkl1206.lib.helsinki.fi [128.214.71.180]) (authenticated bits=0) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id s6I8FvP8016423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 18 Jul 2014 11:15:59 +0300
Message-ID: <53C8D7BC.1020505@helsinki.fi>
Date: Fri, 18 Jul 2014 11:15:56 +0300
From: Juha Hakala 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Larry Masinter , "urn@ietf.org" 
References:  <53BE3A55.3020806@gmx.de> <53BE6D4A.3050206@helsinki.fi> <201407102050.s6AKo5K9008755@hobgoblin.ariadne.com> <353845f4429c4a0b87efc500daf47dff@BL2PR02MB307.namprd02.prod.outlook.com>
In-Reply-To: <353845f4429c4a0b87efc500daf47dff@BL2PR02MB307.namprd02.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------020802020401090704010205"
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/-wkBjYnO7sEX4dlfsjxOmDKXMks
Subject: Re: [urn] URNs, URIs, this working group's job, and some steering
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Jul 2014 08:16:11 -0000

This is a multi-part message in MIME format.
--------------020802020401090704010205
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hello Larry; all,

On 18.7.2014 1:36, Larry Masinter wrote:
> g) convincing people to use urns instead of 'Cool URLS' should not be a goal.
>      Yes, it adds a level of indirection, but the extra level doesn't buy much
>     and it adds another failure point.
There are people out there who think that the extra level does buy much.

A quote from a recent discussion on BIBFRAME list where librarians and 
system developers talk about linked data:

> On Jul 17, 2014, at 4:45 PM, "Denenberg, Ray"  wrote:
>
> What would be the benefit of representing an isbn as a urn if it doesn't resolve?
>
> Ray

> Speaking for a moment while wearing my software engineer's hat, some advantages are:
>
> 1) A uniform form for identifiers in managed data. Knowing that the identifiers in our data will appear as URIs allows us to make low-level assumptions about indexing and validation that aren't available over generic strings, leading to tools with better performance at lower cost.
>
> 2) A much shorter road to creating "resolvability" for those identifiers that lack it. Creating, managing, and sharing a resolution mechanism for some particular kind of URN is much more straightforward than creating such a mechanism for generic strings.
>
> ---
> A. Soroka
> The University of Virginia Library
>

Of course, if a URN were actionable, the benefits of expressing an ISBN 
as URNs would be even greater.

There are a lot of people out there who are already convinced that using 
persistent identifiers such as URNs instead of Cool URLs is a good idea 
or even essential. They don't need any more convincing, they want 
modernized URN standards. There are also a lot of people - mainly those 
who don't need to preserve digital content for long term (decades, even 
centuries) - who believe that persistent identifiers are not worth the 
trouble. It is impossible for the one group to convince the other that 
they are wrong. Arguments made are brushed aside as irrelevant.

But as usual in cases like this, time will tell which group is correct.

IETF is caught in a crossfire and has to decide how to perform a 
balancing act between URN-believers and non-believers. Such decision 
will be a political one, since technical issues we are debating will 
remain unresolved for the time being. What about adopting the view that 
there are Cool URLs and URNs out there, and list key arguments these 
camps are using to promote their system so that people reading these 
documents can make up their minds with the help of balanced 
information.  So, instead of just repeating a claim of the cool URL camp 
that the extra level of resolution does not give much added value, the 
URN community could list the actual benefits gained / achievable by 
resolving URNs.

Comments to your position statement:

> I wanted to summarize my position.
>
> a) I don't think any changes to 3986 are actually necessary to
>      allow URNbis to do what is requested, although some
>      changes would be useful.

Indeed. Since the adoption of RFC 3986 IETF has been sitting on two 
chairs, on the one hand saying that URIs have made URNs and URLs 
redundant, but in the same also maintaining a set of URN-related RFCs.
>
> b) splitting URNs from URIs is harmful to many use cases.
Perhaps; some practical examples of this would be nice.

On the other hand, saying that Cool URIs are sufficient and URNs are not 
really necessary is harmful from the URN point of view.
>
> c) what is being suggested (and motivating) -- adding query
>       parameters -- is actively harmful for non-document
>      applications of URNs

I don't see why there would be a problem like this. In practice, when 
URNs are assigned they will never contain either query or fragment. 
Queries will be added by client applications based on the requests of 
the end users who want certain kind of resolution services.

I am not sure of what you mean by non-document application of URNs. But 
even these applications may be able to support some resolution services. 
There is no reason why such services could not be requested by queries.

>
> d) The threat that some other group will redefine URN
>      for their own purposes has already happened, although
>     they were polite enough to call it 'xri' and not 'urn'.


As far as I am concerned, XRI extends URIs and IRIs, not URNs, although 
URNs can be embedded in XRI strings (just like they can be embedded in 
URIs). Had XRIs been mainly about URNs, it is unlikely that the W3C 
Technical Architecture Group would have bothered to recommend OASIS not 
to approve XRI as a standard.
>
> e) The privacy impact of the underlying system architecture --
>     that URNs would be sent to a service which would provide
>      location information for the name -- has terrible
>      privacy implications.
I fail to see why the URNs would have more serious privacy implications 
than e.g. URIs or URLs. On the contrary. The key issue here is not 
technology but management.

URN (and other PID) resolvers are often maintained by the same 
organizations which administer the naming process and are responsible of 
the preservation of documents. From the point of view of privacy and 
security, this kind of managed environment is far better than the 
Internet in general. There are e.g. national libraries out there which 
guarantee that whatever you get when a URN is resolved will be the same 
thing for all practical purposes. Moreover, we take privacy seriously 
and do not share information which must be protected.

As far as I am concerned, cool URLs are less trustworthy than URNs from 
privacy and security points of view since it is impossible to know if a 
URL has been cool or not. Just one example: back in 2006, Henry Thompson 
said in URNs, Namespaces and Registries 
(http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.html) that he 
"...now owns lccn.info and oclcnum.info". He then makes the following point:

> URIs can produce names which are very little different from the 
> equivalent myRI 
>  
> (compare e.g. http://lccn.info/2002022641 to |info:lccn/2002022641|), 
> while gaining all |http:|'s benefits of scalability and installed base.

URIs above turned out not to be cool at all, so I can see "http:'s 
benefits" from persistent identification point of view. Info URI 
initiative was discontinued in 2010, and there is nothing left of 
lccn.info domain. oclcnum.info is still there, but it has nothing to do 
with OCLC numbers any more. Looks like the owner of the domain has 
changed, since page http://www.oclcnum.info/ looks like some kind of 
Chinese marketing effort, which is not what Henry Thompson does.

Question to cool URI supporters: is the URI http://www.oclcnum.info/ 
cool because I still get something? Is it OK that some URIs are 
re-cooled every now and then?

As an aside, the book with the LCCN number shown above can now be found 
from

http://www.worldcat.org/search?qt=worldcat_org_all&q=2002022641

and no, there is no URN namespace for LCCNs.

Can't tell if this URL will still work 8 years from now. As far as I am 
concerned, trusting cool URIs or something I assume is a cool URI can be 
a serious security issue and it may have privacy implications as wello. 
There are already a lot of domains like oclcnum.info which have been 
taken over by companies which use them to lure in people who think the 
content has not changed. Of course, redirecting these web users to where 
they want to go is not at all in the interest of these tricksters.

>
> f) The actual modern needs of 'memory institutions'
>      for identification and as keys in indexing systems
>      goes far beyond those represented here. The
>     'systems' track of the annual IS&T Archiving conference
>      http://www.imaging.org/ist/conferences/archiving/
>      is a good source of reference for the range of
>     identification issues that need solutions for which
>     URNs are inadequate, no matter how tarted up.

Memory institutions are not trying to solve all their identification 
issues with URNs.

As an aside, one of the organizers of IS&T archiving conferences  is 
NESTOR, German competence network for digital preservation. They use 
URNs a lot, and maintain a good summary page with links to various 
persistent identifier systems:

http://www.langzeitarchivierung.de/Subsites/nestor/DE/Standardisierung/PI.html

And the reason why persistent identifiers should be used in summarized 
nicely:

> Persistent Identifier dienen der eindeutigen und dauerhaten 
> Adressierung von digitalen Ressourcen. Im Gegensatz zu herkömmlichen 
> Web-URLs unterscheiden sie zwischen Identifizierung und Adresse einer 
> Ressource. Mit Hilfe eines Resolving-Mechanismus kann so 
> sichergestellt werden, dass auf eine Ressource auch noch zugegriffen 
> werden kann, wenn sich ihr physikalischer Speicherort verändert hat.

Juha
>
>
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn


-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  Library Network Services
  P.O.Box 26 (Teollisuuskatu 23)
  FIN-00014 Helsinki University
  Tel. +358 9 191 44293
  Mobile +358 50 3827678



--------------020802020401090704010205
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Hello Larry; all,

      

      On 18.7.2014 1:36, Larry Masinter wrote:

      

        
g) convincing people to use urns instead of 'Cool URLS' should not be a goal.
    Yes, it adds a level of indirection, but the extra level doesn't buy much
   and it adds another failure point. 

      

      There are people out there who think that the extra level does buy
      much.

      

      A quote from a recent discussion on BIBFRAME list where librarians
      and system developers talk about linked data: 

      

      

        
On Jul 17, 2014, at 4:45 PM, "Denenberg, Ray" <rden@LOC.GOV> wrote:



        
What would be the benefit of representing an isbn as a urn if it doesn't resolve?

Ray

      

      

      

        
Speaking for a moment while wearing my software engineer's hat, some advantages are:

1) A uniform form for identifiers in managed data. Knowing that the identifiers in our data will appear as URIs allows us to make low-level assumptions about indexing and validation that aren't available over generic strings, leading to tools with better performance at lower cost.

2) A much shorter road to creating "resolvability" for those identifiers that lack it. Creating, managing, and sharing a resolution mechanism for some particular kind of URN is much more straightforward than creating such a mechanism for generic strings.

---
A. Soroka
The University of Virginia Library



      

       

      Of course, if a URN were actionable, the benefits of expressing an
      ISBN as URNs would be even greater. 

      

      There are a lot of people out there who are already convinced that
      using persistent identifiers such as URNs instead of Cool URLs is
      a good idea or even essential. They don't need any more
      convincing, they want modernized URN standards. There are also a
      lot of people - mainly those who don't need to preserve digital
      content for long term (decades, even centuries) - who believe that
      persistent identifiers are not worth the trouble. It is impossible
      for the one group to convince the other that they are wrong.
      Arguments made are brushed aside as irrelevant. 

      

      But as usual in cases like this, time will tell which group is
      correct.  

      

      IETF is caught in a crossfire and has to decide how to perform a
      balancing act between URN-believers and non-believers. Such
      decision will be a political one, since technical issues we are
      debating will remain unresolved for the time being. What about
      adopting the view that there are Cool URLs and URNs out there, and
      list key arguments these camps are using to promote their system
      so that people reading these documents can make up their minds
      with the help of balanced information.  So, instead of just
      repeating a claim of the cool URL camp that the extra level of
      resolution does not give much added value, the URN community could
      list the actual benefits gained / achievable by resolving URNs.  

      

    

    Comments to your position statement: 

    

    

      
I wanted to summarize my position.

a) I don't think any changes to 3986 are actually necessary to
    allow URNbis to do what is requested, although some
    changes would be useful.

    

    

    Indeed. Since the adoption of RFC 3986 IETF has been sitting on two
    chairs, on the one hand saying that URIs have made URNs and URLs
    redundant, but in the same also maintaining a set of URN-related
    RFCs. 

    

      

b) splitting URNs from URIs is harmful to many use cases.

    

    Perhaps; some practical examples of this would be nice. 

    

    On the other hand, saying that Cool URIs are sufficient and URNs are
    not really necessary is harmful from the URN point of view. 

    

      

c) what is being suggested (and motivating) -- adding query 
     parameters -- is actively harmful for non-document
    applications of URNs

    

    

    I don't see why there would be a problem like this. In practice,
    when URNs are assigned they will never contain either query or
    fragment. Queries will be added by client applications based on the
    requests of the end users who want certain kind of resolution
    services. 

    

    I am not sure of what you mean by non-document application of URNs.
    But even these applications may be able to support some resolution
    services. There is no reason why such services could not be
    requested by queries.   

      

    

      

d) The threat that some other group will redefine URN
    for their own purposes has already happened, although
   they were polite enough to call it 'xri' and not 'urn'.

    

    

    

    As far as I am concerned, XRI extends URIs and IRIs, not URNs,
    although URNs can be embedded in XRI strings (just like they can be
    embedded in URIs). Had XRIs been mainly about URNs, it is unlikely
    that the W3C Technical Architecture Group would have bothered to
    recommend OASIS not to approve XRI as a standard. 

     
    

      

e) The privacy impact of the underlying system architecture --
   that URNs would be sent to a service which would provide
    location information for the name -- has terrible 
    privacy implications. 

    

    I fail to see why the URNs would have more serious privacy
    implications than e.g. URIs or URLs. On the contrary. The key issue
    here is not technology but management. 

    

    URN (and other PID) resolvers are often maintained by the same
    organizations which administer the naming process and are
    responsible of the preservation of documents. From the point of 
    view of privacy and security, this kind of managed environment is
    far better than the Internet in general. There are e.g. national
    libraries out there which guarantee that whatever you get when a URN
    is resolved will be the same thing for all practical purposes.
    Moreover, we take privacy seriously and do not share information
    which must be protected. 

    

    As far as I am concerned, cool URLs are less trustworthy than URNs
    from privacy and security points of view since it is impossible to
    know if a URL has been cool or not. Just one example: back in 2006,
    Henry Thompson said in URNs, Namespaces and Registries
    (http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.html) that he
    "...now owns lccn.info and oclcnum.info". He then makes the
    following point:

    

    
URIs can produce names which are very little
      different from
      the equivalent myRI
      (compare e.g. http://lccn.info/2002022641
      to
      info:lccn/2002022641), while gaining all http:'s
      benefits of
      scalability and installed base.

    

    URIs above turned out not to be cool at all, so I can see "http:'s
    benefits" from persistent identification point of view. Info URI
    initiative was discontinued in 2010, and there is nothing left of
    lccn.info domain. oclcnum.info is still there, but it has nothing to
    do with OCLC numbers any more. Looks like the owner of the domain
    has changed, since page http://www.oclcnum.info/ looks like some
    kind of Chinese marketing effort, which is not what Henry Thompson
    does. 

    

    Question to cool URI supporters: is the URI http://www.oclcnum.info/
    cool because I still get something? Is it OK that some URIs are
    re-cooled every now and then?

    

    As an aside, the book with the LCCN number shown above can now be
    found from 

    

    http://www.worldcat.org/search?qt=worldcat_org_all&q=2002022641

    

    and no, there is no URN namespace for LCCNs. 

    

    Can't tell if this URL will still work 8 years from now. As far as I
    am concerned, trusting cool URIs or something I assume is a cool URI
    can be a serious security issue and it may have privacy implications
    as wello. There are already a lot of domains like oclcnum.info which
    have been taken over by companies which use them to lure in people
    who think the content has not changed. Of course, redirecting these
    web users to where they want to go is not at all in the interest of
    these tricksters.          

     

    

      

f) The actual modern needs of 'memory institutions' 
    for identification and as keys in indexing systems
    goes far beyond those represented here. The 
   'systems' track of the annual IS&T Archiving conference
    http://www.imaging.org/ist/conferences/archiving/
    is a good source of reference for the range of 
   identification issues that need solutions for which
   URNs are inadequate, no matter how tarted up.

    

    

    Memory institutions are not trying to solve all their identification
    issues with URNs. 

    

    As an aside, one of the organizers of IS&T archiving
    conferences  is NESTOR, German competence network for digital
    preservation. They use URNs a lot, and maintain a good summary page
    with links to various persistent identifier systems: 

    

http://www.langzeitarchivierung.de/Subsites/nestor/DE/Standardisierung/PI.html

    

    And the reason why persistent identifiers should be used in
    summarized nicely: 

    

    
Persistent Identifier dienen der eindeutigen
      und dauerhaten Adressierung von digitalen Ressourcen. Im Gegensatz
      zu herkömmlichen Web-URLs unterscheiden sie zwischen
      Identifizierung und Adresse einer Ressource. Mit Hilfe eines
      Resolving-Mechanismus kann so sichergestellt werden, dass auf eine
      Ressource auch noch zugegriffen werden kann, wenn sich ihr
      physikalischer Speicherort verändert hat.

    

    Juha

    

      


_______________________________________________
urn mailing list
urn@ietf.org
https://www.ietf.org/mailman/listinfo/urn


    

    

    

    
-- 

 Juha Hakala
 Senior advisor

 The National Library of Finland
 Library Network Services 
 P.O.Box 26 (Teollisuuskatu 23)
 FIN-00014 Helsinki University
 Tel. +358 9 191 44293
 Mobile +358 50 3827678 




  


--------------020802020401090704010205--


From nobody Fri Jul 18 02:15:35 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D951B2952 for ; Fri, 18 Jul 2014 02:15:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
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 g_ipiyQYiotv for ; Fri, 18 Jul 2014 02:15:30 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2A21B294F for ; Fri, 18 Jul 2014 02:15:30 -0700 (PDT)
Received: from [192.168.1.106] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LcBin-1WirmM17R7-00jdsR; Fri, 18 Jul 2014 11:15:27 +0200
Message-ID: <53C8E5A8.5020802@gmx.de>
Date: Fri, 18 Jul 2014 11:15:20 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Juha Hakala ,  Larry Masinter , "urn@ietf.org" 
References:  <53BE3A55.3020806@gmx.de> <53BE6D4A.3050206@helsinki.fi> <201407102050.s6AKo5K9008755@hobgoblin.ariadne.com> <353845f4429c4a0b87efc500daf47dff@BL2PR02MB307.namprd02.prod.outlook.com> <53C8D7BC.1020505@helsinki.fi>
In-Reply-To: <53C8D7BC.1020505@helsinki.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:EATp2sJIk7a/29u68e5sXNfl49ETZowoschdWv3CnZ8ynnWL8S9 EBsdKa643LqPmvWVfGl9TwvLFetc/CI5GRPSHdXKY1XJb6fakUVMZIQapxMl4JWlRxDdxi9 EDZSGrkwweOEJAPYqq6okAnh745XuaoLlXR05GuOgJgtYmDt4V+sq+IH59vXXSF8q4o0KfV FJrymVJYuq4A6RucvOviA==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/WF9ciR998D6al46q_lpSj1Ke6Yc
Subject: Re: [urn] URNs, URIs, this working group's job, and some steering
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Jul 2014 09:15:32 -0000

Hi Juha,

a few quick comments inline:

On 2014-07-18 10:15, Juha Hakala wrote:
> ...
> There are people out there who think that the extra level does buy much.
>
> A quote from a recent discussion on BIBFRAME list where librarians and
> system developers talk about linked data:
>
>> On Jul 17, 2014, at 4:45 PM, "Denenberg, Ray"  wrote:
>>
>> What would be the benefit of representing an isbn as a urn if it doesn't resolve?
>>
>> Ray
>
>> Speaking for a moment while wearing my software engineer's hat, some advantages are:
>>
>> 1) A uniform form for identifiers in managed data. Knowing that the identifiers in our data will appear as URIs allows us to make low-level assumptions about indexing and validation that aren't available over generic strings, leading to tools with better performance at lower cost.
>>
>> 2) A much shorter road to creating "resolvability" for those identifiers that lack it. Creating, managing, and sharing a resolution mechanism for some particular kind of URN is much more straightforward than creating such a mechanism for generic strings.
>>
>> ---
>> A. Soroka
>> The University of Virginia Library

That's an argument for using URNs instead of plain strings (say ISBNs), 
not an argument of URNs in favor of "cool URIs". Actually, a "cool URI" 
has the same properties with respect to the two points.

> ...
> IETF is caught in a crossfire and has to decide how to perform a
> balancing act between URN-believers and non-believers. Such decision
> will be a political one, since technical issues we are debating will
> remain unresolved for the time being. What about adopting the view that
> there are Cool URLs and URNs out there, and list key arguments these
> camps are using to promote their system so that people reading these
> documents can make up their minds with the help of balanced
> information.  So, instead of just repeating a claim of the cool URL camp
> that the extra level of resolution does not give much added value, the
> URN community could list the actual benefits gained / achievable by
> resolving URNs.
> ...

That would be indeed useful.

> Comments to your position statement:
>
>> I wanted to summarize my position.
>>
>> a) I don't think any changes to 3986 are actually necessary to
>>      allow URNbis to do what is requested, although some
>>      changes would be useful.
>
> Indeed. Since the adoption of RFC 3986 IETF has been sitting on two
> chairs, on the one hand saying that URIs have made URNs and URLs
> redundant, but in the same also maintaining a set of URN-related RFCs.

RFC 3986 doesn't say that.

>> b) splitting URNs from URIs is harmful to many use cases.
> Perhaps; some practical examples of this would be nice.

You lose the ability to use URNs in places where URIs are expected.

> On the other hand, saying that Cool URIs are sufficient and URNs are not
> really necessary is harmful from the URN point of view.

Is any specification saying that?

> ...
> As an aside, one of the organizers of IS&T archiving conferences  is
> NESTOR, German competence network for digital preservation. They use
> URNs a lot, and maintain a good summary page with links to various
> persistent identifier systems:
>
> http://www.langzeitarchivierung.de/Subsites/nestor/DE/Standardisierung/PI.html
>
> And the reason why persistent identifiers should be used in summarized
> nicely:
>
>> Persistent Identifier dienen der eindeutigen und dauerhaten
>> Adressierung von digitalen Ressourcen. Im Gegensatz zu herkömmlichen
>> Web-URLs unterscheiden sie zwischen Identifizierung und Adresse einer
>> Ressource. Mit Hilfe eines Resolving-Mechanismus kann so
>> sichergestellt werden, dass auf eine Ressource auch noch zugegriffen
>> werden kann, wenn sich ihr physikalischer Speicherort verändert hat.
> ...

That's misleading in that URNs do not "distinguish" between name and 
resolution, but simply do not *address* resolution.

Anyway.

The point of this thread isn't whether URNs are better than cool URIs, 
nor how resolution services ought to work. It's about whether there is 
any reason to accept John's proposal to "split URNs from URIs". Can we 
please focus on that?

Best regards, Julian



From nobody Fri Jul 18 11:22:17 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0CC1A0091 for ; Fri, 18 Jul 2014 11:22:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.477
X-Spam-Level: 
X-Spam-Status: No, score=0.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
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 PXJ9l1lvKZrS for ; Fri, 18 Jul 2014 11:22:15 -0700 (PDT)
Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB1121A0092 for ; Fri, 18 Jul 2014 11:22:14 -0700 (PDT)
Received: by mail-pa0-f53.google.com with SMTP id kq14so5909252pab.12 for ; Fri, 18 Jul 2014 11:22:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=64qHVfbWVcUpqhCW3C2BDDJdFennHWJ6HbBED1yD6pU=; b=Bk8OcBOLgXejD2qvB/owzGoeiVu11DCxhlxGpCOjF04WBheqDiQfyWvwX8yfbab9tH yNVMLcHefQWH5DUwdO4Lb6g7wrShS3qYeIXTumVYIrqWHsqWFW/Dz98eZIb4WGODVfyp RxNhuz9hkq7rjCKRm0+6YBs8jTb1WOvO63bcrilGC0mSaUTgEVYLXWbuYJ5gT+TLd+57 sGJ8vnA25E2x3r7niEaCP7LMLg/FE2driVnGLTWCblNp6YfW6gwdu6GKbjQ6CpGPTpv0 JZYq1WllPpclLIu4kse68TtPtkiLL8jMICHQ9llHoXxUAWc7pf6o4kLmjwDc7iRKzzEe XmMg==
X-Gm-Message-State: ALoCoQnzMtn2fMfAQh4pFT4HBxmgFNpMY/SJGVeNSqQgbMmiyljcArl4GbPcDeJ8MGafsu1WxGHQ
MIME-Version: 1.0
X-Received: by 10.68.139.36 with SMTP id qv4mr7538867pbb.82.1405707734605; Fri, 18 Jul 2014 11:22:14 -0700 (PDT)
Received: by 10.66.27.5 with HTTP; Fri, 18 Jul 2014 11:22:14 -0700 (PDT)
X-Originating-IP: [192.149.252.11]
In-Reply-To: <9c6dc1f783a1459f824cde09f33daa38@BL2PR02MB307.namprd02.prod.outlook.com>
References:  <53BE3A55.3020806@gmx.de> <53BE6D4A.3050206@helsinki.fi> <201407102050.s6AKo5K9008755@hobgoblin.ariadne.com> <9c6dc1f783a1459f824cde09f33daa38@BL2PR02MB307.namprd02.prod.outlook.com>
Date: Fri, 18 Jul 2014 14:22:14 -0400
Message-ID: 
From: Andrew Newton 
To: Larry Masinter 
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/OfvcE1p62PcXSgBkIQHfsoScDVQ
Cc: "urn@ietf.org" 
Subject: Re: [urn] URNs, URIs, this working group's job, and some steering
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Jul 2014 18:22:16 -0000

On Thu, Jul 17, 2014 at 6:28 PM, Larry Masinter  wrote:
>
> c) what is being suggested (and motivating) -- adding query
>      parameters -- is actively harmful for non-document
>     applications of URNs

Larry,

Can you elaborate on this? Can you provide a specific example?

-andy


From nobody Sat Jul 19 18:05:08 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70ED71B2B4A for ; Sat, 19 Jul 2014 18:05:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 ZOLwlneRm1Pf for ; Sat, 19 Jul 2014 18:05:03 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0144.outbound.protection.outlook.com [207.46.163.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E031B2B49 for ; Sat, 19 Jul 2014 18:05:02 -0700 (PDT)
Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB306.namprd02.prod.outlook.com (10.141.91.19) with Microsoft SMTP Server (TLS) id 15.0.990.7; Sun, 20 Jul 2014 01:05:00 +0000
Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0990.007; Sun, 20 Jul 2014 01:05:00 +0000
From: Larry Masinter 
To: "urn@ietf.org" 
Thread-Topic: harm of adding query parameters in general
Thread-Index: Ac+jtiSl9YhNVjoVQsqK2OkC225m4Q==
Date: Sun, 20 Jul 2014 01:04:58 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [50.184.24.49]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 02788FF38E
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(24454002)(110136001)(86362001)(77982001)(101416001)(66066001)(106356001)(79102001)(20776003)(21056001)(46102001)(64706001)(4396001)(76482001)(229853001)(19580395003)(83322001)(50986999)(33646002)(99286002)(15202345003)(76576001)(107046002)(99396002)(74662001)(54356999)(74316001)(2351001)(81342001)(107886001)(85306003)(83072002)(85852003)(15975445006)(74502001)(92566001)(95666004)(105586002)(80022001)(87936001)(2656002)(31966008)(81542001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB306; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/MiL_w7hzFhXbuyOwEUcza-rqf_A
Subject: [urn] harm of adding query parameters in general
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Jul 2014 01:05:05 -0000

I wrote:
> c) what is being suggested (and motivating) -- adding query
>      parameters -- is actively harmful for non-document
>     applications of URNs

And Andy asked:
> Can you elaborate on this? Can you provide a specific example?

The arguments are similar to those made in BCP 190, RFC 7320, URI Design an=
d Ownership. Here are two examples:

1. Michael Mealing wrote, in=20
http://www.ietf.org/mail-archive/web/urn/current/msg02363.html
> BUT, in RFC 2141 there IS a statement that if I see
> urn:isbn:whatever
> that I can safely and correctly rely on that identifier being forever
> bound to the resource (whether that resource is physical, electronic,=20
> or metaphysical). If something violates that assumption then I can=20
> know that SOMEONE ELSE has made an error.=20

> By using 'urn:' over 'http:' you are making an explicit statement
>  about your intent as verified by the URN registration mechanism.

But when you add query parameters, the URN with query parameters is no long=
er managed, but is a reference to some initial state in a resolution method=
 that is defined outside of the URN space itself.  (One might argue that th=
is benefits of URNs isn't as strong as claimed, but it's at the core of wha=
t distinguishes URNs from 'Cool URLs')

2. In the mail thread containing http://www.ietf.org/mail-archive/web/urn/c=
urrent/msg02282.html
Peter Saint-Andre noted the use of urn:ietf:rfc:3264 to identify the featur=
e defined in RFC 3264 rather than the document itself.  However, http://too=
ls.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn claims:

>  If a query component, fragment identifier component, or both have
>   been appended to the assigned URN, they MUST be ignored for purposes
 >  of determining equivalence.

For the application Peter described, rfc2141bis demands that the query comp=
onent be ignored for the purpose of determining equivalence.  If taken lite=
rally, this would break all implementations that merely do a string compari=
son.

Both of these problems arise because URNBIS Is attempting to redefine somet=
hing that was previously defined to have a syntax and semantics, and there =
are deployed applications that rely on those semantics, while the new appli=
cations imagined that might use the changed syntax and semantics are not de=
ployed and have little or no implementation experience.  If URNBIS defined =
a new URI scheme "urnq" whose definition was "Exactly like urn: except that=
 query and fragment components are allowed" then at least existing applicat=
ions which make assumptions about URIs that start with "urn:" wouldn't have=
 those assumptions broken.

Larry
--=20
http://larry.masinter.net




From nobody Sat Jul 19 20:45:23 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34DF1B2B48 for ; Sat, 19 Jul 2014 20:45:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.146
X-Spam-Level: 
X-Spam-Status: No, score=-0.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=no
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 YMpurkWu53NS for ; Sat, 19 Jul 2014 20:45:00 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9A11B2841 for ; Sat, 19 Jul 2014 20:45:00 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1X8hzS-000Pxd-I1; Sat, 19 Jul 2014 23:40:46 -0400
Date: Sat, 19 Jul 2014 23:44:51 -0400
From: John C Klensin 
To: Larry Masinter , urn@ietf.org
Message-ID: 
In-Reply-To: 
References: 
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.115
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/gq82nF6WVEl4VJS8UV5PXrmqIZY
Subject: Re: [urn] harm of adding query parameters in general
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Jul 2014 03:45:03 -0000

--On Sunday, July 20, 2014 01:04 +0000 Larry Masinter
 wrote:

> I wrote:
>> c) what is being suggested (and motivating) -- adding query
>>      parameters -- is actively harmful for non-document
>>     applications of URNs
> 
> And Andy asked:
>> Can you elaborate on this? Can you provide a specific example?
> 
> The arguments are similar to those made in BCP 190, RFC 7320,
> URI Design and Ownership. Here are two examples:
>...
> But when you add query parameters, the URN with query
> parameters is no longer managed, but is a reference to some
> initial state in a resolution method that is defined outside
> of the URN space itself.  (One might argue that this benefits
> of URNs isn't as strong as claimed, but it's at the core of
> what distinguishes URNs from 'Cool URLs')

Larry,

Most of the discussions about this would add provision for some
parameters or parameter-like things (you can read "query
parameters" into that, but I'm trying to be very general right
now) to the syntax.   2141 didn't ban that, it just reserved
them for future extensions.  At least according to WG
discussions that have been going on more years than I care to
think about, the actual use of the things would then be a
per-NID matter.  If one used them with an existing, unmodified,
and otherwise conforming NID, what would happen to them would be
whatever happens today -- presumably they would be rejected by
careful implementations and ignored by others.  

For NIDs whose registrations explicitly allowed them, they would
be allowed.

If someone proposed to change a given existing NID to allow
them, that decision would need to be made one NID at a time and
would presumably have to analyze and deal with any compatibility
tradeoffs.   When, for example, ISO TC 46 members and the ISBN
Registration Agency tell us they don't see a problem with
allowing queries to be associated with ISBNs and you tell us it
would cause grave harm to that particular URN NID because of
some generic issues, my personal opinion is that they carry
slightly more weight.  You presumably disagree.

It seems to me that what you are arguing is that, if they are
allowed anywhere, then they would be allowed, with the same
semantics, for all URNs.  Not only do I not see anything in 2141
that requires that, I don't think it is a requirement even for
http-URLs.  If it were a requirement for all URIs in 3986, then
existing SIP and other heavily-used URIs would be
non-conforming.  For URNs, if that were true, it would just
strengthen the argument for separation of URNs from all or part
of the 3986 URI definition.

If that is not your position, I still don't understand it.

URNs don't all have the same semantics today.  If they did, we
couldn't have some that act purely as indicators (e.g., the XMPP
case) and others that rely on a variety of resolution methods,
some defined in an IETF context such as DDDS and some not.
 
> 2. In the mail thread containing
> http://www.ietf.org/mail-archive/web/urn/current/msg02282.html
> Peter Saint-Andre noted the use of urn:ietf:rfc:3264 to
> identify the feature defined in RFC 3264 rather than the
> document itself.  However,
> http://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn
> claims:
> 
>>  If a query component, fragment identifier component, or both
>>  have been appended to the assigned URN, they MUST be ignored
>>   for purposes
>  >  of determining equivalence.
 
> For the application Peter described, rfc2141bis demands that
> the query component be ignored for the purpose of determining
> equivalence.  If taken literally, this would break all
> implementations that merely do a string comparison.

If 2141bis, which, IMO, has somewhat lagged some of the thinking
in the WG, says the wrong things, it should (and presumably
will) be updated.

This is an area where I, and I presume other WG participants,
would welcome your constructive suggestions.

> Both of these problems arise because URNBIS Is attempting to
> redefine something that was previously defined to have a
> syntax and semantics, and there are deployed applications that
> rely on those semantics, while the new applications imagined
> that might use the changed syntax and semantics are not
> deployed and have little or no implementation experience.  If
> URNBIS defined a new URI scheme "urnq" whose definition was
> "Exactly like urn: except that query and fragment components
> are allowed" then at least existing applications which make
> assumptions about URIs that start with "urn:" wouldn't have
> those assumptions broken.

Like Andy (at least prior to this note of yours), I'm confused
about why you see an issue with some NIDs being registered as
allowing the use of some syntax that other NIDs don't allow.  I
don't see that as being any different from some http-URLs
utilizing queries where others don't (and, in practice, either
ignore them or emit unpleasant messages).  I believe that
http-URL case should be a much more restrictive one than for
URNs.  Your case that it creates an incompatibility would be
stronger if 2141 prohibited the use of queries, fragments, etc.,
forever, but it doesn't.  As I read it, it explicitly reserves
them for future extension.  And not only can 3986 not somehow
implicitly change that to make a permanent restriction (it
certainly doesn't say "updates 2141" anywhere), but arguments
that it, or for that matter 7320, constrain what the WG can do
merely strengthen the argument for the separation of URNs from
generic URIs.

That is part of the problem the WG faces.  If there is really a
requirement and 3986 is interpreted as "you can't do that", then
there is an incentive to either find ways to get around 3986
while meeting the requirement (while I don't particularly like
the results, Dale Worley has been, IMO, quite creative about
that) or to separate the two (which some members of the
community believe should have been done as a condition of
approval of 3986).  More on this below, but my own position at
this stage is "whatever is needed to make progress on something
that will serve the URN communities (not plural) well for the
long term".  Just my opinion, even though, for reasons discussed
below, I don't see "just say 'no'" as an option.

I also suggest that, carried to their logical extreme, the
position I understand you to be taking would make both HTTPbis
and the WHATWG-W3C effort to redefine URLs impossible.
Certainly any effort to fold non-ASCII characters into URLs
violates the syntax and semantic constraints of 3986 to a degree
that not even "httpi" would fix and, at least to my knowledge,
no one has proposed than the method name be changed.

As far as "urnq" is concerned, I think there are two important
reasons why that isn't a good solution, with the second much
more important than the first.

(1) As discussed above, I don't think that it is necessary.  It
would certainly be disruptive to a lot of existing uses and
users.  At least so far, I don't believe the WG is convinced
that there is a problem serious enough to justify a new method
identifier.

(2) The community out there that believes (in good faith and on
the basis of what they believe is many centuries of experience
with the kinds of identifiers and identifier-qualifiers that
they are asking for) that they need some additional qualifying
syntax associated with URNs to identify or request specific
metadata or portions of named information is (contrary to what
might be read into your "no experience" assertion) large and
organized.  They have URNs of various sorts widely deployed,
with millions of assigned identifiers (NID+NSS) in use.  They
have been developing and using extensions that go beyond 2141
out of what they see as necessity and on the their own but have
been waiting patiently for the IETF to draw things back together
and standardize a set of clarifications and extensions to the
standard that meets their needs.    Now, the IETF could
certainly say "sorry, but you don't get to call those URNs, call
them URNQs or something else".  I believe, based on informal
discussions within their well-established standard bodies, that
their reaction would be a more polite version of "you can't tell
us what we can't do", followed by standards development in those
bodies that would use the term and method "urn" and would build
compatibly (by their definition) on the principles of 2141 but
would ignore 3986 and anything else that got in the way of their
meeting their needs.  Because it is not their area of expertise,
some of the changes they might make might be accidentally
hostile to some non-document or non-resolvable uses of URNs.  

If that community were a hastily-organized ad hoc Consortium for
a New URN, it would probably be safe to ignore them.  It isn't
-- again, some of their institutions are many hundreds of years
old and some of them even have the ability to turn Voluntary
Standards into Regulations or legal Requirements.    Encouraging
(or forcing) them to go off in their own direction would
essentially lead us to a forked standard -- two different, and
inconsistent, URN specifications.   If they do develop their
own, forked, standard, very few of us will have a seat at the
table (although the larger customers of some of the companies
who pay people to do this work in the IETF might).   I think
that is pretty close to worst case.  I therefore think we should
be working on finding creative ways to keep the various
communities together and focused on a single standard rather
than explaining why that cannot be done.  I'm willing to do
things I actually find quite uncomfortable --such as proposing a
URN-URI separation mechanism-- in order to meet the goal of
retaining a single URN standard with a single SDO responsible
for change control.   YMMD, of course.

      john

p.s. In case it isn't clear from the above or other things, I'm
not a fan of draft-ietf-urnbis-urns-are-not-uris.  I wrote it
for the convenience of the WG because several of us concluded it
is was necessary expedient.   I'd be the first to welcome a
better solution, again with the understanding that I don't
believe "just say 'no'" is a plausible part of the solution
space.  I guess I get to say that again next Friday.


From nobody Sun Jul 20 00:40:43 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DB61B2B7A for ; Sun, 20 Jul 2014 00:40:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 wDk0QJNUk6vj for ; Sun, 20 Jul 2014 00:40:39 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A66BB1B2B78 for ; Sun, 20 Jul 2014 00:40:38 -0700 (PDT)
Received: from [192.168.43.245] ([82.113.106.88]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MRocn-1WxOuy1Tb7-00St9o; Sun, 20 Jul 2014 09:40:23 +0200
Message-ID: <53CB6C78.60406@gmx.de>
Date: Sun, 20 Jul 2014 09:15:04 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: John C Klensin , Larry Masinter , urn@ietf.org
References:  
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:G8+BumKcFE5swXRyMxMtwAUONTVVP7nldhpsObc6b3iWR6Qf4vb hLV2WgGz3KCvpP1cGwkwCarQDRcKCB/JDER3ZXUTWEhLdSYEb1nyBYmxcIvwWv29ZXyIxAI i/jQ9Wbd4DLm/XKNyqCcRgkFNB0sQuYrZDymlkzjCzbfhlc4HoL/35dj28EAQ4m8/Gl0svr ko3xfD82qF+aYo9b6l2Cg==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/v6NZaGL8oi8SdxK14tFI6r-rHL8
Subject: [urn] httpbis WG and URIs, was:  harm of adding query parameters in general
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Jul 2014 07:40:40 -0000

On 2014-07-20 05:44, John C Klensin wrote:
> ...
> I also suggest that, carried to their logical extreme, the
> position I understand you to be taking would make both HTTPbis
> and the WHATWG-W3C effort to redefine URLs impossible.
 > ...

I'm not aware of any HTTPbis effort to redefine anything in this area.

Best regards, Julian


From nobody Sun Jul 20 00:51:15 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF761B2B7F for ; Sun, 20 Jul 2014 00:51:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 6EcFzyvJ3gAq for ; Sun, 20 Jul 2014 00:51:07 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 318F21B2B7E for ; Sun, 20 Jul 2014 00:51:07 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1X8lpb-0000S3-HW; Sun, 20 Jul 2014 03:46:51 -0400
Date: Sun, 20 Jul 2014 03:50:57 -0400
From: John C Klensin 
To: Julian Reschke , Larry Masinter , urn@ietf.org
Message-ID: <06972CE1A98D0C388AE84EE1@JcK-HP8200.jck.com>
In-Reply-To: <53CB6C78.60406@gmx.de>
References:   <53CB6C78.60406@gmx.de>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.115
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/jXl7UZb2lq2aCS3emdGlp6y1dq8
Subject: Re: [urn] httpbis WG and URIs, was:  harm of adding query parameters in general
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Jul 2014 07:51:09 -0000

--On Sunday, July 20, 2014 09:15 +0200 Julian Reschke
 wrote:

> On 2014-07-20 05:44, John C Klensin wrote:
>> ...
>> I also suggest that, carried to their logical extreme, the
>> position I understand you to be taking would make both HTTPbis
>> and the WHATWG-W3C effort to redefine URLs impossible.
>  > ...
> 
> I'm not aware of any HTTPbis effort to redefine anything in
> this area.

That part was a prediction that, if URLs are redefined for HTML
purposes, it would not be long before various systems started to
pass those URLs to HTTP and expected HTTP to handle them.  I may
be wrong, of course, but that is how the trends seem to be going.

    john





From nobody Sun Jul 20 00:57:31 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0A51B2B7E for ; Sun, 20 Jul 2014 00:57:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 3DN-ttgTRGVo for ; Sun, 20 Jul 2014 00:57:29 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5821B2B7F for ; Sun, 20 Jul 2014 00:57:29 -0700 (PDT)
Received: from [192.168.43.245] ([82.113.106.88]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Me5Q2-1Wtq9I06kY-00PvO5; Sun, 20 Jul 2014 09:57:26 +0200
Message-ID: <53CB765C.1090609@gmx.de>
Date: Sun, 20 Jul 2014 09:57:16 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: John C Klensin , Larry Masinter , urn@ietf.org
References:   <53CB6C78.60406@gmx.de> <06972CE1A98D0C388AE84EE1@JcK-HP8200.jck.com>
In-Reply-To: <06972CE1A98D0C388AE84EE1@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:15u6kNUexM6y1vKo7LqF8ekwBtCpWpNxFV2ZNU7EZbYRryKMP5r g0PuDM67kjvd0PifEmlsotf7IGAxvapVrCCVOtEk1ni+Vtd9ora6VQngFTGQ0Lx5Hn3uIuU RGlHFVfADAQMrD1zKsW9+0YXcgbqDlSOsELcRJ75gbJSF+TjjY3le7k1tS1tCGyMHKLCtDO yaXG0S0SVvXgxyEHqRN7Q==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/DA3Dxz6jDz1wGIv86Gyu86Vnl7c
Subject: Re: [urn] httpbis WG and URIs, was:  harm of adding query parameters in general
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Jul 2014 07:57:30 -0000

On 2014-07-20 09:50, John C Klensin wrote:
>
>
> --On Sunday, July 20, 2014 09:15 +0200 Julian Reschke
>  wrote:
>
>> On 2014-07-20 05:44, John C Klensin wrote:
>>> ...
>>> I also suggest that, carried to their logical extreme, the
>>> position I understand you to be taking would make both HTTPbis
>>> and the WHATWG-W3C effort to redefine URLs impossible.
>>   > ...
>>
>> I'm not aware of any HTTPbis effort to redefine anything in
>> this area.
>
> That part was a prediction that, if URLs are redefined for HTML
> purposes, it would not be long before various systems started to
> pass those URLs to HTTP and expected HTTP to handle them.  I may
> be wrong, of course, but that is how the trends seem to be going.

It is already that the "things that appear in HTML anchor elements that 
are not valid URIs" leak into HTTP. Not necessarily the request line, 
but for instance the Location header field.

Best regards, Julian


From nobody Sun Jul 20 09:29:42 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1281B285E for ; Sun, 20 Jul 2014 09:29:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 56DZYvLkia7f for ; Sun, 20 Jul 2014 09:29:39 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 658091B2859 for ; Sun, 20 Jul 2014 09:29:39 -0700 (PDT)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1X8tvP-00014Z-VY; Sun, 20 Jul 2014 12:25:24 -0400
Date: Sun, 20 Jul 2014 12:29:35 -0400
From: John C Klensin 
To: Julian Reschke , Larry Masinter , urn@ietf.org
Message-ID: <22E44E31F38FFB76616BC35E@JCK-EEE10>
In-Reply-To: <53CB765C.1090609@gmx.de>
References:   <53CB6C78.60406@gmx.de> <06972CE1A98D0C388AE84EE1@JcK-HP8200.jck.com> <53CB765C.1090609@gmx.de>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/lhXsjCVajQMB5HizhORR4f8tzvc
Subject: Re: [urn] httpbis WG and URIs, was:  harm of adding query parameters in general
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Jul 2014 16:29:40 -0000

--On Sunday, 20 July, 2014 09:57 +0200 Julian Reschke
 wrote:

>> That part was a prediction that, if URLs are redefined for
>> HTML purposes, it would not be long before various systems
>> started to pass those URLs to HTTP and expected HTTP to
>> handle them.  I may be wrong, of course, but that is how the
>> trends seem to be going.
> 
> It is already that the "things that appear in HTML anchor
> elements that are not valid URIs" leak into HTTP. Not
> necessarily the request line, but for instance the Location
> header field.

And knowledge of that general sort was part of the reason for
the prediction.   While it seems unlikely to me, it is possible
that all HTML implementations will be hyper-scrupulous about
non-ASCII characters and other extensions beyond 3986, so it
remains just a prediction that could be wrong.  

On the other hand, there have been statements from the direction
of WHATWG and various W3C efforts about intent to obsolete 3986
and 3987 (just as there have been statements about intent to
obsolete the IANA Charset registry) so I think the intent of the
people involved is clear.  I would not go so far as to assume
institutional intent although that seems plausible, especially
in the case of WHATWG.


    john



From nobody Mon Jul 21 02:55:50 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355841B2B60 for ; Mon, 21 Jul 2014 02:55:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.107
X-Spam-Level: **
X-Spam-Status: No, score=2.107 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=no
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 qGdK6t0AVar0 for ; Mon, 21 Jul 2014 02:55:47 -0700 (PDT)
Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id BFECA1B2C9D for ; Mon, 21 Jul 2014 02:55:41 -0700 (PDT)
Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id BC30332E4F5 for ; Mon, 21 Jul 2014 18:55:39 +0900 (JST)
Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 12b8_df08_f69ba84e_4fd6_4162_a8f6_8758562908a3; Mon, 21 Jul 2014 18:55:38 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id DD86CBFC2A for ; Mon, 21 Jul 2014 18:55:38 +0900 (JST)
Message-ID: <53CCE38B.7070609@it.aoyama.ac.jp>
Date: Mon, 21 Jul 2014 18:55:23 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "urn@ietf.org" 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/iOKjBInsiKXmD1CK6xAIrCXnoN4
Subject: [urn] Query choices
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Jul 2014 09:55:49 -0000

I tried to answer some of the previous mails, but concluded that the 
following may be easier and faster.

I'm trying to list some of the choices that are possible for the 
upcoming URN spec with respect to query. The ones below are the main 
ones I have found.

A) (continue to) not allow query

B) (continue to) not allow query but provide (a) separate scheme(s) for 
using URNs with queries

C) allow each Namespace to opt in to use queries, and define how they 
are used (syntax details, semantics, within some common boundaries)

D) define a common use for query parts for URNs; allow each Namespace to 
opt in to this common use

E) define a common use for query parts for URNs; do not require opt-in 
so that this use is possible with any Namespace when desired/appropriate


My understanding from fairly recent email is that John is somewhere 
around C), Yuha probably close to E), and Larry around B). Of course I 
might have read something wrongly; in that case I apologize in advance.


My personal preference coincides with Larry (B), but probably isn't as 
sharp as his. I'd be okay with C) if that's what the WG decides to do 
(after all, it's mostly the people who define and use certain Namespaces 
who have to live with the queries on them), and could live with D) or E) 
if that makes the WG and the IETF happy because I'm not using URNs.


I'd also like to note that none of the above alternatives would need a 
separation of URNs from RFC 3986. RFC 3986 delegates the question of 
whether and what queries are allowed to each scheme, in our case urn:.
Also, there is nothing in RFC 3986 (or in RFC 4395, which is relevant 
for registration) that says that the syntax of a scheme cannot be changed.


Regards,   Martin.


From nobody Mon Jul 21 06:49:25 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198CE1A0081 for ; Mon, 21 Jul 2014 06:49:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
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 s96yKaM7v8bo for ; Mon, 21 Jul 2014 06:49:18 -0700 (PDT)
Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFB0A1B2BFE for ; Mon, 21 Jul 2014 06:45:58 -0700 (PDT)
Received: by mail-pa0-f48.google.com with SMTP id et14so9759145pad.7 for ; Mon, 21 Jul 2014 06:45:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uiSs529a4hp6nfUgFkoeeMK1hkoHBK1y45IGGiUF8n8=; b=f5tRroJgKCbcjwhjIgzVRzI8UWY6Dgd3IBFP8k+MQcuqb8TvOqNx+NalX/puNEgCpr JHE0wR2zzokpgb0cQBrrAtlqX9p66Pn/yWyaUdLRNLRlOIv6b58h9AvkhVJB2l7jhxlm bFGDdIJR7CGIDEhFcqQO7yN70tz1IOfHpRsIUp2orvQdt8Yt5B07i1CkxzZDxwOJUQzS dXNIaOzvATfTQyGs0XTaOX3cuu5Ub0/hTbjL9SWO8lzoUr+gZWzF+jrLgtEqqPUI1NHP heTd2lp0H9/gXdVFQyfDWpmdQVEYsC1hlkh3h6segW1mCdx+ZK0pFqU7ZTFMSLN48xup cdFg==
X-Gm-Message-State: ALoCoQmMqj0rODI8zNfKhMw/ezB1gQgiAv1m396Ic9ltWLb72FoKu1xDu389ddjyPX/Ijeo/P0vT
MIME-Version: 1.0
X-Received: by 10.66.196.47 with SMTP id ij15mr1697078pac.103.1405950358312; Mon, 21 Jul 2014 06:45:58 -0700 (PDT)
Received: by 10.66.27.5 with HTTP; Mon, 21 Jul 2014 06:45:58 -0700 (PDT)
X-Originating-IP: [2001:67c:370:176:156b:96e8:c71:4f47]
In-Reply-To: <53CCE38B.7070609@it.aoyama.ac.jp>
References: <53CCE38B.7070609@it.aoyama.ac.jp>
Date: Mon, 21 Jul 2014 09:45:58 -0400
Message-ID: 
From: Andrew Newton 
To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/FNax6gFM95-Q7ddL_zG6XnsN20A
Cc: "urn@ietf.org" 
Subject: Re: [urn] Query choices
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Jul 2014 13:49:20 -0000

On Mon, Jul 21, 2014 at 5:55 AM, "Martin J. D=C3=BCrst"
 wrote:
> I'd also like to note that none of the above alternatives would need a
> separation of URNs from RFC 3986. RFC 3986 delegates the question of whet=
her
> and what queries are allowed to each scheme, in our case urn:.
> Also, there is nothing in RFC 3986 (or in RFC 4395, which is relevant for
> registration) that says that the syntax of a scheme cannot be changed.

Not to disagree with you, but people have pointed out to me the figure
at the end of Section 3 (http://tools.ietf.org/html/rfc3986#section-3)
which they have interpreted as RFC 3986 disallowing queries and
fragments in URNs.

-andy


From nobody Mon Jul 21 07:06:26 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582561A0062 for ; Mon, 21 Jul 2014 07:06:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.85
X-Spam-Level: 
X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5] autolearn=ham
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 ep5yIp8qEJju for ; Mon, 21 Jul 2014 07:06:21 -0700 (PDT)
Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 529461A000A for ; Mon, 21 Jul 2014 07:03:29 -0700 (PDT)
Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id EB6B88AD2D; Mon, 21 Jul 2014 16:03:27 +0200 (CEST)
From: "Svensson, Lars" 
To: =?Windows-1252?Q?=22Martin_J=2E_D=FCrst=22?= , "urn@ietf.org" 
Thread-Topic: [urn] Query choices
Thread-Index: AQHPpMn82X9pQ1XBoUexF+mfINGt5ZuqjtRQ
Date: Mon, 21 Jul 2014 14:03:25 +0000
Message-ID: <24637769D123E644A105A0AF0E1F92EFA44671D9@dnbf-ex1.AD.DDB.DE>
References: <53CCE38B.7070609@it.aoyama.ac.jp>
In-Reply-To: <53CCE38B.7070609@it.aoyama.ac.jp>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.69.85]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/eeKPrrzvJ2j2Vg1-r1ZQ-4u5zKI
Subject: Re: [urn] Query choices
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Jul 2014 14:06:24 -0000

Martin,

> I tried to answer some of the previous mails, but concluded that the
> following may be easier and faster.
>=20
> I'm trying to list some of the choices that are possible for the
> upcoming URN spec with respect to query. The ones below are the main
> ones I have found.
>=20
> A) (continue to) not allow query
>=20
> B) (continue to) not allow query but provide (a) separate scheme(s) for
> using URNs with queries
>=20
> C) allow each Namespace to opt in to use queries, and define how they
> are used (syntax details, semantics, within some common boundaries)
>=20
> D) define a common use for query parts for URNs; allow each Namespace to
> opt in to this common use
>=20
> E) define a common use for query parts for URNs; do not require opt-in
> so that this use is possible with any Namespace when desired/appropriate
>=20
>=20
> My understanding from fairly recent email is that John is somewhere
> around C), Yuha probably close to E), and Larry around B). Of course I

s/Y/J/

> might have read something wrongly; in that case I apologize in advance.
>=20
>=20
> My personal preference coincides with Larry (B), but probably isn't as
> sharp as his. I'd be okay with C) if that's what the WG decides to do
> (after all, it's mostly the people who define and use certain Namespaces
> who have to live with the queries on them), and could live with D) or E)
> if that makes the WG and the IETF happy because I'm not using URNs.

Thanks for providing this list. My preference is C).

>=20
> I'd also like to note that none of the above alternatives would need a
> separation of URNs from RFC 3986. RFC 3986 delegates the question of
> whether and what queries are allowed to each scheme, in our case urn:.
> Also, there is nothing in RFC 3986 (or in RFC 4395, which is relevant
> for registration) that says that the syntax of a scheme cannot be changed=
.

Best,

Lars


From nobody Mon Jul 21 07:09:20 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19BCB1A00D5 for ; Mon, 21 Jul 2014 07:09:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.25
X-Spam-Level: 
X-Spam-Status: No, score=-6.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5] autolearn=ham
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 viUHWye7B9Eq for ; Mon, 21 Jul 2014 07:09:17 -0700 (PDT)
Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id CA5671A00DF for ; Mon, 21 Jul 2014 07:08:00 -0700 (PDT)
Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id 131338AD32; Mon, 21 Jul 2014 16:08:00 +0200 (CEST)
From: "Svensson, Lars" 
To: =?Windows-1252?Q?=22Martin_J=2E_D=FCrst=22?= , "urn@ietf.org" 
Thread-Topic: [urn] Query choices
Thread-Index: AQHPpMn82X9pQ1XBoUexF+mfINGt5ZuqjtRQgAAAwbA=
Date: Mon, 21 Jul 2014 14:07:58 +0000
Message-ID: <24637769D123E644A105A0AF0E1F92EFA44671F6@dnbf-ex1.AD.DDB.DE>
References: <53CCE38B.7070609@it.aoyama.ac.jp> 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.69.85]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/m3q718vmZUchx09jvHtKJBgZv2M
Subject: Re: [urn] Query choices
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Jul 2014 14:09:18 -0000

Sorry, sent too quickly...


> > C) allow each Namespace to opt in to use queries, and define how they
> > are used (syntax details, semantics, within some common boundaries)
=20
> Thanks for providing this list. My preference is C).

That said, I still think that *if* the scope of sending parameters with a u=
rn (using the URI query syntax) is to give information to resolution servic=
es what to do with the URN, then the use of queries should be handled in 24=
83bis and not in 2141bis. This would also solve the question if the query i=
s "part of the urn" or not.

Lars


From nobody Mon Jul 21 07:31:53 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDCC1A002C for ; Mon, 21 Jul 2014 07:31:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
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 erGNZ3S02fLt for ; Mon, 21 Jul 2014 07:31:46 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE6BB1A0019 for ; Mon, 21 Jul 2014 07:31:45 -0700 (PDT)
Received: from [31.133.160.134] ([31.133.160.134]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MZCxA-1WoPQ43giK-00L2A4; Mon, 21 Jul 2014 16:31:37 +0200
Message-ID: <53CD2445.2040004@gmx.de>
Date: Mon, 21 Jul 2014 16:31:33 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Andrew Newton , =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
References: <53CCE38B.7070609@it.aoyama.ac.jp> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:Ud2fnnG0wb0kZVFw/FkkMsqJ44Iti9kkE00mSu6zuH9hNPRfjaN 1DvXQZmWfEKs/Jw0TPr41St6PyOEuQfMzTAcp9NWdim3o7oa6sQ8vIf+KmukfZm88dy7/tz cVwviOa8WPhClAiJjmiqkCO5Ku+6Vx9g3s++zJ6HmrmSUE4Gw7Fb98X8Z8QP6hclEH5bNrE yx6L7/ifSFtzgtgUOY36w==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/-EU4PcjvOiK-O5Gng2wa22h4Too
Cc: "urn@ietf.org" 
Subject: Re: [urn] Query choices
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Jul 2014 14:31:47 -0000

On 2014-07-21 15:45, Andrew Newton wrote:
> On Mon, Jul 21, 2014 at 5:55 AM, "Martin J. Dĵrst"
>  wrote:
>> I'd also like to note that none of the above alternatives would need a
>> separation of URNs from RFC 3986. RFC 3986 delegates the question of whether
>> and what queries are allowed to each scheme, in our case urn:.
>> Also, there is nothing in RFC 3986 (or in RFC 4395, which is relevant for
>> registration) that says that the syntax of a scheme cannot be changed.
>
> Not to disagree with you, but people have pointed out to me the figure
> at the end of Section 3 (http://tools.ietf.org/html/rfc3986#section-3)
> which they have interpreted as RFC 3986 disallowing queries and
> fragments in URNs.

Well, that's a misreading of the spec. It's just an example of two URIs 
and how they are decomposed.

Best regards, Julian


From nobody Mon Jul 21 19:43:40 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EEF1A0392 for ; Mon, 21 Jul 2014 19:43:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.302
X-Spam-Level: 
X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 QgzqN9BiueM5 for ; Mon, 21 Jul 2014 19:43:38 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 866E11A0383 for ; Mon, 21 Jul 2014 19:43:38 -0700 (PDT)
Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB308.namprd02.prod.outlook.com (10.141.91.24) with Microsoft SMTP Server (TLS) id 15.0.990.7; Tue, 22 Jul 2014 02:43:37 +0000
Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0990.007; Tue, 22 Jul 2014 02:43:36 +0000
From: Larry Masinter 
To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= , "urn@ietf.org" 
Thread-Topic: [urn] Query choices
Thread-Index: AQHPpMoPqI1efsK1sUS4S/my+X2WwZurEA0g
Date: Tue, 22 Jul 2014 02:43:36 +0000
Message-ID: <4351aa24205e455e88c5c31a98257b62@BL2PR02MB307.namprd02.prod.outlook.com>
References: <53CCE38B.7070609@it.aoyama.ac.jp>
In-Reply-To: <53CCE38B.7070609@it.aoyama.ac.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [31.133.138.253]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 02801ACE41
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(83322001)(33646002)(95666004)(50986999)(19580395003)(46102001)(87936001)(74316001)(99286002)(54356999)(85306003)(76176999)(99396002)(101416001)(15975445006)(76482001)(77982001)(21056001)(79102001)(83072002)(4396001)(107886001)(74502001)(86362001)(107046002)(81342001)(81542001)(76576001)(2656002)(31966008)(74662001)(105586002)(20776003)(92566001)(106356001)(106116001)(85852003)(64706001)(15202345003)(80022001)(66066001)(108616002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR02MB308; H:BL2PR02MB307.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/tPmmms3GhJp6fq0qvvH3plwqLNQ
Subject: Re: [urn] Query choices
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Jul 2014 02:43:40 -0000

Thanks Martin, this is helpful.

> A) (continue to) not allow query
OK with me, but includes B.

> B) (continue to) not allow query but provide (a) separate scheme(s) for u=
sing
> URNs with queries

One way to accomplish most of (E)

> C) allow each Namespace to opt in to use queries, and define how they are
> used (syntax details, semantics, within some common boundaries)

This is fine with me, but changing an existing Namespace should be done
 with caution for backward compatibility

> D) define a common use for query parts for URNs; allow each Namespace to
> opt in to this common use

This is (C), but with "common boundaries" taken to an extreme

> E) define a common use for query parts for URNs; do not require opt-in so
> that this use is possible with any Namespace when desired/appropriate

This is (D) if "desired/appropriate" is treated as "opt-in".

> My understanding from fairly recent email is that John is somewhere
> around C), Yuha probably close to E), and Larry around B). Of course I
> might have read something wrongly; in that case I apologize in advance.

I prefer B or C. If the features of E are really needed, use B instead.

> My personal preference coincides with Larry (B), but probably isn't as
> sharp as his. I'd be okay with C) if that's what the WG decides to do
> (after all, it's mostly the people who define and use certain Namespaces
> who have to live with the queries on them),=20

Just be careful that the users exceed the definers for existing
Namespaces.

> and could live with D) or E)
> if that makes the WG and the IETF happy because I'm not using URNs.

If we don't care about users because we're not users, I have
to confess: I don't use URNs either.


> I'd also like to note that none of the above alternatives would need a
> separation of URNs from RFC 3986. RFC 3986 delegates the question of
> whether and what queries are allowed to each scheme, in our case urn:.
> Also, there is nothing in RFC 3986 (or in RFC 4395, which is relevant
> for registration) that says that the syntax of a scheme cannot be changed=
.

RFC 2141 URN Syntax is standards track, so the bar for updating=20
should follow the rules for updating standards track document:
based on implementation experience. If there is implementation
experience with using ? in URNs, which would justify C, D, or E,
please cite it. If there is none, stick with B.

Larry
--
http://larry.masinter.net


From nobody Mon Jul 21 22:28:52 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219491A019C for ; Mon, 21 Jul 2014 22:28:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] autolearn=no
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 akDi616r-8mx for ; Mon, 21 Jul 2014 22:28:49 -0700 (PDT)
Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id E6A6A1A008F for ; Mon, 21 Jul 2014 22:28:48 -0700 (PDT)
Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 8C0D35686BD; Tue, 22 Jul 2014 00:28:47 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 835FAA0303; Tue, 22 Jul 2014 00:28:47 -0500 (CDT)
X-Virus-Scanned: amavisd-new at smtp-out-1.01.com
Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wu0Fc9kqNOP; Tue, 22 Jul 2014 00:28:47 -0500 (CDT)
Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 62079A02E8; Tue, 22 Jul 2014 00:28:47 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 347E8A0303; Tue, 22 Jul 2014 00:28:47 -0500 (CDT)
X-Virus-Scanned: amavisd-new at smtp-out-1.01.com
Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id UBOw651F7pKI; Tue, 22 Jul 2014 00:28:47 -0500 (CDT)
Received: from [192.168.1.101] (c-98-192-98-17.hsd1.ga.comcast.net [98.192.98.17]) by smtp-out-1.01.com (Postfix) with ESMTPSA id CF31BA02E8; Tue, 22 Jul 2014 00:28:46 -0500 (CDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Michael Mealling 
In-Reply-To: 
Date: Tue, 22 Jul 2014 01:28:46 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <384D762F-BA5F-4163-A0B2-4A86ABAB175A@refactored-networks.com>
References: <53CCE38B.7070609@it.aoyama.ac.jp> 
To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/DMoinAXwniGr3OnAMyvU9E06jLU
Cc: "urn@ietf.org" 
Subject: Re: [urn] Query choices
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Jul 2014 05:28:50 -0000

De-lurking:

I try not to get sucked into this discussion these days but since I've =
dealt with many uses of URNs in the course of developing software (from =
registered uses in XMPP to numerous unregistered uses inside various =
well known systems) and I helped authors write several URN registration =
documents I think I understand some of their motivations.=20

Based on that and my rather rusty memory of the old discussions I still =
think I would opt for D. I remember discussions with TimBL back in '92 =
(prior to the revisionist history suggesting Tim had an actual design =
behind URLs) saying that query parameters and fragments were 'modifiers' =
of the base 'URL'. In practice query parameters were simply alternative =
representations of a path. Fragments really were orthogonal to the URI =
since they were interpreted within the scope of the returned MIME type.=20=


I've been writing REST-ful APIs using Node lately and there is no =
functional difference between /v1/foo/:id and /v1/foo?id=3D:id. Query =
parameters are a hold over from a world that doesn't exist anymore. So =
I'm loath to perpetuate the fiction that query parameters are somehow =
'special'.=20

For me the distinction between D and E is one of whether Joe Random =
Developer out there even gives a crap. I've seen perfectly reasonable =
people attempt to do this: mailto:foo@bar.com#fragment expecting to be =
able to denote a part of an email. Or something. I'm not sure they even =
understand what the mailto URI scheme means. So you can't really stop =
them. The only thing that stops them is a meaningless result.

So while I can't stop someone from doing this: =
urn:uuid:01489A2A-6F30-4BF8-A9E2-CC9D47D5E661#cthulurises I'm fairly =
sure they won't do it outside some closed system simply because a) there =
is not resolution system for UUID URNs and b) if there were it would be =
nearly meaningless to attach a fragment to it.

So go for D. Make sure that if someone decides to allow them for a =
namespace that they follow the existing query parameter standard. But I =
would strongly encourage ALL URN namespaces to disallow their use since =
in practice they merely represent an extension of the name, not some =
external resolution API parameter expression mechanism.

For those that remember the discussions in '93 there was a proposal that =
query parameters and fragments be put into separate attributes to the =
HTML anchor tag. Have fun thinking about the ramifications of that. ;-)

So yea, I'm behind D.

-MM



Michael Mealling
+1-678-640-6884	@mmealling
Schedule a meeting:  http://meetme.so/michaelmealling




On Jul 21, 2014, at 5:55 AM, Martin J. D=FCrst  =
wrote:

> I tried to answer some of the previous mails, but concluded that the =
following may be easier and faster.
>=20
> I'm trying to list some of the choices that are possible for the =
upcoming URN spec with respect to query. The ones below are the main =
ones I have found.
>=20
> A) (continue to) not allow query
>=20
> B) (continue to) not allow query but provide (a) separate scheme(s) =
for using URNs with queries
>=20
> C) allow each Namespace to opt in to use queries, and define how they =
are used (syntax details, semantics, within some common boundaries)
>=20
> D) define a common use for query parts for URNs; allow each Namespace =
to opt in to this common use
>=20
> E) define a common use for query parts for URNs; do not require opt-in =
so that this use is possible with any Namespace when desired/appropriate
>=20


From nobody Tue Jul 22 02:35:50 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C241A05D1 for ; Tue, 22 Jul 2014 02:35:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.208
X-Spam-Level: 
X-Spam-Status: No, score=0.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=no
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 Zl_HyM9F5qd4 for ; Tue, 22 Jul 2014 02:35:38 -0700 (PDT)
Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5101A0503 for ; Tue, 22 Jul 2014 02:35:37 -0700 (PDT)
Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 79FEE32E4F6; Tue, 22 Jul 2014 18:35:36 +0900 (JST)
Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 0af4_f0b8_22040f97_6199_4870_be88_5a3c1b9532f7; Tue, 22 Jul 2014 18:35:36 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id A0BA9BFC81; Tue, 22 Jul 2014 18:35:35 +0900 (JST)
Message-ID: <53CE3059.1040806@it.aoyama.ac.jp>
Date: Tue, 22 Jul 2014 18:35:21 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Andrew Newton 
References: <53CCE38B.7070609@it.aoyama.ac.jp> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/u7eCI3IDGkodOnXMcXuUz4BEo2M
Cc: "urn@ietf.org" 
Subject: Re: [urn] Query choices
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Jul 2014 09:35:49 -0000

Hello Andrew,

On 2014/07/21 22:45, Andrew Newton wrote:
> On Mon, Jul 21, 2014 at 5:55 AM, "Martin J. D=C3=BCrst"
>  wrote:
>> I'd also like to note that none of the above alternatives would need a
>> separation of URNs from RFC 3986. RFC 3986 delegates the question of w=
hether
>> and what queries are allowed to each scheme, in our case urn:.
>> Also, there is nothing in RFC 3986 (or in RFC 4395, which is relevant =
for
>> registration) that says that the syntax of a scheme cannot be changed.
>
> Not to disagree with you, but people have pointed out to me the figure
> at the end of Section 3 (http://tools.ietf.org/html/rfc3986#section-3)
> which they have interpreted as RFC 3986 disallowing queries and
> fragments in URNs.

Seems that a lot of squashing of misunderstandings is needed, but I'm=20
glad to help. This seems (*) to refer to:

    The following are two example URIs and their component parts:

          foo://example.com:8042/over/there?name=3Dferret#nose
          \_/   \______________/\_________/ \_________/ \__/
           |           |            |            |        |
        scheme     authority       path        query   fragment
           |   _____________________|__
          / \ /                        \
          urn:example:animal:ferret:nose

Now the text here says "two *example* URIs". One of the *examples* is=20
"urn:example:animal:ferret:nose". That example very clearly doesn't have=20
a query part. Other examples such as
"foo://example.com:8042/over/there#nose" and
"foo://example.com:8042/over/there" would also not have query parts. It=20
would therefore have been very wrong if the figure would have shown it=20
as having a query part.

Any generalization from this example have to be done within the=20
boundaries of logic. It's very clear that if we have an example of an=20
URN with a scheme part, then there are URNs (at least the one we just=20
saw) with scheme parts. On the other hand, observing an example of a URN=20
without a query part cannot lead to the conclusion that no URN can have=20
a query part. Such a conclusion would be about as wrong as concluding=20
that all primes are even from the fact that 2 is a prime and is even.

Of course, at the time of writing of RFC 3986, there was no other choice=20
of URN example for RFC 3986 than an URN without query. This also shows=20
that, contrary to claims made earlier on this list, RFC 3986 actually=20
was aware of RFC 2141. And even if RFC 2141 gets updated by the work of=20
this WG and allows query parts, I think nobody is proposing to disallow=20
URNs without query parts, and so the example in RFC 3986 will continue=20
to be valid, and no split of URNs from RFC 3986 at all is necessary.

Regards,   Martin.

(*) Strictly speaking, that figure isn't at the end of Section 3,=20
because Section 3 ends just where Section 4 begins, which is a few pages=20
later. It is at the end of the introductory text of Section 3 that isn't=20
part of any subsection of Section 3.


From nobody Tue Jul 22 04:41:53 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4231A01D5 for ; Tue, 22 Jul 2014 04:41:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.208
X-Spam-Level: 
X-Spam-Status: No, score=0.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=no
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 anhunMS6EK7O for ; Tue, 22 Jul 2014 04:41:47 -0700 (PDT)
Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2681A00E8 for ; Tue, 22 Jul 2014 04:41:47 -0700 (PDT)
Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id B78E532E4A1; Tue, 22 Jul 2014 20:41:45 +0900 (JST)
Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 0af4_422b_95b95914_12e4_44d0_8963_75858cbd5175; Tue, 22 Jul 2014 20:41:45 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id B492DBF509; Tue, 22 Jul 2014 20:41:44 +0900 (JST)
Message-ID: <53CE4DDB.4070203@it.aoyama.ac.jp>
Date: Tue, 22 Jul 2014 20:41:15 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Michael Mealling 
References: <53CCE38B.7070609@it.aoyama.ac.jp>  <384D762F-BA5F-4163-A0B2-4A86ABAB175A@refactored-networks.com>
In-Reply-To: <384D762F-BA5F-4163-A0B2-4A86ABAB175A@refactored-networks.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/ukEPKMjCAn5BxkCUmWSdW8mLCxs
Cc: "urn@ietf.org" 
Subject: Re: [urn] Query choices
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Jul 2014 11:41:49 -0000

Hello Michael,

On 2014/07/22 14:28, Michael Mealling wrote:
> De-lurking:

Your historical perspective,... is very much appreciated.

> I try not to get sucked into this discussion these days but since I've =
dealt with many uses of URNs in the course of developing software (from r=
egistered uses in XMPP to numerous unregistered uses inside various well =
known systems) and I helped authors write several URN registration docume=
nts I think I understand some of their motivations.
>
> Based on that and my rather rusty memory of the old discussions I still=
 think I would opt for D. I remember discussions with TimBL back in '92 (=
prior to the revisionist history suggesting Tim had an actual design behi=
nd URLs) saying that query parameters and fragments were 'modifiers' of t=
he base 'URL'. In practice query parameters were simply alternative repre=
sentations of a path. Fragments really were orthogonal to the URI since t=
hey were interpreted within the scope of the returned MIME type.
>
> I've been writing REST-ful APIs using Node lately and there is no funct=
ional difference between /v1/foo/:id and /v1/foo?id=3D:id. Query paramete=
rs are a hold over from a world that doesn't exist anymore. So I'm loath =
to perpetuate the fiction that query parameters are somehow 'special'.
>
> For me the distinction between D and E is one of whether Joe Random Dev=
eloper out there even gives a crap. I've seen perfectly reasonable people=
 attempt to do this: mailto:foo@bar.com#fragment expecting to be able to =
denote a part of an email. Or something. I'm not sure they even understan=
d what the mailto URI scheme means. So you can't really stop them. The on=
ly thing that stops them is a meaningless result.
>
> So while I can't stop someone from doing this: urn:uuid:01489A2A-6F30-4=
BF8-A9E2-CC9D47D5E661#cthulurises I'm fairly sure they won't do it outsid=
e some closed system simply because a) there is not resolution system for=
 UUID URNs and b) if there were it would be nearly meaningless to attach =
a fragment to it.
>
> So go for D. Make sure that if someone decides to allow them for a name=
space that they follow the existing query parameter standard. But I would=
 strongly encourage ALL URN namespaces to disallow their use since in pra=
ctice they merely represent an extension of the name, not some external r=
esolution API parameter expression mechanism.

I'm not sure if I expressed myself clearly about D), or if I'm=20
misunderstanding you, but what I meant with D):

 >> D) define a common use for query parts for URNs; allow each=20
Namespace to opt in to this common use

I did't just mean "follow the existing query parameter standard" (which=20
I interpret as "what RFC 3986 says" which in turn would roughly boil=20
down to "query is everything between the first "?" and the first "#" in=20
an URI"). I explicitly meant something along the lines of what Juha=20
(sorry for the typo in my previous mail) was proposing, namely that=20
across all (opted-in) URN Namespaces, there would be a common set of=20
query parameter names with each having a defined set of query parameter=20
values.

In contrast to that, I meant C):

 >> C) allow each Namespace to opt in to use queries, and define how=20
they are used (syntax details, semantics, within some common boundaries)

in the sense that e.g. the issn: scheme could define some query=20
parameters for periodicals (maybe volume and number to indentify issues=20
from a periodical, or whatever), the isbn: scheme could define some=20
query parameters appropriate for books, and so on, but there wouldn't be=20
parameters or values that could be used across schemes unless these=20
schemes had been designed/defined in concert.

Regards,   Martin.


> For those that remember the discussions in '93 there was a proposal tha=
t query parameters and fragments be put into separate attributes to the H=
TML anchor tag. Have fun thinking about the ramifications of that. ;-)

P.S.: This is totally unrelated to the discussion at hand and OT for=20
this WG, but I'm sometimes worried we'll end up with some of these=20
ramifications with Web Intents (http://www.w3.org/TR/web-intents/). I=20
hope to be proven wrong.

> So yea, I'm behind D.
>
> -MM
>
>
>
> Michael Mealling
> +1-678-640-6884	@mmealling
> Schedule a meeting:  http://meetme.so/michaelmealling
>
>
>
>
> On Jul 21, 2014, at 5:55 AM, Martin J. D=C3=BCrst  wrote:
>
>> I tried to answer some of the previous mails, but concluded that the f=
ollowing may be easier and faster.
>>
>> I'm trying to list some of the choices that are possible for the upcom=
ing URN spec with respect to query. The ones below are the main ones I ha=
ve found.
>>
>> A) (continue to) not allow query
>>
>> B) (continue to) not allow query but provide (a) separate scheme(s) fo=
r using URNs with queries
>>
>> C) allow each Namespace to opt in to use queries, and define how they =
are used (syntax details, semantics, within some common boundaries)
>>
>> D) define a common use for query parts for URNs; allow each Namespace =
to opt in to this common use
>>
>> E) define a common use for query parts for URNs; do not require opt-in=
 so that this use is possible with any Namespace when desired/appropriate
>>
>
>


From nobody Thu Jul 24 04:36:18 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7EC1A0179 for ; Thu, 24 Jul 2014 04:36:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level: 
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=no
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 TRdlqMPzJbt1 for ; Thu, 24 Jul 2014 04:36:15 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84A1F1A017E for ; Thu, 24 Jul 2014 04:36:14 -0700 (PDT)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XAHFS-000Crz-NB for urn@ietf.org; Thu, 24 Jul 2014 07:31:47 -0400
Date: Thu, 24 Jul 2014 07:36:12 -0400
From: John C Klensin 
To: urn@ietf.org
Message-ID: <69C28E0B5B9A1CAA8F5817DF@JCK-EEE10>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==========F3C7AAB4DDE0076ECD9C=========="
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/4raQxXrnhFn6alXuDw9_ho2GlpI
Subject: [urn] Tomorrow''s "URNs are not URIs" topic
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 11:36:16 -0000

--==========F3C7AAB4DDE0076ECD9C==========
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi.

Apologies for these slides being so late, but in-the-hall
discussions had them changing until late last night and again a
few minutes ago.  We are still outside the 24 hour limit I've
proposed occasionally.

Andy, please post to the materials page at your convenience but
note that I'm circulating them directly to get them into
people's hands.

Please note that, while I've drawn some things together in
different ways, I do not believe there is anything in these
slides that is new and has not been discussed on the URN or IETF
mailing lists in the last six months.    They (and the
presentation) are really just a summary to be sure that we are
making the same assumptions about what is going on (and, if we
are not, to expose that efficiently).

In particular:

(1) If people's concerns about "URNs are not URIs" are about
some perceived symbolism, I think we should rework the draft
with a different name and terminology to reduce that symbolism
as much as possible.   The draft is intended to be a pragmatic
solution to a practical problem, not to make any symbolic points.

(2) Some comments on the list have seemed to imply assumptions
that the separation is about changes that would cause generic
URI parsers to fail in massive ways.  It would allow us to do
that.  However, or actually doing so is unnecessary for any way
that I can imagine, would probably create incompatibility with
URNs allowed by 2141 and in use, and, IMO, would be a stupid
move for those and other reasons.  As a parser specification,
3986 only requires [1] a separation of
   method:path?query#fragment
using the delimiters shown.  I don't think we need to change
that in any way that would  cause such a parser, much less a
parser based on 
   method:
to fail.
    
To review an example in advance of the slides, 3986 gives a very
specific interpretation to what people --and many existing URL
applications-- consider a sequence of queries, e.g., 
    ?x abc?y def?g=http://foo.example.com/?

3986 allows the sequence but treats it as a single query string.
AFAICT, the only practical difference is that permuting the
sequence of queries would, under 3986, cause two URIs to compare
not equal (one of many types of false negatives for some URL
situations that 3986 predicts).  Because of some expectations
about URNs (e.g., "persistence" and non-retrieval uses), that
restriction may be worth a change, even if the syntax of the
query-collection does not change a bit.

Anyway, I hope the rest of you are looking forward to a
constructive meeting tomorrow, one that makes significant
progress, as much as I am.

Note that these slides are _not_ "final".  I may not use all of
them and they will probably be edited again to improve clarity
for the proceedings if not before tomorrow.

best,
   john

[1] More or less.  The spec is unintentionally tricky and
actually does not quite "work".  I hope we can avoid getting
dragged into that discussion.

--==========F3C7AAB4DDE0076ECD9C==========
Content-Type: application/pdf; name="URN-IETF90-Klensin.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="URN-IETF90-Klensin.pdf";
 size=101941

JVBERi0xLjQNCiWm6c/EDQoxIDAgb2JqDQo8PA0KL0NyZWF0b3IgPEZFRkYwMDREMDA2OTAwNjMw
MDcyMDA2RjAwNzMwMDZGMDA2NjAwNzQwMDIwMDA1MDAwNkYwMDc3MDA2NTAwNzIwMDUwMDA2RjAw
NjkwMDZFMDA3NDAwMjAwMDJEMDAyMDAwNTUwMDUyMDA0RTAwMkQwMDQ5MDA0NTAwNTQwMDQ2MDAz
OTAwMzAwMDJEMDA0QjAwNkMwMDY1MDA2RTAwNzMwMDY5MDA2RTAwMkUwMDcwMDA3MDAwNzQwMDc4
Pg0KL1Byb2R1Y2VyIDxGRUZGMDA1MzAwNjMwMDYxMDA2RTAwNTMwMDZGMDA2NjAwNzQwMDIwMDA1
MDAwNDQwMDQ2MDAyMDAwNDMwMDcyMDA2NTAwNjEwMDc0MDA2NTAwMjEwMDIwMDAzNz4NCi9DcmVh
dGlvbkRhdGUgKEQ6MjAxNDA3MjQwNjU2MjUtMDQnMDAnKQ0KL01vZERhdGUgKEQ6MjAxNDA3MjQw
NjU2MjUtMDQnMDAnKQ0KL0F1dGhvciA8RkVGRjAwNEEwMDZGMDA2ODAwNkUwMDIwMDA0MzAwMjAw
MDRCMDA2QzAwNjUwMDZFMDA3MzAwNjkwMDZFPg0KL1RpdGxlIDxGRUZGMDA0RDAwNjkwMDYzMDA3
MjAwNkYwMDczMDA2RjAwNjYwMDc0MDAyMDAwNTAwMDZGMDA3NzAwNjUwMDcyMDA1MDAwNkYwMDY5
MDA2RTAwNzQwMDIwMDAyRDAwMjAwMDU1MDA1MjAwNEUwMDJEMDA0OTAwNDUwMDU0MDA0NjAwMzkw
MDMwMDAyRDAwNEIwMDZDMDA2NTAwNkUwMDczMDA2OTAwNkUwMDJFMDA3MDAwNzAwMDc0MDA3OD4N
Cj4+DQplbmRvYmoNCjQgMCBvYmoNCjw8DQovTGVuZ3RoIDUgMCBSDQovRmlsdGVyIC9GbGF0ZURl
Y29kZQ0KPj4NCnN0cmVhbQ0KeJzVk01LAzEQhu8L+Q9zTA475jubq9JCKwiVFQ/ioeD2A3VLty34
883sZrFKvXiTwCSTZJjnnUn2rFBAo1uzomWFl1hZcD6giRC0hFIHCV3DihUrFqzYs+K6ZldTBdai
NFCvmAKZhgItI1owzqC1APU7e+IPQqHn93ei1Fqj5ZOPtMLAj0LJNDWtKBU6/tLkme5RxFQojYo3
S+Ex8uOJjiXvhDJY8eYgnus5m9QjUMJW1qO0oGPP7WxE48E6VLpnf4T2d+4ca6REP4LXG0rpeTMQ
mVHJjPyYUJc9uh2QQ4LLyLshrnvdpgDN2zWd26R1ccoiD4Lij9tdO/rf1VxoR5Z1uR1n6qsKgxvV
V6Tmv4lPmBKdgS9DhSByo3+Qm5Q51UZVDqsMPt9t2gHJ85thYfjtW3pmRHvoLaE53v49b2oGKBMx
6Jx1JuhxTnpbTymtT2mjoMrJ5JrUQ14OX0BxnffJqt7as53Q2+GOO2f8BA+QwG0NCmVuZHN0cmVh
bQ0KZW5kb2JqDQo1IDAgb2JqDQozNzENCmVuZG9iag0KNyAwIG9iag0KPDwNCi9UeXBlIC9QYWdl
DQovUGFyZW50IDMgMCBSDQovTWVkaWFCb3hbMCAwIDg0MiA1OTVdDQovUmVzb3VyY2VzPDwNCi9Q
cm9jU2V0IFsvUERGIC9UZXh0XQ0KL0ZvbnQ8PA0KL0YxIDYgMCBSPj4NCj4+DQovQ29udGVudHMg
NCAwIFINCj4+DQplbmRvYmoNCjggMCBvYmoNCjw8DQovTGVuZ3RoIDkgMCBSDQovRmlsdGVyIC9G
bGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KeJzNVU1v2zAMvRvwf9BROkSVKNmSjxu2HnoZhgXYIenB
aZwma+qg+djQfz9SkhMnTdF0GIYhgGNRIvn4+Cg/5Zlm9Fvf51mbZ6WS3rKidNJUzIFiA3CKrZs8
m+XZ1zx7yrOPw1zJwrDDg3wVox+9XV1rZq1Uhg1nuQ5mTKCdLJn1pVSWseFjPuJfJsJKyzdioKXh
zVoMvCz5T6GNBF4LPM+3i1UrBqArWfAPgo5NVrjG1W6L/+Dw5HZOARRf4L6maGQu+DeyFnwZrHFv
2sRNxz81tGv53YO4Hd7kn4e92q6ugRk4ha8sAbfKSR/g8zFAIYY/Tn31GV+jj31HmH8pABHVQnss
6lloqqCZEj6FuCbNnSCc9W6DyB0PwK30fEW4NZ/RusT13bxu7/Go5k2o3GC06Q59IPoQo1uhIboC
EJFERsFb4UMgDKu6sOtH3PK8Xp5j5fXKTFnJrqnTRSiMYCO9Ab5Pq5g3pWoJrlH4hvAQ5LzzC1bH
f8Wimgdqf4GGMa9b4scQH8sQqt5QZZAijMX7emmILPjDZvacR/wmEh7QOL7telO3sQOQKo8sxOeu
SZVCZ4jUP4ZINc6CQePzSUU4nwk8VGFAUTbgmZfehxH9zto3ywaHQ2NfK5syxApTBqMtRdeKyj3O
8To7vRwjnFvqEc26SbUmCcQm4iDjwBe8WYb5fu5U2662YWiTMFDlyFeJkdoGQwEK5AU31hY4YR01
ePZS2ORYwSk15QtqLAodugRQKFlezExy7RNTx7tpGfVSHc22OTsYdF3O6010cHhLNO0JC2fu8gT3
/F3eU5RTB0WB+/t6Kr0s9nrCFp9K9n+VU8Qd5HQZ6neqKcZParoww78R01ttMZ70FfN313r8UKku
X/riVt3FthCHVqXv0L4Tfev+Lu0h+g3IKs8yDQplbmRzdHJlYW0NCmVuZG9iag0KOSAwIG9iag0K
Njg3DQplbmRvYmoNCjExIDAgb2JqDQo8PA0KL1R5cGUgL1BhZ2UNCi9QYXJlbnQgMyAwIFINCi9N
ZWRpYUJveFswIDAgODQyIDU5NV0NCi9SZXNvdXJjZXM8PA0KL1Byb2NTZXQgWy9QREYgL1RleHRd
DQovRm9udDw8DQovRjEgNiAwIFIgL0YyIDEwIDAgUj4+DQo+Pg0KL0NvbnRlbnRzIDggMCBSDQo+
Pg0KZW5kb2JqDQoxMiAwIG9iag0KPDwNCi9MZW5ndGggMTMgMCBSDQovRmlsdGVyIC9GbGF0ZURl
Y29kZQ0KPj4NCnN0cmVhbQ0KeJzlVctu2zAQvAvQP/BIIQ1LLimSuvYRoD0ESOoiB7cHx1EcB7ac
+FE0/frukpQquU7TBL0VBmRR4u7szA5X93mmGP3Wszxr8sxK4Q0rrRO6Yg4kOwYn2brOs+s8O8uz
+zx7M8pfnyhmjJCaja5zxST+FAOvhWfGWyENY6NlPubnJ4UThr8tjgGMKDkoo+heCsk/F0pYfn66
Kb6OPubvR4P0wDTspVfSUGIjHaJQev4FoCxGt/ux6kCsVsPYMQXr4lhhdbs1VqJ5g08MFaeE50d0
47G+U3zn+Ae8Sv4OH2qKOIp8fHr7ifJY/HsWEW0xFl7IpBc85meEr/iuJiKKz/Fa8noTWL3CUpXH
p9dBbtxRIYHJjEI0X+JD4HWDXar4NuygMBPCoMTlpLmKrDVfRZi47QbBcItGpBhxV0/nQY3JolfF
jwJ1QoSrQ9r8gR4m1vBbpxAaUPXJPCAsAkLbNYswmwKdBfyh4xN240Ly73GPIgUUvkzyEAuLy2+F
Ik/WV9GdBuXCwmXLeR0bLpOKu20BiEPGAZK6NUtdKHIFYpX4OuHXDUFVSZCUsNnTA09esgVU4ehh
keCZF96Hw3fBmicNBc4JMI8ZihCiuAmhtEZoi8Gk9BDj8cb0MMZ4rIlKxyi6bCAb+csn5s2MjER6
xXX03t0CpVS8XoYTVh/oXPTbUL0NpXKd925Wu0XwXvJq2XX5tp5SCDVjKPiBoZd0OTz0eg1y8leD
wP379lgvyq496Kt9B/wH3XmKp/bUsMgzzaPVJtbYjua/mQUH9Xjm90hVIJx94RjvBY/5RYHNRnHm
YbhgxRZ5dUOEaiYml3UgtD+foqA07NHEXIfhVoWrD1dL2tMnOA50TNWO+hUtK7LAahvfQJdvsiAD
lPwhqlqlkN1lcEdqn3xu+1QZrN21jwiu4gentWP7LcKiJTonwiYbTqilbuC8aZzArj/doUuTFJ1u
Q5Z9r/ZK/wkt4ufXDQplbmRzdHJlYW0NCmVuZG9iag0KMTMgMCBvYmoNCjczNQ0KZW5kb2JqDQox
NCAwIG9iag0KPDwNCi9UeXBlIC9QYWdlDQovUGFyZW50IDMgMCBSDQovTWVkaWFCb3hbMCAwIDg0
MiA1OTVdDQovUmVzb3VyY2VzPDwNCi9Qcm9jU2V0IFsvUERGIC9UZXh0XQ0KL0ZvbnQ8PA0KL0Yx
IDYgMCBSIC9GMiAxMCAwIFI+Pg0KPj4NCi9Db250ZW50cyAxMiAwIFINCj4+DQplbmRvYmoNCjE1
IDAgb2JqDQo8PA0KL0xlbmd0aCAxNiAwIFINCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQo+Pg0Kc3Ry
ZWFtDQp4nL1YS2/bRhC+C+B/INDLEqi3+34ARQukSYD2UKCxgh7cHmSJslREsi3JDfrvO7NLW5wl
TUM9FAYUkvvtzDfPnc1jNZM1/h3uqtm+mjnBg6mt81zH2itRXykv6kNbzdbV7Ldq9ljN3s2r7z7K
2hgudD1fV7IW8AcyrOFa1SY4Lkxdz3fVDfv0sfHcsJ+aK6UMt0zH4PBZcMEW++ZKwuIqL2p22uAH
wVr84HhgnxvJHfv0K75bLtn7QyMD7FjsFs2f81+qD3PCSdVaEELCIBMjNfJCQuwPENTM/yp3ynKn
lsXOG/ah0QrIrZuYfoEQMsVPyxPyjmyb3v5uwsvKl/T7D/CXaFgG7B7uj3lDBqH9qI+BdTptBQey
E7zhv/eLjB1XAoJFfyeuPTYo7Kk5ayTLuzat7JMdpyMqRxH3+zGXvuIYHQSPz475nMRClFDs8YLA
aCP/Y2B6Owv9736+xmzBx+VmcTg1Ur5YfsAVfaG7koN0CtNZ0uJLD75Pz3c5SQX7uk3vmMxKhfSU
4oSPOuYgQhFc4GwRzs7OKo9dAj31OJWeh2LuBKiYqllGqCZTC25CKujf6/20YuXi2cs96qk6BbvO
ibTrErRLqGz9smQz0mQ6WhNN5pW86fEayZue3U5y5Z/t1o5L9f8b3hmCG2m3NCKpgtyKZ1vcSA3o
kc1Ocdff+73Q7foH2PuC8JaHArG2BBFiuW7660oorkqEIghpuaEIITRBQKMvWAhJZWjDfaFG+hWB
mFCqkbfEFAXuEIUe6dYUEoYQuSCQILl30/YEj6lEpVgiRYvUmihEEJt1PlYoZCkIBA7EUCqSLYFo
P/AtZauN5rYwSEaqx+qBzSVb57ga2EwipL0aQqhzdbC4NkkX67TM2cK5MXBZ0qVcDPSIAUQFApHD
dCm4GOl5nPaLgWPTTKe/gZ5TBtpYkrrwWia39iTOxo1kC60Q432xHpZkPaTeN0m1DI62hIWFbjCA
GMLCQjuwAymkCi10sjd8ZvVILVNzrbHDpKUWW5hFw3SILZ5CZbrdegLxelCFpUXBDLhoTyFRDfK6
5AJ5/YZfnDBv9RUHA2PpuRAJQqfTfxJiRuqHdh5n/SCdSipwgk5HyPkw7Bm0Obkw9Iqm5eOieaut
eCEG7i96hhduCImk83g866Yj5NVI5y8UKT+EUKM9tPWyijpFg3HxtblAWEzbPL48HbtLFV4zsPGx
E1zJPLvPty7JtvsVIuBhCQuBLeBqETtQGlyhh8HHbvaBGUUjXOMVCKoD5OAdLf/ComkiOIp9i/jI
FUzDpyx9k8dyy0751peGYviggECDl7pO4+Ehi4chXAG6baCQYQ1ezAu1JGCLOhVMX4li7Cisxwfr
VzwlvcfqzZ562zQgjJxu2+3+LrOX7LjEPQ7s2SVgewXTuGSr9gGpGwbeRVntHi8VHslDZJM8ddmk
KOE0N2ZyUnzdzvPeG/YeqIMVWwi7ge/gwuzJzq8cPlu88Fzje2AP7TJn0Ha9PSfR182iiXmTgqRW
Pe/9CJ+gtT67DE9SuOuvsvf6wG/OTlUMvQfhX2AyhCwWmPc3bu4byGv29bIIQ93q5whnYUDIAf82
XfNk/t8Gcc6rDcbN5ku7xQwGO+GqnvIx9NGkim4vS+e0tuJ9U/4FWKaawQ0KZW5kc3RyZWFtDQpl
bmRvYmoNCjE2IDAgb2JqDQoxMjM1DQplbmRvYmoNCjE4IDAgb2JqDQo8PA0KL1R5cGUgL1BhZ2UN
Ci9QYXJlbnQgMyAwIFINCi9NZWRpYUJveFswIDAgODQyIDU5NV0NCi9SZXNvdXJjZXM8PA0KL1By
b2NTZXQgWy9QREYgL1RleHRdDQovRm9udDw8DQovRjEgNiAwIFIgL0YyIDEwIDAgUiAvRjMgMTcg
MCBSPj4NCj4+DQovQ29udGVudHMgMTUgMCBSDQo+Pg0KZW5kb2JqDQoxOSAwIG9iag0KPDwNCi9M
ZW5ndGggMjAgMCBSDQovRmlsdGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KeJydVltv2koQ
fkfyf/DjrhT27MX22n3sTTpHak6aUulITh9IvARXYBIMOUp/fediE0NBbRAS3tvMznzzzcw+RiMT
4299H42aaJRplSdxmnnlithbHY+t1/E6RKNZNPocjR6j0dtJ9NdHE7tCFVk8mUUm1vADHTpTaRYn
OchmcTxZRqX4ei3HRhlx2cqxtYmyopZGedHcLbZVwDWrctEGmcGhJ2m0SkVYS4syUxRNxAJPZTDY
4NyJ54fAG6TSgMAK56mY8cFU3FjrmimfXoYWpon8Nvkn+jDZc8HGTu/bnyidxIlxylmyHzWlcvL9
UNIcSjpzIFmKT1NpcqXFM1hlChjMwXENTpkUPk8S9zoAtKhor5Y4nsmC/m1KJ3BpLUFzP2lof8PO
H+w9kp7tQNve9jLQTqcB8XMabVrQ8qq5R6V47f81rWzmx3A74b3LtSp677fdRUO3xlYVAMfLEm/T
pWTQfM/K9hUxc4k5M2YDyVL8i5wpOrswOBRBYGc6RHxFRMt3DkyXLMbWj3lyJz1F25OkMbsY3NPS
as0Q8Fr75rivwGbt9oxONBmt0x5qdDc76u6vwplV2VC2FFfbHT/AWUzMuqk4Y2v0IAcPcvBmA2MP
eWZUhozysN9eMFmcCAokNAzuVbdmxX+oxItPGHQjrq4o6d/gJSkobVZcDdJO5e13PA5W3G1YgPQg
NZsg8dgTMJYKAyjwMAIbLC60KG/FAveNCNUBjEcqmy1+V9lOw249GHse6i+ipfiwJKNvQ1XV6LcV
lHgGaxrjMWN4ClFXoYEAOK59iahndSD8ufoBCB4GORVHmCRiyuED5hFETlT1DwlIFgjO2GrfnTma
1qdsT5xKe8YEvM7vrrtd8HV1y6yZc7y6u7wIixZXoKLMA1ENooTB5UJ/hDh/s6Nf8JOLt5eUYRdM
nORgt/tcXnCJteI9siflNM7g8KuSympQcWZ0d6Jlb9RDuOuQmS6Ytb4PIpZABwdaXneHQe/JTZyH
PuBAXaBF+DadWkIRU/koitcfJTbCdzjHG75KvPj68kRNPQWJ8YnK8/MwGciWg/uJtBk0mE1HGG7a
po/d/ucL1+Dkl4TfUqGA1wTPm1f6BZ/0zEweyJbiRrAXD2Sf7cvZ9JaDtHjmvKYektALp6tjlMI9
M+CVQvVxV1/J1Qvmg+OcxndCr7/j0ZzqocXDVU1NE4BoO9at9qY38hXN1GiLnzOa6UCyFO/5DfHn
zxmDjZH75qprqcvt8AmxqeVLH+X+489/PKW7Bh4GrZiVtWqI10/nEl3HDQplbmRzdHJlYW0NCmVu
ZG9iag0KMjAgMCBvYmoNCjk2Mw0KZW5kb2JqDQoyMSAwIG9iag0KPDwNCi9UeXBlIC9QYWdlDQov
UGFyZW50IDMgMCBSDQovTWVkaWFCb3hbMCAwIDg0MiA1OTVdDQovUmVzb3VyY2VzPDwNCi9Qcm9j
U2V0IFsvUERGIC9UZXh0XQ0KL0ZvbnQ8PA0KL0YxIDYgMCBSIC9GMiAxMCAwIFI+Pg0KPj4NCi9D
b250ZW50cyAxOSAwIFINCj4+DQplbmRvYmoNCjIyIDAgb2JqDQo8PA0KL0xlbmd0aCAyMyAwIFIN
Ci9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQo+Pg0Kc3RyZWFtDQp4nM1VO2/bMBDeDeg/aCqOgxm+KY19
Dt2KGshgd1BS2k5qS47stM2/7x0p2bLroHXQoRAgSkce777vXg/ZSOb0tItsVGcjJ3hhcus812Xu
lcjHyou8Ddlono0+ZaOHbPRmkl19kLkueenyyTyTucAH75CCqyI3Beq6PJ+ssym8ZWPJLTRpeVwx
yRV8ZWOlFPewrkiu4BvTBrcDyS3Ku+M7WjQsQ5s2LNyyAt8V83EX7TkIC2a56FXaO6a4gbBNJgTc
RBMlbENnde9Mzb5MPmbvJ0ewVK5RSx/BEoYLkxvheRFRwQydYZP7U115RlfLY90pvAuLlklyIBBe
qXu8EubkocaPDSImwTrSVdWhvg1Xm/hDOyWuW/wzcMfoIvwmNne0FECH6aICqYuWSggPj/G+dLwX
RkIM3vXqHBPPo9Gu5KZDM2d4g+gBxDgJClnDNF78I/lRwIrts0BCvbiMeY2caPVC6gfKU7gmBwws
KYGIr0i3IOIwkZYNcSqgI8/t+WwpDB626bjqohKq0wTC6uk8VmUsH6QZ6wHxF7GArvP6j1iV91yZ
57CShQSrs6BKjaHAOkCIxyaeZ2Rg4sBIYJQIHRGx3jDLir0A+SrhqSem2mxWWGY6SjTVW0dVc8LI
mc7SOX6+swwY9OLAoPL/nj+HjaTnj1L0f6Svw6r8aaM1InqiLW30WN3Zuvhd2SnuhrpTmKAf6P4y
tpTQVwV1Uou9OgprarYSdiT0MKeFKoMAUOdOZ3fbsMK6N9gVLgIiS8udeRmQge4UXtfkvEMPmpv7
cEuw4hRRmtrPDChanroSLR1c7Iamh+0piMsYtKE8aieI2/SroKnDjF0I09phH7sM5kF3Cp9jIxWw
DmmkodNP6J2DTYIUnbTEwjzlXDxqKX5M0nyJM9F1sa2Yw+zc7/zdKFCYsEh7HPmdVzMlbCLRHc0D
mg9VGuD9REtz6Ccb233VPLZUA/bQfU9n4r6WookSqpsmJuF3ykzq2gPHfwFMJNp9DQplbmRzdHJl
YW0NCmVuZG9iag0KMjMgMCBvYmoNCjc1NA0KZW5kb2JqDQoyNCAwIG9iag0KPDwNCi9UeXBlIC9Q
YWdlDQovUGFyZW50IDMgMCBSDQovTWVkaWFCb3hbMCAwIDg0MiA1OTVdDQovUmVzb3VyY2VzPDwN
Ci9Qcm9jU2V0IFsvUERGIC9UZXh0XQ0KL0ZvbnQ8PA0KL0YxIDYgMCBSIC9GMiAxMCAwIFI+Pg0K
Pj4NCi9Db250ZW50cyAyMiAwIFINCj4+DQplbmRvYmoNCjI1IDAgb2JqDQo8PA0KL0xlbmd0aCAy
NiAwIFINCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQo+Pg0Kc3RyZWFtDQp4nNVXy47bNhTdG9A/aEkC
sSI+RErbIg2QLgK0cJHFTBfKmH6ktjyRx3Xz970PSpZkJ3GDbooBbJPivbrn3MNDzudkplL8a9fJ
rElmLs9KmxbOZ6ZKvc7TufZ52oZktkpmvyazz8nsp0Xy+q1KTZVVLl2sEpXm8Ac5TJF5nRZKZcal
6WKfPIjF5iDnKivEMci51jrLRVPjTCX2Yf4kS5iopYcFL1LlmRNhLQuYi1GtnBeZEV841gkMKLqH
+/2p2UqVKYiFCSNw4EU4yj8WvyQ/L75Xr9YFYrXOXOr9GHZbqSF5gDIK8RcWhQN6v+9etAlUZF/W
ppbKwcRwOXAhmhAwwIrlzZp0qv2IwNxmORSkyq4g8QiJ5OLTNZpJpFGTyAfxQRqHhEIxCgmuW6ls
nKBGAONY+4ExtVLnQCWNSnFab+BpLnY4VIzUw/jUEOFxestff0qD5IQdLTOA94WJOODYwornQOlL
cTzVy76iWEDY327YTYim0pm1EWIstsvTMpIzleVQcveTbkD4uf0R0geR16SjMmArgTL8RUewBw7M
FHTl45bVPKaUIfW0T/mM47Db4UwJS7/JJWC2o8otlWwMJNE9ZncDs51GOtD7MPBBvDnwfm4ghX75
SivteOPBnhgnOR1JbqED/LtEmn7jzO/p2XQLgVlFHLoit1KwjwEpbGryqw9p8x34uUK/+gp8TE9g
Y3bjLAoPqlN6kn+KL5J0SU8kUd+ZIwCZ42a6BzQIqYIf24ZNBbQAmqpIE3HiuW455GX7xD9OO5xC
BebijFJBk6U0XyYk3vD+iPe29w9Jd5k1kfQcrfW/Jb3ItOlJz9Q0/f+Y89tm4j1aNxB+MZNHnReQ
0uTdgVjigYgOYACAQvv4W+Lsc3iSigyVUA6dlQxnbMjlldscMZnuXYVg47EVH6/YrErAVdKro4st
49GR/Quf1cZn7od8dhAJ9wqmgw5iTT4JCPB+UMFn3fT3hRYPZitCDZVfbHN6AG1bJk6LAx3+55hA
i0cs0pAsVlLn3eUDG6EBeXfyLWGVpVWPshNBVNZ7ptwPSEYB1c2SD2Qvlhyhr95w/6mo1UD3I1QK
7yFMS8y730fB8lE+OnDi4PYVyk7ebaAhhRu/u+bDrEHauS/deXXJvg8dJbFSjgnSQXV9yO0rhkQx
36c3uO+BMylPX9/S2xSXcm4S+SDesdJXbA1WnAPX6cUZIIM/AWQ853EHAnTVtZk2XAVUtAGeu777
DDmCa5gPDX3ydAXDNnX5kKEWZenEjk3LxxVYjNHXNFJhKGVHFw+eRN7aescS2HGkRuldHh8ZSCxq
3XWSvl7fIwhVVOhhqoAr4FgP7dMGkxcDteX9e8lAOxSnGBAkbpZXJNFXTKobsN4MC+fPZcfilPrI
IWeMBfVGzrFxNlayYb/zo37Afxv8tBn1bnBRQ1+Nie7cP5A3VdBRW0a6Yg9jFu7dRSQ4WrMCTb+Z
nvmyy0W2hN1ftmGEpelOOqjpH8ue9VsNCmVuZHN0cmVhbQ0KZW5kb2JqDQoyNiAwIG9iag0KMTEy
Mg0KZW5kb2JqDQoyOCAwIG9iag0KPDwNCi9UeXBlIC9QYWdlDQovUGFyZW50IDMgMCBSDQovTWVk
aWFCb3hbMCAwIDg0MiA1OTVdDQovUmVzb3VyY2VzPDwNCi9Qcm9jU2V0IFsvUERGIC9UZXh0XQ0K
L0ZvbnQ8PA0KL0YxIDYgMCBSIC9GMiAxMCAwIFIgL0Y0IDI3IDAgUj4+DQo+Pg0KL0NvbnRlbnRz
IDI1IDAgUg0KPj4NCmVuZG9iag0KMjkgMCBvYmoNCjw8DQovTGVuZ3RoIDMwIDAgUg0KL0ZpbHRl
ciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0NCnicvVdLj+JGEL4j+T/42C0Fp19u29dIu4fVJlFW
JHtgcvCCDd4FM4ONyPz7VHW1TZthdsMcopEwU+6q+ur1VfMUzWSMf8dNNGujmRVJbuLUZoku4kyJ
eK4yER+raFZHsz+i2VM0+2UR/fxexrpIChsv6kjGAv7AhioSbeNUSnzEi320ZO/4XCaG/cPnCh49
lyKxrGrXKE5Zw2WSsXYDb5VOJPvzE8ol+637CUUWVD5xmcGj4imc9/olGfXa+FCBkR7faratSKCY
LnJSsPzvxYfo3eJHgSgJzlRsrL4E8hHdaNZ+47JIxABhw3OABZ5MKpKCzefoM03yEfbTKYz0yKXC
+Ds6JthnbhDygQ4dv90CqGItJmkWJhEmNtImyoFjD2CML77eiGyqqOVUccn+4iYDGBVX8Ano4LNx
32ssWMGeKYeC9duS48n+FkJz5UhZgxkNHbl8FWznjO9eqcPEiBauE0MjAFCPaJ8c2lOAefJ6X7k3
Lcdq9R21E8alUHw4oiC/MvMyDSRx2q7q0Lj/AbpPtM6hBTz02hk9kvdyQ9l4iVEipNK1CTr3oFcu
9Ye2a9z5jkvpSiEvoL0N1EDhmU72WxRAu8AMkMvcgkQLsoId+BxCIItUaRxZ+Yag0zwZZqaj+Pa+
+N4JQVt1JMRBl2ZMeEsvd0FV1kE96PVmqMejz6p0+VmRRV8zb/+m3gMbIZEH3+VfOKUE/kWL5+1h
T+ce+O3JxPLoSRaMcFlA7jLjdNqb0/lS2QI7hLpL9jv6t8y1KzLoakvsVgLfFUQ9CiZEE+sZtj04
Nuwq6gRLlJMiETVHLG/Gqj21NpZDDnrYfCKH/x8YUXDJDVitkXDd1GggtWqFDQYvx9PozY6+q+NV
lmCfUEyqcPtEijSGqSuUWyif4/aHuRBgOPe5eHSxqNFpBsHQ9xXQ8CDf7borFDf2m8dze78FqE2S
SkKd5Pn/Cvp71K/spLvu4P5A803k7+klZBN8zukx8BQ3IdPuG08x4wjKO3hX67spSOkssfcRrzH2
mngdgFPtjtQBtFXDX6XdF9ulJCLbDQbbQJc+157SPTMd6oGxR2677LRuAvuejMCw5kNGMJm+sHVQ
hP40+vJgfTk9Be5PbZCFPsxCl9zHjjKzic3fxo6B7pL9SnRUla1bnppq4biodDeznmKBK+NuR9u0
8BNXU8bTC3ntaRNBpO6udup4TvxIW/mLp1R1NdKrqvMUWq0HWmxachZQ46DcldB8Nyv3WsApoBlu
QGcofQHcLNHL851ZVwJvtW/L+kV3SXdbO1kpbiFksCKG3FTrZkWh+ww07oIu7UVyyUl96k+01oZt
NWy1c9PTOtrS2ZRtm43/biYMiqQDlpp11TrH1McOHR243k3fD7iAXwDDNWZduU1ZN60PAo2Ww+WM
uqXZuFsIymG/jUHTNvbdINnjriRs7RBO4/pQgCKVtqJfBqnnIk0C/G1xduM5hruZzNy/Z5bzzQ0K
ZW5kc3RyZWFtDQplbmRvYmoNCjMwIDAgb2JqDQoxMTEwDQplbmRvYmoNCjMxIDAgb2JqDQo8PA0K
L1R5cGUgL1BhZ2UNCi9QYXJlbnQgMyAwIFINCi9NZWRpYUJveFswIDAgODQyIDU5NV0NCi9SZXNv
dXJjZXM8PA0KL1Byb2NTZXQgWy9QREYgL1RleHRdDQovRm9udDw8DQovRjEgNiAwIFIgL0YyIDEw
IDAgUiAvRjQgMjcgMCBSPj4NCj4+DQovQ29udGVudHMgMjkgMCBSDQo+Pg0KZW5kb2JqDQozMiAw
IG9iag0KPDwNCi9MZW5ndGggMzMgMCBSDQovRmlsdGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVh
bQ0KeJzFVslu2zAQvRvQP+hIHsxyEyUd26IFWqDpAhc9qD0osbwkspzIFtz8fWc4prxURhFfCgMi
TXJG7z3OoqdopGL8tfNo1EQjJ0Vm48SlwuRxqmU81qmM2yoazaLR12j0FI3eTKJX71VsrZAmnswi
FUv4gY80EzKLbeaEtHE8WUUF+9JylYiMrflYCcfu2m7Dc2HZlispUlZt+FhrDbMlV0Ix/zcVCWvA
QMO4xQUnTHDQtbSQsVlLJlWDOwmb8l+Tj9G7yQlKHRt9jlJahGcVuCOU7KfWCZ/cnxurAWOjzowL
9glgSPbMx0bkyAtQLohGxsrbdYcUDJItcTUByPPuGacZnN8RiYOZQS4lbWfstpqSK8PKZj+Fc2tu
hGa7cAp99FKBMt5ZWMT55mXaGAdXdKU0B9uCffDKzBCXAZI7nuJ9DWMBYrk78Wel9wdubdaDcYNg
/jZ2Wrhj24K99ZEoWVUCDAnCoHIVYFMW4tErnmMEVtz6e/Raa7aekcqS3XEHl7huNlwZMN22HFhJ
tCS5MVwbCG4wxjC2PhwWXv8STMmnv95V+cD9yyqSRsJbG7DHEc8kAGjd1NxQXCEw07/gVD3IWOKq
c5+xyiVCg2oSiWPW/oibf8okFdqQTHvEVeAfWPPchymJpjAgf/Oxha1jpU6xDdSVPcrhunLExQiX
9lxEqv83lRCk9rTe+UKnXXYcocPpcmaZ2zPLgt34ZKkwmvIwTDGQVA7rax8eMyol4e92sT/ni6Ly
MZr1u6sVbXbNcrvcH7xQCIZ5GSgmV9HqDQv22UPphgE+dvVmSfOGaqOkxoAnQmZwpQ7LJfdqYFIo
zOLdcutrLe35+ifZY9kS2+3ybi9BjUtkMieHe0GaoCAcHZDmEkMAkwWKZwibaRkuBSqLvNSXBiVX
aS70NZIfDAv2mhqFCgGC/VUGNH0c4HZXb4PsNV0DPR+Iim/Glu4Ansu6fg7egnp0vpv7A4uXdRkF
heC6HhMsCzZZrDf0FUCUFX0n9A21ag/J7xObdlewq/fPrvHDcbukuf82gWzLQpOu/XJNq47dw6eM
gqJzaLzkEIq7SUgjbByux7LkdBGDcXaRK4hlQ0VDuR3bNRTyKfvuEX27OUoW7esYDJkPRbh2B9Cn
J4n/Bz9hH1wNCmVuZHN0cmVhbQ0KZW5kb2JqDQozMyAwIG9iag0KODYwDQplbmRvYmoNCjM0IDAg
b2JqDQo8PA0KL1R5cGUgL1BhZ2UNCi9QYXJlbnQgMyAwIFINCi9NZWRpYUJveFswIDAgODQyIDU5
NV0NCi9SZXNvdXJjZXM8PA0KL1Byb2NTZXQgWy9QREYgL1RleHRdDQovRm9udDw8DQovRjEgNiAw
IFIgL0YyIDEwIDAgUj4+DQo+Pg0KL0NvbnRlbnRzIDMyIDAgUg0KPj4NCmVuZG9iag0KMzUgMCBv
YmoNCjw8DQovTGVuZ3RoIDM2IDAgUg0KL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0N
Cnic1VZLb+M2EL4b0H/QkQRqLl+m5OMW2wIp2gANXOzBuwcnlm1tFDmx7Kbur+8Mh9TD62Tj3AoB
egz1Def5DZ+SkUrx2q2TUZ2MnBS5TScuE2aaZlqmY53JdFcko1Uy+jMZPSWjn2fJh19Vaq2QJp2t
EpVKuEDH1Aid2twJadN09pDM2Wc+VkKyDVe5UOzIx1pL+P6itcEVx/7ieL+5bnDJiJwtdlyBGlag
wIGg3sKbmLA9CUyEXHENmhpUY1Ch5V9nvyW/zAZW6lRnAxOlReOsmohMexsROuGzb6dIdYo06gQ5
Z9dgyYQtGq40WLz3dh15JkXGfgJrlYPvw7ryIuVFBr1/3HGIgmNbtD1ndwXHGC0P8FAM1iwqrVDB
FJZJLYjBzRIRit3dv+CrHVhsJVpsciNM56s77+sQ6bRwfeCcfeRgjGR/o6sSLMd7ufRZs2h8gZZN
weyyXscsP5f7Db5P4H3NFToZfqvDc1feUd4lZBVV3pD8Cp3PfXp7qIdFQHOF6vcIxm+0QqEV+82C
o5X7uGuH8AYdz4XtBecnmYhF/Bj2J68fK1+a+LokSQ1h1e2eUL+2sxkC8i+FrkVRhQdB5s2O4YjQ
C7KrB5V8QXZ1r5Cpl1YxcTE94RGTu2wreFFVW+4wxZSKhooVFqhJITQlpS6k6EBfdC9D2GLEtu3u
Xjl99oICvxHYP47DIqAH5f0fPraWIrqooyVdUQyjClxHkdBTz3XaOmHzFCzSnu4+p/WrAdRT6M4Q
P/Ir1knwuVyVMXAxsCuqQ/JwFy28tDeI94benOHw4Nd5Du95D12uovdQfvn/0PvXuF47K/L8PVzf
Q87ZJ0/DgbILX/AZCOotDaCOcvy4yqEBoKCdHwihzc0094FyhLWRzYngm6JaXdD32mjM1+V93wP+
kNV3ZXMfk9c1qXfzUJfDDixOuDn0uJ9jPs+hLqAz1wNEu1tQtI15f4kHHgNNhvWI0n6PvH2vXiqS
s+GUUrwrmi3uzSOyWtB/gcdoXnrJoNCvI+657+DuPkbheVPiICK+a2l3Xz7gWAH8ONBvF5Ca+vTw
gFu+eRCqrNcE7YAy3lHv4XlOLzu/w8olU01ZPEleno4ON2fGbzv199zfXTxVbBbNcPYMi8x9V2S3
VTyCXMI8SuZCv4t5esg5+8PzA1SNg3Pl8bYg+jCs2XjusexQLelsoZlf1Si8g6Hn6BgJHFMR1RRL
AtMJ/Pc45S38uadGn8QqvPYHzobikfUUD9dPD97/AXyun5gNCmVuZHN0cmVhbQ0KZW5kb2JqDQoz
NiAwIG9iag0KOTQ2DQplbmRvYmoNCjM3IDAgb2JqDQo8PA0KL1R5cGUgL1BhZ2UNCi9QYXJlbnQg
MyAwIFINCi9NZWRpYUJveFswIDAgODQyIDU5NV0NCi9SZXNvdXJjZXM8PA0KL1Byb2NTZXQgWy9Q
REYgL1RleHRdDQovRm9udDw8DQovRjEgNiAwIFIgL0YyIDEwIDAgUj4+DQo+Pg0KL0NvbnRlbnRz
IDM1IDAgUg0KPj4NCmVuZG9iag0KMzggMCBvYmoNCjw8DQovTGVuZ3RoIDM5IDAgUg0KL0ZpbHRl
ciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0NCnic1VdBj9o8EL0j5T/kOJE+UttxnORatZXaQ6Wv
peqB7SELAdKGkBLotv++Mx4bAsu2sLcKiSW2Z/LmvfHM7PdgJEP6bJfBqA1GRsS5DlOTxUkRZkqE
Y5WJcFsFo0Uw+j8YfQ9GLyfBizcy1DoWSThZBDIU+JGh0ibUuYmFDsPJOpjCx2gs4xSqjv+W20jm
cQZllMUGdvWmjcZKFrjzqqQTCazLJe7lUEVfJu+C15OTN6owEcPXSaHpVVqaWNkXwp1SaTT5em4o
zw0TeWo4hbcLhiLIR0JgCvgUKXz+8BZ3FBpA2XUR/W3sem2/ZwhX2IAEBmS3N22PPjRZJbSHQdPJ
J0JS5oxEqQWBS3LteSRI5mJYj42Nis3QFiOjYDS0UY687hBoBtW2Y7otNNQnIg12fLBulwhdZLFC
AmjBEoBPPTGEWQGLCAPLYYO7Bl1gnBT9w6qekQcBKybs4HFVRRqffjHDOczJUkGLYakdn81h387Z
ukJQGVr1CFijC0SooaRdhT+LgdMLfD5NSYra5o6S3gI16GNtY6j6G7XBgPP8mdocbafwiphNHZNM
POakxqzKkSDOnMTJs9g3zJWEjnYMrvU1BSLBWiqBTpgoxXpJEvtXREp7+ZlNfCjgJx00lMMrzoZq
9i3KvNAKTY8KJ9L6Lhs+iT7F4PXn9GEV4WBVYauI0ognx0sYJ8ZWks9h+1eeBIrtb6fXnIDbtFJY
RwTse5cyHH0BSZEb2pQI/qrwOeEfw9dYWlAlhz8jJFeid5YD+DA+zQ9yjzgO3ilcfbV7a3lCzhzL
q0YVPEln0Vwo7j6si8V9IF4aF6kXD13rf0w7C99qdx34m6Szzlm6K73frNyfmp4yJyXohq43sJzC
BMsoNafWd6t+w71vXfmV3ap2R0iuZe+rxkM9aIaNX0XlaHVnG+Kmo2VNh/l5+42NnC/aLY6udit/
3HXe93b5xuKskjTO1POK88AWubmcuA9YjQtXGvfNnAMv4L7i4m3gvpzfiBglTZ+L+Gg7hZd7h/KY
UtWhxVt0CdS9R9zUOxLr0Kabim8VNRy8CPCjnlftjPcqHgnEhdusqGWwV2pWq7Lji91VLd7OMXX6
Jd9r8fi6/jk4mWHjMy64zkaiHPP3je3dyhUEP7vM6E0JwmCVysiS4dtVfJsuUudUk5+ly8D2MILZ
ERMTDFoegBzo/zjrsb/6S0SRZbCfcbM9jFNNvVy5aHmKGz9QYPiLNgoaqX2SusntvZ8Yri6oT2S3
H8aY5aa5TUasI34a5cmG/beYZurRNEnMrHlUtPXdIjBWfoPnyhkfGSjuE9Tm9x3wTOImRvpH494l
tjoyvIzSw9zF33Q6ITIx68u7aBjgb+POyFUNCmVuZHN0cmVhbQ0KZW5kb2JqDQozOSAwIG9iag0K
MTAyNA0KZW5kb2JqDQo0MCAwIG9iag0KPDwNCi9UeXBlIC9QYWdlDQovUGFyZW50IDMgMCBSDQov
TWVkaWFCb3hbMCAwIDg0MiA1OTVdDQovUmVzb3VyY2VzPDwNCi9Qcm9jU2V0IFsvUERGIC9UZXh0
XQ0KL0ZvbnQ8PA0KL0YxIDYgMCBSIC9GMiAxMCAwIFI+Pg0KPj4NCi9Db250ZW50cyAzOCAwIFIN
Cj4+DQplbmRvYmoNCjQxIDAgb2JqDQo8PA0KL0xlbmd0aCA0MiAwIFINCi9GaWx0ZXIgL0ZsYXRl
RGVjb2RlDQo+Pg0Kc3RyZWFtDQp4nN1WTW/aQBC9I/k/+LgrFWe/vT5VadU27SFSK6ocoAcD5iMB
QzAU9d93ZnadACGqyLFCcuzdmdk3b9/M5DHpyBR/m2nSqZOOE5k3qXV5pos0VyLtqlykmyrpTJLO
96TzmHQ+9JKrzzI1JhM67U0SmQr4QYy8yKRLjXeZMGnaWyZ9pgvveFfJPFPspuRdmVnWwIIymWdz
LjPJtvitRWbYir738BSsRqMcXtYbLm3mYBOcHRsuqmXDf/W+JZ96R4BUqtUpIGEQiZHgGACxgVKW
9+5PneUZZy1PnPvsFqDliEQpMA+QJKurkJBC6EAfK2ueg92WI2DK1mUFfirYJO8CaAjbszlXGOMB
SdCwXA5XO9wy7AqXJHiOg01Dq6Md/vUsspYfxzlLzevZ6Rwo9jG74Q4iqRhvoIS9jGatDUrnbTQf
OPfZV1LABInSkNMd0mzYDaG75h4p7t3xApj50krnKlyBbY01GGv2MYhIR+p2o1FVjYOlJPXZVmee
PRCrYXFx8IxmUzzJAYAQuaCnp6ej57sTtqCWYm6qoGKy4A7lAZesHRXUXVr/mxchMtVeEJaCAjBV
QyfulgS5HC5Iln8wEw9XB1aommq94KjScjSvKYdpUJ6OKW2DMD3bxzoMOgqis5GyKPElcV9xDRbH
up2eEcqZhhI5ON9QDqmC2Lqlymb5f85ULCkQYOGOcjKC6HAKxdKWlDtbUi+dwcsd+vahKiAgwBpS
Pl3COELAnlU1Ni1IakNoEayFvctwKpuZN8J8cu2z66bBFlSw5Rz4U6wmYvEyDL5sZ4Sw5KGbUt0q
tiajCtB7uNoG8Rd4JVBmYOQPM8RAgmYLupRhoCyr2Ek1tO8uyiNQEE/DZgzbFk5a0PpqxC1qKaBA
W5gI9fm2+0rOsrAo7yhVAkPwIfgaEkEpxsABm31GC3aG9EW9UeAyKpV0B4ehtJHA7SzkJNiAhaRW
myBXxe5xAWqCzn0iio7J2Tg0SnouhyTcAb9sDkirM+/fOAcOnPttL5+VcZzGnGflek06rup4derF
cP1JBj9un0cwCqqsx4EFDdMFd+ByFazv2nZx2hiojH+Hyg69IBR7eG/nfxP+IXDtwuSyISwltBoV
c95TtrpNqEUg8S4rvEPpgIs92MgAFw8crwLwgtUrqpz9+0MIfwGwFhqZDQplbmRzdHJlYW0NCmVu
ZG9iag0KNDIgMCBvYmoNCjg3Nw0KZW5kb2JqDQo0MyAwIG9iag0KPDwNCi9UeXBlIC9QYWdlDQov
UGFyZW50IDMgMCBSDQovTWVkaWFCb3hbMCAwIDg0MiA1OTVdDQovUmVzb3VyY2VzPDwNCi9Qcm9j
U2V0IFsvUERGIC9UZXh0XQ0KL0ZvbnQ8PA0KL0YxIDYgMCBSIC9GMiAxMCAwIFI+Pg0KPj4NCi9D
b250ZW50cyA0MSAwIFINCj4+DQplbmRvYmoNCjQ0IDAgb2JqDQo8PA0KL0xlbmd0aCA0NSAwIFIN
Ci9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQo+Pg0Kc3RyZWFtDQp4nNVWTW/TQBC9R/J/8HEtEbM7u16v
K1WVQPTAoRIoiEPg4KZOKUqcxEmK+u+ZDydNjENp4YIieW1n5+O9nXnjVTQwMf2a22hQRwOv0+Di
zOepLeIcdDyEXMdNFQ2m0eBDNFhFgzej6PWliZ1LtY1H08jEGn/ow+rUudgFn2oXx6N5NFa2CH6Y
mDRTd3g1ar5cJEOTFmpNi1XVTTIEcPhitaU3uaqaZGhx5wP+YRwaNomxaVDVOgm4bBpxNNnQ6hW7
86peJ19H76N3o6MkIbbQTVI7ys4ZtJIk1ReALBl97xqbHmNrOsZj9ZbTKde4aFUNKR1Q9ORUVdNa
MPRMbThfub9PjKbtAj4QeDIT7MDYIeDusiZ+LDE1ZXMko0DP5a3QNxezOskxzIasLLqd4CMIM6bd
sizREvCx6iXqNFab56kOLdZtzc5mjKEicJYOEsBj+Mm3sr7FyKY9VEppmiA8vUul6Qvtfg1tA7Lm
j0OXswQQ+OwPs3eAtRiOXXzitD9eMZFyQunzqsZaR93xsqo5MB6rD8LIlk4cMCuu9hwzkvrYk1rO
uLx+UL0EVSYmIOUPfL77PXi2fPQZ3rdMT6UU8Ci4sszOz2ElUkjrqZV6y+WO+Raa2v/qDlsoF8Zp
wgYF64XJUh/jiXsWjM9xvWeUqsEfkbIzRASwZ9QfM0oBPJBP8W+x+PE4EbXphjA9IVrTfYSxumwS
AOorUQ3uIq3m2EDIL3ZQy2m+27Bk+HJtX2EfOek5NDFqQ3WZC5mWhEg6P3F4vU8KdFp1y75Hb1t8
/Xp7SDNmaYRmT/X9r2kORWqzHc2BLP9blp9oZciylw+AA+MxWVtK2qkLTI+yxTeO+jlgytJxOAhg
3343lWh6flL2OyJwU2KH5tS2QCLwit4XeFcvNiK0QLSRAOyauawX9R37bp+l/UW4H4bPGwEA5lFE
28nG84QnEfrXu9R4nlGgPmCOp77ISe9RgTsKnvNnhAnYGf6Jc+pYFq5jSdqP4FRTn5Hc8lzSPJdg
fz2T75JrBMY3F7KU52Jx3T5PZDmXBQddCOSJBvUzQFH9hBeBerT8C1AdEF2oJ5Cc0BaDdRBOScvv
VePRdKyuMGHotjSXk8d8SS0W8yVXVUcipJnwe2TF1b09lJGjz4Wf/uJKmQ0KZW5kc3RyZWFtDQpl
bmRvYmoNCjQ1IDAgb2JqDQo4NjMNCmVuZG9iag0KNDYgMCBvYmoNCjw8DQovVHlwZSAvUGFnZQ0K
L1BhcmVudCAzIDAgUg0KL01lZGlhQm94WzAgMCA4NDIgNTk1XQ0KL1Jlc291cmNlczw8DQovUHJv
Y1NldCBbL1BERiAvVGV4dF0NCi9Gb250PDwNCi9GMSA2IDAgUiAvRjIgMTAgMCBSIC9GNCAyNyAw
IFI+Pg0KPj4NCi9Db250ZW50cyA0NCAwIFINCj4+DQplbmRvYmoNCjQ3IDAgb2JqDQo8PA0KL0xl
bmd0aCA0OCAwIFINCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQo+Pg0Kc3RyZWFtDQp4nNVWTW/TQBC9
R/J/2BPalRqzH856feAAiEpwQIBScQgc3MQpLU2cOm6l/HvmY524waVKbyhSnOzOzM57M/PWd8nI
CPw0V8lonYy8TkMmJj5PXSFyq8XY5lo0VTJaJqOvyeguGb2bJq/PjXBFWngxXSZGaPhADFukXmQB
XL0Q01Uyk64IamzSTPrx9UqZ1MpNrcY21XJbLeCHtelELtHEykZZk3pZssPVqlqrPM1li2YezBpl
LOxXW3waXDepk821smA+p7+5vFb4XeOfiVxv1c/pp+TD9FHmVjhIwD3KXGepzkRmIIGMUpc/rJ2o
6c2xsxlwdubIeSbPMQGPKReQXHnFuTIDhKsgXLDrJOABmwo3tSw70OiOYCZyvgVLp8FlUW1gxUAE
4g54ZqRGrvl/wBMNWFbKgT9HIYZsXHpQxkH88pZPD12A5RBTT4N1eZ7qEMFu4FBIhbNljGWjxg5Q
7TCvwExQXlsyjYfew6oH63mF2eRg9grts30wBhDx5x1/CwSksVEwdohWu001XG3g5ahPM00YoIGN
31fbD1b7b2cPTdj3ncnPxG/N6QC4y5tqjk0O+Z9x6hkUCIuMNs4yHRnVJIPVtonVRhdeeuD9ktvo
lnbOeBDggIZ/FcdRVzBTlshDe+THYRHancLdDfcZriK3b7hl7D7IYAM8hV+HtLAR/xIm10E5Y7bU
7Fri/Brs2vZ4CkFlOIotSGUcaI4XUFqSme9i/dzpNje4zqe/L9eIoJB1yxXQ8vIx0o7sBfVUpQK0
0hI5ChE7SZFD3i/VBDapa2k05yxGv+KIHnfYgHJGTP9Qzqc7sodroCMPtPnsQJtz/x1rz7HgJi8b
ys5xJr8QNEAQIPWahjEH7dmSxB7y3tY4WaCn+OgBOMJzgSqey7enwTBFwMeLkPR8B0sVJ414Dt0D
8ZHaoBAAArwiTW8uF1SOUnm6fLodhGg6DWhZSVzshfqeDybCArkFvjJY6Z5XsQI1f3GStBh49ehu
lr6Unsi+o2l8GfsH372476nfRBa7+x1oaLuRqZedVXVHU3PfN2YVZ37aXSfOsXhxVub8FvN7f72v
ObaN53Y3LcZY8SUbZIzVu1VoVhVcEZAJLWb41kEvE7FXTiuJRqVhPi44w2/8FvexH+cPJRUwGw0K
ZW5kc3RyZWFtDQplbmRvYmoNCjQ4IDAgb2JqDQo4NjMNCmVuZG9iag0KNDkgMCBvYmoNCjw8DQov
VHlwZSAvUGFnZQ0KL1BhcmVudCAzIDAgUg0KL01lZGlhQm94WzAgMCA4NDIgNTk1XQ0KL1Jlc291
cmNlczw8DQovUHJvY1NldCBbL1BERiAvVGV4dF0NCi9Gb250PDwNCi9GMSA2IDAgUiAvRjIgMTAg
MCBSPj4NCj4+DQovQ29udGVudHMgNDcgMCBSDQo+Pg0KZW5kb2JqDQo1MCAwIG9iag0KPDwNCi9M
ZW5ndGggNTEgMCBSDQovRmlsdGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KeJzNV0tv20YQ
vgvgf+Cp2AWsDfdBcnlsHj0UiYEGSnuQe6CltepAImXKSpp/n3ksRcmSaynIodBB4nCe33w7O3pI
RjrFT7dIRk0yKjLlXZoXpbJVWposHZsyS7uQjO6S0R/J6CEZvZ4kr37Tqa1UVaSTu0SnGXxAoI0y
YKu1skWaTlbJVNjKy7FWThRybIxRpXhdL0CSgWghdalyUbPCQnp4CPLvye/Ju8lLsbT2yrnUFXaI
dSPethjFqUI0+Etl4hEFBTjuJGRXiLDBb41yyFJ099JA7BmpWVWJTx/xhRbXmyu2dOJ2i6I9V9uG
BU0InPo8zPFHLm7kqfRNaiEVe5B+5lQG6QNUhaP0xY0xuZx8PlH7kbHVT4yn4k+ZZ5B26OTYKiO+
Qa4ArhNLiXm1XFSDyOMz1VZh4bIE7fh6BbpGrJcSAQpSO+XFv1y0FoAb6K/DjBF2mC/11AOqd9KU
oBykhYevKEVwa4AVcdrWmEUZc8HULHqEjmhAPNRzNADaiXtSeLwMQ1tAIT8I4WA7Fe8oV6g3BxAe
kSVQUINlVzGxLxJom0GVhICPkHDRWGkBEqLRDtE7foZatxIRYQQCqZUgZr8dcRPkS1JihxDMAmZ1
Ax0qiXu6gpcxsZYbmItP5OHj9WH4GxEUHbJSLNTVM0fqOUyswwnAoPQ94sxqyCWLpR5DggXHdN4z
bESzHJTnLRppMWZYeq8rgryVZq/eJSkeHSSYTLHfpqLRBB6MT6EPMHFwOv2VNi9SxVQQ6TmqYATr
lTZ9hNzhaMH8/ZMIJ8GLpn2Eqbgm0vdH70Q9oOt8H61C0M8N1lvuyhkf1WIyo+yuFldBm/y5/ne2
QzE8KOqmbe5pSsTnJTPZ4gRw1EtuMHbWH/Blw4OkAm42kb0WJugMBzJQhs9STePL0YwAf9VA70P0
TtxYsdDTN9Yee3yuyjyyhwfoz2aPh3skj+wBTrunEX4uezgasefcYBewh71H9pzp/3/PnhcGoMk9
fnHm4WFLA2k37vaGVMDZXPV7gR+uTINjbRbW0u0KuOIJWcVLtpawv1jx7TbEGXmEAUNT0sICbyNi
61jwpYuG0bnyP3hJDrZT8YYKP2df+G/gZoFXB9uLFrIY9hTaykxE7p8VLgwIzddX/c0LWGWDbX8P
X9Rl7TVeHVxWExbckOdvuM1pwKFHTxZTl5F7Z/EQ9IgXJxE/Ni7wzOzZTsWHLWCBmwNuCI8ITCnW
VDCLEEgLDYrCDusAIHFNI/Zs6I69J91G8qI9Nm7fAW5zX2TF9zxaxf0kE7/wDy/mDPGiwz7CinIx
HFnR7+mXwzHYTsWvm82WdovVWuJyHhFpGzz6nLlzwAn6U1GIW8q73eIZtRmYtbefaYWlPRNk2OIZ
eAIXq3U8mmTZ0bFj3DbtwQD+DlGKxn0NCmVuZHN0cmVhbQ0KZW5kb2JqDQo1MSAwIG9iag0KMTA1
OA0KZW5kb2JqDQo1MiAwIG9iag0KPDwNCi9UeXBlIC9QYWdlDQovUGFyZW50IDMgMCBSDQovTWVk
aWFCb3hbMCAwIDg0MiA1OTVdDQovUmVzb3VyY2VzPDwNCi9Qcm9jU2V0IFsvUERGIC9UZXh0XQ0K
L0ZvbnQ8PA0KL0YxIDYgMCBSIC9GMiAxMCAwIFI+Pg0KPj4NCi9Db250ZW50cyA1MCAwIFINCj4+
DQplbmRvYmoNCjUzIDAgb2JqDQo8PA0KL0xlbmd0aCA1NCAwIFINCi9GaWx0ZXIgL0ZsYXRlRGVj
b2RlDQo+Pg0Kc3RyZWFtDQp4nK1WS2/bOBC+G9B/0JEEtipfJqVTkaJdIAtsFtu66MHpQbGlWoUi
u1KaYv/9zkOUHTtBGqMwIIvkzHDmm29m9D2Z6RR//ddk1iUzr7LcpXMfMlukwaj0lQkq7atkViez
f5PZ92T2dpG8/lOnzmXKpos60amCn06NLjKfutxnyqXp4jZZis/ylc6U2FT4Pxe91DbLBayMzjMv
GqkzLQZYmgDHdxsWx3PjQTDKowTsb/HYi5a07qVWoFP1b+SXxV/J+8UD90xq1aFvWjn0yoE9a8g5
cW3MXC6+HWvqY02rjzSX4rLGCApwqURX5/DySaKHH65wbeHtVtL5f7BGA+JGTpGhIEWGa1wMFFgB
geHqXubTyTqauxbd9o5hObh0R0Z/0HOyOAo1ZKCjszU9eWclA5nA5x09t/21fBxDNPQgxdopBMOG
kBV7GP2jMJ4qewP8ONBdin84ox0xwsPbphwYojk5FzDnxjjId910hAbyqIxBQtAoWgGCOjOivZcF
iFb9CyhhbZG5cxixV1yKK4KWM4RvZUuIt9HPiR24O8T0ceKGivkP6dhM/BhKpsRtFRmw7abDa+BI
mDjSY3EUxDSysm3HnD+CwVOhqDAGsotcOmLQqqG/3RiWmW4/oc4j3cQUz3WTJ3JjoA2dlZu94lJ8
kHr+C6WGMJLgWCAdE++kcocdy4+I1AdQxZp9US0Ze2YhmakdXXAVIa+gHILYlT3u5OKOOWEElocX
NYdU4L7OnGC6YeFcXb7jjhbEuqIagnJrSCyIhour4xotgH64r6EjyTlc8vPJ7gFA+wd+BxoNRoFv
+TNpPVUu3JHyUvwtsfqbrxKbwkZqndkYcy6wX+BG0+OkCKJaSUs9jxKJgojJBk49BAO8wNMf0RZV
nRclA9nF9eXFFaldYF+fgx4ZN6JCPbhzkAXdgTKQBLRMI0Dx+LIj0SALgfIFWQA+IZoriMWIpm4q
anM5eLjG5gfe3BL+oytN9zJ+aQ+T1p1HsQPd38KyjzzfP+6nGjNpR308Grgpb1iupZ6G8EaqcefU
HAjBqvfDYIBqdvHWOBmkIw81Ir2i7wt72rOeg9C67NwqPdA9hZCbjAfXyvWaY+aiy6eiK1vmqyG8
gaow/ZAPbgoNp2RF3Qu/oSKkTc3YBQCtgGRUDB1oty1LbKUHqwQp1n28+MXgKHUmMqMifE5xymru
wA88VvDCS8Aqp6+CkWyH7KJPh7iB9Y5ta/1HnLMdYzmp/uRYNZc51rst4Kv1MO7/AQ1wVx8NCmVu
ZHN0cmVhbQ0KZW5kb2JqDQo1NCAwIG9iag0KOTQ4DQplbmRvYmoNCjU1IDAgb2JqDQo8PA0KL1R5
cGUgL1BhZ2UNCi9QYXJlbnQgMyAwIFINCi9NZWRpYUJveFswIDAgODQyIDU5NV0NCi9SZXNvdXJj
ZXM8PA0KL1Byb2NTZXQgWy9QREYgL1RleHRdDQovRm9udDw8DQovRjEgNiAwIFIgL0YyIDEwIDAg
Uj4+DQo+Pg0KL0NvbnRlbnRzIDUzIDAgUg0KPj4NCmVuZG9iag0KNTYgMCBvYmoNCjw8DQovTGVu
Z3RoIDU3IDAgUg0KL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0NCnic3VZba9swFH4P
+D/4UYZW08WW7UEZFDq2vW0L7CHbg5sorUfipHHarv9+5+JbEpfS7m0EYulI5/adI326CyY6xN/u
JphUwcQpmcVh4lJp8zA1Kjw3qQp3Ppgsg8nXYHIXTC6nwbuPOrS5zF04XQY6VPDTocmUNGGitbQu
DKfrYCY+L6NzY6xMxWOUSys8TjOYFtG5lrHYRdpIx2ID4tpXdRkZqcT1KtLSwMqv6Zfgavqi7ziR
qQtjZ3vntd+SmwzcGA1uiiiVidijzIoS7Kdig5NEVBCAzmG+xLnBuBJQaFbXHLUSNs84bjcWlgmt
GsakVSxVHMYKDBuKSfw0Jommv0cSOtS0+khzJr5hSAoAQXSKFQaMc0arrjGuXNxDUorhdDBY0JS3
LKEA+G96K5Cl7SYVre9RNaGNmnek8NkgAlbBaNs4MP3i3JNsG6HavqTJpqpfgZB1TiZvQmigORNX
fzigYs1gcKwripUjfj8eFGJlD6zHiqybrAvKjQZ1qumgnztFOADcL0suFx+DnAukYFB5v8AlB0vg
xHJrfgARKBUXcxhZGC0uPKzGIFYZ9GNRLbjC2akSbKWRQfVWCTvb392XD1hwC93jqzlqpeLpCBG4
AZrkTU5XgI4RYAgwcXQL/AirF3EzucLtz0CHLgilxkOck3GdHdl/Ft2B+Zn4VEQaG/cBgE16YPdw
1Ol0AwJSi0UzSkQNvcxXTgzw7bk8t2WFAy1uWB/Au97c01nARoJj77hKlm+shNCEIULo19xheIA0
WDwEdORybfIev1wHBchimeu2AFDbY4D+vQCZlUlfACv/zxK8BFZipTZvO+gD3Zm4pHB1BiFsKUYD
2SPvXBfXmBvcRU9tctWG6O3Z5B/L1YrPuD3aW875689azvL11jfCEokBDZEn4rBOe5RIn8sLQW/z
uom0ApO+8jtOow2BIoCWpuqcQwm0mEdZl3YF9TXIONBYjWjH9Lom7i0rSBcb54yzBg4pADeHLeJp
AA8C+Qoe0Wkus7fQSK84E98LZo+1Z3yB4KKWAxu5PqBL5hxsVsoj7dhGggJ+b2S3UK8GjLxteLOX
VDTGJrB2IGyUi2qz5xhuD1h4/IU0mmdsuzwXAxvMkexuzQy+x5PV+6BXHEhvCwKjOZcn23RvgHNp
tw921e0TY3/bvPuUuKPN99GhS8gU29jSi+JVeaq0y7M8eN2cRLtt3zn8EnL9G6YvBmXaMm2OTEs1
b9iVEnjDS4tb4YCA/wI7q3PWDQplbmRzdHJlYW0NCmVuZG9iag0KNTcgMCBvYmoNCjk0MQ0KZW5k
b2JqDQo1OCAwIG9iag0KPDwNCi9UeXBlIC9QYWdlDQovUGFyZW50IDMgMCBSDQovTWVkaWFCb3hb
MCAwIDg0MiA1OTVdDQovUmVzb3VyY2VzPDwNCi9Qcm9jU2V0IFsvUERGIC9UZXh0XQ0KL0ZvbnQ8
PA0KL0YxIDYgMCBSIC9GMiAxMCAwIFI+Pg0KPj4NCi9Db250ZW50cyA1NiAwIFINCj4+DQplbmRv
YmoNCjU5IDAgb2JqDQo8PA0KL0xlbmd0aCA2MCAwIFINCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQo+
Pg0Kc3RyZWFtDQp4nOVWTW/bMAy9B/B/8FECVk1flu3jBmzAdhi2IUMP6Q5OojReHTe1nXb99yMp
O82Hh669DgFiSSap9x5FynfRRMX4a66jSR1NnBSZjROXCpPHqZbxhU5l3Phosoom36LJXTR5P43e
flSxyUXu4ukqUrGEH8RItHDgq5QwLo6nm2jGPq34hdZGpOyB58Iwj9MMprWHoRKWLXFFw0q7W6xx
7IRkRfByrN0UFVdCsSq8AnvPE7C4h9WElfCfgnUK4w7jmX7pFicJq/nP6efow/Q56FpLoWPrzBPy
S9p2zRXGfsTdE8TjtwWGzljDtYKFYW8lYeIHLiu00WCj0KkHswncJTN5Fri7MXg6NlpIc6SstELa
2MpUZASPXQEcPv01Qu3M16hj3xn7ugNgGvGitobYAU3LivntDmTURgIHz5UFnr8D1K1fkiAl6e7r
BUliIQhAcYGZA94gpGFFSbZNxTWo8Di8vdtxVCWEWNy8jLxxkFf9SvYHzjP2jlBVhKJDITLmm5oQ
YzYlLgLaAPMeMyuZb5FEuhegXqB/znZLouTHuYDDSYlYSXBAJWv3XNwol3NnBzk79AUqG18TDoRh
AZumQ4/ja8wjAr5imMEUNzKwBgY7MtjyUH74X3AHQTr0T5/8oUzIzQa3Kw5Pq+kAk1oZ5h2MFOad
qq4JVQqh1qQhFoRBvVrcDXReBCwB6AofGVuciAddKFDVOXUhm2Uiy4C+kBl1osu4fk4lnTnsY0Gl
HsyJOnAwWBvw6X7V0yGHo49NyVhYmUOzScMJxvb1I8D/joJI9oUOUvsmGCeMOoPrY/Uh3Lk2o0HQ
OoEYt3XFDSw/nogy0qR7ecab9JOIaS50uhcxE0r/tyIOdO0R19RhTeoEKPRcQ8nkbNtgD5TQwHGT
eTGvqFViD6/DjSCZpneK/u3BeF62HNWBqnlRb9Bwfebudb3hwHcG0sDlo6AEMQUPQa6GhysSc3ha
7djN9XlpdxwODl5h2MMN2xQ3XOcUlxqiHqIN04qmvm3DPeIYaaixgyoDO3XNwTlahLu0h3IPnwj5
eC/9S9LwYV6QtbkPJoBFUaO/wJsfj7DaO1S7rgyjOlCQrFwN2X7or4Nw0Uu2LpbDN8uurspN2QEH
eh+6ch+/Kzc+fNLAt029/CeGOV17ysL3xcCwD1v3z57nNYF/DGvHx+0PfQkY6g0KZW5kc3RyZWFt
DQplbmRvYmoNCjYwIDAgb2JqDQo4OTANCmVuZG9iag0KNjEgMCBvYmoNCjw8DQovVHlwZSAvUGFn
ZQ0KL1BhcmVudCAzIDAgUg0KL01lZGlhQm94WzAgMCA4NDIgNTk1XQ0KL1Jlc291cmNlczw8DQov
UHJvY1NldCBbL1BERiAvVGV4dF0NCi9Gb250PDwNCi9GMSA2IDAgUiAvRjIgMTAgMCBSPj4NCj4+
DQovQ29udGVudHMgNTkgMCBSDQo+Pg0KZW5kb2JqDQo2MiAwIG9iag0KPDwNCi9MZW5ndGggNjMg
MCBSDQovRmlsdGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KeJztVk2P00AMvVfKf4jEZUba
DvOVyeSEFgECDkigShwKh26bbgttutu0FP49zzNJ+kF32Z64oEptx7HHfvaznfukp1L6rG+TXpX0
nBTeppnLhSnSXMu0r3OZrsukN016H5PefdJ7OUiev1GptUKadDBNVCrxwR3KiUyn1jshbZoOlsmQ
veNKGDblfa2NcGzHC6FZSUcnPBtzj+9RhbOR0BvdrrnSEJVBxYo8PFTCsgkJciHZcsUtzj+4kiJj
jZ6EC63gYEXajq15P4OjHVdKFGyEWw2OE/518D55PTgColOjT4FISwgsjF0Ewr5onfHBt1NjdcbY
qBPjIXuLLGg24soi5BC5jJErodgmQl7RucDzSTmeQz/Hn4i5YLtZyQ10oApwsxLwtCog2PEcN3RX
bavgaAIFPC5YTVfnrYdRRUk0IeULTvqLcwl5GJPJUQDfYJqGWLYbruFxG+rWlcOzbQ05IqsjBNVG
ugh8WEQ+4FyttrczOvl9nF0mvkPZs2rFTaglpBlsUAoTOfECIhkllp5qyBqQ5GWv+CxoXIbVaiJz
xLqbN+lSiKoL/qarTwPjLLtIwR05sDI4AMlcRy53TC40onIaz3URGjHLcuF9agw1JzXj57TqIPzp
IZjuHVAb9okY1IfKAwPxxLLV5opylUEwCwIwNAu9ReRp0GmUxbdV8UjrJKiWbRdCMudU+7qMiVe4
JjRhFducqK6Agv3kfRuqTNeVVUhmTbYFuwl3xnsW4Tv+3/yiO3NYLcvxbBRRVAfK9fIk66eZU5kV
Bj0OyRPzpnNYuI7lmlpxtY78co3ziH4XiaowxxyNqgi7BumPYzozYJvozg/YIwxgZ1N9SWH9L/6T
iu9QkH3x5b+s/l+2jEZTN0P18i1zYBx3rWx3rcIWuAtTq6wmzS+nWbWJyzaLq1LFQoFfjfl1mOcf
wgK6jjXU7BMHcRwrb8lEsnmsXrdcaOHOg91+3je3h8yF1R4Z5Nmr1XJEFxSsurpsJKvC70dyjGEZ
9t3dIiybKBrzPOxaeleIsUV5C7eO+BUVl14cukAvmt7KyYen9+MM25sOmxVFXL6LzFpTpvO2M2p6
bzHHTTOmeHF6aKU9EjO9gtnLg/Y0sA6MhwfBIqCuSZbNW07T/6TSBnsY6G/ZAjWcDQplbmRzdHJl
YW0NCmVuZG9iag0KNjMgMCBvYmoNCjg2NA0KZW5kb2JqDQo2NCAwIG9iag0KPDwNCi9UeXBlIC9Q
YWdlDQovUGFyZW50IDMgMCBSDQovTWVkaWFCb3hbMCAwIDg0MiA1OTVdDQovUmVzb3VyY2VzPDwN
Ci9Qcm9jU2V0IFsvUERGIC9UZXh0XQ0KL0ZvbnQ8PA0KL0YxIDYgMCBSIC9GMiAxMCAwIFI+Pg0K
Pj4NCi9Db250ZW50cyA2MiAwIFINCj4+DQplbmRvYmoNCjY1IDAgb2JqDQo8PA0KL0xlbmd0aCA2
NiAwIFINCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQo+Pg0Kc3RyZWFtDQp4nNVWyW7bMBC9G9A/6EgC
jUpStJZT0aJJkR4CtFGRg9uD4siyGllyZDuB/74zHJGWFXdJbkUAhqQ4w/feLPSDN5E+/nWlN2m8
SSSCRPvTKA7C1I+V8M9ULPyu8CYLb/LFmzx4kw+Z9/ZC+loHIvSzhSd9AX/gI5WB9nUSBUL7frby
ZuyGn8lAsGXOoyBmW36mFPhnFZeBZAtcRkHInngaKFbQMmFznsCYN2irWdPCfjAl4xAmedlxqeBE
UeAJxd7xH9ln7zw7wqf8UByBExphaZEGsTLo2Helpjz7ObaUY8tQjixn7H3NkdeqRQQp23CJSwMR
J/PCfO447ZqPeWVWjRlrrmDcEyUB1JX7dIebMUx2Zrm2yyey3y5xQ6NDnExhsuDm0ra75wi19+b8
OHAEo7kzfnIjIh47KR4EYhRcLVCFMAbFnXzRSfme20YqiAamM5ZRbJctxwBuMPSARpvQK4a7EVvB
GPfjrqnQQqLEaFgVGzSJYUpEQkofAcFoyOmW+CtW8ilkDfmsmpJUi+B7DI4xuVQCE3vKiCtBXN0n
ZgpzmcDW/oVKhWEQR6+U6mA7Y9dIOTkSxXGlzQWhTq06y2KF6qRACCpPIs9Hjitnd1sUDWkunYDk
a9eYxMGNnAoSsvWgaIhQ+jVomSKYjs7F7nosXXShDoBG2kGjIaYqNY0G/mHVYZu58Zu/yiOgIVh5
LumK84xK8QJpJZgXloiC0qlr22vqCqpEAO2i3pNIVsWdARvDiUeeDEWuthSBYETiRN/s6ZzumwPS
kGtEGvz+Z6z/1F0VqKD1a7rrwHLGrkwDa21/g/w8NMl8Q4zbhipXmELuT2Nju+WHHkhttjJjwTGV
kaQgksp009xYu87tmupm2K7LunfamxHAy4+4TscIS7K0bReqIwS8+1Efr3uAJ8T9nURQ4k6iWwdI
JuaVkGMYG/sGnUVwveV99DIUA3m2S1p1PEH6b2zt53X/7LS70j09m/7dWxX2BXuiIOxqd4N5ihbG
mG4AcwrXv1OWSXKg7J45i6IH/oL8lHoaqFfl58ASXq+lE/7y3JC6/mQ35s+EMFLn6/X44cdtABGS
lJRo7dbqPvxJMJR+uG8jZqJe7k8UxNRgMD5eIjv81HFk+8h294BV23CPam67dKXxzWD6ejU6uaZg
zYcofgEP8j0/DQplbmRzdHJlYW0NCmVuZG9iag0KNjYgMCBvYmoNCjg4MA0KZW5kb2JqDQo2NyAw
IG9iag0KPDwNCi9UeXBlIC9QYWdlDQovUGFyZW50IDMgMCBSDQovTWVkaWFCb3hbMCAwIDg0MiA1
OTVdDQovUmVzb3VyY2VzPDwNCi9Qcm9jU2V0IFsvUERGIC9UZXh0XQ0KL0ZvbnQ8PA0KL0YxIDYg
MCBSIC9GMiAxMCAwIFI+Pg0KPj4NCi9Db250ZW50cyA2NSAwIFINCj4+DQplbmRvYmoNCjYgMCBv
YmoNPDwNL1R5cGUgL0ZvbnQNL1N1YnR5cGUgL1RydWVUeXBlDS9OYW1lIC9GMQ0vQmFzZUZvbnQg
L1ZKQUFBUSsjNDMjNjEjNkMjNjkjNjIjNzIjNjkNL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcN
L0ZpcnN0Q2hhciAzMg0vTGFzdENoYXIgMjU1DS9XaWR0aHMgWw0yMjYgMzI2IDQwMSA0OTggNTA3
IDcxNSA2ODIgMjIxIDMwMyAzMDMgNDk4IDQ5OCAyNTAgMzA2IDI1MiAzODYgDTUwNyA1MDcgNTA3
IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDUwNyAyNjggMjY4IDQ5OCA0OTggNDk4IDQ2MyANODk0
IDU3OSA1NDQgNTMzIDYxNSA0ODggNDU5IDYzMSA2MjMgMjUyIDMxOSA1MjAgNDIwIDg1NSA2NDYg
NjYyIA01MTcgNjczIDU0MyA0NTkgNDg3IDY0MiA1NjcgODkwIDUxOSA0ODcgNDY4IDMwNyAzODYg
MzA3IDQ5OCA0OTggDTI5MSA0NzkgNTI1IDQyMyA1MjUgNDk4IDMwNSA0NzEgNTI1IDIzMCAyMzkg
NDU1IDIzMCA3OTkgNTI1IDUyNyANNTI1IDUyNSAzNDkgMzkxIDMzNSA1MjUgNDUyIDcxNSA0MzMg
NDUzIDM5NSAzMTQgNDYwIDMxNCA0OTggNTA3IA01MDcgNTA3IDI1MCA0OTggNDE4IDY5MCA0OTgg
NDk4IDM5NSAxMDM4IDQ1OSAzMzkgODY3IDUwNyA0NjggNTA3IA01MDcgMjUwIDI1MCA0MTggNDE4
IDQ5OCA0OTggOTA1IDQ1MCA3MDUgMzkxIDMzOSA4NTAgNTA3IDM5NSA0ODcgDTIyNiAzMjYgNDk4
IDUwNyA0OTggNTA3IDQ5OCA0OTggMzkzIDgzNCA0MDIgNTEyIDQ5OCAzMDYgNTA3IDM5NCANMzM5
IDQ5OCAzMzYgMzM0IDI5MiA1NTAgNTg2IDI1MiAzMDcgMjQ2IDQyMiA1MTIgNjM2IDY3MSA2NzUg
NDYzIA01NzkgNTc5IDU3OSA1NzkgNTc5IDU3OSA3NjMgNTMzIDQ4OCA0ODggNDg4IDQ4OCAyNTIg
MjUyIDI1MiAyNTIgDTYyNSA2NDYgNjYyIDY2MiA2NjIgNjYyIDY2MiA0OTggNjY0IDY0MiA2NDIg
NjQyIDY0MiA0ODcgNTE3IDUyNyANNDc5IDQ3OSA0NzkgNDc5IDQ3OSA0NzkgNzczIDQyMyA0OTgg
NDk4IDQ5OCA0OTggMjMwIDIzMCAyMzAgMjMwIA01MjUgNTI1IDUyNyA1MjcgNTI3IDUyNyA1Mjcg
NDk4IDUyOSA1MjUgNTI1IDUyNSA1MjUgNDUzIDUyNSA0NTMgXQ0vRm9udERlc2NyaXB0b3IgNjgg
MCBSPj4NZW5kb2JqDTY4IDAgb2JqDTw8DS9UeXBlIC9Gb250RGVzY3JpcHRvcg0vRm9udE5hbWUg
L1ZKQUFBUSsjNDMjNjEjNkMjNjkjNjIjNzIjNjkNL0ZsYWdzIDMyDS9Gb250QkJveCBbLTQ3NiAt
MTkzIDEyMTMgOTUyXQ0vU3RlbVYgODUNL0l0YWxpY0FuZ2xlIDANL0NhcEhlaWdodCA1MDANL0Fz
Y2VudCA5NTINL0Rlc2NlbnQgLTI2OA0vU3RlbUggODUNL0xlYWRpbmcgMjIwDS9BdmdXaWR0aCA1
MDMNL01heFdpZHRoIDE2ODkNL01pc3NpbmdXaWR0aCAxNjg5DS9Gb250RmlsZTIgNjkgMCBSDT4+
DWVuZG9iag02OSAwIG9iag08PA0vRmlsdGVyIC9GbGF0ZURlY29kZQ0vTGVuZ3RoIDcwIDAgUiAN
L0xlbmd0aDEgNTg1NjEgDT4+DXN0cmVhbQ0KeJzUvQl8U0XXPz5z782eNPveJDdJk7RN2yTdN9qU
7kCBLkALFFpK2ZcCZUeWgqwiIIuCyqqoqNCyFhEBxQUUxQ131EdUXEDBhbXpb+bmpi2L7/O8/8/n
/b+fNyX3zpy5d+6cM+d855w5NwogACAMzAckqMkrLy5cvNXuRZRfATBW9in3xB9prB8JQHgeotXU
ja9tmDHyCx2qPwUA/8u6aY0079A6AQCO+QBwhCMaRo5/0f/XYACilwMgMIwcN3PEOH3JTgAS0PVl
D42qrx1+TDysDIDF+BnJoxAhS/SiGNVHoHrEqPGNMwrnqdtRHd0vXzRuYl1tt09RC3gsDNWXjq+d
0SAhoAuA5zYgIj2hdnx9wsO9D6I6+mq+aZg4pREgRgA4zrQ3TK5v2PWz8mtUR+0RIkSDzB8+A2N3
dFYB5mNM9zYZk7mC6MVFi69JII/Y2mR0IZKdgNAn8gq4HHcYSRg4wFvLFbq5kIJNKQSktpZ7S70x
XSjh283zw0Em89cHDANTwEQwDtSDRvTNwn9ea5fOKJX/u/GzttZti4jyfRr2+Lo5pz565a+5W5vU
X3ubyJPoG7uVJCBByAqP6dd/vbKsIPfaF+OLJL6nvJKOoUIOGtSCFcwgyX4UV0kMzPGpvUpc4SvF
A+qnNNZPnkDn1jbU+1ReBSbzlKK8qZOH1U6YNnrcuHqfFPWGqEIlt2JU7fTGep/Ja8QEkVIVJNC5
9ZMbR48YXVfbOHriBJ/Fa8LNpFLDNleMHo+eUju+YfSEkXRujteslXgTfPHeRC/zGaiV+HA1IT4h
KS0pbaC3vMtg+5X7tF518Plh/esnjy4fPXJCDF08oS7O5/ZGBR9kCzUwj6LLQ88qr588bXRd/RT8
0CZo6yoVyAFkE5QCRBcSTRCC507vfeqdM/Qe4QPLXlgy9ff9va98fUJ6bGTt0R3Dwz8/cuN0wvOL
vMsq5z70xdivkjdLj73/64yr03fOnZh5bO0eyUuj/hy37vTRstjni7r9dfDj6qFGYstNz1jzU9d2
bNppeIv4dl6vsu/Can71h889LDmf/eb+r5ccHTprjC+O3LhA+Wwh/a5vimRA7JkZiQnrFRsVh8+P
8uz64btXlz8U/doK65IRRxdWDpg49VjmLueS6tMydeaWRT9XnBBOOBl4vcdXh3nyR21zvshyvW+e
8esW36krP9j0X5zcV5i7yTB0q3n1hSF/XZ5z5YHnh8FVf5WIzp+19X92/ZndS6ftvvyS5I8LJZ9t
vTVq625Vxr4lJ44QJFL8HQu+8C741JvI5SON5XB4EFKRXqc3IlT3wsW6UY2NDekez8S6KQ1x05Dc
pyC5x9VNHM/ojkkJYTvF93LRiYDAm4NpFirdm+pN3pq4NX6xl729bvK4O+72BHWlq6rk5sShqxhN
NTkosVcYGgXJ94ZhohQ/i0IWwEUjRHU5hTTzKb1XG9JvUimuKM9BipYa64tNSrjLKsgFC0CPsTd+
rnw1L9y3bOZG94ZjTS/Ac+G9zjQvr5zwNT9qx5C3Tq9V/kiVSX4rdHlAavOFU2t7b/rINkx9LTvF
2qfBN//KitQl+y5efBQE3uu3oXfEB8+5es/afag254/od3889dmQr464H8w68OSBz74d0P7K/tfn
/vWeePPvjwbcH2aUGY2prmvZPZANt3ubiB9ZO5b85P79o0+jluriOYIhm6YtvduO/0cs415z9KZ2
NccB/+FDPd7Y4EOd/+6huK1+8r81yb19I4u++nDUrEW6vBFTq+eebN1S52zvlvvEHHmqzNFvymdT
XaPbeh+mB38ovLHVGH2pX39r7afmLy68nDD2zd++2pFS/7BxrfhguXnwnBFJQznL8wPTen9dPn/7
AvrJ3UsHb+df+95747ItpVd34btfv2E5ea7fTwuyD5TtiNkFZ13dvmtlUmDLD9VjOFu6jf3u2Ibj
gXdqbvh/5G3N+2VB6YSno68eXC6LvLTqS+7WxX03ze7Bl3hNp2Wbx177qXI39Zx/497Ii6s0L2R+
Vz6x54dJTx6YONy0b0PMkW4/zvxl/Kwbmh+cL+75bWP5IX/M+taZuwIflT0f1Ti3+69p5u1jND9U
HYkY9SmYnytbMn8sa5KnvQve/P9okuIOkyS8wJsQNMYYb7Q3cqtza8Ri2z8ZY+OUKbF1tYz5aRjz
w138FxbIPf4fWWDi3RaIZ3nJjIbPe5dBetA3M081eU+2HdZvOLoGvHb0zJk3/gz7tP1GyfGEYV75
6381Gj965PzQJ2hly5z8V/qeWfjjfO3CZ1xrRyoLbp1ufSyHfOfx0kGcFfOenfiHsa8xIu7q6JXj
bNeOnNasvyRuPD5q+me/bBy25MSU1deXNc6yP7/jsdmPtlxbFTWpJG6qsSjn898PSOiKc9O3PtpU
N7pN8N7y36ceETz+2Q15P+em2vhXZhHNsxe/sv21FbaYGe8nTXv5kSmDbxz+oZdaaH/nwgcfJcYV
+9WZ0ppZEW88PeK3De81/JL145+SuV++P2fHtEmjTzzRp9CbZG3ZvscwLNP92cO7onmzP9XtGzz7
X08+PTGQuexFbxOlQBBwMwgBUnACrMjMXCp/P+vvul+/9neVGIUQoCFk2yKlLXdiw8zJo0eOaqQj
66JoX1paCl0yum7yxCkTRzTSuRMnN8T5zN7w4MXqO1smTg6u1VavJThNus72sokTG+mcqY2jJk4e
3TgTw0Naitfn83pTWHiI9/riE3xs9X9hRP92KSeOnmj4IeNqb2PklkdnDPH+vP25lY6h1wPre+04
FHhyO501p3T749tX1cSPfb/78JmXX5h2quLzq788sTh81ZZFI/a9PnbWMPs5U+Z5KXzk4oaTx2JH
bNo0yrnxbHrMMfGBSueJgh+FWakbYp6LTHv21+KF3b9bJD2yaVy/2hea5myriZ3e66eN+4dnbOob
7uNHqLY89+Mat+6Hbo/VqWoqOfVbTCllS64989s64g3jh8f65e9bNv9Y+q8V63rvbntm1vjG3nt0
72wQRFrBgNU1o1OO9FTwMvu3D7r11Aghf+cHC/oP+O1gxhDNgunU53+/snv++kDzmXnnnjFMHpx5
+uXf+Tts3n3cB0/to6crH/yaxY1nvQue9i7Yju0SUgs2eRc8Ol826GzDb6Mnb7aXzlXtLXm4/e1t
k///n7+mf6PjDCqsvyg6vvKPR3VJl1phxKfT5X8Mronfsln0dhZnzdJVp9J/sF79fcDamANbC98a
9tvtT97JyBj4XHLF6EDE+OxT7+w6z5nzlW9lty2yhjFHAoo+utHHb5/N/U4+kO7z87DZe3bp33Kn
OGJfqd+mWO6Q1u24VhF+w3rqnPqPshcm5Mbz2pq0178fOU5S+vfRK2VvHv3xpPc27RMsNa2PMpR8
bCKevjL/G3L/oD9bvnprwOX64jfLKg7uJyMV7avP/c5fNbf10defT4m5MOvCs9O/m7YVnB2TfeKD
5OXf5CieTRpjHPNF0rcfhVMXns2n3hqYkDqhJFwy7JBw+0MfflyRXXAmvN/Ohi8U6UvWTt3yzAdb
ESq8hpyDPaxjMEa0sc9xYHpe/vlJYtsI10uhIMH0vwUJ3mTkLyT6UhITfYnYgUcQH58cgoQFO+90
GZReeTDcEA6onTIKuQKN6DkyZglBwQavrH74+IkThodGJvynkf0Tm/Hoofewafdag2wYurYMr2ec
D+yN9GWCAvpeJJFgJOEzSPLaO/TKl79uz+p7edarH0U4/p72rrX9THT/3qefONS0N2lmLDj5LP/j
ulOHnv77pxMnzrU8tGE776b0YFPZpl+a3jgqe/3Z45fHLnq43Hik783hcNkJzUdNo4B/Rt5fitTe
t+pKv7nZ7fD3KS1f1/HsGZP8iYV/jt1d8Jdritn2dne9ufRg2aYPd5xVvqHPnsQdf3W9NW9o90vH
T20cTreeSLy9Pe+H2XtNntad5//c9vXjVmmg0pfTL3XunsofL/xaNdPx/LVojzw7dUZW93nPjLow
1zZK+0OPR07OyCsr3NZn0bK1jx8fOftnwa3F5AN/b5yU6X5mxGPvfB37LzdhkCYW1f+VqdhzZUm4
yVk28R2ke+SOJhiN5OG8nx9O/t+AFwVXwAbgaoQvBEkCiglRTWGUhlI5rrt7Vr81ueLF7//eGq3V
3Dpxo3yBV99xi4qgxGYhKAdTUbieC3K8IsbxYeKOAq+0w8HieEl06mKXDIzVfffNH5zW5p9FosT3
m3xZy4blf8x/5kZt/Vtx5M3Uopz3Dlx1Lfzwu9f7lz97QP/uOz9c2Xqj/8GidYUR3z9n+XLWR39r
Zim++GO18Vd+9b4HVx9+qPJI+DvrP1y/LuHPNefblz4+pGdx3zRnOm2sSLn9wGD12te+DH/499qy
zO95l0b8NvPXVe8OqKtfryveOuvr+kNfO3cH3lIcfGP7O28MXdHwx+kvnm+awPuyXn/42b8Xvyro
/tgV5wujZ7WccD/TPMLy9J4l/LGPKlubkzeaOTuUqTuOv+DNesn6iXfn6WGK8D0DVn5/ZZb8pSGZ
4pQra088srQ3NZAz+M33zj332bcPrJnhurV/wtOruAmVLUOi5VJvEycBQZkxCGPC2oLNbwMKAFB/
zw7F/xXI6MS+tMSExGQcLaUg3whVk3DV2/g/wgfbTv5D+791ic4s2JC6e/D2qye+Pn/2+fUrz2U+
aVnxWvXiuOrfWyb/9fwLS8cc+LzFNlv01ltP91wzxKb86cZf9icP/Dlh2u7fLj+V+ebJ41WDs5/f
NyXBuXPYgtqZ24b9OWHp+rMTvnpzywdPlcqn1b7UsLx+2wbNsmeqF5zNG/H9F/03+0/f/nJaRFye
F3x/7oHZ6+UfV5p2XOwjOrX0y+3nyjeOO113euOYTY8M6VUiv+j5cNCgIUPLdkyJffrIonzJQ3r1
tLf5n2/a2aC+WPLr6LbqvWNXXYoqTUld8UZBsXpd38ea/xz11CfnBZNGNm6e/pDpwbGP/vzj0Px3
vvlhkuT9OrB2tu+xh0X7lUf3nb185Wvr5edqai+n5HZ7LegSNcFHkEQevid26QSDy5+NfW5q+Zk+
l4299Vzzjieef29d2z8g33OYaqcWbPMu2Dz/viiyrfGp/w38u9dZ6BkM/PK83b3+rVlbMxendwn8
xof6YSK/hrGjMdXTMHni8Kl1jVM82ACw/iPdj2cCwj5dItFcb443uyMSJRYnsP1Onz79fv3WT763
w8b7xYSpn/22PvXxwY+pqismjP6aeOvHfbc+fLXkRc/z8yokn8cfvD7mB8ktq2F61tOjZu1fP3f5
4Ku5Jxc+Xv/A0r6lc5pUfy2c8sn2VwafJhredY7TvlymenrZ8UMXtr2zbeqTayZ1Mx7vD/ofuL7I
+fmQhFvnHLOGbPp8560/r+YYXuhX8GLRl2tSlZWC4it/+JZYXqYeHqSoJ38SlZ7dJl6+8ehnJ549
y1c7rAcODlgW/v6gxUlPn27bteTX51KyD+WO/Y6+kv/y3N0/Xem3d1vRy/WvlCd+duoit47izpjQ
t73oyOM/5w5c8sWLwvl/Vb0ec+H7eYN6fB8/87LtwUfEsfv6DnrjVX9l5fMfnPnOc+LMr+O3pMz0
NVGnEGy+TkDoXXDg/ww43gHwndvYWxf84FV1LKiR0McjOcwuPF5m2akXkD5x151zNPTOmsgX5u3a
qvbaO2+kfMhu34F/fVXW61j2XKs/2ZNxsOCB5j/qvQ1dbhH7hnlrtibPT0RreC0YB0aj1XwyOtKg
AEwEE0AjmILK/UE9ok5BdEyjgQ/EAS+I3+acH/GPmt04s2HiyMm1DaNm3u1LUk0Q7NxW9Hp0glfe
97U9A4cOjVzQXnXw+idvLd8z9MyH+2/1nzYCrqBvuKsffWF4amNhXe8x8/6a8Evu9bUHH3i40dvw
WTZx5NNXP9fQ75T80GJNV99cbzV8J8hZ9sUH2W8X9V7EVR1d/MODjQW7alQjbC+OG/VGovay+fvb
Dd30GS+efOPC/Jf7/rjq2+vlZ+Zd/+DnNVOfHlWZ9ur362WiHcfSvoqC5z9r/3KIKszrWp6Vt9jz
ae9lXxkCFw1vrDh8+K+Us3/c/H1Rtph7ZFedcrq7X678qa+m9E4kEx9p+GTXy5Gfkz8cMJ14WXOt
W9Yps275p6f9xy488dJVTUr+gaORE34fnNK96nPbZw+pwKtX9hUe2taEnKImeKtzvri+JvgrIl3E
yj3yf2RL8z4bqWIuPzgAAmHM1iqvrqvmiToTOxApXkcLxydlVvs0n8+X5otPTBqI0LeL4iko2Ub9
ekvCG3uvbV53NqvXLxWP3UcFdD1y4183rnctiTrUXT1kSV9L/tNrF0698MqObdMLXi+b1HP7mdWu
5U/P+aPieefHI+eNlN749m+9v+jLc7e2vPDxg875orLd1R9f31mx7GN/xabnZScEewe88/nVPW/v
OjVu4ew5L3nfenXZeWPRu7t7LVh0sXHlF5XODasXjHmudvNXpoWB2/1kqp1J3ZLzIltz33xf9ET6
e4lXvbHTTeEFJ9+znhmR4TV03/Tw7ov2n36tLV6/pKntD90f46/3T239wVE5/sJbPtGTGccqbvE/
fPjN5vLoWyPXJPdc8k3rEXLzxZIpOtPIl/mzjx7dP/gzU4JB/uRzP59bc+u6uz2yv+23TOfIEV+O
+GX9nrMpEW3NR5GhkxQPrgYcwOds5CQAAM3BM3kWLCYAHxBSDkEQaC2mtgLiNz+gZwP2U1JO0wAR
blFcEADwJG8z4aQB2ILbyEOcMJzFY6CEYLJ2OF9H4hJhBlxCCIKJPAju/EB0NcGUCPBff4J3kmQP
8lHyEPkslUY+Rm4g55LzyIepbmQ/cjJZSY4jfyUvkZfJ38jfySvkVfIP8k/yL3IA2Z/Ko3KofLKE
fBwhohwogA6EAydwgRjgAekgE2SBPJAPeoIBoAoMBEPAcDAKYU8jmAlmgXnkfLKBXECuI2fBS5CA
UiiDBmiGkbAvHAir4Wg4Dk6EU+E0+ABcBlfAh+BquAkegMfhCfgGfBO+QzaRE8iF5Ho0fgEQAy0w
gyLQF4xHeEhCDlJ0LhRCNaShBVqhHQ6FQ2ANHAZnwnlwLpwPm+ACeAgehK3wJXIVuYPcRb5AriFn
k4/Ax8it5GZyG7xK8KjuQAoqqF5UAVVIFZF7qDKqhKqgyokVVG94Fr5PlUIJXEz2JntSxVQf8kUq
l+pLjiJHk1VolpA2gD6gP1xKNpLTyCHkUHIgOYjyU/3g22AuFUnuJIeT9TAOFpKryTnkMLKOSgc8
YAFcYAUmhMzxIBFhcwnojTjsBcaAsWA0HAGvIUWSEAoigtAS0YSFiIG3AcV9BV0zB+kRB0l9LuLw
EdhOGIk3iVPEVyRF8kkxqSDVZCSZR05Fs7ucfIjcRr5LDaXqqKnUGvOD5j9oGa2mDbSZttFO2kun
093oPLqBfph+wcqxKq1aK221WZ3WOOtQ60YbYePapDaFzWAz29y2IluNrd5x+hbV3s5o61b09JuE
jngDPf1TEpBcUsg83Yme3oievgg9/WFyBwWoYdRkarV5vvkqerqS1tHhNM08PY19eiP7dE3H08ut
q9mny236jqcPR08HzNMBYQwqdnteSMXbTYFf0bGqPa7dDkCg9W4T+G5YRynhgvA793fK7y58txiA
f938V/N3qejc9K95iBqOr/hXz3/1+BfT87/i/mX/9ta3//r2u/MrGDuaA9G1xJ9EgKQwHJBhpIY0
MMZlCPZO6tDXRhaRm6nB1BBqODWCagCAaqAaqRnUnK4johrZ8/YOyhPUfrZ0nHr1jmtb/8/bL0n2
ZKzvKXIPOZFcQ/DIzfAsOYoqRqPfSkiQphSQ18kb8CpVRj5CziGiyWvwfXI0FUNFU/Fkb6TzXGQ3
fAYFpAgHTAgJLMiGvKwNGREu9GLsqA/oS2WDCuT9YGsajyymEj6G0IJCeMFFiCFE1qxGeEEziDEE
YQZGDBPCDGxT8xFiNFF+uBihxiGMG/AUXI5sWQj5QAQFIAyKgRLKgQoqgAaqgBoqgR4agQGGAxuM
AHboABHQCRzQBWhoA5GwFETBMhANy4EbVoBYOAjEwcEgAdaCJFgHkuFwkArrQQocAdLgSJABx4Ju
cDycALJhA8iBk4EfTgK5sBF0h1NAAZwOiuEsUAhnwNmgB5wDSuFCUAYXgXL4IEYhMAiuBNVwFRgM
HwZD4RpQAx8Bw+A6UAvXghHwCVAPHwcj4ZNgHDwMJsAjYCJ8GTTAo2ASfAVMhsfAdHgSPABPg7lg
PjwDmuB7YAF8F24EEigCMhgG+sEloA6ux33Ba/A2i1ExCK8s8Hf4F8IEDiEj1EQkISIMhA0hVBzh
JmKJTcQThI/YTCQTaUQm0YPoSzQRXiKeSCASiSQihUgl0okMIovIJvxEDtGdyCXyiQKikCgiiole
RAnRm+hDdCN6ElOImcQcYj6xlphMNBLTiOnEDGIWMZt4gJhHLCQWEQ8Si4klxDJiBfEQ8TCxklhF
rCbWERuIR4nHiAXEI8RyYg2xkXiBeJH4mHiW+IB4ldhH7CcOEIeJl4lzxCFiL/E6cZp4inia2Ek8
Q+winid2E3uIZqKFOEi0Ei8RR4ijxDHiOHGCeI04ibD3LYR/bxPvEGeId4n3iLPE+8SHxEcIiSWk
lJSRKoQPetJAGslw0kraSQfCx0gymowhY0kP6SMTySQymUwl08h0MoPMJLuRWaSfzCG1pI7sTsrJ
bDKONJMWkiYjSBeZi5DFRMaTKcQnZB7xChlFvEEmEM+RCjAVvgqmwdfADPg6mA3fYtaiGXglQisO
XpPq0Oq3Gq17N8lb5G2yjQyQ7QiZIYW8FYqC31AcikvxKD4loISUiBJTEiqMklIySk4pKCV5kNxC
uSkvFUv5qAQqiYqjkikPlUilUKlUFNWfqqQGUFUI7YZSg6iBCPeq0eqZRc6h+kA3XvlgKuwJAG8z
wuW1d4ByX2ShU8B89LcYrARrwTHwBYpnFqLSRrAV7ATPgWZwApwCn/wb/+a/9QnM5IwHYvIQwhMl
WjFutl8K7ETfVuSFdVLWopqSojsp7bL2y3fRLgfWtssCrVwFEDL3SogPEPUP2NZ+k8jG9fZkXCeW
oLKUueMKb3NgT+CZu2RQilB3EBgMqkENiumGMfgbxK5xCL0mMLUJqG0kOo5AtaHoqjp0FS53XjUR
NKDvZITbU8E09NfARIDBGm6bxNSngunobwaD7bMRMj7AHqczlDmoZRZTn4G+c8E8NDMLQBNTCp2D
lIVgEXgQzdoSsBQs+y9ryzpKy8EK8BCa54fBqn8sr7yjthr9rQGPIH1YB9aDDeAxpBePgyfuoj7K
0DeBzcif3sm0rUeULUwJt74M3gAHwG6wBxxkZFmHpBaUSEguIxgZNiAZzEEcLuwy4qD8pndIay7i
HfO2nOV0BqI3dbljGitHfOVCdGWwl+A84F4euEsSqxEPwXInR8Haeob/TmpXqfxX1JA8nugimceZ
Gi7dTf2n8gbwJLLAbeiIpYpL21E5WNrClLvSN3dcu5Wp7wBPgafRXDzDlELnIGUnKj8DnkW2vQs8
D15Af53lrqXgeTd4kZm5ZtAC9oJ9YD+ayYPgEGhl6P9V2/3o+1j63g7KYfASOII05BVwHCHNq+gv
RDmKaMdY6kmGFqy/Cl5DdXxVsPYGeBMh1GnwNngHvAdeR7V3meNbqHYWfAA+BJ9ACSq9D35CxzZw
1l84fOiQ6sGDBlZV9qsoLyvt26d3Sa+ePYqLCgvy83K75/izs7plZqSnpaYkJ3niYmMinY4Iu82i
U8llUolIKODzuByctQEx+faCGrrZWdNMOe1FRbG4bq9FhNouhJpmGpEK7rymma5hLqPvvNKPrhxx
15X+4JX+jiuhjM4EmbExdL6dbj6TZ6db4cDSSlRemWevopsvMeUSpkw5mYoEVaxWdAedrxuVRzfD
Gjq/uWDaqOX5NXmovxaRMNeeWy+MjQEtQhEqilCpOdLe0AIjsyBTICLz01tQhC3Bj20mHfm1w5v7
llbm5xmt1iqGBnKZvpq5uc08pi96NB4zWEG3xBxf/lCrDAyrcYuH24fXDq5sJmvRTcvJ/OXLlzTL
3c1R9rzmqFkXdIjl+uYYe15+s9uOOutZ1vEA2MxxyOz08r8AGrz90q93UmpZCtch+wvgImaxQ0yo
PVQGaGxohIg/qxWPZUWrHwxDleb5pZXBOg2GGfcCv8dd1UzU4JbjoRZ1P9wyP9TScXuN3YqnKr+G
/TdtlK55/jA6NgZJn/nnQP9QO91MOmuG1Y3C59r65fa8vKDcKiqb/Xmo4K9lec1v8XrQ9bU1iInR
WAyllc0ee0Ozyt49eAEi0HgORpdXMrewtzWrcptBTR17V7MnPw+Pi85fXpMXHCDuy15aeRgktH/T
kkgb9yUgr70Kj6NZk4smxZm/vHL4iGZLjXE40s8RdKXR2uyvQuKrslfWV+FZssuao75Bj7MyT2Tu
QrzddXXoYsw5z8GnKwkjWYVnCxHoAnSwd89EDTI0XUwVz2j3TLoSufChy9BT2Ctw6Y5+UIV05Bbh
JhLfmltktFZZg5//YkhGdkwcRzO/S18yROgYU/A5/zi04NV4QFF0fn1elwHe0SmHHSDb2/3HSWBZ
sA9Gd/DxdBaFmkgHslxEI1A3DAnPoo5uBn3pSnu9vcqOdMjftxLzhmXNzG/PcnvP0oGVzGyzWlJx
Ry3YnhqsNQMrag5ViFykgwVuY2hamXohU++oFt3VXBxqppfz7T3Ll+PO7WyHgEYWhJjmOotrV6Qq
EpFpFiB0sxfU2mkZXbC8trV9/rDlLX7/8ob8mlHpuA978fDl9vLKTCMz1rLKB4yz8KMUoCfsWdE9
NgZhT/cWO1xa2uKHS8sHVh6WAUAvrajcS0Ait6Z7VUsEaqs8TAPgZ6gEpmIirtC4gnsqQxU+c73x
sB+A+UwrxRCYel0rBAyNH6JBUNdKBGmyEI1ANCpI8zM0/EGTpBuFRIzgNp8ejqdnTtWo5TVV2LiA
Bk0l+geboT0LNBP2rBZIcMXNQnt992aRvTumZ2N6dpDOxXQeUgyogUg4GJOW19gRTiGFqgRGGFRF
EndJt7a3V1RazxgvVVmRqg1G34GVzQI3wn6Oowe6rhB/axC5sHl+XS0eB+hXie/lOYrrqpDahjpE
lxQ3C1APArYHdEUBcw9WR3RTHZobNIHM/fNRpXl+VXOVGz+0cnQVo86yZlBkT0fTHuyT48QP8lQt
V9jjGdtEpiB0LMEnARobKK8MUoyoih5WFRQST4xGXmdHTXU1NJI2BerKkaoHsVRoDFLqESRSznrm
KzSyjQCzRTpEEmGzIA51iP7hsigOmyTHwauqCg6eqS1hL0DPljWL0IicXUTJ3oCkg5qK8VjQvyVo
qPjSE7ib0lZQZp+BkAUPmumJh5qbJY7iWgT+wftFiGJPDd3MxxghYvs4GaTyMOdiJHfSUdHa/ox9
prXLJzbGjhcHrJjAeBgpNqhafjeheZA7NoZ/N1XCkJcv50vuf0NQXnxJxxkT6Xy0agAOis6mkB+g
aIoEPJDG7OYMehlIYBnQgHR44IA6L48fy3sF5iIzoGEF4AMIc/1SipAcMhiy7YeSuCtJeXErjN2f
zVtJECC77Xzbu56285cUaZ5L0PPVt+e/lV15V57mSfj2o299Xii3ypmvKozg8VRcuy2OSHI5kxMS
4rOIpESn3RZGMLTE5JQsMiHeTJCqECWLwHVIfnB7INmnjUvMtWf3T+CYDVKVhMshwnWK2EyHrHyQ
IzPOxCN5XJLD50WmdLf1HJdv+5wnN6k1JgWfrzBp1CY5r+0LTtjNq5ywW7nUuFvrSG7G4OwI8jEh
n6C43FazTh+dYS3uL1XKKJFSJtfweQq5ODJvcNtidTjuI1ytDvbVVoLEYm+/Sc3lqIANOMGTh0FE
+8X9YhnsZW9lC87W9t/3i1BBFCoIUcFvwCWHDB8lzFHMHP2R0IGbY0SwJMLudPwpFol1NpNdKIEa
SgzEMjGxx37M/p6dtIvtYoWpTNGP0w9kZ2cr0tI8nupquTZNjoryBNmleHkCkri72s18gNvt0Gi4
jMhdpJUMI+02pzM5BQblrOXZSSs1lQ9lDovFoRRQE9t+GEMKlfZwk0MK+XAvJdG7zHS0IYyaDb+G
r3bTGMMokicWwIzAKYFEQHHCjBpqryiMT5J8qWhl22z8g6kXAKAg0i4zcINU8JbfYNHJYIlFJsUH
CTroxOhAI14trUScP9Kg9qN2tR+1q9WiGHxxDL44Bl8cgy+OwRfHvETEo/j++AFUBs4EJOl96Ep0
/n2flD1LmPPf+8TM+eI+ET4TMr9kq+i4iBAZXH/6fLyIVijYKytNbIWiFl4FyL6UzehtGvRUf8sI
Lf4jd7CAyG53WrCMhKoKo+xWmzNJnpicYEXSU2N9NpMwMY6w2+VYmZWdRQpaUvvUTSoO7NZGRWmh
s3FdXbzGnROdNDg/MtBmSB3YY+/J3LJkfW9H4djSd29mVOY64ZRuI8uyotUWF9XkssRUzCqJqyhM
VQiTyiYQ0NMrKTxQbc/o0/ZVemWmJZAanlKGVq7a9t8pMceMrHjYvnCQ4Wal4malgs6/Yqmg82Us
FTcrFfcrRAIIAzroAVbghDF7leXUERgNkoAXxrUI+iOT/ugS/kJPkH3ZuZM+r0MVxu1illw1a6bY
gNUqM4H5xmpFiQkOX+UfOrt47turSso3vD8vdczAAiOfQ1J8ET8svs+kPv1XDk9Jqls9qGRKaaKU
J+SSh2Q6RZgqymWseOrKk9tu7xmspqONYUqDQhWuFLg8rvzFJ+bMPjovx+lxcuVmZIFYy1YhLVMA
C5juN2VboRJrjhJrjlKFeFYqEMNKHeJWeQRrDjAEZWNgZWNgNcbAaoyBlY3hCCEHAiQb8d6wUmMr
dLZwgloSksVHIY2oxoh2h0rwuijAqv5P/74zcJmZfsezF58sPZA4cdfiPS1zdk1OIzY9e+vpsuBE
D9hxcePoA4t63JZnzT+Bsx+IM3IO4iwGTGsxuNgZdbGjdrGjdrGjdrGjdrUScr9AoKSVNBq8oRXy
/ZL5TnjcCc86odPJ1bcifiSlLnRq4XZoffWkyYgtDwMjMlb7mXkm7tF0u1V+V5GcQwkl/La1mENi
BF/C53DQIcCFe/kIGigBKvcmIF8ipAoVRgU/yC1fYVQpjHJ+YIxAFq5UGGS8gI8vNzJ8t98kKxDf
LjC4hadk+VayfCtZvpUs30qWbyXi+4DEBMwmHmJtn1Kp57bCyH22Uj0GSHZF8pyUp3VwB+9hJrTa
hNglKxBjvACSHg8Nnin7+SraoLOp+IjVAoZ6UhmOuCjiyYxqpVEuaPueJ+FxOOhA7cZcmjBHg9ov
UzM4NMgG2/2m8HCpDmuoDmuoDmObTijGJcSFDs+eBBxzQdrld9W4SJeU5V/K8i9lLVnKWrKU5V/a
SsTv9yTCRF0rFO632dI8WUegEK3xQhi1N61c1QpjWjz98Xwja5YHxcHi3EfV1Sc7gI6Vyx3WnJwi
x1qArZ2RlhwjYKf9U9QMii/miVOHLBw4dte07PxZz9Vnzk4KfCSXUwK0Rjwu0iiEivTBw4b7Nvy6
o3/1c5dW92iqzzcIqSFKk5LvjHP2Xv7KxDnHF+WZTHCmLQKJkc+XhSsCSoPTZNOJq1/4fd2mm821
BnuUwRbUD6ovWnM9oHV/tg/axayIxKyIxKyKiFkVEbMiEmPhhmsjRFj6Iix9EZa+CEtfhPFBhNcI
LfCr0cLiV+KDTA57AT9qB9rW9uP7UAM+H0Rt2ugytIDE+KXHxfCsGIrvXI2RQV3KhmjV+AiLlVW5
TsOqdnSoWletC6KmGtFCRaovX2XVGWgVv20fKumx5vFVNp3equITJYwuopIBSR+pnJhPZLW9GipT
n4dKbTcJbqjM2hesRPJTg76HsrV9tHu0JGBFCFgRAlaEgBUhYEUIXkKYKGw/fghJQigrY9hFbHYA
oeMeZmBlaNwCtVWr7zrazhHiUfHaL8MLaFSRoBK5r/+N4ZjQcOSwxBRmLxMcgfFAiSA7roXDrl3I
6N1dVm48Om7InWT8zs6RXgjPm1gWnhJnE/E4BIlWKL7eHmexeWlZkAWlABaUzB/oE0jlYrFcr9Ag
X1KqkMrjSnPIzZgfbAUsfl1HnCSAYX65D5u1F2uXB5esQlbSQpY1IcuakGVNyLImxMoqVrvKrEKZ
sUzW6edlh5YfpEfoGJS40+mC91Ek1r1Tq7g8CDUa8jpPZTPaYzS8QMTd2gRPc2Vaq8FAK3kSRaAc
vivnhWMo58qExJK2mR2g1qlVJ4hsgZhHcRBBYtC2tbdtMijZVasn4t4Aig4DdZBZNcusmmVWzTKr
ZplVI2b3A4G0TN0K3eyyBD1nQvPWZR3qMBEMzz3R2iJoO6mN6mDiLHZGe6qMSgFaZXaHhnprm0Ae
zmo+141Wlkzwgl9Wk9WQRUi8Xq3HI4zT6Qyt/6FbgCfGHOETi4UYR4QYR4QYR4QYR4R4poVYLZGH
6tdjHY1ILhXptBKPzhfHtUSWWvqFYCJbgdz1BMRoyM9EPrusoyRP6+ZJSMBefBerskPsuSMfHtrv
WK0YJx4m4Plm5MN181UWvdaq5BOBBFKkNqnUZpWICBRChBl6HZrkGOMo2huhE8DpHLhYZLA49eOl
RqW40zhH3lrHE/JICjllKEza2EHfGR0hNkQabw8gd5qj9SKB0qRmMXkuRw66gQf3uaRSFStM5ixl
zxLm/DsWpooVpooRplkYFxePhRmvk+IDujBeJsYldEk8vkQGzKllwjipi9LjFR1rCCM+LLx7ZOdJ
YFUmKClkG3aNRn0feZlJbYKzi1ZRcyVqgyTF4LLb1YFRdE44QRB8pUWnsyj4MYYyk8tiksN0U3K8
TweRQ6O06DW0gl+oQnGhyBTvIr5JeyCjaEOP2390WMuuSJtQG2Vpeyuxrqba0+f5PsQrKGpCPhEC
Cry31H6JusixIshygTl+gwrLQIUVSoUdVxV2XFW6oJgS/AIaeJn/ooaZFa6Z1VQz6xKYWZfAzArX
fAQ590KgRw6AtNyOLYvT/04HtvouZOwItBn/tYs3T13ssfb8ukc+XpHXY935das+Wpl/wDXosYaG
x4ZGOQc+OnnSpiGRxIYnb7cMHbDz760bb+4Z2v/pP56bcHRF74qHjoycfHxFScWql7GvjpDxTWR/
4SAKzGiJ4LKMcFlGuKzJcVmT47KMcLEKaOUmLB4TFo9JJpbAXiYcDZqQ37MXyB3I69nH5YoRm6J9
6lJxF6cvqCCyO/0++93OHtXFZSff9E9/ccZagdKqx6gSbYDq6JLR43tFHcgYUB2z5fHeIwsiyLW1
T0zIDMR12AWaap42e/DMAX3GJIa13YgsrAvOcA5nCZphF8gAD/tNQqsiEnMRibmIxJMciSc5Ek9y
JOLELwR0uDd8fjgZHs8KJ54VTjw7y/HsLMezwkH2kbBfYRVKYlth1H5tuYNKwVMtwVP90RkshLTO
+e7w89J8Xg4rARe3azDHRrMceJcGIC6EYq6qqnFRlm9DXUgTVny4qkgZlRVdPKEoUsUPvHC3UkzW
WuRca/bATHNM/53Xtm66gTXj6pOl6xY1xGbm2qRKO/HNhJdX9C5f+dKoycceQmpyFAT1hBIhPUkG
eWCN3yyLk6fwEaspWGopzNynYCmmYLGlIP4PReGdg6hsOZYVKslZmclZhZKzCiVnZSZHCrU3PE6G
oqODDX7o92u7Ib05YC3VstDMxESXOgTXZScgjcUWZiMljrxHkTRaM8luCGiVGg1MdLqczlAoKOKq
IswGq0pETVfHZlVkTAmpGAoNlb4cQ88pvV327oPT6MTYSFVjGD/QltdXn52w5tm8uu4WBM3IxRAg
YPQlDsi2t33WoXoo0OCQktT+E3NzRvZJV4W5M3v7At9FmMgHe43W8riBXtaMvgijC9svkXVIF4vB
j4dBTvvF/VIZ7JXDiiiHFV0Oi9A5rKhyWokYvzver1TBXvF+5GdFxEfEi406fK8RL3tGmQwf0C1G
PB3GlwgfXvv2GRk37fg+PXtWBc8HpdilFscdgS6QgoITp18kp1Ngil8khr3Q/Bz3C3EpRZ4i12Si
SO5AjpETVa5Bus2iF5qCS3Icp7rd1bJLMmzgnT62IthwF6xRdzh8iR0O4N0bF1yyLnf6tuqciQMy
tCLkzPHDEvpO6pFanRsRXzZ6wqiyhIzRayrcA0oylVyKILkinsiTV52e3DfREF8+ZsKY8gQ4dtDD
dfEa2qZzWDQmBc8WaTen9E1I6Z3hS8iqmNSndF7/WKneohTJdUpFuFIQbjeZvN0dyb0z4xO6lU9C
cyRFCPkJ0nwbqD+k8+PYUI6lth87v/8xXGL3Q95+/ADWfK4Ch8EmFhHjkbN+hRHO627ZSXdHENwZ
joSQgHGwPmGC93UhXxGV2OCeXMSE9kzse2tzhyIO48vDlcrg9ij2t3ah9W0m8gXdYKPfVBMLaWy1
NLZiGqsOjT0mGmsNjSMvedfIC2ka0LAMa1iGNSzDGpZhDcuw5iVChqMSHJ8JsQoJUBdCZ5mszNip
N0w4xuKgu1NFquG9brPq7tCAmpk/v3Xq2Oa5ecHwX8mPKZ9a3HNqqZsRjRVFBuenHZ7fPWvmwemk
PSSO21cHLq6KjalsGkBqu0Y6NoRuo5BUIsAEvykCA1tkBDTgs9MAI7XQKYExehijg/pW1kiZAoY9
XYiCC34FJul1ep3TYSnTcRTBeEyRli1XwKAhYA5BdTWsrq52V7sdjPNIYZcoObmLyxiv0XB5xCEq
TO8yaaw6uZhHBqr4UBFpC7cqBBScAuFoko+gyxIhIflmvM0Lkd8v4lN7mY1gvkR46xiVjel4Ixjz
2A152t8gHjPByH3OTIgWq+v+XGzYDqSCfFyI9ECHjKE4oE2HC1E2qKNxIdYHY70wNgLG2mFKWXSZ
3Ssiu4bXyO/LRjOHPniDm/1zdHjGZKh0N5t3MsxZSMnCo8wWd3gYFbhC3CTDDFG0NSZcSgZ2caHc
SVsilDwC2iFUkQKVwxxuVQlIGEVAE8lV2k1muwxynGFy7M3Jw8j3b3tCZep5rQFLJUx06ySVLpLi
wFAquvUGlSFEZU6YQYsl5EWW/jezi+H1m6I8MCoOOnXQqYUuDYwEMKrMLpKbyuRdAj9krdXMp3Mr
H8KOnfwu3HawCMkLEo4iykZHqEVU4JvAVxyxOsJsdUo5Elgb2CPmyRBAOTVCLtRAFUeotJksLjkl
DjRnaQxSDgqBBQTZ1oacVZIjNWiIciJbY5RSJA+BQji8wJfwmPluex2v2YPR6pJNnkZRrx80+2lp
d0t3T3dSJNAmipGpJmJ7T8SmnijD+pvYCq/5w4DLJQVQDDAigHR25UlnY4V01rrTQzqf3krw/Sq5
9nWQKEskMo4nQpAIExPjcqJbodEvPWuDNhtl+jmuR7cvxSUU8IT2NpntrupJQ6pDju9J95DqNHaf
Mx4t6ENQhIUFimKBpC7OUEIS6wOxFIrBAl5wsdDgbTEyWxZuNFjCMtaUFk4pjc1qfHb0HI2vd1q3
2mKfmI8cfZ6xe/8RibVLK5xPrcwb3t1S1TdnYjedWIw8VfHA7AJHwYicXg09HAWJfZOMJruJL9NL
9SaD3aSM6Te34qQ2NjuqoLx7HpLuRiTdjzmTQDSOsA4gMBNak1kUTGZRMZmVF64z8kpuhdf9RrUb
e5huGu/+Y/m7MQa7ZUxSgBD6BUAtTE6yUhxvK+QcdPYwFsh6paFiC6eEQU0kQm1aR5TVKbMO3HSp
7wXQoLGFggieXKNh3OqPE+pWV7uLCwpcfIVRjcImLk9J6/QohorsWVQUOWzFgMjd6sT+fjrLn+/K
m5ObVZmihz9OPbKoQO5Mj5qAMJSiEIZyUvnBzRZ+2/dRqXZZ74XNU/ObhndTRHePD2wsH5BZNxvZ
10AkMZo8BZLAspZwxgMJbih9w24kXdyPg/P7bKtfvnM7vf3n4DY7IfJLPGEwTP+jxS+UFFkiWiGx
X9mD/MWH12eBpMgX0wq5LYISvO/kvsQcOrZYT3ZsqN+VOOEG3Q9u17QJSRMcnj6zZ6WndkN9Us6k
jVXu0rwknYBLKCRSV2a/9OnzrP7qzLT+2W4xDtG3y/Vyid5hUvhn75v64LFZGTKDTRem1ClcFmuk
9dDuAQsr3RFuO19pwnZag+TyBGc8cII0sMJvyc6AImMats40vBqnYW8uDWtHGlaWtCPwBgDAE5Sa
hxWWhxWWh7VYDyssD1YoodJaIEpzGakwZJacvboeyNSpfWElnF7YAWHUKfuuDAqjTx2bHF1NELnT
HVpFOp1dA5IU8gmePFyFk7KFGwfVPTQgMn7YmqF9Fvp5KgvWKcHO3AfyspEGIY3KsXbzF7j0IQWa
XtK/ZGHLsMYjiwrzcwlRKFpvy0e6M2yOP6+pHulSrg9LqxpJayNCNTdIBLv90Z7k7OSJyaQSW5OS
xukIpTUG+74xWFrBRCWDb0gXbhzIcz/lJnAK7gC2tkSKVT6K1TGmLmLOQYCjsPys1pg351OrKeI4
Bc9SkKLCPV86e+h+rglrCCPCBD+HMwpW3TVvEzTKr9xBZWOylYyBcu3WLmqlvlP5CLUrmREoj9zo
0rftNRc0lPqHF3vEPBGXJEieKLn/JP/EZyanZ07aWjdmfU3sTnLm9G6Ds2wEQbisPWf0j1Mb1Lww
vUKilIpFep0ya1brrMbDC/LzpjxeqWxaF9erPgWvc472m8RizgzkCQzfq5FhA2QMz8iiljGEVkYW
zoysMiHX7cZeb7Sjtf2sX4H34R3CS8mFBuclbxHdS1bERGnxeC/DfTLhStDGEk7elb1Qs7ufXaM0
O5vJSAhlL4jFyJfh8tTmKKMjkQ47hVY9jkJ6io+gSUcr+fNkMgw18+xF43vYu0eIkY8jVWrDOAKR
QJdQmj6MJzcoI+jbv2B3CKc1STUdoTTIedVDlvSPkkjFSiPOhScF1pLLyLdAFugNhoKzfrUithBb
WSEfsVxIy5SwV2FCNvKSsAiyWftC528O4qZsXh9U9EukCtirj5GSeskEHg9rj4yR13G/BBViE3hG
Iy8hlsIy9idiIVfiR1TSMnRbZbTDL0Jnh9TLI1N7fC4uv6hW16SSP2UWRdPdP0vtMegzug+bDswO
JojOBaHfnXAGC1eLHErsUsoRUXbGjf65QwcsdSRjjSa4FDhdXIRnGi0bCYd0LgUtr4nJzDFo2ShY
honOjuUUp82dLlcYydbIZUrpAnt4fPX83il1RoU2J/mX3IayuMSxOyeN3zgsRmb10T5PvMMSkTh4
Qa+oQguUyeWBQH21t9CjrR/kK/Joy4eW/kRH6QSLpvWszzKSjXZLxABP7xnlMSaNIs5sjyOEhLVb
VUZWQz+fw1+VaM1KTdDre8V0q3E6qruXzKqIFfCtgSuDR9KpxZFVIywpRW1D0rMJvj42KlKdk2vy
ZmH93oj8uK1oZY4HM/dnJ8LozoQkq9hdMpVs5hIty1pzMO3EJKCY3BMDGyLcJgxmnMzRehlaUQ7F
9ogo0Pdi4JPZmOjIaAQX47Q70y7MasK7Ty4g6Byqya18RXDN1cUVe7Pm5KEqsyEcWooLVxcPnN3L
qg/pMyEtGZIXUdmvbUWI0nX97VncbcSyWoyUD7bfhKUcD1ADK3joULa9j32indSwvtwdEZuSOX9z
V2QXjOSOEJNAOFD/U5qAFakaiemg0ILfFLG0wqz9elkxI59zl9wsGrIry/1zUkq87GJlRFoIs+4W
gDImI92Nvx0iIBeFsjvQmx4dlYa+iOP2jwNr4XDEcQTwgsX7+sTjd3cYZwGdr+JxO0LAjl/qwQw4
WomGvW4xYK/rks4K8tWR10LY5xfq9SA+DvMYh3jcF2kpVqGVtIXDWCniVJ6QEPJng9wiXjl3bHho
7oxi72C71OwfXkjH6lB4R/IEPK5da/WYw0Kgh2UQ7c7IiJYOn13h5gslcoUE5+g5qtiiYvL5e8UR
tIM5yA4SwXq/ODsZRvmgz6+AJcg9Ossw52OXPx/mXsycmeXPd4RwARsQszL45+wtMg2DJjYWYJEE
TURjE3Eii8ML5CHzYDY7kbOFvHtmTYj/JqQFHWrwHyXK5vCVNoPRrpNyA4vu1g9YwVfobTq9TS2Q
SAMvwQkSEbM1h8IiAbwakNxrJrc/gNOEEgGJFlWBWCcLvBRwyNUsdsAsJDM18DOZ2IlMJvb+qc5O
HYHX9wtlBQzHrALcP/N6j2br7x0aOwrOWeTj9AU/+40KnKVk3pZxMtG5iwnNG8pgwb1vXAR3DLu8
mfFzB76ZzRqckTDHB7NiTH6MSY0xMCdE+n2oL97j6Zt17wsswW7vedHlCLyOQFYGuXt79kDON9cv
yemRVRCbWhzbS99l/rsmONLYfVt5WigJjNESuDvypveHzH/CUDUbYLPKwjkbhFIlXxWTF5c2JR9b
j9aq5GlicuPSGjuQlasI12pMMl6vVcWpVXleWWxpz8KIAdOKLZ0Ya0+7C2PvpZCLkGNCkgIRf3q/
PgZPTqQvL1qJwLdXaA1CMxgP1vmlwRnEB3Y5unuW/uH9GRwsmkUyWWhVYl6Q6PJuBLx+iF2Y8LLk
F8b2iNZHFIdEj72Gzly77A5p/wfLk/rfLU8dQny05N8sT3cICgmoBq9OOBo8jySEM23P+sOzo2Ck
AkbJ8V6bUwydfOjkwWhmd+c+2bVv7ptdw8662SOEwi5pO/rOtN1L+L8m0X78kBSUNKBp0rdCuFfa
w44iRza8xhEiKzJPRzKuOvT5d1k58nz6lBcnT3x6QnLalBemoHPKbmPWmD7Fo/OsxuwxfYrG5NHw
+wmHF/fsPnf/ZHTugc5zipuGpSUObSrp0VSbljikCe8tBNaRHyPZ4L2F+XhvwZp8n7cSgujT+XoC
dmLUwW0FZoOByQgEdxjuu69QLOvzj/sK99tWuI+O/PO2wiNDIvNy/BFdlEWlNip4Ub1KSmOHLcfb
CgnMtkKBK29WblZVigH+NO3lhYUyW6I9kBXCQuonpDMk3vWaGZ0Vpe61aM/U/AXDM5VRub7ApvLK
zOFzmPgZSesJVlqL/UYkLovIjQ3GLRSHtlgYkHPj2DkaJATVpsv7qT+z76eG3lsNvZ+KYme1o1jU
zW2hZHE4djb0SMWxs6wEr/n3j53vkFmSPLjzGdIXbdI/x84CbGYWFS+qR1GxC4sovm7N0MiC/MJo
/IqzKlzOuyd+DuwPSQqeiUqzS0MxtNyRETU+JLrAX8EgOrghg4JoBp2IZ5idwbr9DUnQKWWVqvPV
NVa5pKzWSbFyKbokArCWAQPSOYdf4O7hlKrpYnUvwMI9s+C7O3zhrgHg/YCGUSIu8QzBFfD5WlOE
Wu9NSrffDTOOnPQ0k8QaYRJTJCSHacxygUDAV8X1SmlrvhdoFibnuaQkXygUhDFvMJa2XyLeRRwX
g3f9Yk/P7J59es7ruacnp0uy7W82ycYoRQ7enlLelYRjkm/wS78lmHFjcm1YxdiEGw6RMeYYX4J/
My+bCLFbJPYzrhKqOlF/2eI9YkIc91WK8Bd5X3mNvEFOBhNrX+CsWg/NxaAxdqTU2IRaNU6RdEmo
dfrS/92EGvFuwpCm3t4B+V6NkMIJM3d2/9TovHijy9+3X6nfFVU2uyyiKD1KzSORdyTkCmzJxZ5o
f5Q60l/Wr9zvgmH549B8a/WqCIsS+Z9G2qiwJzuciZEWmzurf2ZSbXGMWKGWiaUamVwv42n0GqXd
G+5KiqRt0ZkVeC6s7b8R46kXQToYvD8KyO2xrMxj2bmIZeciljXIWFYrY7ESirWS2Ev2IpPkkrbI
h71vXhC2z2C1S2B3r86cDG7tUfffYLhzG0IT2o4hxvNldFSctmC43zRXqsBZtQdCjtqPeO9YIf0x
pVAbEa7icwQcapDJJgsTcB09p/QmwoI7DOdCr5KcC+5BBITVQwVCASdMh/leh/f5yJeRT/CI34I8
AZELa5ALa5AL55pcDEi5ZIzLBW8cDFqahZWKhZUKOl9nbBMX9jGv6rPGamF11IJjFYEyttgl4uiL
kWPG6dzs6/q6WodK3Xez767kW3JK57bfEzyFSa01ybklG5iln6cKxihaT5E3a3Y+T2VBlqsQdHgE
0/v1zhy5bBhhC1ln2599huY6KvsRU0MUNgtHzkbyiQHfHQb2drSaYUfXwuSmHBZoDhbMUMPyqWbP
qk73lzkrOt4paP/dn4JfSEBehRy6ZDCSA22RiNDNBiNs0IqL2VYYYYU0Q6VhBA1dUjjNCq14k0sg
VxdZaWS1VpzbEyBVtOIdRlzDM2HF/YvxK4SRxVaRoVgUBEAmrenGv/CoZjwHd/AfkykKyh1nx9zM
b246Xh7rskQotSlK9sc2syFBEoEzlMQQaTZH6sOowLsUB7/mpDXZlQIqQJG3CKHSatSa5TxyCyUQ
inm3n8NJP4ofJiQHiBUCEsWEBDoI2gxiMfGDQMwnCb4ISzsJxRiLkLTzwfnDoBDBUzfEWire/IpK
hSn47IiDTit00tBpgU4zdJqgKxxGUjCKhOkZMCMdZsTCTPx7aDUskbHbB/jsFyJ1ldGoB5mUJeOz
X4wXEkyW5hQz12FhZsv6yCbK5skomV+hKZIlFDuK01fHwBjcFoNRU6bUFI2MmR5D5COqtpcAC/lj
LMnqk9nZZ5Akg/LuTK0Gk6vBT1DQ3A45ky5el1zkfUTepchZRHEC10iJNtJsidaLyaMEsYeUGKLM
FheqBW5wKBRdaMNtCj75GUG8SQgUSO0tCj7xCQHPEQKl1aAz4WnhqaSdk0KsFAjapnROkVTFE4jQ
DKFItc0gEKAZkiDgxS9z6kI1gi/E8xWFrKMnmi8PWOCX0z6cs4UlcRgsMuKgDqniQZzK00EtCwua
EEkDBVhRo3HIiu/JBDDVDpNFUETjyAJPiEjk80YV4/RmsbwjeggmrT0dCWust0HVrXZoVKFfLpH3
SXcqlZ3pzly+0mUx29Ui6tNPKJHaFm5yyKEA6gLX+FDpok12lZA6c5YSyi1Gk0NBCAI3YsKUYg4K
zHmwPvA4OpEcsTIMHoLPhCklFMkV8gItsA8XvwgpUkkDQxjkQB7gHCSbCFB2GBgRs0nY6o0wygh1
TOCsg86w5DDCJYAGvBynG6A+FUtODy3FeqGyWNiT6gN6sgErzmS7gwaLDddKBnlNUeJ3ep2JHRls
JbOjo1HxiIQZXF+8gZYT3DkCGRk4xpdFmM02lYADIXmdK7fR4RFybuCATM4Rq8JgGqUQkoPVujAO
yZdK2uKIc0oRB60RCsRJFXJoPyEPATfIOAxkiBMNfqPAybxh5UHtiYI8ASFwyFHAsk9fJHUxgQsa
ON54j0d+wplq/A5yx+u5zC4vvOOnAsyrUBAXiU+4/DB+2zm1EesiXBmYJ1Pi93cJSiQX8zAtMBXu
5EsE3AKlUc4Lt9rCNBq9jBhjdShQnRumkdNhOq1B1raBJzMGdxz/JgdwhoBEUASc/rCICItAtY/D
8Qry0vGqBFu8BXix/gr/ApHZ0Q5mBzp+ekg68Sod9GDuyfPeHXuRA+IHzi3h2V1qs4LPhQJFuEKT
MzjNQPtru6cP8EcJeWj54arSSmsTx24a7g2cFOiizHSkXiDQR9LmKJ2A/LpyaU0y54pUig0OohVN
yYvKGxyfNjTfqTfruHKTRqdXWgyKbqMeup1hdRtFIqPbao3Vi0T6WDQX0YHzcAr4BhiBcK9IGw5k
H50JvorG4wUxJkXZ8TPJKdwwrXwZR6LUK+VaIaQeFOkiDPoIrWiVJTEuVv8uT8hnzB4q5xtpGZcr
o7E8j7RfgyvJ9UyMbGwBqlZi9iGh2Y4ifGkRyD6TfQa7PPH3viwqv6sOVyKeLXQkwhRdJG0JyuCO
OknTMZi/GNoWi8+xbZHWIAExjJYOQyy2s0fReCYgjkVA24Jffjp+EL/kJCARYqChuE9g9rvsaE7w
ZGXG4e/4Qk9cPvrivMuG9mvU7+A87gPYQfQxoCPmADMQE7OBAvE85xDXqhYYpbjPhIQz8Uipv8V/
d3bN+YcyHO3JTI/DX/haHC5loDXqZIg2rsATl3efL55LciqcwpmB5lKA5rIQ8RNSzf98KjlOS4In
VvcuT8xAuAAq5xloBZerYOZyKTmdjGOekAIk+7k2TTx6CmIQPeeOnAz7Q1vefagM1uwUae06nU0j
4kq0siUcsUKvkGmEkBPQ3qcBwS5VOJcdhcGcgFTtDF/Iw78U5Qcu/UMDHq2bnE683zFakUub0DHa
Dqk4nYmdYuHcV1jE+3gwSymJQocHQy4Sau16rV0jCmzq0oCGTzEtePQclwWNRneGL0KjQY4LlCMp
yrlcOW34pwb8//oL/EgKOa8ANeC3yDjAg5BFyw6G3UnmPUtJVCa13qqguEQ1JVGa1cixpzhXJFI+
xZMoJdzZEqkA8a+SoP7y4X4ijugGpCBsP+CJLlEAv7jM5tWsQXVjMDROIQ8MUaAP3I6QkgNvuMwW
p9PMlRsAbP8bXqIIYi7qRb4X9XIYhoN/6ogilMrb2UqFQkmeEEgFHCLZabc7HXZB8Bd4DwaegX9w
ViCLsfnVJF71SRxqkszCQKotogdBtgehQfAlSy6KbRTajneS4khGh4JygL8NrR46iAPDTHqFQSkm
k8tSwy1pZQlQIAvXaMNlBGfYqUDVuU8CA98Wy0UcgsvnjHj/068mTfrysw9GUlwuWoFleESz0Ih+
RCOygoTDQBH0xBVsJIfPB/DIFMwLpiJmryA4Qnd8x3ugvJDrkKxISiRcTtYZ0yjgj+GppcmkWGlQ
GEwSyBk8ZMgQipCFa9Xhcj4xciqhn/TVp++P4PC5BActVafhM5+cg8+cEsiEaHRc6kygD/5vV7df
5lg4PUAFGMX896g8fmHxlETzDP1AnnRCKyQP9C6JipKmtULugbyS4b9KC0K/vGQ2dXxeJRZZUHKd
L2GT2iwyqTOKDNJQcMQkWoN+ZfCNPqhidqVD6xgZ2uaJI9EFcJzZP7I4Ms0hi65+ZFTlgn5uZ8XC
alvfAYNiUCQl5skseo1FhTxInzk212MRChUixKmYNqi8/n5p0dX/r73zgI/iOtf+OTO7K2klbVEX
KruoF1ADCSEBWiQQCNGEWIqoK2klFtRYrWg2Ni644hpsBzeM4xIbbMPaxnK3EyfudhLXxElc49iO
HTuOu0G6z5l3jiRKfPF37/fl3t+H4K/nmTMzZ2bOnPLO7MzK11tTtX717FIE5FbHWEddy6Sk2ILa
4tK6wrhA+rS2mty5M1xJ49tXL80sqcmNGnibuye0rFg8pmzJ7OnpU9YvHpdV2zK5snn5spLcpU2L
c5Kmz5mfm2GODDMoIdbIxPKO9pU5GUWpEUpoQmJiqtUcakmfVJBWkRsflztlXrOqJJVPrs3Pne5y
ZaSU5iYkjZ10OGf8oqp0e0pu/FhPs6fAWVXlUrejD8nQnpyNQUyzgk10pcxfsGhy3ZtNpaam8SHL
3kzNs6c24V9GzYIMd/zwK/P2ceJV+RJdquTLAaL3iyUn+5jRQ27o+j5aHwjG6SF8rDpadyEiAyMm
sUcIqs/KCVijTaGRIdvzuAkVKz7VZuJ5Ax/lKUZrcnyCmMrVlogIPSd3szU62npeLg+xp8YnJFsN
eTwum4faUhPiUyxGntNrjT58IIfH5qkb7AnWkIF7UtM0vV3Erlocu2ikTxFzQ/nsVGd6Kp+KJIMh
JNw08MhI71g9cA+fLfrhdYOfqA8bnVpEtet+NgsXRPFWZc7qWTy/r4q3VfGaKj6+imdU8ap+pcYV
E5GcHLGllK8t5fWlvKKU55fyUsw42MO46CbF5Ri9vffBfciGFUXwiP7B71xmTERUDBYVGbP6OQtG
L53Wz2MPGFcNvYOPhrviZUT+K97WrquixMN6mhPvTuaPuAllOPqmU8hR94jlnfKHx3fcsr7h1OWT
M21RBfM23tKVOds1xhJiUHhIeFh4VtmccSvOceeqo6bOWVTsu3Rp1p3xZU3VmbOmV40aXbWyyrVy
Sgr/mXv35rqcWR0X3LSy8fbrL2yfFGaNCo+0RluiRtlCLXbL7G23LbemJlgnes9fXbGqOiMy3hF1
xp2+sUUNXhGJLEDZPqC9CTKBzeBn3s/KxI0Uu3hMD0Z0X6X9ekqpTBkvU8bLFO02sn34dnKd9kg9
TlEdL5LLFMlbNCNTtI9ai/qVRFdiTI7Wj+doN4B076QXUBJco1Kt6amp4j2sGO1XakyquVxbplzc
pIhNwWW7tqKeKFYsf0CpQQ/48t3iJA+f9KFn/vUn7x7TP9d8THsAqFpcJppFHtVFyLRa7nS13Olq
faerRVWzm8WVlLl0snHs4cSl0w8PVZaJQ6+fvky3O454EQBiG/EJg6g9LF//GRnGHtv1quOHnsuL
LysTX+ggn0wpUx+YtP6Wda3Xd1Xk1HdNn7TcNbq4ZVdb8yUrxojH8mZ012e/nlLeWNrRnTRx8SRv
R17a9PZpVasmO7afve0sPnvhWU0FeQs2zZnctqg+zTG9YXnZtI1LxhU2dFWNW7mwzpk+y71KWZU3
rSix2Z1dM2miY/xph28sqJ86ebRjSnXdGM/adWinM1GXntTeG8tnH7kSj/ooK1N+lDVW3NHIFLVj
LB/xIZX4ZDZG3AeMEScvRnyxRsyDCkJu5qRboE69cjn1zyqc+s1A6AciBs9wcme/MtYVZhavpLmY
qn2nSZh4ItA8z6ww7W6W9lokVYjHtBbPzMw8dkxSPzcHrY3ifS35Otrw0+q4AkZDH/kJonbKfuDz
MMOIjzUM6pOFnfvP2HJrW35Rx/5tp0D3W5LyJ80pcq+dHJc61Tuz3D0ZVyHKBVd8dcCz+Lavb9j5
tab7PFdvcE9InL/joY7Lnt1WkVGz0r8d3dedaLa7jfGsgP3FlZGRyjNSeEYyT0/iGaN4RqL+tHau
VvZR4uZGkfYklijuIs5E0bJc/Z5yrl6gufrd1Vy9QHP1uye54gU3S2qCWCkhXPwOt+vtCKq1K7ve
jkakP6a/0oSixxo32Lk9OqqfV92dviDX1s9D6D3akqrDz2t39MXP8+IhOfn+BzWG4btXK/TrePkC
CK65TXTXakKmPsDZtSvh3SZzZMjh5SER4SZTWGQot3wnnodTTeFhPM8QgRA7AYH+R6GWMOM0cc8+
xDYqOmqUPUx9/QqzITI13p5gizA9Kr4IVww/318ShuAVpe1HaV+LOj2F7XRF5pbx/FSemyLuBLr6
5TDk4nGiFsdpPU+cU7vtpIw9OC4T/9hEvawnPqCczsKpcMLFfb9w8Tm2vXyi0zkRla/g4Lg4U0Gj
DaFYjiwh+vyjkDoTdCDPD30NhlZG2h2+IwpH3LQ76qaBaajvCNFenbnWiLj6cKkl1hqimq0R3y/2
TYxKLp0/Xns0XIy9ijE0oXLpusqVF60oiJtxTvfzyrhQa7hxlngvKMSWGheTGh8fyc3LL9/UnJ8/
pyItLSctNCo11hpns8RmpCeULt8yfcopl9zlfzUsSovZ29EnXI7yW8KN97MmFFmyKLImXhyKQikW
Db9YK7diUW7F/Uqpyzy3MWvu3IRoPscl7jhnYZEscSPUhdQsl2pJCrXJz5i0NZOc2mOZVGWTUPL3
anf4tGepRfu26FXTotd2izhx0TgNlkrxyE6lS7utVMm1qqtXYRoBKu2V9riyfh6OqLlxzD+dTmOd
eOUrfOiVr8JPJtqG3vpC111I/b3e12uPJorHPKImDvfzwy/7l434pIpeCqb47dg7P8MnMRYjwOVT
Arevm7p+SYU11KRaIsNKG7unVbdOS8tv3DznFJyrEFO4JWx9ta8ue9T4htIKz+wSswi8cA0TXeHu
djWdt2ysc0pTZU33/LHcv/SStgmxKQ6LBVeFGcnOTGfaFHfJhCWuNDSP2OhEa0iaa+mEnLoyR3pO
utGaFGeNt1uicZ4LFvbNmOxrmBiuhJTOF32/eG/kJcS5eeiXvndViNvmY3n2GJ6RzTOyeGYyz0ri
6VoHlZnAM+N5VhzPiuVZMTzLxnGKM4w8w8Dzk7jWW0VRbzU2LgEmzmnTn8yjJ/Leuk88sZdcUGDr
HzzkSsESNtH8bKJG2MSHSTYxiNjE5aFNfFdONjNQX2XAACAfcHaZxRPOhqLC7KQC7QQb8kfbbObR
C8z0rhJa3TgRgdPN33z9MzXxOvfzmg63wKN++JGP9Q41TT7cV8XxdD5afSkm6nL51vvhjyJskbjK
NIfw3xmjU8ek4qLHdrk9dmCPMrCM38p7RmcNfCY/SOI2E8Lu6NTE+Eg1KlQ8+Itr7kO/Tlc+PFwh
WpwXLe5KowU91uOuyOwJPLtMe5BE1Xqsg9RhTdB7pQna13+JF1fFy3k5KPoc8RqwaBc5lnkl3SWn
l6glx3/B+QFlnPZ9GPpYeq/29Ft0v3isRDxdGp1QJr6HJGJMxRdO8QaMcUxDwhFNZ8UnoukU5nPb
q3qLeWLFy9R4qHBF6R73qzEoBEo/4guATOmj9UdJ1Strtx3omNSxsMxq0r4vI8ScN8M3s6anoSC7
4dRFk5dkJSc4UpTJoVazMSZqICW9rqj7lu6J/IY1N3ZX2BMTLBH2UVH2JHtoYsoo57T2WVNWVTki
RmUq1tHOMHSCGTkDVxiVUs8Fg4PyukQxqc8wUfItaAN3oeQd7LX7mR19l9k+ms+222z6K75Hvvr7
gT5OfqPVxYD28ZytX65ls9EHSdpaNn0tbXa4+ASwzyYajkn/8G+0PLOj+YjA9nUtoI3VR+QRT6t+
oH/pxVv3Yp1Yo72fj717VEP40KuY2pCsnYV8/dM6+aHd8Od12qcdI++pq3epxjDTQIHRGp8xKi3L
rpj4R4d/Eh1tNFvClM8tseEmwxNRKUmJlu9fiLCGqabI6EjDrJyMaIwrpqhklKZ+JYLSfI6Jqz4x
fYtR/G2HavawKzq3gOcZea72yVteFs8y82miq3CKw56G4SRSjiQpW4r5xOK6Yl+xml/Mi8WLwmHM
YnGyHqbQZQBdDtwjamylGDewaqWIV7QXF/sqeVllbWVbpZpRySv7lXyXpTCTZ7o+dzpDyr7Ia0Qt
Dj0QsmjERaF2Oai9TLNCvyIsGVmHtVpsOPrxhAlHvN5uOPIZqjL1lpiihlNu68lvmDomBoUVHhqe
M3nBOM+FS8YopTtXd/xkaXbJ2pv8DVuXu7Ltd6VVr66aurwyObG8qbp+h/LAwn27L1xTGW6LinKM
ihtlMVqjrPWn3bLcUVTZtqNx0TUbanPndF6wp3bbXR1FhfNaSyubp2Vqd7ZrWYd60BDHCllMMC8j
VXwlV4QpihWOe/7w8+N+6KXco74A5aDJbAkd6A+1J8fGpNjhwiLNJkRnobwu1J4SI25gwUWGGxVX
dFKUeH83XLy/i66tIzQqKVp8GxdcZJjRSO/5Rmmfq6zk5ep1ah2LZEks5R5mCYkNf4ibxZ8zwe8E
Jl4M4IX63dkRdxXj7EdMqdfFWw9HWONi7MoXUTEjvarmOBw5GWlpA4vFB82ZaWn0N5O40eGv+ObU
VdZJX7LEUO3r+h/826mijrLHs2dOP1Q80Bt2UPxdAxam/+UmQH/hyTwXc3eEHTz6rzYZPAbL8BR/
ESl7WPqJYkoafE5gaGL7DNOY57h8jHkfs6sMgyxJoH7A9oHputbqtIBV4Aw9fZ96B9tnjGDLjsZw
CPkBo4s5FQPbpxgGZ0FzoBNBMZgP5oFTkJ4Ksg2XY7mLWIhy0eBthhysD9QVGmeozbrvYcmGlWyf
6TXknXccQsBs1vKfMo8wfcpaDGnYFjA2wy+BJxqF4vhm6MSChKHp95l1JMY0dvuJYriApYWksslH
Y8hmRcgr9RgeZZU6ozT9gtlOFOPywXcEBgPboz7LOo+Hwcv2gLWGjaxEoG7DstuwL6ROnTEgF1Tr
6XvU+VjvTNZxDJuQvontMFzHXPxjtod/PLgEmgidCbKBGywA65FuBwmGJLZHmYJmO2Vwh/o08gbK
WxrnKu/r/jPs2ytsj8mE/C8bYhfYpPk2cDtr+095gEA+beqvsC1gOAD/CTwxXdN5rI4Y/BJ8NTS9
lCWrSwcHSFEfL2K7wbW6XgX6dH8M6mE22jSFTTgajGFl6lk4Z0fjY9N0QjV9hS0/itTjpGmYCgnD
eLYL7adJZy5YLKdDulmT6U+AE1h2tWEHWAvGM4/6PVtxIijrWabpapYZ+grLNOyFv0b3k45i3lHo
6aYNR3H+UejpRywfhm3UjMj7rOF5hk8IYzTLDMlhmeoTrPRotGM9ll2G8YN3GGoGv+Wvsu381cEu
qBXaBJzAD5aAdqTbwS71MbbdkMrO4x8NvqLTov4M6TpiGZCnJGtaz79nycphtsvUKrZ1BHM1vXHw
Ok3LcT6OZN4xaZMI03PauZP5rFaeYbuIwW+hXepo1kCg3o4ePCynjXcSyGsX/weWv5ONVp4AQh9i
WYb32WhD34mBsh4dUo/6/fsTA/u5E1ys6zlgDjhf9ztHol7H0oz9rPRo1I3ok3aztGPIZUt1QjQt
Z37Vw1rVTair+9g05S+sQ5mr6Uyln83gj7MM5Sqcow9ZB29hHt45+DqmO/hK9GeLsOz7GtO19bAO
/wqKSJO/y9LFOsp25lA/ZWOU0zDGncMcygRWrSxEf9YHdopR+zBCgUMfKIuOTcP+MXUV0NIO7Qbt
R6VdB3x8ENNXgxvBz7V0L1itZiC/L5FWC9q19BvAaWo2puvA2qE8tqoRmLYCu5a2D9ymXIb1fwpu
0NI+BO8oiDGUX4B7sezj4G2m/WlbzFsAivkLiENeBS8QOJY5Ahzb2dAtyumabuBfs7PFN+lQLDJ4
vohB1EaMr2ezCoohBp4UYxrFCwPXi7GZ4oWBIGKDBVoccAXLkOM9yriRxvDBOG0djNvqXsQmNA5j
vBzoEmqKxjYxnpoYu9Q4n600zh/4lsbEwT4xFirfa2NMOo1lA78VfSuNWwMvG+5hbTRuDTyMMWqh
Nh69zexy3FHPZStpLBmsFOtoY8gyVq+NB1q/PXCjUCNKSvTrxiXsXDG+GA4MtmPs92i40E5LUB8v
x9hXhOVuRh0FylPoA2ZjnmAq+qNNzKSUsJ1KyeDHYAuwav3KPTi+NuhVqOsKm6OqaDuyT+hgOYYo
tgHrL8X5X64mMtXgZpfqbAVxxjLmNlYyN447yngb22m8nLUKlPO1c2lGWYlzXaYY2VVDZKDeD7Iu
gXY+57A7tPPZo7MB5yibqSNiR49pDbbxDKs3ivhKR48H54tYbyjeepeppu/AaxQ3hqjDcZzhWzrP
Ik6VsReOk+hHv7CTzrUxGct8CfwsYPoceaTC/41ZTQlQF2hmKwwe1hwSCr8e8d0g1v8csZv4q4yi
bvyd3ajFSTE62Tjf25hlRDw0xrgJY/A2tthwPuadz64EV+gxjlvELzjWPQKcW67Vl016THIbWKvX
FRF3yTjiOtTZ6xBzF+I4zFRfDBdjHR+W+451mtIR70zH9CoWbzwLaR+A99g69TPELyXwgxjfVzGH
oQWgBWIM51o6xn9DDcpF1K1X0K8/oQOPOlGHOC9ejBMjx3DkPwUxQb2hEXWvETFVI8Y0GgP9YlxT
D2JdYIhlcSaFRRt9bJVhBsaxHH2sKgZ5w+OZFmOIcSaRmcVYp/fNCervWJphAOnou1EXdxnGaWNo
tfFltss4gOlZzGxciLRfgAtRty/Cvv0a/llWbmgc/FaMzTjfCWoXjk0HdfVmgXINNyvXsEcF6r1s
O1ip8WfU7dXsE3BAbWVbMBasQj3OE3UaPCjqt/EcdiXSdoh0qThH54F8qXpavnKQBcBjUg2JiPkS
0R50VeMZV97EmHAXv0A9xO/EdDimxyq9GEOAegjxJAiZwq4YCdK+VQ+xx4faXCfbDrYoARxTgDUp
Z7NFoE9xoV91IX0W2w/a/9VyyOt6sBFsAhsM+9k6w2TEA4fYWjCZP8EuVEvZhUaMSUaMTSFfA4wb
IZNITXewuwS4/txmvIlVGfexOThehnWrDHejHllQHofQHixa7LQE/n4wC9ON0E6URT78ePWfGKt3
o/0+guvH3VhuN+K00awudBz6ikPo399FHbezFMNOtkp5Fv3yx6wZNKB+pKmvQcvYaWoQMVsZ+oMy
1G0LmwnuBH7QDpzAC9aBFrBAowZlcxFLVM9AP9iL/nAfy1LXYD/uQxnUsULUDfF88ALsz3xwEfCC
ZlAB2rV93o36sxv1Fcscs385J7x/RcfbP7SPmfwbxBD7Wb1yB5uqvMEylVtQR95kyzAulyhvI/1N
xCkfsQZog/Ibtpg/xFaDJf+VdZXrWDn/khUrC9gkpQ71chaLUWqxTgMrUspZmrIYec1B3ie63IHB
ejWaTTOuAhhLjfG6FoBG8DSbq9HOZhjvAzeC51m2cSubDj8dY7uI52aGzmUzkbY85Gmcr0MY1w+x
2WA1yAcrdb8UoA3hXNF8N1gk6rPxQzbGYGSlppeYD+feo3yC+O8QCxXxhogDxJhp8qIvXsiWGeLY
LLS5q8GV4GkNC7srxMIrpJrnsqtN5bh2a2M5+t2X6iNRVv54xP1fwxPHx3j9kZiuPDFC1jAWevBY
wr4axrzjxAlfREQs1Pns+FhmMWbddnxsPT8OezMRhWg0+u9HEnv58YlbfSTxG06chCbGEk89llGz
T3KSHybp9h9P8h8ZS/nixHCkHYmz9cQYvfZ/NunTToyM2cNkTvlxZM0eJnvbMDmm45P7FGN5H/1r
xph+HGPHEwVtjBUuOZKi906M4j/+v6Pk0IkzHuewbNSxTChjrJwdh0dOcpKTnOQk/78ycd8PU2HR
uR68w1jlJp0/DDPpPMYml/8fcN6/4AViSsIJgvitatb/fVzP/fuotv33UdNBTO//9zIjlbGZOxir
w/HV38PYnCmMzf05wLx5uCaej3itYdNJfogFcUex498KF0/EsDtYCNsHFGZjhcyLq4YEfiYzaM/O
jFVwxcRU7YZNq/Zb1Z6zsWhTqva8mEU8q615VfuLNOQNSN+veyNLYI/o3oT0V3Ufwr5j7+k+lOXx
P+s+jDmVUN2blRuUHN2Hs0WGp3QfwfKMqbqPVH5qnKl7C+sIeWvouZ+S0Nm65ywk9DTdK/Dbda+y
hNAdujcg/SbdG1lE6F7dm5B+n+5D2NbQR3QfymLDKnUfxmxh83Vv5vPDVus+nOWb9+s+gsWa39B9
JJ9t/kz3FlYWMQl7wg1hopwj/LpHOUe8qnuUc8R7ukc5R3yue5RzZJruUc6RRbpHOUfO1D3KOXKR
7lHOlvm6Rzlbtuge5Wy5WvcoZ3uF7lHO9kt1j3K2P6B7lHPMAnYbc7ISnPUiVgY3h/lYC2pDN+sF
bSyAtBo4P+vRfnuQ4oPrYgWYM5V14J+TLUBaO1uDeb3alBfqxdIb8LsVS9ZgvQ4s04w0nza/nfUh
xYPpY7dYoW1z5BoVQ/tYetScRdp2evV9crJibK0Iyx651JFTTiD20wsNYK9FDk4s4YSKPRNzA1qq
2HsnvDjuVkx1anu8DmndQ+scf27bjypLsUddWl5ib5zMjSmftg9i+41wHm2qV9tmF1IL9T3oHnEE
LZjqw9yAdpRi6YIfsQ+zsW4Ly0FKL8vFUq3anszQ1hVbOX4ZihLoxPxWbR/EMfRqe9irOa+2rCiL
NqR2wnewzZjaqJe8WKYPOQaQ7tXKn46gVSuPdi2Xbj3XgFbCwyVAxyu2STVA1Mc67fjakCKOq087
g736efVoNdWnlWWHViq9bIyWc6eW0qHl6EG5ULrcSqdWU0Up9eh72YWUTm2rlKc4zsCIPRBb7NGO
hcpYljDtu9hSN0rAieOnViP2qhPLerD9wIi6INsUlRltxante5d+XFTPmrUlh/d45BGJUtukrUdH
vQ7TBce0r2wtt04th81aOfTprXdkecvaKba+UStVz1BL8elnm7YozrUTefQMHQ3tY7u+jGivW/Tc
AzgKOkMbhs6SR6sjojV1HnFcsga3YE882vZb9O0XaCUVwBYr0DYKsbb4V6DVuSPrf4FWbzqxTADH
Ks5Qu5ZTD3LYjFSRY5t2vsSZPDJXmS5qM5XcuqH8lmp1l0pxs3b0vVppBbTz3KvVS1rbqZWbqCNe
7Qh92jaorTdr68qSno6eYDZ6WVrXP2IO1a9Wrc0O15mN2rZatDp1vO3StFi2BeXcp7Xa1qFz0KrN
79H65c0jyr1HO9IuveQpL6/2W9Sko49bzKcam4O1crV+thPH5R2qQ8fuVdcxOZ94GQ3nLnsNp97u
qR9sOaL9HXvswz3vkftVOaIExJHQsVAvJPtO/1CP1qq16S6tbXv+5ZFSOXuOKFOv3o8f3ZuLUhU1
r09bs1VrH+JovEP5iCU7tDb2Q2fov6tdDLeJQm1vRBugnrFAO1c9bNNtzpKiojLnHF+Lv7u3uy3g
rOn293T7PQFfd1eBc2pHh3OBr31NoNe5wNvr9W/wthbUeDp8zX7fAm97X4fHP7RihVOfUSFyLNUn
Fnn9vcjJWVxQVKIn6eL09Tq9vsAar9/pcfq97b7egNfvbXUG/J5Wb6fHv87ZLeaMmGw7/l46fV1O
ZON0d/kCWL8x4Al4e52ertZCZNCtbaClu68r4Pd5ewuOm8PsvpYcT2+us9XrnOHv7g6M2EOPs7O7
1evvcvZ6unqdKAFfm7PN0+nr2OzciJ139vY1Bzq8Tj820Orrau91Yn9wIJ3aDmC7/i4UQIGzLuBs
83oCfX7smd/r6XD6AthGS+8YZ2+nB2Xc4umBF6t09nUEfD3Isquv0+vHkr3egJZBr7PH3409FjuM
3Ds6ujc61+DUOH2dPZ6WgFYK4kxhz7CKs8PXhW2hzJp97VrGtKGAd1MAK/vWeQvk+crudXZ6ujY7
W/pwemm/RXF2eTc6/R5xUnw4bKzo6XT29YjNIMd2pPT6tmDxQDcOaIM4JI9zo8ffSdsSBdyyxuPH
jnn9BWsCgZ6KwsKNGzcWdMryL2jp7iwMbO7pbvd7etZsLmwJtHV3BXr1RYVv82Dn1onllnb3YRc3
O/t6vdg1nBUx2+lBiXj9nb6AOOvNm7Wdnu6ePRVz/doEyqu1j0pm4xpfy5oR60J9XS0dfa2iwnU7
W329PR3YgNj3Hr8PC7RgKW9XoMApt93dhYLN8eU6vZ3NYqXhrLrkwsfdI21xUTVQTL2ogy10/oa2
rlVePa9KbQdyfNgKqpConX5R0Vq7N3Z1dHtGbhT77KE9xYkYqubdfYGevgCq8QZfi1css8bb0XPU
AZ3IudDORGGrt82Dyljg6e3ZdPKK4+QVx8krjpNXHOzkFcfJK46TVxwnrzj+C1cc+n3tf/kTDFOd
/crZ94Ql8FkwZ0lzpjRnSLNNmtOlOU2ardKcKs0p0myRZrM0m6TZKM0GafqkCUjTK816aXqk6Zam
S5pOaTqkWSfNWml80qyRpl2aNmm80rRK0yJNszQeaVZLs0qaldKskGa5NMukaZJmqTRLpFkszSJp
3NIslKZRmgXSNEgzX5p50syVZo40s6Wpl2aWNHXSzJRmhjS10kyXZpo0NdJUSzNVGpc0VdJMkWay
NJOkqZSmQpqJ0pRLM0GaMmlKpRkvzThpSqQplqZImkJpCqQZK80YafKlyZMmV5ocabKlyZImU5oM
adKlSZNmtDROaRzSpEqTIk2yNEnSjJImUZoEaeKliZMmVpoYaaKliZLGLo1NGqs0FmkipYmQJlwa
szRh0oRKEyKNSRqjNAZpVGkUabg0TDd8UJoBaQ5Lc0ia76X5TppvpflGmq+l+UqaL6X5Qpp/SvO5
NP+Q5jNpPpXm79J8Is3H0vxNmo+k+VCaD6T5qzTvS/MXad6T5l1p3pHmbWnekuZNaf4szZ+k+aM0
b0jzB2l+L83r0rwmzavSvCLNy9K8JM3vpPmtNL+R5kVpXpDmeWmek+ZZaZ6R5mlpnpLmSWl+Lc2v
pHlCml9K8wtpHpfmMWkeleYRaR6W5iFpHpTmAWnul6ZfmvukOSjNvdLcI83d0gSlOSDNfmnukuZO
ae6QZp80e6W5XZrbpPm5NLdKc4s0N0tzkzQ/k+ZGafZIc4M0u6W5XprrpLlWmmukuVqaXdL8VJqr
pLlSmiuk2SnNT6S5XJrLpLlUmkukuViai6TZIc2F0lwgzfnSnCfNudKcI812aWTYw2XYw2XYw2XY
w2XYw2XYw2XYw2XYw2XYw2XYw2XYw2XYw2XYw2XYw2XYw2XYw2XYw2XYw/3SyPiHy/iHy/iHy/iH
y/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iH
y/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy/iHy7CHy7CHy7CHy2iHy2iHy2iHy2iHy2iHy2iHy2iH
y2iHy2iH19wtDKLmYOoUB2LmYGos5EyaOiOYWgHZRlOnk5wWTI2AbKWpU0lOIdlCsjmYMhWyKZhS
A9lIsoGkj+YFaKqXxE+J64Mp1Q7xNzY16SbpokU6STpI1gWTp0PWkvhI1pC0k7QFk6dBvDTVStJC
0kziIVlNsopkJa23gqaWkywjaSJZSrKEZDHJIhI3yUKSRpIFJA0k80nmkcwlmUMym6SeZFYwqQ5S
RzIzmDQLMoOkNphUD5keTJoNmUZSQ1JN86bSei6SKlpvCslkkkm0ZCVJBa0+kaScZAJJGUkpZTae
ZBzlUkJSTFJEmRWSFNB6Y0nGkOST5JHkkuSQZFPWWSSZlGcGSTpJGmU9msRJ6zlIUklSSJJJkkhG
BUfNhSSSJARHzYPEk8RRYixJDCVGk0SR2GmejcRKiRaSSJIImhdOYiYJo3mhJCEkpmDifIgxmNgA
MZColKjQFCdhmvBBkgFtEX6Ypg6RfE/yHc37lqa+Ifma5CuSL4MJCyFfBBMaIf+kqc9J/kHyGc37
lKb+TvIJycc0728kH1HihyQfkPyV5H1a5C809R5NvUtT75C8TfIWzXuT5M+U+CeSP5K8QfIHWuT3
NPU6yWvB+MWQV4PxiyCvkLxMiS+R/I7ktyS/oUVeJHmBEp8neY7kWZJnaJGnSZ6ixCdJfk3yK5In
SH5JS/6Cph4neYzkUZr3CMnDlPgQyYMkD5DcT9JPS95HUwdJ7iW5h+TuYFwVJBiMWwY5QLKf5C6S
O0nuINlHspfk9mAc+mt+G+Xyc5Jbad4tJDeT3ETyM5IbSfaQ3ECymzK7nnK5juRamncNydUku0h+
SitcRVNXklxBspPm/YRyuZzkMpp3KcklJBeTXESyg5a8kKYuIDmf5DySc0nOCcZ6INuDsc2Qs0nO
Csa2Qc4kOSMY64ZsC8aiM+anB2PLIKeRbKXVT6X1TiHZEoxthWym1TeRbCTZQNJHEiDppaz9tPp6
kp5gbAukmzLroiU7STpI1pGsJfHRemtI2mnP2mh1L0krLdlC0kziIVlNsopkJR30Ctqz5STL6KCb
KOultKElJItpdxfRhtyUy0KSRpIFJA3BGBdkfjBGbGFeMEZU77nBmLMgc4IxYyGzaZF6klnBGMQF
vI6mZpLMoMTaYMxpkOnBmHMh04Ixp0NqgjHbINXBqFrIVBIXSRXJlGAUxnc+maYmBe1LIZUkFUG7
qBoTScqD9hmQCUH7EkhZ0N4EKaV540nGBe1jICW0ZHHQLg6sKGgXbbOQpIBWH0tbGEOST5nlkeRS
Zjkk2SRZJJlBuyilDJJ0yjON8hxNmTkpFwdJKq2XQpJMkkQyiiQxaFsBSQjaVkLig7ZVkDiSWJIY
kmiSKFrBTivYKNFKYiGJJImgJcNpSTMlhpGEkoSQmGhJIy1poESVRCHhJMw1aG12CAasLY7D1lbH
IfjvwXfgW6R9g7SvwVfgS/AF0v8JPse8f2D6M/Ap+Dv4BOkfg79h3keY/hB8AP4K3re0O/5iWeN4
D7wL3gFvI+0t6Jvgz+BPmP4j9A3wB/B78HrkOsdrkcWOV6GvRHY4Xo7McrwEfgf/28h8x2/Ai+AF
zH8eac9FdjqehX8G/mn4pyLXOp6M9Dl+HbnG8avIdscTWPeXyO8X4HHgGnwMvx8Fj4CHI9Y7Horw
Ox6M6HU8EBFw3A/6wX1IPwjuxbx7MO9upAXBAbAf3BW+2XFn+BbHHeGnOvaFb3XsDT/NcTu4Dfwc
3ApuATeHj3XcBP0ZuBHr7IHeEL7OsRv+evjrwLXw1yCvq5HXLuT1U6RdBa4EV4Cd4Cfgcqx3GfK7
1DzXcYl5nuNic7vjIvPNjh3mWx3b1UzH2Wq54yxe7jjTvc19xt5t7tPdW92n7d3qDt/Kw7cmba3f
esrWvVvf2OqaYzKf6t7iPmXvFvdm90b3pr0b3Rv29rkNfTF9gT71iz6+t49P6+NFfVxhfbY+Z58a
EXD73b17/W7mn+/f5t/vN1Tu97/lV5ifm8VXvfqTUmvFF6Oe6o+01a53d7t79na7u9o63WuxW77y
dveave3utvJWt3dvq7ulvNntKV/tXlW+wr1y7wr38vIm97K9Te6l5Uvci7H8ovKFbvfehe7G8gb3
gr0N7nnlc91zkT6nvN49e2+9e1b5THfd3pnuGeW17uk4ZJZsS3YmqzaxA3OTsScsiVcXJbmS3kr6
LMnAkvYnPZakRllHOUYpudZEXjMvkXcnnp54SaJqTXgxQXEl5I6ptca/GP9m/KfxhmhXfG5BLYuz
xTnjVO1rbOPmLKzVtGoaaXGpdqxz4tKzaq2x3BrriFWmO2I5s79l/8yuxj5qe9GmWK3cah20Ki4r
FrdaHBZF/Bq0qC5L8YRaa6QjUhG/BiPVOFckUkSO2RHzF9Zawx3hirsqfF644gqvqql1hY8tqmUq
d3LOuA2ihoo/G8FjHbXqQ1w8RG9knF96YGFjfn59fyhbUL8/dP6y/fy8/ZmN4reroWm/6bz9zN20
bMkBzi9eeoArNQv3x9Q3NNH09osuYinV9ftTGpcE1RtuSKleWr9/m/Aul+YHhWdYZGn+yt6+3vz8
wEr8WtkbyNf+Y4r3ial8kSj+9wYwLf71adNDf2Ti+D+0GGRVL34Celrgh1f6n/7D/9078L//5wBD
NV0ydVA5m7UqZ4EzwRlgGzgdnAa2glPBKWAL2Aw2gY1gA+gDAdAL1oMe0A26QCfoAOvAWuADa0A7
aANe0ApaQDPwaF/+1KqsAivBCrAcLANNYClYAhaDRcANFoJGsAA0gPlgHpgL5oDZoB7MAnVgJpgB
asF0MA3UgGowFbhAFZgCJoNJoBJUgImgHEwAZaAUjAfjQAkoBkWgEBSAsWAMyAd5IBfkgGyQBTJB
BkgHaWA0cAIHSAUpIBkkgVEgESSAeBAHYkEMiAZRwA5swAosIBJEgHBgBmEgFIQAEzACw9RB/FaB
AjhgrJUjjQ+Aw+AQ+B58B74F34CvwVfgS/AF+Cf4HPwDfAY+BX8Hn4CPwd/AR+BD8AH4K3gf/AW8
B94F74C3wVvgTfBn8CfwR/AG+AP4PXgdvAZeBa+Al8FL4Hfgt+A34EXwAngePAeeBc+Ap8FT4Enw
a/Ar8AT4JfgFeBw8Bh4Fj4CHwUPgQfAAuB/0g/vAQXAvuAfcDYLgANgP7gJ3gjvAPrAX3A5uAz8H
t4JbwM3gJvAzcCPYA24Au8H14DpwLbgGXA12gZ+Cq8CV4AqwE/wEXA4uA5eCS8DF4CKwA1wILgDn
g/PAueAcsJ21Tt3G0f452j9H++do/xztn6P9c7R/jvbP0f452j9H++do/xztn6P9c7R/jvbP0f45
2j/3A/QBHH0ARx/A0Qdw9AEcfQBHH8DRB3D0ARx9AEcfwNEHcPQBHH0ARx/A0Qdw9AEcfQBHH8DR
B3D0ARx9AEcfwNEHcPQBHH0ARx/A0Qdw9AEcfQBHH8DRB3C0f472z9H+Odo+R9vnaPscbZ+j7XO0
fY62z9H2Odo+R9v/d/fD/8t/lv67d+B/+U/CqpX/ARW4EBkNCmVuZHN0cmVhbQ1lbmRvYmoNNzAg
MCBvYmoNMjk4NzYNZW5kb2JqDTEwIDAgb2JqDTw8DS9UeXBlIC9Gb250DS9TdWJ0eXBlIC9UcnVl
VHlwZQ0vTmFtZSAvRjINL0Jhc2VGb250IC8jNDEjNzIjNjkjNjEjNkMNL0VuY29kaW5nIC9XaW5B
bnNpRW5jb2RpbmcNL0ZpcnN0Q2hhciAzMg0vTGFzdENoYXIgMjU1DS9XaWR0aHMgWw0yNzggMjc4
IDM1NSA1NTYgNTU2IDg4OSA2NjcgMTkxIDMzMyAzMzMgMzg5IDU4NCAyNzggMzMzIDI3OCAyNzgg
DTU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiAyNzggMjc4IDU4NCA1ODQg
NTg0IDU1NiANMTAxNSA2NjcgNjY3IDcyMiA3MjIgNjY3IDYxMSA3NzggNzIyIDI3OCA1MDAgNjY3
IDU1NiA4MzMgNzIyIDc3OCANNjY3IDc3OCA3MjIgNjY3IDYxMSA3MjIgNjY3IDk0NCA2NjcgNjY3
IDYxMSAyNzggMjc4IDI3OCA0NjkgNTU2IA0zMzMgNTU2IDU1NiA1MDAgNTU2IDU1NiAyNzggNTU2
IDU1NiAyMjIgMjIyIDUwMCAyMjIgODMzIDU1NiA1NTYgDTU1NiA1NTYgMzMzIDUwMCAyNzggNTU2
IDUwMCA3MjIgNTAwIDUwMCA1MDAgMzM0IDI2MCAzMzQgNTg0IDc1MCANNTU2IDc1MCAyMjIgNTU2
IDMzMyAxMDAwIDU1NiA1NTYgMzMzIDEwMDAgNjY3IDMzMyAxMDAwIDc1MCA2MTEgNzUwIA03NTAg
MjIyIDIyMiAzMzMgMzMzIDM1MCA1NTYgMTAwMCAzMzMgMTAwMCA1MDAgMzMzIDk0NCA3NTAgNTAw
IDY2NyANMjc4IDMzMyA1NTYgNTU2IDU1NiA1NTYgMjYwIDU1NiAzMzMgNzM3IDM3MCA1NTYgNTg0
IDMzMyA3MzcgNTUyIA00MDAgNTQ5IDMzMyAzMzMgMzMzIDU3NiA1MzcgMjc4IDMzMyAzMzMgMzY1
IDU1NiA4MzQgODM0IDgzNCA2MTEgDTY2NyA2NjcgNjY3IDY2NyA2NjcgNjY3IDEwMDAgNzIyIDY2
NyA2NjcgNjY3IDY2NyAyNzggMjc4IDI3OCAyNzggDTcyMiA3MjIgNzc4IDc3OCA3NzggNzc4IDc3
OCA1ODQgNzc4IDcyMiA3MjIgNzIyIDcyMiA2NjcgNjY3IDYxMSANNTU2IDU1NiA1NTYgNTU2IDU1
NiA1NTYgODg5IDUwMCA1NTYgNTU2IDU1NiA1NTYgMjc4IDI3OCAyNzggMjc4IA01NTYgNTU2IDU1
NiA1NTYgNTU2IDU1NiA1NTYgNTQ5IDYxMSA1NTYgNTU2IDU1NiA1NTYgNTAwIDU1NiA1MDAgXQ0v
Rm9udERlc2NyaXB0b3IgNzEgMCBSPj4NZW5kb2JqDTcxIDAgb2JqDTw8DS9UeXBlIC9Gb250RGVz
Y3JpcHRvcg0vRm9udE5hbWUgLyM0MSM3MiM2OSM2MSM2Qw0vRmxhZ3MgMzINL0ZvbnRCQm94IFst
NjY0IC0zMjQgMjAwMCAxMDA1XQ0vU3RlbVYgNzgNL0l0YWxpY0FuZ2xlIDANL0NhcEhlaWdodCA1
MDANL0FzY2VudCA5MDUNL0Rlc2NlbnQgLTIxMQ0vU3RlbUggNzgNL0xlYWRpbmcgMTE3DS9BdmdX
aWR0aCA0NDENL01heFdpZHRoIDI2NjQNL01pc3NpbmdXaWR0aCAyNjY0DT4+DWVuZG9iag0xNyAw
IG9iag08PA0vVHlwZSAvRm9udA0vU3VidHlwZSAvVHlwZTANL05hbWUgL0YzDS9CYXNlRm9udCAv
UUVWTUFRKyM0MyM2MSM2QyM2OSM2MiM3MiM2OSM0RiM0RiM0NSM2RSM2Mw0vRW5jb2RpbmcgL0lk
ZW50aXR5LUgNL1RvVW5pY29kZSA3MiAwIFINL0Rlc2NlbmRhbnRGb250cyBbNzMgMCBSXQ0+Pg1l
bmRvYmoNNzMgMCBvYmoNPDwNL1R5cGUgL0ZvbnQNL1N1YnR5cGUgL0NJREZvbnRUeXBlMg0vQmFz
ZUZvbnQgL1FFVk1BUSsjNDMjNjEjNkMjNjkjNjIjNzIjNjkjNEYjNEYjNDUjNkUjNjMNL0ZvbnRE
ZXNjcmlwdG9yIDc0IDAgUg0vQ0lEU3lzdGVtSW5mbw08PA0vUmVnaXN0cnkgKEFkb2JlKQ0vT3Jk
ZXJpbmcgKElkZW50aXR5KQ0vU3VwcGxlbWVudCAwDT4+DS9XIFsNMyAzIDIyNg0xOCAxOCA1MzMN
MjU4IDI1OCA0NzkNMjgyIDI4MiA1MjUNMjg2IDI4NiA0OTgNMjk2IDI5NiAzMDUNMzQ2IDM0NiA1
MjUNMzQ5IDM2NyAyMzANMzgxIDM4MSA1MjcNMzkzIDM5MyA1MjUNMzk2IDM5NiAzNDkNNDAwIDQw
MCAzOTENNDEwIDQxMCAzMzUNNDM3IDQzNyA1MjUNNDQ4IDQ0OCA0NTINODQ1IDg0NSA0NjMNODUz
IDg1OCAyNTANODYyIDg2MyA0MTgNODk0IDg5NSAzMDMNOTUxIDk1MSA0OTgNMTAwNyAxMDEzIDUw
Nw0xMTA5IDExMDkgNTExDV0NL0RXCTEwMDANPj4NZW5kb2JqDTc0IDAgb2JqDTw8DS9UeXBlIC9G
b250RGVzY3JpcHRvcg0vRm9udE5hbWUgL1FFVk1BUSsjNDMjNjEjNkMjNjkjNjIjNzIjNjkjNEYj
NEYjNDUjNkUjNjMNL0ZsYWdzIDQNL0ZvbnRCQm94IFstNDc2IC0xOTMgMTIxMyA5NTJdDS9TdGVt
ViA4NQ0vSXRhbGljQW5nbGUgMA0vQ2FwSGVpZ2h0IDUwMA0vQXNjZW50IDk1Mg0vRGVzY2VudCAt
MjY4DS9TdGVtSCA4NQ0vTGVhZGluZyAyMjANL0F2Z1dpZHRoIDUwMw0vTWF4V2lkdGggMTY4OQ0v
TWlzc2luZ1dpZHRoIDE2ODkNL0ZvbnRGaWxlMiA3NSAwIFINPj4NZW5kb2JqDTc1IDAgb2JqDTw8
DS9GaWx0ZXIgL0ZsYXRlRGVjb2RlDS9MZW5ndGggNzYgMCBSIA0vTGVuZ3RoMSA0MzE1NSANPj4N
c3RyZWFtDQp4nOy9B3xURbs/Puec7btJdrPpm3KSTa+bXkmWNBJCgCQkJEAgmx5II4VeQ29WQEGl
CogghNCCiIIvFhAUFbGLviKigoqKikDyf+bMmRCK7+u9v3t/939/HxOe/X7nmXJmnnlm5pkjLohB
CFmhOYhDw9MLsgct3GA0geYThAzFwwrCIg63VdUg5BoFurKKSW28/OBKJaRXIiRVVTfXNDxnvjYG
Ic91CCldauqnVgfrSzIQCuxGyGNwbZWl8iVNeT5Cg1moH1MLimT1cxpIx0Hau7ahbcqg2fa9kIY2
dPPrmyos45+BHDT6c0gvbrBMabZiGT+EGmpByTdaGqoiHxh6ANKLEXL4vLmptQ1BxxGaL+Q3t1Q1
P/ut/jykId9bDTpG+MWIDKmAdkj4MSSYOgwxMmXgwqyFv1kxcnZDh8EPVEaWYcLVJqVMGmTNsS5S
ZLLIVEEyRsJ0xLKMZEOBKc8U3E/jusl9jitKEn6HoXLUippQPapCbSDJ+Nfk2a8xiZ35y4ZpGyo2
egeEf2D9xMoZJ86+eG3Whg7786YO7jhIyAaOZVhWO+gl51XnV+Rnpv32cUOWVfjTJqu+rjJS6NTc
ZUInuUKJTM+OGhhub9LjhEKvGVnV2lbV0sinWZqrwu1Mtlgt16vT21vKLY2T6urrq8JtoDXQqvSy
EbWWyW1V4W4mA1ao9XZEwadVtbTVVddVWNrqmhrDPUxuOJvTO4jZI+oa4CmWhua6xho+baDJ3dHK
FBkeYYoyCT+jHK3CcTIyIjI6Pjp+lKmgX2cLC8IdTfbk+dZFVS11BXU1jcF8dmNFaHiQKYA8yItm
CI/iC+izCqpaJtVVVLXih3YwXv2twkgR18HYINCr2A6GQdtPdj196jS/WzVzyc5F7T/uG3r1/DGb
l2osRzZXun50+PrJyB3zTUuKZy3/eMKnMetsXnr78pSfJm+d1ZT00qO7rZ6v/aV+5ckj+SE7sgZc
O/Be6TgDu/6PsAnuT/+2ee1Wl9fZL2YPyf/Suuyy2XXWIavPUl7bd37RkXHTxoeHcmvm6p8ZxL8Z
3mo1MuT0lKjIVbZrbA99Vhv27MUvX166PPAfyzwXVR+ZVzyyqf2lpGd9F5We1NonrZ//7Yhjqsbj
Pa8M/vSQXPeY14yPk/3edp9yeX34iasXvZw/Pr53UNpal3Eb3B+6MPba9zOuztxRzjx4LVf92Rmv
omdWnd61eNKu75+3+vlC7ocbbtRu2GWXuHfRscMsB46/ee7HprkfmKJkCvBYqVTOMBJ/k6/Jm6ZN
zEKn2ra25oSwsKaK1ubQSWD3VrB7aEVTg+A7bnqG6ZUoTDIAlkGmgVjnIUkwxZliNkRtiFhoEqtX
tNTfUTuM+Ep/V0kbGAqlBE9185FoTCraC05hssZKG/wsCawAGfQQ0joJeObTziZH6t+cXjOiYCA4
WlxIeEh05F2rgps7Fw2ecP3b4pfTXcOXTF0TtPqljp3MOdchpzuXFjeeVwRsHvv6yUf1X0vyrX4Y
5BeG4jovnHh06NqzXuX2v6XEeg5rDp9zdVncor2XLj2Get4qXD3U+53tfkOn7TpoGfhz4Jtfn/hw
7KeHgxYk739q/4dfjOx9cd8rs669pVn342M9Qe8m5hsMcX6/pQyGNdxr6mC/Ftex1TdBP579IGCx
U4RUOXbtpMV3r+P/lpVx73I0xfVfjiP/4kPDTCHkob7/7qE4r6rl3y7JruH+WZ++WzttvlN6dXvp
rOPd6yt8ewekPTlDF6f1KWz9sN2v7tbQQ/yYd1XXNxgCrxQWeVo+cP/4wguRE1774dPNsVUPGB7V
HChwHzOjOnqcdGlGz6Sh5wvmbJrLP7Vr8ZhNit++Ml3/3it2SKrqzfOvehw/V/jN3JT9+ZuDn2Wm
/bTp2RXRPesvlo6Xrh8w4cuXVh/tOVV23fy1fEP6d3PzGrcE/nRgqdb/yoOfyDYsHL52+mCFlcnt
pHbdhN++Kd4l2W5e0+V/6UGHnUlfFjTlvBv91P6mSre9q4MPD/h66ncN0647XPR9bvcPawoOmoNX
dU99tuds/o6Atlmpl+PdN413uFhy2Lv2AzQnTbtozgRxSZ40zX3tP7kkNX1LkjUhUyRZjMGmQJP/
Bt8N3gu9/mwxtrW2hlRYhOXnICw/3MS/WIGyo39pBUbdvQLxLC+a0vzR0HyGH/351BMdpuO3Djmv
PvIw+seR06df/cX6g97ruUcjy026V661Gc4+8tm4J3n9nhkZLw4/Pe/rOY7ztvk9WqPPvHGy+/GB
3Kkn8kZLl81+pulnw3CDd+hPdSvqvX47fNJh1RVN29HayR9+t6Z80bHWh35f0jbNuGPz49Mf2/Pb
gwETc0PbDVkDP/pxvxU/4tzkDY91VNTdUr619Mf2w8onPryuK/Rda4l4cRrbOX3hi5v+scwreMrb
0ZNeeKR1zPVDF4fYq4ynLrxzNio022yfZFM2zfvVLdU/rH6r+bvkr3+xmvXJ2zM2T5pYd+zJYYNM
0Z57Nu12KU8K+vCBZwPl0z9w2jtm+j+f2tLUk7TkOVOHxBa2gD/IFmCDjqFlSUmLdW8n/1px+by5
v8UksAM007Wt1nulNTVPbamrqW3j/SsC+PD4+Fg+t66ipam1qbqNT2tqaQ4Ndze5ksL2d+Y0tZCz
2tPkQabJ6XZ+flNTGz+wva22qaWubSreHuJjTeHhJlOsuD1EmMIjIsPF5P9Aj/7tUc4eOdZ8MfGn
oQb/9Y9NGWv6dtP2FT7jfu9ZNWTzwZ6nNvHJM/I2PbHpwbKICW+nVk79fuekEyM++um7Jxe6Prh+
fvXeVyZMKzeec0v6zIZ55NLq4y+FVK9dW+u75kxC8Eua/cW+xzK/ViXHrQ7e7h//zOXsealfzrc5
vLa+0LKzY8bGspDJQ75Zs68yce1w13CFt9367V8/HOR0ccDjFXZlxdKq9W6x+Yt+2/bDSvZVw7sv
FWbsXTLnpYTLI1YO3XVr27SGtqG7nU6tVvp7opEPldXFHs6xlScV9Y6+8XS1SrH1nblFI384kDjW
Ye5kyUe/vrhrzqqeztOzz21zaRmTdPKFHxWbvUx7ZQtO7OUn6xecF/eNZ0xzt5jmbsLrkpHMXWua
+9gc7egzzT/Utawz5s2y68p9oPeNjS3/9+ev49/4uLArrLqkPrri58ecoq90M94fTNb9PKYsYv06
9RvJ0ocXP3gi4aLnTz+OfDR4/4ZBr5f/cPP9U4mJo7bHjKjr8W5IOXHq2c+kMz4NXzFgvbZ5/OEe
22FOdUdvnkn7UjeKH/Zt+fTdzzq/HhTrE/Ji1UbbpT42FZt/G+F63fPEOfuf83c2pkXIb3U4/v5V
Tb1V3q9Hrua/duTr46abfLhysduqAJfc99zYLVfnfM7tG/3Lnk9fH/l9VfZr+SMO7OP8bXsfOvej
4sFZ3Y+9siM2+MK0C89M/nLSBnRmfMqxd2KWfj7Q9pno8YbxH0d/cdZVcuGZDMnroyLjGnNdrcoP
qjYtf/e9ESmZp10LtzZ/bJuw6NH29dve2QC7wj8gONgtBgbj1WuGHUVuO3QfHWc3Vvs9Ty8Jbv9T
W4IpBuKFqPDYqKjwKBzAwxYfEUO3hLlb7wwZ9CYduW6oRlpaayEUaIPnaIUjBC4b8vyqyoamxkra
M9Wf9ezPhhkBD71nmEaTJxmGS/+cyioh+MDRyHDhUsDfu5NY4Z1EIewk/zjFr3jhfG/y8O+nvXzW
2+fXSW969p4OLBp68smDHV3RU0PQ8WcU71WcOLjl12+OHTu3Z/nqTfI/bA505K/9ruPVI9pXnjn6
/YT5DxQYDg//o5JZcszhbEctMk9Jv2YbN/RGRd7nfww49FXsnvMVcmPiRHPUoF8m7Mq85tfq7vVG
qrN73oH8te9uPqN/1Tlloqzhp1We6eNSrxw9saaS7z4WdXNT+sXpXW5h3Vs/+2Xj+Sc8bXqKwwcW
xs3aXfz1hcslU312/BYYpkuJm5KcOntb7YVZXrWOFwc/cnxKev6gjcPmL3n0iaM1079V3ljIzfx1
zcSkoG3Vj586H/LPINbFJiqr6lqS7e6ri1zdfPObToHvcZs7mECwh+/94nDuf8f2YitTihdwe9hf
WI5DEuGK6mYtcZDY+fwelFP6esuI5776dUOgo8ONY9cL5pqc+6rYsRKNuwoVoHa4rqehgSa1EPgI
945Mk01fgCU1cQD91qWwjVV8+fnP0u7Ob9XqqLc7wpOXlGe8p9h23VL1eij3R1zWwLf2/+Q3790v
XykqeGa/85unLl7dcL3oQNbKQd5fbff4ZNrZXx2m2X7880OGy4rSvQseOrS8+LDrqVXvrloZ+cvD
n/UufmJsTvbweN8E3jAi9ubMMfaP/uMT1wd+tOQnfSW/Uv3D1MsPvjmyomqVU/aGaeerDp733dXz
uu2BVzedenXcsuafT368o6NR/kmV86Fnfl34sjL18au+O+um7TkWtK2z2mPL7kWKCY/puztj1rhL
N+vjNh/daUp+3vN909aT5bauu0eu+OrqNN3zY5M0sVcfPfbI4qGSUdIxr711bvuHX8x8eIrfjX2N
Wx6URRbvGRuoszF1SCNhKzOQbUxlyVz3BpIghKrueUPxv2XLuL33xUdFRsXg21IsxEaQjMZJU9t/
yzjEfO5P8v9tSHR67uq4XWM2/XTs/GdndqxacS7pKY9l/yhdGFr6456Wazt2Lh6//6M9XtPVr7++
JefhsV76b65fMz61/5fGSbt++P7ppNeOHy0Zk7Jjb2uk79byuZapG8t/aVy86kzjp6+tf+fpPN0k
y/PNS6s2rnZYsq107pn06q8+LlpnPnnzk0neoekm9NW5mdNX6d4rdtt8aZj6xOJPNp0rWFN/suLk
mvFrHxk7JFd3Kezd0aPHjsvf3Bqy5fD8DKvlzvaT3lB8tHZrs/2l3Mt1t0q7Jjx4JSAvNm7Zq5nZ
9iuHP975S+3T73+mnFjTtm7ycrcFEx779utxGac+vzjR6u0K9Oj08McfUO/TH9l75vur5z2/315m
+T42bcA/SEjUwTwCFnngnrvL7c3g+w8nbG8vOD3se8NQZ5n75id3vLXy1p/sfNux1iiZu9E0d92c
++4iG9ue/p/Y/+4NFnLIxS/dlGoyb0jekLQwod/Fr4G2I9z8mifUYW1Yc0tTZXtFW2sYXgDY/8H3
I4QL4bB+N9E000BTSt9NlF0YKbY7efLk+7Vb1XJvg233uxPGffjDqrgnxjxuVzqise48+/rXe2+8
+3Luc2E7Zo+w+ijiwO/jL1rd8HSZnLyldtq+VbOWjvkp7fi8J6pmLh6eN6PD7tq81vc3vTjmJNv8
pm+94wv5dluWHD14YeOpje1PPTxxgOFoESra//t834/GRt445zNt7NqPtt745aeBLjsLM5/L+uTh
OH2xMvvqz+GLPF6QPDDator7Rp13ZqNm6ZojHx575ozC3sdz/4GRS1zfHr0wesvJW88uurw9NuVg
2oQv+asZL8za9c3Vwq6NWS9UvVgQ9eGJS7IKiWxK4/DerMNPfJs2atHHz6nmXCt5JfjCV7NHD/4q
Yur3Xgse0YTsHT761ZfNxcU73jn9Zdix05cb1sdODe+QnIBt8xWWYUxz9/+v2Rzv2OBvv8beMPei
ya7vQPVnwuWcVHgLj49ZceqVXLim/5tz6PrtlDrc2tQ/195kvF1REg7r9hRz7dP8IS+lzPI0x4Ql
Hsic2flzlam5XxVNeLmpbEPMnCg4wy2oHtXBad4CnzzKRE2oEbWhVuBFqAq0raDHOh6Fo1BkQhEb
fed4/6lnt01tbqppsTTXTr07lpR0MGjrxqxXAiNNuuH/2D1q3Dj/ub0lB35///Wlu8edfnffjaJJ
1cwy/npQ6WM7K+PaBlUMHT/7WuN3ab8/emDmA22m5g9T2MMfvPyRA38q9+IezwT7P1Z5unypHLjk
43dS3sgaOl9md2ThxQVtmc+W2VV7PVdf+2qU4/fuX91sHuCc+NzxVy/MeWH41w9+8XvB6dm/v/Pt
w+1baovjX/5qlVa9+aX4TwOYzz7s/WSsnbXJb2ly+sKwD4Yu+dSl55LLq8sOHboWe+bnP36cn6KR
HX62Qj85qDBN9/SnrUOjuKhHmt9/9gX/j7iL+92OveDw24DkE+5OSz84aX7pwpPP/+QQm7H/iH/j
j2NiU0s+8vpwuR16+ereQQc3dkBQ1MHcuD1fsvAO5jKoLmHnrvlveaV5nxepGpmCdICFPWZDicmp
v+epb/+HHQYcry9HGm4jnPbx4eHh8eERUdGjYPft53i2Eu0a51Ueka92/bZu5ZnkId+NePw+LuA0
OC3iFcMqv0UBB1Ptxy4a7pGx5dF57Rde3LxxcuYr+RNzNp1+yG/plhk/j9jh+17N7Bqb61/86mzO
+uTcjfU731vgO0edv6v0vd+3jljynnnE2h3aY8qukac++mn3G8+eqJ83fcbzptdfXvKZIevNXUPm
zr/UtuLjYt/VD80dv92y7lO3eT03C7V2W6MHxKT7d6e99rb6yYS3on4yhUx2c808/pbn6epEk0vq
2gd2XTJ+c9mSvWpRx62fnX5u+L0orvuiT3HDhdfD1U8lvjTihuLdB17rLAi8UfNwTM6iz7sPc+su
5bY6udW8oJh+5Mi+MR+6Rbrontr+7bmHb/we1Otf5PVDkm9N9SfV363afSbW+1bnEVjonETOPISk
SCFdI41EiHEnyJ1BC1mkQKyNlGVZOIslGxD7gxnx05H4k1vA8wgUNyQy1IOY4/J1rC+P0Hqcxx2U
WuP/ioe3Evk6hHoeRf1/hqPxsJLnwO9CtAI9il5CH8OanwdsDdqAtqLtqBMuCifQ++i/8KdnqrQB
abiDSIb0CPX+0XulZytIN/T0tuZRSOkl/G1Nr7b3+7t03/c82qvt6ZbZIpVQ14p9B7Q/M7d6/2BT
cLo3BqfZRcBthBpX5et6dvdsu8sGeWgUGo3GoFJUBvteOapEtbC7jUcTYA9sgD0OpxohrwY+qyE1
DkpVQCnMb5dqQs0gLbBLtqNJ8Nss7JIkhfMmCul2NBl+p6CpaBqajmagmeLnZEEzA3KmCekpILPQ
bJiZuahDYBSJZh6ajxbArC1Ci9GSf5la0seWomVoOczzA+jBP+Ur7kg9BL8Po0fAH1aiVWg1ehz8
4gn05F3axwT9WrQOfG6rkLcKNOsFhnNfQK+i/WgX2o0OCLasAKsRi1C7VAs2bAYbzIARzuvXY2K/
yX3WmgVjx2NbKo50Cug7+tWYJNoRl5wHJUkrZB5wKzPvssRDMAbCb4+IpFYJ47+t7W+Vf6Wl9niy
n2WeEFKY3a39M74aPQUrcCN8Yqtitgk4YesF3l+/rq/sBiG9GT2NtsBcbBMYRaLZCnwbegbW9rNo
B9oJv7d5f0ZwF3pOmLlOtAd1ob1oH8zkAXQQdQv6f5V3P/1eUd/VpzmEnkeHwUNeREdhp3kZfqnm
COheErXHBR1Jv4z+AWlciqReRa/BDnUSvYFOobfQK5B6U/h8HVJn0DvoXfQ+YwXsbfQNfN5CZ8yD
KseNLR0zelRJceGIgvy84cOG5g7JGZydNSgzIz0tdaA5JXlAUmJCfFxsTHRYaEiwv6+Pt9HLw8lO
p7WxUquUCrlMit9soOAMY2YZ3+lb1inxNWZlheC00QIKSz9FWScPqsw7y3TyZUIx/s6SZihZfVdJ
Mylp7ivJaPkklBQSzGcY+c7T6Ua+mxmVVwx8RbqxhO+8IvBcgUt8hYQVJDw9oQaf4VSbzncyZXxG
Z+ak2qUZZenQ3h61Ks2YVqUKCUZ7VGqgamCd/sbmPYx/MiMQ1j8jYQ+cQlb4sZ2cT4alsnN4XnFG
usHTs0TQoTShrU5ZWqdcaIuvw31Gy/g9wUeXLu/WovKyIE2lsdIypriTs0ClpVzG0qWLOnVBnQHG
9M6AaRecYMhVncHG9IzOICM0lpPf9wCmU+qjNfJLryHovPHK5Ts1FlEj89FeQ5jiIfaZCfIpR9A3
6CGMz9MT92VZtxmVQ6JzTl4xSfOo3NCFzGFBJZ1sGc45SnPsC3HOHJrTV73M6ImnKqNM/DOp1qlz
TjkfEgzWF/74wB/I5zs537LyilqMlqqlxvR0YrcRxZ3mdCBmizjWjD2mMChvKYNB1GEz5BV3hhmb
O+2MqaQAKHg8B3UFxUIVsVqnXVonKqsQa3WGZaTjfvEZS8vSSQdxW8a84kMosvfzPVG8YW8kikIl
uB+dDmkwKb4ZS4srqzs9ygyV4J/VfLHBs9NcAuYrMRZXleBZMmo7Az6Hx3kKTxRqwdjuKk0L45HL
fRR8MWvgSvBsgYLPhA9jahJkaGG6hCSe0dQkvpgxIFoMniKWwOyOdiDB+aRl4SwOV03LMniWeJKf
f9Elg9gnqU+nol9bWlD09Yk850+7RkrjDgXwGVXp/Tp4R6NSsYNia/fvJ4ttIT4YaijwdGbRLM4H
Vi7oWGhGUOFZdOI70XC+2FhlLDGCD5mHF+OxYVsL85tTYMzJG1UszLboJSPuSJH8OJLqRJ6QTRNs
GvhgZpCBTquQHiSk+5JZd2Vn02x+qcKYU7AUN24UG0Q8rCAYtMw327IszjYKlmYm7G7GTIuR1/KZ
Sy3dvXPKl+4xm5c2Z5TVJuA2jNmVS40FxUkGoa/5xTMN0/CjbFEOkzMiNSQY9p7UPUZmcd4eM7O4
YFTxIS3EtItHFHexDJtWllqyxxvyig9B1GsWtCzWYiVO8DiBW8qHhEIobzhkRmiOkCsRFEK6optB
gk5BdQyq6GaJTkt1LOgkRGcWdPgHJsmpFkwM220GX4mnZ0ZJ7dKyEry4kANMJfxhOhljMupkjcl7
GFam6VQZq1I71cZUrE/B+hSil2G9HByDcWDAOHhPWlpmhH0KHKoYGRjiihxuku/u7R1R7HnacKXE
E1xtDMio4k5lEOz9Up/BUG4QljJQD+qcU2HB/UCFxbiu3Ce7ogTcljYIRbI7ldCCUmwBSmQKdbA7
QqUKmBuYQKH+HEh0zinpLAnCDy2uKxHcWduJsowJMO2kTakvflBYyVJbY4SwNmEpqHwWYVBC31BB
MdEYIAkPKyFGkmug5xVGyKoo48HaElRRAK5O9lKVgWiqYEuU+FYJojKImQgPi/NRW6k6laHQIPzB
XB2Kl6TUR15SQjovpBaJBeDZ2k419Mi3nynFCmAdyMrGfYE/i6CruOgx3ExeN8o3ToGdBXdaaEkO
2Z1WPtkW2PxJfTVojHG0sgLvEWqxjeNEK8cj14DdOZ8R3b3bjFM9+/2EBBvx4YAdExkOgWOjkqV3
KzpHB4UEK+7WWgnqpUsVVvevQOylsOpDrOQz4NSA2yfqaeXegdsUh+QoHuWioWj0C8iKyUcOKIHZ
v98+PV0RIn+RSYNlwDMj4F7KMGlmGwlrddDFJcV4MFq2gtNldzMh+1LkK1gWpdz67NabYbc+u2Ib
H3aFCfv0i8++0F59UxcfFvnF2S/CTYzOUyeInTUrl9vJjF6hbLSfb0xkZEQyGx3la/SyZgVdVExs
MhcZ4c5ydlSTzOI0w71zcxQ37JaMnWVMKYqUurvY2FnJpKyrk21Iko+2YLRPUqibnJPLOKlC7h+b
6pVTn+H1kVznZu/gZqtQ2Lo52Lvp5Lc+llr/8ZPU+kaapP7GSk6WOCbFm3tcpWAlMlm3u5NzYKJn
dpGNXitR67U6B4XcVqfxTx9za6G9K27D1d6etHUrt9+9kkGW3h8lGqk72LF8rytKDOruvbRXy+QC
/rjXRsDLe60E/H6vRsBLe9WAL7KRyBo5MWHIE/kywV36AslhJhBFIxMTukdZBEY9ewULE/ZFEP7R
njsebvKxs5b1M4zMXjQUNqG9nTuLLYoNJtGwUoWdedz07FlvPJhbsPrt2XHjR2UaFFJOolArrCOG
TRxWtKIyNrriodG5rXlRNnKVjDuodbK1tgvwM4x4+upTG2/uHmPPBxqs9S62dq56pV+YX8bCYzOm
H5k90DfMV6ZzB9cY03uFS+FOokhwuk4zb5PqkRqWyqmVjlEaGGiUFkYd5aTGzEbLDInqZn4zWyM/
PxvEaJAWTIMSsI2gaAK2iZWIaoL7cJ2EblZhttM5voKitFFs4tEoBkUxUVGhAwO7GYPZ5owX4+Ul
cfs2dPCATzS5EhSWciUF+2DpFR3+nDi2lFrveNDY0vgwrcAj4sNNY0t97GRgSV/f6GjZbYtGRkcR
W4oaCbalvZxY1yEyIiaWS9G6Glw8rBMfzhvUmheS3PZM3QyH8KHxAyzZ4RqFRimRG1KLqqMsi0f4
Pr0ivTLVo2T4wKYBThqNTKbRjErJ9MmsHjikebBPZtTwaIOb0U2hdbZxdnMxuumDC2eNOO4YkhKQ
WZCaDtYtA+s+KW1AvuBZy8weKYmM2hCPbRqvApPFa7X4A6wYj00cf5i5Dt4Y1vs5tmOY6INhog+G
iXYOE+0b1s2qzCq9Z6Y63s8gsQZjSrucBsMESfZa50qHoBTBjo7xKdT3zhLAlgPDiebpb7gIB0ed
uFbtOV/f/u4Yyz0p17na4UU0aM3oiuUj/SPKHx43bJ5Zbufh5MzbKremzUxPKY51to8qGug5wJzp
56zQyCUSuUYxObcod96e8rbD8wdlpLFquZVcKoWPWxkFI5PKZ5jTO6oG2AamhSOwVilYaw34YhBE
u7vMgWExKTFNMZyeB2voeTCBXu8ZrAUTBGNrBWMzBgteGdzNXN+fHvR0EIsX7H68YKMk3cSMEnHJ
Cmm1gMQtJdh+np7Br82RPCRhj0qYMxJGInEN+8R3sNO3ZdbN1qy18lvXXLyES0WPnNhCXTHi06BS
gYA6KAgMysCO6Nlv7drfucZZe78YwaBybo2f860u98zmPHNldphGrpZxLCdXxxRNNDdta0lImrih
YvyqspCt3NTJA8Yke0F85OeZM6Uo1N7FXm7tbGult9GonZ30ydO6p7UdmpuR3vpEsb5jZeiQqli8
j/n0/sEulE5BSaiyy0GLYMz7YMzIgH0HjIFRGDyQX7FVDKIzGcCCXaZAn+7eM2ZbrY4Z4qO6EjPI
xfeKKYsfos0CZ0q5EpECow86HnmVrMVI2MmY/juXPRm3zGjUUe/SweKka1Kwg4RdKJEqZHJ79wCD
TxRvfUKhVkptbU4o9LyTE69XzNZqJQqNYrYxq2GwMdVbo+CkNnpHa6lSrXSKzEsol+tc9N78ze9g
/5PgTZCz5731Ljp56dhFRQFWNhq9AVthTe8f3AbpRBSBpu5LiWIC9eIo9XT4enH4etEu+m7md7Oj
uxovSjX2KzX2MLXgXGqcp0JmyELugc7abkZ2MGSwd6bzEGGRpWDXYMLCggR3IJvTHStMJ+xGMvlt
o1CX0MXEkLW2QWHL41WkcArNNiXPSIekM1hDLtcT9aCHskdNH+LpTEfN2uSOTfcuLry1jGqkcWA1
CTbdra9ysgdUL7Hg9bSg9w8mTxqG7OF0Wn4wxTjM2GTkHMR92kG0gZDWC/g53m8cxP3GQTSaw2F2
InJF9sRS9mItezHXnprUHsx0QOVhhpoe3UzyPmdttmCfc1eCxDUj7j9BdxpHtIUeRxTgK2ARByb5
bgPogxMTgrD0mYCbLycDljOmhMCAeBBx5plkmHl7ZD6Y4jjMscmRQ+IcI7HnSOw5oj1H0PN9Km2m
0F2xr/ft4739cr7X/tjuo2Af+wz2MT3yQ8+YXVMCGH9bJkDH+FoxvhrGV8H4yplAjglgGXdxk3cX
je4u7lru4q7lLnbWHW9W7mEqRmXnBMXt8Jlhh/dFO1soZYe91e55VoVQ79GDNii3GUzh3M0wXTaD
jd0Mu0cK29gVvHxLiZsGhZHdC4+T/jB3hWvyqDsjEu6zhNbnWpq2NMbEt+5sBYzdZUgePyy7Lt3T
kDJ+WNb4dJ75qvHQwpzUWftaAAcDzsjuKI+PGteRO7jDEh81tgNss6ZnJfce2CYQDUBz9oPBPWNU
4gypxBlS0ZlRiaNXCcvTPggPOAgPOMgJZwfhYQdhyyiRvSom2lMiNcEpeMB3sCFbOyweqDjwFOEg
ZMLO9lujwjFIx+x37+K0J0EstYJc5+AgWOG9yIpHxvqnDzR7U2eQ2cLBaLCVBwzJzQspXzrSf5d9
ZJGZT4ZDMH1aWnJJrAvzzaQX5g3SekUZe5Kpn0i+UYIXc7D/TQ1MDrAfMn93e8bcyiR9QFp4z1q4
X1fOEP2Z3SZEZxX7mqMZXxvRRDaiZWyoqWxEG9pgU9kiMyxoZNbBB7YZcgEL+piVQYN9bez5bHvs
6Lbx8dghjoMp+vas/tv5ffYrYhIZu42VKRUKRzdve2dTdIKxnx0cHdy0cp+BCfFuVp7ebhoJx3Dl
Du46pVKpsAsdEnur8/byhYFzHJhgXky6nw2nUKmU1sLendd7hX0TRpyN3jRrwnJScoblzM7ZnSMd
KA5woGiBgeKKATyKty8hrRVRjZH5xOzhHeEdoTHgHd2A93YDDrgMWnzg4RVkeJ75FS8ZswoHshoz
6DXQnNkX2kvR7NawmtBPY1Xf6YbrynTNOi5WF6tzSPp4oEEaMNjhEnEtMOMVXXx8WFip9opWWGBB
Z8U1ZovVt/c80bgSur7IvSlU9ie3ABn7ZuTYjqGmkRkmB5VEpparg1KK4gLTIwx+5uGFeWa/gPzp
+d5ZCQH2co7jIPRXesVkhwWaA+z9zfmFBWY/xjqjHubb0dnO20PvopUbeIOtMcbHN8rfwysouSgp
2pIdrLG112psHLQ6Z63cwdlBbzS5+kX7816BSSPwXHj2/sA2SJ5DCWjMvgCkM4aINg8R5yJEnIsQ
cRcLEb0yBDuhxtEq5Ioxy83qimNWOESle+RkEzqN3S5SjEVPH48Q7kOS+4cLdwYVDjS4YhsUWj4g
1DGz0uw2y8ZWqrBSzKRb8tc4fre1+Tp2kKO3q51CqpRKRrt5aa2VMp+c1qGsNYkXzsmhlESpASJE
FD2q0nFKlVJq7YTHvRJH7dwLED88AjF7FKP2wx7khz3ITwHj8xMCAz/sR34QOB0gK81DtIqHaBXA
34W1iQk2iwddrB6ij8JBed2s1Idk+6mlztnesGHdDt3x+qSRe59L3Td0vx1PCDt1TOztIP5Jua2b
vaObTpa7OhdHEHI7EmY5hmWZkqdnQPAOK9dW2XeMTS4cmlSzpJz1oqvz1i/DxqX5FBey7VSD7eMF
8dV0sE8w+vIQMvbC3qzWwKgU+NPHg3EnxJ1xEMdpL6Ld7ThMQFsRdZBvjgUSC2ekjvHTMv5Sxssf
FAO8GG8vxhPTFE/G25PhBS3PePOMnw0zyZPxxCGrUmef5cnDqoXUJbMSXNET3xdwCs+EJ25fAxU9
/bM91S7ZarIBgn0Fq6KgUuEcDCJ/GHwaErtDOihIeOPBWHPCQcHcPiAd9Y6xevFVx3SG5die0xIr
F393d39na0nPmxIpo9B7OLoZ9UpJj4S7wcJdzeDorpNz6yVKlUZ+c7vaWgE3eWsVN1Jjq+QglGHh
Q3nLRaNhLyoh9GUVahLF/cqNlI6FO1EW8jVbe3t7KO32SqUmZXoC9iBmjykTL6xP8bsa4c5M4vK+
lzScL15RZLe5515896nPjYwYNStXbvSzd7dVyBilrautw8Ax8S682ZKaMNIcoJKDq8js4vMsURPW
Vpp6jiudAtx5f2el0tmfdw9wUnLnixeXxUiv2thwEKEx4H16eUD6mIj4cRm+zu5OMp2bg5Oz3sPF
dkDt8puJnkEGtdoQ5OkZ4qxWO4eAbwX2fMa0os+RAam61I6uSHv2tLBDwHjIFMTq+14otcqsHXVL
pFZ6Z73OUcVIFqidvF2cvR3VD3pEhYY4vylXwQmLe6GfY+C1MpmWx967nGtnzsIdyYCUXTKHQSgF
HsDY97NDrPACy8HBTs4M0Th5O+MWyZM0emdbW0e1RJI528DrZDIdb3CPCg11elOhkkvwk/B8LeYm
c6FC+7HIap/MyyECnhF5OuK+T4EI40+ezW5VOxqdnLwc1DIrR+0iqcbW2VbroGKkPY73ybCHTg2a
5cLbymS2vIt7JAz/NO1Uz5U/ycC9DeIms2/39Vbt5xjZ19s+o/v6Rt22uvS+c8G+jTuzWGJl64Q7
w81XORqdHY0O6p61/TKg+xIhB/de6ucBvXE6rVBDb8DxGd1sF2JUlz/LgNlb0LON+Vm6DBmRl9me
w1swh49yTquxYoZw9h7qBSglDA4Y4dBlZHB22Do6OJCt0i+UE2xMDM/8MK503GgpY+3mbOui13Ax
+XGuHvH5kYxS6+rg6KplpeUnekrOvd8z6g2NTi1lZQpp9dsffDpx4icfvlMjkck4mUqL/Wka9Ohr
6JEnijyEbMlOZyuelBj3457ZwnXj6AG1EIuRHgZFkC5icxIjx8TG2EZHsX6+4v7iYMt87RqXF8Np
9C62Lm5WjHTM2LFjJazW1dHeVadga9pZ54mffvB2NdyoWalapznJbHv/HLPthFKrgt7JJKd7hsEM
e8Nu/b7UDpWgUhRvdhueXzQg+/yoaNmoKPno8+6BOvdR8Oudlu9d6FiIL7RC3KKLjNReiYgQIUW8
6huxb9oTRj3As4/1nd568SoXKW6P9pynyOS4ASkkoUdKK/k8/zYbvUxhJV8QyMhgWI7uWhkT2PNt
ICu1cXV0wqkAoYRGsTBgqo1eb7M4gJHr3B2dXG0kgYyDH6PQujs5ullLGf9WG/2tPf6MfSA3Sedk
I+/Z5+4l4LNyNURI8MEU9eduOFfBDHHnje7MQFBJJHK1rOfF/tyjrGcf3A/BhhMgIjgi5YU9eM0h
NBiCREcbNrdsMBPUnsJUpzBpKUxUCuOdwqR0s2lmO42rq2ZaNDM+msmJZhKimaBoJhoyDsDFDDsx
vuXZkKvoQWgGmTQMBJ5/QBzK5moSek0mqW83g7r0JendjP0e6TgkvhPFL2BKz8K5VPqFcGezxa9D
BQbrtTSoX4gpuTuklN91n6G3uiNR9Vsn5s0YM8BHaxs6bPLWRp8h5mBruYRl5Gql2jcmN7J0YWEA
5zIwtyi87qES312OMaNSfQZnpLh4poxNMY9NdmM2F66fmu0/uH7p02MLnl23rCZJaWOrtrLRW9u6
aBXWOushc7aPsXF3somvWlKWMC7V28rRw3burroQU14V/vqKfLDt81JPuCvHokFMxyEUg8MkHTMk
BsdLePFEd4uaaKqJopooqonEKw7CsEhx5WXj9YanKJsx0TImGoD11whvBU3drLPZ2c5f2EX8hfBO
5Dzk+nezTmYXdxujO4wCX7fxh7uduypOKBOHQxB7NyY3TqgoKnHFuOfZNLhgnN2LJ/n2pB/dayei
VkTyfuKo8LIuFUcrKtxGqgkaTaWdTqWdThU7nYpdTafC1xZV9ABpyC3nkoxbfc4C910xajxLgpl+
txIBtP1uw9h7UJD40z8miCVbpvhKk5W7cxx5n4VfCzjGxOgh5WfNkRfr3PNJE7dOqFzXmOCf05iR
NMbsGV6xprr8wdJgT3Np0qCmHL8P3OIKouubDPEjk6rqA70yatJTxg3wWDB/zjxmyIh5o0ID86fk
DqguyvHyyMgbE5M+uTgyLK8xJXLsiGzeOLhwHDsuMN3kXF7ol5YU7xE169am0JyBAzw9klOzgy3j
J8DCqgFfegR8qZiRHkKjYJW6YhcYxYQrwNLh+KAIF2YnHM9OeDcbbVYNLfAdOtQJYkczjh19oYgv
jh3NoPU1c9YGhZbeFoWaBl54XUoiekM3G7IfKcjbpEv78Cxbi9NsLfqhNb5Q6iEItU7E78YSzbiR
sERGh6fdRoh9j5LZTtQl6hxiuhm1WZVdEPwzz0uzCxwguUdaRG6aYVfiteSyGSTEpWFkbsV5dQQ9
1kAEeHtOxamUCS/W+u6csH33/ceSe+NCWd9k28NsP5Lc9uyEgROLE2wUMs7aShld0JSeWpnuFVQw
NXe6wkYtl6mtlRNT67L9XKLyohMsQyJUeJOF01KfUNhkHrV4dAifPCoxrWl4CNNS8mB1rL2bh7W1
nZu9tyvvw3slF0bEFpu95FoXe72zjdzLXBLrnx3jYfQ3Sm0MDjaOOmu9t9EpdET7oAF1efFqVh49
fEJvL92PWRl3EtZXL91DIH0K4f0ap7eCH5hQKjpi1geEMoFSJkDCBHBMoC/jq2LSsdl57Bzp4BxW
1C/cpoUz8eHZ4XXhXFA4Aw4SbFYia2seNUOjwsyShbwPL+RE7AVQNREvWFtcvT2RiUnMTKxO5LwT
mcRuNshsHebD+Jh/4nl5zC+BBU7djGKPvKjfdi5s5Ph1elCpuJdHiKuxtJQRX8tJ7n5tENv/P9q4
S+58UxfDbbUz5U3f3hyUNzDYTsnJ1Aq1/4D8SMuy4mA2emVZ/aMlfhHjn27JmznG7Kfb7ZValjJw
TKKrc9yo1Jzl7PMjdq5fVpuo1traerg4uFhLbWxtcmZtHeNhSqxeXlD0xKTMgNyGpRsz5+yuN4UN
q4xOLE/3CcEWHwxRxgvSIOQGkVmS2VpvbePuJvFE7p7unjbGw8wlmBae+eaAjbuX0kkJcUaYsEN9
cfYLwAEQbwBggUADx930tgUxEUMOLke5nGFiGW6vUtPzolTrbHR2NjpppT3dSkbNpEu0zt5OgqKR
7fmVcWQZFXvINtjx1kGVFZz4Cislm6/3t2NzVVZwJVBqVHPYHpseiYT5AZHvR5J6tCT8PmOcTdI1
5KwQ/qPw4e9mYF9Cx/yyMm6G97QqD+C/lY2UMFbxG5XI3+FWDYXc5coDgrbfj8Qise73n5jfAs1G
ZPyrIjP0nsIiGYV2StKR5b5yGfIuo8ckvciAhbuEdoJkiJgpSgXIOJC5on4n9xzaKdWg0XeL5Ca0
ByI1I56VoJ2spHcwoD9gPEg4yHCQYSDTQe8O4id5BMqtQHJ2Re92iT/UB+FKBZnLlYu8GblKxqKd
sveh7cD7iBxkCKr4tzKMiOwHVCHxgmeBSMuBFwMnUoARxjdIFHsQp770RWTTX6Re6Nm/KpKlyEvu
jgbcLRI/ZIK23O+Rl1CiKC4C/oK0f1WkY3r/iUUiQRu5N1DD/URShTaCjJdMRhFYuDlQdg70hSAv
SjBIAEiqqN/IDYd6Haj+HpkC+iloueQpZGYuo43M5d5iQGfALBA/kEKQfJCJoNeBOEkMaCObDIs/
uXc5dwLaBmE/F2QRe1HkP0Lf3kMbZTJo/+E+WQMyReDVIM+i6n8rzxOBdqq5V+BZIJI9wK8AJ5Ih
4DCUTaT3GsivfekS5MqV9PYQBH9cgdaDPCniYyDtIr9HuFvIU5aMYu8WOGtiuHkwZ3dLHUoXRSHg
e2jMXeJ+H50gsjAikii0BtbPKFGGgoykaXkTGiX7FIQhAmXLJMtBxoNEIQt3A5X+FWEnIh/ZWuSj
eA/5SHYAf0LkSXfJsLtE1Msm3SVL7hJRf0d5JTwjrV/b827nSa4QkeqRj9wf+XDHUfTdIoz1Xlkj
iep9TpLWe505hxYw53obAW0AR4HwIC0gxSA1oNeBrOGOogUSd7SY+bb3PVEquM2gFwWXAQlkXQXM
YW4gV/YWWiOrxM+6Q4YKuKn3KQHjYD7ulGH36JKIyE4Jc0fbKWNPojVEeq8DNnKeKI8I+K1n7y2a
lu4iAm2tYa5C+V3Ikz0OgvEF5Cu5iDwl7X9NwNae8hzw7w//mkA/V4I8IOJCkFyQJSJf2V+4p5CX
tBtF3y3cZNiT1iOveyQAlYgiFzAOtXAWVMlNAV/didLZr1A9O1TALLYb7orHkDf7GMzRN6ieqUAW
pqH3A0jXM2NhPyuCshcFyRDqQR3mV0CICJkvkRHXYRcgD+4HFMzOgjNuIfJgY1EqOwL2s3aQlfjU
vgWhwM1LbNG9Ougf4saBCLqb60Fq7tI9BVLH9EJ6LcgmEOG7HW/CpfdmGecN7V0DXSZIjaDfADKL
84N0Nsj4vjZmchpI24DoBN1OkO3sw1D/cZANgu4bkH+yEGOwL4Psh7LHQL5Awv+8Cnn5IOHMmxCH
nAN5kwiMJRcLjG0+4DR2toCTmN/QfDacxiu9S3AMwhXA+TofJZAYouc1fKaReKFnHT6bSbzQ0wWx
Qb4QB6xC3vS8BxsXkDO810GoA+c2twNiE3IOw3nZ04hRpodnwnkqQ+gh6XA0Vjq85zo5E3vb8VnI
3hDOGCM5y3rexnsrObd6zkr2oWpybvUcgTNqhHAefYF09NzhFqGx5CzpTcR1hDNkNMoRzgNh3+7Z
hFEKlsL7urQYLcLni2RPbw2c/RZBzLBOI8AfH4GzzwTltoCPgrCvwx4wBPKwDIT9aAqSsRFoJRvR
exlkGoiNsK/sg/FVAz4Gvs6iXI6DtUP3hHrkL7FFk6B+Ccz/GM4ZcZJC9JAoM0EcpDGoUJqICmHc
ttLtaKX0EVSJhV0izKUKbIXnOoaVosf6xBv8vhc1YhHmMxc9J8xnsyiTYI78ENcvdrTIauEZJ1GO
FMdXoojx4HAc6/XFW18iTvYHyPskbpRzt+M4yXUyzzhOpbEXjJNIN+wLK8lcS12hzDWQFtQm+wna
cAf+HbKROQGaQcpRqcSCyuUK4BMhvuuF+j9B7AaOLfjG92iTECfZieIH8z0HWfeLh4KlU+AMnoNG
SpZA3hK0GmSVGOMU4vgFxroRC8wtI/jLFDEm2Q4yXvQVHHfROOIp8NmnIOYOg3GoiL9IHoA6dVDu
D9QgM0K8kwHpcchROg90l0AuoAncjxC/RADvhfN9HPKQVIDACoQznBH0cP5L0sAu2Lfeg339uCjA
wSeyIc5zxOdE/zMc2k+GmCBHUgC+VwAxVQGcaeQMbMHnGncA6oJI7JGDjEV6aR0aJxkE55i/eFaF
gwTePs+EGAOfM85Ihc86cW924t5BXpIe0MPeDb64RhIpnKGp0rNojbQH0oORSjoCdC+DLAPfXgF9
exX4GyhOUtB7HZ/NMN9OXCOMTRTw1S1Y2CfgtvYEegkLtx8tABkryGfg22XoCsgerhJNg7NgHPhx
IPZpkMPYv6UL0WrQLcd6ijBHi0GCKIq6IPYAagM5SlHiDDGfM6wHETlHxLDn4UzYzSzlbjK7IK2G
dAjbCmcICHcT4kkQeTJa1V9Ad527iY71rbkGtABkGtsGY2pDo9j5qAiknTXDvmoG/WDUCVLzZ+Wg
rXUgk0GmgEySdKIJkgEQD9xE40EGMMfRMi4aLZPCmSSFs0n+GwicG/IkgrLn0G4scP+cI30apUh3
olwYL4K6KZK94EfWYI+bsB6shdipGPghkMGQLgBsAFsEAY/ifoazej2s3xfh/rgeyq2HOM0TZSsi
Ya+4Cfv7l+DjOuQmWYnGsW/AvnwZlYPkgX94ce8DxqBZXBfEbDGwH8SAb1ujLJBdIC0gNSA8SBXI
BJAKkHxB0sA2K5AzNxf2wVbYD3ciX64W+nEQbJCNwsA3crgXUD70ZzjICpAqkHKQBJAaoc/rwX/W
g79CmXv65/+X+2e6X/9gfWQxv0MM0Yly2OfQQPZj5MNuBR85j0bDuRzBfgH68xCnfIvyAPPYM2gk
8wIqAyn+P6nLPoXimGsonM1HSWw2+OVgZMdmQp08ZGLjkBc7EtrKhbb/ark9vTmcHqVLx4HAWSp1
FDEUpADkBBoqSA0aJD0IsgnkNPKTzkQZwDPgbMfxXJZiKMoC3Rj5CZivm3Cu30RDQMpAgkDGirwE
BNYQzBXJLwQpwv4s/QYFS6QoWvYuqoO5t7BXIP67iRQ43sBxAD4zZVWwF49AoyUOaDCsubUgq0FO
CGKNdsutmQSKqqForSwO7m7VyF98+5LaT4b85wWs+Lf8LX/L/1Lhnv7vFck7d4rM7q+J3OX/DVF4
3Ral3X+RrP3PierAf0zUF26L5tydYl3+18Rm1P890U7766K79Lf8LX/L3/K3/C1/TWzP/WvRx91H
Hr9T7CDmsvv1f07sFyPk4P//tjjW/9eJ0+tEDHb//xHXm7fFTSOKK0LuD/wt/5PiMfg/JAz+GzHo
OSRHO0FYpEVhqAohoxPTgSTC350JYeHWIHyRKkKVwicn/D0bayHFCX+vyxq1iJxDJjRH5BLQd4pc
ipzQiyKXgf6cyOXoD3RB5AoUyHwmciXiWYXIVewG1l/kalQkeV3kGhQodRe5Ffu4NEvk1qhe/nnf
3/uJUAwROYPkilkiZ4EvEDmHnBTLRS4B/dMilyKNYofIZaA/KHI5mql4UeQKZK9MFLkSaZXDRa5i
hivLRK5GQapOkWuQvepjkVsxQ1Q/itwaxWiSoCeMRIntrGkROdgZbjqEg501F0QOdtb8JHKws5WX
yMHOViaRg52tskQOdrYqEjnY2Xq4yMHO1tNEDna2XitysLMuQeRgZ91DIgc7654XOdjZLh9tRzyK
gFk3oRhgucK3E7agJuEfnatGbaBLE77VkXy3owU05HtvQyFnIKqHXx7lg64G1Yrfj5sPHtgqfEfu
JPishJJ3fpsuzq9B7aCxQPreJyYIz+xfI6Gvj9F35fzJd/HeVerub/OtE/pZBdgGvcYt8FCCB8Q9
qxO+LbFKSFWCtk0YdyWkGoQeTwBdU1+d++dW/4dsyQvfr8mLveFRIaTqhD7g5xcAswipVuGZjaAN
E3vQ1G8EFZBqF76lGI8Slw79D/RhCNStQP6gaUUBUKpS6MkgoS5+yv1tiC3QAPmVQh/wGFqFHrYK
rEooi21RDdoG4PVoKqQmi5bnhe8DLQdeLzytRRxBpWCPGqGVJrHVNsHCty1AxoufSTwA+2O2ML5q
0FiE77tsEW3WImjqhV63ieOogJxgoeUGQVMvtGgBuxA9fUqD4KnYSs1iLxtB0yA8lbTZKvzTjLd7
gJ/YLIyFfh8qsTDpO35SE1iAF74JtEawQp3w3Z/4O1Xb+vkCXVPEZuQpvND3RnFcxM/KhZK3e9x/
RNhqU4R6ZNQTIB16z/ryE1prEFqYKtihXVy9/e1NvRM/fbJgVUvfSqkTZ5s8Ec81D200942G9LFG
LIPX6zSx9TYYBZmhSX2zZBF8BK+mhjvGRT24AnpiEZ5fIT4/VLBUGzwxAdZGmPAds5NB23CP/4cK
ftMAZdpgrHiGaoSWmqGFqaDFLVb3fdv3na1SfbXwLbktgj1peyWC7xIrThVG3ypYq02Y51bBL0lt
XrAb9pEqYYR1wjPIWi8X6lJLZ8BOMAR2WVK3pV8O8a9KYc3e9pnJ4rfL1v7Jc0kal60AO7cLq7ay
bw4qhfxmYV+e2s/uzcJIG0XLk7aqhE/sSXePG+cTj/WHWgHCPtsA46rq86F7e9V4T8t/3Ua3W6e7
Bi+ue7IPVtyx/u4d++2d985+JfazAB4JGQvZheje2dK3o1UKa7pRWNuWPx0psbPlDptWifv43bs5
tir2vHahZqWwPvBoqvrawSXrhTX2r2bov2pd3F4TYUJv8BogO2OoMFfNaMp2/I8CxPD3/XcEQvmB
9fV8Pv7nA1r5/KrWqpZJVZWhaZb6uvKWuvyqmvZ6S0tfxQRezEjALUaLiaKqllZoiQ8PNUWIKhH4
ula+qq6ttqqFt/AtVTV1+J+rrark21oslVUNlpYJfBPO6Zesvn8v+bpGHprhCxvr2qB+QZulraqV
tzRWhkEDTcIDKpraG9ta6qpaQ+/bwpD2Cn9LawBfWcUPamlqauvXQwvf0FSJ/xndVktjKw8WqKvm
qy0NdfVT+cnQeb61vbytvopvgQdU1jXWtPLQHxhIg9ABeG5LIxgglM9u46urLG3tLdCzlipLPV/X
Bs+oaA3mWxssYOMKSzNwXKWhvb6trhmabGxvqGqBkq1VbUIDrXxzSxP0GHcYWq+vb5rM18LU8HUN
zZaKNsEKeKagZ1CFr69rhGeBzcrraoSGyYPaqqa0QeW6CVWhdL78WvkGS+NUvqIdppf0G5uzsWoy
32LBk1IHw4aKlga+vRk/BlqsAU1r3TQo3tYEA5qEh2ThJ1taGsizsIErai0t0LGqltC/8C8shFW0
VTc1trWKRTGvtkDnJuByJU3t0MWpfHtrFXQNZgVn8xawSFVLQ10bnvXyqUKnMwqHDITcFiEh/ksn
uMuTa+sqavvVBaxrrKhvr8QO18RX1rU218MDcN+bW+qgQAWUqmpsC+Xps5sawbD+dQF8VUM5rnS7
qUZa+L49Eopj1wAztYIPVpD563u64LxiW4lCB/zr4CngQtg7W7CjVTZNbqxvsvR/KPTZQnoKE9Hn
5k3tbc3tbeDG+J9LwGVqq+qb7xrQX5kLYSbCKquqLeCMoZbW5il/3zj+vnH8feP4+8aB/r5x/H3j
+PvG8feN4//gxiG+1/7Tny4lx3ez8/cpnZjBQOZR0kHJXErmUDKbklmUzKRkBiXTKZlGyVRKplAy
mZJJlLRT0kZJKyUTKWmmpImSRkoaKKmnZAIl4ympo6SWkhpKqimpoqSSkgpKyimxUFJGyThKxlJS
SskYSkZTMoqSEkqKKRlJSRElhZSMoKSAknxK8igZTskwSoZSkkvJEEpyKBlMSTYlWZQMoiSTkgxK
0ilJoySVkoGUmClJoSSZkgGUJFGSSEkCJfGUxFESS0kMJdGURFESSUkEJeGUmCgJoySUkhBKgikJ
oiSQkgBK/Cnxo8SXEh9KvCkxUuJFiSclPCUelLhT4kaJKyUGSlwocabEiRJHShwosafEjhI9JbaU
6CjRUmJDiTUlVpRoKFFToqJESYmCEjklMkqklEgo4ShhKWEoQSJheinpoeQWJTcpuUHJH5Rcp+R3
Sn6j5FdKrlHyCyU/U/ITJVcp+ZGSHyj5npIrlFym5DtKvqXkG0ouUfI1JRcp+YqSC5R8Sck/KfmC
ks8pOU/JZ5R8SsknlHxMyUeUfEjJB5S8T8k5St6j5Cwl71LyDiVvU3KGkrcoeZOS05ScouQNSk5S
coKS1yl5jZJXKXmFkuOU/IOSlyk5RslRSl6i5EVKjlDyAiWHKXmekkOUdFNykJIDlOynZB8leynp
omQPJZ2U7KZkFyXPUbKTkh2UPEvJdkqeoWQbJVsp2ULJ05RspmQTJRsp2UDJekrWUfIUJU9S8gQl
aylZQ8njlDxGyWpKVlGykpJHKXmEkocpeYiSByl5gJIVlCynZBklSylZQsliShZRspCSBZTQsIeh
YQ9Dwx6Ghj0MDXsYGvYwNOxhaNjD0LCHoWEPQ8MehoY9DA17GBr2MDTsYWjYw9Cwh6FhD9NCCY1/
GBr/MDT+YWj8w9D4h6HxD0PjH4bGPwyNfxga/zA0/mFo/MPQ+Ieh8Q9D4x+Gxj8MjX8YGv8wNP5h
aPzD0PiHofEPQ+MfhsY/DI1/GBr/MDT+YWj8w9D4h6HxD0PjH4bGPwwNexga9jA07GFotMPQaIeh
0Q5Dox2GRjsMjXYYGu0wNNphaLTDpO3FBKLmLvdkD4iZu9ztATpIam6XewLAHJKaTWBWl7sGYCZJ
zSAwncA0AlO73AYCTOlySwOYTGASgXaS10ZSrQRaiHJil1sqQDOBJgKNpEgDgXoCE7pcMwDGE6gj
UEughkB1l2s6QBVJVRKoIFBOwEKgjMA4AmNJvVKSGkNgNIFRBEoIFBMYSaCIQCGBEQQKCOQTyCMw
nMAwAkMJ5BIYQiCHwOAuQzZANoGsLsNggEEEMrsMOQAZXYYhAOkE0gikkryBpJ6ZQAqpl0xgAIEk
UjKRQAKpHk8gjkAsgRgC0aSxKAKRpJUIAuEETKSxMAKhpF4IgWACQQQCCQQQ8CfgR5r2JeBD2vQm
YCTgRZr2JMCTeh4E3Am4EXAlYCDg0uUyFMCZgFOXyzAARwIORGlPwI4o9QRsCehInpaADVFaE7Ai
oCF5agIqAkqSpyAgJyDrch4OIO1yzgOQEOCIkiUphgASgOkl0CMUYW6R1E0CNwj8QfKuk9TvBH4j
8CuBa11OIwB+6XIqAPiZpH4icJXAjyTvB5L6nsAVApdJ3ncEviXKbwhcIvA1gYukyFckdYGkviSp
fxL4gsDnJO88gc+I8lMCnxD4mMBHpMiHJPUBgfe7HEcCnOtyLAJ4j8BZonyXwDsE3iZwhhR5i8Cb
RHmawCkCbxA4SYqcIPA6Ub5G4FUCrxA4TuAfpOTLJHWMwFECL5G8FwkcIcoXCBwm8DyBQwS6ScmD
JHWAwH4C+wjs7XJIAejqchgNsIdAJ4HdBHYReI7ATgI7CDzb5QD7NbOdtPIMgW0kbyuBLQSeJrCZ
wCYCGwlsILCeNLaOtPIUgSdJ3hME1hJYQ+BxUuExklpNYBWBlSTvUdLKIwQeJnkPEXiQwAMEVhBY
TkouI6mlBJYQWExgEYGFXfYWgAVd9uUA8wnM67KvBuggMLfLvhBgTpc9bMbM7C77GIBZBGaS6jNI
vekEpnXZVwJMJdWnEJhMYBKBdgJtBFpJ0y2k+kQCzV32FQBNpLFGUrKBQD2BCQTGE6gj9WoJ1JCe
VZPqVQQqSckKAuUELATKCIwjMJYMupT0bAyB0WTQo0jTJeRBxQRGku4WkQcVklZGECggkE8gr8vO
DDC8yw4/YViXHXbvoV128wByu+xCAIaQIjkEBnfZQVzAZJNUFoFBRJnZZTcLIKPLbhFAepfdbIC0
Lrs5AKldtpkAAwmYCaQQSO6yhfOdGUBSSV26EoBEAgldOuwa8QTiunSDAGK7dMUAMV26UQDRJC+K
QGSXLhgggpQM79LhgZm6dHhthhEIJdVDyBOCCQSRxgIJBJDG/An4EfAl4NOlw1byJmAkbXqRNj1J
YzxpxYOAO6nnRsCVgIGACwHnLm0pgFOXdiyAY5d2HIADAXsCdgT0BGxJBR2poCVKGwLWBKwIaEhJ
NSmpIkolAQUBOQEZKSklJSVEyRFgCTAEkLnXptwDS49Nhcctm0qPm8BvgPwBch10v4PuN5BfQa6B
/AL6n0F+gryrkP4R5AeQ70GugP4yyHeQ9y2kvwG5BPI1yEXrGo+vrGs9LoB8CfJPkC9A9zngeZDP
QD6F9CeAH4N8BPIhyAdWEzzetwr3OAf4nlW9x1krX493Qd4B/rZVkMcZkLdA3oT806A7ZdXg8Qbw
k8BPAH/darzHa1Z1Hq9a1Xq8YlXjcRzq/gPaexnkGIi59yh8vgTyIsgRzUSPFzQtHoc1rR7Pa9o8
DoF0gxwE/QGQ/ZC3D/L2gq4LZA9IJ8hu9VSPXeppHs+pZ3jsVM/02KGe5fEsyHaQZ0C2gWwF2aIO
8XgacDPIJqizEXCDeoLHeuDrgD8F8iTwJ6CttdDWGmjrcdA9BrIaZBXISpBHQR6Beg9Dew+phno8
qBrm8YCqxmOFaovHctU2jwWcj8d8Ls5jHhPn0VE4p3DujjmFswtnFs7aMbNQPZNRzzTMzJk5feaO
mR/PNOfKVDMKpxVO3zGtcGrh5MIpOyYXTtrRXihpt2tva+d+aWd2tDPp7YypnWFRu7adb+c0bYUt
ha07WgpRy/CWOS2dLZLEzpbPW1jUwqjw98a2GNwz8ReYzmix0mZOLGwqbN7RVNhY3VA4HrpVF1dT
WLujprA6rrKwakdlYUVceaElrqxwXFxp4dgdpYVj4kYVjt4xqrAkrrhwJJQvihtRWLhjRGFBXF5h
/o68wmFxQwuHgj43LqdwyI6cwsFxWYXZO7IKB8VlFmbAkJGr1pV35bS4A0NdoSfIwKSaDGbD54Yf
DRJk6DQcNXC2Ni4eLmyAjTOTNsyZaXKe7fygM2fj9JYTa3YKCM60cXzL8fz/V92dRTdRBlAcnzsD
WAnJpEJSFGuqyGYEqYq4d9rCgMZKoak2raZHjftuUhXXoqJ1KYIiuFt33Ce4oaLgvov7Ai6ooLiC
4r6F/wSPTx5fa7/M75v55kxyMg/3PuVMylaX9ervlI0Y5RrRcLQiakX8e4vWJd3ivmrc+n3lmOK9
1kUHD3XtiOxILGKOj0VklC4vXVNqRRaFl4RN25ZtF2zTsbncDsVCpj8VQpYTqhzr2sFY0PSnQtCK
OkHO+J84rF990rUDsYDZWBWYFDCdQFWt6wRGjnYNSxWSoTA7q8R/MLMiMddaKP9H9L0NaWY+2RCP
JxaUGFMSXkl9i6cOb0iDPzuTm70+HZ7R2NzSlJdmpPIya5PeAP9vd4vr6Z2dRnlNwitvaJpvdXWV
16QSXrt/7DjF44J/bHBJKp7OtmXj8VyaKZ3NxYsbK7X5q7h/0t+yOdb+q624/ucxzv8+1l/GrjXL
yP19Lvffb/q/D3X3F+j5I2/4/xZdXTDPMTLm2TgL09COM3EGTsdpOBWnYCpOxkk4EW3IIYvjcRyO
xTE4GkfhSByBw3EYDsUhOBgZHIQDcUDx4U8ZsxVp7I/90IJmpNCEfbEPGpFEA6ZgMuoxCXujDnsh
gT2xByZiAlyMxzjUogbVcFCF3bEbdsUu2Bk7YUeMxQ4Yg+2xHbZFJUZjG4zCSGyNOLbCCAzHMAzF
EGyJwdgCm6MCMWyGcmyKQdgEG2MgyhBFBAPQHxuhFGHYCCGIfgigLzZECTZAH/RGr+oCswUTgmFk
xDn9hT/xB37Hb/gVv+Bn/IQf8QPW4nt8hzVYjW/xDb7GV/gSX2AVPsdnWIkV+BSf4GMsx0f4EB/g
fSzDUryHd/EO3sZbeBNv4HW8hlexBK/gZbyEF/ECnsdzeBbP4Gk8hSfxBB7HYizCY3gUC/EIHsZD
WIAH8QDux324F/ORh4d7cDfuwp24A7fjNszDrbgFN+Mm3IgbcD26cB2uxTW4GlfhSlyByzEXc3AZ
ZuNSXIJZmImLMQOduAgX4gKcjw6ch3Mx3chUt4v8i/yL/Iv8i/yL/Iv8i/yL/Iv8i/yL/Iv8i/yL
/Iv8i/yL/OsE0AGiA0QHiA4QHSA6QHSA6ADRAaIDRAeIDhAdIDpAdIDoANEBogNEB4gOEB0gOkB0
gOgA0QGiA0QHiA4QHSA6QHSA6ACRf5F/kX+RfZF9kX2RfZF9kX2RfZF9kX2R/e7u4R4+Ut39BXr4
GNiaXgdLodOmDQplbmRzdHJlYW0NZW5kb2JqDTc2IDAgb2JqDTIwMTIyDWVuZG9iag03MiAwIG9i
ag08PA0vTGVuZ3RoIDc3IDAgUiANL0ZpbHRlciAvRmxhdGVEZWNvZGUNPj4Nc3RyZWFtDQp4nJXS
zWrDMAwH8CfIOxhy6dghiZ04DZTA6FroYZ8dO+yWOnIXWJ3gpoe+/WL9wwa7LbSlv0q25FrJene/
c90okmffmz2Nwnau9XTuL96QONCxc1EmRduZcRZ/mlMzRMm0eH89j3TaOduLaLWKktcpeh79VSxe
Nu8Pdy+3ca5incV6Hesq1jIuZfiSb/lVxHoTa3UjouTJt+Q7dxSLD+pdFn7aX4bhi07kRpFGdS1a
slPNh2Z4bE4kkn8U+F36dh1ISHaGA5m+pfPQGPKNO1K0SqenFqvt9NQRufZPXFZYdrDms/Gcrqb0
NJVpHZRJVq6CshTSGStroBwiqGDJJaRZxZy5hFqoYmkLGVY5xyxrWbHKFDKQZFUphM4qVCjRy6GA
0IuZM7kXlaOC4gqqQKY0UNhFTpUgguaYhVpWidNKZJY4g+QTqUMJcWeKEFOQxT+o0IvNIexi0Yvi
XXLuTBam4Wub7ydcYJjVn7ExF++nieKB5okIs9A5+pn5oR/CKn5/A7Uhy54NCmVuZHN0cmVhbQ1l
bmRvYmoNNzcgMCBvYmoNMzkwDWVuZG9iag0yNyAwIG9iag08PA0vVHlwZSAvRm9udA0vU3VidHlw
ZSAvVHJ1ZVR5cGUNL05hbWUgL0Y0DS9CYXNlRm9udCAvV1lWVUNEKyM0MyM2MSM2QyM2OSM2MiM3
MiM2OSMyQyM0OSM3NCM2MSM2QyM2OSM2Mw0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZw0vRmly
c3RDaGFyIDMyDS9MYXN0Q2hhciAyNTUNL1dpZHRocyBbDTIyNiAzMjYgNDAxIDQ5OCA1MDcgNzE1
IDY4MiAyMjEgMzAzIDMwMyA0OTggNDk4IDI1MCAzMDYgMjUyIDM4OCANNTA3IDUwNyA1MDcgNTA3
IDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDI2OCAyNjggNDk4IDQ5OCA0OTggNDYzIA04OTQgNTc5
IDU0NCA1MjIgNjE1IDQ4OCA0NTkgNjMxIDYyMyAyNTIgMzE5IDUyMCA0MjAgODU1IDY0NSA2NTQg
DTUxNyA2NjQgNTQzIDQ1MiA0ODcgNjQyIDU2NyA4OTAgNTE5IDQ4NyA0NjggMzA3IDM4NCAzMDcg
NDk4IDQ5OCANMjkxIDUxNCA1MTQgNDE2IDUxNCA0NzggMzA1IDUxNCA1MTQgMjMwIDIzOSA0NTUg
MjMwIDc5MSA1MTQgNTEzIA01MTQgNTE0IDM0MyAzODkgMzM1IDUxNCA0NDYgNzE1IDQzMyA0NDcg
Mzk1IDMxNCA0NjAgMzE0IDQ5OCA1MDcgDTUwNyA1MDcgMjUwIDQ5OCA0MTggNjkwIDQ5OCA0OTgg
Mzk1IDEwMzggNDUyIDMzOSA4NjcgNTA3IDQ2OCA1MDcgDTUwNyAyNTAgMjUwIDQxOCA0MTggNDk4
IDQ5OCA5MDUgNDUwIDcwNSAzODkgMzM5IDgxNCA1MDcgMzk1IDQ4NyANMjI2IDMyNiA0OTggNTA3
IDQ5OCA1MDcgNDk4IDQ5OCAzOTMgODM0IDQzMSA1MTIgNDk4IDMwNiA1MDcgMzk0IA0zMzkgNDk4
IDMzNiAzMzQgMjkyIDUzOCA1ODYgMjUyIDMwNyAyNDYgNDIyIDUxMiA2MzYgNjcxIDY3NSA0NjMg
DTU3OSA1NzkgNTc5IDU3OSA1NzkgNTc5IDc2MyA1MjIgNDg4IDQ4OCA0ODggNDg4IDI1MiAyNTIg
MjUyIDI1MiANNjI1IDY0NSA2NTQgNjU0IDY1NCA2NTQgNjU0IDQ5OCA2NTggNjQyIDY0MiA2NDIg
NjQyIDQ4NyA1MTcgNTI3IA01MTQgNTE0IDUxNCA1MTQgNTE0IDUxNCA3NTQgNDE2IDQ3OCA0Nzgg
NDc4IDQ3OCAyMzAgMjMwIDIzMCAyMzAgDTUyNSA1MTQgNTEzIDUxMyA1MTMgNTEzIDUxMyA0OTgg
NTI5IDUxNCA1MTQgNTE0IDUxNCA0NDcgNTE0IDQ0NyBdDS9Gb250RGVzY3JpcHRvciA3OCAwIFI+
Pg1lbmRvYmoNNzggMCBvYmoNPDwNL1R5cGUgL0ZvbnREZXNjcmlwdG9yDS9Gb250TmFtZSAvV1lW
VUNEKyM0MyM2MSM2QyM2OSM2MiM3MiM2OSMyQyM0OSM3NCM2MSM2QyM2OSM2Mw0vRmxhZ3MgMzIN
L0ZvbnRCQm94IFstNDc2IC0xOTMgMTIxMyA5NTJdDS9TdGVtViA4NQ0vSXRhbGljQW5nbGUgLTEx
DS9DYXBIZWlnaHQgNTAwDS9Bc2NlbnQgOTUyDS9EZXNjZW50IC0yNjgNL1N0ZW1IIDg1DS9MZWFk
aW5nIDIyMA0vQXZnV2lkdGggNTAyDS9NYXhXaWR0aCAxNjg5DS9NaXNzaW5nV2lkdGggMTY4OQ0v
Rm9udEZpbGUyIDc5IDAgUg0+Pg1lbmRvYmoNNzkgMCBvYmoNPDwNL0ZpbHRlciAvRmxhdGVEZWNv
ZGUNL0xlbmd0aCA4MCAwIFIgDS9MZW5ndGgxIDQwMDkwIA0+Pg1zdHJlYW0NCnic7L0HXFRH1z8+
d+7dvgvsLn0pF5YmdemgIIsUBURpKlhZYBGUJsVe0Vijxho1iV2jseHao8YSTdRoYhJjuiYxMc0S
jcbY2N+5dxYENE983t/ved//+/9E/fKdOdPPnDlzBnVBFELICk1GNCpMzk3rbj/hyGyQXENIk987
NyRsRn3ZUIRckkFWWFxpqBk99EtHyK9HSPxV8ch69t0PXpEj5D0ZIYFVac3Qytykr6FH/3kISdRD
K8aUvhW2zgqh8DUIuarKjIaSt85ndkYoaxf0F1UGgoXq7grI/wx5r7LK+tHbto5SIZQNMuW0iupi
Q9NCKEFFCyA/s9IwuobB56Cs3gmEbJWh0jhbbSWEfCxCDsk11XX1CBaC0JwJXHlNrbFm4Ce/3YT8
awjZPAYZxf/mGGm6Adsi/pems65REyWU+E/vMf2eghLh1Y0aXxBpMUWFynQSoSDAisbOAqQzCKUB
QoqhGqMxxazO1WXrAttIXNa6TXZBcfzv3qgI1aFqVIGMqB7Qlfut82jTGWPrc+366tzB4/rtWZMp
2/Wg+8pBMUuyVjfaXdY10icAQatpTGFs0/2I05LLc3NSk+59WdlDEbpep2idKiWASU2Zw0+S7sMI
1bh/YqidTs1lxGp5P2NdvbG2ik0y1BhDbXUqTixSy5IbaosMVSPLKyqModbQG0ilamFemWFUvTHU
VafhBDK1LRGwScba+vLS8mJDfXl1Vai7zpUrptX2luK88koYxVBZU141lE1K1Lk5KHThoWG6CB3/
q7+DIpTLhoeFR8ZGxvbX5baZbJ/cUAedHRnfqq+xtjy3fGhVIJtWVRwcGqDrRAbybCngh2JzW8bK
NdaOLC821nGDNlKebbVCCRDdSFkjkEtxI0WhzWdM68+eY3dIJ8zaOqPht929bl0+Zn1kqOHwuhKX
Lw7ePxO+ZZpuVv7EF78c/nXUSusjH14bfXvUxonVcUcW7VC8WXanYvGZwzlBW3rE3937yaAhGrzq
Qchwt/X31q3Y6HwKfzupZ84Vq8JrepeJBxSXEt7dfXnG4SFjh4UG08unqDd1Z98PrVP0Czo3OiJ8
iWq56sClspA3rl45PvtF/7fneMwoPTw1v191w5G4N3xmDDpjYxe3atovecekVSeaT6Z/fUCkfNlz
/JddfT90G31tVejpW1c9nb48sat70grnIavdXvp+8N0b429N2FJEzb+bKbt03rPvpiXnts8cuf3G
m4rfv8/8fPXDstXbbbvsmnHsIKbB8NdN+VI35TNdhFAMFisQiCiK8dP56Lxa8jpqumNZfX1N55CQ
6uK6muCRoPc60HtwcXUlbzuuaooyM2KdEAhTSJfIydyZzroYXdTqiNVh03WW5sW1Fe1ahxBbaWsq
SYnBUIu3VFdvRq6TtsyCFuusOKE1NxYDJ0AIM4S8kgHLXO+kc2ixb1otz8tNBEOLCQoNigzvcCro
KVNQ+vD7v+QfT3YJnTVmecDSI41bqYsuPc81zc6vuizutG7wqTOL1D8yOYqb3X1DUEzT96cX9Vpx
wbPI7l5CtEfvmtDJt+bEzNj1008vo+YP+izt5fXRZt9eY7fvMyT+7v/+j6c/H/z1wYAXuu55bc/n
3/Yzv7X75MS7H8hX/vZyc8DHXXI0mhjfewnpcIbNukb8o+UcK34O+O3CZ51mOoYJJINXjJzZ8Rz/
R07G08dRF9P2OPZ7zkFDdEFkUJ+/G5QrM9b+7ZE0Zfn1+PrjsrHTHJNLGwZNPLF/VbGPOT7p1fHK
GBvvPnWfN/iWP+51gB34sfT+ao3/9T59PQyfuX35/aHw4e/e/HpdtHGeZpF8b67bwPGlkUMEs1Oa
R/a6nDt57RT2te0zB64V3/tBd/+GZ3TPbtL3L7/jfuJin5+nJOzJWRf4BjX29to35kY2r7o6aJhg
VfzwK0eWHm0+W3hf/6NodfKvU7KrNvjf3jvbxu/6/K+Eq6dnrRiXLlboXM/YrBx+7+f87cxm/XKT
30/z7bfGXcmtzvg48rU91SWuu5YGHoz/ccyvlWPv21/12bbj5vLcffrAJfvHvNF8IWdLp/qJ3a7F
uq0dZn+14KBX2WdocpLNjMnDLUfyjG7Ku//FIylvPZJYh3Th5DAG6vx1fqt9VntN9/yrw1hfVxdU
bOCPnz1//Lgu/sUJFB59rhMY0fEEcrs8Y3TNF71yKHbAN2NON+pOPD7gtPTwAvT24XPn3rlj9Zn5
fubR8CKd8uTdes2FhZeGvMqqd45PeSvr3NQfJztMfd130VB16sMz+5cl0mdfyR4gmDNpU/XvmiyN
V/Dt8rkVnvcOnrFfcl1ef7Rs1Oe/Li+acazupT9n1Y/Vblm3bNzLO+/N7zQiM7hB0yPxi9/2KNi8
i6NWv9xYXP5Y8sHs3xoOSl75/L6yj88KQ9hbY3HTuOlvrX17jmfg6A8jRx5aWDfw/oGrPe2k2rPf
f3QhIjhNbxdnXTjW650NpTeXflDza9cf7ygmfvXh+HUjR5Qfe7V3d12kx861O5yL4gI+n/eGv2jc
Z467Bo777rUN1c1xs7bpGhkVuIAHxAVYo2NoTlzcTOWHXf8ovnZZ31ZjDHiAmpazLVN7JlXXjKkt
H1pWz/oVd2JDY2Oj2czy4trquurSejapurYmONRN50Iq27Uvqa4ld7WHzp1sk+OT8pzq6no2saG+
rLq2vH4M5x5io3WhoTpdtMU9hOlCw8JDLdn/gRn97VWODx+rudrldi+N36qXRw/W/bJ281zvIX82
L+m5bl/za2vZruOz176ydn5h2PAPu5WMubF15Om8L27/+up0l/mrppXuOjl8bJH2omvcJWtq4U9L
TxwJKl2xosxn+fnOgUfke/J9jqX+KO0aszRws1/spmtpU7tdmWZ9cEVFH8PWxvFrCoNG9fx5+e6S
LiuyXELFXrarNv+4IMDxavyyYtvCfIFxlWt0zox7r99cjN/RfHykT8quWZOPdL6Wt7jX9sevj62s
77XD8exSiZ8H6vdSYXn0wQyVKK6vecDD9aVS8caPpvTtd3Nvl8H2U0YxX/zx1vbJS5qbzk26+Lpz
7cC4M4d+E6/z1O0SvnB6FztK/cJli9/YpJuyQTdlLXcuKWbKCt2UlyfbDDhfc7O8dqU2e6KtKXOe
+b01tf/9+9f4NzbOe4UlP8mOzv39ZcfI6/spr89GKX8fWBi2aqXsva6CBTPnn+581eP2b/0WBe5Z
3f1U0c1Hn57t0qX/5qi88mavyoTTZ9+4JBj/dejc+FU2NcMONqt6O5YffXQ+6YqyP9v7l6JxO95w
OhUQ7R30lnGNara3dfG6e3ku9z1OX7T7PWdrVVKY6HGjw58/DK1QZP9x+FbOu4d/PKF7xIZKZrou
6eSc+Ykr3nBr8jf07gF3dn59qt8NY9q7OXl7d9N+KvNLF38Tz5+4/+WTW6IDvx/7/aZRV0auRueH
JRz7KGr2N4mqTZHDNMO+jPz2ggvz/aYU5lT/8JiqTBdF0T7p2hc//iQvIfWcS5+NNV+qOs9Y1LDq
9Y9Wg1d4G4KDHZbAYJhsee+jyHWL8osTeE2p75stjwTX/ymXoIuCeCEiNDoiIjSCC+DBxYdFtbiE
KRvbhwxqnZI8N6T9DHVlEArUwzg2/BUCjw1RjrGksrqqpGVm0r+a2V8tMwwGfWqZWp0HWYZz25IS
Ix98cNFIFv8oYJ/2JArOk4h5T/L2WXbuocvmrlk3xh6/4OX9x8j3Pczn/Pv2OvPqvkZT5JggdGKT
+JPi0/s2/PHzsWMXd764dK3ogfXexpwVvza+c9jm5KajN4ZPm5erOZj1oISadcz+QmMZ0o9OvquK
6fWwOPubB/EHfojeeblYpO0yQh/R/c7w7al3fevcPN/r5uSWvTdnxcfrzqvfcUoYIay8vcQjeUi3
60dPLy9h9x+LeLQ2+eo4k2vI/o2X7qy5/IqHdXN+aGKfmIk78n/8/lrBGO8t9/xDlAkxo7t2m/R6
2fcTPcscrqYvPDE6Oaf7mt7TZi165ejQcb9IHk6nJ/yxfERcwOuly85eDvouADtbR/Qw3o1T7bg1
w8XVJ6f6LNgeva6R8gd9+DwrDqf/d7gXlVBieYDbgX/BNI0Y/onqasXYM7befwZkDDpVm7fthz9W
+zvYPzx2P3eKzqm1iS1m5G5SlIsa4LmehBJ1Mj7w4d8dqTrr1gBLoKOB2pxL3o0VX/nmd8H+pl9k
sogPG0O7zipK+UT8+n2D8VQw/SCmR+IHe277Tv34ysm+uZv2OL1/9uqt1ff77u2xuLvXD5vdvxp7
4Q/7saovf39Jc008aNcLLx14Mf+gy9klHy9ZHH5nwSXzzFcGZ6Rlxfp0ZjV50Y8mDLRb9PZXLvN+
M+TE/SC6XnpzzLX57/crNi5xTFs99rJx32Wf7c2nVHvfWXv2nSFzan4/8+WWxirRV0anA5v+mH5c
0m3ZLZ+t5WN3Hgt4vanUfcOOGeLhL6v3N0UtdxOsU8esO7pV1/VNj091G88UqVx29Jv7w62xyjcH
x8mjby06tnBmL6a/YOC7H1zc/Pm3ExaM9n24u2rDfGF4/s7B/kprXaMgHFyZhrgxqSF15XuIQQgZ
n/oOxf8Wl/HE98VGhEdEca+laIiNIBvJZXX1/5F1WMrpvyj/25Do3JSlMdsHrr197PKl81uWzL0Y
95r7nLcHTQ8e9NvO2rtbts4ctueLnZ7jZKdObchYMNhT/fP9u9rX9typGrn95o31ce+eOFowMGHL
rrpwn41FUwxj1hTdqZq55HzV1++u+mh9tnKk4c2a2cY1S+1nvT5oyvnk0h++7LtSf+bRVyO9gpN1
6IeLE8YtUX6S77rup96y0zO/Wnsxd3nFmeIzy4etWDi4Z6byp5CPBwwYPCRnXV3QhoPTUhQvOtmN
fE/8xYqNNXY/ZV4rfzzINHz+9U7Z0TFz3klNs1uctazpTtn6Ty9JRgytXznqRdcXhr/8y49DUs5+
c3WE4sNitGhc6LJ5st3qw7vO37h12ePG5kLDjeik+LdJSNRILQSNzHvq7fLEGdz4fPjmhtxzvW9o
ejkJ3da9uuWDxY//wvNt5qRaZsoa3ZSVk5/pRdbUr/+f8H9PBwsZ5OGXrOum06/uujpueuc2D7/K
ln74l1/N8HJOGlJTW13SUFxfF8IdAM7+wfbD+Adh7zYv0SRdoi6h9SWKp4db+h01atSz+jXWPt1h
/bPehDGf31wS88rAZbaD8qrKL+NTP+56+PHxzG0hWyblKb4I2/vnsKuKhx7Oo7puKBu7e8nE2QNv
J52Y+opxwsys7PGNtnen1n269q2BZ3DN+z4VDodybDfMOrrv+zVn1zS8tmBEvOZoX9R3z5/TfL4Y
HP7wovfYwSu+2Pjwzu1E5619Urf1+GpBjDpfknbr99AZ7oeYeQNURvpnWfb5NfLZyw9/fmzTebGd
t8eevf1muXw4YHrkhjOP35hxbXN0wr6k4VfYWymHJm7/+VYf05oeh4xv5UZ8fvonYTEjHF2VZe5x
8JVfkvrP+HKbdPLdgpOB3/8waUD6D2Fjbni+sFAetCtrwDvH9fn5Wz46dyXk2Llrlauix4Q2MqfB
bZ7EFKWbsud/jXNs5+CffBt79ZSrOtvWC9WPChXRAv678Nw1a9l6CR0qb/udc5j6k5ws1ErXttRO
p33SkAmFc7vjasYH/Q86LZuxmY2c/lP1sLVuzFRdTZsm8tAiXeHqqMkRcIcbUAUqh9u8Fr6yKBVV
oypUj+og3RcZQVoHck7GolAUjHQobI3PZK+/tOz6MTXVQ2sNNWVjOsaSTCOFymcyJ27M8FnGmAzv
M96nbJPeP1DYY3bwFon9nWlVaPS4uNzfH2+YRe/Rb3kh51x8QUZIr7fMo9iste4BGz/75osLbrg+
0PXe7QnWvt3umCfQ17LYLVuFK0s2en34ww3bPT9c2NY89dJ771cMWlpVM29aoF+/K2/cXzjS0Wnl
9gt24z1X9ZH+Vj/Abm/ob4+/vDZh+zb23dMFk+brRadvHpkz9fXGb3yXHRi/fnriet3w9G0e2ycV
Viw6/zBR3zPsfdv6mh2D6JRz1z0/mR3QU4CNFfjrhz/NsV33Xf+doTHXN3+vXfCZc+CdgSsff/vd
AJdjN3P/PBOa+1jHZKUNpDLmXuib57joE5eDp9b4Pv5yTSMERY3Uwyf7JQxtpK6B6CfOuIf+R76l
+YxvpMqFYjIBDD5mdYHOsa3lyZ78xQ4FhtdaIgi15m/72NDQ0NjQsIiw/uB92xieirHpf3nBlvix
JStMaRVpb9ht3/8ME7CiBpxaNzUwdEXQTwtvDXSY98O6UyvcV+/uOu3lkY8EYz96+UbXj3799tr0
qaMX/LDqp2X55Tu3NTq8E3LtiHzN7bwFbzpXLOn9KOgIM3WEqm/GZK9ZfkulWd1/XT1v/VTpnvLv
1bZ3LqRdWrxtnXN8lU2P746/tn5XRHrmS91OLj7xyqTILP+MI0scX4puLqASsroc85wm+WZV8anP
HL7ZpX7z9Y29dr65MHJv7Zivb2ye9t2lF1wHVmxSm5hl/cf/fHnN22Fb57+xrBarVLHj2fp6/dKv
jiQNyvikyHXy+glzzort7+QMGvjZSv+Dfe47D5LMHpl/Z9WKpoGZvmja4PSjG65lNW6YtWn/L5Vz
Px+V42IPB51mBNRLSIDEguWCcIQoN8L0eTQdIzHC1gKMMSPFzGqEb+oROw5ZfmXmsiyiEPuQEaJm
RJ0QrcQ+LEKruDL6sEDJ/S0e70ow/7d23N/X0VwKuyEhliLyF3kUav+LgtqYT2H0r3+RljSdTr9M
76M3MbH0MnopPZGeRM9j4uk+dC2dT1fQ1+jr9A36Jv0bfYu+Tf9O36Hv0v3ovkwyk8ik0Jn0K+AR
lUiFHJEL8kG+KBCFoM4oDnVFySgFZaB+qAD1R4NRCSoD31OPxqCxaBI9ma6hp9CL6bHUdQpT1pQN
5Uy5UX5UFtWfGkSVUxVUNdVAjaQmULOoOdSL1EvUCmoPdZQ6Rr1DvUudpRvpKnoqvQTmL0Fy5IDc
UA+UhSrBH9KUAAxdSEkpO4ql3CkPSksNoQZThVQRNYaaRE2kJlON1BRqH7WX2k+9Sc+n19Fv0Fvp
BfQ4eiG1jF5Nr6TXULexiOmGrFEe05NJZbozPegdTA6TyeQxuXgO04s6T33IZFMKajrdi85g0pje
9DYmicmiy+hyugB2CawB9UZ9qZl0PT2SHkwPofvTAxg904d6D01k/OiNdAltpIKp7vRL9Hi6iC5m
OiMRckdC5IFcwTOHoQjwzZmoF6ywJxqGhqNyqpS6B4akwCrshR2wP3bHgdQjxAjfgjrjkR7GjEMT
YYULKTPW4Hfxafw1zdBiWk6raDvaj06mG2B3Z9Mv0mvo95khTDHTwCxwe8Htd9aGtWOdWTfWk/Vh
dWxnNp5NZmvYeexWD4GH2sPBg/Xw9PDxCPYY4rHcE3sKPa09VZ7Onm6eAZ49PAs9jd5nHjJmM2+t
q2H0B9gRvwOjf0YjWkhL+dF9YPR6GH0ajD6PXscgpoipZV5ym+x2G0ZXs46sC8vyo8daRq+3jG7f
Onqux0uW0ZWeTq2jl8DoiB8dYQ0xbHNyi4mbXZuvwdcCc7BZi1Dz/o5H4EpRayr8e+mVgCvqK99f
mY7Qdw++a7oSA9z43SSQunA1vsv4Lv07vufvgr/Tfvvw2+++vXJpDn+OxlNQF9/BzTTDuQPairan
nfnD5Ux6px0BnnQPeiUzkBnMlDClTA1CTA1Tz4xmxredEVNv4bWtkleZ3ZbUUeZ4u7r7/9efX5rO
4E/fenoHXU0vwCJ6JXWeLmPSYParsQIsJZX+k75P3WZy6IX0eOxP36M+pMuZQMafCaN7gc0L4dyI
eS9gDX7AFTyBO5whneUMacAv9OTPUW+UxSSgPIh+uNNUCScmn1oG3oIBfyEEjyGF02wH/oLlPcZg
8Bmcx3AFn8GdqcngMRoZPTUdvMY+zm9Qp6nZcJallBjJKAlcg3KkppTIllIhe8oW2VFq5ERpkDPl
gjwpL6SlvJEX5YO8KV/EUp7Ij8pGnagc5E/logAqDwVRA1AwNRCFUwYUSRWjKKoExVBGFE2Volhq
KOpCDUfxVCVVhRKoGpRI1SI9NQIlUfWoG1WHUqlRKI0ai7pTo6lxKJ0aj7KpqSiHmoZyqRc4L4QG
UHPRIGo+GkjNQ0OoBaiQWoiKqMXIQC1CpdSryEi9goZSr6EK6gCqog6iauoQqqEOoxHUW6iWOoJG
USfQBOoMmogmU+dQI/UBmkK9Ty1HCkqGbCgr1IeagYqpJVxf1D3qkcVHBYK/cqd+o+6CTxBgG2yH
/bAMO2NP8FDBOAAH4RX4VRyKV+IoHIvjcDrOwo1Yh8NwOI7AkTgax+DOuAvuihOwHifibjgJp+BU
3B33wGm4J87EvXBvHI8zcB0eg8fjyXgRrsX1eCQehUfjsXgcnoAn4al4Gn4BT8cz8Cw8B7+I5+G5
eD5+CS/GS/HLeBmeghfi2XgBXo634m34E7wJf4SP4114N96DD+BD+CLeh034JD6D1+MNeCN+Hb+B
t+DteAduwjvxXrwfv4kP4sP4CD6Kj+G38QnwvafA/72Hz+Jz+H38AT6PP8Qf4wvgiRW0NW1D24J/
cKKdaQ3tQnvQWtob/KMf7U8H0kF0CB1KR9CRdBQdQ8fSnekudBwdT3el9XQi7UA70t1oJZ1AB9Nu
tDvN0l60L50EnsWVDqOj8ad0Mn6L7oTfocPxZlqFGqjjaCT1NhpNnUTjqFP8XTSau4ngxuHupGK4
/V6Ce+8B/ZB+RD+mm2kzeGaKwQzNMNQ3jIARMiJGzEgYKSNj5IyCsWKsGRtGyagYNb2XXsUEMDom
iAllwplIJpiJYkKYCCaaiWE6MX2ZfKYfUwDebggzgOkPfm8Q3J5d6fFMbyqAu/moGCoDIdFK8MuL
2jnlLDihdWgy/J6O5qJF6Aj6Et4zUyG1HK1GG9Fm1ISOodPo07+Jb/6tX81jBJVITu8Df6KGG+OB
+XrzRsB+gVUbySLIqRn2icRsY77RQXajeZHZpnm/UIWkfFsF/gikv1OPzQ9wApc3R3F5PAPS1nyL
W6KVzTuaX283nXTwWnmoD7zZOP/bm/gvlA2ebBAaAm+8YvDHRlSKhoJXJh6tAnxaFaAUXnc1aAT/
0qtHDWgkpOstEpIfzfvwCRYeB55wAqTGQ5pLTUSTQPNTWrmxlZ9IpqIXANPg63Q0A81Es4C5r+1l
7XOz0Rz0IuznPDS/NT3/mVIu/RJaAliAFsKuL4b0Mtj7FegV9CovXYSWopf53Cq0FsqXtqvLlT2p
/xpaCbVWozVQcx1Yz+sd6nI1V6FD6DDY1DvoLbC2I5A6jg5A+ji6jL5B36Mf0U/oZ7DaKKo7uo3u
oA9A+6WgdU7nNfzXcvg6tFXjo0C3LZqdCBprr4eRljKiz0ZeTy1lo6DmDNiNxjZtZvP71NIXV7ul
r7b64tbEreiJjKxwUavkybrbtyL12uqsvQZX8JL2pR012za95i9L1qENgPXwlduHjrmW1CY44Rze
QFvQVkiRr0/yLaltaDvaAb5gJ9qF9qC9aB/a35rfDbkn5SZe0lLn2fI30UHeCo6go/z+v41O8LIj
kDpgKT1iKXmTTx9H74IXeg+dRefQSbCdd3m8h94H+/gQfQRe6yt0yWJBF3kL0lIB6Dz6kPFBnwms
KAF9FB3HvdBoyH+Kl6OF+tQhgwcNHNC/IL9PXm5OdlbvXpk9M9LTenRPTUlO6paoT+gaH9elc2xM
dFRkSHBQoJ+Pt5fW093RVmljrZBJJWKRUMD9xQ0KTNGmFrJNPoVNjI+2R48gLq81gMDQRlDYxIIo
tX2dJraQr8a2r6mHmqUdaupJTX1rTcqGjUNxQYFsipZtOpesZfdT/bPzIT03WVvANl3n05l8mvHh
MwrIeHhACzbFsSyZbaIK2ZSm1JFls1MKk6G/nTJpkjbJKA0KRDulMkjKINXkp63ZSfl1pfgE9kvp
vBMe2Qpu2CbaO8VQ0pSVnZ+SrPHwKOBlKInvq0mY1CTi+2LLuTmjOezOwKOzX9xvg4oKA+Ql2hLD
wPwm2gCNZtMps2fPaFIGNHXSJjd1Gvu9IyzZ2BSoTU5pCtBCZxk5rQNQTQJvGy07+y6CyWuvX2sv
MVgkQm+bu4hLcktsVROUt6QRzA1mCOvz8ODmMme/HhVBpmlydj7Js6hIY0L6kICCJlzIlRxtKbHr
w5VMbilpbV6o9eC2KqXQ8mdkmWPT5CI2KBC0z//xhj9QzjbRPoVFxWUcG4yztcnJRG95+U36ZEjo
DZa1puzUhUB9QyEsopxTQ3Z+U4i2pslW241UAAHL7UF5bj7fxNKsyTapCRUWW1o1haQkc/NiU2YX
JpMJcn1ps/MPoHDzNzsjWM2ucAjcC7h5NNknwab4pMzOLyltci/UlIB9lrL5Go8mfQGor0Cbbyzg
dklr09TpGxjOgx+RbwVr61C7pTK3cpG3mM3HGrqA2y0QsKnwRdstDgpsYLv4LLej3eLYfIjiW6rB
KJYaXKpdP5ChvZN6cEU01zSph8ajwIP8+hdT0ljmJPBuErfpywYErXMi4/zl1EhtbkKd2BRjcpsJ
tutUYJmgpbdnzxNzurAMDC3E3Hb2aCmiveHkggxDN7yI20VHtgllsflao7ZACzakz8rn1sbpmt/f
jFxtRnb/fH63LVaS1y5HymNIrgl5QHFLBieBDaYGaFq2lc935/Ot2R4ditNaitnZYm1G7myuc62l
Q8TCCYJFC33SDHNiVBFwNFPBu2lTDVrWhk2dbdhvnlw0e6deP7smpbCsM9eHNq1ktjY3P07DzzUn
f4JmLDeUCmVQGXndggLB93TbqaVmZu/UUzNz++cfsEGInZmXb8IUTirsVrDTC8ryD7AI6Xkp5qSc
kMuwXIbrKQcyYr6+5oAeocl8KcML+HzxfgrxMnGLjELF+zGR2bTIMMgYItPzMu4XbJJjGagY3G0K
W8Jtz/iCstmFBdzhQvawlfCHaqK0XVET1nbdSWGhvEmqNXZrkmm7cfIETp5A5EJOLgLDoOwpUA7n
k2YXasFPgUHlIw1FTJHmumT3m815+R7nNNcLPMDUBgL65zdJAsD3C7zToV53DoUg7t40udjAzQP1
yefairzTigvAbFs6hCppTRLoQWLpAWqk8m04c4RGxbA3sIF8+8mQaZpc0FQQwA2aX17Am7NNE+qh
7QzbTvoU+HADhRTMVmnD+LMJR0HqPYMjCcwN5eYTiQayMFgBUZJIDjMv1kJRcSEL2mZQcS6YOvGl
Ug2RGMElMj5GHlKNpRBxy6K9ZQppkyQYOoQ/XFoWzB1JgbeooIBMns/NsFSAsW2aZDAjnzaqtDQA
7UBRGjcX+DMDpspVPcZ1k70f5WhHg2fhJs33JILiJoV3mgGcP2kvA4k2pqWxmPMRMksfJ4hUxK1c
DnqnvfP2m1/XjvFo8ysoUMtdDpxhIs0BMGxUMLujoGlAQFCguKNUwYtnzxYrnt2A6EusaGUQIgE8
zeroL+ApRSMR6sI/iXrvCbIPshfHJUqp6ygNiagSMH6WehGJEUWV6FUM9o4W0tkahbImm8pOFuE8
lPD1pa8HXfr6HPA5KuTr6xev2zy+eF0VGxsSEqqjlB5KHrZWWCQSCrWewTg6OioqPDysK46MCMZa
TyuAT2REVxzdlQ4Pc8N8VVKTl0JlTkp/8WgA3fuxEI9zT6nq5YXdNVa2cgHFCtwdxPG9g9XWHpF+
fvoQd5FUiAViobhT52TP5MGdnZv30CKZSMra2ztbCRiRXCxhndROVkxzqsDqwW2B1cMkpuLhYjo0
YmhOlGCZVIwZofCQxsG7S6qHUwCrtlbbyK0EanuVUKRWyXzi0x/PETs4O4ikUpHcRipxdLQXS6RC
uc3jGFBUPkLMSdCnI/JFJW/iCXgiyg+AE57UB65ghKP1EifW3cbaxlrivp8SmNTZEMh57dJL8vwC
HBOcM68ncGqjQt4JC79wPVSn2fWvK4bqCkBXQq0Hp1M1qMkD9CTidKoFRXZlmJMq364FDUv3T2n+
VuFgIxRcFYW4UcolJ6Ym7u2UP2vE7tOmsesn5sc403GJc+fOHFfW019ko7FlGn3dE0Zvm5A+viD8
kbKLcfriV7hvxOaYH1APBLbIDqW0X5ne2g7JpHYyJGUENjmCPtwUE1QO3DrCw2AVetnTZTB1byua
NwY12XURhSiZvaejM6sS4j8phb2HoyOrFmInkVwkEMAX5quWFPfXL9nm6/S39BnkA3Y79008CU9u
nc8uiavYbT+1Y7ePr08X8X5q+z5k7UOpaZ/Q/dhN76BGki6+rj5C2iPN/75zetSfeqtMuic/MV6x
ZOrXL8B74evr4cpwm+tKTtUavf1zNOTW1WLkZH1gwkx4mL2DxYxFIh8fMHnGztYNc0cgmg5kvPxt
nW2gW0XyoNouWeVdHexCMoa9WFAwKUzN+PjZamwY6uOQyuSofkmh7tYy96iA6OrCdJWT0ooRySRv
sD31/jED6+Nj5i1+sTqpR8IAGytaLBddS0kJzxteWxWoTYnVxlcszOf2sCdorS99GkWiGR105uKC
lJx6XP0i7vm5CyiB9I+QdPYPP+Rk44SltJPtA713JjG+xxcQ6CbgegIkgEBXJ2JDOAW5/LtNiQFj
Tk1EJ/acSkBbdpxZ804BdOfG0H1FVmq5lVtoRmd9cZrOTdG/IHFQor+NWMJIFI5xvQeGrlllF9ar
dqnBLz0x0lVE91L5eNi7erlF9qmoGuozdBjbibW2knto3Zy8XNXr18YvWDR7uB5MzFllsSUmVlCJ
AlFCR73opR5BCZ5QIPGM5tTjbOcZSPumglAiRkIr3X2X9M4d7QDMIIE/xpxewsMmzLA6cYJTj9Nz
N33KihiLJrBD62lpMSN7YkVBtJe/nbONALO8FXXp18XbTmSvyxg2Jz+gZ9cIu1JKass6ObqrBLj5
IhhTZJ/kUNamW1pbU9rkkZHQyT0iJS3dvfNLC+YM76b2CHaimkUK7tgpRI+LUnqE5gwbURVsGBo3
bGE/0Fwm2NNrcAqDUVxHze31D4sWMkiyH1vpJVql3I22tdWG7McKvR3SCt+KjvZ3UyrlYR/6p8sv
690yW/2aMjZEqYoNAbO6AD4uxCEWzp8Df/7Uz9GqxaK0QmE7a8KitqeR85Kc+rCIq0G/pp95YfEw
kaC4Wl+aoZNIJIxYIZbH55WEFUwvCHSK6jvq1aK8hgzPzVnpiSWZ0crS8rl9tPgHuIX8PbpqSoap
7dUKudTF1Vkid1DL/XLH5yUuWTi9tKt/t+zo8ISgnsYY56A4RJnjmxfRoYLRcM/O63D6VG5K94PU
D+DLlNQPem1aXA99Whd9mr19mr4Lg/zlV3p1d4u70sXdS9WjR9QVvVfvloWfAGt5fCIBtHXCAe7b
EE4LoLFWn6X++6ZEZYzlEIKDIhpj4BLhdAZOtOUcEoelbjmY4Zb72sHeng7FtFAsFYrsXHwcAuID
3WTK0zIFI5TIrERntig751WlBMWKGIZmoJZIpLC2s/GPD3CVr58slcFlLVdIJzrZxPWpTrLXdXIX
CoWCaEZp52ALd7XYOTovtr+1UuboYGcjfbQ1b1y2r5VQIJcyaq4CTdNQoQsdplCJHRztVbIJOeOy
fAUSuVCgAvvsBhrnbok4lI12dzjZivCIuLj47CxXl3iX+O7c4faRdUIuEXHIhRFEp7lnx4czXvr7
unQ/yV2VyqHnn16ZDt/qBb3b3MAh6HqA5dByd0Z4yInrJ2z4835CSYWryBZ4/pd7hJ0RPHMLoqKe
93Jxtele9XJh7qxO1jJKIJLZSORecQWJUf0SO0mVnjKb1IFVsRllCS7EUTx14fRNCnO3hrjKh/cS
wVmje/t5OEjV1kJ7e0e1zM7Z3j4wOWTAaA/vjATfsH6jUjovWDSnslvbKygst2JEdVBAj3C3+IpF
/eAGSjA/oJsEI1AimtBhP7TBTl6JEChoZY6yxAhGoL6vj03XOkmRV7DQrVOqW08BcZScZjh18SoP
ORGmDD9Hwgzn527XNvqIimqJQkW0RUZZfCzkRSRpZysUgY1L7TgXqhRQ1RCGaALcI6uHZCizsNTW
w9EJxJiSYomdB1eFobIEVtbWQpvkgdVd9P1jncUiJ7FMzDDwBQc6Jzq66rS2XSsX92ke0SIWxIjl
XEoubi53jorUqbQZCf7eif0jvJK13C0FmqNuCkKQGnVCw9rrbncnd1s3tB8X6WVSdzc3W/dOjJeT
9X6q+16B3ivNyXLBXMq8ruSVdvHCdSUENqCzfX9Tl/MNFqVYYvOOQdvPAqWLv5urjwoLhCoNpLzV
uPneE5XsgnvHgyiNOQvOQSp18HFx8XaSSJy8H4a2rJ2eJiJrF3FRSlewkV1gIxFP3cb+jBrONc3Q
Af5q207w212vCnDzVyt0abZuKkGAeyeRk1eqU09Fmy3nr+ITJ5zBSsjZhKMZxq2f14De7m9b8w5S
KKIoe/4m4dbvSz1lK5YEvUvp1DyGUkjFYjutswtrK2WavykGy4Fw1l0pxJTsiYmso9aIbZ21jo4e
ajG9Wu7s0LyzuYvKSSRRiAVwfiTU7WYFryFQzhPrePQRNUaiENHwqiHniboFurJD3Tvoygaicr0U
QWAOoXeq5RDw++9sOTCypwthrdEdVnb12fbt9LTdIjIfwY/gcQeg1zvMJzY5KCg41sHe06OX5wA0
AAaHmFwa4ynLTVf63denpccEg3NB9kEyzwG9kmOtwrumhfd0aT29luMLNxac+pATEEYqYRtVsSeA
3uE2lFuRx7/bV0dP4NPOETxLZNGKxTE4PPEPgqFU6y6DfwiNDxtemM55B15oI6SqRYKwuPBhRNii
0j2URO1qa6exZihP65SBlbFxfaOdadvUgRUxSf1jHNu5DdcIZ33P+OGL+jZXPRG6dXaKT2svpF8A
g6E5D7zVEx4HHrG9Q7Q9E/x9uuVHaJO9UIsXhl3qjMZ12CWfUGdnjQ9jRSNrypa2tvK2u6+PSvfW
WDHO1qE+YjYgje0pae9QudMF2wFb0LoP9n/fynKqnl/VdJNYNALsr8UFiwQR8R0dcDttJg8eEc/p
EF+EVT9+/4nK3Dvbx2f8S5V1SsoHj9sLotsPQUsOKATlt9cT95p310uQo40jVtOOXlz4IJO73lWn
d7qiFz2JSy0PSe4xr5c+Xdwm9noSmbY8hvg7nKE/dInNH/XyoMJZ+f6azv34VIH/drvQ3jFxRZmx
3ir70F4x8QYuhevSV8yfODg6OH9ydvqKeZMGR4fkT+4flhXtFpBWVN0QE5YV4xaQXlRTj7D5z+bF
9HlYmz+8eRZ2jIw8IqPkikhFpKPCwRFxS3MJcJBHRXowIt19n3QHhSPLqDRpqt6xf7ZZDL+x5Fa+
cD2Ec6+t7pa/nZ+/gzZa8W1jH22NQdRyZ4vs7XktnSchTFB61wj7PlgCd44DvHWox5h/FoE5WCXB
s6jnUL3LNghofKNqCjOUHiEVyZHwqPawxtM6L1g8pyJRxQY4N2e1+DPmF4hjwC62eGQk+kf0G9U7
oEeESxzEMRtSU8LyhtXWkJOEb4Mew1FFx5ejn1LpqnJBri7y/ZSj3kYflK5yUfq5+godPNMcWj0u
OUEhJ1pvpANI/jfVO0bsf+Wb7GFmsA6FWKx2cLP1LOjbXdm7/c1sOSseDgnp2b5KrZuDUEi/yji4
sRqVSCrqUjYvt7n66SOyvlPPWE+BSCIUcr5EYr6OfwUNpKJt7TVwCFzIY3jSRMALMMC+C/xGWusI
vSblAz9WoBPoBbRA+oE+nb3vh/xt/LGc9g+5pNc8+zsFSnKLc99T5F43nEF5/d/01f47D+C/3ZjW
u719sA3RIff6xhaN/iqUWUvkHrqk4MDkYMfIrEG9I6OHLuwfkpukU4hFWMh/X9AzOic+uneEU0Tv
gb0jI4a8kO3TPS5QJqMrpB6svdrR1ikg2s0v0r9Tl9yE1DH9Qq3sNXKxUi625x4wGneNJijOwz8y
wD82V99tRG6wXGUvk3KaHmG+iU8y21AKmt3B1jpFBQZEB3QTSxIlidGSgABdtEO0A9J16xGdGCcO
vCIJ8IjqYf2n3qP1rIEKroedi42Fy/Qcp1RVrOXAnjhhM4N8u0L9HK1bLFFL//V7u/XFiFtfjPwb
E5/EQqnMSnLVyAgDdBo/V3uxWAJvQZGY9Q9xiMmJ0WCBgDZOkMmFcrViYgAls+VvVwEVcNVaSi+S
2NnbK6XNUrsIZXiIRCqRWSvc3RxFIiuZ0DE8M0ruyrJW1AOF2sqbtb8okksYRiIXXbQHPdaAX/+O
PgSvwoYOevSUOaLQuLBQrZeTI5I5eoU6aePCJPB2c0sL/FNvkyl48r0aEkpBJHWCe4Io+aeew3O0
aRNxtD7iolqPLq/Hlod2iyyQkqpc7Ww11gLsYZMyqDo2eVCsk0RU3RJVCqgqoVDGv0cKM1S9KVmL
2Am0yUePmz0z9H7eiQWRHilaHNFyjh9/5Bzj6hbqZRtfsSSfmtci5v7RLcQH60BDoahvx3vPg5ph
Utn7HcTuCCGWeqiX6e2D0jwVmjRL2KzijApWe+G6zdf8QZV0LLZc/eBbiQJ8aR+f1iOmtgMjsdgJ
vU7IeA8aMSNLpHJi7d197CTUCxQlVrk7O7NKIVUh6FKUl+FLyyDSdnRTiugNEM9WXv76k2KZXIQZ
sZWU7iNTihRWsC6RQvLYWS4seN10YiQfPQsksM75EK0eh3VmoGkd1xlEvbHbzVOt0h2kHkGc1IV6
Ybeqs8qz20FsDQsPpB7rVXrP7mmRacFxatrJN639s6FFBa3fjbHowuavW3TUSiRNtSTaq8cSmLfT
lOC4gPYZUDmxh8hO42nnrLWTJDV/KLBx9nVx8XOSDwGlqT2cnSE0pVIZqg8jVbk5wP0optIFwQP7
ZrJYbufpDEGqgN4gcxC3UyFe/LgaXB7Dq7OfRCmUW0uIOh0lEvyTWMEpVy5+rBGLe+w4dsbQolzQ
rh3EGJwV6VBZh+93aW3VnQ5iG1CkJ/V4l6Mj921Crd5Krw5O04ptXdNsM6x6W1QTazGnE7EhT76t
JX9mvSca5DXn4wPnqp3uwi36sqfXMQKPXmVzCpsfC1XO3k4arQrL7izBWAQ+RuOuFFENuGtJXnd3
LLPz0gS50etlDtIBJz/9ZUrzKniYMQK5rRUVS1fLbUUyXh1W0see/XYfOGzgLko5osxLmi9RUegb
iB09d8ohhuplshKpD1PZyBH5WXQRYHPnHMSH74TqvGHW/N948VNueWpHhYfsUvhDgCemRYccBDZO
3i5O8FLcGlsX8761QiC2kVHqkRrWRihQqEHb6eZ7lD8/ovshiE5rEfevpvuYRD39WpQfwMej3HDt
Q07KXyC1dgz0dPGyFQtk1g6dfFy1tqLlVj5+no5ysVqjtPH18XBQSNXO3K5OohswKxiNnJArFwX3
2mNjJbHr3mYQWNRFGIXbClHrPlgWhdlwnUlkY++iUtlLyLIcffhlCZJj66PfF8lFNCO15lbG/UWQ
QGELuhzR/CP9keAteON6HkJ22BbJYFxml9RG4NfyN1EBISGwNG5Yh5Yh+WNib28r8hApHd3hWFhT
YnqzSOnA2jl7WotuKazFjEihVgjHKWALRXJbBflvO5TAvT9rM3SIddxd5CTm/8XowV/Hn+X4mP+d
/o9Cm+ske0Ur4X0gsfznIQD5T0bSXo9CH38r2StG1Iq2/+KUMTBWT3LUByBZYz7zvBBqzPUcmP4o
jwlGdc9APXMN5fMwowQO9E8oHxBu4SRAF0AeINMiI9iGcgRyVNURzCOUw0GgR/WYQTmYMXsD2wPH
AoIAvQA9AaNArgF+jVkI9eaa9wM2MH7QHkAPgjE4FFm4BmmZwShf+Cn07fcMwFiCOFT7t0hCPhyE
N1Et4wljeaJsQRak8yFNEMcxvRIxBOY/gKnW/FW0DmBv4cUCT7ToecHMRsdE7ujLjmB8zR9CX0cA
XSycCSijj5h/aoc75n3Pib2CgeY5HBgGpdFbUPmzwBhRTx6jUDwHejKMOxkFWZgFuAMCAT4AvUWe
SWeh7kwjGv4URoKcw2uogLqGulPXzEnALsA9AL6APoAcwAiQK4HnMhrUHXc1NwEm06dRdw74G5TJ
46qFf0Pe9CcoE54NqcyYZ6AUxlyOCv8Wb6I0DtBPEX0cxjqOUpi1qJD+EdIEKTwnIExg/g1wozVf
gCbTBeb7wPWAScwLaEIH1D1DxoO+jpYI3dDGjqDPmr+gJ6LpAKWFpQBHutx8qy0YV5TdAZ2fIeMh
lKAQDpCOp/NQTwu6AhJa8qJU1FN4FvUU3CLg29YAygARKIv+CPb5OYBHmOOF08zx4rfM8cwWs7tw
KqQPQzquA3p3gEUuHNkBszrAIm+tPwoggTGS2vQ99UlfzPcEAqk5XuQOaVfUrSPoE+bDHQHyBB7+
KJO6iBKoi2YOfwKyABpAFSAbMBgwk6tDH4X6GuRD/WLu0gJ6HeiZIIH0g4KwC9/fHuohSsSPUYIw
zzLWEwTwPNd8m2cN6tUBuqdkcbC/AOE0SLua/yRA2fgtlEBg/gVgpl2RhMB8G3CrJS/YQMDEmAOo
W2ZnvB2NwCcA25EBH0L+zFU0gml4PgjUaIQoA40Qfv58gHnWALIszIHbp+GAUkB5G3kNvQCNF+xH
8zuCHmU+Ty9GdgDKwhxs6U5IYAHiuRaNoA1oCj0a9cefoTfwJ2gVTkQb+fQatIk6Zr4L6dfxF2gV
VYTWUpXmn/HLaDU1GK1meqLV+EvARaj7KRoJeIP6DfI6NJW6gg5C2TH8Anqbvonex+PRYDwdzccx
aALOgzCjAbCYu7UfQyjw6Cfc92kZP8chAF72aBVgaAfZa4Byygx5iAvotYBNvNwIKKS9oL+7IEsF
DOXlqwETaV/IpwGGtfYxAWJLRMMDhFbysq2AzXgBtF8GWM3LfgZ8hyHGwMcBe6DuMcC3iP90BSjL
AYRSpyEOuQh4nwDWkskBN5i59pfxJPMD4GvUPfOPOLQ1XnmZi0HoXLhfp8E9xscQzSe5O43EC817
IV6oJfFC85tcjMDHAUvMZ1vue9AxIne4Wci3gbub3mK+Y7mHD9NXm+cA5wltYUy4T4UIHYF7XS7I
ar5ruRPHcHchfsjdMeYPyF3W/CHvW/l7q/k0sxMVknur+TDcTXn8ffSt+UDLvUPPQDJyl5i7MKMh
z90hA8x/8vfCVDSVntq8DthGAJri/LogH70CfaqYneY8uAOyecSCnXc23wO7Hs3ooN4GFMIBn0IR
4HcTeIxGeiYRVeAwZMRh5q8BY3FY803Op9C7wVf1gjFfhjsFQ5xGo/BWn1CBBIzK/DG0zYD9z6Kd
QE99UIMF5QCJoAv4+yiUDuseKdgMZ2sh6ssBz+L3Ukrf4fc6CgvQbSygogFC7GXeCTZ4kjKbr/P7
mYkK+P2sgT3gMBL2yNdc3iZ2zBOWge85g2iIe3JaYIkHe3GxXmu8dcW8XfgA8CmJG0X0kziOuU/2
mYtVW2IvJgbucA770HHBYrLXAheIb+8CatFbwtsoT+QG6V/RGqEjxLV6QBFyYwyoRiSBvkaYH0Kc
u5q5jdYIuP8YzNnGDbj/uDjJFvaTgy/Yw2TzqDbxUKBgtPlXYCtmFpRZYIlx+nDxC30K7AHAhJk3
8/Yy0hKTvAIYxsca3fm4qyWOeA1iPTiZTAjEkFJiL8w8lM6Uw948QCuEWpQuTIH8EDRWMBXm9hPg
e4jDfkNFwhDoC3wClE1hilEj7AcSUjBuGIzJ3eNJUMbZ1ifQVxrEcADwewkcM5G83+3W9g4Xppvv
QpxNW3wud0f2ttyBNfydthfuMwBjZz4E4xwSlCMhEw33mJ/lrnIH+LfcZWCbXIwBdwx3zwmjIFbi
fTPcPR+Bva2DMcF3M90t/v0oMnB1hAZ4i6SjfoI8ZKQPolJ6DtxTcyE2PwHzfs/8A5OBMrm7mfFF
Q+kqWJsFYKsbOOBXwB+/AvffK6iS3oMeADwBCfQl9B0uRK8A+tIl6Gu4C3Rgx0s4m8ZeqBLsPF3w
AkoD+74GmAQwAxbCHv0MaAQ8Aizh2kDstwzvReMBYwBLAYsYJ4gDneDd44SWA2bSzuYR+LJ5Bb0D
/UQ/goejGp3Fl9FxXId6AErpR3AnPULOoq5oA+DNFqYfmQeD/HuYzybAAVyJGnCl+UtcjwJwvfkk
noZK8TTz91iPqrAe7vZ0kKdDvhLNhHo3oF5XqPcZ1BsD9e5BX38AvgIYASlMEzrCxKPVkJ4CWESd
QPfoSHRPAHeSAO4m0T0A3BuiOJ5thdvQaQ7w/rwuWI8uCraiObBeBPO8yexCGSAPhH7sgd3BZ9lC
+j0ou8e9VyFdCrqIgXQ6/TvyolchF/otiGlXwdpXgV3LUYU4CPwG6EH4Ddis0mxmFqMB+D00mIZ3
AX3NfInpAz76U/PnTBSaSJvgHESBbUWBf7MC32iFhgBYxsp8B3AOcB3ywwCjAMGQvw9nYAieiwro
KWBHdUhFbwX/UQZ2uA8N4n0jZx+HkB/MJwXQB2AD0ABsLZwFmAbQAjxhfsNgfnPJ/JAC7idr+lMk
tsxvjGV+4TB+5pP5wZvVCjkCXC3z20jmhzrRHugA9SfYRhOahrehKRBLTMUb0QtgK6fgXj6Mv4U4
5TLgF3QS+CQ+j3ZTh9AHgGpoS0FbW9xkPou3mU/jL83v4Y3mc1DPBtoK8Ldw914G/IIUIFPg8+ZH
0M6BOmTeh1+Dd9ddpMM55qs4De6WdLCZVPNlnI0YiF3kuJ/5B5wJ9vQa2MhdZMI5qAyngS7TIX5K
hdgwG02HevNwPzQUZ6IavLP5B1ptbhYMAZQDHCwcbH4syAWcRoN5DEWZgn2AtYBzqFgwAe6htQB/
8wWI5wziXsggmIKKRedgzx7xGAIIB8QB0gDpgO6AfgBPAN0GvQQ/o0BGgHoIP0YzYe+z8HXzCJD3
5eINLg7g7kyhEa1h8sxHGHtUAWduBWAp4DQPK7RDZEV1bmFpL/DBMWgVvC39LN99yfrPAgf+B/Hm
P/gH/+D/BSAC+y9BIHw+CPXtIap6Poi/+f82pLXPB9nWJ5Av/a9DcfwJrHKeDes/EVK6/Qs8+Peg
7vYEtsntYbf9+WD/x38fHB2fH9zPN3Ie/Gxo+v+Df/AP/sE/+Af/Bs4+gUtEG2z8v4er6h/8g3/w
/yNQ3L+IQReQCDUBMLJBIagQIcnPVC/E8P+iJgh7IvLzNhEq4b/S/L+zseJz5GN75ajWkqZRVzTR
kmaQCzpkSQuQI/rMkhaC/DdLWoQeUHJLWoz8sdCSliAW6yxpKV6NsyxpGerLtLSVI39BqiWtwMsE
NZa0FaoQi1s/MDhMXG9JU0gk3mhJYyQUb2v5aGDkLt5lSTPISvyRJS1AcnhlkbQQ5NcsaRGaIH5g
SYuRnWSUJS1BNpIXLWkplSV51ZKWoQBpS1s5spM5WNIKqqcs0JK2QlHy0dzHHjMSTs/y7ZY06Fmh
sqRBzwrWkgY9KwItadCzYpglDXpWTLekQc+KlZY06FnxpiUNerbabUmDnq0uWdKgZ6tmSxr0rGxp
C3pW3rGkQc8qN0sa9Gy7F21GLApDOvgdBalMVI6KwRqq+Z+KWorqQZYEqVpUw381gIR8MHswlCSi
CvjNohyQcR/xRz7APQcZgbkPcR8JX0ugZvuPe0+DeiRf/IzxOvMjtv94+LYtOrfON/Jf1vuLj5Hv
0CaoXZuO/ZXz6zEC18PquP5YqMECG2G95fwH6Rn5XAlI63n9cB94WAlci4aDrLq1zbNLS/8tnXMz
quL74mbDoj6QK+fnwI2fy6+kntc+N2YVSEMsM6hus4JiyDXwH7fPrZKrHfxvzKEntC1GfiCpQ52g
Vgk/k+58W26UZ+uQ00AllJfwc+DWUMfPsI5PGfm6nC5KQUo+pnAM5EZZNM/V4X70Tz3/c3pZfqwG
fn2cPobyvVRbeq3nNfxEA2S93JjEHoItdsKNZeTX1cDvYJ1lXw28RZe3sYo6FMj3XMlLKvgeDaAX
Im8ZpRL6qeC1VGOZZRVIKvlRSZ91/M8YfjIDbsQafi1Exy0aJnPnRqoGDbD8R2cO5bVQzn+QI/ex
mvVtbKHl7BGdkVFYfu5VlnUROyviaz6ZcdsVcVobzbcjqx4O+eCnTqIv31sl38MYXg8NllPeVt8t
1smNPorXqqH1pJRbdpuMyO01C33UtK6GzHGopQ53esdaeq+HVZAdGtm6SwbeRrjTVNluXS0WXAwz
MfDjF1vGD+Y1xX3QaGc4GyHQmvsdzNtce/sP5u2mEupwHybN7dBQvqca6GEMSLkeS1t/bEX7Xlvk
nDUTzQ1v7a+At12ixTH86ut4bdXz+1zH2yVpzfJ642zEyK+wnB+DnPUivm2LplPAE/QEb0za1rYp
IfZVwp/ZJzYzih+rmLepZ41L8lzdYtBzA39qS1r3oIQv56ycrKBF7zX8Sqssmid9GfmvnCV1XDdX
TizWD1p14v1sJazL2GpDT8+q6qmen19HT3pv8Rqs5dwTP1jc7vw9vfYnnrf9vLq00QC3ErIW4oVa
fGdtq0cr4c90FX+2DX+5UqJnQzudGi1+vKM357TKWV4D37KEPx/caoyt/XA1K/gz9q926P/VuXhy
JkIsH/5rsHjGYH6vatDozdxPt4lin/kDcYLZxIoKNof7OTh1bI6xzlg70lgSnGSoKC+qLU+rBy5u
bdeZtchZUtCZ6zeyvayvsbYOumVDg3VhlpIgUtJSr7yONZbXlxlrWQNbaxxazv0sdmMJW19rKDFW
GmqHs9VcSZts6bNnzpZXsdAN26eqvB7a59Yb6o11rKGqJAQ6qOYHKK5uqKqvLTfWBT+zh54NxX6G
uk5siZHtXltdXd9mhga2srqE+xnxdYaqOha0Ul7KlhoqyyvGsKNg8mxdQ1F9hZGthQFKyquG1rEw
H1hIJT8BGLe2CvQQDDphS42G+oZamFmt0VDBlvOqqAtk6yoNoPdiQw2kuSaVDRX15TXQZVVDpbEW
atYZ6/kO6tia2mqYMTdh6L2ionoUWwbbxZZX1hiK63ktcLsHM4MmbEV5FYwFOisqH8p3TAaqN46u
h8blw43BLZvoW8dWGqrGsMUNsOVk3pw6q4yj2FoDtynlsGxoaKhkG2q4YaDHoSCpKx8L1eurYUEj
uSUZ2FGG2koyFqfg4jJDLUzMWBv8HD8+KKS4vrS6qr7OUpVLlxpgcsO5egXVDTDFMWxDnRGmBrvC
FbMG0IixtrK8ntv1ojH8pFP69EyE0lo+Y/kxXtyUR5WVF5e1aQtcXlVc0VDCGVw1W1JeV1MBA3Bz
r6kthwrFUMtYVR/MtoxdXQWK9SvvxBori7hGT7qqaqn8zBnx1TnTADXVgQ0Wk/1rHZ03XktfXfgJ
+JXDKGBCnHXWcoZWUj2qqqLa0HZQmLOBzBQ2otXMqxvqaxrqwYy5nwXE1SkzVtR0WNDz7AW/EyEl
xlIDGGOwoa5m9D+vlX9eK/+8Vv55rfzzWvnntfLPa+Wf18p/x2vF8r3zv/y1U0Lvx2NNbl3d9+Mx
hEab3GRAowiNNLl1BmogVE+q1JncugDVmtzigEYQqiFUbXKLB6oiVEkaVBAabnJNBBpGqNzk2g2o
zOSaBDSUUCkhI6ESQsWkQRFpYCBUSMqGEBpsckkBGkRoIKEBhPoTKiCUT6gfob6E+hDKI5RDKJtQ
FqHehHqZXJKBMkmuJ6EMQumE0gj1INSdUCqhFELJJk0aUJJJkw7UjVAiIb1JkwGUQKirSdMTKJ5Q
HKEuhDoTyiUUS/qMIRRNOosiFEkogvQZTiiMtAslpCMUQiiYUBDpLJA0DyDt/ElZJ0J+hHxJTR9C
3qSBFyEtaedJanoQYgm5E3Ij5Gpy7gXkQkhjcu4N5EzIiZAjKXMgZE+EdoRsCalJmYqQkghtSM6a
kBURKgjJCckISQlJTE5ZQGKTUzaQiJCQkIAQQ6rQJIcJUYQQT5SZUDOhx3wD6hHJPST0gNB9Qn8S
ukfoD5NjLtBdQndMjnlAvxO6TegWod9IlZuEbhDhdULXCP1K6BdS5WdCPxH6kZRdJfQDoe8JXSFV
viP0LRF+Q+gyoUuEvjY59AX6itCXJod+QF8Q+pwIPyP0KRFeJPQJoQuEPiZVPiK5D0nuPKEPiPB9
QucInSX0HqEzpOZpQqeI8F1C7xA6SeiEyR78EvW2yT4B6DihYyb7AUBHCR0h9Bahw4QOETpI6E3S
7gCh/US4j9BeQnsI7Sa0i5CJ0E7SronMZQfJbSe0jVTZSmgLoTcIbSa0ibR7nTTYSIQbCK0ntI7Q
WkJrCK0mtIrQSpNdEdBrhF412RUDvWKyKwFaYbIzAi032ZUCLSP0MqGlhJYQWkxoEaGFJjsD0ALS
50ukz/mkz3mE5pKuXyQN5hCaTWrOIlVmmuz6AM0gnU0nnb1AaBqpOZX00kiaTyE0mdAkQhMJTSA0
ntA4QmNNduCTqTFkhNGk61GERpIRGshc6gnVkfFqSfMRhGoIVROqIlRJqILQcLKUYWS8ckJlJrso
oKGESk22jUBGky1nuyUm20lAxSZbrl0RERpMtnqgQiIcQoSDTbYTgQaZbKcCDTTZvgA0wKSGS5jq
b1K7ARUQyjeppUD9CPU1qeGap/qY1HC/U3mEcgnlmNRwzVPZJjVc7FQWod4mFTfrXiZVKlAmoZ5E
mEEonQjTCPUg1N2kgnuTSiVVUogwmVCSSdkdqJtJyR3KRJMyH0hvUhYAJZiU/YG6Eoo3KTlrjSPU
hVBnQrEmZQBQjEkZCBRtUsYCRRGKNCm5gSLIQOGEwkxKToOhhHQmJafIEELBZC5BhALJlALIlPwJ
dSJT8iPkSybhQ8ibkBchLWngSWp6kCmxZBLuZDw3Qq6kpgshDWnuTMiJkCOp6UDInkzQjpAtmaea
DKQipCTtbAhZE7IipCBV5CQnM9kMApKabAYDSUw2Q4DEhESEhIQEpCZDatJEiAlRhJDeDGyGes3A
jwGPAA8BD0B2Hxr+Cel7gD8AdwF3rIvcfwfcti52v2Vd4v4b4CbgBuA6yK8BfoWy/1PdnQRHUUZx
AO+vO6J2T09PlJnJ0IkvVRZaccBKDpZd5SFdAVp0zEbmaRaZuCAJKEZ6pkVCGiJKFQcDuAuIxAVR
26UDqFFR4r4b9w2VuC8XOXgf/z145qp+3b/vfe/1m6nvu3fN/IH8d/gNfoVfUP8ZfsL6R8Qf4Hv0
zSA/At/Bt/ANHIav4wP0VXyQvoQv4HP4DLVPET+Bj+Ej5B8iTsMH8D68B+/CO/A2vKVfTW/q19Ab
+ln0OuJr+jx6FbVXsH5ZX0V2eUpfSYf0FfSSPkgv4slBvYlegOfhudhqmoy59GysSM/ESvQ0HID9
yPchTqAnhKfgSXgCHocAHoNHtfX0iDZMe7W19DDiHm2EHtJ8ehD1B+B+GIfdcB/sgnthJ+zQ5tN2
uEfdS3ere+guxDvhDrgdblMH6VZ1I21Td9JWdRdtUXfTGOq3wCZlLt2sWHSTsGgjj/KNwShvYJ/X
Bz5rvtB808/56/zAP+zbrbPUER7mdcEwr+U1fEOwhq8PPK7yZnslT/nLE4EnFnqi0ROy5CW8ek+J
ldjlYuCy5Ha4o27oVp0XujOuLLlCnSxP7XfN0xxEe8TVE85qHuLrgiG+dvkqXoltrbAGeDAY4OXW
Mr4qWMZXWlfw5dZl3G8t5UKwlC+1erkv6OUeq5svQf/FVp45yHOX1clLgk5ut9q4DfVWK8cXBTm+
0FrMFwSL+XzL4UU4slSbqK2vVRLRBtpqsRPJFC2Npm3OmEfNKskMzSlTOcWYQ3PkBiMjFrRnxFBm
Q2ZrRjFqpmtku6ZhnmOkp9NH0n+mq0610w1nO1IqkapPKcnobKnWvFOJzQuPxaZzKmdtTZ1+hmMk
hZGkpLyIkkKqnqk+Wq0kDyWmE7JhCMMoG7JtoN2IU1yOpnJcseNN5zqGTrocTWVdSdk6KtE3nhnr
yDuGRprMzVq7Jtta8wLH1uY3OpIi6oWQRAJBOQm9B0SSHOWgiN4VOkESYttEviubzU2eWF6SC0/u
6AvF5nBuVzTbnb3hrM2hxL193RNCbOmJfuQrH86O/h+qkm8aG5PqWnJhXVf3PmV8vK6lJxeORmvb
rqzL0VpCS0+2UPSK2WypgKlQLGUrNzLhRVk2KkZ3sYQ8urxKLmWPO461IfQXMUr/1ErH/9D/doh/
ewP/8VHTX/gb0ObZLg0KZW5kc3RyZWFtDWVuZG9iag04MCAwIG9iag0xOTYzMg1lbmRvYmoNMyAw
IG9iag0KPDwNCi9UeXBlIC9QYWdlcw0KL0NvdW50IDIwDQovS2lkc1sNCjcgMCBSDQoxMSAwIFIN
CjE0IDAgUg0KMTggMCBSDQoyMSAwIFINCjI0IDAgUg0KMjggMCBSDQozMSAwIFINCjM0IDAgUg0K
MzcgMCBSDQo0MCAwIFINCjQzIDAgUg0KNDYgMCBSDQo0OSAwIFINCjUyIDAgUg0KNTUgMCBSDQo1
OCAwIFINCjYxIDAgUg0KNjQgMCBSDQo2NyAwIFINCl0NCj4+DQplbmRvYmoNCjIgMCBvYmoNCjw8
DQovVHlwZSAvQ2F0YWxvZw0KL1BhZ2VzIDMgMCBSDQovUGFnZU1vZGUgL1VzZU5vbmUNCj4+DQpl
bmRvYmoNCnhyZWYNCjAgODENCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAxNyAwMDAwMCBu
DQowMDAwMTAwMDgxIDAwMDAwIG4NCjAwMDAwOTk4NjEgMDAwMDAgbg0KMDAwMDAwMDY5NyAwMDAw
MCBuDQowMDAwMDAxMTUxIDAwMDAwIG4NCjAwMDAwMjQyNzcgMDAwMDAgbg0KMDAwMDAwMTE3MyAw
MDAwMCBuDQowMDAwMDAxMzMwIDAwMDAwIG4NCjAwMDAwMDIxMDAgMDAwMDAgbg0KMDAwMDA1NTY1
MSAwMDAwMCBuDQowMDAwMDAyMTIyIDAwMDAwIG4NCjAwMDAwMDIyOTEgMDAwMDAgbg0KMDAwMDAw
MzExMSAwMDAwMCBuDQowMDAwMDAzMTM0IDAwMDAwIG4NCjAwMDAwMDMzMDQgMDAwMDAgbg0KMDAw
MDAwNDYyNCAwMDAwMCBuDQowMDAwMDU2OTk2IDAwMDAwIG4NCjAwMDAwMDQ2NDggMDAwMDAgbg0K
MDAwMDAwNDgyOSAwMDAwMCBuDQowMDAwMDA1ODc3IDAwMDAwIG4NCjAwMDAwMDU5MDAgMDAwMDAg
bg0KMDAwMDAwNjA3MCAwMDAwMCBuDQowMDAwMDA2OTA5IDAwMDAwIG4NCjAwMDAwMDY5MzIgMDAw
MDAgbg0KMDAwMDAwNzEwMiAwMDAwMCBuDQowMDAwMDA4MzA5IDAwMDAwIG4NCjAwMDAwNzg2ODYg
MDAwMDAgbg0KMDAwMDAwODMzMyAwMDAwMCBuDQowMDAwMDA4NTE0IDAwMDAwIG4NCjAwMDAwMDk3
MDkgMDAwMDAgbg0KMDAwMDAwOTczMyAwMDAwMCBuDQowMDAwMDA5OTE0IDAwMDAwIG4NCjAwMDAw
MTA4NTkgMDAwMDAgbg0KMDAwMDAxMDg4MiAwMDAwMCBuDQowMDAwMDExMDUyIDAwMDAwIG4NCjAw
MDAwMTIwODMgMDAwMDAgbg0KMDAwMDAxMjEwNiAwMDAwMCBuDQowMDAwMDEyMjc2IDAwMDAwIG4N
CjAwMDAwMTMzODUgMDAwMDAgbg0KMDAwMDAxMzQwOSAwMDAwMCBuDQowMDAwMDEzNTc5IDAwMDAw
IG4NCjAwMDAwMTQ1NDEgMDAwMDAgbg0KMDAwMDAxNDU2NCAwMDAwMCBuDQowMDAwMDE0NzM0IDAw
MDAwIG4NCjAwMDAwMTU2ODIgMDAwMDAgbg0KMDAwMDAxNTcwNSAwMDAwMCBuDQowMDAwMDE1ODg2
IDAwMDAwIG4NCjAwMDAwMTY4MzQgMDAwMDAgbg0KMDAwMDAxNjg1NyAwMDAwMCBuDQowMDAwMDE3
MDI3IDAwMDAwIG4NCjAwMDAwMTgxNzAgMDAwMDAgbg0KMDAwMDAxODE5NCAwMDAwMCBuDQowMDAw
MDE4MzY0IDAwMDAwIG4NCjAwMDAwMTkzOTcgMDAwMDAgbg0KMDAwMDAxOTQyMCAwMDAwMCBuDQow
MDAwMDE5NTkwIDAwMDAwIG4NCjAwMDAwMjA2MTYgMDAwMDAgbg0KMDAwMDAyMDYzOSAwMDAwMCBu
DQowMDAwMDIwODA5IDAwMDAwIG4NCjAwMDAwMjE3ODQgMDAwMDAgbg0KMDAwMDAyMTgwNyAwMDAw
MCBuDQowMDAwMDIxOTc3IDAwMDAwIG4NCjAwMDAwMjI5MjYgMDAwMDAgbg0KMDAwMDAyMjk0OSAw
MDAwMCBuDQowMDAwMDIzMTE5IDAwMDAwIG4NCjAwMDAwMjQwODQgMDAwMDAgbg0KMDAwMDAyNDEw
NyAwMDAwMCBuDQowMDAwMDI1Mzc4IDAwMDAwIG4NCjAwMDAwMjU2NTggMDAwMDAgbg0KMDAwMDA1
NTYyOSAwMDAwMCBuDQowMDAwMDU2NzQ2IDAwMDAwIG4NCjAwMDAwNzgxOTcgMDAwMDAgbg0KMDAw
MDA1NzE3NyAwMDAwMCBuDQowMDAwMDU3NjY0IDAwMDAwIG4NCjAwMDAwNTc5NTggMDAwMDAgbg0K
MDAwMDA3ODE3NSAwMDAwMCBuDQowMDAwMDc4NjY2IDAwMDAwIG4NCjAwMDAwNzk4MDkgMDAwMDAg
bg0KMDAwMDA4MDExMiAwMDAwMCBuDQowMDAwMDk5ODM5IDAwMDAwIG4NCnRyYWlsZXINCjw8DQov
U2l6ZSA4MQ0KL0luZm8gMSAwIFINCi9Sb290IDIgMCBSDQovSURbPDk3OTdlYzBjNmJmMzRhN2Jk
OTkyY2FhZDg2OTdiNDAxPjw5Nzk3ZWMwYzZiZjM0YTdiZDk5MmNhYWQ4Njk3YjQwMT5dCj4+DQpz
dGFydHhyZWYNCjEwMDE1Ng0KJSVFT0YNCg==

--==========F3C7AAB4DDE0076ECD9C==========--



From nobody Thu Jul 24 06:06:13 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B02B1A02F5 for ; Thu, 24 Jul 2014 06:06:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.408
X-Spam-Level: *
X-Spam-Status: No, score=1.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_31=0.6, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=no
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 anmd0zuNe7Ic for ; Thu, 24 Jul 2014 06:06:07 -0700 (PDT)
Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id DECEE1A011C for ; Thu, 24 Jul 2014 06:06:06 -0700 (PDT)
Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 2582D32E533; Thu, 24 Jul 2014 22:06:05 +0900 (JST)
Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 3a89_cdf9_e5df98ea_7f83_4278_88b4_b7246336780d; Thu, 24 Jul 2014 22:06:04 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 1E298BF510; Thu, 24 Jul 2014 22:06:04 +0900 (JST)
Message-ID: <53D104AD.2080702@it.aoyama.ac.jp>
Date: Thu, 24 Jul 2014 22:05:49 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: John C Klensin , urn@ietf.org
References: <69C28E0B5B9A1CAA8F5817DF@JCK-EEE10>
In-Reply-To: <69C28E0B5B9A1CAA8F5817DF@JCK-EEE10>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/erh0zZJirkSNpOggzkiVOEl4bGY
Subject: Re: [urn] Tomorrow''s "URNs are not URIs" topic
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 13:06:10 -0000

Hello John, others,

I'm at work late because of a thunderstorm and a lack of raingear.
As I have said before, I'm not in Toronto and will not be able to attend=20
remotely.

But the mail below and the slides still contain stuff, to put it shortly=20
but bluntly (sorry), that has no basis in facts, and therefore benefits=20
from being corrected.

On 2014/07/24 20:36, John C Klensin wrote:
> Hi.
>
> Apologies for these slides being so late, but in-the-hall
> discussions had them changing until late last night and again a
> few minutes ago.  We are still outside the 24 hour limit I've
> proposed occasionally.
>
> Andy, please post to the materials page at your convenience but
> note that I'm circulating them directly to get them into
> people's hands.
>
> Please note that, while I've drawn some things together in
> different ways, I do not believe there is anything in these
> slides that is new and has not been discussed on the URN or IETF
> mailing lists in the last six months.    They (and the
> presentation) are really just a summary to be sure that we are
> making the same assumptions about what is going on (and, if we
> are not, to expose that efficiently).
>
> In particular:
>
> (1) If people's concerns about "URNs are not URIs" are about
> some perceived symbolism, I think we should rework the draft
> with a different name and terminology to reduce that symbolism
> as much as possible.   The draft is intended to be a pragmatic
> solution to a practical problem, not to make any symbolic points.

If there is indeed a practical problem (I have asked for one and tried=20
to find one myself, but haven't been successful), then the best solution=20
is for the draft to describe the actual problem. Name and terminology=20
may be important, but they are secondary.


> (2) Some comments on the list have seemed to imply assumptions
> that the separation is about changes that would cause generic
> URI parsers to fail in massive ways.  It would allow us to do
> that.  However, or actually doing so is unnecessary for any way
> that I can imagine, would probably create incompatibility with
> URNs allowed by 2141 and in use, and, IMO, would be a stupid
> move for those and other reasons.  As a parser specification,
> 3986 only requires [1] a separation of
>     method:path?query#fragment
> using the delimiters shown.  I don't think we need to change
> that in any way that would  cause such a parser, much less a
> parser based on
>     method:
> to fail.

Okay, great. Then what's that "separation" about?


> [1] More or less.  The spec is unintentionally tricky and
> actually does not quite "work".  I hope we can avoid getting
> dragged into that discussion.

I don't want to get into complicated discussions. But given the number=20
of times that people like Julian and me and others have had to correct=20
extremely simple misunderstandings and basic logical errors, I would=20
appreciate if you could say in detail what you are talking about here.=20
There is a high chance that the spec is actually quite simple and does=20
work, and I wouldn't want anybody to miss that.


> To review an example in advance of the slides, 3986 gives a very
> specific interpretation to what people --and many existing URL
> applications-- consider a sequence of queries, e.g.,
>      ?x abc?y def?g=3Dhttp://foo.example.com/?
>
> 3986 allows the sequence but treats it as a single query string.

Well, yes. That's not because RFC 3986 didn't understand URNs or=20
whatever, but because there are virtually no such strings around.
Everybody on the Web writes queries like the above as something like:

?x=3Dabc&y=3Ddef&g=3Dhttp://foo.example.com/


> AFAICT, the only practical difference is that permuting the
> sequence of queries would, under 3986, cause two URIs to compare
> not equal (one of many types of false negatives for some URL
> situations that 3986 predicts).

RFC 3986 does in no way limit anybody's choice in how to do URI=20
comparisons. Section 6 (http://tools.ietf.org/html/rfc3986#section-6)=20
gives a long (but in no way closed or complete) list of some ways to=20
compare URIs and some of the applications for these various comparisons.

For the schemes where queries are mostly used (http: and https:),=20
queries are mostly interpreted by software on the server, and I can tell=20
you that most decent Web frameworks (starting with Ruby on Rails, which=20
I know best) do exactly the same with

?x=3Dabc&y=3Ddef&g=3Dhttp://foo.example.com/
and
?x=3Dabc&g=3Dhttp://foo.example.com/&y=3Ddef

and all the other permutation variants.

> Because of some expectations
> about URNs (e.g., "persistence" and non-retrieval uses), that
> restriction may be worth a change, even if the syntax of the
> query-collection does not change a bit.

There's no need to change. It's already mostly done that way where it=20
matters. On the other hand, trying to declare by fiat that every place=20
that up to now compared URIs by simple character-by-character comparison=20
MUST compare those URIs that start with urn: in a different way will not=20
get very far.

> Anyway, I hope the rest of you are looking forward to a
> constructive meeting tomorrow, one that makes significant
> progress, as much as I am.
>
> Note that these slides are _not_ "final".  I may not use all of
> them and they will probably be edited again to improve clarity
> for the proceedings if not before tomorrow.

I hope we get the version of the slides that was used for presentation=20
into the proceedings (modulo simple typos). Otherwise, it's not worth=20
calling these "proceedings". Of course, you can always produce updated=20
versions and send them here or publish them wherever feasible.


Now let's get to the slides:

Slide 3: "Written before 3986 and so not really subject to its semantic=20
restrictions": As I have tried to explain before, there are really NO=20
relevant semantic restrictions in RFC 3986. If there are any, please=20
point them out.

Slide 4: "Effectively imposed retroactive requirements on URNs": This=20
isn't true. RFC 3986 didn't impose anything on URNs. It was written=20
carefully to make sure that URNs fit into the overall picture.

Slide 4: "3986 Could have said =E2=80=98if a =E2=97=8A (or =E2=80=9C?=E2=80=
=9D or #=E2=80=9D) appears, it is
used to indicate a =E2=80=9Cfoo=E2=80=9D, with the interpretation of
=E2=80=9Cfoo=E2=80=9D being scheme-dependent=E2=80=99
=E2=80=93 Did not. Specified what =E2=80=9C?=E2=80=9D and =E2=80=9C#=E2=80=
=9D meant and how
and where they were to be interpreted."
The "where to be interpreted" piece is true for "#". That's mostly=20
because existing software (for almost as long as the Web has been=20
around) does it that way. So "#" is indeed out of reach of URNs, as well=20
as any other scheme. But that's not a retroactive requirement that RFC=20
3986 did put on URNs. With respect to "?", "the interpretation being=20
scheme dependent" is exactly what RFC 3986 says, just in slightly=20
different words.

Slide 7: ",," -> ","

Slide 7: "We have no ability to tell them
=E2=80=93 Don=E2=80=99t use URNs
=E2=80=93 Don=E2=80=99t use URNs in that particular way
=E2=80=A6 or expect them to listen if we do."
I think we can't for sure expect them to listen, but we can at least try=20
to talk to them.

Slide 7: "They can create their own (=E2=80=9Cforked=E2=80=9D) URN standa=
rd for
their communities any time they like.
=E2=80=A2 If we want to retain control of the overall design/
architecture,, we need to treat each community as
having importance"
It's nice to be able to tell others they are important. But how many=20
communities are there? If each community wants something different from=20
URNs, what will be left of URNs when we are done? What we need is good=20
engineering, collect requirements, find solutions that work across these=20
requirements, and so on. "Splitting" before we have a clear, documented=20
idea of where we want to go doesn't make sense.

Slide 8: "Verify that 3986-conforming queries and
fragments are sufficient for all needs of present
and future communities.": As you indicated with "Requires predicting the=20
future with high confidence", this is essentially impossible.
What URIs do is to provide a very, very course structure for=20
identifiers, so that any kind of identifier need can be accomodated. It=20
has worked well so far, and it should work well in the future. Of course=20
this requires target communities to make a minimum of compromises. If=20
somebody comes along and says: I want "#" to mean query and "?" to mean=20
fragment, that wouldn't work, about as badly as if somebody comes and=20
says: I want "table" to mean "bed" and "bed" to mean "table". (sorry,=20
didn't see the "bed" on the next slide coming, this is unrelated)

Slide 9: "And the result looks silly enough": Can you (or somebody) tell=20
me what kinds of "silly" stuff you are talking about?

Slide 10: "Avoids dealing with generic URI semantics that many
people don=E2=80=99t realize are there": Well, they are not there. If the=
y are=20
there, please show them.

Slide 10: "If needed, allows a discussion of other syntax than that
specified for generic URIs": Discussion is always allowed. If at the end=20
of the discussion (or in the middle), somebody says: "what about=20
replacing this character with this other one, then we don't have to=20
"split", then we can always make a split if we really think we need.

Slide 12: "If WHATWG / W3C succeed in killing 3986": W3C doesn't want to=20
till RFC 3986. WHATWG will only succeed to the extent that the IETF=20
allows it. The best way to think about that spec is to see it as a=20
detailed implementation spec to avoid or reduce browser divergence. It=20
contains all the stuff a browser implementer needs to know, but=20
virtually nothing else. In that sense, "Assuming that persistent names=20
without location properties are a myth (or just dumb)" is slightly=20
wrong; they are just not relevant for browsers (simply put, because=20
nothing happens when you click on them). And by the way, while the spec=20
uses "URL", than in no way excludes URNs. It's just that the spec=20
writers decided that the term "URL" was much more widely known than=20
"URI", and wide familiarity of Web developers with this term was=20
considered more important that terminology hairsplitting.

Slide 13: "Case-sensitive query and fragment compares unless changed for=20
all URNs.": Even if you want to change that, you probably can't. As an=20
example, there are a lot of URNs used for XML namespaces, and these do=20
character by character comparison, to the extent that even
"http://example.org" and "Http://example.org" are different despite RFC=20
3986 saying schemes are case-insensitive.

Slide 13: "Query is always part of equality comparison =E2=80=93 Fragment=
s=20
apparently never": Where did you get that from? I'd guess that all the=20
examples in RFC 3986 work that way, but where does the spec *mandate*=20
it? I'd guess nowhere.

Slide 13: "Urn:foo:bar?a=3Db?c=3Dd and Urn:foo:bar?c=3Dd?a=3Db Never comp=
are=20
equal": Wrong, it's up to who is comparing them to decide.

Slide 15: "Very long, complex spec": If you think you can do it shorter,=20
why don't you give it a try?
"few actually read it": Unfortunately, that shows from time to time on=20
this list.

Slide 15: "Extensive sets of rules irrelevant to URNs (e.g.,
relative URLs, dot-removal)": True but irrelevant, because it doesn't=20
require a split.

Slide 15: "Complex equivalence algorithm": Wrong. No fixed algorithm.=20
Various options for equivalence/comparison/normalization, because that's=20
what happens in practice (with a wide range of choices from XML=20
namespaces (see above) to what search engines do for optimization)

Slide 16: "my be resolved" -> "may be resolved"

Slide 16: "If we want the third, not with 3986." ("the third" is "As an=20
additional parameter (if we allow it)"): Why not with 3986? I don't=20
think there is anything in RFC 3986 that would disallow this.

[I personally think it would be somewhat disingenuous to the purity of=20
URNs to include the resolver in the URN, but as far as RFC 3986 goes,=20
that would be okay.]

Slide 17: "If we need =E2=80=9C?a=3Dc?d=3De=E2=80=9D and =E2=80=9C?d=3De?=
a=3Dc=E2=80=9D equivalency": The best=20
thing to do here is to write these as "?a=3Dc&d=3De" or "?d=3De&a=3Dc". N=
ot=20
everything, but a lot of software will treat these as equivalent.

Slide 18: "If we need such a small deviation
Why separate from 3986": and what if it turns out that we don't need any=20
deviation? Given all the 'reasons' for a deviation/split I have seen so=20
far, I think that's the most likely outcome, and would definitely save=20
some work and other hassles.

Slide 20: "The IESG could apply =E2=80=9Cnot enough energy to do
work=E2=80=9D to the URN topic": If the only way for the URN WG to show e=
nergy=20
is to prematurely agree on a "split" without actually having done the=20
necessary legwork to justify it, that would indeed have to be taken as a=20
strong sign of no energy.


Wishing everybody a successful meeting,

Regards,   Martin.


From nobody Thu Jul 24 15:16:28 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B541A0111 for ; Thu, 24 Jul 2014 15:16:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
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 SEISkQPyCSTZ for ; Thu, 24 Jul 2014 15:16:25 -0700 (PDT)
Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C9FA1A00DE for ; Thu, 24 Jul 2014 15:16:25 -0700 (PDT)
Received: from dhcp-b18d.meeting.ietf.org ([::ffff:31.133.177.141]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 24 Jul 2014 18:16:24 -0400 id 015AC29D.53D185B8.0000135D
Message-ID: <53D185B7.8080102@thinkingcat.com>
Date: Thu, 24 Jul 2014 18:16:23 -0400
From: "Leslie Daigle (TCE)" 
Organization: ThinkingCat Enterprises
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "urn@ietf.org" 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/PeVo5oMrfQttNMpCYcHrjUqfaJk
Subject: [urn] Choice matrix
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 22:16:27 -0000

Hi,

Reading through John's slides for tomorrow, something clicked in my head 
(errr, hope it wasn't unhealthy ;-) ) and it seemed to me to be useful 
to think of the discussion in terms of a matrix of choices:  whether or 
not URN syntax is divorced from URI syntax; whether or not "?" and "#" 
syntax elements are defined for URNs.

I deliberately stated those in terms of functional choices, not 
semantically-laden options.


1-1:  URN syntax IS divorced from URI syntax; "?" and "#" ARE defined 
for URNs
	+ Avoids the problem that existing URI fragment & query semantics don't 
fit for URNs
	+ Can (IMO, should) define "?" and "#" using terms OTHER than fragment 
and query, and make them as generally applicable to URNs (as defined by 
the IETF standard) as possible
	- contributes to demise of the current standard for URI syntax
	? problems with parsers?


0-1:  URN syntax is NOT divorced from URI syntax; "?" and "#" ARE 
defined for URNs
	- Existing URI fragment & query semantics don't fit for URNs; 
workarounds include per-namespace rules, etc, but largely unenforceable



1-0:  URN syntax IS divorced from URI syntax; "?" and "#" are NOT 
defined for URNs
	? Avoids potential future clashes of syntax between generic URI syntax 
and URNs
	- seems kind of pointless


0-0:  URN syntax is NOT divorced from URI syntax; "?" and "#" are NOT 
defined for URNs
	? status quo.


Other thoughts on +/-?

Leslie.


From nobody Thu Jul 24 15:27:12 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF011A0B05 for ; Thu, 24 Jul 2014 15:27:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 iHRtyhokLV0Y for ; Thu, 24 Jul 2014 15:27:08 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35F7A1A0AE3 for ; Thu, 24 Jul 2014 15:27:08 -0700 (PDT)
Received: from [31.133.141.13] ([31.133.141.13]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LlqNY-1Wb6j23nmq-00ZKzP; Fri, 25 Jul 2014 00:27:05 +0200
Message-ID: <53D18827.9010203@gmx.de>
Date: Fri, 25 Jul 2014 00:26:47 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "Leslie Daigle (TCE)" ,  "urn@ietf.org" 
References: <53D185B7.8080102@thinkingcat.com>
In-Reply-To: <53D185B7.8080102@thinkingcat.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:Dw2hhQ011a+lmMfw0fT2/mf13mS1L+0km/1bnAeJi0kZh50pKrc VF29gPxal/xZclctKfz1BSToYjTwHXEsS2kTLslDEP4AOMa/wNYUuyjn5lDTm2ZE/EFtprx fahud8lPGYzT2wdg2W744JGUC0bX/hvp4eUidac14tyn7VvjQN7h/m9SzOv4nVRIo0MGXb5 21t9/z+/fs7yqhs1RdSSQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/KIW-b3sFgYY25QyVqVgzZvm5HTM
Subject: Re: [urn] Choice matrix
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Jul 2014 22:27:10 -0000

On 2014-07-25 00:16, Leslie Daigle (TCE) wrote:
>
> Hi,
>
> Reading through John's slides for tomorrow, something clicked in my head
> (errr, hope it wasn't unhealthy ;-) ) and it seemed to me to be useful
> to think of the discussion in terms of a matrix of choices:  whether or
> not URN syntax is divorced from URI syntax; whether or not "?" and "#"
> syntax elements are defined for URNs.
>
> I deliberately stated those in terms of functional choices, not
> semantically-laden options.
>
>
> 1-1:  URN syntax IS divorced from URI syntax; "?" and "#" ARE defined
> for URNs
>      + Avoids the problem that existing URI fragment & query semantics
> don't fit for URNs
>      + Can (IMO, should) define "?" and "#" using terms OTHER than
> fragment and query, and make them as generally applicable to URNs (as
> defined by the IETF standard) as possible
>      - contributes to demise of the current standard for URI syntax
>      ? problems with parsers?
>
>
> 0-1:  URN syntax is NOT divorced from URI syntax; "?" and "#" ARE
> defined for URNs
>      - Existing URI fragment & query semantics don't fit for URNs;
> workarounds include per-namespace rules, etc, but largely unenforceable
 > ...

Can you elaborate on what's the problem with the RFC 3986 semantics for 
queries? (not fragments)???

Best regards, Julian


From nobody Fri Jul 25 04:34:26 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B788A1A01EF for ; Fri, 25 Jul 2014 04:34:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.101
X-Spam-Level: 
X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=no
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 lrAkbH6VOaXy for ; Fri, 25 Jul 2014 04:34:20 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 818B71A01A9 for ; Fri, 25 Jul 2014 04:34:20 -0700 (PDT)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XAdh6-000FjJ-7G; Fri, 25 Jul 2014 07:29:48 -0400
Date: Fri, 25 Jul 2014 07:34:17 -0400
From: John C Klensin 
To: =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= , urn@ietf.org
Message-ID: 
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/1PofKh3I6g_C0GR6Enks-mIPvYY
Subject: Re: [urn] Tomorrow''s "URNs are not URIs" topic
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 11:34:24 -0000

Hi.  I'm sorry it has taken so long to get this note and the
accompanying one out.  Putting together a careful response,
checking it against specific text in 3986 and other documents,
and going over some of those checks with others has taken around
8 FTE hours during a busy IETF meeting with many interruptions.
I hope it is right (there is an additional disclaimer in the
other note) but, if it isn't, can we try to be as specific as
possible, especially about what documents say and what is
[just?] based on common practices and interpretation. =20

I've also worked on the two in parallel: there may be
information in either one that helps inform parts of the other.

--On Thursday, 24 July, 2014 22:05 +0900 "\"Martin J. =
D=C3=BCrst\""
 wrote:

>...
>> (1) If people's concerns about "URNs are not URIs" are about
>> some perceived symbolism, I think we should rework the draft
>> with a different name and terminology to reduce that =
symbolism
>> as much as possible.   The draft is intended to be a =
pragmatic
>> solution to a practical problem, not to make any symbolic
>> points.
>=20
> If there is indeed a practical problem (I have asked for one
> and tried to find one myself, but haven't been successful),
> then the best solution is for the draft to describe the actual
> problem. Name and terminology may be important, but they are
> secondary.

See following note.

>> (2) Some comments on the list have seemed to imply =
assumptions
>> that the separation is about changes that would cause generic
>> URI parsers to fail in massive ways.  It would allow us to do
>> that.  However, or actually doing so is unnecessary for any
>> way that I can imagine, would probably create incompatibility
>> with URNs allowed by 2141 and in use, and, IMO, would be a
>> stupid move for those and other reasons.  As a parser
>> specification, 3986 only requires [1] a separation of
>>     method:path?query#fragment
>> using the delimiters shown.  I don't think we need to change
>> that in any way that would  cause such a parser, much less a
>> parser based on
>>     method:
>> to fail.
>=20
> Okay, great. Then what's that "separation" about?

Getting away from limitations in 3986-imposed restrictions and
semantics considerably below that level.  I think that is in the
slides.  Really.

>> [1] More or less.  The spec is unintentionally tricky and
>> actually does not quite "work".  I hope we can avoid getting
>> dragged into that discussion.
>=20
> I don't want to get into complicated discussions. But given
> the number of times that people like Julian and me and others
> have had to correct extremely simple misunderstandings and
> basic logical errors, I would appreciate if you could say in
> detail what you are talking about here. There is a high chance
> that the spec is actually quite simple and does work, and I
> wouldn't want anybody to miss that.

Independent of the problematic restrictions (see above and the
slides), 3986 contains a lot of "stuff" that has no
applicability to 4121 URNs and that could easily be banned from
expanded URNs without any negative effect.  Take the dot-removal
stuff.  It would be fairly simple to just ban those from URNs as
we expand them; as far as I can tell the very restricted forms
allowed by 2141 ban them now.  After several readings, it is not
clear whether, once one expands because 2141, such a ban would
actually be conformant to 3986.

All the machinery for relative URIs (really relative URLs, IMO).
are another example of something that is unneeded for URNs,
could cause confusion if used, but do not appear to be ban-able
on a per-method basis.

At a different level, the syntax production for  (in
Section 3.3)  appears to use an RHS matching rule and/or an
implicit name-component match to link it to the production for
 at the beginning of Section 3. I've seen syntactic
metalanguages that allow things like that, but ABNF isn't one of
them (nor, AFAIK, is there anything in its family that does).
There is no production, or set of productions, that I can find
that links through from  (beginning of Section 3) to
.  How confusing that is depends on experience and
perspective, and it may be worse for people with lots of
experience reading ABNF and metalanguages of the same general
style and easier for people who just mentally shrug and move on.
But it is not correct.

>> To review an example in advance of the slides, 3986 gives a
>> very specific interpretation to what people --and many
>> existing URL applications-- consider a sequence of queries,
>> e.g., ?x abc?y def?g=3Dhttp://foo.example.com/?
>>=20
>> 3986 allows the sequence but treats it as a single query
>> string.
=20
> Well, yes. That's not because RFC 3986 didn't understand URNs
> or whatever, but because there are virtually no such strings
> around.
> Everybody on the Web writes queries like the above as
> something like:
>=20
> ?x=3Dabc&y=3Ddef&g=3Dhttp://foo.example.com/

And they often take, and treat, it as an ordered sequence.  The
issues arises if one has an unordered sequences of, e.g.,
name-value pairs that one wants to express as or embed in
queries because queries are the only tool that 3986 provides.
Out of curiosity, is "Everyone on the Web..." do it another way
in http UPLs, identify one of those factual errors?

>> AFAICT, the only practical difference is that permuting the
>> sequence of queries would, under 3986, cause two URIs to
>> compare not equal (one of many types of false negatives for
>> some URL situations that 3986 predicts).
>=20
> RFC 3986 does in no way limit anybody's choice in how to do
> URI comparisons. Section 6
> (http://tools.ietf.org/html/rfc3986#section-6) gives a long
> (but in no way closed or complete) list of some ways to
> compare URIs and some of the applications for these various
> comparisons.

Yes, and I've said things that agree with that statement several
times.  On the other hand,=20

(i) Section 6.2 discusses a comparison ladder and appears to
say, approximately, "apply as many of these operations, in
order, as you  like, with the understanding that going further
up the latter will cost more processing time but eliminate more
false negatives" (see Section 6.2 for the exact statement).
Noting that several of the rungs on that latter are not
applicable for URNs (but would be harmless if mechanically
applied), I can find nowhere in Section 6 that says "compare any
way you like" or "additional types of comparisons are
encouraged, or even allowed, on a per-method basis" except for
Section 6.2.3, which does not appear to me to be applicable to
URNs.

(ii) It appears to me that the statements, e.g., in Section 3.4,
make the query component atomic as far as 3986-based equivalence
checking is concerned and do not make allowance for per-method
parsing, much less reordering in some method-dependent canonical
way, of that atomic unit in making comparisons.  I could find
nothing in Section 6 that contradicts that and I've now read it
carefully three times in the last 48 hours.   If you can, please
point me to it because I'm sincerely wondering what I missed.
If not, can we pull back a bit from statements like "no basis in
facts"?

> For the schemes where queries are mostly used (http: and
> https:), queries are mostly interpreted by software on the
> server, and I can tell you that most decent Web frameworks
> (starting with Ruby on Rails, which I know best) do exactly
> the same with
>=20
> ?x=3Dabc&y=3Ddef&g=3Dhttp://foo.example.com/
> and
> ?x=3Dabc&g=3Dhttp://foo.example.com/&y=3Ddef
>=20
> and all the other permutation variants.

Here we get into a gray area, at least IMO, because 3986 clearly
allows a method-specific implementation to do whatever it wants
to interpret a query string, including treating its components
any way it likes.  But that is not part of the 3986-level
parsing or comparison procedure, it is something that 3986
allows in the process or accessing or considering the object.
The first sentence of Section 3.4 appears to say that, although
I'm not positive that is what it means.   That takes us back to
a discussion that has been going on, IMO, unproductively, for
more than 20 years.  If one believes that URNs are either bogus
or really no different from http-URLs (and I note that all of
your examples are based on the latter), then, yes, all of this
works out except, maybe, the option Section 6 gives for
determining equality by fetching the resources and comparing
them rather than syntax.  If one believes that URNs are a
different sort of more abstract naming critter, then it becomes
less clear what that first sentence means (if anything).

>> Because of some expectations
>> about URNs (e.g., "persistence" and non-retrieval uses), that
>> restriction may be worth a change, even if the syntax of the
>> query-collection does not change a bit.
>=20
> There's no need to change. It's already mostly done that way
> where it matters.

And, clearly, one option for the URN WG is to say "mostly, where
it matters, no one pays much attention to what 3986 says in
detail, so we should follow common practice and ignore it".   I
don't find that satisfactory but if the WG, which still had a
charter item to align URNs with 3986, thinks it can do that and
survive Last Call, it would be very efficient.

>  On the other hand, trying to declare by fiat
> that every place that up to now compared URIs by simple
> character-by-character comparison MUST compare those URIs that
> start with urn: in a different way will not get very far.

To the best of my knowledge, no one has suggested any such thing
as a "MUST compare differently".  I certainly have not.   I note
that Section 6.2.1 appears to strongly discourage bit-by-bit and
byte-by-byte comparisons and prefer character-by-character ones
but also warns that it, and its position on the bottom rung on
the ladder, guarantee a higher proportion of false negatives
than testing based on more subtle parsings of URIs.

However, if one wanted to think about this a different way (I
think it would drag things out and I don't particularly want to
do the work) the comparison part of the problem could be
addressed by=20
(i) Modifying Section 3.4 to explicitly allow particular methods
(or just URNs) to impose requirements that subdivide the query
as long as the "from '?' to '#' or end" rule is not violated and
(ii) adding a 6.2.5 that applied to those method(s) only.


>> Anyway, I hope the rest of you are looking forward to a
>> constructive meeting tomorrow, one that makes significant
>> progress, as much as I am.
>>=20
>> Note that these slides are _not_ "final".  I may not use all
>> of them and they will probably be edited again to improve
>> clarity for the proceedings if not before tomorrow.
=20
> I hope we get the version of the slides that was used for
> presentation into the proceedings (modulo simple typos).
> Otherwise, it's not worth calling these "proceedings". Of
> course, you can always produce updated versions and send them
> here or publish them wherever feasible.

That was my intent.

> Now let's get to the slides:
>=20
> Slide 3: "Written before 3986 and so not really subject to its
> semantic restrictions": As I have tried to explain before,
> there are really NO relevant semantic restrictions in RFC
> 3986. If there are any, please point them out.

See above and the slides.   "This all gets treated as one
string" or "this is processed by the user agent after retrieval
and has to be interpreted according to the media type" (not the
exact words of 3986 which I don't have in front of me but, I
believe, an accurate characterization) are semantic
restrictions... or, if you prefer other words, restrictions that
go beyond a simple specification of syntax.   "Relevant" is, of
course, debatable but depends on these other uses and use cases,
not on whether there are semantic restrictions and statements in
3986.

> Slide 4: "Effectively imposed retroactive requirements on
> URNs": This isn't true. RFC 3986 didn't impose anything on
> URNs. It was written carefully to make sure that URNs fit into
> the overall picture.

I really don't want to have the discussion that leads off
because it involves opening up old arguments and wounds but,
since you have said similar things several times and challenged
me (and others) to refute it...   The problem in the last
sentence is that there is disagreement about what URNx are and
hence what overall picture they fit into.   At least one of the
listed authors of 3986 is on record as not believing that URNs
are legitimate, that the distinctions some people are trying to
make about them make any sense, and, indeed, that there is
anything one can do with a URN that cannot be done with an HTTP
URL.  URNs that fit into _that_ overall picture could be pretty
easy and totally irrelevant to URNs as seen by those who think
they are different and that the differences are important.

> Slide 4: "3986 Could have said 'if a =E2=97=8A (or "?" or
> #") appears, it is
> used to indicate a "foo", with the interpretation of
> "foo" being scheme-dependent'
> =E2=80=93 Did not. Specified what "?" and "#" meant and how
> and where they were to be interpreted."
> The "where to be interpreted" piece is true for "#". That's
> mostly because existing software (for almost as long as the
> Web has been around) does it that way. So "#" is indeed out of
> reach of URNs, as well as any other scheme. But that's not a
> retroactive requirement that RFC 3986 did put on URNs. With
> respect to "?", "the interpretation being scheme dependent" is
> exactly what RFC 3986 says, just in slightly different words.
>...

> Slide 7: "We have no ability to tell them
> =E2=80=93 Don't use URNs
> =E2=80=93 Don't use URNs in that particular way
> =E2=80=A6 or expect them to listen if we do."
> I think we can't for sure expect them to listen, but we can at
> least try to talk to them.

Sure.  And I intend to say something like that as I'm going
through the slides in the meeting.  At the same time, we aren't
going to say the first unless we conclude that either URNs are
not legitimate or that they aren't legitimate for some of those
uses, especially library-like ones.  Given the charter, if we
reach  that conclusion, I think we are done.  Relative to the
second, we have been trying to talk with them, but we can't have
much of a conversation if we deny either their experience or the
legitimacy of their needs (see other note).
=20
> Slide 7: "They can create their own ("forked") URN
> standard for
> their communities any time they like.
> =E2=80=A2 If we want to retain control of the overall design/
> architecture,, we need to treat each community as
> having importance"
> It's nice to be able to tell others they are important. But
> how many communities are there? If each community wants
> something different from URNs, what will be left of URNs when
> we are done? What we need is good engineering, collect
> requirements, find solutions that work across these
> requirements, and so on. "Splitting" before we have a clear,
> documented idea of where we want to go doesn't make sense.

See other note, but we have no reason to believe that the
requirements are incompatible.  So far the only evidence of "do
my thing but nothing else" or "my needs exclude those of others"
requirements come from those who say "adhere strictly to the
syntax and semantics or 3986" or "don't extend 3986 beyond =
2141".

> Slide 8: "Verify that 3986-conforming queries and
> fragments are sufficient for all needs of present
> and future communities.": As you indicated with "Requires
> predicting the future with high confidence", this is
> essentially impossible.

Yes, that was the point.

> What URIs do is to provide a very, very course structure for
> identifiers, so that any kind of identifier need can be
> accomodated.

If one accepted PHB's model of URIs --what I've referred to as
"Scheme:" or "Method:", that would certainly be
true.   If 3986 specified syntax but not semantics, we could
probably make it work.   Given the syntax and semantics, the
"any kind of identifier need" becomes dubious.   I think I've
provided some evidence that is true.  In contrast, you have
asserted "no basis in facts" and "any kind of identifier need".
I've not being persuaded by your evidence, much of which I
believe to be non-existent; you are not being persuaded by mine,
much of which you seem to believe I have not offered.  I don't
see how me make progress on that basis.

> It has worked well so far, and it should work
> well in the future. Of course this requires target communities
> to make a minimum of compromises. If somebody comes along and
> says: I want "#" to mean query and "?" to mean fragment, that
> wouldn't work, about as badly as if somebody comes and says: I
> want "table" to mean "bed" and "bed" to mean "table". (sorry,
> didn't see the "bed" on the next slide coming, this is
> unrelated)
=20
> Slide 9: "And the result looks silly enough": Can you (or
> somebody) tell me what kinds of "silly" stuff you are talking
> about?

Please, e.g., look at Dave Worley's strawman about using escapes
to embed everything in the NSS, thereby staying within the 2141
constraints.

> Slide 10: "Avoids dealing with generic URI semantics that many
> people don't realize are there": Well, they are not there.
> If they are there, please show them.

See above.

> Slide 10: "If needed, allows a discussion of other syntax than
> that
> specified for generic URIs": Discussion is always allowed. If
> at the end of the discussion (or in the middle), somebody
> says: "what about replacing this character with this other
> one, then we don't have to "split", then we can always make a
> split if we really think we need.

See above.   My definition of "allowed" may be a little
different from yours because my sense it that the foundation of
several comments on this list is that changes to, or departure
from, 3986 is not allowed to be discussed.

> Slide 12: "If WHATWG / W3C succeed in killing 3986": W3C
> doesn't want to till RFC 3986. WHATWG will only succeed to the
> extent that the IETF allows it.

No, they will succeed to the extent that the marketplace accepts
what they are doing and/or the browser vendors accept and
implement what they saying and not more openly developed
consensus standards from other areas.  That is more likely to be
the case if W3C endorses and publishes what they produce with
minor or no modifications and that seems to be on track.   At
that point, the only choices IETF will have is whether to have
forked standards covering things of the same name or to give in
and conform to whatever W3C/WHATWG have produced.  I think the
URN situation is, in that regard, quite similar except that some
of the other bodies involved are much more established and
better-known.

> The best way to think about
> that spec is to see it as a detailed implementation spec to
> avoid or reduce browser divergence. It contains all the stuff
> a browser implementer needs to know, but virtually nothing
> else.=20

While you can look at it that way, statements made by several of
the leaders of that group over the last couple of years suggest
much broader intent and applications as well as a view that the
world resolves around the web and that either nothing else
counts or everything else should get in line.  The recent flap
about deprecating the IANA Charset registry is, IMO, symptomatic
of that pattern.

> In that sense, "Assuming that persistent names without
> location properties are a myth (or just dumb)" is slightly
>  wrong; they are just not relevant for browsers (simply put,
> because nothing happens when you click on them). And by the
> way, while the spec uses "URL", than in no way excludes URNs.
> It's just that the spec writers decided that the term "URL"
> was much more widely known than "URI", and wide familiarity of
> Web developers with this term was considered more important
> that terminology hairsplitting.

But that "terminology hairsplitting" goes to the scope of what
these various specs apply to.  If you turn it around, we
wouldn't be having this discussion at all had someone gone
through 3986 before publication and substituted "URL" or "URI".
>From a different point of view --I think expressed on this list
in the past-- the difficulties with 3986 are precisely that it
was written for URLs and then extrapolated to URNs by changing a
few words.  I think that is an exaggeration at best, but that
the careful attention to the needs of URNs you cite was largely
limited to the URNs of 2141 and not the allowances it makes for
further extension much less needs that were not well-defined at
the time.

I think your comment above reflects the same problem.  If one
can say "URL" and mean "HTTP[S] URLs in a Web Browser context"
but then claim it really applies to all URIs including URNs we
are, at best, in very bad shape wrt communicating with each
other and probably in worse shape to consider the needs of
communities whose needs are very different from those of the
HTTP-URL-in-browser community. =20

> Slide 13: "Case-sensitive query and fragment compares unless
> changed for all URNs.": Even if you want to change that, you
> probably can't. As an example, there are a lot of URNs used
> for XML namespaces, and these do character by character
> comparison, to the extent that even
> "http://example.org" and "Http://example.org" are different
> despite RFC 3986 saying schemes are case-insensitive.

Sadly, that takes us back to the alternate strategy of simply
ignoring 3986 where it is inconvenient and moving on.  It also
takes us down the path of where I think WAHTWG has gone, which
is "enough systems use this that it, rather than anything that
is written into an IETF Standard, is the norm and nothing else
counts".  From some important perspectives, it is actually a
reasonable position to take, but it makes this WG irrelevant:
there are already established URN practices (whether at XML
scale or not may depend on how one measures) that move beyond
2141 so 2141 doesn't need updating except maybe to memorialize
those changes and what 3986 actually says is irrelevant so the
charter item about reflecting it is too.

> Slide 13: "Query is always part of equality comparison =
=E2=80=93
> Fragments apparently never": Where did you get that from? I'd
> guess that all the examples in RFC 3986 work that way, but
> where does the spec *mandate* it? I'd guess nowhere.

What do you think it says?  See the comments about the
comparison ladder above.

> Slide 13: "Urn:foo:bar?a=3Db?c=3Dd and Urn:foo:bar?c=3Dd?a=3Db =
Never
> compare equal": Wrong, it's up to who is comparing them to
> decide.

Not as I read 3986.  See above, note particularly the 3986 text
about the balance between false positives and false negatives,
and explain to me where you get "up to who is comparing them to
decide".   Again, if it is the consensus of the community that
3986 provisions are meaningless in practice, we don't need the
"URNs are not" draft, we need some notes (independent of this
WG) to move 3986 to Historic as no longer of
protocol-specification interest.

> Slide 15: "Very long, complex spec": If you think you can do
> it shorter, why don't you give it a try?

For URLs, with their history of accreted features and odd cases,
it probably cannot be.  Whether the provisions to handle them
need to apply to all URIs is another 	question.    And, while I
think one should probably go a bit further, I note that the
"Scheme:" theory of generic URIs could be written up in
well under a page of substantive text.  That would then require
different specs for each fundamental URI type (where "type" is
probably a class of schemes), with the current 3986 text
providing a good starting point for web-oriented URLs or perhaps
URLs generally.

> "few actually read it": Unfortunately, that shows from time to
> time on this list.

Indeed.

> Slide 15: "Extensive sets of rules irrelevant to URNs (e.g.,
> relative URLs, dot-removal)": True but irrelevant, because it
> doesn't require a split.

But it does go to length and complexity.   What that group of
slides says is only that, were we to decouple from 3986, we
wouldn't need some of its baggage.  I hoped it was clear that I
didn't consider any of it justification for a split.

> Slide 15: "Complex equivalence algorithm": Wrong. No fixed
> algorithm. Various options for
> equivalence/comparison/normalization, because that's what
> happens in practice (with a wide range of choices from XML
> namespaces (see above) to what search engines do for
> optimization)

Perhaps I am reading too much into the "ladder" statements, but
they seemed fairly clear.  And normative as a sequential set of
options.

>...
> Slide 16: "If we want the third, not with 3986." ("the third"
> is "As an additional parameter (if we allow it)"): Why not
> with 3986? I don't think there is anything in RFC 3986 that
> would disallow this.

3986 says, pretty clearly I think, that the path ends with a
"?", "#", or the end of the string.   Queries are all of the
text between "?" and either "#" or the end of the string and
cannot follow fragments, and fragments end with the end of the
string.   So I don't see where else 3986 would allow putting an
additional parameter.

> [I personally think it would be somewhat disingenuous to the
> purity of URNs to include the resolver in the URN, but as far
> as RFC 3986 goes, that would be okay.]

I should probably have said "resolver class" or something to
that effect.  Will fix the slide.

> Slide 17: "If we need "?a=3Dc?d=3De" and "?d=3De?a=3Dc"
> equivalency": The best thing to do here is to write these as
> "?a=3Dc&d=3De" or "?d=3De&a=3Dc". Not everything, but a lot of
> software will treat these as equivalent.

According to my reading, 3986 allows that reading only at the
lowest rung of the equivalency ladder if it allows it at all.
References and comments about "a lot of software" above.

> Slide 18: "If we need such a small deviation
> Why separate from 3986": and what if it turns out that we
> don't need any deviation? Given all the 'reasons' for a
> deviation/split I have seen so far, I think that's the most
> likely outcome, and would definitely save some work and other
> hassles.

Again, I believe that is possible only if one is going to
interpret 3986 very generously.

> Slide 20: "The IESG could apply "not enough energy to do
> work" to the URN topic": If the only way for the URN WG to
> show energy is to prematurely agree on a "split" without
> actually having done the necessary legwork to justify it, that
> would indeed have to be taken as a strong sign of no energy.

As appears to be the case with 3986 and 3987, at least based on
Wednesday's plenary and related discussions.

    john



From nobody Fri Jul 25 04:34:38 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB02B1B27EE for ; Fri, 25 Jul 2014 04:34:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 eD86sNb2yzlS for ; Fri, 25 Jul 2014 04:34:35 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 298431A01A9 for ; Fri, 25 Jul 2014 04:34:35 -0700 (PDT)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XAdhM-000FjV-BW for urn@ietf.org; Fri, 25 Jul 2014 07:30:04 -0400
Date: Fri, 25 Jul 2014 07:34:33 -0400
From: John C Klensin 
To: urn@ietf.org
Message-ID: 
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/PQTYRlHjjjv9hjJxmElmT_yog-4
Subject: [urn] The "needs" (was: Re: Tomorrow''s "URNs are not URIs" topic)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 11:34:36 -0000

Hi.

I was asked in a non-list note what the "needs" are, why they
haven't been more explicit, and, at least implicitly, why I
didn't address them.  To save probably having to answer that
question multiple times, I'm going to protect the anonymity of
the question but answer on-list.

That slide deck already pushes pretty hard on my mandate to
discuss the "URNs are not..." draft (and Andy may beat me up and
get me to narrow it).  So I didn't try to summarize the
needs/requests for that reason and a more important one.  

The latter is that I'm just trying to bring things together on
this and prevent what I otherwise see as an inevitable fork,
probably in multiple directions.  I prefer that those with
requirements not met by 2141 would speak for themselves.  In
several cases, I think they have but one of our problems in this
WG is different communities speaking in different conceptual
languages and not being understood by others (even at the level
of whether and what requirements are being stated).  I may well
have a version of that problem that causes me to inadequately
understand what people are asking for.

I still really hope that those who have expressed those
requirements will explain them in clear form (in some cases,
"again") either on-list or in today's meeting.  What follows is
_not_ really adequate.

But, again in the hope of moving things forward and the further
hope that people will correct me if I've gotten things wrong,
things I think I've heard include the following in mo particular
order:

(1) RFC 3986 is quite clear that its comparison rules (for
determining whether two URIs are equivalent) are designed to
produce zero false positives with the expectation of lots of
false negatives.   It also suggests that the ultimate criterion
for URI equality involves retrieving the objects pointed to by
two URI strings and then comparing them, with comparison
criteria presumably depending on media type or other
content-specific features.   Precisely because a lot of URNs are
defined without content or used without the expectation of
retrieving content, somewhat deeper criteria --fewer false
negatives-- for URN comparison may be in order.  The query set
example I used in the slides is a rather trivial example of that
issue should the WG want to go in that direction, but I gather
that there are other concerns and cases people would like to
have covered.

(2) As a sort of extension to the above, I think I've heard
requests for even finer control of matching/comparison with,
e.g., some query terms (or fragment terms) participating in
matching and others not.  If that is real, we need syntax or
other mechanisms to denote which is which.  And, of course, we
need to define "terms", which immediately takes us beyond 3986.
I discussed that possibility further on-list some months ago
with comments about a possible four-tuple to be specified in
registration, part of a "query", or otherwise and summarized
that option in the temporary appendix B to urns-are-not-uri-01.
I hope then and hope now that we don't need to go that far, but
I think it represents the most general case (and a rather
different data model from 3986, regardless of what can be forced
into the latter).

(3) It has been pointed out that, if one has a name that is
associated with an object, one might be interested in lots of
aspects of that name, including the object, a whole lot of
properties of the object, the number and locations of instances
of the object (perhaps up to some ceiling), and so on for a
rather long list.  One of the philosophical issues I've been
trying to avoid under the "if we tell 'them' what to do, they
are likely to ignore us and fork the spec instead" umbrella is
that one can, in principle, express those things with
constructions like:

ObjectRetrieverFromName://resolver-retriever-domain/parametric-stuff?urn:foo:name-describing-stuff

One could use similar things for different types of data,
metadata, or inquiries.   Note that, if additional query
information is needed that would naturally go in queries, any
notion of hierarchy or association-bindings in the query is, as
Martin indirectly pointed out, a matter of very local
conventions.  If one believed those associations were needed in
syntax for all URNs or probably even on an NID basis, that would
constitute a requirement that 3986 does not meet and may, if
read narrowly, not allow a URI to meet.

If, by contrast one wants some of that information bound to or
as a conceptual part of a URN (one not embedded in some other
URI string), it appears that one at least needs queries in URNs
and may need an extended version of what 3986 specifies as query
syntax.  That, as discussed elsewhere, may require somewhat more
specificity about comparisons, relationships among information
or requests, and so on than are permitted by 3986's
effectively-atomic query string, whether the internal delimiters
are "%", "?", both, or something else.   See the response to
Martin, the slides, and the discussion of 4-tuples above for
cases that represent different degrees of extreme.

best,
   john


From nobody Fri Jul 25 07:30:06 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0861B295A for ; Fri, 25 Jul 2014 07:30:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
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 14212_w1wmtb for ; Fri, 25 Jul 2014 07:29:58 -0700 (PDT)
Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C47831B2970 for ; Fri, 25 Jul 2014 07:29:40 -0700 (PDT)
Received: from angora-2.local ([::ffff:206.47.221.210]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 25 Jul 2014 10:29:39 -0400 id 015AC2BF.53D269D3.0000655A
Message-ID: <53D269D2.2030902@thinkingcat.com>
Date: Fri, 25 Jul 2014 10:29:38 -0400
From: "Leslie Daigle (TCE)" 
Organization: ThinkingCat Enterprises
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Julian Reschke , "urn@ietf.org" 
References: <53D185B7.8080102@thinkingcat.com> <53D18827.9010203@gmx.de>
In-Reply-To: <53D18827.9010203@gmx.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/gFaEqXyAgR3pDsDeU3o2ARuau5E
Subject: Re: [urn] Choice matrix
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 14:30:00 -0000

(Keenly aware that this is a slippery slope, and trying not to rehash 
every single previous argument):

[Julian quoted me and said:]
 >> 0-1:  URN syntax is NOT divorced from URI syntax; "?" and "#" ARE
 >> defined for URNs
 >>      - Existing URI fragment & query semantics don't fit for URNs;
 >> workarounds include per-namespace rules, etc, but largely unenforceable
 >  > ...
 >
 > Can you elaborate on what's the problem with the RFC 3986 semantics for
 > queries? (not fragments)???

RFC2141 set aside the use of "?" because we could not figure out how 
queries (in the URI standard) made sense against _all_ URNs/URN namespaces.

And, if they don't make sense for all URNs, it's hard to see how to 
enable them in the URN-wide standard.

Leslie.



On 7/24/14 6:26 PM, Julian Reschke wrote:
> On 2014-07-25 00:16, Leslie Daigle (TCE) wrote:
>>
>> Hi,
>>
>> Reading through John's slides for tomorrow, something clicked in my head
>> (errr, hope it wasn't unhealthy ;-) ) and it seemed to me to be useful
>> to think of the discussion in terms of a matrix of choices:  whether or
>> not URN syntax is divorced from URI syntax; whether or not "?" and "#"
>> syntax elements are defined for URNs.
>>
>> I deliberately stated those in terms of functional choices, not
>> semantically-laden options.
>>
>>
>> 1-1:  URN syntax IS divorced from URI syntax; "?" and "#" ARE defined
>> for URNs
>>      + Avoids the problem that existing URI fragment & query semantics
>> don't fit for URNs
>>      + Can (IMO, should) define "?" and "#" using terms OTHER than
>> fragment and query, and make them as generally applicable to URNs (as
>> defined by the IETF standard) as possible
>>      - contributes to demise of the current standard for URI syntax
>>      ? problems with parsers?
>>
>>
>> 0-1:  URN syntax is NOT divorced from URI syntax; "?" and "#" ARE
>> defined for URNs
>>      - Existing URI fragment & query semantics don't fit for URNs;
>> workarounds include per-namespace rules, etc, but largely unenforceable
>  > ...
>
> Can you elaborate on what's the problem with the RFC 3986 semantics for
> queries? (not fragments)???
>
> Best regards, Julian


From nobody Fri Jul 25 07:32:08 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88E51A0318 for ; Fri, 25 Jul 2014 07:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.55
X-Spam-Level: 
X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] autolearn=ham
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 d0sYEdNeODKX for ; Fri, 25 Jul 2014 07:31:58 -0700 (PDT)
Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 151EE1B2925 for ; Fri, 25 Jul 2014 07:31:46 -0700 (PDT)
Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id CEBAE92E7C; Fri, 25 Jul 2014 16:31:44 +0200 (CEST)
From: "Svensson, Lars" 
To: "Leslie Daigle (TCE)" , Julian Reschke , "urn@ietf.org" 
Thread-Topic: [urn] Choice matrix
Thread-Index: AQHPp45zq3lH9cWDwkCyOiib43V2PZuwuRYAgAAh1OA=
Date: Fri, 25 Jul 2014 14:31:43 +0000
Message-ID: <24637769D123E644A105A0AF0E1F92EFA446B13A@dnbf-ex1.AD.DDB.DE>
References: <53D185B7.8080102@thinkingcat.com> <53D18827.9010203@gmx.de> <53D269D2.2030902@thinkingcat.com>
In-Reply-To: <53D269D2.2030902@thinkingcat.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.69.12.117]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/F3TQ6BCrOg-jAkVEbt6WZ67cYAs
Subject: Re: [urn] Choice matrix
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 14:31:59 -0000

> (Keenly aware that this is a slippery slope, and trying not to rehash
> every single previous argument):
>=20
> [Julian quoted me and said:]
>  >> 0-1:  URN syntax is NOT divorced from URI syntax; "?" and "#" ARE
>  >> defined for URNs
>  >>      - Existing URI fragment & query semantics don't fit for URNs;
>  >> workarounds include per-namespace rules, etc, but largely
> unenforceable
>  >  > ...
>  >
>  > Can you elaborate on what's the problem with the RFC 3986 semantics fo=
r
>  > queries? (not fragments)???
>=20
> RFC2141 set aside the use of "?" because we could not figure out how
> queries (in the URI standard) made sense against _all_ URNs/URN
> namespaces.
>=20
> And, if they don't make sense for all URNs, it's hard to see how to
> enable them in the URN-wide standard.

That's why I think it would be best to specify queries on a per-NID-basis.

/Lars=20


From nobody Fri Jul 25 07:34:18 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B7F1B295A for ; Fri, 25 Jul 2014 07:34:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level: 
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  FREEMAIL_FROM=0.001, J_CHICKENPOX_31=0.6, MIME_8BIT_HEADER=0.3,  RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
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 R1rQkVeJ1WcC for ; Fri, 25 Jul 2014 07:34:09 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0E01B281C for ; Fri, 25 Jul 2014 07:34:08 -0700 (PDT)
Received: from [31.133.141.13] ([31.133.141.13]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MKprU-1XAgZM0vGy-0007Tx; Fri, 25 Jul 2014 16:34:00 +0200
Message-ID: <53D26AD2.8050302@gmx.de>
Date: Fri, 25 Jul 2014 16:33:54 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: John C Klensin , =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , urn@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:UOElLYKIJXGC3DgneuhysQ8Y6rk4syBVg720D5j5k0Wp3LZ0FxI +Ly/o3bY2DUtY3JAtuJr8YKMYanG9H4IeXBbYFfR2LBPltnkOQoCkkMOaJtsIl9w0DqXV7m KD9RexNivB0NO0GrRNnhc4pXl8ScNf4gPhwtVhnFESHXLHUhZcKNDLtryExZLeDPb0sBIfA r9e4K+xYrzE/pKNlcOMOA==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/oazEr_R-JXYL5_t95cyc82MomzA
Subject: Re: [urn] Tomorrow''s "URNs are not URIs" topic
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 14:34:13 -0000

Hi there,

due to time constraints I'll have to focus on a few specific lines below...

On 2014-07-25 13:34, John C Klensin wrote:
> Independent of the problematic restrictions (see above and the
> slides), 3986 contains a lot of "stuff" that has no
> applicability to 4121 URNs and that could easily be banned from
> expanded URNs without any negative effect.  Take the dot-removal
> stuff.  It would be fairly simple to just ban those from URNs as
> we expand them; as far as I can tell the very restricted forms
> allowed by 2141 ban them now.  After several readings, it is not
> clear whether, once one expands because 2141, such a ban would
> actually be conformant to 3986.
> ...

Does dot-removal play any role outside resolving against a base URI, and 
as part as a totally optional comparison function?

> All the machinery for relative URIs (really relative URLs, IMO).
> are another example of something that is unneeded for URNs,
> could cause confusion if used, but do not appear to be ban-able
> on a per-method basis.

"Unneeded" is not a reason for a split. "Could cause confusion" is more 
severe, but you really need to be more concrete about it.

Generic URI processing code *does* handle relative resolution in a 
generic way. Is this a problem? And what is the intended way to solve this?

If you say "URNs are not URIs" this implies that (1) you can't put a URN 
where a URI is expected anymore, and (2) you can't use generic URI 
processing code. Is this really really the intent?

> At a different level, the syntax production for  (in
> Section 3.3)  appears to use an RHS matching rule and/or an
> implicit name-component match to link it to the production for
>  at the beginning of Section 3. I've seen syntactic
> metalanguages that allow things like that, but ABNF isn't one of
> them (nor, AFAIK, is there anything in its family that does).

If you believe that there's a problem in the ABNF, by all means submit 
an erratum. That being said, I don't understand what the problem is but 
maybe you can explain it today in more detail.

> There is no production, or set of productions, that I can find
> that links through from  (beginning of Section 3) to
> .  How confusing that is depends on experience and
> perspective, and it may be worse for people with lots of
> experience reading ABNF and metalanguages of the same general
> style and easier for people who just mentally shrug and move on.
> But it is not correct.

Why is it not correct?

>>> To review an example in advance of the slides, 3986 gives a
>>> very specific interpretation to what people --and many
>>> existing URL applications-- consider a sequence of queries,
>>> e.g., ?x abc?y def?g=http://foo.example.com/?
>>>
>>> 3986 allows the sequence but treats it as a single query
>>> string.
>
>> Well, yes. That's not because RFC 3986 didn't understand URNs
>> or whatever, but because there are virtually no such strings
>> around.
>> Everybody on the Web writes queries like the above as
>> something like:
>>
>> ?x=abc&y=def&g=http://foo.example.com/
>
> And they often take, and treat, it as an ordered sequence.  The
> issues arises if one has an unordered sequences of, e.g.,
> name-value pairs that one wants to express as or embed in
> queries because queries are the only tool that 3986 provides.
> Out of curiosity, is "Everyone on the Web..." do it another way
> in http UPLs, identify one of those factual errors?

I didn't get what you think is a problem here.

> Yes, and I've said things that agree with that statement several
> times.  On the other hand,
>
> (i) Section 6.2 discusses a comparison ladder and appears to
> say, approximately, "apply as many of these operations, in
> order, as you  like, with the understanding that going further
> up the latter will cost more processing time but eliminate more
> false negatives" (see Section 6.2 for the exact statement).
> Noting that several of the rungs on that latter are not
> applicable for URNs (but would be harmless if mechanically
> applied), I can find nowhere in Section 6 that says "compare any
> way you like" or "additional types of comparisons are
> encouraged, or even allowed, on a per-method basis" except for
> Section 6.2.3, which does not appear to me to be applicable to
> URNs.

"Other scheme-specific normalizations are possible." - 
http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.6.2.3.p.4

Why is that not applicable???

> (ii) It appears to me that the statements, e.g., in Section 3.4,
> make the query component atomic as far as 3986-based equivalence
> checking is concerned and do not make allowance for per-method
> parsing, much less reordering in some method-dependent canonical
> way, of that atomic unit in making comparisons.  I could find
> nothing in Section 6 that contradicts that and I've now read it
> carefully three times in the last 48 hours.   If you can, please
> point me to it because I'm sincerely wondering what I missed.
> If not, can we pull back a bit from statements like "no basis in
> facts"?

I agree with Martin. Nothing in Section 6 disallows scheme-specific 
additional re-ordering.

>> For the schemes where queries are mostly used (http: and
>> https:), queries are mostly interpreted by software on the
>> server, and I can tell you that most decent Web frameworks
>> (starting with Ruby on Rails, which I know best) do exactly
>> the same with
>>
>> ?x=abc&y=def&g=http://foo.example.com/
>> and
>> ?x=abc&g=http://foo.example.com/&y=def
>>
>> and all the other permutation variants.
>
> Here we get into a gray area, at least IMO, because 3986 clearly
> allows a method-specific implementation to do whatever it wants
> to interpret a query string, including treating its components
> any way it likes.  But that is not part of the 3986-level
> parsing or comparison procedure, it is something that 3986
> allows in the process or accessing or considering the object.

It is simply out of scope of the generic syntax and semantics.

> The first sentence of Section 3.4 appears to say that, although
> I'm not positive that is what it means.   That takes us back to
> a discussion that has been going on, IMO, unproductively, for
> more than 20 years.  If one believes that URNs are either bogus
> or really no different from http-URLs (and I note that all of
> your examples are based on the latter), then, yes, all of this
> works out except, maybe, the option Section 6 gives for
> determining equality by fetching the resources and comparing
> them rather than syntax.  If one believes that URNs are a
> different sort of more abstract naming critter, then it becomes
> less clear what that first sentence means (if anything).

Again, I have no idea what the concrete problem here is.

>> There's no need to change. It's already mostly done that way
>> where it matters.
>
> And, clearly, one option for the URN WG is to say "mostly, where
> it matters, no one pays much attention to what 3986 says in
> detail, so we should follow common practice and ignore it".   I

Is there something specific in 3986 that you think is "commonly 
ignored"? If yes, what?

> However, if one wanted to think about this a different way (I
> think it would drag things out and I don't particularly want to
> do the work) the comparison part of the problem could be
> addressed by
> (i) Modifying Section 3.4 to explicitly allow particular methods
> (or just URNs) to impose requirements that subdivide the query
> as long as the "from '?' to '#' or end" rule is not violated and

There's nothing that needs to be modified here.

> (ii) adding a 6.2.5 that applied to those method(s) only.

6.2.3 already allows URI-scheme-specific comparisons. I really don't see 
a problem here.

>> Slide 4: "Effectively imposed retroactive requirements on
>> URNs": This isn't true. RFC 3986 didn't impose anything on
>> URNs. It was written carefully to make sure that URNs fit into
>> the overall picture.
>
> I really don't want to have the discussion that leads off
> because it involves opening up old arguments and wounds but,
> since you have said similar things several times and challenged
> me (and others) to refute it...   The problem in the last
> sentence is that there is disagreement about what URNx are and
> hence what overall picture they fit into.   At least one of the
> listed authors of 3986 is on record as not believing that URNs
> are legitimate, that the distinctions some people are trying to
> make about them make any sense, and, indeed, that there is
> anything one can do with a URN that cannot be done with an HTTP
> URL.  URNs that fit into _that_ overall picture could be pretty
> easy and totally irrelevant to URNs as seen by those who think
> they are different and that the differences are important.

I happen to agree mostly with that author, but then it's totally unclear 
how this affects the technical argument. Can we please stick to what RFC 
3986 says, as opposed to what some of the authors said somewhere else?

>> Slide 12: "If WHATWG / W3C succeed in killing 3986": W3C
>> doesn't want to till RFC 3986. WHATWG will only succeed to the
>> extent that the IETF allows it.
>
> No, they will succeed to the extent that the marketplace accepts
> what they are doing and/or the browser vendors accept and
> implement what they saying and not more openly developed
> consensus standards from other areas.  That is more likely to be
> the case if W3C endorses and publishes what they produce with
> minor or no modifications and that seems to be on track.   At

The IAB and the IESG met with Philippe Le Hegaret on Monday to discuss 
this, and I have a different recollection.

That being said: pulling the WhatWG issue into this discussion is a 
distraction. The reason Anne van Kesteren and others work on their own 
spec (IMHO) has absolutely nothing to do with URNs.

>> The best way to think about
>> that spec is to see it as a detailed implementation spec to
>> avoid or reduce browser divergence. It contains all the stuff
>> a browser implementer needs to know, but virtually nothing
>> else.
>
> While you can look at it that way, statements made by several of
> the leaders of that group over the last couple of years suggest
> much broader intent and applications as well as a view that the
> world resolves around the web and that either nothing else
> counts or everything else should get in line.  The recent flap
> about deprecating the IANA Charset registry is, IMO, symptomatic
> of that pattern.

I agree with what they do is problematic. But can we please focus on 
URNs and RFC 3986?

> I think your comment above reflects the same problem.  If one
> can say "URL" and mean "HTTP[S] URLs in a Web Browser context"
> but then claim it really applies to all URIs including URNs we
> are, at best, in very bad shape wrt communicating with each
> other and probably in worse shape to consider the needs of
> communities whose needs are very different from those of the
> HTTP-URL-in-browser community.

Do you have a proposal how to fix this problem?

>> Slide 13: "Query is always part of equality comparison –
>> Fragments apparently never": Where did you get that from? I'd
>> guess that all the examples in RFC 3986 work that way, but
>> where does the spec *mandate* it? I'd guess nowhere.
>
> What do you think it says?  See the comments about the
> comparison ladder above.

I agree with Martin. Please be more specific.

>> Slide 13: "Urn:foo:bar?a=b?c=d and Urn:foo:bar?c=d?a=b Never
>> compare equal": Wrong, it's up to who is comparing them to
>> decide.
>
> Not as I read 3986.  See above, note particularly the 3986 text
> about the balance between false positives and false negatives,
> and explain to me where you get "up to who is comparing them to
> decide".   Again, if it is the consensus of the community that
> 3986 provisions are meaningless in practice, we don't need the
> "URNs are not" draft, we need some notes (independent of this
> WG) to move 3986 to Historic as no longer of
> protocol-specification interest.

Again, Martin is right. Software that is aware of URN-specific rules can 
normalize query strings any way it likes (and is defined for that scheme).

>> Slide 16: "If we want the third, not with 3986." ("the third"
>> is "As an additional parameter (if we allow it)"): Why not
>> with 3986? I don't think there is anything in RFC 3986 that
>> would disallow this.
>
> 3986 says, pretty clearly I think, that the path ends with a
> "?", "#", or the end of the string.   Queries are all of the
> text between "?" and either "#" or the end of the string and
> cannot follow fragments, and fragments end with the end of the
> string.   So I don't see where else 3986 would allow putting an
> additional parameter.

If it hurts, don't do it.

> ...

Best regards, Julian


From nobody Fri Jul 25 07:36:37 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A801A02CF for ; Fri, 25 Jul 2014 07:36:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 IP_fqQ7ex8VT for ; Fri, 25 Jul 2014 07:36:33 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DE091B2994 for ; Fri, 25 Jul 2014 07:36:21 -0700 (PDT)
Received: from [31.133.141.13] ([31.133.141.13]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M9aX9-1XMT7B0e2J-00D36Q; Fri, 25 Jul 2014 16:36:14 +0200
Message-ID: <53D26B5A.4000509@gmx.de>
Date: Fri, 25 Jul 2014 16:36:10 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "Leslie Daigle (TCE)" ,  "urn@ietf.org" 
References: <53D185B7.8080102@thinkingcat.com> <53D18827.9010203@gmx.de> <53D269D2.2030902@thinkingcat.com>
In-Reply-To: <53D269D2.2030902@thinkingcat.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:hMisFpZIxVgY71bZCRcfDFKiu6eA/jIr6BYAOWGnHYgUTKHbh+x YrHx1OnGxO0kmIYGXmLOkk9gU3fdGCDebGz70tahbRftgnHsjCnbrr5b+ktWvfCol83+0g/ dkb5eOUAyXBuuPVoxFcliqqCK74Lak4CFe1XGlony3jzp4+pn77fxmMNiePU67HuonA2zwt QUablukRc42N4F6hVkGzQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/cgMksCD-azut84dAlcpu4BHuOug
Subject: Re: [urn] Choice matrix
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 14:36:34 -0000

On 2014-07-25 16:29, Leslie Daigle (TCE) wrote:
>
> (Keenly aware that this is a slippery slope, and trying not to rehash
> every single previous argument):
>
> [Julian quoted me and said:]
>  >> 0-1:  URN syntax is NOT divorced from URI syntax; "?" and "#" ARE
>  >> defined for URNs
>  >>      - Existing URI fragment & query semantics don't fit for URNs;
>  >> workarounds include per-namespace rules, etc, but largely unenforceable
>  >  > ...
>  >
>  > Can you elaborate on what's the problem with the RFC 3986 semantics for
>  > queries? (not fragments)???
>
> RFC2141 set aside the use of "?" because we could not figure out how
> queries (in the URI standard) made sense against _all_ URNs/URN namespaces.
>
> And, if they don't make sense for all URNs, it's hard to see how to
> enable them in the URN-wide standard.

I understand that, but it's not a problem of RFC 3986, right?

Best regards, Julian




From nobody Fri Jul 25 07:39:43 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CBA1B2994 for ; Fri, 25 Jul 2014 07:39:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 jZBcB2u5bwx1 for ; Fri, 25 Jul 2014 07:39:41 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811731B2991 for ; Fri, 25 Jul 2014 07:39:41 -0700 (PDT)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XAgaS-000G9w-Rf; Fri, 25 Jul 2014 10:35:08 -0400
Date: Fri, 25 Jul 2014 10:39:38 -0400
From: John C Klensin 
To: "Leslie Daigle (TCE)" , Julian Reschke , urn@ietf.org
Message-ID: 
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/sjblapJ0-xItJ6OvZU2Llwoooq8
Subject: Re: [urn] Choice matrix
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 14:39:43 -0000

--On Friday, 25 July, 2014 10:29 -0400 "Leslie Daigle (TCE)"
 wrote:

>  > Can you elaborate on what's the problem with the RFC 3986
> semantics for
>  > queries? (not fragments)???
> 
> RFC2141 set aside the use of "?" because we could not figure
> out how queries (in the URI standard) made sense against _all_
> URNs/URN namespaces.
> 
> And, if they don't make sense for all URNs, it's hard to see
> how to enable them in the URN-wide standard.

I think that is much of the reason why discussions in the last
couple of year about making query syntax available has
concentrated on allowing them in the syntax but allowing their
use only on a per-NID (registration) basis.  That obviously
means we need to figure out appropriate guidance as to what a
processor is expected to do when an URN string is encountered
that contains a query component but for which it makes no sense
and to determine whether we need comparison rules that do
reasonable things (presumably well up the "ladder" described in
3986).   Of course we could conclude that the "appropriate
guidance" or comparison rules  are "do as you will" or "punt".

 best,
    john





From nobody Fri Jul 25 07:47:24 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9B81B2925 for ; Fri, 25 Jul 2014 07:47:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
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 Izm0MUzEJV3a for ; Fri, 25 Jul 2014 07:47:18 -0700 (PDT)
Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388C41B29AD for ; Fri, 25 Jul 2014 07:47:13 -0700 (PDT)
Received: from dhcp-b18d.meeting.ietf.org ([::ffff:31.133.177.141]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 25 Jul 2014 10:47:11 -0400 id 015AC2BF.53D26DEF.00006704
Message-ID: <53D26DEF.3030508@thinkingcat.com>
Date: Fri, 25 Jul 2014 10:47:11 -0400
From: "Leslie Daigle (TCE)" 
Organization: ThinkingCat Enterprises
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Julian Reschke , "urn@ietf.org" 
References: <53D185B7.8080102@thinkingcat.com> <53D18827.9010203@gmx.de> <53D269D2.2030902@thinkingcat.com> <53D26B5A.4000509@gmx.de>
In-Reply-To: <53D26B5A.4000509@gmx.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/oo4ZYWAY5MCPThRcntzRpfmM7T0
Subject: Re: [urn] Choice matrix
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 14:47:23 -0000

I think we agree -- my aim was not to criticize RFC3986, but rather talk 
about the options for URN specification whether it remained part of the 
URI (syntax, semantics) spec or not.  That's not (intended to be) a 
value judgement of the URI spec.

Leslie.

On 7/25/14 10:36 AM, Julian Reschke wrote:
> On 2014-07-25 16:29, Leslie Daigle (TCE) wrote:
>>
>> (Keenly aware that this is a slippery slope, and trying not to rehash
>> every single previous argument):
>>
>> [Julian quoted me and said:]
>>  >> 0-1:  URN syntax is NOT divorced from URI syntax; "?" and "#" ARE
>>  >> defined for URNs
>>  >>      - Existing URI fragment & query semantics don't fit for URNs;
>>  >> workarounds include per-namespace rules, etc, but largely
>> unenforceable
>>  >  > ...
>>  >
>>  > Can you elaborate on what's the problem with the RFC 3986 semantics
>> for
>>  > queries? (not fragments)???
>>
>> RFC2141 set aside the use of "?" because we could not figure out how
>> queries (in the URI standard) made sense against _all_ URNs/URN
>> namespaces.
>>
>> And, if they don't make sense for all URNs, it's hard to see how to
>> enable them in the URN-wide standard.
>
> I understand that, but it's not a problem of RFC 3986, right?
>
> Best regards, Julian
>
>
>


From nobody Fri Jul 25 07:48:07 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3C01A0314 for ; Fri, 25 Jul 2014 07:48:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 MMCjOnRHA8CC for ; Fri, 25 Jul 2014 07:48:01 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2F3B1A032E for ; Fri, 25 Jul 2014 07:48:01 -0700 (PDT)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XAgiX-000GB0-SL; Fri, 25 Jul 2014 10:43:29 -0400
Date: Fri, 25 Jul 2014 10:47:59 -0400
From: John C Klensin 
To: Julian Reschke , "Leslie Daigle (TCE)" , urn@ietf.org
Message-ID: 
In-Reply-To: <53D26B5A.4000509@gmx.de>
References: <53D185B7.8080102@thinkingcat.com> <53D18827.9010203@gmx.de> <53D269D2.2030902@thinkingcat.com> <53D26B5A.4000509@gmx.de>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/ruW6IcoYVP-gZCCYfnaHlLIOLaw
Subject: Re: [urn] Choice matrix
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 14:48:04 -0000

--On Friday, 25 July, 2014 16:36 +0200 Julian Reschke
 wrote:

>> And, if they don't make sense for all URNs, it's hard to see
>> how to enable them in the URN-wide standard.
> 
> I understand that, but it's not a problem of RFC 3986, right?

I believe that is correct.  I believe the query-related problems
with 3986 arise only if one pushes beyond what 3886 is specific
about and if some things that you apparently believe are totally
optional are, in fact, requirements if one goes down a
particular path, e.g., one cannot pick and choose rungs on the
comparison ladder but more conceptually start from the bottom
and work one's way up.  I believe 3986 clearly allows adding
rungs at the top of the ladder, but not reinterpreting the ones
that are there.  I gather you and Martin read it differently.  

I suggest that, if 3986 allows contradictory good-faith and
careful readings, that is a problem with 3986 but not a problem
for URNs.

However, were URNs (or other types of URIs) to move away from
3986 for other reasons, they might be able to avoid taking those
ambiguities, and some operations that are apparently not
optional (another difference in reading) but obviously
inapplicable to many cases, along.   The latter would simplify
fully-conforming implementations although, if I correctly
understand the implications of some of Martin's remarks, either
far more of 3986 is discretionary than I believe to be the case
or fully-conforming implementations are rare.

    john




From nobody Fri Jul 25 08:03:05 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB081B29C1 for ; Fri, 25 Jul 2014 08:03:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 YcRlHBroMdbf for ; Fri, 25 Jul 2014 08:03:03 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B93961A0012 for ; Fri, 25 Jul 2014 08:03:02 -0700 (PDT)
Received: from [31.133.141.13] ([31.133.141.13]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MIhDo-1XCtwR46P2-002DTh; Fri, 25 Jul 2014 17:02:52 +0200
Message-ID: <53D27199.3010007@gmx.de>
Date: Fri, 25 Jul 2014 17:02:49 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: John C Klensin ,  "Leslie Daigle (TCE)" , urn@ietf.org
References: <53D185B7.8080102@thinkingcat.com> <53D18827.9010203@gmx.de> <53D269D2.2030902@thinkingcat.com> <53D26B5A.4000509@gmx.de> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:WQ4k+xGo2QMCjRPd/iyg6VoCbgyNl1XZ0dY7nILJp0UyrDmKsJw +eap4MAwECfghn1GF2lRsW0zOjHgyVYQhvPsAxu2YedIkuJcup1xPSFGAVWa4mAZSxThvIK ah40RDLxpD9mZgHrM1LrqA6yOExOX0MKUSdftM5aWQ0ANp8kANPAfcRpoFLF3RGjpuWFLl/ RkU2CEiK8QX9vRFzyj5gw==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/G5roFtx8d75YWlwMgANm6YXlgKU
Subject: Re: [urn] Choice matrix
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 15:03:04 -0000

On 2014-07-25 16:47, John C Klensin wrote:
>
>
> --On Friday, 25 July, 2014 16:36 +0200 Julian Reschke
>  wrote:
>
>>> And, if they don't make sense for all URNs, it's hard to see
>>> how to enable them in the URN-wide standard.
>>
>> I understand that, but it's not a problem of RFC 3986, right?
>
> I believe that is correct.  I believe the query-related problems
> with 3986 arise only if one pushes beyond what 3886 is specific

...pushes beyond what it actually says...

> about and if some things that you apparently believe are totally
> optional are, in fact, requirements if one goes down a
> particular path, e.g., one cannot pick and choose rungs on the
> comparison ladder but more conceptually start from the bottom
> and work one's way up.  I believe 3986 clearly allows adding
> rungs at the top of the ladder, but not reinterpreting the ones
> that are there.  I gather you and Martin read it differently.

6.2.3 specifically allows scheme-specific normalization. This is your 
extension point.

> I suggest that, if 3986 allows contradictory good-faith and
> careful readings, that is a problem with 3986 but not a problem
> for URNs.

It would be a problem of 3986. I personally think it's clear enough, but 
if some specific prose gives you a hard time then we should raie an 
erratum instead of taking a drastic step.

> However, were URNs (or other types of URIs) to move away from
> 3986 for other reasons, they might be able to avoid taking those
> ambiguities, and some operations that are apparently not
> optional (another difference in reading) but obviously
> inapplicable to many cases, along.   The latter would simplify
> fully-conforming implementations although, if I correctly
> understand the implications of some of Martin's remarks, either
> far more of 3986 is discretionary than I believe to be the case
> or fully-conforming implementations are rare.

You keep ignoring the downsides, as far as I can tell.

If URNs are declared not to be URIs, you can't use them anymore in 
places that accept URIs, right?

Best regards, Julian


From nobody Fri Jul 25 08:13:46 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722E11A0012 for ; Fri, 25 Jul 2014 08:13:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
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 Hn_XflDRzznQ for ; Fri, 25 Jul 2014 08:13:42 -0700 (PDT)
Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9951A02E1 for ; Fri, 25 Jul 2014 08:13:42 -0700 (PDT)
Received: from dhcp-b18d.meeting.ietf.org ([::ffff:31.133.177.141]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 25 Jul 2014 11:13:40 -0400 id 015AC2C8.53D27424.000068CA
Message-ID: <53D27424.2010802@thinkingcat.com>
Date: Fri, 25 Jul 2014 11:13:40 -0400
From: "Leslie Daigle (TCE)" 
Organization: ThinkingCat Enterprises
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "Svensson, Lars" , Julian Reschke , "urn@ietf.org" 
References: <53D185B7.8080102@thinkingcat.com> <53D18827.9010203@gmx.de> <53D269D2.2030902@thinkingcat.com> <24637769D123E644A105A0AF0E1F92EFA446B13A@dnbf-ex1.AD.DDB.DE>
In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA446B13A@dnbf-ex1.AD.DDB.DE>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/0pfhw8cb4tUEFkdjs2H7RixXP5E
Subject: Re: [urn] Choice matrix
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 15:13:44 -0000

To be very clear:  "URN" is the "scheme" in the context of the URI 
syntax.  That is, something that is "scheme definable" in the URI spec 
must be defined for all URNs.

To implement something on a per-NID basis is hard to police (opinion), 
and I believe is not consistent with the URI spec.

Leslie.

On 7/25/14 10:31 AM, Svensson, Lars wrote:
>> (Keenly aware that this is a slippery slope, and trying not to rehash
>> every single previous argument):
>>
>> [Julian quoted me and said:]
>>   >> 0-1:  URN syntax is NOT divorced from URI syntax; "?" and "#" ARE
>>   >> defined for URNs
>>   >>      - Existing URI fragment & query semantics don't fit for URNs;
>>   >> workarounds include per-namespace rules, etc, but largely
>> unenforceable
>>   >  > ...
>>   >
>>   > Can you elaborate on what's the problem with the RFC 3986 semantics for
>>   > queries? (not fragments)???
>>
>> RFC2141 set aside the use of "?" because we could not figure out how
>> queries (in the URI standard) made sense against _all_ URNs/URN
>> namespaces.
>>
>> And, if they don't make sense for all URNs, it's hard to see how to
>> enable them in the URN-wide standard.
>
> That's why I think it would be best to specify queries on a per-NID-basis.
>
> /Lars
>


From nobody Fri Jul 25 08:14:30 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA8B1A02E1 for ; Fri, 25 Jul 2014 08:14:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 vS3ipv-nyIuI for ; Fri, 25 Jul 2014 08:14:26 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DCC81A0012 for ; Fri, 25 Jul 2014 08:14:26 -0700 (PDT)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XAh86-000GF9-GE; Fri, 25 Jul 2014 11:09:54 -0400
Date: Fri, 25 Jul 2014 11:14:24 -0400
From: John C Klensin 
To: "Leslie Daigle (TCE)" , Julian Reschke , urn@ietf.org
Message-ID: <3760CA03DD0D4E9ACDC26297@JCK-EEE10>
In-Reply-To: <53D26DEF.3030508@thinkingcat.com>
References: <53D185B7.8080102@thinkingcat.com> <53D18827.9010203@gmx.de> <53D269D2.2030902@thinkingcat.com> <53D26B5A.4000509@gmx.de> <53D26DEF.3030508@thinkingcat.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Mail-From: john@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/q23vwIIISHyjaf1_--Jx3mm4hGE
Subject: Re: [urn] Choice matrix
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 15:14:29 -0000

--On Friday, 25 July, 2014 10:47 -0400 "Leslie Daigle (TCE)"
 wrote:

> I think we agree -- my aim was not to criticize RFC3986, but
> rather talk about the options for URN specification whether it
> remained part of the URI (syntax, semantics) spec or not.
> That's not (intended to be) a value judgement of the URI spec.

Let me add a personal note to Leslie's comment.   The separation
draft (which others convinced me to call "URNs are not URIs")
was never intended as a value judgment of the URI spec.  It was
just the result of conclusions by several people (and maybe even
the WG), reached before I did, that the entanglements with 3987
were creating complications and impediments with moving forward
with URN work.   The biggest assumed entanglement was that 3986
was basically a URL spec that had been generalized for other
types of URIs but not generalized enough to accommodate URNs
which, advantageous syntax similarities aside, were a different
sort of creature.

It is no secret that I've acquired an aesthetic dislike of the
way 3986 is constructed as I've been working on this URN effort.
But that is my problem and, unless pressed, I don't even want to
spend time discussing it.

A different version of the questions posed by Andy and Leslie is
that, if one says "different kind of creature" and "don't be
completely dependent on 3986", whether one can preserve enough
of the 3986 syntax to allow generic, really scheme-independent,
URI parsers to keep working regardless of what more specific
changes are made for URNs.  I'm pretty sure the answer to that
question is "yes" and that the URN WG shouldn't do anything that
turns it to "no" (whether in conformance to 3986 or not).  

So, if potential incompatibility with generic URI parsers (one
that, among other things, do not make assumptions based on HTTP
practices) is the concern, we really have no disagreement that I
can see.

On the other hand, if the issue is about the legitimacy of URNs
or whether they are (or get to be) a different kind of creature
from traditional HTTP-URLs, then we have a different sort of
disagreement.  I don't know how to make progress on that one.

     john


From nobody Fri Jul 25 08:29:08 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C6A1B2944 for ; Fri, 25 Jul 2014 08:28:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 HzsKePILmDeU for ; Fri, 25 Jul 2014 08:28:51 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49FB1B27D8 for ; Fri, 25 Jul 2014 08:28:50 -0700 (PDT)
Received: from [31.133.141.13] ([31.133.141.13]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MT60g-1X2LAe1AU2-00S71k; Fri, 25 Jul 2014 17:28:46 +0200
Message-ID: <53D277AA.2040901@gmx.de>
Date: Fri, 25 Jul 2014 17:28:42 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: John C Klensin ,  "Leslie Daigle (TCE)" , urn@ietf.org
References: <53D185B7.8080102@thinkingcat.com> <53D18827.9010203@gmx.de> <53D269D2.2030902@thinkingcat.com> <53D26B5A.4000509@gmx.de> <53D26DEF.3030508@thinkingcat.com> <3760CA03DD0D4E9ACDC26297@JCK-EEE10>
In-Reply-To: <3760CA03DD0D4E9ACDC26297@JCK-EEE10>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:cjspjGr26kJ4TRshC/97D6WoRoPg3wwG6cH2Ppx6heTngwr0W6a 8nbWthTlb9b1m/nx7B1JM2DO7yK9gCxsOVMMVoYiD3WXP86dOrzTOi8l2FS6h2foHcAb6ou vWgLhpGE6CXy2gTG46dh2WfibdEbP93I/mQSzwwr2F/gJ/LUbtQ3muspkNH5okwrE0POZ72 xOBs16YMWXsE3wbmR9B2Q==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/lwMdKfVczvYTs6onJAQKHM9_xfA
Subject: Re: [urn] Choice matrix
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 15:28:55 -0000

On 2014-07-25 17:14, John C Klensin wrote:
> ...
> A different version of the questions posed by Andy and Leslie is
> that, if one says "different kind of creature" and "don't be
> completely dependent on 3986", whether one can preserve enough
> of the 3986 syntax to allow generic, really scheme-independent,
> URI parsers to keep working regardless of what more specific
> changes are made for URNs.  I'm pretty sure the answer to that
> question is "yes" and that the URN WG shouldn't do anything that
> turns it to "no" (whether in conformance to 3986 or not).
> ...

But if you continue to feed the non-URI-URNs into code written based on 
RFCs 2396 and 3986, what's the point in pretending they are not URIs????

> So, if potential incompatibility with generic URI parsers (one
> that, among other things, do not make assumptions based on HTTP
> practices) is the concern, we really have no disagreement that I
> can see.
>
> On the other hand, if the issue is about the legitimacy of URNs
> or whether they are (or get to be) a different kind of creature
> from traditional HTTP-URLs, then we have a different sort of
> disagreement.  I don't know how to make progress on that one.

I haven't seen anybody saying URNs aren't legitimate here. Nor does RFC 
3986 does say that.

Best regards, Julian


From nobody Fri Jul 25 08:29:59 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47801B2936 for ; Fri, 25 Jul 2014 08:29:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 UsQMFC8m8jQL for ; Fri, 25 Jul 2014 08:29:53 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B811B27D8 for ; Fri, 25 Jul 2014 08:29:53 -0700 (PDT)
Received: from [31.133.141.13] ([31.133.141.13]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MK4fR-1XC4Lo3RB7-001QnK; Fri, 25 Jul 2014 17:29:50 +0200
Message-ID: <53D277EA.30601@gmx.de>
Date: Fri, 25 Jul 2014 17:29:46 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "Leslie Daigle (TCE)" ,  "Svensson, Lars" , "urn@ietf.org" 
References: <53D185B7.8080102@thinkingcat.com> <53D18827.9010203@gmx.de> <53D269D2.2030902@thinkingcat.com> <24637769D123E644A105A0AF0E1F92EFA446B13A@dnbf-ex1.AD.DDB.DE> <53D27424.2010802@thinkingcat.com>
In-Reply-To: <53D27424.2010802@thinkingcat.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:W3RjEqyxorgCaSpCm4f5uQq7XFUwd2sMwR5c+8xZmlCesykjxCs oU+4XK98nPMie/6OicJytMhO2dBUXhlxByLaVvu7C2Kv19jVngI0V9Gt7EviibdeDpUSBlj V7XRaWyMt7OQOAuNS196OP5itr0UCE3hqJ3SYNg65eY2OeqGi5tmln+piDgHHeJi+l81FA7 TiJh5IWv1gZ9dhuu5QEHQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/JMAQ0fTAWP_uDKP_0HLPNTCTffI
Subject: Re: [urn] Choice matrix
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 15:29:55 -0000

On 2014-07-25 17:13, Leslie Daigle (TCE) wrote:
>
> To be very clear:  "URN" is the "scheme" in the context of the URI
> syntax.  That is, something that is "scheme definable" in the URI spec
> must be defined for all URNs.
>
> To implement something on a per-NID basis is hard to police (opinion),
> and I believe is not consistent with the URI spec.


I agree that it's tricky to specify, but I don't see RFC 3986 forbidding it.

Best regards, Julian



From nobody Fri Jul 25 08:36:28 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18BD1B29AE for ; Fri, 25 Jul 2014 08:36:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 h0T27WlExw-K for ; Fri, 25 Jul 2014 08:36:25 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0D621B298F for ; Fri, 25 Jul 2014 08:36:25 -0700 (PDT)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XAhTN-000GHm-G1; Fri, 25 Jul 2014 11:31:53 -0400
Date: Fri, 25 Jul 2014 11:36:23 -0400
From: John C Klensin 
To: Julian Reschke , "Leslie Daigle (TCE)" , urn@ietf.org
Message-ID: <2002EC06EAC176CD50447913@JCK-EEE10>
In-Reply-To: <53D277AA.2040901@gmx.de>
References: <53D185B7.8080102@thinkingcat.com> <53D18827.9010203@gmx.de> <53D269D2.2030902@thinkingcat.com> <53D26B5A.4000509@gmx.de> <53D26DEF.3030508@thinkingcat.com> <3760CA03DD0D4E9ACDC26297@JCK-EEE10> <53D277AA.2040901@gmx.de>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Mail-From: john@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/RSZkq9nhLcQK0zj4t_-a0xAPZ9E
Subject: Re: [urn] Choice matrix
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 15:36:26 -0000

--On Friday, 25 July, 2014 17:28 +0200 Julian Reschke
 wrote:

> On 2014-07-25 17:14, John C Klensin wrote:
>> ...
>> A different version of the questions posed by Andy and Leslie
>> is that, if one says "different kind of creature" and "don't
>> be completely dependent on 3986", whether one can preserve
>> enough of the 3986 syntax to allow generic, really
>> scheme-independent, URI parsers to keep working regardless of
>> what more specific changes are made for URNs.  I'm pretty
>> sure the answer to that question is "yes" and that the URN WG
>> shouldn't do anything that turns it to "no" (whether in
>> conformance to 3986 or not). ...
> 
> But if you continue to feed the non-URI-URNs into code written
> based on RFCs 2396 and 3986, what's the point in pretending
> they are not URIs????

Leslie's note illustrates why we wanted to unbind URNs from 3986
(whether they are, or are not, URNs is actually not relevant).
She believes that 3986 doesn't allow query syntax (or not) on a
per-NID basis.  You disagree.  The draft was motivated by trying
to get unstuck from that type of argument in order to make
progress on URNs.  

I'll be happy to discuss the legitimacy issues and the reasons
I'm concerned about them with you f2f.

    john

p.s. I'm almost certainly offline between now and when the WG
session starts.


From nobody Fri Jul 25 11:40:47 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350231A0334 for ; Fri, 25 Jul 2014 11:40:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.55
X-Spam-Level: 
X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5] autolearn=ham
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 zKdy1byuy2Ph for ; Fri, 25 Jul 2014 11:40:45 -0700 (PDT)
Received: from nordpol.dnb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id A120F1A015D for ; Fri, 25 Jul 2014 11:40:44 -0700 (PDT)
Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.dnb.de (Postfix) with ESMTP id 897B992FAA; Fri, 25 Jul 2014 20:40:43 +0200 (CEST)
From: "Svensson, Lars" 
To: "Leslie Daigle (TCE)" , Julian Reschke , "urn@ietf.org" 
Thread-Topic: [urn] Choice matrix
Thread-Index: AQHPp45zq3lH9cWDwkCyOiib43V2PZuwuRYAgAAh1OD//+p5AIAAQnaQ
Date: Fri, 25 Jul 2014 18:40:41 +0000
Message-ID: <24637769D123E644A105A0AF0E1F92EFA446B3B7@dnbf-ex1.AD.DDB.DE>
References: <53D185B7.8080102@thinkingcat.com> <53D18827.9010203@gmx.de> <53D269D2.2030902@thinkingcat.com> <24637769D123E644A105A0AF0E1F92EFA446B13A@dnbf-ex1.AD.DDB.DE> <53D27424.2010802@thinkingcat.com>
In-Reply-To: <53D27424.2010802@thinkingcat.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.69.90]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/WObRiN0xLPGbMcrxgEh2SDnRBWA
Subject: Re: [urn] Choice matrix
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 18:40:47 -0000

> On 7/25/14 10:31 AM, Svensson, Lars wrote:
> >> (Keenly aware that this is a slippery slope, and trying not to rehash
> >> every single previous argument):
> >>
> >> [Julian quoted me and said:]
> >>   >> 0-1:  URN syntax is NOT divorced from URI syntax; "?" and "#" ARE
> >>   >> defined for URNs
> >>   >>      - Existing URI fragment & query semantics don't fit for URNs=
;
> >>   >> workarounds include per-namespace rules, etc, but largely
> >> unenforceable
> >>   >  > ...
> >>   >
> >>   > Can you elaborate on what's the problem with the RFC 3986 semantic=
s
> for
> >>   > queries? (not fragments)???
> >>
> >> RFC2141 set aside the use of "?" because we could not figure out how
> >> queries (in the URI standard) made sense against _all_ URNs/URN
> >> namespaces.
> >>
> >> And, if they don't make sense for all URNs, it's hard to see how to
> >> enable them in the URN-wide standard.
> >
> > That's why I think it would be best to specify queries on a per-NID-bas=
is.

> To be very clear:  "URN" is the "scheme" in the context of the URI
> syntax.  That is, something that is "scheme definable" in the URI spec
> must be defined for all URNs.

Is there anything in 3986 that prevents a scheme specification to delegate =
specific parts of the syntax to more specialised specifications? I have rea=
d and re-read 3986 but can't find anything.

> To implement something on a per-NID basis is hard to police (opinion),
> and I believe is not consistent with the URI spec.

The question is if we take the position that things that are not explicitly=
 allowed are forbidden, or if it's not explicitly forbidden, it's allowed.

/Lars


From nobody Fri Jul 25 13:10:29 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4301A0342 for ; Fri, 25 Jul 2014 13:10:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 zednb5w26QfG for ; Fri, 25 Jul 2014 13:10:25 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A6D51A0310 for ; Fri, 25 Jul 2014 13:10:25 -0700 (PDT)
Received: from [142.131.65.175] ([206.47.221.210]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LbgyV-1Wm7Ij2031-00lDHC; Fri, 25 Jul 2014 22:10:22 +0200
Message-ID: <53D2B9AB.6020607@gmx.de>
Date: Fri, 25 Jul 2014 22:10:19 +0200
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "Svensson, Lars" ,  "Leslie Daigle (TCE)" , "urn@ietf.org" 
References: <53D185B7.8080102@thinkingcat.com> <53D18827.9010203@gmx.de> <53D269D2.2030902@thinkingcat.com> <24637769D123E644A105A0AF0E1F92EFA446B13A@dnbf-ex1.AD.DDB.DE> <53D27424.2010802@thinkingcat.com> <24637769D123E644A105A0AF0E1F92EFA446B3B7@dnbf-ex1.AD.DDB.DE>
In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA446B3B7@dnbf-ex1.AD.DDB.DE>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:ccCj5rMqeMOwWlZFnFKjNSE/UHY7aMkTUc0iFguAzOtE3VYImEF TQMBlGDsviSYmfZNPTaDuEReGNX0OLT1amJL73ZOUcUnHOlDAxz1zcxI4Mwf+Rrr9D/UjJQ BqDykzvfKOM1hSWhHkkdFRw6QMc0Ebhmak8MYKZ/6fy3Bdv8ckpYd30UAKqN0ASQw+CcM8g ZyA5Xi167amHp2z+8UsyQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/IT2J7ngyUzOOXjZMtMOcXdj580I
Subject: Re: [urn] Choice matrix
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jul 2014 20:10:27 -0000

On 2014-07-25 20:40, Svensson, Lars wrote:
>> On 7/25/14 10:31 AM, Svensson, Lars wrote:
>>>> (Keenly aware that this is a slippery slope, and trying not to rehash
>>>> every single previous argument):
>>>>
>>>> [Julian quoted me and said:]
>>>>    >> 0-1:  URN syntax is NOT divorced from URI syntax; "?" and "#" ARE
>>>>    >> defined for URNs
>>>>    >>      - Existing URI fragment & query semantics don't fit for URNs;
>>>>    >> workarounds include per-namespace rules, etc, but largely
>>>> unenforceable
>>>>    >  > ...
>>>>    >
>>>>    > Can you elaborate on what's the problem with the RFC 3986 semantics
>> for
>>>>    > queries? (not fragments)???
>>>>
>>>> RFC2141 set aside the use of "?" because we could not figure out how
>>>> queries (in the URI standard) made sense against _all_ URNs/URN
>>>> namespaces.
>>>>
>>>> And, if they don't make sense for all URNs, it's hard to see how to
>>>> enable them in the URN-wide standard.
>>>
>>> That's why I think it would be best to specify queries on a per-NID-basis.
>
>> To be very clear:  "URN" is the "scheme" in the context of the URI
>> syntax.  That is, something that is "scheme definable" in the URI spec
>> must be defined for all URNs.
>
> Is there anything in 3986 that prevents a scheme specification to delegate specific parts of the syntax to more specialised specifications? I have read and re-read 3986 but can't find anything.

Nope.

> ...

Best regards, Julian


From nobody Sun Jul 27 00:35:33 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F171A00D8 for ; Sun, 27 Jul 2014 00:35:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.107
X-Spam-Level: **
X-Spam-Status: No, score=2.107 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=no
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 r74hHJn37DMO for ; Sun, 27 Jul 2014 00:35:30 -0700 (PDT)
Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1903C1A00CF for ; Sun, 27 Jul 2014 00:35:29 -0700 (PDT)
Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 51B6432E4F7; Sun, 27 Jul 2014 16:35:28 +0900 (JST)
Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 737e_f148_ea3fa919_0f86_48c3_8dd2_2bd59197e17b; Sun, 27 Jul 2014 16:35:28 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 8F2B6BF53A; Sun, 27 Jul 2014 16:35:27 +0900 (JST)
Message-ID: <53D4ABAF.5040303@it.aoyama.ac.jp>
Date: Sun, 27 Jul 2014 16:35:11 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Julian Reschke ,  "Leslie Daigle (TCE)" , "Svensson, Lars" , "urn@ietf.org" 
References: <53D185B7.8080102@thinkingcat.com> <53D18827.9010203@gmx.de> <53D269D2.2030902@thinkingcat.com> <24637769D123E644A105A0AF0E1F92EFA446B13A@dnbf-ex1.AD.DDB.DE> <53D27424.2010802@thinkingcat.com> <53D277EA.30601@gmx.de>
In-Reply-To: <53D277EA.30601@gmx.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/MulsbFpQVgXZe0sIAYIBiEq9Zxc
Subject: Re: [urn] Choice matrix
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Jul 2014 07:35:32 -0000

On 2014/07/26 00:29, Julian Reschke wrote:
> On 2014-07-25 17:13, Leslie Daigle (TCE) wrote:
>>
>> To be very clear:  "URN" is the "scheme" in the context of the URI
>> syntax.  That is, something that is "scheme definable" in the URI spec
>> must be defined for all URNs.
>>
>> To implement something on a per-NID basis is hard to police (opinion),
>> and I believe is not consistent with the URI spec.
>
>
> I agree that it's tricky to specify, but I don't see RFC 3986 forbidding
> it.

I actually think it's utterly consistent with RFC 3986. RFC 3986 only 
says that it's "scheme definable". This means that a scheme can define 
what it wants.

The 'mailto' scheme uses a definition that's consistent across all 
'mailto' URIs. A query part such as 'subject=Greeting' or 'body=Hello' 
means exactly the same on every 'mailto' URI. 
(http://tools.ietf.org/html/rfc6068#section-6.1)

The 'http' scheme leaves everything open and completely variable. 
http://example.com?q=foo can e.g. mean something different every 
different hour of the day (not recommended but allowed). There is 
definitely no guarantee that 'q=foo' mean the same thing on 
http://example.com and on http://example.org, quite to the contrary.

If the URN spec decides to leave things to NIDs, that would be in the 
middle of the above two extremes. There's no possibility for that to be 
disallowed.

Regards,   Martin.


From nobody Sun Jul 27 00:51:05 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24D91A00E6 for ; Sun, 27 Jul 2014 00:51:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.908
X-Spam-Level: **
X-Spam-Status: No, score=2.908 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=no
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 d7UcAEqpzpin for ; Sun, 27 Jul 2014 00:51:01 -0700 (PDT)
Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id BD0A31A00E2 for ; Sun, 27 Jul 2014 00:51:01 -0700 (PDT)
Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 382B432E55C; Sun, 27 Jul 2014 16:51:01 +0900 (JST)
Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 737e_f328_5714a77a_07ad_40d6_b3c2_01e80e9a1ef3; Sun, 27 Jul 2014 16:51:01 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 6C0A4BF53A; Sun, 27 Jul 2014 16:51:00 +0900 (JST)
Message-ID: <53D4AF54.8040505@it.aoyama.ac.jp>
Date: Sun, 27 Jul 2014 16:50:44 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Svensson, Lars" ,  "Leslie Daigle (TCE)" , Julian Reschke , "urn@ietf.org" 
References: <53D185B7.8080102@thinkingcat.com> <53D18827.9010203@gmx.de> <53D269D2.2030902@thinkingcat.com> <24637769D123E644A105A0AF0E1F92EFA446B13A@dnbf-ex1.AD.DDB.DE> <53D27424.2010802@thinkingcat.com> <24637769D123E644A105A0AF0E1F92EFA446B3B7@dnbf-ex1.AD.DDB.DE>
In-Reply-To: <24637769D123E644A105A0AF0E1F92EFA446B3B7@dnbf-ex1.AD.DDB.DE>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/diguzjw46Q3NRr7widgR6a9fp3E
Subject: Re: [urn] Choice matrix
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Jul 2014 07:51:03 -0000

On 2014/07/26 03:40, Svensson, Lars wrote:
>> On 7/25/14 10:31 AM, Svensson, Lars wrote:

>> To be very clear:  "URN" is the "scheme" in the context of the URI
>> syntax.  That is, something that is "scheme definable" in the URI spec
>> must be defined for all URNs.
>
> Is there anything in 3986 that prevents a scheme specification to deleg=
ate specific parts of the syntax to more specialised specifications? I ha=
ve read and re-read 3986 but can't find anything.

Nor can I. And I gave examples of widely deployed schemes on both extreme=
s.

>> To implement something on a per-NID basis is hard to police (opinion),
>> and I believe is not consistent with the URI spec.
>
> The question is if we take the position that things that are not explic=
itly allowed are forbidden, or if it's not explicitly forbidden, it's all=
owed.

This isn't something that the URN WG should have to worry about. It=20
should be clear (or derivable with some common sense) from the spec=20
that's being used.

As an example, syntax productions are usually "if not allowed, then=20
forbidden". So trying to claim that urn:NID:=C2=B6=C2=A7=C2=A9=C3=98=C3=B4=
=C3=87 is allowed by RFC=20
3986 would be clearly wrong.

As another example, usage is generally wide open. RFC 3986 delegates=20
specifics of the query part to each scheme because it assumes that there=20
are many possible uses for schemes and queries, and it would be=20
completely foolish to restrict them.

Regards,   Martin.


From nobody Sun Jul 27 01:30:28 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC851A010F for ; Sun, 27 Jul 2014 01:30:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.208
X-Spam-Level: 
X-Spam-Status: No, score=0.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=no
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 jZxb-p0dqSCf for ; Sun, 27 Jul 2014 01:30:21 -0700 (PDT)
Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8991A010E for ; Sun, 27 Jul 2014 01:30:21 -0700 (PDT)
Received: from scmeg01-14.scbb.aoyama.ac.jp (scmeg01-14.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 741D932E4F7; Sun, 27 Jul 2014 17:30:20 +0900 (JST)
Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 737e_1c89_78919c25_12c5_4799_a6ac_082d6dc06aeb; Sun, 27 Jul 2014 17:30:20 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 9A753BF547; Sun, 27 Jul 2014 17:30:19 +0900 (JST)
Message-ID: <53D4B88B.8020106@it.aoyama.ac.jp>
Date: Sun, 27 Jul 2014 17:30:03 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: John C Klensin ,  Julian Reschke , "Leslie Daigle (TCE)" , urn@ietf.org
References: <53D185B7.8080102@thinkingcat.com> <53D18827.9010203@gmx.de> <53D269D2.2030902@thinkingcat.com> <53D26B5A.4000509@gmx.de> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/_xAfRRd8xR9PZ0YEye9RGIIsDLU
Subject: Re: [urn] Choice matrix
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Jul 2014 08:30:23 -0000

Hello John,

On 2014/07/25 23:47, John C Klensin wrote:

> I believe the query-related problems
> with 3986 arise only if one pushes beyond what 3886 is specific
> about and if some things that you apparently believe are totally
> optional are, in fact, requirements if one goes down a
> particular path, e.g., one cannot pick and choose rungs on the
> comparison ladder but more conceptually start from the bottom
> and work one's way up.  I believe 3986 clearly allows adding
> rungs at the top of the ladder, but not reinterpreting the ones
> that are there.  I gather you and Martin read it differently.

Yes indeed. Here is some text taken from RFC 3986:

Second paragraph of Section 6, Normalization and Comparison 
(http://tools.ietf.org/html/rfc3986#section-6):

    URI comparison is performed for some particular purpose.  Protocols
    or implementations that compare URIs for different purposes will
    often be subject to differing design trade-offs in regards to how
    much effort should be spent in reducing aliased identifiers.  This
    section describes various methods that may be used to compare URIs,
    the trade-offs between them, and the types of applications that might
    use them.

The key phrase is "*describes* various methods that *may* be used". So 
it's essentially "here's some things you may want to consider, and why".

Then we have at the start of Section 6.2, Comparison Ladder 
(http://tools.ietf.org/html/rfc3986#section-6.2):

    A variety of methods are used in practice to test URI equivalence.
    These methods fall into a range, distinguished by the amount of
    processing required and the degree to which the probability of false
    negatives is reduced.  As noted above, false negatives cannot be
    eliminated.  In practice, their probability can be reduced, but this
    reduction requires more processing and is not cost-effective for all
    applications.

    If this range of comparison practices is considered as a ladder, the
    following discussion will climb the ladder, starting with practices
    that are cheap but have a relatively higher chance of producing false
    negatives, and proceeding to those that have higher computational
    cost and lower risk of false negatives.

For me at least, the phrase "*If* this range of comparison practices is 
*considered* as a ladder" clearly indicates that the ladder here is an 
expositionary device, chosen to bring a bit of order into the range of 
choices, rather than some pre-/post-condition structure.

> I suggest that, if 3986 allows contradictory good-faith and
> careful readings, that is a problem with 3986 but not a problem
> for URNs.

Fully agreed. If you have any textual fixes, please submit them as errata.

> However, were URNs (or other types of URIs) to move away from
> 3986 for other reasons, they might be able to avoid taking those
> ambiguities,

If whatever you create is to be used in places where URIs are used, then 
you can only avoid part of these ambiguities.

As I already mentioned, URNs *are* used as XML namespaces, and XML 
namespaces *are* compared character-by-character, so even if the URN 
spec says that
urn:example:foo&a=x&b=y and urn:example:foo&b=y&a=x are always the same, 
using such an URN as an XML namespace would still have to make sure that 
everybody only use one of the two variants.

On the other hand, even in the case that you wanted to insist that
urn:example:foo&a=x&b=y and urn:example:foo&b=y&a=x are two 
fundamentally different URNs, there might still be search engines that 
decide that they treat them as the same because for other schemes, that 
will reduce costly re-fetching of one and the same resource at the cost 
of an occasionally missed resource, and the search engine, at any 
specific point in time, may consider the cost of dealing with UNRs too high.

> and some operations that are apparently not
> optional (another difference in reading) but obviously
> inapplicable to many cases, along.

I guess you are referring to removing /./ and /../ and the like. If 
something is mandatory but inapplicable, my guess is that it is an 
identity operation, which would be *very* easy to implement.

I have to admit that Section 5, Reference Resolution, which deals with 
/./ and /../, isn't the part of RFC 3986 that I'm most familiar with, 
but my strong guess would be that as long as URNs don't allow '/', we 
are indeed talking about an identity operation.

> The latter would simplify
> fully-conforming implementations although, if I correctly
> understand the implications of some of Martin's remarks, either
> far more of 3986 is discretionary than I believe to be the case

Yes indeed.

> or fully-conforming implementations are rare.

In a sense, that's also true. There are many parts of the spec, and what 
an implementation needs to do depends on what operation it is applying. 
That can be comparet to implementations of SMTP; some implementations 
will only implement the client side, others only the server side.

Regards,   Martin.


From nobody Sun Jul 27 01:47:13 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98F21A0115 for ; Sun, 27 Jul 2014 01:47:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.608
X-Spam-Level: *
X-Spam-Status: No, score=1.608 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=no
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 xZaWyUAWi0eS for ; Sun, 27 Jul 2014 01:47:10 -0700 (PDT)
Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id D30C51A0113 for ; Sun, 27 Jul 2014 01:47:09 -0700 (PDT)
Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id C3C5632E538; Sun, 27 Jul 2014 17:47:08 +0900 (JST)
Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 737e_1ea9_3e17ea7d_7864_41f5_97f3_fed2390409e8; Sun, 27 Jul 2014 17:47:08 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id E91C7BF547; Sun, 27 Jul 2014 17:47:07 +0900 (JST)
Message-ID: <53D4BC7B.3090803@it.aoyama.ac.jp>
Date: Sun, 27 Jul 2014 17:46:51 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= 
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: John C Klensin ,  "Leslie Daigle (TCE)" , Julian Reschke , urn@ietf.org
References: <53D185B7.8080102@thinkingcat.com> <53D18827.9010203@gmx.de> <53D269D2.2030902@thinkingcat.com> <53D26B5A.4000509@gmx.de> <53D26DEF.3030508@thinkingcat.com> <3760CA03DD0D4E9ACDC26297@JCK-EEE10>
In-Reply-To: <3760CA03DD0D4E9ACDC26297@JCK-EEE10>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/vl-B_A0h6CJY2nuzZIFJyno-Kqs
Subject: Re: [urn] Choice matrix
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 27 Jul 2014 08:47:13 -0000

Hello John, others,

On 2014/07/26 00:14, John C Klensin wrote:
>
> --On Friday, 25 July, 2014 10:47 -0400 "Leslie Daigle (TCE)"
>  wrote:
>
>> I think we agree -- my aim was not to criticize RFC3986, but
>> rather talk about the options for URN specification whether it
>> remained part of the URI (syntax, semantics) spec or not.
>> That's not (intended to be) a value judgement of the URI spec.
>
> Let me add a personal note to Leslie's comment.   The separation
> draft (which others convinced me to call "URNs are not URIs")
> was never intended as a value judgment of the URI spec.  It was
> just the result of conclusions by several people (and maybe even
> the WG), reached before I did, that the entanglements with 3987
> were creating complications and impediments with moving forward
> with URN work.   The biggest assumed entanglement was that 3986
> was basically a URL spec that had been generalized for other
> types of URIs but not generalized enough to accommodate URNs
> which, advantageous syntax similarities aside, were a different
> sort of creature.

My impression so far is that this is mostly based on misunderstandings. 
Some of these misunderstandings may be relatively easy to make, others 
are very difficult to understand (such as generalizing from a single 
example).

> It is no secret that I've acquired an aesthetic dislike of the
> way 3986 is constructed as I've been working on this URN effort.
> But that is my problem and, unless pressed, I don't even want to
> spend time discussing it.

[Thanks for mentioning this. It was my impression, too, and I was 
debating with myself whether I should bring it up or not, but given that 
you have mentioned it now, I will do my best to not touch this point any 
further.]


> A different version of the questions posed by Andy and Leslie is
> that, if one says "different kind of creature" and "don't be
> completely dependent on 3986", whether one can preserve enough
> of the 3986 syntax to allow generic, really scheme-independent,
> URI parsers to keep working regardless of what more specific
> changes are made for URNs.  I'm pretty sure the answer to that
> question is "yes" and that the URN WG shouldn't do anything that
> turns it to "no" (whether in conformance to 3986 or not).
>
> So, if potential incompatibility with generic URI parsers (one
> that, among other things, do not make assumptions based on HTTP
> practices) is the concern, we really have no disagreement that I
> can see.
>
> On the other hand, if the issue is about the legitimacy of URNs

There is no question that RFC 3986 considers URNs legitimate. Otherwise, 
it wouldn't give an example, or would it?

> or whether they are (or get to be) a different kind of creature
> from traditional HTTP-URLs,

Of course they are different from http: URIs. Mailto URIs are also 
different from http: URIs. And the same for all the other many 
registered (and unregistered) schemes. But they are all URIs, and it 
makes a lot of sense to keep them as URIs.

> then we have a different sort of
> disagreement.  I don't know how to make progress on that one.

I don't think we have a disagreement, or where we might have a 
disagreement (e.g. with respect to where exactly to use http: URIs vs. 
URNs), it's not relevant for the technical work we are chartered to do.

Regards,   Martin.


From nobody Mon Jul 28 02:56:08 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D211A0397 for ; Mon, 28 Jul 2014 02:56:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level: 
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 wHL4V0dEg51E for ; Mon, 28 Jul 2014 02:56:00 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 229FB1A0385 for ; Mon, 28 Jul 2014 02:55:59 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by gateway1.nyi.internal (Postfix) with ESMTP id 136F620B85 for ; Mon, 28 Jul 2014 05:55:57 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Mon, 28 Jul 2014 05:55:58 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type; s=smtpout; bh=sOh4 cr6zfBRiWsw4PHE/f1FRZ9w=; b=YlYJ6JX62QRjEgVVSbmMsNblFvxJW5BaDrYM f5oCq1UECUXd2LuRksCbjjXwJRSfbkc7zotL/uRxOn5bAWZK8Cjifpuk6/553Bv9 l8Idrb8TiI4MTc2Ud1+V1c4kJC8XqgkfO6eYbs2oKgQJRfMQBGyYTZ29cIsUN0Ab 87qh0+o=
X-Sasl-enc: cccuKE9kNJYrQHiCieAH5zt084W9fbTVhj3Ua3h4hCo6 1406541351
Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 0FEB7C007AC; Mon, 28 Jul 2014 05:55:49 -0400 (EDT)
Message-ID: <53D61E20.3030103@network-heretics.com>
Date: Mon, 28 Jul 2014 05:55:44 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "Leslie Daigle (TCE)" ,  "urn@ietf.org" 
References: <53D185B7.8080102@thinkingcat.com>
In-Reply-To: <53D185B7.8080102@thinkingcat.com>
Content-Type: multipart/alternative; boundary="------------090206020604010202000704"
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/QYg6uZ7OrjPpU7Vy2Z9Bt5Qmw5g
Subject: Re: [urn] Choice matrix
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Jul 2014 09:56:04 -0000

This is a multi-part message in MIME format.
--------------090206020604010202000704
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Summary of my preferences:

1. URN syntax IS divorced from the syntax of other URIs, or at least RFC 
3986 syntax.   Though we still call URNs a kind of URI, and we still try 
to make URNs look more-or-less like URLs modulo the extra ":" after the NID.

2. Define a new "extended URN" syntax using neither "?" nor "#" for 
"facets" of URNs,

3. "?" and "#" and what follows aren't part of the URN.  However, the 
behavior of "?" and "#" when appended to URNs is defined.

Goals:

1.  Do not overload "?" or "#" with new behaviors in the URN context.   
Retain the familiar, most-visible behavior of these.

2.  Relieve the pressure to overload "?" and "#" with new syntax for facets.

3.  Retain the ability to use "?" and "#" with resources referenced by 
URNs that resolve to URLs, in a way compatible with that used when the 
URLs are accessed directly.    (Once the client resolves a URN to a URL, 
it handles "?" and "#" in the context of that URL exactly as it does for 
any other URL.)

4.  Avoid, or at least minimize, the need for special-cases in client 
software and protocol handlers that deal with URNs.   (This is the 
reason for goal #3)

A requirement for special-case handling of URNs as a class, as opposed 
to other URIs, is tolerable when necessary.   Requirements for 
special-case handling of specific URN namespaces should be steadfastly 
avoided because this makes it difficult for client software to handle 
all URNs in a generic fashion - it makes it much more likely that client 
software would only handle a small subset of URNs, and thus harms 
interoperability.   (However, namespaces that believe that they control 
all resolution of their particular URNs might still get what they want, 
if they adhere to some implementation constraints...see below.)

(Of the above, I regard #4 as the most important.   But #3 is important 
to implement #4 unless you just want to say that "#" and "?" can't be 
used with URNs at all.)

Details:

  * Redefine URN syntax in an RFC that updates RFC 3986.

    Reasons:
      o RFC 3986 seems to be a large part of the confusion regarding
        applicability of # and ? to URNs,
      o we need to extend URN syntax to accommodate additional
        requirements, and
      o revising RFC 3896 is the task of Sisyphus.

  * reserve "/" (I think that's the best choice) to introduce new URN
    "facets" using a syntax of the form

    extended-URN = URN *( "/" type = value )

    where type and value are tokens that don't contain any characters
    that would confuse a URI parser.

      o Define an IANA registry for types and interpretation of
        associated values.   The registry defines for each type whether
        value is base64-encoded, and whether that type can appear more
        than once with different values.

      o Define a canonical ordering for /type=value suffixes so that
        comparison of extended URNs with facets in canonical order
        sort-of works with things that use existing URN comparison
        rules.   Mandate use of this form of extended URNs in most
        circumstances where URNs are used as references.

      o Decide whether extended URNs must themselves qualify as URNs -
        i.e. whether the binding between an extended URN and the
        resource (version, section, whatever) named by the extended URN
        must itself remain persistent.   Perhaps reserve a portion of
        "type" namespace (say, all types beginning with "-") for facets
        that break binding persistence.

      o Then invite other standards-making bodies with appropriate
        expertise to define and register extended URN facets that meet
        their requirements.   They can, of course, define fragment-like
        facets or query-like facets (presumably defined better than the
        traditional web facilities) using this syntax.   IMO, IETF's
        role in reviewing such facets should mostly be to make sure that
        the syntax doesn't break things, client software can parse,
        compare, and generally deal with all URNs in a uniform manner
        (special cases are bad), and that the facet is defined in such a
        way that it doesn't break persistence (unless its type name
        indicates that it does).

  * "?" and "#" are reserved specifically for use in the context of
    referenced resources in a manner consistent with their use in
    external links on the web:

      o "?" is reserved for queries submitted to the named resource (NOT
        a resolution server) using the URL and protocol used to actually
        access the resource

        So if urn:foo:bar resolves to
        http://some.domain.example.com/random/path
        then urn:foo:bar?THING is interpreted as
        http://some.domain.example.com/random/path?THING

        Strictly speaking, the "?" and what follows are NOT considered
        part of the URN (because persistence is not assured), but they
        MAY appear with a URN.

        If the WG prefers, instead of describing "?" in vague terms of
        protocol, define this as a purely syntatic convention for
        mapping from URNs to URLs.   So if a URN maps to a URL that uses
        "?" for something other than a query, it will still work with
        this convention.   That has the nice attribute that client
        software doesn't have to care what "?" actually means in the
        context of URNs - it only evaluates "?" and what follows in the
        context of any URL that a URN resolves to.

          + /Note that with this behavior, nothing stops someone from
            using "?" with a URN to mean anything they want it to mean,
            as long as the resolution for that URN works in such a way
            that IF the resource is network-accessible, then whatever
            resource(s) the URN maps to are described with URLs, for
            which the "?" and what follows do what whoever used "?" with
            that URN wants it to do. //So in the case where a URN
            maintainer (or NID maintainer) believes it controls all
            resolution of resources of a URN or group of URNs, the
            maintainer can effectively make "?" mean whatever it wants
            it to mean, e.g. by arranging for all such URNs to be
            resolved to HTTP servers that interpret "?" the way the URN
            maintainer wants.   I'm not sure that's entirely a Good
            Thing, as URNs should retain their meaning independently of
            any resolution service.   But this might be politically
            convenient for parties that really want to use "?" in some
            way, and I've already said that "?" and what follows aren't
            actually part of the URN./

        Applicability of "?" to resources that will never be
        network-accessible is undefined, but even for those resources
        "?" MUST NOT be defined in such a way as to change the meaning
        of the URN or behavior of a resolution service.

      o "#" is reserved to identify fragments within a referenced
        resource, according to however fragments are identified by the
        content-type of the referenced resource.

        So if urn:foo:bar resolves to
        http://some.domain.example.com/random/file.html
        then urn:foo:bar#zot resolves to
        http://some.domain.example.com/random/file.html#zot

        Strictly speaking, the "#" and what follows are NOT considered
        part of the URN (because persistence is not assured), but they
        MAY appear with a URN.

        (if you want, make this a purely syntatic convention)

          + Note that with this behavior, nothing stops a URN maintainer
            from defining "#" to work however it wants "#" to work, as
            long as such URNs always resolve to zero or more
            content-types that interpret the "fragment" portion of the
            resolved URL in the way the URN maintainer wants them to be
            interpreted.  What the URN maintainer cannot do is redefine
            the meaning of fragments for existing content-types.



--------------090206020604010202000704
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Summary of my preferences:

      

      1. URN syntax IS divorced from the syntax of other URIs, or at
      least RFC 3986 syntax.   Though we still call URNs a kind of URI,
      and we still try to make URNs look more-or-less like URLs modulo
      the extra ":" after the NID.

      

      2. Define a new "extended URN" syntax using neither "?" nor "#"
      for "facets" of URNs,

      

      3. "?" and "#" and what follows aren't part of the URN.  However,
      the behavior of "?" and "#" when appended to URNs is defined.

      

      Goals:

      

      1.  Do not overload "?" or "#" with new behaviors in the URN
      context.   Retain the familiar, most-visible behavior of these.

      

      2.  Relieve the pressure to overload "?" and "#" with new syntax
      for facets.

      

      3.  Retain the ability to use "?" and "#" with resources
      referenced by URNs that resolve to URLs, in a way compatible with
      that used when the URLs are accessed directly.    (Once the client
      resolves a URN to a URL, it handles "?" and "#" in the context of
      that URL exactly as it does for any other URL.)

      

      4.  Avoid, or at least minimize, the need for special-cases in
      client software and protocol handlers that deal with URNs.   (This
      is the reason for goal #3)

      

      A requirement for special-case handling of URNs as a class, as
      opposed to other URIs, is tolerable when necessary.   Requirements
      for special-case handling of specific URN namespaces should be
      steadfastly avoided because this makes it difficult for client
      software to handle all URNs in a generic fashion - it makes it
      much more likely that client software would only handle a small
      subset of URNs, and thus harms interoperability.   (However,
      namespaces that believe that they control all resolution of their
      particular URNs might still get what they want, if they adhere to
      some implementation constraints...see below.)

      

      (Of the above, I regard #4 as the most important.   But #3 is
      important to implement #4 unless you just want to say that "#" and
      "?" can't be used with URNs at all.)

      

      Details:

      
    
        
  • Redefine URN syntax in an RFC that updates RFC 3986.
    
          
    
          Reasons: 
    
          
      
            
    • RFC 3986 seems to be a large part of the confusion
              regarding applicability of # and ? to URNs,  
      • 
          
    
          
      
            
    • we need to extend URN syntax to accommodate additional
              requirements, and 
      • 
          
    
          
      
            
    • revising RFC 3896 is the task of Sisyphus.
      • 
          
    
          
    
        
    • 
        
  • reserve "/" (I think that's the best choice) to introduce
          new URN "facets" using a syntax of the form
    
          
    
          extended-URN = URN *( "/" type = value )
    
          
    
          where type and value are tokens that don't contain any
          characters that would confuse a URI parser.
    
          
    
          
      
            
    • 
              Define an IANA registry for types and interpretation of
              associated values.   The registry defines for each type
              whether value is base64-encoded, and whether that type can
              appear more than once with different values.
      • 
          
    
          
    
          
      
            
    • Define a canonical ordering for /type=value suffixes so
              that comparison of extended URNs with facets in canonical
              order sort-of works with things that use existing URN
              comparison rules.   Mandate use of this form of extended
              URNs in most circumstances where URNs are used as
              references.
      • 
          
    
          
    
          
      
            
    • Decide whether extended URNs must themselves qualify as
              URNs - i.e. whether the binding between an extended URN
              and the resource (version, section, whatever) named by the
              extended URN must itself remain persistent.   Perhaps
              reserve a portion of "type" namespace (say, all types
              beginning with "-") for facets that break binding
              persistence.
      • 
          
    
          
    
          
      
            
    • Then invite other standards-making bodies with
              appropriate expertise to define and register extended URN
              facets that meet their requirements.   They can, of
              course, define fragment-like facets or query-like facets
              (presumably defined better than the traditional web
              facilities) using this syntax.   IMO, IETF's role in
              reviewing such facets should mostly be to make sure that
              the syntax doesn't break things, client software can
              parse, compare, and generally deal with all URNs in a
              uniform manner (special cases are bad), and that the facet
              is defined in such a way that it doesn't break persistence
              (unless its type name indicates that it does).
      • 
          
    
        
    • 
      

      
    
        
  • "?" and "#" are reserved specifically for use in the context
          of referenced resources in a manner consistent with their use
          in external links on the web:
    
          
    
        
    • 
        
      
          
    • "?" is reserved for queries submitted to the named
            resource (NOT a resolution server) using the URL and
            protocol used to actually access the resource
      
            
      
            So if urn:foo:bar resolves to
            http://some.domain.example.com/random/path 
      
            then urn:foo:bar?THING is interpreted as
            http://some.domain.example.com/random/path?THING
      
            
      
            Strictly speaking, the "?" and what follows are NOT
            considered part of the URN (because persistence is not
            assured), but they MAY appear with a URN.
      
            
      
            If the WG prefers, instead of describing "?" in vague terms
            of protocol, define this as a purely syntatic convention for
            mapping from URNs to URLs.   So if a URN maps to a URL that
            uses "?" for something other than a query, it will still
            work with this convention.   That has the nice attribute
            that client software doesn't have to care what "?" actually
            means in the context of URNs - it only evaluates "?" and
            what follows in the context of any URL that a URN resolves
            to.
      
            
      
            
        
              
      • Note that with this behavior, nothing stops someone
                  from using "?" with a URN to mean anything they want
                  it to mean, as long as the resolution for that URN
                  works in such a way that IF the resource is
                  network-accessible, then whatever resource(s) the URN
                  maps to are described with URLs, for which the "?" and
                  what follows do what whoever used "?" with that URN
                  wants it to do.   So in the case where a URN
                  maintainer (or NID maintainer) believes it controls
                  all resolution of resources of a URN or group of URNs,
                  the maintainer can effectively make "?" mean whatever
                  it wants it to mean, e.g. by arranging for all such
                  URNs to be resolved to HTTP servers that interpret "?"
                  the way the URN maintainer wants.   I'm not sure
                  that's entirely a Good Thing, as URNs should retain
                  their meaning independently of any resolution
                  service.   But this might be politically convenient
                  for parties that really want to use "?" in some way,
                  and I've already said that "?" and what follows aren't
                  actually part of the URN.
        • 
            
      
            
      
            Applicability of "?" to resources that will never be
            network-accessible is undefined, but even for those
            resources "?" MUST NOT be defined in such a way as to change
            the meaning of the URN or behavior of a resolution service.
      
            
      
          
      • 
          
    • "#" is reserved to identify fragments within a referenced
            resource, according to however fragments are identified by
            the content-type of the referenced resource.
      
            
      
            So if urn:foo:bar resolves to
            http://some.domain.example.com/random/file.html 
      
            then urn:foo:bar#zot resolves to
            http://some.domain.example.com/random/file.html#zot
      
            
      
            Strictly speaking, the "#" and what follows are NOT
            considered part of the URN (because persistence is not
            assured), but they MAY appear with a URN.
      
            
      
            (if you want, make this a purely syntatic convention)
      
            
      
            
        
              
      • Note that with this behavior, nothing stops a URN
                maintainer from defining "#" to work however it wants
                "#" to work, as long as such URNs always resolve to zero
                or more content-types that interpret the "fragment"
                portion of the resolved URL in the way the URN
                maintainer wants them to be interpreted.  What the URN
                maintainer cannot do is redefine the meaning of
                fragments for existing content-types.
        • 
            
      
          
      • 
        
    
      

      


      

    

  


--------------090206020604010202000704--


From nobody Mon Jul 28 03:13:40 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BFE1A038B for ; Mon, 28 Jul 2014 03:13:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 Fx51nED9t8TM for ; Mon, 28 Jul 2014 03:13:35 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FFD01A036C for ; Mon, 28 Jul 2014 03:13:34 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by gateway1.nyi.internal (Postfix) with ESMTP id D6CCF2176E for ; Mon, 28 Jul 2014 06:13:30 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 28 Jul 2014 06:13:30 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=f5ezAQtCjMqB7WGZD7D5/1 vK21U=; b=gfgpRp5IG9rGsanD++M5/8EALuMuyhhCngSvWAXdGvJWxvy/UilgxU nhTsqAap5lyCjVZYtA66lZwuqs6N6Ym/Gx8610bA9UfDlXvhK/gGgAODL/K4tdu+ N4tBT3H1ulDMyPyMcJnD0qXJOClxEaoYMofnjmNy1kUNTep2izLtQ=
X-Sasl-enc: ZpWmTo1jUXyjktJe345MpGPqI+Hz73K/w6x7DLxq2ymH 1406542409
Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 96D11C00005; Mon, 28 Jul 2014 06:13:21 -0400 (EDT)
Message-ID: <53D62231.9020602@network-heretics.com>
Date: Mon, 28 Jul 2014 06:13:05 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: =?windows-1252?Q?=22Martin_J=2E_D=FCrst=22?= ,  Julian Reschke , "Leslie Daigle (TCE)" ,  "Svensson, Lars" , "urn@ietf.org" 
References: <53D185B7.8080102@thinkingcat.com> <53D18827.9010203@gmx.de> <53D269D2.2030902@thinkingcat.com> <24637769D123E644A105A0AF0E1F92EFA446B13A@dnbf-ex1.AD.DDB.DE> <53D27424.2010802@thinkingcat.com> <53D277EA.30601@gmx.de> <53D4ABAF.5040303@it.aoyama.ac.jp>
In-Reply-To: <53D4ABAF.5040303@it.aoyama.ac.jp>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/MujFopPs2SNCJCMGXUY-CFf5fkE
Subject: Re: [urn] Choice matrix
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Jul 2014 10:13:38 -0000

On 07/27/2014 03:35 AM, "Martin J. Dürst" wrote:
> I actually think it's utterly consistent with RFC 3986. RFC 3986 only 
> says that it's "scheme definable". This means that a scheme can define 
> what it wants.
>
Yes, 3986 allows a scheme to define what it wants.   The reason that "?" 
should not have a namespace-specific meaning is not because 3986 
prohibits it.

Some reasons that "?" should not have a namespace-specific meaning are:

- This would require every client that tries to generically handle URNs 
to special-case handling of specific namespaces and the interpretation 
of "?" within each namespace

- This would, for namespaces that defined "?" differently, preclude 
passing query strings to URNs that resolved to URLs that could accept 
queries.

- It would lead to really odd behavior.    if A and B were both names 
for resource X, but A and B were in different namespaces, A?Y and B?Y 
might produce different results.   I don't think this is actually 
prohibited by any of the URN-related specifications, but it violates 
common sense, and makes it potentially problematic to assign new names 
to previously named resources even when there are good reasons to do so.

Keith


From nobody Wed Jul 30 07:53:59 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C491A00A7 for ; Wed, 30 Jul 2014 07:53:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
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 B_KpZ3D-_nYO for ; Wed, 30 Jul 2014 07:53:55 -0700 (PDT)
Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF8A11A015F for ; Wed, 30 Jul 2014 07:53:54 -0700 (PDT)
Received: from angora-2.local ([::ffff:142.167.241.226]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 30 Jul 2014 10:53:45 -0400 id 00050077.53D906FC.000043AD
Message-ID: <53D906F5.5090008@thinkingcat.com>
Date: Wed, 30 Jul 2014 10:53:41 -0400
From: "Leslie Daigle (TCE)" 
Organization: ThinkingCat Enterprises
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Julian Reschke , "Svensson, Lars" , "urn@ietf.org" 
References: <53D185B7.8080102@thinkingcat.com> <53D18827.9010203@gmx.de> <53D269D2.2030902@thinkingcat.com> <24637769D123E644A105A0AF0E1F92EFA446B13A@dnbf-ex1.AD.DDB.DE> <53D27424.2010802@thinkingcat.com> <53D277EA.30601@gmx.de>
In-Reply-To: <53D277EA.30601@gmx.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/QJ6XPLlb5dNZn8-92syddW526c8
Subject: Re: [urn] Choice matrix
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 14:53:57 -0000

Coming back to this before following up a later message -- I believe 
we're largely saying the same thing, but my opinion (annotated as such!) 
is that per-NID specification is not only tricky, it's likely to lead to 
heartbreak.

Leslie.

On 7/25/14 11:29 AM, Julian Reschke wrote:
> On 2014-07-25 17:13, Leslie Daigle (TCE) wrote:
>>
>> To be very clear:  "URN" is the "scheme" in the context of the URI
>> syntax.  That is, something that is "scheme definable" in the URI spec
>> must be defined for all URNs.
>>
>> To implement something on a per-NID basis is hard to police (opinion),
>> and I believe is not consistent with the URI spec.
>
>
> I agree that it's tricky to specify, but I don't see RFC 3986 forbidding
> it.
>
> Best regards, Julian
>
>


From nobody Wed Jul 30 08:13:00 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3381A01AF for ; Wed, 30 Jul 2014 08:12:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
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 QA4O0iy2TOsn for ; Wed, 30 Jul 2014 08:12:54 -0700 (PDT)
Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26BA81A0208 for ; Wed, 30 Jul 2014 08:11:26 -0700 (PDT)
Received: from angora-2.local ([::ffff:142.167.241.226]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 30 Jul 2014 11:11:24 -0400 id 00050079.53D90B1C.0000455C
Message-ID: <53D90B1B.8000009@thinkingcat.com>
Date: Wed, 30 Jul 2014 11:11:23 -0400
From: "Leslie Daigle (TCE)" 
Organization: ThinkingCat Enterprises
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "urn@ietf.org" 
References: <53D185B7.8080102@thinkingcat.com> <53D61E20.3030103@network-heretics.com>
In-Reply-To: <53D61E20.3030103@network-heretics.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/WoaMt9yP2hRzpmccZ2BMJY_A5VU
Subject: [urn] PReferences (no longer really Re:  Choice matrix)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 15:12:57 -0000

Getting beyond the meta, I'd like to see actual proposals for how to 
handle facets (whether using the "?" and "#" or not) in a way that works 
consistently across all persistent identifiers.

To further remove noise from that discussion, I think having the 
discussion in the abstract -- e.g., for a new [UR]identifier, as Joe 
Hildebrand suggested at the meeting last week -- might be helpful.

Thumbwrestling about interpretations of RFC3986 is distracting from the 
hard problem, IMO.

I don't have a proposal to kick off the discussion, as I am a 
self-admitted skeptic :-)

A few comments on Keith's proposals:

On 7/28/14 5:55 AM, Keith Moore wrote:
> Summary of my preferences:
>
> 1. URN syntax IS divorced from the syntax of other URIs, or at least RFC
> 3986 syntax.   Though we still call URNs a kind of URI, and we still try
> to make URNs look more-or-less like URLs modulo the extra ":" after the NID.
>
> 2. Define a new "extended URN" syntax using neither "?" nor "#" for
> "facets" of URNs,

IMO, 2 is possible iff it's an entirely new identifier scheme (because 
there are no other reserve characters for URNs).  That observation may 
be consistent with Keith's thinking.

>
> 3. "?" and "#" and what follows aren't part of the URN.  However, the
> behavior of "?" and "#" when appended to URNs is defined.

Isn't this how they were originally defined for URIs?

>
> Goals:
>
> 1.  Do not overload "?" or "#" with new behaviors in the URN context.
> Retain the familiar, most-visible behavior of these.

Yes.  If possible.
>
> 2.  Relieve the pressure to overload "?" and "#" with new syntax for facets.
>
> 3.  Retain the ability to use "?" and "#" with resources referenced by
> URNs that resolve to URLs, in a way compatible with that used when the
> URLs are accessed directly.    (Once the client resolves a URN to a URL,
> it handles "?" and "#" in the context of that URL exactly as it does for
> any other URL.)

Given that URNs don't consistently resolve to particular URLs, for a 
single URN, let alone across all URN namespaces, how would this work?

Leslie.

>
> 4.  Avoid, or at least minimize, the need for special-cases in client
> software and protocol handlers that deal with URNs.   (This is the
> reason for goal #3)
>
> A requirement for special-case handling of URNs as a class, as opposed
> to other URIs, is tolerable when necessary.   Requirements for
> special-case handling of specific URN namespaces should be steadfastly
> avoided because this makes it difficult for client software to handle
> all URNs in a generic fashion - it makes it much more likely that client
> software would only handle a small subset of URNs, and thus harms
> interoperability.   (However, namespaces that believe that they control
> all resolution of their particular URNs might still get what they want,
> if they adhere to some implementation constraints...see below.)
>
> (Of the above, I regard #4 as the most important.   But #3 is important
> to implement #4 unless you just want to say that "#" and "?" can't be
> used with URNs at all.)
>
> Details:
>
>   * Redefine URN syntax in an RFC that updates RFC 3986.
>
>     Reasons:
>       o RFC 3986 seems to be a large part of the confusion regarding
>         applicability of # and ? to URNs,
>       o we need to extend URN syntax to accommodate additional
>         requirements, and
>       o revising RFC 3896 is the task of Sisyphus.
>
>   * reserve "/" (I think that's the best choice) to introduce new URN
>     "facets" using a syntax of the form
>
>     extended-URN = URN *( "/" type = value )
>
>     where type and value are tokens that don't contain any characters
>     that would confuse a URI parser.
>
>       o Define an IANA registry for types and interpretation of
>         associated values.   The registry defines for each type whether
>         value is base64-encoded, and whether that type can appear more
>         than once with different values.
>
>       o Define a canonical ordering for /type=value suffixes so that
>         comparison of extended URNs with facets in canonical order
>         sort-of works with things that use existing URN comparison
>         rules.   Mandate use of this form of extended URNs in most
>         circumstances where URNs are used as references.
>
>       o Decide whether extended URNs must themselves qualify as URNs -
>         i.e. whether the binding between an extended URN and the
>         resource (version, section, whatever) named by the extended URN
>         must itself remain persistent.   Perhaps reserve a portion of
>         "type" namespace (say, all types beginning with "-") for facets
>         that break binding persistence.
>
>       o Then invite other standards-making bodies with appropriate
>         expertise to define and register extended URN facets that meet
>         their requirements.   They can, of course, define fragment-like
>         facets or query-like facets (presumably defined better than the
>         traditional web facilities) using this syntax.   IMO, IETF's
>         role in reviewing such facets should mostly be to make sure that
>         the syntax doesn't break things, client software can parse,
>         compare, and generally deal with all URNs in a uniform manner
>         (special cases are bad), and that the facet is defined in such a
>         way that it doesn't break persistence (unless its type name
>         indicates that it does).
>
>   * "?" and "#" are reserved specifically for use in the context of
>     referenced resources in a manner consistent with their use in
>     external links on the web:
>
>       o "?" is reserved for queries submitted to the named resource (NOT
>         a resolution server) using the URL and protocol used to actually
>         access the resource
>
>         So if urn:foo:bar resolves to
>         http://some.domain.example.com/random/path
>         then urn:foo:bar?THING is interpreted as
>         http://some.domain.example.com/random/path?THING
>
>         Strictly speaking, the "?" and what follows are NOT considered
>         part of the URN (because persistence is not assured), but they
>         MAY appear with a URN.
>
>         If the WG prefers, instead of describing "?" in vague terms of
>         protocol, define this as a purely syntatic convention for
>         mapping from URNs to URLs.   So if a URN maps to a URL that uses
>         "?" for something other than a query, it will still work with
>         this convention.   That has the nice attribute that client
>         software doesn't have to care what "?" actually means in the
>         context of URNs - it only evaluates "?" and what follows in the
>         context of any URL that a URN resolves to.
>
>           + /Note that with this behavior, nothing stops someone from
>             using "?" with a URN to mean anything they want it to mean,
>             as long as the resolution for that URN works in such a way
>             that IF the resource is network-accessible, then whatever
>             resource(s) the URN maps to are described with URLs, for
>             which the "?" and what follows do what whoever used "?" with
>             that URN wants it to do. //So in the case where a URN
>             maintainer (or NID maintainer) believes it controls all
>             resolution of resources of a URN or group of URNs, the
>             maintainer can effectively make "?" mean whatever it wants
>             it to mean, e.g. by arranging for all such URNs to be
>             resolved to HTTP servers that interpret "?" the way the URN
>             maintainer wants.   I'm not sure that's entirely a Good
>             Thing, as URNs should retain their meaning independently of
>             any resolution service.   But this might be politically
>             convenient for parties that really want to use "?" in some
>             way, and I've already said that "?" and what follows aren't
>             actually part of the URN./
>
>         Applicability of "?" to resources that will never be
>         network-accessible is undefined, but even for those resources
>         "?" MUST NOT be defined in such a way as to change the meaning
>         of the URN or behavior of a resolution service.
>
>       o "#" is reserved to identify fragments within a referenced
>         resource, according to however fragments are identified by the
>         content-type of the referenced resource.
>
>         So if urn:foo:bar resolves to
>         http://some.domain.example.com/random/file.html
>         then urn:foo:bar#zot resolves to
>         http://some.domain.example.com/random/file.html#zot
>
>         Strictly speaking, the "#" and what follows are NOT considered
>         part of the URN (because persistence is not assured), but they
>         MAY appear with a URN.
>
>         (if you want, make this a purely syntatic convention)
>
>           + Note that with this behavior, nothing stops a URN maintainer
>             from defining "#" to work however it wants "#" to work, as
>             long as such URNs always resolve to zero or more
>             content-types that interpret the "fragment" portion of the
>             resolved URL in the way the URN maintainer wants them to be
>             interpreted.  What the URN maintainer cannot do is redefine
>             the meaning of fragments for existing content-types.
>
>


From nobody Thu Jul 31 01:58:40 2014
Return-Path: 
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DD91A0496 for ; Thu, 31 Jul 2014 01:58:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 wjNzoYcS8fBX for ; Thu, 31 Jul 2014 01:58:36 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04CAB1A0495 for ; Thu, 31 Jul 2014 01:58:35 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by gateway1.nyi.internal (Postfix) with ESMTP id 89F0921A7D for ; Thu, 31 Jul 2014 04:58:34 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Thu, 31 Jul 2014 04:58:34 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=aTJM9eKY0eMMJ20iQVSL94 TX0I8=; b=UeauCYmQN2k+C+QnrK9NGrsg2fCJP2Z3HD9kduMCLJW3ZhwV0+fI+Z SsNanfIs08TH3cEbPhXRhmQ/bT0kqqB8MEW1vniX2HHAyJgabCNbdAjjbaMcDu5z xbvzlsJER31DRRO388rUfHEZQTtTrrZdYb8pwee+AcZD6sH1Gv1ew=
X-Sasl-enc: 99lvygIqzYXY72C7b+OQMR68jg+m/kX+ki6OZB9q9mok 1406797113
Received: from [192.168.1.4] (unknown [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 7E37F680163; Thu, 31 Jul 2014 04:58:33 -0400 (EDT)
Message-ID: <53DA052D.60807@network-heretics.com>
Date: Thu, 31 Jul 2014 04:58:21 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "Leslie Daigle (TCE)" ,  "urn@ietf.org" 
References: <53D185B7.8080102@thinkingcat.com> <53D61E20.3030103@network-heretics.com> <53D90B1B.8000009@thinkingcat.com>
In-Reply-To: <53D90B1B.8000009@thinkingcat.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/SblJmDoNAgEwpq9ycEVmFeqJV_g
Subject: Re: [urn] PReferences (no longer really Re:  Choice matrix)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Revisions to URN RFCs 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 08:58:38 -0000

On 07/30/2014 11:11 AM, Leslie Daigle (TCE) wrote:
>
> Getting beyond the meta, I'd like to see actual proposals for how to 
> handle facets (whether using the "?" and "#" or not) in a way that 
> works consistently across all persistent identifiers.
>
> To further remove noise from that discussion, I think having the 
> discussion in the abstract -- e.g., for a new [UR]identifier, as Joe 
> Hildebrand suggested at the meeting last week -- might be helpful.
>
> Thumbwrestling about interpretations of RFC3986 is distracting from 
> the hard problem, IMO.
>
> I don't have a proposal to kick off the discussion, as I am a 
> self-admitted skeptic :-)
>
> A few comments on Keith's proposals:
>
> On 7/28/14 5:55 AM, Keith Moore wrote:
>> Summary of my preferences:
>>
>> 1. URN syntax IS divorced from the syntax of other URIs, or at least RFC
>> 3986 syntax.   Though we still call URNs a kind of URI, and we still try
>> to make URNs look more-or-less like URLs modulo the extra ":" after 
>> the NID.
>>
>> 2. Define a new "extended URN" syntax using neither "?" nor "#" for
>> "facets" of URNs,
>
> IMO, 2 is possible iff it's an entirely new identifier scheme (because 
> there are no other reserve characters for URNs).  That observation may 
> be consistent with Keith's thinking.

To be clear, I'm not proposing that we define a new URI scheme to serve 
the same purpose as URNs.  (I don't mind if others define a new URI 
scheme for purposes similar to that of URNs or for any other purpose, 
that's just not what I'm proposing.   Though I don't really think that 
creating a new scheme to do what URNs were intended to do will actually 
help much, if any.)

RFC 2141 defines "/" as a reserved character for URNs (just like "?" and 
"#"), so I'm proposing that we define what it means in the context of 
"extended URNs", and that we use it to define "facets". (Whether the "/" 
and what follows is "part of" the URN is something to be determined, but 
this is probably not as important as defining what it means.)

RFC 3986 (erroneously, IMO) tried to shoehorn URNs into a generic URI 
syntax.  Software that tries to treat an "extended URN" as a URI 
according to the RFC 3986 grammar, might get confused by trying to treat 
facets as a "path", for example when processing "relative URIs" and 
perhaps in other cases.    That's not ideal, but I think it's better 
than defining a new URI scheme to do what URNs were intended to do, 
better than not permitting URNs to have facets, and better than defining 
"?" and/or "#" to mean something different for URNs than they mean for 
other URIs.   I strongly suspect that most software that can currently 
accept both URNs and other kinds of URIs, treats the URNs as opaque 
strings.   That software will presumably keep working with faceted 
extended URNs - or perhaps it will be necessary to avoid using extended 
URNs in such contexts until that software is updated.

(It is of course possible that I've missed some more compelling reason 
why "/" cannot be used to introduce facets in extended URNs, in which 
case please accept my apology and point out what I've missed.)

>> 3. "?" and "#" and what follows aren't part of the URN.  However, the
>> behavior of "?" and "#" when appended to URNs is defined.
>
> Isn't this how they were originally defined for URIs?

I don't remember.    Does it matter?

>>
>> Goals:
>>
>> 1.  Do not overload "?" or "#" with new behaviors in the URN context.
>> Retain the familiar, most-visible behavior of these.
>
> Yes.  If possible.
>>
>> 2.  Relieve the pressure to overload "?" and "#" with new syntax for 
>> facets.
>>
>> 3.  Retain the ability to use "?" and "#" with resources referenced by
>> URNs that resolve to URLs, in a way compatible with that used when the
>> URLs are accessed directly.    (Once the client resolves a URN to a URL,
>> it handles "?" and "#" in the context of that URL exactly as it does for
>> any other URL.)
>
> Given that URNs don't consistently resolve to particular URLs, for a 
> single URN, let alone across all URN namespaces, how would this work?

Good question.    I can think of cases where a fragment or query would 
be meaningful across all URLs to which a URN resolved (e.g. the URLs are 
replicas of the same resource, or the URLs name each of several versions 
of a resource all of which have the same fragment space and/or interpret 
queries in the same way), and I can think of cases where a fragment or 
query would not be meaningful across all of those URLs.   And this is a 
property of the resource named by the URN, since a URL can be associated 
with multiple URNs (some of which might have the property and some might 
not).   My suggestion would be:

In the absence of a positive indication from the resolution service that 
fragments and/or queries are meaningful (either for all URLs associated 
with that URN, or on a per-URL basis), treat use of a fragment or query 
with that URN as undefined and/or an error.

Keith