From nobody Thu Nov 17 05:12:51 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3766112969E for ; Thu, 17 Nov 2016 05:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.418 X-Spam-Level: X-Spam-Status: No, score=-3.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 fRW5apDEgcYK for ; Thu, 17 Nov 2016 05:12:48 -0800 (PST) Received: from loire.is.ed.ac.uk (loire.is.ed.ac.uk [129.215.16.10]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE53129698 for ; Thu, 17 Nov 2016 05:12:47 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by loire.is.ed.ac.uk (8.14.7/8.14.6) with ESMTP id uAHDCjBu012474; Thu, 17 Nov 2016 13:12:46 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id uAHDCjE0004247; Thu, 17 Nov 2016 13:12:46 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id uAHDCjA4011608; Thu, 17 Nov 2016 13:12:45 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id uAHDChH0011595; Thu, 17 Nov 2016 13:12:43 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Peter Saint-Andre References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 17 Nov 2016 13:12:43 +0000 In-Reply-To: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> (Peter Saint-Andre's message of "Mon\, 5 Sep 2016 20\:31\:03 -0600") Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at loire.is.ed.ac.uk with MIMEDefang 2.78, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.78 on 129.215.16.10 Archived-At: Cc: urn@ietf.org Subject: Re: [urn] version -18 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 13:12:51 -0000 First, my apologies for taking so long to get back to this. I've been asked to comment on the revision of terminology around names/namespaces etc. which is to be found in the current draft (18 [1]), in part in response to comments I had made on previous drafts. Overall I think things are much better, thank you. I have a few remaining nits to pick, which will follow in individual messages for ease of reference etc. ht [1] https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-18 -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Thu Nov 17 05:22:16 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F403129459 for ; Thu, 17 Nov 2016 05:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.418 X-Spam-Level: X-Spam-Status: No, score=-3.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 b_DN44QpgA9F for ; Thu, 17 Nov 2016 05:22:12 -0800 (PST) Received: from loire.is.ed.ac.uk (loire.is.ed.ac.uk [129.215.16.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3254D128B38 for ; Thu, 17 Nov 2016 05:22:12 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by loire.is.ed.ac.uk (8.14.7/8.14.6) with ESMTP id uAHDMBJx018542; Thu, 17 Nov 2016 13:22:11 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id uAHDMBDU008366; Thu, 17 Nov 2016 13:22:11 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id uAHDMB3u011987; Thu, 17 Nov 2016 13:22:11 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id uAHDMBEI011986; Thu, 17 Nov 2016 13:22:11 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Peter Saint-Andre References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 17 Nov 2016 13:22:11 +0000 In-Reply-To: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> (Peter Saint-Andre's message of "Mon\, 5 Sep 2016 20\:31\:03 -0600") Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at loire.is.ed.ac.uk with MIMEDefang 2.78, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.78 on 129.215.16.10 Archived-At: Cc: "urn@ietf.org" Subject: [urn] Terminology -- 'resource' and 'abstract designator' X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 13:22:14 -0000 There are two parts to this External: the current use of these terms is incompatible with the 3986 Internal: The definitions and uses of 'abstract designator' are inconsistent TL;DR: 1) 3986 distinguishes between 'resource' and 'representation', and so should we; 2) The term 'abstract designator' should be dropped. Part 1 -- 3986 incompatibility URNs are URIs, that is, Uniform Resource Identifiers. Every URI identifies something, as the name implies, and 3986 uses the term 'resource' as the cover term for _anything_ that is identified by a URI. It explicitly places _no_ constraint on what a URI can identify. In other words, anything can be a resource: real, imaginary, abstract, concrete, individual, set (finite or infinite), ... The current draft does not define the term 'resource'. It often uses it in ways which are consistent with 3986's definition, for example in phrases such as "resource identifier" (lower case in original), "identified resource", "The kinds of resources identified by URNs" and "persistent identification of resources". This longer exposition is also pretty much compatible with 3986: URNs (either individually or entire URN namespaces as defined below) that do not resolve to URLs at all or that resolve to metadata or non-Internet objects are among URN use cases explicitly permitted by this specification; each leaves the concept of "resolution" somewhat more abstract and difficult than the simple case of resolution to a URL. [1.1, 2nd para] But the current draft also uses 'resource' in many ways which are clearly incompatible with 3986. 3986 is very careful to distinguish between the resource _identified_ by a URI on the one hand, and _representations_ of that resource and _metadata_ about it on the other. The latter are much more concrete, and the kind of thing you can get your hands on/interact with (see section 1.2.2 of 3986 [1]). Some examples of where the current draft is incompatible with this position: "A URN [may] be ... an abstract designator that is persistent but that does not identify a resource" [Abstract, Introduction] Per 3986, _all_ URIs identify something, which it calls a resource. "media type of those resources" [2.3.3, next-to-last para] Per 3986, resources do not in general have media types, _representations_, e.g. as returned in messages, have media types. I don't think this will be hard to fix -- there's already a distinction between what is identified and the outcome of a resolution attempt, as well as between resolution and retrieval, and the wording around these just needs to be tightened up a bit, with the word 'resource' used a bit less. Whether the idea behind 3986's word 'representation' needs to be imported, along with the word, will I think be an editorial decision to be made in the course of the tightening-up effort. Part 2 -- 'abstract designator' Here are some examples of the use of this term which taken together leave me confused as to what is meant: A URN [may] be ... an abstract designator that is persistent but that does not identify a resource [Abstract, Introduction] If there are or will be resolution services available for a URN, this document calls the URN a "resource identifier" in roughly the sense that term is used in [RFC3986]. If there is no intention to provide any resolution services, and the distinction is important, this document calls the URN an "abstract designator". [1.2, near the end] If the URN does not resolve to a URL (i.e., is an abstract designator) or if it resolves directly to an object or a non-URL resource designator [2.3.2, 3rd para] [note that this is the only use of the phrase 'resource designator' in the draft] If the URN does not resolve to a URL (e.g., is an abstract designator) [2.3.3, 2nd para] because a URN might not specify the location of a resource or even point indirectly to one [4.1, 2nd para] (e.g., URNs within some URN namespaces are intended to act as abstract designators and thus are not intended to be resolved) [6.4.6 1st para] Clarified that there can be URNs that neither resolve to URLs nor are abstract designators. [F.8., 6th bullet. I _think_ this refers to the quote above from section 2.3.2] It is often argued that 3986 implies that there are two in-principle possibilities for any URI (including URNs) as far as resolution is concerned (where the possibility that resolution may involve more than one step is assumed): 1) Resolution services are or could be provided, but the results of resolution necessarily consist only of metadata about the identified resource, that is, no _representation_ of that resource is or could be available; 2) Resolution services are or could be provided, and the results of resolution may in practice and could in principle include one or more representations. However I think the above quotes from the current draft taken together provide evidence that it considers there to be a _threefold_ distinction, adding 3) No resolution services of any kind are provided or envisaged; However the quotes also demonstrate that no consistent interpretation for the term 'abstract designator', e.g. as (1) or (3) (or their union), is possible. Although at first it may seem that the most likely intended meaning for the term is (3), in fact I don't think this makes any sense. An identifier about which _no_ information is provided is useless, or rather, it makes no sense to make it available, as no-one when encountering it will be able to make anything of it. Registering a URN namespace must surely imply the intent of providing _some_ information about the resources identified by URNs which use it, even if that is only metadata to the effect that all interesting information about such resources is available offline in such-and-such a way. Or, more simply, the difference between (1) and (3) is surely a contingent one, bearing in mind the timescales over which we expect URNs to persist. It would be an odd namespace indeed for which the defining documents mandated that no-one could ever implement a resolution service providing useful metadata! What I think is the key distinction being implicitly appealed to is the _representability_ of resources in a namespace. The draft appears to use the acronym 'URL' to _mean_ a URI which is (at least in principle) resolvable to a representation. But I'd much prefer if the difference between (2) vs (1) union (3) were _not_ equated with "resolve(s) to a URL", because a) For 3986 and many users of URLs (understanding 'URL' to mean 'non-URN URI'), many URLs identify resources for which no representations are possible; b) There are perfectly good ways which are _not_ mediated by URLs at all to access representations for resources. So in summary I'm arguing that the only non-contingent property worth naming with 'abstract' or something like it is a property of _resources_, not of URNs. As such it's not really relevant to this specification. My most-preferred outcome: just remove the term 'abstract designator' altogether, and only discuss briefly the contingent nature of resolution, as sometimes yielding metadata, and sometimes (perhaps indirectly) access to representations. ht [1] https://tools.ietf.org/html/rfc3986#section-1.2.2 -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Thu Nov 17 07:31:35 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F446129976 for ; Thu, 17 Nov 2016 07:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.418 X-Spam-Level: X-Spam-Status: No, score=-3.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 4eWG37q-5fbD for ; Thu, 17 Nov 2016 07:31:31 -0800 (PST) Received: from loire.is.ed.ac.uk (loire.is.ed.ac.uk [129.215.16.10]) by ietfa.amsl.com (Postfix) with ESMTP id 2A42912944E for ; Thu, 17 Nov 2016 07:31:30 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by loire.is.ed.ac.uk (8.14.7/8.14.6) with ESMTP id uAHFVTUJ009051; Thu, 17 Nov 2016 15:31:29 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id uAHFVSTn014308; Thu, 17 Nov 2016 15:31:29 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7) with ESMTP id uAHFVSeZ019026; Thu, 17 Nov 2016 15:31:28 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.7/8.14.7/Submit) id uAHFVS0B019025; Thu, 17 Nov 2016 15:31:28 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Peter Saint-Andre References: <3bee74ce-c5ce-3f28-5cc9-437f34b778e9@stpeter.im> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 17 Nov 2016 15:31:27 +0000 In-Reply-To: (Henry S. Thompson's message of "Thu\, 17 Nov 2016 13\:12\:43 +0000") Message-ID: User-Agent: Gnus/5.1012 (Gnus v5.10.12) XEmacs/21.5-b34 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at loire.is.ed.ac.uk with MIMEDefang 2.78, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.78 on 129.215.16.10 Archived-At: Cc: urn@ietf.org Subject: [urn] Terminology issue: 'URL' X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 15:31:34 -0000 TL;DR: Replace 'resolve to a URL' with 'resolve to a Locator' throughout The current draft (correcly, IMO) defines 'URN' as "A name that is a member of a URN namespace", that is, a name of the form urn:nid:... It doesn't list 'URL' as a term, but does say, towards the end of section 1.2 *Terminology* this document uses the term Uniform Resource Locator (URL), rather than the generic term Uniform Resource Identifier (URI), to refer to locators; see also Section 1.1.3 of [RFC3986]. I think this either partakes of, or at least encourages, a confusion between properties of URI schemes and properties of individual URIs, thereby missing the key point of the referenced section of 3986: 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... [1] That is, although many http: URIs are locators, some are names (and some are both), and although all urn: URIs are names, some may be locators as well. A URI is a locator if it can be dereferenced, if, for example "[there are] services related to the identified resource, such as ... delivering a document object from a convenient source" [2]. That's not a property of the URI as such, but of its context of use and the services available therefrom. As that quote indicates, some URNs may have that property in some circumstances. On the other hand, just because a resolution service provides you with an http: URI when invoked on a URN does not mean you are now on your way to a document object, because that http: URI may itself be a name and not a locator. So, I'd suggest that you add a new term to the term list in section 1.2, as follows: Locator: A retrieval-enabled URI and use that term in most of the places where 'URL' is currently used. The penultimate paragraph of section 1.2 would then need to read something along these lines: This document uses the terms "resolution" and "resolver" in roughly the sense in which they were used in the original discussion of architectural principles for URNs [RFC2276], i.e., "resolution" is the act of supplying services related to the identified resource, such as translating the persistent URN into one or more current Locators for the resource, delivering metadata about the resource in an appropriate format, or even delivering a document object from a convenient source without requiring further intermediaries. At the time of this writing, resolution services are described in [RFC2483]. Section 1.1.3 of [RFC3986] helpfully observes that "A URI can be ... classified as a locator, a name, or both" and goes on to define locators as URIs which "provide a means of locating the resource [which they identify] by describing its primary access mechanism (e.g., its network 'location')". This is what we mean by 'retrieval-enabled' above, and we use the term 'Locator' to refer to the class of individual URIs which have this property. A few places where 'URL' is effectively used as shorthand for "non-urn-scheme-URI' will require some more explicit rewriting, e.g. The URN r-component has no syntactic counterpart in URLs --> The URN r-component has no syntactic counterpart in any other URI scheme that we are aware of The overall point here is that RFCs are meant for the entire community, and it's at best misleading for an RFC to redefine a widely used term to have a meaning other than the one already in wide (and documented) use. I do of course understand that there exists a sub-community within which this distinct meaning is understood and intended, but this spec can and should reach out more widely. So note that I'm _not_ proposing that the spec should use 'URL' as defined in 3986, but rather use 'URN' to mean urn:nid:..., as it does already, to use 'URI' as the generic, and _not to use 'URL' at all_. ht [1] https://tools.ietf.org/html/rfc3986#section-1.1.3 [2] https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-18#section-1.2 -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From nobody Thu Nov 24 01:03:34 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765A5129D39 for ; Thu, 24 Nov 2016 01:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=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 8Q9G8ULpCc6q for ; Thu, 24 Nov 2016 01:03:31 -0800 (PST) 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 080BF129B85 for ; Thu, 24 Nov 2016 01:02:04 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1c9put-000Ogg-2y for urn@ietf.org; Thu, 24 Nov 2016 04:02:03 -0500 Date: Thu, 24 Nov 2016 04:01:58 -0500 From: John C Klensin To: urn@ietf.org Message-ID: <9CC33BE498E6996637FB5091@JcK-HP8200> 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.10 X-SA-Exim-Mail-From: klensin@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [urn] FWD: Last Call: (Advertising Digital Identification (Ad-ID) URN Namespace Definition) to Informational RFC X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 09:03:33 -0000 URNBIS WG: FYI. This is worth looking at, and possibly commenting on, with regard to not only its content and definition quality but also to whether the new registration model would sufficiently identify and deal with any issues. In particular, (1) The new registration procedure would turn this over to Expert Review, largely eliminating the possibility that someone in the community who accidentally knows about and understands the subject matter would look at and review it. On the other hand, Expert Review can permit more intensive interaction and negotiating with the authors of a registration request and/or template than is normally part of the "throw it over the wall" character of IETF Last Call and approval. Is that the tradeoff we want? Would be worth the trouble to add an announcement to the IETF list and window for comments to the expert to the procedure (assuming the IESG would let us)? (2) This I-D apparently contains references, some of them implicit rather than listed, to documents that are behind paywalls or otherwise hard to obtain and whose stability status is unknown. Some of its content describes those external documents, which might be considered as either an informal tutorial or something that might, as the external standard evolves over time, become inconsistent with that external standard. Are those things satisfactory? If not, do we need to describe the external documentation we are willing to accept and/or push the authors/ would-be-registrants to be more explicit in some way? Please copy this list on any Last Call comments that would bear on 2141bis. thanks, john Brian E Carpenter ---------- Forwarded Message ---------- Date: Monday, November 21, 2016 10:55 -0800 From: The IESG To: IETF-Announce Cc: alexey.melnikov@isode.com, draft-adid-urn@ietf.org Subject: Last Call: (Advertising Digital Identification (Ad-ID) URN Namespace Definition) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Advertising Digital Identification (Ad-ID) URN Namespace Definition' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-12-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Advertising Digital Identification (Ad-ID) Identifiers are used identifying Advertising Assets across all media platforms (over the air, on-line, over the top, mobile, place based). This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID) for Ad-ID Identifiers. The file can be obtained via https://datatracker.ietf.org/doc/draft-adid-urn/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-adid-urn/ballot/ No IPR declarations have been submitted directly on this I-D. ---------- End Forwarded Message ---------- From nobody Sat Nov 26 22:00:49 2016 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8E7129406 for ; Sat, 26 Nov 2016 22:00:45 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6_JWSJuvrbii for ; Sat, 26 Nov 2016 22:00:42 -0800 (PST) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0095.outbound.protection.outlook.com [104.47.93.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 367E8128E19 for ; Sat, 26 Nov 2016 22:00:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AnQiyhZgaJFlCbl+w8v1vNl1/pSvs6nkQYYpqWQEHC4=; b=u/Jn8gigqv6Q1ZrwMqrLjh5+gU5zXwYEhoWUo3sCjSmFOlUi6sM56M206SJNZmQab1ffT4htw0Moge4CzMBO7VAmi0/J0E8kzI6b7ZRo/ZhY4vuAiMBTR3DnB4y5Qrz55BY92BKe5t/JpRixn9gJoNTNEiZ2yQ6AAlbT46OnRxk= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [192.168.1.2] (223.218.165.230) by OSXPR0101MB0983.jpnprd01.prod.outlook.com (10.167.149.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.13; Sun, 27 Nov 2016 06:00:38 +0000 To: John C Klensin , References: <9CC33BE498E6996637FB5091@JcK-HP8200> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Sun, 27 Nov 2016 15:00:36 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <9CC33BE498E6996637FB5091@JcK-HP8200> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [223.218.165.230] X-ClientProxiedBy: OS2PR01CA0050.jpnprd01.prod.outlook.com (10.164.161.160) To OSXPR0101MB0983.jpnprd01.prod.outlook.com (10.167.149.17) X-MS-Office365-Filtering-Correlation-Id: 58ca2fea-6067-42b4-ba57-08d4168ab61e X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:OSXPR0101MB0983; X-Microsoft-Exchange-Diagnostics: 1; OSXPR0101MB0983; 3:eMRXxuwm5s0aBQMscDulboLsczXqidfR5DbvF+ti0cTfO+dDwWhpj/W1Y3XgkwM9joQcPfC0IiD7uM1lYt1WP1bwfTOrKaHCDn0ZHA8aUmoS+dPXrYUF0TR/jr1kTCE9c3OHEteu9ONsRrh2ic6qcrEqoj20KW1SkOoLVogr2zRyVmgl6RyixKuDKUeV3sy4WakRpTdIssFcQi54J7zn51Dk9K+WU2g9SnstRJ3Y8wil2D7JWH5BduwT+RKF1P0iJq5CHBhEspH8fedeNQaZGA== X-Microsoft-Exchange-Diagnostics: 1; OSXPR0101MB0983; 25:hdpTTSqt7VAKiBAOuRGiy1S67EccouFHlb4rlC4/0JyVJ+Va9wMXpv2om0T6lmpitx5AKcJg6PgBcoJD+87m/MuYOrytJisAMAQ9P8kXVQdycfBKUyY3lQ8iIQlrsH3IitgTxV4qaR4dOCEY5SqATdhXELngCynxGDJ/q7RqB8WAUTWHMbXypRrU5w4afJY4Zl0P40lRSRiQpbTQgvzr9cE5qCthRponVMpWvDl2aSdaRMEp5z4NVnUzUwRlVHKFMdAGdCHFgVBlun+uoLJdujTMZK4im1aCnTvUOl9+qwMy0+bDBIL73BegcO802GVzmFbZKq88Em1USoVw0Ynz3f4adFLvK40QBF2GyPjZOtBz+rvoHiQ+wDY8Eb5+mDbRnNvf0WQtDb5mEyYx/v1VY5m1x/D9VljiaULarpSdfJQUU7XxWh5SpLvsuxqJMsBXzyrA9BZlPTHcBdW1Onc8EHTPiXbX6z1I0NOrJ6a/ciUJkTyUy8n7r9EakKxlsRmCvOtWn2BZeXj5CUQ9S4KZ1HuTpVMtF1Q2eeRVXpFTCo6jdrFrU3/OO5x47QDL5hjmTBuxvrDHNRA1WV6XqswHCjLuqYIYB2oIzFFwDBLngGpBfN+iw3TVzYVGpm+YqQDPBf4W33mgKR7aRtj7ubrU9TP12HjpGJ1P6xMXuh0dB049/DtHX8z9pH8ix+GZy584G3ebfxGJXNvz8Pkeu5BrSU8oA1A72xk6DmhUzgTRTOdmnBfA6scCGVR/7eM0ZE3MZrNTCFZdr2dVcNYzZWWDdvBuAmPlisYrDmGwL+pAYM+3FjwH+M3jQ9SctMmbFEhxJ3LspGSvSNpgRjoxO2s8qNrTkWqrE92gPo4WL1Hfq+hRaAD+/2ybLs8CMFKNAQyH X-Microsoft-Exchange-Diagnostics: 1; OSXPR0101MB0983; 31:ftBqX/v/zL6ISVLlZYlEcf1mJ+eI+xaIYbwOf5E9CzLvAhpRyb93EZBJMKWtoPHu3TsEC7vm6+gT+KF6Tih9JWfLzjK2/ykiUtqVCANUssDTyjXoMaCKr/gtpk+h7kC+hgjrmOi/E9JnI634LRgzia14mQQCnGAlZVXmzlF+cn7T40kvyqhr7Ig4ilHWnYXAY83mnKkNOMvkWyZ23NOEw0km1Szyp9s0Zk2xTXm6EjnNbIPKQQqxYs3uBedAcgbuMcbMzJBqlCq4wTpqCL7JQiQ+2aZ1z70r3YCfS8Fn0w4= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6045199)(6040361)(6060326)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(6061324)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(2016111802025)(6072148)(6043046)(6042181); SRVR:OSXPR0101MB0983; BCL:0; PCL:0; RULEID:; SRVR:OSXPR0101MB0983; X-Microsoft-Exchange-Diagnostics: 1; OSXPR0101MB0983; 4:DCdmZSnVxMC7DHIv6Hdqki7xisSEmmoP9ddFQHbBgIGWLTlmH2tsQLwmsvkc4WENoJoTVIB14DnCxWuc5XYSSz+7tlR9mCtMGXjGh7dEJFVd9K4ImKssxZkAvokDml8OyzhrYYWWg1U7UWLz7QSoqoR8/1+7u+IaM/kmPDTrHjZTxhlJOYV2Crq9oHuxx1vm469HuZpSOn+RmcFlkSDc3pW8kKKgsh81yiezZsxPJT7TZJl2LLV3cXOcuIeI4NiW5YpYMB510ev+QCcGZC4KcaRtA5MVqcJhQtYH/o25YteQ+M5gdntv5cylKFk3neH8VMOWR1yBOJK1XIg7+wnx/INCTj11uxEcIzggbL9vLMwdwbKP767VIifY87irKCOCpA8JkaOyXVgVWPTuUkRihgDLB1CX5T1eLBvYVSc829ThcfX8Gc4LM6dQCYy7SjQVmvRhc558c4kunO5MoXomcJF6fdSHonJnCAb0HHnVxGA3dX5plFO4q/TFDt3G9go2j3V4ZAPTejyuyxL8V6i8W8yvIGFZApH2V/zGbZtFfINWHPsVet2UQSmlDosRwa+KaQ2tIBYSIeSHlTt0t9csEiC9Ly653wjfmObDfGg4xif1s72lFADlNPdSoxdP0tb3ENtb8p9XiUbODovdLugPRmUpyAx7T4S2Zk57hfd32NeQV6IXvLJPeSlUAokXbI5qCc3hJ03BFM3UYRG7Za6duHaeSLo+dulIdSYfKrnn9us= X-Forefront-PRVS: 0139052FDB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(24454002)(69234005)(377424004)(189002)(199003)(57704003)(65806001)(305945005)(50986999)(31686004)(42186005)(76176999)(2870700001)(105586002)(54356999)(66066001)(74482002)(117156001)(31696002)(65956001)(68736007)(230783001)(733004)(47776003)(101416001)(6486002)(23676002)(77096006)(33646002)(92566002)(97736004)(4001150100001)(4001350100001)(64126003)(6116002)(7736002)(42882006)(2906002)(2950100002)(86362001)(7846002)(5660300001)(5001770100001)(83506001)(50466002)(65826007)(81156014)(38730400001)(229853002)(8676002)(106356001)(81166006)(3846002)(107886002)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:OSXPR0101MB0983; H:[192.168.1.2]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPU1hQUjAxMDFNQjA5ODM7MjM6dlpFK0EvMUxwYzJVU3lVVkFoODRsbnFO?= =?utf-8?B?QjdjcDZBYUZTL3FlSjBQV1dSSkErSnUyOVRabHZ6eHpYN0llV3k4TEFSdEdN?= =?utf-8?B?QlRuSU5uUEtMbXYvbkxzUFhkR0xZNkM1eC9HTWZCK1FTSVRESEN1aHFuTmpT?= =?utf-8?B?QlU3aEVXOUQwL2Mzb2hhT1FKS2xKOWt5N215ODJBMTNPNkFjaHp4NTdCVTM1?= =?utf-8?B?akk1L2p4ZzA2STRML3YvU1FkSUJzZDBMazZIZ29vNmZxMVpzZG13RUxVdk1X?= =?utf-8?B?K25KNDFqMzJRdzd3SEhjdk5GZEVVTlF3TTkzdkJXc1I4TVFpUWRvNGtWUjhC?= =?utf-8?B?M0l3SllEbGI3M3pna01oMHZsUllldCtGL2RwdVVFRndQVVo4YUEyOTZsYTJQ?= =?utf-8?B?V29DQmVkQ3E0NFRXbkEzZlBxRmJ6TEh2NGpPekJHMG5zT1ZUcUdaNXZHczVp?= =?utf-8?B?NzlMbitoMWZBTjJick1VRTVkcHdOUEsvbDhlRVBmemgyU2RIWGJzdDc5d09n?= =?utf-8?B?WTQ4eGdiaWxUcHB2SWxyVDdsV2g3eTdRWERqOWFFaDFvMDFiZXZUNzNsSFgw?= =?utf-8?B?UmREejUxcWlxYWNrS2ZhVUc2OWtCOFVPa2xGcDNSVWxONDdvSzZ3RWxBT1I3?= =?utf-8?B?V0YzVzZRV3hIcVVuTGpETVdCalRHZkdoT0JmMHZuTXN2bFoyYUtieDZ6YlF5?= =?utf-8?B?dzFlelBDc2dOU0xLaWtmR29lOTNNRStPKzhsMUtxdVpncElXUGRnTkZZcHNC?= =?utf-8?B?S1YvOTduNzc4ZG1LS3c1QjFwb2tiVkFabG1pVUdrMWdPbExFT1N3d3g1Rk42?= =?utf-8?B?V2ZVakNsenRTODM4b09OSFJHMWIrRUJMWVRJRjZjajN0ZjBGNStJMFdtQ2Yw?= =?utf-8?B?KzJScVdTN1E5azhBWGZkRkVMRE5hQWNqbjY4NDNrK1VjeU1ML1hBeityN1Fs?= =?utf-8?B?akdKaEF4OTdwVmVXSVQveHhvdTFkdXR2M1hQdC9oTkYrd1RGTFR3ZWZ6MW5C?= =?utf-8?B?QjdPclBHbE1zY3YvVU5Dd05pS0JFbkJ5UzZTZDRYbnRQMW5tOHNhU3dQQmx1?= =?utf-8?B?S2U5NE5RbFhuODJEeHVGN3A2RStudmNYbC9RZDZXVC9md3ZJdmxHSG10VWlU?= =?utf-8?B?cnUvaWgvSElBSEpFODhEQ2NWcm9GREJiZDUxZXVqbU0zWndkcEFpVVdHeDFF?= =?utf-8?B?ZEs3bVBqQUN3cGZxV2l5S05NaHZicWtXY1hrbmpMRDFZd3p2alQyN0pHNGtM?= =?utf-8?B?c3JxTzdadnJEQnRlV3dwTmJycWkrYUs0TENVVGx5RFkwQThKYVhPeVFLaHR2?= =?utf-8?B?OCtQbFJaTk8vOUNyMmhjV3JqbW5KMy9iQ2xkU0hKaG16SXRpcDlrUVRsUmhB?= =?utf-8?B?TGlTaXNoQ1BNMmhCM0FOcGlaTS92RkJLYWtudWp6NHordVI5dEhYZk5MWU1a?= =?utf-8?B?MUIycXR2SjZ1cHFaV1pjMnJVZ0UrNzZveGNocTVpaW12MUVYUGIraVlzdlpz?= =?utf-8?B?OFQ4Nkt3ZGhFNmRuUlpKS2xCMTVHREZ3MHhFdGVuNE8wYWZGVVFmbEw2dFpz?= =?utf-8?B?aDR1OEV1N1lKSVpvUzFKTEhVOEdydW9HNDNLR1ljQVZEOVEvb3RNeXpLR0Vr?= =?utf-8?B?U1VOZ1pRblJ1d1VhRWRidHdNdlUra1g4UVBGdm9EOTlndU9VVFNrZFYzLzQ2?= =?utf-8?B?cEFITkNTNm9nazNEdzZnS1NMdk9rNDZNQVZZRmRxdXkwRW9sS1BuUWU2a29o?= =?utf-8?B?QTQ0SjRCSjN0ODROZ3cwS1E5Q2g5d3NORy9ybWtyc0pXWCtXenQ1b2RmS1lQ?= =?utf-8?B?dkpEZVdxdDZxZFlETndjMzhIOFh0dUZ5U3liUkEyZndkejhjMXdLa3JRZlFH?= =?utf-8?B?Q3JhdG43KzJNRG9RRFl4UGhFQXg1UCsyREszY25EV0QyNUp5bUNlWVV3eEVa?= =?utf-8?B?ZlpIWGswVkpxbVE9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; OSXPR0101MB0983; 6:c3Q3lQMfBh7OBc7Na+TzKScoswV8eJwB7FN3UhblVuE70hPVJAv/bO+mMQ9nYcaSKjeSl9FLM1zxJLmmB//OOCJG91qaNxqk48cJJXOmw5rpI2/UXusawDtcJUdB1sxWwL3Ng7Xy29vupclR4ky2hT8FNbclL/Pqi3S6chWiCokza/gF+E5+QWSz9p93369mgHD8iRhv6cZPFwg5OYqITnmeyF2ezt2QkDNY2AdODvNEUZfbL3/779UqhkX0y3/dukG7BtHJhuEwZtBmR1fOTzWwsIxwvKaKUNyCgpS6bzCDQ8bpXel3jHpea90OXycXbVHpO8I/Zo/gsyne+TlHfzQbdkFjxyQ+WcviV1oDNkK1kMStvZrvIFdfPqjMXl2ircj5ae+UZIsrfZwTSpRqqZm5u9iDAWOTaPtO9O+r8sREIo6xuN9PefQwpgeXsJ+CasEVqGmbm5cA0kpGO7a4DtUWxYi4ZXp3dI373Oe70Ds=; 5:TNn6g5iBgZcm/gdFoR2Yh2Fja5Ahf0Iu7Gr6OqiXjZkJGKftcTZ0ewhPHgMsqMptykPo1uAVrTsHoyTovR48WtxqqONrQXpPJ/VLpi0ikNgqY3pOocAF4NJrJR36tRlui97UhZnC4elecouhWdZRKw==; 24:wq5yUgSf1MnG0ApmSECqyrGZ6b0SSQdBXI2qmdpd4iocXAbRQUAevoLkpA0bX2ROwIHzYt1qe38Ilfjvjqu3VxUmDfqLSHp50o4jeyilcZQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; OSXPR0101MB0983; 7:kY3cVkrzD80uQH0Bn95qp55I6hhbhMz3DCz57OyyuiiwJld9X0Y29nH9fxKz6qbetD+0wLxcn0LpdGhnPyQdeJeKt65N/APCPjW5r/Xql3CTepj3pVEHE0R+I9mTrsdOHyRXFnQGP8pVnqhpsfJ0kyeO5uP4XLMeMwCmYxPa5UCCfShRvn9o/mbUFhtZK2Y8I6b8RH7podqIEL0ojCKEKtRviOWiov7bl6r57RLfGbFL3o7FUbW2hmvpNRos/FT75nKEppNEuvMtbXjQBfxAGGihXlUBGNm5NqWv10JUprp0re/WnmgCtNBPaX+BHmTakwF3OTaC/7Oaori2Laryzo2N4mTZTJhnMJkCBOmKQ+OnpeVo4lFPN5j/1saPhnh3QplyZgm7y49XQYN+LLHMfYGta4fiuAjqtT1NzqPMH/dKr0ZTE4rtuH31rpMe1+QMJFHH85yq2G+jDJArtmM+9g== X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Nov 2016 06:00:38.1116 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSXPR0101MB0983 Archived-At: Subject: Re: [urn] FWD: Last Call: (Advertising Digital Identification (Ad-ID) URN Namespace Definition) to Informational RFC X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Nov 2016 06:00:46 -0000 Hello John, others, On 2016/11/24 18:01, John C Klensin wrote: > URNBIS WG: FYI. This is worth looking at, and possibly > commenting on, with regard to not only its content and > definition quality but also to whether the new registration > model would sufficiently identify and deal with any issues. > > In particular, > > (1) The new registration procedure would turn this over to > Expert Review, largely eliminating the possibility that someone > in the community who accidentally knows about and understands > the subject matter would look at and review it. On the other > hand, Expert Review can permit more intensive interaction and > negotiating with the authors of a registration request and/or > template than is normally part of the "throw it over the wall" > character of IETF Last Call and approval. Is that the tradeoff > we want? Would be worth the trouble to add an announcement to > the IETF list and window for comments to the expert to the > procedure (assuming the IESG would let us)? I think if this is the scenario we're concerned about, then submission to an urn-related list (the easiest would be this list) when applying for expert review, and conducting the expert review (mostly) on that list, would be better than further cluttering the IETF list. Regards, Martin. > (2) This I-D apparently contains references, some of them > implicit rather than listed, to documents that are behind > paywalls or otherwise hard to obtain and whose stability status > is unknown. Some of its content describes those external > documents, which might be considered as either an informal > tutorial or something that might, as the external standard > evolves over time, become inconsistent with that external > standard. Are those things satisfactory? If not, do we need > to describe the external documentation we are willing to accept > and/or push the authors/ would-be-registrants to be more > explicit in some way? > > Please copy this list on any Last Call comments that would bear > on 2141bis. > > thanks, > john > Brian E Carpenter > > ---------- Forwarded Message ---------- > Date: Monday, November 21, 2016 10:55 -0800 > From: The IESG > To: IETF-Announce > Cc: alexey.melnikov@isode.com, draft-adid-urn@ietf.org > Subject: Last Call: (Advertising Digital > Identification (Ad-ID) URN Namespace Definition) to > Informational RFC > > > The IESG has received a request from an individual submitter to > consider the following document: > - 'Advertising Digital Identification (Ad-ID) URN Namespace > Definition' as Informational RFC > > The IESG plans to make a decision in the next few weeks, and > solicits final comments on this action. Please send substantive > comments to the ietf@ietf.org mailing lists by 2016-12-19. > Exceptionally, comments may be sent to iesg@ietf.org instead. In > either case, please retain the beginning of the Subject line to > allow automated sorting. > > > Abstract > > Advertising Digital Identification (Ad-ID) Identifiers are > used identifying Advertising Assets across all media > platforms (over the air, on-line, over the top, mobile, place > based). This document defines the formal Uniform Resource > Name (URN) Namespace Identifier (NID) for Ad-ID Identifiers. > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-adid-urn/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-adid-urn/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > ---------- End Forwarded Message ---------- > > > > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > . > -- Prof. Dr.sc. Martin J. Dürst Department of Intelligent Information Technology College of Science and Engineering Aoyama Gakuin University Fuchinobe 5-1-10, Chuo-ku, Sagamihara 252-5258 Japan