From nobody Fri Aug 10 03:17:10 2018 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 E52B8130ECA for ; Fri, 10 Aug 2018 03:17: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, 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 jHTQPutipxDP for ; Fri, 10 Aug 2018 03:17:01 -0700 (PDT) Received: from smtp-out12.electric.net (smtp-out12.electric.net [89.104.206.33]) (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 DFE17130DE3 for ; Fri, 10 Aug 2018 03:17:00 -0700 (PDT) Received: from 1fo4TZ-000hbS-UT by out12b.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fo4Ta-000hdN-TS; Fri, 10 Aug 2018 03:16:58 -0700 Received: by emcmailer; Fri, 10 Aug 2018 03:16:58 -0700 Received: from [130.226.226.11] (helo=post.kb.dk) by out12b.electric.net with esmtp (Exim 4.90_1) (envelope-from ) id 1fo4TZ-000hbS-UT; Fri, 10 Aug 2018 03:16:57 -0700 Received: from EXCH-01.kb.dk (exch-01.kb.dk [10.5.0.111]) by post.kb.dk (Postfix) with ESMTP id 63F0691ED1; Fri, 10 Aug 2018 12:16:57 +0200 (CEST) Received: from EXCH-02.kb.dk (10.5.0.112) by EXCH-01.kb.dk (10.5.0.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1415.2; Fri, 10 Aug 2018 12:16:56 +0200 Received: from EXCH-02.kb.dk ([fe80::b595:1a1f:5666:b29]) by EXCH-02.kb.dk ([fe80::b595:1a1f:5666:b29%7]) with mapi id 15.01.1415.002; Fri, 10 Aug 2018 12:16:56 +0200 From: Eld Zierau To: "Hakala, Juha E" , "Henry S. Thompson" , "worley@ariadne.com" CC: "urn@ietf.org" Thread-Topic: [urn] Suggested PWID URN for Persistent Web IDentifiers - version 3 Thread-Index: AdQc3DGKkm3uj4RtRcGB26kVRboqjAIq7PstAAC7vAACwfXaAA== Date: Fri, 10 Aug 2018 10:16:56 +0000 Message-ID: References: <76f19e6c8892422d9d9475549218d82d@kb.dk> In-Reply-To: Accept-Language: da-DK, en-US Content-Language: da-DK X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.226.229.95] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-IP: 130.226.226.11 X-Env-From: elzi@kb.dk X-Proto: esmtp X-Revdns: post-03.kb.dk X-HELO: post.kb.dk X-TLS: X-Authenticated_ID: X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) X-PolicySMART: 10573177 Archived-At: Subject: Re: [urn] Suggested PWID URN for Persistent Web IDentifiers - version 3 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 10:17:09 -0000 Let me start by apologizing for the late response, which is due to the holi= day season. I would like to make some precisions and explanations in this response, sin= ce I think most of the critique is based on misunderstandings - probably be= cause I have not been clear enough. I will of course gladly incorporate in = a new version if that can help.=20 Below I have included the different responses with my comments in (on line = starting with "--"): 1) to Dale R. Worley's mail 2) to Henry S. Thompson's mail 3) to Juha's response to Henry S. Thompsons mail Best regards, Eld ----- Comments to Dale R. Worley's mail ----- 1)=20 Dale R. Worley worley@ariadne.com Re: [urn] Suggested PWID URN for Persistent Web IDentifiers - version 3 21-07-2018 Comments on this draft: I am by no means an archivist, so my comments will be largely technical. The draft seems to me to be prolix, giving a lot of discussion of details t= hat are not reflected in the URN proposal itself. A careful editing will p= robably fix this. A major component of pwid-urn is archive-id. My assumption is that the arc= hive-id is the top-level component and defines what abstract "archive" the = URN is a reference into. And that the "archive" defines the exact interpre= tation of archival-tine, coverage-spec, and archived-item. However, in ord= er for PWID URNs to be unambiguous, it must be unambiguous what "archive" a= given archive-id refers to. The draft suggests "it is recommended to use = the web domain as the identifier for the web archive". What if an institution decides to create PWID URNs that use an archive-id w= hich is a domain name that the institution does not own? As written, the d= raft does not forbid *me* from creating PWID URNs with archive-id "netarkiv= et.dk". -- Eld: I think there is a misunderstanding here - it is not the archive th= at chooses the archive name, it is the creator of the reference, - and that= is why it is recommended to use the domain name. It would be best to have = a formal registry, but I have to start somewhere, - and with the domain nam= e it is possible to find a reference to any existing web archive (restricte= d access or not). Within the next 5-10 years, I think there will be evidenc= e enough (e.g. from web archives) to reconstruct a registry in case there a= re web archives changing domains within that period. I will definitely wor= k on having such a registry formerly established. -- It could be that it should be stronger here and instead say: 'must use' = - instead of 'recommend to use' In regard to archival-time, the draft states "The 'archival-time' [...] can= therefore be specified at any of the levels of granularity as described in= [W3CDTF]." However, W3CDTF gives a number of formats for time designation= s, and calls those formats "granularities", whereas this draft allows only = one format. I suspect that a more careful description of the meaning of th= e quoted sentence would fix this problem. -- Eld: absolutely The syntax assumes that knowing archive-id, archival-time, coverage-spec, a= nd archived-item (the archived URI) will always be sufficient to specify ex= actly the resource in question. However, it seems likely that special situ= ations will arise when two distinct resources will have attributes that are= similar enough that the distinction between them is not easily expressed i= n terms of archive-id, archival-time, coverage-spec, or archived URI. In t= his case, additional information is needed to create an exact reference, an= d the URN syntax needs to have an expansion facility to allow this. -- Eld: The very nature of web archives is based on information archived UR= I and archival time - per archive - if there are such cases the web archive= would have a problem with their indexes, as these are based exactly on thi= s information. This is also why it is this information that is chosen and w= hy it is important to specify the archive as well. The content-coverage is = another story, which I will go more into in my response to Henry S. Thompso= n's mail archived-item can be a URI, and a URI can contain the characters '?', '#', = '[', and ']', among others. However, those 4 characters may not appear in = the NSS part of a URN. Note that the first 2 of these characters are used = in URIs only to introduce the "query" and "fragment" parts, but as the draft is written, the archived-item URI is not restricted= to not having a query or fragment part. -- Eld: that is a problem if the archived URI does have fragments Dale ----- Comments to Henry S. Thompson's mail ----- 2) Henry S. Thompson Re: [urn] Suggested PWID URN for Persistent Web IDentifiers - version 3 27-07-2018 Eld Zierau writes: > Please note that I have updated the suggested PWID URN for Persistent=20 > Web Identifiers with the following changes: > > ... > > It is available as version 3 from > https://datatracker.ietf.org/doc/draft-pwid-urn-specification/, and it=20 > is attached to this email as a pdf. [Before my comments, please note that I don't believe it's best practice to= attach drafts in mail to this list -- your original was classified as spam= as a result of the attachment, and I only found out about it as a result o= f Juha's mail.] -- Eld: Got that Much of what follows is a critique of the requirements analysis and the pre= sumed use cases, rather than the specifics of the namespace itself, and the= overall conclusion is negative. This is a bit unusual, in that I wouldn't normally bother with an extended = critique whose TL;DR would be "It doesn't seem likely to me that this will = solve anyone's problems". After all, if it doesn't solve anyone's problems= , no-one will use it, let the 'market' decide, right? This might be so, for a narrowly focused namespace targeting a specialist c= ommunity. But this proposal has _very_ large-scale use in view. -- Eld: Yes it is aimed big, and there is already a big interest for it - a= nd there are several reasons for this. -- Let me start by pointing out that I have a background as a computer scie= ntist (from 1989) with a PhD in digital preservation from 2011. With this b= ackground, four years ago, I would probably raise some of the same question= s. -- The background for the PWID is a research project, which I undertook wit= h a historian and a literary scientist, and they have much harder requireme= nts for references than what I have been used to in my field. It is this di= fference that has made it clear to me that there is a lack of ways to refer= ence sources in web archives for digital humanist working with web archives= . Please note that the only way to make such a reference today is via URLs,= which only works for online web archives. A lot of European web archives a= re not online, and we are unable to employ such references. At some point, = the Danish web archive recommended the 'URL' used in a protected environmen= t addressing the files directly. These references are now useless after we = have compressed all the data. Please also note that there is nothing sustai= nable about a web archive URL - as noted in the draft, the paths are in man= y cases tools dependent and are therefore very likely to change in 5-10 yea= rs. -- Especially for the humanities there is great focus on the sustainability= of references. It must be evident that all referenced sources can be retri= eved later on in order to re-evaluate the findings (for more than a 5-10 ye= ar horizon). As many studies shows (referenced in the draft) there is a gre= at link rot just over a short number of years. My personal experience is th= at 15 % of the referenced links in my PhD (from 2011) are now dead. What we= found in our studies was that within the literary field, there were quite = a few works that did not reference the web at all - we suspect that this co= uld point at a tendency that they do not want to use the insecure web refer= ences - which in practice can mean that the internet might not be the subje= ct of relevant research. -- A present need for the URN PWID is for definition of web corpora. A defi= nition of a corpora (web collection) is for example the European initiative= to select a part of the archived web for each year - cleaned for duplicate= s etc. - in order to have a basis for statistical measurements. In order to= be able to do recalculation of the measurements and look into the basis fo= r the measurements, it will be required that you somehow preserve a represe= ntation of it. It will be too expensive to preserve the data separately bec= ause of the volume, therefore it must be references that is saved. There ha= ve been ideas about saving CDX indexes, but these are not standard either. = Therefore, specification of PWID URNs as references is a good choice. -- This leads to the use of PWID as a general form, if you have your resour= ce archived or find the resource in an archive: Either by getting a possibi= lity to refer to the large volumes of material in European web archives (wi= th restricted access) or by getting a sustainable technology agnostic way t= o address resources that have been archived for the purpose of creating a p= ersistent reference. -- I hope I with this have made it clear that this is NOT just narrowly foc= used namespace, but will be a huge help especially for any researcher that = wants to make acceptable research in web archive materials. _And_, the legitimacy of discourse around various aspects of 'persistent' r= eference has been so compromised by flawed analyses and failed solutions th= at there is actually real reputational risk for the urn infrastructure itse= lf from yet another example, which I'm afraid I think this is, particularly= given its very high aims. -- Eld: I hope that the above gives some clarification on this, - and about= the infrastructure: this only relies on the definition, - anyone can build= resolvers at any point of time (as long as we have the history of domains,= which I will come back to). The reason is that the PWID is based on the ve= ry basic elements from registering a "located" thing in an archive: the arc= hive, the location, and the time of archiving. Therefore, with the right in= dexes and grants, a resource can be found based on this information. -- I suspect that I may have confused things by both talking about the text= ual and the technical URN PWID. It was meant as a way to explain this, but = that can be changed if it is confusing things instead. So, I'm sorry but for these reasons, and the many specific problems discuss= ed below, I don't personally see a future for this document. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Specific comments, by section *Purpose* As noted above, the goal stated in the open paragraph is very ambitious. The only parts of the argument that follows that I can make sense of, as to= why the proposed scheme is needed, consist of two mistaken and/or unsuppor= ted high-level claims: 1) Citations of web-hosted resources should refer to archives, not to the resources themselves; -- Eld: I have included several references to conference papers in the draf= t to support this claim, - I will of course gladly extend this if it is nee= ded 2) Citation of archived material needs help to be sufficiently 'precise'. -- Eld: There are also references to support this - mainly from the researc= h group that I refer to above - but in these papers there are also other re= ferences - I will of course also gladly extend this if it is needed The first is at best contentious as a general claim, and even in cases wher= e an archive reference is preferred, why packaging it in a PWID urn will ad= d value is not explained. After all, if I know that what I want to cite is= available in some archive, it's because I've found it there, in which case= I already _know_ the URI I can use to retrieve it. More on this when belo= w when we come to the question of uniqueness. -- Eld: This is due to the fact that an URI to a web archive is not persist= ent - and only existing for online web archives. I thought I made it clear,= but I can of course elaborate on this as well. The second surely applies to any kind of citation at all, and seems to depe= nd on a confusion between web identity, media type and the ontology of cita= ble things and loci associated with them -- all of FRBR lurks just around t= he corner here. -- Eld: The precision is needed because references to web materials are ver= y imprecise. Especially within the humanities, you need to specify what you= refer to and thereby also what the author has cheked that the specific re= ference points to. There is a big difference between referencing a web page= or a website or just the html for the web page. The reason that this is pa= rt of the PWID URN is to have all the information there and to make it poss= ible (later on) for the web archives to supply services that correspond to = the reference Just because some representation is hosted on the Web does not make it easi= er (or harder) than it ever was to make clear in a citation what part/aspec= t/property of what you _name_ in a citation is what you actual are _referri= ng to_. More on this below when we come to the 'coverage-spec'. ------------ One more specific issue with this section "The precision regards both regards precise reference where there can be no doubt about that you have the correct web material as well as precision about what is actually referred by the reference (e.g. is it the page or the whole website)" There's nothing in the proposal which follows to back up the "you have the = correct web material" claim, and the subsequent inventory of 8 'type[s] of = archived item[s]' is clearly not sufficient to unambiguously determine "wha= t is actually referred [to] by the reference". -- Eld: I just realize that there is a context missing and precision is nee= ded. It relates to the way Memento argues for URL and date being sufficient= information in order to identify a web resource, i.e. that it does not mat= ter which archive you get the resource from as long as it is approximately = from that time. That should definitely be more clear. I have numerous examp= les of differences in archived material of the same URL around the same tim= e, where a reference can make sense in one case but not the other (typicall= y from often updated news sites, or due to bad harvest settings or warnings= requiring additional information before entering the site). A way to make = the precision could be to say that it is precise about which archive it was= evaluated in. -- I agree that you cannot be sure of your reference as long as it is not e= ntirely based on parts, since it will be up to e.g. Wayback software to det= ermine each of the parts (usually the closest in time, which may change if = included materials from other archives or harvest parts that did not origin= ally exist in the archive). I gladly include description of this as well. *Syntax* I see no problems in the ABNF. ------------ The definitions of the 'coverage-spec' values are hopelessly underspecified= , and heterogenous. The 'part'/'page' distinction is particularly unclear/= non-obvious/ambiguous/medai-type dependent. -- Eld: hopefully it is more clear from the above. - the point is to make i= t possible to present the resource as reference - or for a user of the refe= rence to make the right choices in order to extract the referred informatio= n. This means in case of 'part' for html, asp, jpg . it will be the actual = source of the archived file, in case of web page it will be the "Wayback" s= oftware version (and actually the same for subsite and site). Some archives= have possibility for choosing between snapshots or harvested web files, wh= ich is where the snapshot comes in. A comment from the iPRES 2013 conferenc= e was that it was missing web recordings, which is why recording is in, and= finally there is a need for addressing collection (corpuses) also in order= to make a hierarchi of collections (e.g. each year of the Danish example c= orpuses, another containing those years, a third containing the Danish year= s and some years from UK web archive etc.). if it is useful I gladly includ= e a modified version of this explanation also. *Assignment* The initial claim here and its subsequent gloss taken together don't hold u= p: "The PWID URNs does not have to be assigned by an authority, as they are based on the information created at the time of archiving:" "In other words: the PWID URNs are created independently, but following an algorithm that itself guarantees uniqueness." On a strict reading of "uniqueness" (i.e. a one-to-one relation between ite= ms and PWIDs), this amounts to a claim that _any_ 3rd party considering _an= y_ item in _any_ archive will always construct the _same_ PWID. This readi= ng is obviously false: the presence of the two "+( unreserved )" expansions= in the ABNF amount to a _guarantee_ that there will be multiple distinct P= WIDs for the same item. -- Eld: I never meant to say that it was a two-ways uniqueness, and I can s= ee it can be read as that, so that should be clarified. For example, if int= ernet archive exchange their domain name with ai.org then future PWIDs with= ai.org as archive identifier will point to the same as archive.org for the= same archived items (which covers the first "+( unreserved )". There may a= lso be rare cases with the other one, which represents a generalization (to= include e.g. collections specified by an identifier) - and yes in some cas= es an archive have more identifiers for the same thing. But as you say ther= e should be no problem with that. -- If the assignment is confusing I can also expand that, to clarify that i= t is the basic metadata for archiving (archive, got from location, at time)= combined with precision of what is referenced. RFC8141 does not require one-to-one relations between URNs, even URNs withi= n the same namespace. But it does require, in the case of "URNs . . . crea= ted independently" that they be created "following an algorithm that itself= guarantees uniqueness". The underspecification of the 'coverage-spec' alr= eady alluded to above makes independent _and_ inconsistently understood coi= nages of identical PWIDs not just possible but likely. Consider for exampl= e urn:pwid:web.archive.org:2018-01-01T17:03:53Z:part:http://www.ltg.ed.ac.uk/= ~ht/ One person might coin this to mean the text/html character sequence which w= as served from http://www.ltg.ed.ac.uk/~ht/ (my homepage at the University = of Edinburgh) at the beginning of 2018, whereas someone else might coin it = to mean the text/html character sequence you get from the Web Archive today= if you do an http GET on https://web.archive.org/web/20180101170353/http:/= /www.ltg.ed.ac.uk/~ht/, which are different in important ways. -- Eld: This is only about archived materials, with the limitations that w= eb archiving has. It is only meant to mean the latter case, which can be ma= de more precise, of course In general, it seems that knowing whether to use 'part' or 'page' would dep= end on a detailed understanding of the media type of the retrieved represen= tation, which the average creator of a citation is unlikely to have. -- Eld: This referencing mechanism is meant for users that verify their sou= rce before referring to it, - it is already part of standards to make clear= whether it is page or site, so I would not see any problems with that. I c= an expand the explanation of part with several examples to make clear that = that should not be an option if you mean page or site. For the rest I would= assume that you would know if you were using it. -- It is also meant as a future basis for making tools to respect and prov= ide what the reference is covering - so you do not need to know that you ha= ve to select snapshot, - or use a get for requesting the source of a page, = Also to have tools for corpora where can be made clear when a reference is = to a subcorpora. The inspiration for this way of doing it came from the Int= ernet Archives use of function e.g. the Identity Wayback function which is = called by placing 'id_' after the in the archive url as for example= https://web.archive.org/web/20180101170353id_/http://www.ltg.ed.ac.uk/~ht/= (different functions described on https:/en.wikipedia.org/wiki/Help:Using_= the_Wayback_Machine).=20 ------------- Some of this is corrigible, but only at the expense of a vast increase in d= etail and clarity. Others not-so-much, insofar as so much is _necessarily_= left underspecified, to allow for _anything_ to be considered as an archiv= e ('archive-id' value), with the consequent requirement to allow for arbitr= arily idiosyncratic internal naming mechanisms ('archived-item' value). -- Eld: It should be clarified that this is only in case an identifier can = be found in the archive - actually it should probably also be mentioned und= er assignment that in these cases, it is identifiers assigned to objects by= the archive. I'm curious in this connection to wonder if we actually have any URN namesp= aces where assignment is done "independently but following an algorithm tha= t itself guarantees uniqueness"? Ah, there are registrations for urn:uuid:= , which qualifies, and urn:oid:, which sort of does. OK, is there such a n= amespace in active use? Which provides for resolution, at least in princip= le? -- Eld: we use UUIDs for identifiers for our library material, and we use W= ARC as packaging format, therefore it is essential for us to use the urn:uu= id: since WARC only accepts URIs as identifiers A crucial point here is that in the OID case a urn:oid:... carries a chain = of responsibility with it. If you run across one, you know how to find out= who takes responsibility for every level in the tree that's involved in in= terpreting it. In the UUID case, a urn:uuid: doesn't travel well/at all, s= o the question doesn't arise. But for PWIDs, if I find one I have _no way_= to figure out who's responsible, or whom I can ask for clarification, or w= hom to blame if it doesn't appear to 'work'. -- Eld: I am not sure I understand this - or what is causing a possible mis= understanding. As said before, anyone can make a resolver for open web arch= ives and any archive with restricted access can make their own (only having= the challenge with archive identifiers as mentioned later). You can take t= he PWID and "manually use it to locate you resource. If the person making t= he reference made mistakes or if the archive lost its resources, I don't th= ink it is the PWID that should be blame - which I see a direct parallel to = for any referencing systems - digital or analogue. ---------------- I don't see what the intended value of the discussion of the "SOLR-Wayback = tool" is for the spec. -- Eld: It is to say that you are not on a huge job if you want to collect = all parts for a web page, - there actually exists tools to help you. If it = is not appropriate to have it here, I can take it out. *Interoperability* The above comments about ambiguity/lack of identity apply here too: if diff= erent implementors interpret e.g. a coverage-spec of 'subsite' differently, their resolvers will not interoperate. -- Eld: I can make a more clear definition if wanted, - admittedly, I have = not gone into depth with this, since (as far as I know) there are no toolin= g for this yet, but it is a point that it should be more precise, - also to= make clear what was validated when making the reference. *Resolution* None of this is very much to the point. In particular, it completely ignor= es the precedents set by doi.org, identifiers.org and n2t.net (https://doi.org/10.1038/sdata.2018.95 exemplifies the first and its conten= t discusses the second and third).=20 -- Eld: I don't understand this, - as far as I know these are dealing with = registered identifiers. There are no way that all web materials will have a= registered identifier, - the volume is too big. That is the reason why the= PWID is needed - . maybe I have misunderstood some things here. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In conclusion, I think a useful way to think about this proposal is as a mi= sguided attempt to define a urn type which _is_ a citation. This makes sen= se of PWID's 3rd party nature, and clarifies that the archive-id and -time,= the embedded URI and the coverage spec are just a pretty arbitrary, certai= nly impoverished, subset of what you would expect to find in a _real_ citat= ion. Trying to pack a citation into a URN just doesn't make sense to me. N= either does trying to determine exactly the _right_ subset of citations of = web-hosted resources to pack up in order to be both useful and unambiguous. -- Eld: I hope I have made it more clear in these comments (There is work underway in various venues (see e.g. [1]) to _objectify_ cit= ations and give PIDs to _those_, which might address at least some of the g= oals of this work.) ht [1] http://sched.co/DJ3P --=20 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 _al= ways_ has a .sig like this -- mail without it is forged spam] ----- Comments to Juha Hakala's mail ----- 3) Hakala, Juha E juha.hakala@helsinki.fi RE: [urn] Suggested PWID URN for Persistent Web IDentifiers - version 3 27-07-2018 Hello,=20 a few comments below.=20 -----Original Message----- From: urn On Behalf Of Henry S. Thompson Sent: perjantai 27. hein=E4kuuta 2018 11.58 To: Eld Zierau Cc: urn@ietf.org Subject: Re: [urn] Suggested PWID URN for Persistent Web IDentifiers - vers= ion 3 The only parts of the argument that follows that I can make sense of, as to= why the proposed scheme is needed, consist of two mistaken and/or unsuppor= ted high-level claims: 1) Citations of web-hosted resources should refer to archives, not to the resources themselves; 2) Citation of archived material needs help to be sufficiently 'precise'. The first is at best contentious as a general claim, and even in cases wher= e an archive reference is preferred, why packaging it in a PWID urn will ad= d value is not explained. After all, if I know that what I want to cite is= available in some archive, it's because I've found it there, in which case= I already _know_ the URI I can use to retrieve it. More on this when belo= w when we come to the question of uniqueness. Juha: ISO TC 46/SC 9 is currently revising ISO 690 (Guidelines for bibliogr= aphic references and citations to information resources). One of the challe= nges is how to deal with reference rot, which consists of link rot (404) an= d content drift (retrieved documents change). A large percentage of all Int= ernet resources suffer from these problems.=20 Eld has been most helpful in writing the Annex that discusses the usage of = Web archives in detail, and the current version is based on what she has wr= itten, with two important exceptions:=20 - I don't think that referring just to a copy of the cited resource in a We= b archive is always the best solution. Archive reference only must be used = when the resource is dynamic (say, https://www.ed.ac.uk/) and a specific ve= rsion is cited. But when the page is supposed to be persistent (e.g. https= ://www.w3.org/Provider/Style/URI) the added value provided by the archive l= ink may be modest, because the archived copy may not always be exactly the = same, and web archives themselves may not last forever. The current draft o= f ISO 690 (which is still only a working draft) does promote the use of web= archives, but not as the only solution. And if web archives are used, util= ization of Memento is something that should be considered since it provides= some level of protection to disappearance of web archives. =20 - the current ISO 690 draft does not mention PWID. There are three reasons = for this. First, and most importantly, PWID does not (yet) have a registere= d URN namespace. An ISO standard cannot refer to PWIDs as long as namespace= registration has not been completed. And IMO it is not obvious that it wil= l be completed. Second, every persistent identifier that will be included i= n the examples or elsewhere in the standard must be actionable (expressed, = for the time being, as HTTP URI). So all DOIs that were in the form doi: have been converted into https://doi.org/. This will = not possible with PWIDs, since only the Danish web archive is planning to i= mplement PWIDs, in an archive which has strict access limitations.=20 When you consider what to do with PWID, keep in mind that as a national lib= rary the Royal Danish Library can always use the NBN namespace for items in= the web archive. For instance, something like urn:nbn:pwid: can be c= onstructed, as long as the string conforms to the syntactical requir= ements of the NBN namespace. =20 Henry: The second surely applies to any kind of citation at all, and seems = to depend on a confusion between web identity, media type and the ontology = of citable things and loci associated with them -- all of FRBR lurks just a= round the corner here. Just because some representation is hosted on the Web does not make it easi= er (or harder) than it ever was to make clear in a citation what part/aspec= t/property of what you _name_ in a citation is what you actual are _referri= ng to_. More on this below when we come to the 'coverage-spec'. Juha: trying to express in PWID coverage-spec which part of the of the res= ource has been cited may be more difficult that providing this information = elsewhere in the citation. ISO 690 draft specifies such an alternative appr= oach. And even if PWID really has to be used for this purpose, usage of f-= , r- and q-components may also be considered as an alternative.=20 As Henry says below, coverage-spec would need a lot more alternatives to be= truly useful. Coverage-spec "other" does not add much value, and it would = be necessary to use it for every image, video, etc. And if there are severa= l images on the page, how to indicate the right one (except with f-componen= t)? -- Eld: Thank you Juha - just for this last remark, I am not sure I underst= and it . hopefully the role of coverage-spec is more clear from my response= to Henry S. Thompson, otherwise please tell me. For the case of two image= s, I would say that you would have to get a reference for the exact image p= art of the page, otherwise you have a risk that a totally different image i= s displayed because of update to the archives data. Best,=20 Juha ------------ One more specific issue with this section "The precision regards both regards precise reference where there can be no doubt about that you have the correct web material as well as precision about what is actually referred by the reference (e.g. is it the page or the whole website)" There's nothing in the proposal which follows to back up the "you have the = correct web material" claim, and the subsequent inventory of 8 'type[s] of = archived item[s]' is clearly not sufficient to unambiguously determine "wha= t is actually referred [to] by the reference". *Syntax* I see no problems in the ABNF. ------------ The definitions of the 'coverage-spec' values are hopelessly underspecified= , and heterogenous. The 'part'/'page' distinction is particularly unclear/= non-obvious/ambiguous/medai-type dependent. *Assignment* The initial claim here and its subsequent gloss taken together don't hold u= p: "The PWID URNs does not have to be assigned by an authority, as they are based on the information created at the time of archiving:" "In other words: the PWID URNs are created independently, but following an algorithm that itself guarantees uniqueness." On a strict reading of "uniqueness" (i.e. a one-to-one relation between ite= ms and PWIDs), this amounts to a claim that _any_ 3rd party considering _an= y_ item in _any_ archive will always construct the _same_ PWID. This readi= ng is obviously false: the presence of the the two "+( unreserved )" expans= ions in the ABNF amount to a _guarantee_ that there will be multiple distin= ct PWIDs for the same item. RFC8141 does not require one-to-one relations between URNs, even URNs withi= n the same namespace. But it does require, in the case of "URNs .. . . cre= ated independently" that they be created "following an algorithm that itsel= f guarantees uniqueness". The underspecification of the 'coverage-spec' al= ready alluded to above makes independent _and_ inconsistently understood co= inages of identical PWIDs not just possible but likely. Consider for examp= le urn:pwid:web.archive.org:2018-01-01T17:03:53Z:part:http://www.ltg.ed.ac.uk/= ~ht/ One person might coin this to mean the text/html character sequence which w= as served from http://www.ltg.ed.ac.uk/~ht/ (my homepage at the University = of Edinburgh) at the beginning of 2018, whereas someone else might coin it = to mean the text/html character sequence you get from the Web Archive today= if you do an http GET on https://web.archive.org/web/20180101170353/http:/= /www.ltg.ed.ac.uk/~ht/, which are different in important ways. In general, it seems that knowing whether to use 'part' or 'page' would dep= end on a detailed understanding of the media type of the retrieved represen= tation, which the average creator of a citation is unlikely to have. ------------- Some of this is corrigible, but only at the expense of a vast increase in d= etail and clarity. Others not-so-much, insofar as so much is _necessarily_= left underspecified, to allow for _anything_ to be considered as an archiv= e ('archive-id' value), with the consequent requirement to allow for arbitr= arily idiosyncratic internal naming mechanisms ('archived-item' value). I'm curious in this connection to wonder if we actually have any URN namesp= aces where assignment is done "independently but following an algorithm tha= t itself guarantees uniqueness"? Ah, there are registrations for urn:uuid:= , which qualifies, and urn:oid:, which sort of does. OK, is there such a n= amespace in active use? Which provides for resolution, at least in princip= le? A crucial point here is that in the OID case a urn:oid:... carries a chain = of responsibility with it. If you run across one, you know how to find out= who takes responsibility for every level in the tree that's involved in in= terpreting it. In the UUID case, a urn:uuid: doesn't travel well/at all, s= o the question doesn't arise. But for PWIDs, if I find one I have _no way_= to figure out who's responsible, or whom I can ask for clarification, or w= hom to blame if it doesn't appear to 'work'. ---------------- I don't see what the intended value of the discussion of the "SOLR-Wayback = tool" is for the spec. *Interoperability* The above comments about ambiguity/lack of identity apply here too: if diff= erent implementors interpret e.g. a coverage-spec of 'subsite' differently, their resolvers will not interoperate. *Resolution* None of this is very much to the point. In particular, it completely ignor= es the precedents set by doi.org, identifiers.org and n2t.net (https://doi.org/10.1038/sdata.2018.95 exemplifies the first and its conten= t discusses the second and third).=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In conclusion, I think a useful way to think about this proposal is as a mi= sguided attempt to define a urn type which _is_ a citation. This makes sen= se of PWID's 3rd party nature, and clarifies that the archive-id and -time,= the embedded URI and the coverage spec are just a pretty arbitrary, certai= nly impoverished, subset of what you would expect to find in a _real_ citat= ion. Trying to pack a citation into a URN just doesn't make sense to me. N= either does trying to determine exactly the _right_ subset of citations of = web-hosted resources to pack up in order to be both useful and unambiguous. (There is work underway in various venues (see e.g. [1]) to _objectify_ cit= ations and give PIDs to _those_, which might address at least some of the g= oals of this work.) ht [1] http://sched.co/DJ3P --=20 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 _al= ways_ has a .sig like this -- mail without it is forged spam] _______________________________________________ urn mailing list urn@ietf.org https://www.ietf.org/mailman/listinfo/urn -----Original Message----- From: Hakala, Juha E =20 Sent: Friday, July 27, 2018 1:19 PM To: Henry S. Thompson ; Eld Zierau Cc: urn@ietf.org Subject: RE: [urn] Suggested PWID URN for Persistent Web IDentifiers - vers= ion 3 Hello,=20 a few comments below.=20 -----Original Message----- From: urn On Behalf Of Henry S. Thompson Sent: perjantai 27. hein=E4kuuta 2018 11.58 To: Eld Zierau Cc: urn@ietf.org Subject: Re: [urn] Suggested PWID URN for Persistent Web IDentifiers - vers= ion 3 The only parts of the argument that follows that I can make sense of, as to= why the proposed scheme is needed, consist of two mistaken and/or unsuppor= ted high-level claims: 1) Citations of web-hosted resources should refer to archives, not to the resources themselves; 2) Citation of archived material needs help to be sufficiently 'precise'. The first is at best contentious as a general claim, and even in cases wher= e an archive reference is preferred, why packaging it in a PWID urn will ad= d value is not explained. After all, if I know that what I want to cite is= available in some archive, it's because I've found it there, in which case= I already _know_ the URI I can use to retrieve it. More on this when belo= w when we come to the question of uniqueness. Juha: ISO TC 46/SC 9 is currently revising ISO 690 (Guidelines for bibliogr= aphic references and citations to information resources). One of the challe= nges is how to deal with reference rot, which consists of link rot (404) an= d content drift (retrieved documents change). A large percentage of all Int= ernet resources suffer from these problems.=20 Eld has been most helpful in writing the Annex that discusses the usage of = Web archives in detail, and the current version is based on what she has wr= itten, with two important exceptions:=20 - I don't think that referring just to a copy of the cited resource in a We= b archive is always the best solution. Archive reference only must be used = when the resource is dynamic (say, https://www.ed.ac.uk/) and a specific ve= rsion is cited. But when the page is supposed to be persistent (e.g. https= ://www.w3.org/Provider/Style/URI) the added value provided by the archive l= ink may be modest, because the archived copy may not always be exactly the = same, and web archives themselves may not last forever. The current draft o= f ISO 690 (which is still only a working draft) does promote the use of web= archives, but not as the only solution. And if web archives are used, util= ization of Memento is something that should be considered since it provides= some level of protection to disappearance of web archives. =20 - the current ISO 690 draft does not mention PWID. There are three reasons = for this. First, and most importantly, PWID does not (yet) have a registere= d URN namespace. An ISO standard cannot refer to PWIDs as long as namespace= registration has not been completed. And IMO it is not obvious that it wil= l be completed. Second, every persistent identifier that will be included i= n the examples or elsewhere in the standard must be actionable (expressed, = for the time being, as HTTP URI). So all DOIs that were in the form doi: have been converted into https://doi.org/. This will = not possible with PWIDs, since only the Danish web archive is planning to i= mplement PWIDs, in an archive which has strict access limitations.=20 When you consider what to do with PWID, keep in mind that as a national lib= rary the Royal Danish Library can always use the NBN namespace for items in= the web archive. For instance, something like urn:nbn:pwid: can be c= onstructed, as long as the string conforms to the syntactical requir= ements of the NBN namespace. =20 Henry: The second surely applies to any kind of citation at all, and seems = to depend on a confusion between web identity, media type and the ontology = of citable things and loci associated with them -- all of FRBR lurks just a= round the corner here. Just because some representation is hosted on the Web does not make it easi= er (or harder) than it ever was to make clear in a citation what part/aspec= t/property of what you _name_ in a citation is what you actual are _referri= ng to_. More on this below when we come to the 'coverage-spec'. Juha: trying to express in PWID coverage-spec which part of the of the res= ource has been cited may be more difficult that providing this information = elsewhere in the citation. ISO 690 draft specifies such an alternative appr= oach. And even if PWID really has to be used for this purpose, usage of f-= , r- and q-components may also be considered as an alternative.=20 As Henry says below, coverage-spec would need a lot more alternatives to be= truly useful. Coverage-spec "other" does not add much value, and it would = be necessary to use it for every image, video, etc. And if there are severa= l images on the page, how to indicate the right one (except with f-componen= t)?=20 Best,=20 Juha ------------ One more specific issue with this section "The precision regards both regards precise reference where there can be no doubt about that you have the correct web material as well as precision about what is actually referred by the reference (e.g. is it the page or the whole website)" There's nothing in the proposal which follows to back up the "you have the = correct web material" claim, and the subsequent inventory of 8 'type[s] of = archived item[s]' is clearly not sufficient to unambiguously determine "wha= t is actually referred [to] by the reference". *Syntax* I see no problems in the ABNF. ------------ The definitions of the 'coverage-spec' values are hopelessly underspecified= , and heterogenous. The 'part'/'page' distinction is particularly unclear/= non-obvious/ambiguous/medai-type dependent. *Assignment* The initial claim here and its subsequent gloss taken together don't hold u= p: "The PWID URNs does not have to be assigned by an authority, as they are based on the information created at the time of archiving:" "In other words: the PWID URNs are created independently, but following an algorithm that itself guarantees uniqueness." On a strict reading of "uniqueness" (i.e. a one-to-one relation between ite= ms and PWIDs), this amounts to a claim that _any_ 3rd party considering _an= y_ item in _any_ archive will always construct the _same_ PWID. This readi= ng is obviously false: the presence of the the two "+( unreserved )" expans= ions in the ABNF amount to a _guarantee_ that there will be multiple distin= ct PWIDs for the same item. RFC8141 does not require one-to-one relations between URNs, even URNs withi= n the same namespace. But it does require, in the case of "URNs .. . . cre= ated independently" that they be created "following an algorithm that itsel= f guarantees uniqueness". The underspecification of the 'coverage-spec' al= ready alluded to above makes independent _and_ inconsistently understood co= inages of identical PWIDs not just possible but likely. Consider for examp= le urn:pwid:web.archive.org:2018-01-01T17:03:53Z:part:http://www.ltg.ed.ac.uk/= ~ht/ One person might coin this to mean the text/html character sequence which w= as served from http://www.ltg.ed.ac.uk/~ht/ (my homepage at the University = of Edinburgh) at the beginning of 2018, whereas someone else might coin it = to mean the text/html character sequence you get from the Web Archive today= if you do an http GET on https://web.archive.org/web/20180101170353/http:/= /www.ltg.ed.ac.uk/~ht/, which are different in important ways. In general, it seems that knowing whether to use 'part' or 'page' would dep= end on a detailed understanding of the media type of the retrieved represen= tation, which the average creator of a citation is unlikely to have. ------------- Some of this is corrigible, but only at the expense of a vast increase in d= etail and clarity. Others not-so-much, insofar as so much is _necessarily_= left underspecified, to allow for _anything_ to be considered as an archiv= e ('archive-id' value), with the consequent requirement to allow for arbitr= arily idiosyncratic internal naming mechanisms ('archived-item' value). I'm curious in this connection to wonder if we actually have any URN namesp= aces where assignment is done "independently but following an algorithm tha= t itself guarantees uniqueness"? Ah, there are registrations for urn:uuid:= , which qualifies, and urn:oid:, which sort of does. OK, is there such a n= amespace in active use? Which provides for resolution, at least in princip= le? A crucial point here is that in the OID case a urn:oid:... carries a chain = of responsibility with it. If you run across one, you know how to find out= who takes responsibility for every level in the tree that's involved in in= terpreting it. In the UUID case, a urn:uuid: doesn't travel well/at all, s= o the question doesn't arise. But for PWIDs, if I find one I have _no way_= to figure out who's responsible, or whom I can ask for clarification, or w= hom to blame if it doesn't appear to 'work'. ---------------- I don't see what the intended value of the discussion of the "SOLR-Wayback = tool" is for the spec. *Interoperability* The above comments about ambiguity/lack of identity apply here too: if diff= erent implementors interpret e.g. a coverage-spec of 'subsite' differently, their resolvers will not interoperate. *Resolution* None of this is very much to the point. In particular, it completely ignor= es the precedents set by doi.org, identifiers.org and n2t.net (https://doi.org/10.1038/sdata.2018.95 exemplifies the first and its conten= t discusses the second and third).=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In conclusion, I think a useful way to think about this proposal is as a mi= sguided attempt to define a urn type which _is_ a citation. This makes sen= se of PWID's 3rd party nature, and clarifies that the archive-id and -time,= the embedded URI and the coverage spec are just a pretty arbitrary, certai= nly impoverished, subset of what you would expect to find in a _real_ citat= ion. Trying to pack a citation into a URN just doesn't make sense to me. N= either does trying to determine exactly the _right_ subset of citations of = web-hosted resources to pack up in order to be both useful and unambiguous. (There is work underway in various venues (see e.g. [1]) to _objectify_ cit= ations and give PIDs to _those_, which might address at least some of the g= oals of this work.) ht [1] http://sched.co/DJ3P --=20 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 _al= ways_ has a .sig like this -- mail without it is forged spam] _______________________________________________ urn mailing list urn@ietf.org https://www.ietf.org/mailman/listinfo/urn From nobody Fri Aug 10 18:54:54 2018 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 99457130DD7 for ; Fri, 10 Aug 2018 18:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 MrlvxdwF1Q9r for ; Fri, 10 Aug 2018 18:54:49 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (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 25F1A130DC0 for ; Fri, 10 Aug 2018 18:54:48 -0700 (PDT) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id oIPBf8Jc9eU63oJ79ftlsF; Sat, 11 Aug 2018 01:54:47 +0000 Received: from hobgoblin.ariadne.com ([24.91.37.100]) by resomta-ch2-06v.sys.comcast.net with ESMTPA id oJ78fVAqVOJARoJ78fnECg; Sat, 11 Aug 2018 01:54:47 +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 w7B1sjLH010272; Fri, 10 Aug 2018 21:54:45 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w7B1shid010268; Fri, 10 Aug 2018 21:54:43 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Eld Zierau Cc: juha.hakala@helsinki.fi, ht@inf.ed.ac.uk, urn@ietf.org In-Reply-To: (elzi@kb.dk) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 10 Aug 2018 21:54:43 -0400 Message-ID: <8736vlfz18.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfEAeQEBImwqksdnnuKGkebpTn2XO41WiniQDgvu9ghHEJW810s1vsHmOgIJC3LoEsbt/ivyKeSodzKLTvsBbRkG8ldnrUgWwgevi8I9MvhoLNa0N0pqH mZ261fYcZi2HUVlKGTUFrCjOkW6N1CgzVsuVXLSfoJm+iK1SoBUtrLuCyznPnk9Y6bU4lNqS8IJZkQvI5ZkuoNKsBtewlb3Mldr1SPkcwidtRGEgUi/E6BeG d1LE2mtFM3wzax6VijigmA== Archived-At: Subject: Re: [urn] Suggested PWID URN for Persistent Web IDentifiers - version 3 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2018 01:54:52 -0000 Eld Zierau writes: > Dale R. Worley worley@ariadne.com writes: > > A major component of pwid-urn is archive-id. My assumption is that > > the archive-id is the top-level component and defines what abstract > > "archive" the URN is a reference into. And that the "archive" > > defines the exact interpretation of archival-tine, coverage-spec, > > and archived-item. However, in order for PWID URNs to be > > unambiguous, it must be unambiguous what "archive" a given > > archive-id refers to. The draft suggests "it is recommended to use > > the web domain as the identifier for the web archive". > > > > What if an institution decides to create PWID URNs that use an > > archive-id which is a domain name that the institution does not own? > > As written, the draft does not forbid *me* from creating PWID URNs > > with archive-id "netarkivet.dk". > > -- Eld: I think there is a misunderstanding here - it is not the > archive that chooses the archive name, it is the creator of the > reference, - and that is why it is recommended to use the domain > name. If you are forced to say "it is not the archive that chooses the archive name", then I suggest that the "archive name" is not actually the name *of the archive*, but an identifier of some other entity. When you say "the domain name" here, *of what* is it the domain name? Do you mean "the archive's domain name", or "the domain name of the creator of the reference"? > It would be best to have a formal registry, but I have to start > somewhere, - and with the domain name it is possible to find a > reference to any existing web archive (restricted access or > not). Within the next 5-10 years, I think there will be evidence > enough (e.g. from web archives) to reconstruct a registry in case > there are web archives changing domains within that period. I will > definitely work on having such a registry formerly established. You seem to be describing how you expect these URNs to be processed, but it is not clear to me what the process is. Can you describe how this process works, starting with "I am looking at a PWID URN" and continuing to the point where "I have discovered the particular archive in question". (I assume that after that point, looking up the resource in the archive's index is straightforward, at least conceptually.) > > archived-item can be a URI, and a URI can contain the characters '?', > > '#', '[', and ']', among others. However, those 4 characters may not > > appear in the NSS part of a URN. Note that the first 2 of these > > characters are used in URIs only to introduce the "query" and > > "fragment" parts, but as the draft is written, the archived-item URI > > is not restricted to not having a query or fragment part. > -- Eld: that is a problem if the archived URI does have fragments Yes, it is a problem. But your specification allows the archived URI to have fragments, because it refers to URIs but does not forbid them to have fragment parts. How do you propose to resolve this contradiction? Dale From nobody Mon Aug 13 03:44:18 2018 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 2FA38130DBE for ; Mon, 13 Aug 2018 03:44:16 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 h7GVSMFeq9GR for ; Mon, 13 Aug 2018 03:44:11 -0700 (PDT) Received: from smtp-out12.electric.net (smtp-out12.electric.net [89.104.206.33]) (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 A0F0E127598 for ; Mon, 13 Aug 2018 03:44:11 -0700 (PDT) Received: from 1fpAKW-000o5r-U2 by out12d.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fpAKW-000o9N-Vk; Mon, 13 Aug 2018 03:44:08 -0700 Received: by emcmailer; Mon, 13 Aug 2018 03:44:08 -0700 Received: from [130.226.226.11] (helo=post.kb.dk) by out12d.electric.net with esmtp (Exim 4.90_1) (envelope-from ) id 1fpAKW-000o5r-U2; Mon, 13 Aug 2018 03:44:08 -0700 Received: from EXCH-02.kb.dk (exch-02.kb.dk [10.5.0.112]) by post.kb.dk (Postfix) with ESMTP id 4450E91F59; Mon, 13 Aug 2018 12:44:08 +0200 (CEST) Received: from EXCH-02.kb.dk (10.5.0.112) by EXCH-02.kb.dk (10.5.0.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1415.2; Mon, 13 Aug 2018 12:44:07 +0200 Received: from EXCH-02.kb.dk ([fe80::b595:1a1f:5666:b29]) by EXCH-02.kb.dk ([fe80::b595:1a1f:5666:b29%7]) with mapi id 15.01.1415.002; Mon, 13 Aug 2018 12:44:07 +0200 From: Eld Zierau To: "Dale R. Worley" CC: "juha.hakala@helsinki.fi" , "ht@inf.ed.ac.uk" , "urn@ietf.org" Thread-Topic: [urn] Suggested PWID URN for Persistent Web IDentifiers - version 3 Thread-Index: AQHUMRZFkm3uj4RtRcGB26kVRboqjKS9WtSA Date: Mon, 13 Aug 2018 10:44:07 +0000 Message-ID: References: (elzi@kb.dk) <8736vlfz18.fsf@hobgoblin.ariadne.com> In-Reply-To: <8736vlfz18.fsf@hobgoblin.ariadne.com> Accept-Language: da-DK, en-US Content-Language: da-DK X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.226.229.95] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-IP: 130.226.226.11 X-Env-From: elzi@kb.dk X-Proto: esmtp X-Revdns: post-03.kb.dk X-HELO: post.kb.dk X-TLS: X-Authenticated_ID: X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) X-PolicySMART: 10573177 Archived-At: Subject: Re: [urn] Suggested PWID URN for Persistent Web IDentifiers - version 3 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 10:44:16 -0000 See my comments below - (marked with "--") Best regards, Eld -----Original Message----- From: Dale R. Worley =20 Sent: Saturday, August 11, 2018 3:55 AM To: Eld Zierau Cc: juha.hakala@helsinki.fi; ht@inf.ed.ac.uk; urn@ietf.org Subject: Re: [urn] Suggested PWID URN for Persistent Web IDentifiers - vers= ion 3 Eld Zierau writes: > Dale R. Worley worley@ariadne.com writes: > > A major component of pwid-urn is archive-id. My assumption is that=20 > > the archive-id is the top-level component and defines what abstract=20 > > "archive" the URN is a reference into. And that the "archive" > > defines the exact interpretation of archival-tine, coverage-spec,=20 > > and archived-item. However, in order for PWID URNs to be=20 > > unambiguous, it must be unambiguous what "archive" a given=20 > > archive-id refers to. The draft suggests "it is recommended to use=20 > > the web domain as the identifier for the web archive". > > > > What if an institution decides to create PWID URNs that use an=20 > > archive-id which is a domain name that the institution does not own? > > As written, the draft does not forbid *me* from creating PWID URNs=20 > > with archive-id "netarkivet.dk". >=20 > -- Eld: I think there is a misunderstanding here - it is not the=20 > archive that chooses the archive name, it is the creator of the=20 > reference, - and that is why it is recommended to use the domain name. If you are forced to say "it is not the archive that chooses the archive na= me", then I suggest that the "archive name" is not actually the name *of th= e archive*, but an identifier of some other entity. -- Eld: If it says 'archive name' anywhere, it should be corrected - it is = an identifier we are taking about. When you say "the domain name" here, *of what* is it the domain name? Do you mean "the archive's domain name", or "the domain name of the creator= of the reference"? -- Eld: the domain name of the archive - it is to identify in which archive= you can find the resource in - I actually realized that it should say top = level domain name of the web archive.=20 > It would be best to have a formal registry, but I have to start=20 > somewhere, - and with the domain name it is possible to find a=20 > reference to any existing web archive (restricted access or not).=20 > Within the next 5-10 years, I think there will be evidence enough=20 > (e.g. from web archives) to reconstruct a registry in case there are=20 > web archives changing domains within that period. I will definitely=20 > work on having such a registry formerly established. You seem to be describing how you expect these URNs to be processed, but it= is not clear to me what the process is. Can you describe how this process= works, starting with "I am looking at a PWID URN" and continuing to the po= int where "I have discovered the particular archive in question". (I assum= e that after that point, looking up the resource in the archive's index is = straightforward, at least conceptually.) -- Eld: It is indirectly described under resolution, - but it is a good poi= nt that there should be a construction as well. This would be: -- PWID URNs can be constructed in different ways. In case a single refere= nce is wanted, it can be created by having/finding/creating the wanted arch= ived resource and then construct the PWID URN from that. Or it can be creat= ed for a collection by using tooling producing PWIDs. -- In the first case, there can be three situations where the creator of th= e reference: -- * already has the resource from a web archive that the creator wants to= reference -- * finds resource from a web archive by using tools like Memento and cho= ses the exact web resource to reference from a specific archive -- * creates a resource by asking a web archive/citation service to archiv= e a live URI, and afterwards verifies the reference in the web archive -- In these three cases the PWID URN is constructed by filling out the PWID= URN pattern=20 -- urn:pwid:::: -- By setting=20 -- The to the top level domain of the web archive holding the = reference. For open web archives like Internet Archive's publicly available= web archive collection (with current wayback on https://web.archive.org/) = the top level domain is archive.org. For web archives with restricted acce= ss, choose the top level domain for where the web archive is publicly descr= ibed, e.g. the Danish web archive is described on http://netarkivet.dk/in-e= nglish/ which has the top level domain netarkivet.dk. -- The (on the form described in the syntax and given as UT= C time) to the archival time for the selected web archive resource. In some= wayback solutions, this archival time can be found in the online URI for t= he resource, e.g. in the online URL for an archived version of https://tool= s.ietf.org/html/rfc3986: https://web.archive.org/web/20180418152929/https:/= /tools.ietf.org/html/rfc3986, the archival time is represented in the long = number 20180418152929, where year is the first four digits, month the next = two digits etc. In other Wayback solutions or web archive interfaces the ar= chival date is given as part of the metadata for the web resource. -- The to what the creator of the reference wants the refer= ence to cover, e.g. page or subsite. The to the URI that is archived, which means what the web ar= chive has registered as the archived URI. For URIs that still exists online= , the online URI and the archive URI will usually be the same. However, the= re are case (e.g. for redirects) where they differ. For instance for archiv= e.is archived in archive.org on 2018-01-06T14:08:01 UTC is archived wiith t= he archived URI: http://archive.is:80. -- An example of constructing an PWID URI for https://web.archive.org/web/2= 0180418152929/https://tools.ietf.org/html/rfc3986 would therefore be -- =3D archive.org (to level domain of web.archive.org) -- =3D 2018-04-18T15:29:29Z (deduced from 20180418152929 wh= ich is always UTC time) -- =3D webpage (depends on style sheets references. In case= the creator of the reference wants to indicate that the contents is covere= d fully on this reference without dependencies to calculation of dependenci= es, he/she could choose to say part, - although this may result in a resolu= tion of the html depending on the resolution tool) -- =3D https://tools.ietf.org/html/rfc3986 -- Which results in the PWID URN:=20 -- urn:pwid:archive.org:2018-04-18T15:29:29Z:webpage:https://tools.ietf.or= g/html/rfc3986 > > archived-item can be a URI, and a URI can contain the characters=20 > > '?', '#', '[', and ']', among others. However, those 4 characters=20 > > may not appear in the NSS part of a URN. Note that the first 2 of=20 > > these characters are used in URIs only to introduce the "query" and=20 > > "fragment" parts, but as the draft is written, the archived-item URI=20 > > is not restricted to not having a query or fragment part. > -- Eld: that is a problem if the archived URI does have fragments Yes, it is a problem. But your specification allows the archived URI to ha= ve fragments, because it refers to URIs but does not forbid them to have fr= agment parts. How do you propose to resolve this contradiction? -- Eld: I will certainly make the reader aware of it, e.g. by writing: -- "It should be noted that a valid URN is not allowed to contain the chara= cters ?', '#', '[', and ']'. Therefore, PWID URNs for archived URIs cannot = be constructed as legal URNs when following the instructions given." -- Eld: I would like to discuss different alternative: -- 1: we can just leave it like that - which means that that valid PWID URN= s cannot cover these cases. - In all cases the PWID URN will be a huge step= forward, and cover about 80-95% of all cases. In this case, it will be up = to the users if they construct them anyway - just like the web archives onl= ine URIs are not valid URIs since they contain "//" as part of the path. -- 2: we can consider encoding of these characters (which will complicate t= hings a bit) Dale From nobody Tue Aug 14 12:20:31 2018 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 9E7CE130E14 for ; Tue, 14 Aug 2018 12:20:29 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 3hGT2Nktihka for ; Tue, 14 Aug 2018 12:20:26 -0700 (PDT) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E496124BE5 for ; Tue, 14 Aug 2018 12:20:25 -0700 (PDT) Received: by mail-io0-x242.google.com with SMTP id m4-v6so18336126iop.3 for ; Tue, 14 Aug 2018 12:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=vX6Ker+EOHligwLaNgt+Oga1pzfknR6xaWHdefT1y0Y=; b=YrLu26sp/lj0vgGsO6OOPQki81q/lu6jPO3DN0FZXXstwCxT9IS4wc84aJFCdgWu1L ZiS6mmruu7uN120QOmTYifC0wYEFjHsbqvs2A0nyHLwrTtcd96OL/3phm04+9WWJlXxn xNRLm2kfruNZPnmLF7n2lp5Z2czz3+2c/WdL4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=vX6Ker+EOHligwLaNgt+Oga1pzfknR6xaWHdefT1y0Y=; b=iyTQlU4b7IW5XbQw0zQjOPZeQsTiRQpceRa6mx0mWG9qiPC9+8iJHFgHMQAE+eMHmP U+gNnp5/+4NEJCJvxsSWKHMRg3qt0kmOORLVVetg7kTWfiyZrMzIjPU2BYgaS+D7CW1q oM6BUiidvyMy7qAHSwhNDlRTGzLrYCD9vG3GwLRq5jSOgwI6mjQzm7uZ6f7eD7DUKfd4 LJrhjZkpA0RuGuG/kUIYUdeb9yq0q5AkoXKAT4JB18mZutRWTlDvpYXR9UtF/8fHbot/ 2U31QLzHx57UNtX3Lg89vthtq3sUXvma/eRFYhj+bC9LybYmaVnwMhA+8IWV6Md7JNXg ptxw== X-Gm-Message-State: AOUpUlHlgArVTAbPTLO0vf/liWiDcDDmHGkypSMqhZSjatYq3n0EXjqA b8fI6Q5xzPf2+HV7H/R70E+FpA== X-Google-Smtp-Source: AA+uWPzpyaEYnsEEjXA/NA4Nq51LdQ4lb8CPnGlDcorRgsMT2RhY0MTfWLGQ4ljQYNELuwNgGQDE0g== X-Received: by 2002:a6b:920b:: with SMTP id u11-v6mr15255077iod.287.1534274425185; Tue, 14 Aug 2018 12:20:25 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id k194-v6sm4112275itb.30.2018.08.14.12.20.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Aug 2018 12:20:24 -0700 (PDT) To: "Svensson, Lars" , "urn@ietf.org" References: <87fu1yhwlk.fsf@hobgoblin.ariadne.com> <241B7429-246F-4D13-9402-393315B4727A@gmail.com> <6D608C59-3032-494C-92F8-959FA5D4CA91@gmail.com> <48eaed30-d3a0-fa81-da88-8759d795978a@mozilla.com> <17e4d21c533440a48bd0e1459ab5f48a@dnb.de> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: <55ac5694-a235-34b4-a49f-9fe9deb350f7@mozilla.com> Date: Tue, 14 Aug 2018 13:20:23 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <17e4d21c533440a48bd0e1459ab5f48a@dnb.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="umUjdwe8dp2gi4gojylos3shlJ4SXuX8K" Archived-At: Subject: Re: [urn] [Marketing Mail] Re: New Version Notification for draft-mahesh-etsi-urn-03.txt (Was Re: URN expert review of 'etsi' NID) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 19:20:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --umUjdwe8dp2gi4gojylos3shlJ4SXuX8K Content-Type: multipart/mixed; boundary="gHQMV6oiXnZhwultSYWePUI9OFqxU8IQj"; protected-headers="v1" From: Peter Saint-Andre To: "Svensson, Lars" , "urn@ietf.org" Message-ID: <55ac5694-a235-34b4-a49f-9fe9deb350f7@mozilla.com> Subject: Re: [Marketing Mail] Re: [urn] New Version Notification for draft-mahesh-etsi-urn-03.txt (Was Re: URN expert review of 'etsi' NID) References: <87fu1yhwlk.fsf@hobgoblin.ariadne.com> <241B7429-246F-4D13-9402-393315B4727A@gmail.com> <6D608C59-3032-494C-92F8-959FA5D4CA91@gmail.com> <48eaed30-d3a0-fa81-da88-8759d795978a@mozilla.com> <17e4d21c533440a48bd0e1459ab5f48a@dnb.de> In-Reply-To: <17e4d21c533440a48bd0e1459ab5f48a@dnb.de> --gHQMV6oiXnZhwultSYWePUI9OFqxU8IQj Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable During discussion with IANA, Lars noticed that the "Security and Privacy" section of the template says: If an namespace is URN-equivalent to another namespace used by the device, as per the rules specified in Section 3.1 of URNs [RFC8141], Section 6.1 of URI Generic Syntax [RFC3986], and the lexical rules specified in this document, the request is rejected. It would be helpful to clarify what kind of request is involved here (presumably a configuration or management request using YANG, but let's make that explicit). Also, the "Purpose" section says "the URN" in two places, but that should be "the URN namespace". The "Declaration of syntactic structure" section doesn't seem to reflect the structure of the examples (e.g., "urn:etsi:yang:etsi-services"). Do you foresee having additional "sub-identifiers" other than "yang"? Finally, draft-mahesh-etsi-urn-03 uses the old template from RFC 3406, but IANA requires that registrations use the new template from RFC 8141. Thanks! Peter On 6/14/18 9:22 AM, Svensson, Lars wrote: > Apart from what Peter already said, I have no further comments on this = draft, as far as I'm concerned we're ready to proceed. >=20 > Best, >=20 > Lars >=20 >> -----Original Message----- >> From: urn [mailto:urn-bounces@ietf.org] On Behalf Of Peter Saint-Andre= >> Sent: Thursday, June 14, 2018 2:57 AM >> To: urn@ietf.org >> Subject: [Marketing Mail] Re: [urn] New Version Notification for draft= -mahesh-etsi- >> urn-03.txt (Was Re: URN expert review of 'etsi' NID) >> >> Thanks, Mahesh, that is helpful. >> >> I'm still not sure if we want to make a normative reference to RFC 173= 7 >> (an Informational RFC from 1994) in the Security Considerations sectio= n; >> do you feel that it discusses issues that we left out of RFC 8141? >> >> Other than that, the document looks ready to proceed. >> >> Peter >> >> On 6/13/18 5:18 PM, Mahesh Jethanandani wrote: >>> ETSI has now published a web page that is publicly available and >>> describes the two questions outlined below. Please let us know if the= re >>> are any questions. >>> >>> https://portal.etsi.org/PNNS/GenericAllocation/ETSIURNNamespace.aspx >>> >>> Thanks. >>> >>> On Jun 8, 2018, at 8:18 PM, Mahesh Jethanandani >> > wrote: >>> >>>> The following update to the draft addresses the comments raised as >>>> part of expert review. The remaining action items are for us to make= >>>> available a public version of the ancillary document, whose URL was >>>> provided in the draft, that describes: >>>> >>>> - the NSS namespace and how it will be allocated by ETSI >>>> - how a separate =E2=80=9Croot=E2=80=9D namespace under the allocate= d URN can be used >>>> for experimental namespaces. >>>> >>>> Thanks >>>> --------------------------------------------------- >>>> >>>> A new version of I-D, draft-mahesh-etsi-urn-03.txt >>>> has been successfully submitted by Mahesh Jethanandani and posted to= the >>>> IETF repository. >>>> >>>> Name:draft-mahesh-etsi-urn >>>> Revision:03 >>>> Title:URN Namespace for ETSI Documents >>>> Document date:2018-06-08 >>>> Group:Individual Submission >>>> Pages:6 >>>> URL: >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ht= tps://www.ietf.org/internet-drafts/draft-mahesh-etsi-urn-03.txt >>>> Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://data= tracker.ietf.org/doc/draft-mahesh-etsi-urn/ >>>> Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org= /html/draft-mahesh-etsi-urn-03 >>>> Htmlized: >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc= /html/draft-mahesh-etsi-urn >>>> Diff: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ht= tps://www.ietf.org/rfcdiff?url2=3Ddraft-mahesh-etsi-urn-03 >>>> >>>> Abstract: >>>> =C2=A0=C2=A0This document describes the Namespace Identifier (NID) '= etsi' for >>>> =C2=A0=C2=A0Uniform Resource Names (URNs) used to identify resources= published by >>>> =C2=A0=C2=A0European Telecommunications Standards Institute (http://= etsi.org). >>>> =C2=A0=C2=A0ETSI specifies and manages resources that utilize this U= RN >>>> =C2=A0=C2=A0identification model. =C2=A0Management activities for th= ese and other >>>> =C2=A0=C2=A0resources types are handled by the manager of the ETSI P= rotocol >>>> =C2=A0=C2=A0Naming and Numbering Service (PNNS). >>>> >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at=C2=A0tools.ietf= =2Eorg >>>> . >>>> >>>> The IETF Secretariat >>>> >>>>> On Jun 7, 2018, at 6:53 PM, Dale R. Worley >>>> > wrote: >>>>> >>>>> Comments on draft-mahesh-etsi-urn-02 >>>>> >>>>> =C2=A0=C2=A01.1. =C2=A0Terminology >>>>> >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| PNNS =C2=A0=C2=A0=C2=A0| Prot= ocol Name and Numbering Service =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| >>>>> >>>>> It would be helpful to state that PNNS is an ETSI function: >>>>> >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| PNNS =C2=A0=C2=A0=C2=A0| ETSI= Protocol Name and Numbering Service =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0| >>>>> >>>>> =C2=A0=C2=A0Declaration of syntactic structure: >>>>> >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0The syntax of namespace specific stri= ngs for the 'etsi' namespace >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0is in Uniform Resource Names (U= RNs) [RFC8141]. >>>>> >>>>> This is completely legitimate, but it is not satisfying. =C2=A0If E= TSI has >>>>> plans for how it will organize the space of NSSs, it would be nice = to >>>>> describe them here. >>>>> >>>>> =C2=A0=C2=A0Relevant ancillary documentation: >>>>> >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ETSI publishes information regarding = the registered resources in >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the ETSI URN Namespace (EUN) registry= >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(https://portal.etsi.org/PNNS/Generic= Allocation/ >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ETSIURNNamespace.aspx). >>>>> >>>>> It's good that ETSI gives the URL of its URN registry; many other >>>>> organizations do not. =C2=A0However, I notice that that URL is >>>>> password-protected. =C2=A0It would be much better for the community= if the >>>>> registry was readable by the world, since there is no stated intent= ion >>>>> that etsi URNs are used only within a closed community. >>>>> >>>>> =C2=A0=C2=A0Identifier uniqueness considerations: >>>>> >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[...] =C2=A0ETSI is expected to guara= ntee the uniqueness [...] >>>>> >>>>> Formally, this registration is being submitted by ETSI, so it reads= >>>>> oddly for ETSI to say "ETSI is expected...". =C2=A0=C2=A0Much bette= r would be >>>>> "ETSI will...". >>>>> >>>>> Similarly, "ETSI could..." is used where it is more natural to say = "ETSI >>>>> may...". >>>>> >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Note that using experimental types ma= y create >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0collision as multiple users may use t= he same values for different >>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0resources and specific strings. >>>>> >>>>> It would be very helpful if the registration stated how the ETSI >>>>> registry will make clear how to recognize experimental URIs within = the >>>>> etsi namespace. >>>>> >>>>> Dale >>>> >>>> Mahesh Jethanandani >>>> mjethanandani@gmail.com >>>> >>> >>> >>> _______________________________________________ >>> urn mailing list >>> urn@ietf.org >>> https://www.ietf.org/mailman/listinfo/urn >>> >=20 --gHQMV6oiXnZhwultSYWePUI9OFqxU8IQj-- --umUjdwe8dp2gi4gojylos3shlJ4SXuX8K Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAltzK3cACgkQZWGMGH9o FKm11xAA60/6thL2fzbANBczpv8iWgMxIuG1GBHLsIOp8kAarvV5Kb9mf7W+5qLZ 7CdMge7KhGq1bgBJP+JCk2YMOe9W2MWzxe4SaswrcbSCb1+R3pk2KGPe/UC77u1F Is3aGHH/r8ywEM9efMb3u8IoOCVupEi+lEGvkPlQwSmEVm5dlUhc6sTdH+t/nr+D EXjhAmFmzvtZtJsVWQLWMt1OBBTjxNSpAolWH7gfUWT26cDcYwKkeRm6QPblPUf7 YRYXAJGTX185xVZS2Sh8ZFoWvKqwbxXJtWYM0I1PY/eG8QcqjvXL9802MovjsWzr L5aduh6KN98GcgUgJasWEHS0srAn8dzSR5GazFzHBiDUxqW6Yq9aWSCKkOa85J6b yW8ZwsfHE3FxudsTeftcGSrZI+PbjP7uMoZ4sTb/o19vI0GV5+R1f7CHFUkr/aic T1TUvSlSJmsJscM8A5E2oAx7WTODV1ZqZlolj2/6aMKWoHSjFtWvtvmS2wA6cRgC jAM62wOQCLW1VUw7wgk1MDNRTJhZpu+jhax+k4kpkaJB7A92/Nraqp1vYkH5YQIY hJxO0iYB8PyQYO2OWAFgGPolvOCAcLRaGC8mietIJ2mjBc3BdK+C5UNhk9NBDLeG 1Aray+epkvMZ7F1aRRohczVCCUnkxRo2Q8tqhZbnKITj6b51HxY= =+M+U -----END PGP SIGNATURE----- --umUjdwe8dp2gi4gojylos3shlJ4SXuX8K-- From nobody Tue Aug 28 15:55:12 2018 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 04473130E1F for ; Tue, 28 Aug 2018 15:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 VjCZKMB1MsuH for ; Tue, 28 Aug 2018 15:55:08 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244A9130E0C for ; Tue, 28 Aug 2018 15:55:08 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id h23-v6so4736069ita.5 for ; Tue, 28 Aug 2018 15:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:references:to:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=6/YAA7BFrCJGluJ1zJ/9YvhntD+OJdwEvH8wbd+oKHU=; b=KpEPtsVrAYls59xio6K78hfWGR0bQeAHAD2hFTBKJfpuX5XePXe5X8COPHkygjJV7S 4gy0zLcMv7vgZd4ugSxCL2pFJo86ZV9L655ip9s8BCFglSq19jScAPQVoh9OzufYezmf OYhsHjEqXBYW7gST7hzQXd5NooZV1+2zqjoWw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=6/YAA7BFrCJGluJ1zJ/9YvhntD+OJdwEvH8wbd+oKHU=; b=JvYf7/tWLPLOq7S1pJTnOPzChLPtCWV/RQRAevesa2CPCbtJ61rZ0aj9mBqkwEjjMt uU+c93ivIQpY3Zj4Sk8xBbfyd5Q/KRqo6djrrMJIaLGXtz3DYitA7vkZ4GOMz+Dqqmbo vriOFL0yz7c3RbSKN2J8GfMNPvKhMARU9ERjwEqBPN/ekwUrYZZ8pw9ivf3iTqRcP5/y RhEmK59Khb27JM74VivLnX7zbqyihoURaEac0dqr4j6iur3svHdp8Pu85boz8djgVTMe YURGv38kvi7RRWyHFEgLPoHAYSy1d/4/0LaeCjnlE5NlU/gMjf8B6Zjd3grBE5xBxPmH bDbw== X-Gm-Message-State: APzg51DOKpQ88NI/lTp2lnygzJFFfSx0qa3qds+UI+iriHuj2TihVZfi 7EgtPhZObnFQx1BnPr60nCL//Q== X-Google-Smtp-Source: ANB0VdbPc3QbW2mUICg3O8eIzFO4jtnS1QTAjJhg9OCtW+X/auePFNNhleVfL4+rQK+L6d1prvMW+Q== X-Received: by 2002:a24:4597:: with SMTP id c23-v6mr3204241itd.91.1535496907359; Tue, 28 Aug 2018 15:55:07 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id p142-v6sm1201097itp.30.2018.08.28.15.55.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Aug 2018 15:55:06 -0700 (PDT) References: <20180827190231.75379B80C3A@rfc-editor.org> To: "urn@ietf.org" From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= xsFNBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABzSdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT7CwZQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekM7BTQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAcLBfAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V X-Forwarded-Message-Id: <20180827190231.75379B80C3A@rfc-editor.org> Message-ID: <0bd8136a-7376-db60-accf-d566e4ef0d7e@mozilla.com> Date: Tue, 28 Aug 2018 16:55:05 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180827190231.75379B80C3A@rfc-editor.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kcmcHzQWrsYaMYw4PEnTuy7IWEb38pQX4" Archived-At: Subject: [urn] Fwd: [rfc-dist] RFC 8433 on A Simpler Method for Resolving Alert-Info URNs X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 22:55:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kcmcHzQWrsYaMYw4PEnTuy7IWEb38pQX4 Content-Type: multipart/mixed; boundary="o4BFoIyR1TXrzjZysvnO5rqHPX6a2OZy6"; protected-headers="v1" From: Peter Saint-Andre To: "urn@ietf.org" Message-ID: <0bd8136a-7376-db60-accf-d566e4ef0d7e@mozilla.com> Subject: Fwd: [rfc-dist] RFC 8433 on A Simpler Method for Resolving Alert-Info URNs References: <20180827190231.75379B80C3A@rfc-editor.org> In-Reply-To: <20180827190231.75379B80C3A@rfc-editor.org> --o4BFoIyR1TXrzjZysvnO5rqHPX6a2OZy6 Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Perhaps of interest here... -------- Forwarded Message -------- Subject: [rfc-dist] RFC 8433 on A Simpler Method for Resolving Alert-Info URNs Date: Mon, 27 Aug 2018 12:02:31 -0700 (PDT) From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: drafts-update-ref@iana.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 8433 Title: A Simpler Method for Resolving Alert-Info URNs Author: D. Worley Status: Informational Stream: Independent Date: August 2018 Mailbox: worley@ariadne.com Pages: 45 Characters: 89902 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-worley-alert-info-fsm-10.txt URL: https://www.rfc-editor.org/info/rfc8433 DOI: 10.17487/RFC8433 The "alert" namespace of Uniform Resource Names (URNs) can be used in the Alert-Info header field of Session Initiation Protocol (SIP) requests and responses to inform a voice over IP (VoIP) telephone (user agent) of the characteristics of the call that the user agent has originated or terminated. The user agent must resolve the URNs into a signal; that is, it must select the best available signal to present to its user to indicate the characteristics of the call. RFC 7462 describes a non-normative algorithm for signal selection. This document describes a more efficient alternative algorithm: a user agent's designer can, based on the user agent's signals and their meanings, construct a finite state machine (FSM) to process the URNs to select a signal in a way that obeys the restrictions given in the definition of the "alert" URN namespace. INFORMATIONAL: This memo provides information for the Internet community.= It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ rfc-dist mailing list rfc-dist@rfc-editor.org https://www.rfc-editor.org/mailman/listinfo/rfc-dist http://www.rfc-editor.org --o4BFoIyR1TXrzjZysvnO5rqHPX6a2OZy6-- --kcmcHzQWrsYaMYw4PEnTuy7IWEb38pQX4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAluF0skACgkQZWGMGH9o FKn9og//bbNXbVeD3VXvasl9lNDljaT6f26V9yYvqrPmXnBwJwRIq+Ax1/6dn4Tq FrNH6IaCl66e4oueqncj/yviK4VpHAzbHXAQeWxSnLM18vPiZQ3uqMKGcQ8Y/3gp SNuDFRHmkceJbjumomW0wwpMPVgp90ND4o3tqWyDN9Dmoiu2d2M+/B0WMRdInEbl kM5JKN+HKUwVtV7plEJiz3evTN6CR0MjwMWfb7h3ykeDQLEf14yvAqMNuYN6uDny 0NeE4BRvWWMcONGOYEJFzzTAvp3/AQ+H4ZiWUZ3u+qRyuxykOOf5Ix7zGJSG9jAS xGyRiiz4p/meuesbj3VJVUDrTIOC1wyyFiSLqF8DAOLckEy5alMSM6k+E3rm9Sxx J7S0S5kucz0u4uKnruxBhgreZbm4WuircmbJEqt3ZEtiEw/QGNctTLfVmPL0MEx8 mAu0/R5SD8yCbgfeAokNi30rm2z8/FcJdxS/8Q0dvCgDRGj36eM3kNnOWPho6lag AQQhR7C3G22oJ0FMoM9ypPV+KcgG4UZgJ1GKk2nTgxCGjPAEnYlZ0nezwnNo6uQi U/JPSR9QyhpGLoDv27ZjfN3eG+6JkyeNiBBeiUTkJA1kd5jI/wlZ/8xhgusrhHml rzqVx0QFdm+i5Rvr2DygZg8wYeiyJlJNangwEdZmrQoqbUpuYbw= =eyB5 -----END PGP SIGNATURE----- --kcmcHzQWrsYaMYw4PEnTuy7IWEb38pQX4--