From owner-urn-ietf@LISTS.NETSOL.COM Sun Dec 3 16:11:56 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06834 for ; Sun, 3 Dec 2000 16:11:56 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id QAA24922; Sun, 3 Dec 2000 16:10:21 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8666649 for URN-IETF@LISTS.NETSOL.COM; Sun, 3 Dec 2000 16:08:30 -0500 Received: from albatross.prod.itd.earthlink.net (albatross.prod.itd.earthlink.net [207.217.120.120]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id QAA24913 for ; Sun, 3 Dec 2000 16:08:28 -0500 (EST) Received: from mantiscorp.com (ip214.boston5.ma.pub-ip.psi.net [38.26.109.214]) by albatross.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id NAA15957; Sun, 3 Dec 2000 13:02:14 -0800 (PST) X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <3A15B5B0.8BF705F3@thinkingcat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: "Aaron E. Walsh" Message-ID: <3A2AB5BB.258CEBD3@mantiscorp.com> Date: Sun, 3 Dec 2000 16:06:03 -0500 Reply-To: "Aaron E. Walsh" From: "Aaron E. Walsh" Organization: Mantis Development Corp. Subject: Re: Related BoFs To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Hi Leslie and Michael, thanks for the headsup on the content/caching/resolution BoFs. Is there a specific list or reflector where this discussion is taking place? I couldn't make the San Diego f2f, but would like to participate in the conversation if it's not on this list. Regards, Aaron -- ------------------------------------------------------------------- Aaron E. Walsh http://www.mantiscorp.com/people/aew/ 617.350.7119 ------------------------------------------------------------------- Leslie Daigle wrote: > > Howdy, > > FYI, I draw your attention to the various content/caching/resolution > bofs to be held in San Diego on Tuesday afternoon. > > In particular, this one tackles something of the converse of URN > (global) resolution, and is currently scheduled for Tuesday, 5pm-6pm. > > Leslie. > > -----------8<----------------8<----------------8<-------------- > > Contextualization of Resolution BOF (c15n) > > Day, Date at Time > ============================== > > CHAIR: Michael Mealling > > DESCRIPTION: > > The URN WG's Dynamic Delegation Discovery System (DDDS) describes a > generalized architecture for 'top down' resolution of identifiers such > as URIs. This works well when a (software) client wants or needs to > dynamically determine the explicit authoritative delegation of > resolution. However, there are times when it is desirable to > incorporate other elements of contextual control information in > determining, for example, the "appropriate copy" of a resource -- > preferrentially finding a "local" copy of a journal rather than > (re)purchasing one from the authoritative publisher. This is generally > applicable to all URI resolution, but it is more specific than "web > caching". Software systems being built to solve this in today's > deployed systems are using specialized, non-interoperable, non- > scalable approaches. > > Some current experimentation and a straw proposal are described below. > > This BoF is chartered to determine if there is interest/wherewithal to > determine a standard vehicle to process contextualized resolution that > > a) is not application- or protocol-specific and > b) ties in with global resolution systems (such as DDDS) in order > to preserve authoritative resolution chains, where applicable > > Beyond the "appropriate copy" scenario, this should equally be > applicable in non-document contexts -- e.g., IP-telephony (enterprise > dialing schemes taking precedence over, but linked to, global > numbering). > > While the focus of this BoF is on standardized resolution > steps/mechanisms, not "metadata" or "knowledge transactions", > discussion must reflect that "context" generalizes beyond > location/area (e.g., to "who's paying for this", etc). > > AGENDA: > > . Agenda bashing [2 min] > . Introduction/Overview of C15N [10min] > . Discussion of Straw Proposal (below) [20min] > . Relationship to other work -- at IETF, W3C, etc [5min] > . Discussion of proposed charter [20min] > . Yes/no > > All of the above should be considered in relation to the web-caching, > proxying, and content-delivery BoFs also occurring this week > (OPES, CDNP, WEBI). > > Sample current implementation > ----------------------------- > > Some experiments have been carried out elsewhere -- e.g., the SFX > project described at: > > http://www.dlib.org/dlib/october99/van_de_sompel/10van_de_sompel.html > > and in > > http://www.doi.org/workshop_19sep00/doi_wkshp_0900_llversion.ppt > > Today, this work uses HTTP cookies -- so that the (web) client asks the > global resolution for an identifier (from a reference), and sends > a cookie which is a key for the appropriate context. The > global system uses this key to redirect the query to the appcopriate > local knowledge server (address), which makes the judgement > about where an appropriate copy of the resource shall be obtained. > > Straw proposal > -------------- > > As the starting point for discussion of how to solve this problem, > we propose the following optional additional steps for resolving > URIs in a contextualized fashion: > > There are 3 primary elements: > > . context object -- the identifier and some description of > context > > . local knowledge server [_not_ defined by us, or even > by application; rather, we define the abstract operations > for interacting with it] > > . application linkage to a global resolution authority > (e.g., DDDS for URNs, http resolution standard, etc) > > In order to ground the discussion in some semi-concrete proposal > a strawman proposal based on XLink for link typing and RDF for > context object expression will be used. In this case, the extended > XLink would relate three resources - the local resource, the desired > remote resource, and the RDF info containing the context. Each locator > will have a typed arc that determines the types of traversals > available. Additional discussion may include how this context object > may be passed to various proxies/caches for resolution based on that > context -- strictly as a tie-in with other replication, caching and > content delivery work under discussion at the IETF. > > Xlink is described at http://www.w3.org/XML/Linking > RDF is described at http://www.w3.org/RDF/ > > Open questions > -------------- > > These currently include: > > . Can/should this be transparent to the client software, or > must/should it be an external negotiation in a separate > protocol? > > . Is this configured or dynamically controlled? > > . Is this "get appropriate copy", or "get appropriate > transformation" (i.e., to a new identifier, appropriately > contextualized) > > . Can this support multiple, overlapping contexts (e.g., > location and "who's paying for this") > > -- > > ------------------------------------------------------------------- > "Logic can hold only a certain amount of sway over the rational > mind." > -- ThinkingCat > > Leslie Daigle > leslie@thinkingcat.com > ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Sun Dec 3 17:09:53 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23244 for ; Sun, 3 Dec 2000 17:09:53 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id RAA25556; Sun, 3 Dec 2000 17:09:09 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8666762 for URN-IETF@LISTS.NETSOL.COM; Sun, 3 Dec 2000 17:07:41 -0500 Received: from scaup.prod.itd.earthlink.net (scaup.prod.itd.earthlink.net [207.217.121.49]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id RAA25541 for ; Sun, 3 Dec 2000 17:07:40 -0500 (EST) Received: from mantiscorp.com (ip207.boston5.ma.pub-ip.psi.net [38.26.109.207]) by scaup.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id OAA13923; Sun, 3 Dec 2000 14:01:32 -0800 (PST) X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=iso-8859-1 Approved-By: "Aaron E. Walsh" Message-ID: <3A2AC3A2.472764F8@mantiscorp.com> Date: Sun, 3 Dec 2000 17:05:22 -0500 Reply-To: "Aaron E. Walsh" From: "Aaron E. Walsh" Organization: Mantis Development Corp. Subject: Re: Revised RFC2611 To: URN-IETF@LISTS.NETSOL.COM X-MIME-Autoconverted: from 8bit to quoted-printable by lists.netsol.com id RAA25556 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA23244 > and that very intentionally UTF8 or anything like that is not > possible. And why that is a 'good' thing. Hi Dirk -- I'd like to hear your thoughts on this issue. Aaron -- ------------------------------------------------------------------- Aaron E. Walsh http://www.mantiscorp.com/people/aew/ 617.350.7119 ------------------------------------------------------------------- Dirk-Willem van Gulik wrote: > > Looks good. I am wondering if I should propose adding a small blurp > about i18n and why the URN very intentionally is a > > URN::: > > and that very intentionally UTF8 or anything like that is not > possible. And why that is a 'good' thing. > > Secondly - we could tighten up the assigned-US-ASCII-string a bit -as > obviously the URI rules do not permit just any US-ASCII char. Nor would I > want this. > > Dw > > On Fri, 17 Nov 2000, Leslie Daigle wrote: > > > So, the draft has in fact hit the repository, as > > > > draft-ietf-urn-rfc2611bis-00.txt > > > > I realize that we're getting into the hectic holiday/pre-IETF > > timeframe, but I'd like some feedback from people to determine > > consensus on which of the following is (most) true: > > > > . "this is in line with what we discussed, we're done" > > > > . "started to read it, had some comments, but couldn't > > possibly get to it all this week, give us two > > more weeks (to Dec 1) to read and comment" > > > > I don't want to rush people, and I'd like to know if people believe > > that alotting more time would produce a better result. Otherwise, > > or if people are ambivalent, we can last call the document now and > > have it to the IESG before the end of the year. > > > > > > Thanks, > > Leslie. > > > > > > Leslie Daigle wrote: > > > > > > Howdy, > > > > > > I've submitted a revised version of RFC2611 as an Internet-Draft; > > > I've attached a copy here, as it's going to take a few days to > > > hit the repository. > > > > > > I've incorporated comments on the draft text, circulated earlier, > > > as follows: > > > > > > Martin Dürst offered: > > > > The text only speaks about an RFC, not about an I-D. Also, > > > > it's not clear whether IESG approval or submission to > > > > urn-nid@apps.ietf.org should be first, and in what form. > > > > > > Added Section 5.2, an illustration of the process. > > > > > > > >associated have openly-published APIs. > > > > > > > > I'm a little bit confused by the word API here. > > > > > > Changed it to "access protocol". Let me know if you think it still > > > needs work. > > > > > > Larry Masinter offered: > > > > There are two components to your proposed revision that are > > > > currently intermixed, that might be usefully separated out. > > > > > > Have pushed the "registration template" to the Appendix; Section 3.0 > > > is now "registration types", and Section 4.0 is "registration process", > > > with an attempt to make the delineation you suggested needed > > > clarification. > > > > > > Keith Moore offered: > > > > In general, URNs are not intended to have exposed structure beyond the > > > > NID. This is because the structure by which URNs under a particular NID > > > > are assigned, or resolved (the two are different) may change over time. > > > > > > I didn't see altogether where the document advocated inappropriate > > > exposure of structure. Perhaps there needs to be clarification about > > > what kinds of things might usefully be exposed to the public > > > without compromising the name/structure dissociation? Or, see if > > > it still seems to be a problem when you look at the document > > > as a whole. > > > > > > As always -- comments welcome. I'm sure there are some editorial > > > nits & 'roff-isms... Sigh. > > > > > > Leslie. > > > > > > -- > > > > > > ------------------------------------------------------------------- > > > "Reality with a delicate splash of the imaginary... > > > ... or was that the other way around?" > > > -- ThinkingCat > > > > > > Leslie Daigle > > > leslie@thinkingcat.com > > > ------------------------------------------------------------------- > > > > -- > > > > ------------------------------------------------------------------- > > "Logic can hold only a certain amount of sway over the rational > > mind." > > -- ThinkingCat > > > > Leslie Daigle > > leslie@thinkingcat.com > > ------------------------------------------------------------------- > > -- ------------------------------------------------------------------- Aaron E. Walsh http://www.mantiscorp.com/people/aew/ 617.350.7119 ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Mon Dec 4 23:17:40 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01495 for ; Mon, 4 Dec 2000 23:17:40 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id XAA14760; Mon, 4 Dec 2000 23:16:09 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8670060 for URN-IETF@LISTS.NETSOL.COM; Mon, 4 Dec 2000 23:15:39 -0500 Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id XAA14751 for ; Mon, 4 Dec 2000 23:15:38 -0500 (EST) Received: from thinkingcat.com ([64.229.197.101]) by tomts5-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001205040902.CZLZ22808.tomts5-srv.bellnexxia.net@thinkingcat.com>; Mon, 4 Dec 2000 23:09:02 -0500 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <3A15B5B0.8BF705F3@thinkingcat.com> <3A2AB5BB.258CEBD3@mantiscorp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Leslie Daigle Message-ID: <3A2C6A3F.D1777F18@thinkingcat.com> Date: Mon, 4 Dec 2000 23:08:31 -0500 Reply-To: Leslie Daigle From: Leslie Daigle Organization: ThinkingCat Enterprises Subject: Re: Related BoFs To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Hi Aaron, Hmmmm, now that you mention it, I should announce this BoF on the URN mailing list :-) So, no, this is not being discussed on the URN-IETF mailing list; as far as I know, there is not yet a mailing list for it. It's a few ideas that have come together, and the BoF will be the first real chance to see which parts have resonance to get work done on them now-now. So, I imagine some more particular mailing lists will get set up as a result of that. Sorry you won't be able to make the meeting itself, but stay tuned... Everyone -- the relationship of the c15n BoF to URN work is (in my opinion) fairly complementary. In various discussions, it became apparent that URN resolution mechanisms are (or at least, have been) fairly focused on providing top-down, authoritative (from the URN assignment point of view) resolution pointers. There are times when the appropriate thing is to start from "where you are" and work out a more locally-appropriate target for resolution of an identifier. This is why it's called "contextualized". I'll post info here on whatever comes out of the meeting in San Diego. Cheers, Leslie. "Aaron E. Walsh" wrote: > > Hi Leslie and Michael, thanks for the headsup on the > content/caching/resolution BoFs. Is there a specific list or reflector > where this discussion is taking place? I couldn't make the San Diego > f2f, but would like to participate in the conversation if it's not on > this list. > > Regards, > > Aaron > -- > ------------------------------------------------------------------- > Aaron E. Walsh http://www.mantiscorp.com/people/aew/ 617.350.7119 > ------------------------------------------------------------------- > > Leslie Daigle wrote: > > > > Howdy, > > > > FYI, I draw your attention to the various content/caching/resolution > > bofs to be held in San Diego on Tuesday afternoon. > > > > In particular, this one tackles something of the converse of URN > > (global) resolution, and is currently scheduled for Tuesday, 5pm-6pm. > > > > Leslie. > > > > -----------8<----------------8<----------------8<-------------- > > > > Contextualization of Resolution BOF (c15n) > > > > Day, Date at Time > > ============================== > > > > CHAIR: Michael Mealling > > > > DESCRIPTION: > > > > The URN WG's Dynamic Delegation Discovery System (DDDS) describes a > > generalized architecture for 'top down' resolution of identifiers such > > as URIs. This works well when a (software) client wants or needs to > > dynamically determine the explicit authoritative delegation of > > resolution. However, there are times when it is desirable to > > incorporate other elements of contextual control information in > > determining, for example, the "appropriate copy" of a resource -- > > preferrentially finding a "local" copy of a journal rather than > > (re)purchasing one from the authoritative publisher. This is generally > > applicable to all URI resolution, but it is more specific than "web > > caching". Software systems being built to solve this in today's > > deployed systems are using specialized, non-interoperable, non- > > scalable approaches. > > > > Some current experimentation and a straw proposal are described below. > > > > This BoF is chartered to determine if there is interest/wherewithal to > > determine a standard vehicle to process contextualized resolution that > > > > a) is not application- or protocol-specific and > > b) ties in with global resolution systems (such as DDDS) in order > > to preserve authoritative resolution chains, where applicable > > > > Beyond the "appropriate copy" scenario, this should equally be > > applicable in non-document contexts -- e.g., IP-telephony (enterprise > > dialing schemes taking precedence over, but linked to, global > > numbering). > > > > While the focus of this BoF is on standardized resolution > > steps/mechanisms, not "metadata" or "knowledge transactions", > > discussion must reflect that "context" generalizes beyond > > location/area (e.g., to "who's paying for this", etc). > > > > AGENDA: > > > > . Agenda bashing [2 min] > > . Introduction/Overview of C15N [10min] > > . Discussion of Straw Proposal (below) [20min] > > . Relationship to other work -- at IETF, W3C, etc [5min] > > . Discussion of proposed charter [20min] > > . Yes/no > > > > All of the above should be considered in relation to the web-caching, > > proxying, and content-delivery BoFs also occurring this week > > (OPES, CDNP, WEBI). > > > > Sample current implementation > > ----------------------------- > > > > Some experiments have been carried out elsewhere -- e.g., the SFX > > project described at: > > > > http://www.dlib.org/dlib/october99/van_de_sompel/10van_de_sompel.html > > > > and in > > > > http://www.doi.org/workshop_19sep00/doi_wkshp_0900_llversion.ppt > > > > Today, this work uses HTTP cookies -- so that the (web) client asks the > > global resolution for an identifier (from a reference), and sends > > a cookie which is a key for the appropriate context. The > > global system uses this key to redirect the query to the appcopriate > > local knowledge server (address), which makes the judgement > > about where an appropriate copy of the resource shall be obtained. > > > > Straw proposal > > -------------- > > > > As the starting point for discussion of how to solve this problem, > > we propose the following optional additional steps for resolving > > URIs in a contextualized fashion: > > > > There are 3 primary elements: > > > > . context object -- the identifier and some description of > > context > > > > . local knowledge server [_not_ defined by us, or even > > by application; rather, we define the abstract operations > > for interacting with it] > > > > . application linkage to a global resolution authority > > (e.g., DDDS for URNs, http resolution standard, etc) > > > > In order to ground the discussion in some semi-concrete proposal > > a strawman proposal based on XLink for link typing and RDF for > > context object expression will be used. In this case, the extended > > XLink would relate three resources - the local resource, the desired > > remote resource, and the RDF info containing the context. Each locator > > will have a typed arc that determines the types of traversals > > available. Additional discussion may include how this context object > > may be passed to various proxies/caches for resolution based on that > > context -- strictly as a tie-in with other replication, caching and > > content delivery work under discussion at the IETF. > > > > Xlink is described at http://www.w3.org/XML/Linking > > RDF is described at http://www.w3.org/RDF/ > > > > Open questions > > -------------- > > > > These currently include: > > > > . Can/should this be transparent to the client software, or > > must/should it be an external negotiation in a separate > > protocol? > > > > . Is this configured or dynamically controlled? > > > > . Is this "get appropriate copy", or "get appropriate > > transformation" (i.e., to a new identifier, appropriately > > contextualized) > > > > . Can this support multiple, overlapping contexts (e.g., > > location and "who's paying for this") > > > > -- > > > > ------------------------------------------------------------------- > > "Logic can hold only a certain amount of sway over the rational > > mind." > > -- ThinkingCat > > > > Leslie Daigle > > leslie@thinkingcat.com > > ------------------------------------------------------------------- -- ------------------------------------------------------------------- "Days used to be longer." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Wed Dec 6 09:54:36 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24162 for ; Wed, 6 Dec 2000 09:54:36 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA05209; Wed, 6 Dec 2000 09:49:23 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8673302 for URN-IETF@LISTS.NETSOL.COM; Wed, 6 Dec 2000 09:47:34 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA05072 for ; Wed, 6 Dec 2000 09:23:02 -0500 (EST) Received: from mila12 (mila12.ac.upc.es [147.83.34.131]) by roura.ac.upc.es (8.11.0/8.11.0) with SMTP id eB6EJBX08201; Wed, 6 Dec 2000 15:19:12 +0100 (MET) X-Sender: cruellas@popserver.ac.upc.es X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.1.32.20001206151831.0136d9f0@popserver.ac.upc.es> Date: Wed, 6 Dec 2000 15:18:31 +0000 Reply-To: Juan Carlos Cruellas From: Juan Carlos Cruellas Subject: Question on OIDs and URIs To: URN-IETF@LISTS.NETSOL.COM Dear all, My name is Juan Carlos Cruellas and I am involved in a work dealing with electronic signature formats. ETSI has issued its standard TS 101 733 "Electronic Signature Format" which defines a format for electronic signatures valid in the long term (by usage of timestamping techniques). The core format is based on the CMS structure defined in the RFC 2630, with the adition of a number of what in CMS document are known as signed and unsigned attributes (additional information qualifying the digital signature for people familiar with XML terminology). At the same time, ETSI, being aware of the growing importance of XML syntax and of the works dealing with digital signature in XML, expressed its interest in having something similar to its electronic signature but in XML syntax. ETSI launched a work whose final objective is to define new XML types able to contain identical information (semantically speaking) to the information contained in the new ASN.1 structures defined in the ETSI document. The results of this work will be then, new XML types whose data can be incorporated to the XML digital signature structure defined by the W3c/IETF digital signature group. We, at the UPC, are in charge of the editorial work of this specification, and there have been produced a number of drafts. The reason for send you this e-mail is related with the following problem: In ASN.1 the usual way for identifying, let's say a Policy for signature, is an OID. In XML, identification and reference of objects is made using URIs. So the problem appears when one treats of incorporating information of an OID in an XML document by converting it in a special form of an URI. ETSI thinks that this is a very generic topic where both sides, ASN.1 people and XML people will likely have something to say. The alternatives raised up to now are: 1. The draft being produced by Michael Melling (draft-mealling-oid-urn-...) where the proposal is made of representing OIDs as URNs, leading to something like: urn:oid:1.3.6.1 2. A URL with a fixed a base and appended the OID in an human readable format: e.g., http://www.etsi.org/oid/itu-t(0)/identified-organization(4)/etsi(0)/electron ic-signature-standard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1) 3. As an URN but with the human readable text included: urn:oid:itu-t(0)/identified-organization(4)/etsi(0)/electronic-signature-sta ndard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1) These three proposals have been discussed among several people in the XML digital signature group, ETSI group, and the group that works in the production of the RFC draft and different views have been expressed. Concerns on possible mismatching between numbers and text in the representation with text, have been raised. In the same direction, it has been said that automatic processing is facilitated if only numbers appear.... But human readibility have been argued as a critery supporting the incorporation of the text. Besides the former, the issue raised by approaches 2 and 3 is the identification of the organization "in charge" of the OID, which is repeated. Arguments against these repetitions have also been raised... It is our intention, by sending this e-mail to ask your opinion on this issue, in order to get a major number of views and take, in the end, a better decision. Thank you in advance for your time and interest. Best regards. Juan Carlos Cruellas From owner-urn-ietf@LISTS.NETSOL.COM Wed Dec 6 10:45:17 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02958 for ; Wed, 6 Dec 2000 10:45:16 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id KAA05735; Wed, 6 Dec 2000 10:39:47 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8673390 for URN-IETF@LISTS.NETSOL.COM; Wed, 6 Dec 2000 10:39:42 -0500 Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id KAA05728 for ; Wed, 6 Dec 2000 10:39:41 -0500 (EST) Received: from thinkingcat.com ([64.229.197.101]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001206153304.VLEE27272.tomts7-srv.bellnexxia.net@thinkingcat.com>; Wed, 6 Dec 2000 10:33:04 -0500 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <3.0.1.32.20001206151831.0136d9f0@popserver.ac.upc.es> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Leslie Daigle Message-ID: <3A2E5C0C.375B6525@thinkingcat.com> Date: Wed, 6 Dec 2000 10:32:28 -0500 Reply-To: Leslie Daigle From: Leslie Daigle Organization: ThinkingCat Enterprises Subject: Re: Question on OIDs and URIs To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Howdy, This is perhaps a good time to point out that there is a maximum length of URIs. Whether it's de jure (can't find the reference just this minute) or de facto, URIs of longer than 255 characters will cause problems. Which sort of argues for the URN:OID proposal from Michael Mealling, of the 3 you have outlined, since (apart from anything else) the ones with "human readable" components seem capable of being quite expansive. Leslie. Juan Carlos Cruellas wrote: > > Dear all, > > My name is Juan Carlos Cruellas and I am involved in a work dealing with > electronic signature formats. ETSI has issued its standard > TS 101 733 "Electronic Signature Format" which defines a format for electronic > signatures valid in the long term (by usage of timestamping techniques). > The core format is based on the CMS structure defined in the RFC 2630, > with the adition of a number of what in CMS document are known as signed > and unsigned attributes (additional information qualifying the digital > signature > for people familiar with XML terminology). > At the same time, ETSI, being aware of the growing importance of XML syntax > and of the > works dealing with digital signature in XML, expressed its interest in > having something > similar to its electronic signature but in XML syntax. > ETSI launched a work whose final objective is to define new XML types able > to contain > identical information (semantically speaking) to the information > contained in the new ASN.1 structures defined in the ETSI document. > The results of this work will be then, new XML types whose data can be > incorporated to the > XML digital signature structure defined by the W3c/IETF digital signature > group. > > We, at the UPC, are in charge of the editorial work of this specification, > and there have been produced > a number of drafts. > > The reason for send you this e-mail is related with the following problem: > > In ASN.1 the usual way for identifying, let's say a Policy for signature, > is an OID. > In XML, identification and reference of objects is made using URIs. > So the problem appears when one treats of incorporating information of an > OID in an XML document by converting it in a special form of an URI. > > ETSI thinks that this is a very generic topic where both sides, ASN.1 > people and > XML people will likely have something to say. > > The alternatives raised up to now are: > > 1. The draft being produced by Michael Melling (draft-mealling-oid-urn-...) > where the proposal is made of representing OIDs as URNs, leading to something > like: > urn:oid:1.3.6.1 > > 2. A URL with a fixed a base and appended the OID in an human readable format: > e.g., > http://www.etsi.org/oid/itu-t(0)/identified-organization(4)/etsi(0)/electron > ic-signature-standard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1) > > 3. As an URN but with the human readable text included: > > urn:oid:itu-t(0)/identified-organization(4)/etsi(0)/electronic-signature-sta > ndard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1) > > These three proposals have been discussed among several people > in the XML digital signature group, ETSI group, and the group that > works in the production of the RFC draft and different views have > been expressed. > > Concerns on possible mismatching between numbers and text in the > representation > with text, have been raised. In the same direction, it has > been said that automatic processing is facilitated if only numbers > appear.... > But human readibility have been argued as a critery supporting > the incorporation of the text. > > Besides the former, the issue raised by approaches 2 and 3 is > the identification of the organization "in charge" of the OID, > which is repeated. Arguments against these repetitions have > also been raised... > > It is our intention, by sending this e-mail to ask your opinion on this > issue, in order to get a major number of views and take, in the > end, a better decision. > > Thank you in advance for your time and interest. > > Best regards. > > Juan Carlos Cruellas -- ------------------------------------------------------------------- "Days used to be longer." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Wed Dec 6 14:19:35 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22390 for ; Wed, 6 Dec 2000 14:19:34 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id OAA08149; Wed, 6 Dec 2000 14:13:51 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8673731 for URN-IETF@LISTS.NETSOL.COM; Wed, 6 Dec 2000 14:13:41 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from smtp1.mail.iamworld.net (smtp1-out.mail.iamworld.net [204.91.241.116]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id NAA08011 for ; Wed, 6 Dec 2000 13:48:30 -0500 (EST) Received: from laploaner (pool-63.49.133.103.bltm.grid.net [63.49.133.103]) by smtp1.mail.iamworld.net (8.9.3/8.9.3) with SMTP id NAA499383; Wed, 6 Dec 2000 13:47:50 -0500 (EST) X-Sender: 10003479@pop.iamdigex.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Message-ID: <200012061847.NAA499383@smtp1.mail.iamworld.net> Date: Wed, 6 Dec 2000 14:18:31 -0500 Reply-To: Al Gilman From: Al Gilman Subject: Re: Question on OIDs and URIs To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <3.0.1.32.20001206151831.0136d9f0@popserver.ac.upc.es> Content-Transfer-Encoding: 8bit At 03:18 PM 2000-12-06 +0000, Juan Carlos Cruellas wrote: >Dear all, > >My name is Juan Carlos Cruellas and I am involved in a work dealing with >electronic signature formats. ETSI has issued its standard >TS 101 733 "Electronic Signature Format" which defines a format for electronic >signatures valid in the long term (by usage of timestamping techniques). >The core format is based on the CMS structure defined in the RFC 2630, >with the adition of a number of what in CMS document are known as signed >and unsigned attributes (additional information qualifying the digital >signature >for people familiar with XML terminology). >At the same time, ETSI, being aware of the growing importance of XML syntax >and of the >works dealing with digital signature in XML, expressed its interest in >having something >similar to its electronic signature but in XML syntax. >ETSI launched a work whose final objective is to define new XML types able >to contain >identical information (semantically speaking) to the information >contained in the new ASN.1 structures defined in the ETSI document. >The results of this work will be then, new XML types whose data can be >incorporated to the >XML digital signature structure defined by the W3c/IETF digital signature >group. It is desirable to avoid new XML types unless the type is really different. The criteria for when you have a novel type vs. just appearing in a new location are different. This is a domain analysis issue which affects your total XML usage profile. This can be separated, a bit, from the smaller question of how to identify a resource (the signature-related policy) in URI-conformant form within this XML application profile. You may view the task before you as a special case of schema mapping as used for data mediation. An example approach supported by running code is discussed in http://www-di glib.stanford.edu/cgi-bin/get/SIDL-WP-1999-0126 It sounds as though one approach here could be to start with one mapping at the level of CMS to XML Schema. Then use XML Schema to derive the ETSI signature-in-XML practice (presuming it is actually more restrictive than the general XML signature practice) as a mutual specialization of the ETSI-signature specialization of CMS and the XML-Signature target environment types. > >We, at the UPC, are in charge of the editorial work of this specification, >and there have been produced >a number of drafts. > >The reason for send you this e-mail is related with the following problem: > >In ASN.1 the usual way for identifying, let's say a Policy for signature, >is an OID. >In XML, identification and reference of objects is made using URIs. >So the problem appears when one treats of incorporating information of an >OID in an XML document by converting it in a special form of an URI. You have both problems. Yes, in XML all you are basically required to do is to represent the policy identity in some scheme conforming to the general requirements for URIs. That is all that XML per se requires of you. On the other hand, you do need to survey your user community for what operations on "policy on which signature depends" need to be supported consistently and interoperably. The OID-using community needs to form their own consensus a) that they want a URI-conforming transliteration or representation for OIDs and b) how much they wish to standardize this and how (numbers vs. expanded form, etc.). However, you also have the problem in the ASN.1-based usage pattern of how to deal with policies identified by any URI, and not just the OID-identified policies. >ETSI thinks that this is a very generic topic where both sides, ASN.1 >people and >XML people will likely have something to say. You need to expand this to ASN.1 people, XML people, and URI people. It is important to distinguish what aspects of this design problem are properly in the purview of which group to hold the ultimate decision power on. > >The alternatives raised up to now are: > >1. The draft being produced by Michael Melling (draft-mealling-oid-urn-...) >where the proposal is made of representing OIDs as URNs, leading to something >like: > urn:oid:1.3.6.1 > >2. A URL with a fixed a base and appended the OID in an human readable format: >e.g., >http://www.etsi.org/oid/itu-t(0)/identified -organization(4)/etsi(0)/electron >ic-signature-standard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1) > This is IMHO significantly less than the highest and best use of the URI space. The OID using community has the option of pursuing recognition (using the standard IETF scheme recognition processes) for either a sub-scheme of urn: as proposed by Mealling or a top-level scheme parallel to URN. But using the http: scheme, unless what follows is going to get you some useful stuff when one does an HTTP GET on it, is going to generate more heat than light and should be avoided. >3. As an URN but with the human readable text included: > >urn:oid:itu-t(0)/identified-organization(4)/etsi(0)/electronic-signature-sta >ndard(1733)/part1(1)/idupMechanism(4)/etsiESv1(1) > The point is that the information model for OIDs defines the number form and the text form as synonyms. So it is not a question of picking which one you use in a URI scheme. The service that you offer to the "policy publisher" is broken if someone wishing to follow the policy cannot easily move back and forth between the two synonymous forms of identification defined in the OID pattern of practice. The reference model for your security architecture should include a model (a schema of [possibly virtual] data) which defines this synonym relationship and the rules for each variant form. This synonym relationship between variant data forms must also be covered by conversion services in order for the alternative pattern not to break the application of policies in the signature practice. The pattern of practice that you have to standardize among those using OIDs to identify policy descriptions that signatures will depend on has to be broader than just one data representation. The appropriate bundle to standardize is an "application profile," a bundle of representations and services which assures a healthy life-cycle for the identification of the policy document and its reference and recovery as appropriate. What is the existing best current practice for moving back and forth between numeric and textual forms of OIDs? Is this service part of the standards profile of what to implement with regard to the proposed ASN.1-based security services? Is it [like LDAP] already covered with URI-conformant service identification forms of reference? >These three proposals have been discussed among several people >in the XML digital signature group, ETSI group, and the group that >works in the production of the RFC draft and different views have >been expressed. > >Concerns on possible mismatching between numbers and text in the >representation >with text, have been raised. In the same direction, it has >been said that automatic processing is facilitated if only numbers >appear.... >But human readibility have been argued as a critery supporting >the incorporation of the text. If humans don't have access to the human information of "whose policy are you following" then the system is broken. Human interpretation of the context of policy on which the signature depends is a valid requirement, and the ASN.1-based signature application profile should support it well. This does not [by virtue of logic] have to be satisfied by putting the human-comprehensible information in the data of the XML signature block. On the other hand, if current OID use policies allow for the use of the text form with the numeric form as an ad_lib alternative, this (signature practice) may not be the place to standardize on numbers. If OID doctrine says that numbers are the standard and text synonyms are a permitted alternative, then you have to think twice before breaking this OID tradition. You may well have internationalization or canonicalization problems with respect to the longer forms of the OIDs, but this is a small matter of programming, and there are resources in the canonicalization methods associated with XML signature and the work on internationalization of URIs that may be of assistance. This is a decision to be worked out by the OID using community. One option is to decide, in signature practice, to standardize on the numeric form of OIDs. In this case, it is important that there be services which are highly available that allow one to trace back from numeric OIDs to text OIDs and human readable representations of the policies. >Besides the former, the issue raised by approaches 2 and 3 is >the identification of the organization "in charge" of the OID, >which is repeated. Arguments against these repetitions have >also been raised... > This is a problem wired into the logical definition of the OIDs. There are logically two questions, and they need to be separated. 1) If the publisher of the policy wishes to identify their policy by an OID, how to provide for URI-conformant expression of this identification suitable for use in XML and 2) Given all URI-conformant forms of identification, which will be equally acceptable to XML, do policy publishers really wish to always identify their policies via the OID route? [major IMHO disclaimer] I would be thinking of setting up the model of what the information is you actually capture in the OID dictionary, and be preparing to deal with any form of identification which succeeds in reproducing this information. The binding from information fields to OID path order may in fact be introducing constraints that you would like to get out from under eventually. You will probably be under pressure, if you decide to remove the redundant reference to the congnizant organization, to demonstrate a reference implementation of all relevant transforms. This doesn't seem like a serious technical risk if you develop the binding in a schema-based environment. >It is our intention, by sending this e-mail to ask your opinion on this >issue, in order to get a major number of views and take, in the >end, a better decision. An excellent move. I would also encourage you or someone on your team to monitor what is going on in the security and information services working groups in the Global Grid Forum www.gridforum.org/>. They have the same general problem and may have valuable ideas to contribute to a solution or may be good customers for what you work out. Al > >Thank you in advance for your time and interest. > >Best regards. > >Juan Carlos Cruellas > From owner-urn-ietf@LISTS.NETSOL.COM Thu Dec 7 09:41:52 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25811 for ; Thu, 7 Dec 2000 09:41:52 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA17035; Thu, 7 Dec 2000 09:37:29 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8674878 for URN-IETF@LISTS.NETSOL.COM; Thu, 7 Dec 2000 09:36:55 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id GAA16111 for ; Thu, 7 Dec 2000 06:05:24 -0500 (EST) Received: from mila12 (mila12.ac.upc.es [147.83.34.131]) by roura.ac.upc.es (8.11.0/8.11.0) with SMTP id eB7B1rX29010 for ; Thu, 7 Dec 2000 12:01:53 +0100 (MET) X-Sender: cruellas@popserver.ac.upc.es X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.1.32.20001207120111.01a54b60@popserver.ac.upc.es> Date: Thu, 7 Dec 2000 12:01:11 +0000 Reply-To: Juan Carlos Cruellas From: Juan Carlos Cruellas Subject: Info on how to subscribe the list To: URN-IETF@LISTS.NETSOL.COM Dear all, I sent an e-mail yesterday to your list presenting some work on electronic signatures format and asking for comments to a specific issue dealing with OIDs and URIs.... I forgot to ask how could I manage to subscribe myself to the list in order to be able to get your comments. Thank you very much and best regards. Juan Carlos Cruellas. From owner-urn-ietf@LISTS.NETSOL.COM Thu Dec 7 09:47:03 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27357 for ; Thu, 7 Dec 2000 09:47:02 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA17208; Thu, 7 Dec 2000 09:42:57 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8674914 for URN-IETF@LISTS.NETSOL.COM; Thu, 7 Dec 2000 09:42:54 -0500 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA17201 for ; Thu, 7 Dec 2000 09:42:52 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id JAA18329; Thu, 7 Dec 2000 09:26:45 -0500 (EST) References: <3.0.1.32.20001207120111.01a54b60@popserver.ac.upc.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20001207092645.V9127@bailey.dscga.com> Date: Thu, 7 Dec 2000 09:26:45 -0500 Reply-To: michaelm@NETSOL.COM From: Michael Mealling Subject: Re: Info on how to subscribe the list To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <3.0.1.32.20001207120111.01a54b60@popserver.ac.upc.es>; from cruellas@AC.UPC.ES on Thu, Dec 07, 2000 at 12:01:11PM +0000 On Thu, Dec 07, 2000 at 12:01:11PM +0000, Juan Carlos Cruellas wrote: > I sent an e-mail yesterday to your list presenting some work > on electronic signatures format and asking for comments to > a specific issue dealing with OIDs and URIs.... > I forgot to ask how could I manage to subscribe myself to > the list in order to be able to get your comments. Hi Juan, There are two methods: 1) send mail to listserv@lists.netsol.com with "subscribe urn-ietf" in the body 2) go to this weg page: http://lists.netsol.com/cgi-bin/wa?SUBED1=urn-ietf&A=1 You can also find the list archive here: http://lists.netsol.com/archives/urn-ietf.html -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com From owner-urn-ietf@LISTS.NETSOL.COM Tue Dec 12 14:10:18 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23097 for ; Tue, 12 Dec 2000 14:10:17 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id OAA17193; Tue, 12 Dec 2000 14:05:22 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8683454 for URN-IETF@LISTS.NETSOL.COM; Tue, 12 Dec 2000 14:02:08 -0500 Received: from eufig1.rit.reuters.com (eufig1.rit.reuters.com [194.205.123.3]) by lists.netsol.com (8.9.3/8.9.3) with SMTP id OAA17142 for ; Tue, 12 Dec 2000 14:02:06 -0500 (EST) Received: from [196.7.183.5] by eufig1.rit.reuters.com via smtpd (for lists.netsol.com [216.168.224.214]) with SMTP; 12 Dec 2000 18:53:14 UT Received: from eupig1 (unverified) by euvig1.dtc.lon.ime.reuters.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 12 Dec 2000 18:49:49 +0000 Received: from eungw1.dtc.lon.ime.reuters.com ([132.70.1.161]) by eupig1.dtc.lon.ime.reuters.com (PMDF V5.2-31 #39917) with SMTP id <0G5G00KF8XKNZL@eupig1.dtc.lon.ime.reuters.com> for URN-IETF@LISTS.NETSOL.COM; Tue, 12 Dec 2000 18:48:23 +0000 (GMT) Received: by eungw1.dtc.lon.ime.reuters.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 802569B3.0067F559 ; Tue, 12 Dec 2000 18:55:30 +0000 MIME-Version: 1.0 X-Lotus-FromDomain: REUTERS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Approved-By: Tony Coates Message-ID: Date: Tue, 12 Dec 2000 13:49:55 -0500 Reply-To: Tony Coates From: Tony Coates Subject: Lifecycle of URN NID applications To: URN-IETF@LISTS.NETSOL.COM One thing that is unclear to me is how long it takes from the time a URN NID application made to IANA (via the creation of a suitable Internet Draft) until the NID is proclaimed, for example at ftp://ftp.isi.edu/in-notes/iana/assignments/urn-namespaces Is it just a matter of waiting for the Internet Draft to become an RFC, or is there some other process which determines the timing? Thanks in advance for any advice, Cheers, Tony. ======== Anthony B. Coates Leader of XML Architecture & Design Chief Technology Office Reuters Plc, London. tony.coates@reuters.com ======== ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. From owner-urn-ietf@LISTS.NETSOL.COM Tue Dec 12 14:51:51 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01332 for ; Tue, 12 Dec 2000 14:51:51 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id OAA17953; Tue, 12 Dec 2000 14:47:46 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8683573 for URN-IETF@LISTS.NETSOL.COM; Tue, 12 Dec 2000 14:44:59 -0500 Received: from ns1.49thietf.org (ietf.207.137.80.5.tx.verio.net [207.137.80.5]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id OAA17938 for ; Tue, 12 Dec 2000 14:44:57 -0500 (EST) Received: from thinkingcat.com (ietf.207.137.75.115.tx.verio.net [207.137.75.115]) by ns1.49thietf.org (8.9.3+Sun/8.9.3) with ESMTP id LAA05348; Tue, 12 Dec 2000 11:38:49 -0800 (PST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Leslie Daigle Message-ID: <3A367E94.F411314@thinkingcat.com> Date: Tue, 12 Dec 2000 14:37:56 -0500 Reply-To: Leslie Daigle From: Leslie Daigle Organization: ThinkingCat Enterprises Subject: Re: Lifecycle of URN NID applications To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Howdy, Yes, first, the RFC has to be approved (possibly published) before the IANA will make the assignment. Then, it depends on the workload of the IANA at the time of the request. Leslie. Tony Coates wrote: > > One thing that is unclear to me is how long it takes from the time a URN NID > application made to IANA (via the creation of a suitable Internet Draft) until > the NID is proclaimed, for example at > > ftp://ftp.isi.edu/in-notes/iana/assignments/urn-namespaces > > Is it just a matter of waiting for the Internet Draft to become an RFC, or is > there some other process which determines the timing? Thanks in advance for any > advice, > > Cheers, > Tony. > ======== > Anthony B. Coates > Leader of XML Architecture & Design > Chief Technology Office > Reuters Plc, London. > tony.coates@reuters.com > ======== > > ----------------------------------------------------------------- > Visit our Internet site at http://www.reuters.com > > Any views expressed in this message are those of the individual > sender, except where the sender specifically states them to be > the views of Reuters Ltd. -- ------------------------------------------------------------------- "Days used to be longer." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Sun Dec 17 11:22:03 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26541 for ; Sun, 17 Dec 2000 11:22:03 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id LAA13829; Sun, 17 Dec 2000 11:08:40 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8692023 for URN-IETF@LISTS.NETSOL.COM; Sun, 17 Dec 2000 11:06:37 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id KAA13744 for ; Sun, 17 Dec 2000 10:50:02 -0500 (EST) Received: from [195.20.224.208] (helo=mrvdom01.schlund.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 147fyf-0002wB-00 for URN-IETF@lists.netsol.com; Sun, 17 Dec 2000 16:43:57 +0100 Received: from p3ee01f70.dip.t-dialin.net ([62.224.31.112] helo=weiseworte.de) by mrvdom01.schlund.de with esmtp (Exim 2.12 #2) id 147fya-0004iY-00 for URN-IETF@LISTS.NETSOL.COM; Sun, 17 Dec 2000 16:43:52 +0100 X-Mailer: Mozilla 4.7 [de] (Win98; I) X-Accept-Language: de MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <3A3CE042.BE2D0318@weiseworte.de> Date: Sun, 17 Dec 2000 16:48:18 +0100 Reply-To: Tamara Weise From: Tamara Weise Subject: URN Namespaces To: URN-IETF@LISTS.NETSOL.COM X-MIME-Autoconverted: from 8bit to quoted-printable by lists.netsol.com id LAA13829 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA26541 Dear Sirs, I´m a student of information science (Germany, Saarland University). This time I´m doing my final examination, my dissertation is about persistent identifiers for online publications. URN is one of the models I´m analyzing. I had read RFC 2611 - and now I have some questions about it: Until this time there is only one registered NID (for IETF). Beside this the CDNL/ Finnish National Library is willing to register an NID for NBNs. When will begin the official process of assignment for interested parties? Are there any proposals or decisions on how much will the NID assignment cost? Help me please. I need the information as quick as possible. Thank you for your attention. Best regards, Tamara Weise From owner-urn-ietf@LISTS.NETSOL.COM Sun Dec 17 13:08:57 2000 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14977 for ; Sun, 17 Dec 2000 13:08:57 -0500 (EST) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA14731; Sun, 17 Dec 2000 12:56:42 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8692150 for URN-IETF@LISTS.NETSOL.COM; Sun, 17 Dec 2000 12:55:06 -0500 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA14721 for ; Sun, 17 Dec 2000 12:55:04 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id MAA17877; Sun, 17 Dec 2000 12:38:57 -0500 (EST) References: <3A3CE042.BE2D0318@weiseworte.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20001217123856.B17527@bailey.dscga.com> Date: Sun, 17 Dec 2000 12:38:57 -0500 Reply-To: michaelm@NETSOL.COM From: Michael Mealling Subject: Re: URN Namespaces To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <3A3CE042.BE2D0318@weiseworte.de>; from tamara@WEISEWORTE.DE on Sun, Dec 17, 2000 at 04:48:18PM +0100 X-MIME-Autoconverted: from 8bit to quoted-printable by lists.netsol.com id MAA14731 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA14977 On Sun, Dec 17, 2000 at 04:48:18PM +0100, Tamara Weise wrote: > I´m a student of information science (Germany, Saarland University). > This time I´m doing my final examination, my dissertation is about > persistent identifiers for online publications. URN is one of the models > I´m analyzing. Great! If you can please send us a pointer to your dissertation if possible.... > I had read RFC 2611 - and now I have some questions about it: > > Until this time there is only one registered NID (for IETF). > Beside this the CDNL/ Finnish National Library is willing to register an > NID for NBNs. > > When will begin the official process of assignment for interested > parties? That process began with the publication of RFC 2611. In addition to NBM, others that are in the process are OID, PIN, ISBN, etc. To see all of the requests and discussion on each you can check out the archive of this mailing list at http://lists.netsol.com/archives/urn-ietf.html The official discussion list archive of NID assignments is at http://wilma.cs.utk.edu/mail-archive/urn-nid.* > Are there any proposals or decisions on how much will the NID assignment > cost? Unless something unforseen happens, IMHO they should always be free... > Help me please. I need the information as quick as possible. I hope that helps! -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com