Windows NT to Windows 2000 Migration
Hi, Can any one provide me some documents or presentations on Windows NT to Windows 2000 Migration. Also if any sites available where I can find the relevant information. Regards Maneesh Sharma -Original Message- From: Donald Eastlake 3rd [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 9:00 AM To: chintan sheth Cc: [EMAIL PROTECTED] Subject: Re: SHA1 source code!! RFC 3174 http://www.rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFCletsgo=3174type=ftp file_format=txt == Donald E. Eastlake 3rd [EMAIL PROTECTED] 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) Milford, MA 01757 USA [EMAIL PROTECTED] On Wed, 24 Jul 2002, chintan sheth wrote: Date: Wed, 24 Jul 2002 19:32:04 -0700 (PDT) From: chintan sheth [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: SHA1 source code!! hi, is there any public domain where SHA1 license free source code (C - source code) is available?? Thx in advance chintan __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ** This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. **
Re: Windows NT to Windows 2000 Migration
On Thu, 25 Jul 2002, Maneesh_Sharma wrote: Can any one provide me some documents or presentations on Windows NT to Windows 2000 Migration. Also if any sites available where I can find the relevant information. http://windows.microsoft.com You're welcome! (Note: this list is not the place to ask something like this.) -Original Message- From: Donald Eastlake 3rd [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 25, 2002 9:00 AM To: chintan sheth Cc: [EMAIL PROTECTED] Subject: Re: SHA1 source code!! RFC 3174 http://www.rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFCletsgo=3174type=ftp file_format=txt == Donald E. Eastlake 3rd [EMAIL PROTECTED] 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) Milford, MA 01757 USA [EMAIL PROTECTED] On Wed, 24 Jul 2002, chintan sheth wrote: Date: Wed, 24 Jul 2002 19:32:04 -0700 (PDT) From: chintan sheth [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: SHA1 source code!! hi, is there any public domain where SHA1 license free source code (C - source code) is available?? Thx in advance chintan __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com ** This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. ** -- Pekka Savola Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
Re: ECN and ISOC: request for help...
I found the problem when coming back from Inet2002 and alerted Lynn and Anne. It was the first time they heard about it, they told me... (between us I don care who found it first... does it really matter?) Now, if someone alerted them before, and they forgot about it. I worried that they (or anybody) will ever get arround to fix this problem at least in ISOC. Imagine other places, how hard it will be, if even ISOC with the full backing of IETF cannot do it? And the band played on Cheers Franck On Thu, 2002-07-25 at 20:09, Brian E Carpenter wrote: P.S. Credit where credit is due: it was Ted who first detected and reported this problem with ISOC's mail service provider, during the NomCom process.
RE: NSRG presentation mailing list address
J. Noel Chiappa wrote: From: David J. Aronson [EMAIL PROTECTED] I'm only on the regular IETF list .. and I eventually got it four times too I think there's some bug in the mailer that handles the IETF list. For the past couple of months, I've often seen longer messages get multiplicated (e.g. in the big long secure DNS discussion). Alas, I no longer have the duplicates, so I can't check the Received: lines and see which machine is replicating them. It's loki.ietf.org (132.151.1.177) playing tricks on us: 8--- Loki was the trickster god, the mischief maker, the father of lies and deceit. His heritage as a giant fueled his hatred of the other gods, and would often instigate conflict among them. But as the blood brother of Odin, none of the gods dared to rebuke or harm Loki, no matter how mischievous and malevolent he became. His mischevious acts finally came to an end when the god Balder died at his hand and the other gods set out to punish him. Loki will be set free when the Ragnarok, the final battle between the gods and the giants comes to pass. ---8 Here are the four headers timed at 14:49:22, 14:52:25, 14:57:00 and 15:02:01 8-- Received: from loki.ietf.org (132.151.1.177) by md2.mediadesign.nl with SMTP; 24 Jul 2002 20:12:55 - Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA05255 for [EMAIL PROTECTED]; Wed, 24 Jul 2002 14:49:22 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id OAA05048 for [EMAIL PROTECTED]; Wed, 24 Jul 2002 14:29:00 -0400 (EDT) -8 8-- Received: from loki.ietf.org (132.151.1.177) by md2.mediadesign.nl with SMTP; 24 Jul 2002 20:22:46 - Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA05293 for [EMAIL PROTECTED]; Wed, 24 Jul 2002 14:52:25 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id OAA05048 for [EMAIL PROTECTED]; Wed, 24 Jul 2002 14:29:00 -0400 (EDT) --8 8-- Received: from loki.ietf.org (132.151.1.177) by md2.mediadesign.nl with SMTP; 24 Jul 2002 20:33:11 - Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA05411 for [EMAIL PROTECTED]; Wed, 24 Jul 2002 14:57:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id OAA05048 for [EMAIL PROTECTED]; Wed, 24 Jul 2002 14:29:00 -0400 (EDT) --8 8--- Received: from loki.ietf.org (132.151.1.177) by md2.mediadesign.nl with SMTP; 24 Jul 2002 20:15:07 - Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA05478 for [EMAIL PROTECTED]; Wed, 24 Jul 2002 15:02:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id OAA05048 for [EMAIL PROTECTED]; Wed, 24 Jul 2002 14:29:00 -0400 (EDT) ---8 Greets, Jeroen
Re: Jabber BOF afterthoughts
I happened to be at the Jabber BOF, which since has turned out to be a hot topic, at least judging from the discussions at the IESG plenary. As far as I understood, the objectives of the Jabber community were, that they mainly wanted a place for the protocol documentation to be published, and needed some expert review and help in sorting out the security services for the protocol. A simple misunderstanding: they are some of the motivations, but not the main ones. We mainly want to keep the protocol from fragmenting into disarray, diverging implementations, lack of agreeance, poorly implemented/upgraded security additions as they come along, just all around poor support for a multi-domain multi-use protocol, where that poor support can directly impact the effectiveness and usability of other parts of the network. I didn't see an overwhealming desire to release the control for the development of the protocol to the IETF, but I may have misinterpreted things. I never got my chance at the mic to explain my viewpoint on this. The protocol is based on namespaces, and the JSF is primarily a forum where people create NEW namespaces, which is as separate from HTTP as is new content types served over it. There is very little activity in the JSF around the core protocol, nor has there been any change control asserted beyond independently updated software releases. The core protocol, that primarily documented best by the drafts, isn't controlled by anyone at this point, you could say the JSF is the closest, but it has not taken that role. Again, we're coming to the IETF because we *need* a strong and proven process for managing this important layer in the Jabber architecture. We're not giving up any control, we simply don't have it. My perhaps a rather simplistic suggestion at the BOF was that the Jabber community submit their protocol specifications to the IESG to be published as Informational RFCs. After an addmittedly quick skim through the I-Ds, in my opinion they seemed to describe a pretty mature protocol which arguably works. And my understanding of the IETF process has also been that the IESG does commit to a fairly thorough review for even documents intended as Informational, i.e., give expert review, possibly referring to relevant WGs in the process. Another angle on the same theme: it's not the documents or publications themselves that help force consensus and stabilize a growing-unwieldy network protocol, it's the process of involving all the interested parties in a WG to iron out issues from their varied perspectives and having control of the protocol exist in the hands of a recognized standards body. I didn't say it very clearly at the BOF, but the reason we weren't doing this two years ago was because we didn't care about the protocol (our focus has always been open interoperability and accessibility), and had the expectation that anything the IMPP could come up with would be a superset of what we had and we could migrate to it, after all the IMPP architecture descriptions were almost identical to Jabber. That didn't happen, there is no protocol with comparable characteristics, and now we're faced with the popularity of our own protocol and the implications of new quasi-implementations on the network when nobody has the ability to say or enforce anything. Why is that? After all, the Informational RFC should work equally well for the Jabber community, and would even allow them to retain control for the development of the protocol. I understand the Internet Relay Chat is in fact Informational, but that doesn't seem to have hampered its adoption in the Internet. Funny that you should mention IRC, that's exactly what we're trying to avoid, a protocol full of problems and holes with only patchwork fixes and get a better implementation solutions to work around it's deficiencies, and numerous extensions that aren't exactly optimal :) Jer
DNS based URI without any set access semantics?
IETF Gurus, I'm looking for a URN scheme that uses DNS for uniqueness (perhaps in conjunction with a date) but doesn't have any attached semantics. I'm asking this beacuse XML has the duck problem. It uses URIs for namespace names, but only the URI syntax (for uniqueness), thus you see lots of http:// namespace names but the author never intended to support the retrieval of content given the namespace name. Anyway, this is icky. What XML really wanted was a URN that is based on DNS. As it turns out YAML (http://yaml.org) has exactly the same situation, only we are in a position to do this correctly. So, I was thinking something like... dnsurn://clarkevans.com/2002/my-data-type#my-format Thus, the scheme follows *exactly* the syntax of HTTP (to keep learning curve down) only that the date is required immediately following the domain name. The advantage of this over http is that it doesn't look like a duck... dnsurn is not http. A further advantage is that someone can use everything to the right of the dnsurn: as a http: URL if they wish by just replacing the scheme. I'm completely dogged for time... if something like this is possible how hard would it be? I'm not looking forward to having the equivalent of XML namespaces considered harmful threads on our YAML list and thing something like this would serve to help not only YAML but also XML... Best, Clark
Re: DNS based URI without any set access semantics?
On Thu, Jul 25, 2002 at 11:48:27AM -0400, Clark C . Evans wrote: I'm looking for a URN scheme that uses DNS for uniqueness (perhaps in conjunction with a date) but doesn't have any attached semantics. I'm asking this beacuse XML has the duck problem. It uses URIs for namespace names, but only the URI syntax (for uniqueness), thus you see lots of http:// namespace names but the author never intended to support the retrieval of content given the namespace name. Anyway, this is icky. What XML really wanted was a URN that is based on DNS. As it turns out YAML (http://yaml.org) has exactly the same situation, only we are in a position to do this correctly. So, I was thinking something like... dnsurn://clarkevans.com/2002/my-data-type#my-format Thus, the scheme follows *exactly* the syntax of HTTP (to keep learning curve down) only that the date is required immediately following the domain name. The advantage of this over http is that it doesn't look like a duck... dnsurn is not http. A further advantage is that someone can use everything to the right of the dnsurn: as a http: URL if they wish by just replacing the scheme. I'm completely dogged for time... if something like this is possible how hard would it be? I'm not looking forward to having the equivalent of XML namespaces considered harmful threads on our YAML list and thing something like this would serve to help not only YAML but also XML... It sounds like you want the 'duri' namespace currently going through the process. It was written by Larry Masinter and is currently here: http://www.ietf.org/internet-drafts/draft-masinter-dated-uri-03.txt The URN is of the form: urn:duri:date:encoded-URI Examples: urn:duri:2001:http://www.ietf.org urn:tdb:20010814142327:file://this.example.com/c|/temp/test.txt urn:tdb:2001:data:,The%2520US%2520president etc... -MM -- Michael Mealling| Vote Libertarian! | urn:pin:1 [EMAIL PROTECTED] | | http://www.neonym.net
RE: Jabber BOF afterthoughts
--On 23. juli 2002 21:49 -0400 Peterson, Jon [EMAIL PROTECTED] wrote: I don't think it is unreasonable to suggest that chartering a new WG today that competes directly with SIMPLE would be taken by many to mean that the IETF still has not arrived at a workable solution (and no doubt some proponents of XMPP feel that to be the case). I think the single step most useful to stem this perception is to get the CPIM documents out the door and published, have at least one IM-transport protocol publish its interface to CPIM, and having running code that proves that the resulting functionality is in fact useful. Pair of facts beats house of prediction. Harald
Re: DNS based URI without any set access semantics?
On Thu, Jul 25, 2002 at 12:07:19PM -0400, Michael Mealling wrote: | |dnsurn://clarkevans.com/2002/my-data-type#my-format | | Thus, the scheme follows *exactly* the syntax of HTTP (to keep learning | curve down) only that the date is required immediately following the | domain name. The advantage of this over http is that it doesn't look | like a duck... dnsurn is not http. ... | The URN is of the form: urn:duri:date:encoded-URI | | urn:duri:2001:http://www.ietf.org | urn:tdb:20010814142327:file://this.example.com/c|/temp/test.txt | urn:tdb:2001:data:,The%2520US%2520president Hmm. If the above proposal is too close to http, then formalizing java package names as URI would be useful... package:com.clarkevans.MyDataType The end goal is (a) to have a DNS based URN and (b) not have this URN imply any sort of access mechanism (http,https,ftp,news,etc.) Best, --- Clark C. Evans Axista, Inc. http://www.axista.com800.926.5525 XCOLLA Collaborative Project Management Software
Re: DNS based URI without any set access semantics?
ick. please don't embed URIs in URNs. that will just tempt people to use the embedded URIs and not treat them as URNs. I can see wanting to have a URN that's based on DNS, but there shouldn't be any expectation that you can derive a URI from the URN just by modifying the syntax. that defeats the whole purpose. Keith
Re: DNS based URI without any set access semantics?
On Thu, Jul 25, 2002 at 12:07:19PM -0400, Michael Mealling wrote: | |dnsurn://clarkevans.com/2002/my-data-type#my-format | | | It sounds like you want the 'duri' namespace currently going through the | process. It was written by Larry Masinter and is currently here: | | http://www.ietf.org/internet-drafts/draft-masinter-dated-uri-03.txt | | The URN is of the form: urn:duri:date:encoded-URI Thanks Michael. This looks a bit too noisy for me; I'm just looking for something that I can replace http with no other changes to that the duck stops quacking. This proposal is very noisy and probably woudn't be adopted by XMLers or YAMLers. Further, the / is reserved within URNs and thus would need to be escaped no? | urn:duri:2001:http://www.ietf.org | urn:tdb:20010814142327:file://this.example.com/c|/temp/test.txt | urn:tdb:2001:data:,The%2520US%2520president Also, the date is the least important part (this can be removed from the proposal). I'm just looking for something which allows for absolute http uris (with fragments) to be used excepting http is replaced by something else so that the unique identifier can be used without bringing along the http semantics. Lastly, since http occurs within urn:duri:2002:http://yaml.org/somewhere, this doesn't solve my urn without semantics issue since the http is still there. Hmms. Clark -- Clark C. Evans Axista, Inc. http://www.axista.com800.926.5525 XCOLLA Collaborative Project Management Software
Re: DNS based URI without any set access semantics?
- Forwarded message from Clark C . Evans [EMAIL PROTECTED] - Date: Thu, 25 Jul 2002 15:17:05 -0400 From: Clark C . Evans [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [xml-dev] DNS based URIs that don't imply access method Ok. I've also asked this question on the ietf list and appears that there does not exist a URI scheme with these properties: - it uses DNS to gaurentee uniqueness - it does not imply any sort of access protocol (http/ftp/etc.) - two instances of the scheme are unique iff their strings are unique So. I'm now asking if we should create a URI scheme with these properties. Let's call it pkg for now, but any sufficiently generic name should work. Here is the proposal: - the scheme starts with pkg:// - next is a domain name in *small caps* - optionally followed by: - a slash '/' - a standard httpish path per URI specification. - no relative forms - no fragments Examples: pkg://clarkevans.com pkg://clarkevans.com/data-type pkg://clarkevans.com/2002/my-data The end goal is (a) to have a DNS based URN and (b) not have this URN imply any sort of access mechanism (http,ftp,etc.) For XML-DEV people... What do you think? Pretend for a moment that this is 1997 and XML is just about to emerge. Would something like this have helped? Please limit comments to what the URI change will impact, not about general problems with XML namespaces and such soap boxes. Ok. Now, given today, if it took a while to catch on would it improve the situation (mod other namespace problems)? If not, why? Anyway, if you are interested, I'm going to attempt to carry out this conversation over on the ietf's discussion list at http://www1.ietf.org/mail-archive/ietf/Current/index.html in a manner independent of XML. I'll be observant of replys to the xml-dev list, but I'm not at all interested in the xml-namespace soapbox. ;) Best, Clark -- Clark C. Evans Axista, Inc. http://www.axista.com800.926.5525 XCOLLA Collaborative Project Management Software - End forwarded message - - End forwarded message - -- Clark C. Evans Axista, Inc. http://www.axista.com800.926.5525 XCOLLA Collaborative Project Management Software
RE: SHA1 source code!!
Also, last I checked, it came with PGP source code. Just FYI. -Original Message- From: Donald Eastlake 3rd [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 24, 2002 5:30 PM To: chintan sheth Cc: [EMAIL PROTECTED] Subject: Re: SHA1 source code!! RFC 3174 http://www.rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFCletsgo=3174type=ftp file_format=txt == Donald E. Eastlake 3rd [EMAIL PROTECTED] 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) Milford, MA 01757 USA [EMAIL PROTECTED] On Wed, 24 Jul 2002, chintan sheth wrote: Date: Wed, 24 Jul 2002 19:32:04 -0700 (PDT) From: chintan sheth [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: SHA1 source code!! hi, is there any public domain where SHA1 license free source code (C - source code) is available?? Thx in advance chintan __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Re: DNS based URI without any set access semantics?
On Thu, Jul 25, 2002 at 01:35:08PM -0400, Keith Moore wrote: | ick. please don't embed URIs in URNs. that will just tempt people | to use the embedded URIs and not treat them as URNs. I'm not set at all on using URIsh syntax. I just thought it'd be the easiest approach. | I can see wanting to have a URN that's based on DNS, but there shouldn't | be any expectation that you can derive a URI from the URN just by | modifying the syntax. that defeats the whole purpose. Great. So, should this thingy be a URN NID? How about using reverse DNS, aka Java package names? urn:dns:com.clarkevans:MyPackage Where the first three components are always small caps. Best, Clark -- Clark C. Evans Axista, Inc. http://www.axista.com800.926.5525 XCOLLA Collaborative Project Management Software
Re: DNS based URI without any set access semantics?
On Thu, Jul 25, 2002 at 01:35:08PM -0400, Keith Moore wrote: | ick. please don't embed URIs in URNs. that will just tempt people | to use the embedded URIs and not treat them as URNs. I'm not set at all on using URIsh syntax. I just thought it'd be the easiest approach. | I can see wanting to have a URN that's based on DNS, but there shouldn't | be any expectation that you can derive a URI from the URN just by | modifying the syntax. that defeats the whole purpose. Great. So, should this thingy be a URN NID? How about using reverse DNS, aka Java package names? 1. it doesn't matter whether the components are reversed or not. 2. you do need a date, because domain names change hands. 3. it's not a good idea to embed any more human-meaningful content in a URN than necessary to get uniqueness. my offhand proposal would be: URN:dns:f.q.d.n:date:unique-suffix f.q.d.n fully-qualified domain name datedate in the form MMDD (exactly 8 digits) it can be any date that the DNS name was officially registered to the party assigning the name. it is recommended that the same date should be used consistently for all URNs issued under that domain by that domain holder. one way to do this is to use the date of initial registration. unique-suffix a suffix that is uniquely and permanently assigned to a particular resource. it's strongly recommended that this be a string of digits or other meaningless ascii characters rather than a human-meaningful string. I'm tempted to suggest that the f.q.d.n:iso-date portion be hashed with MD5 and encoded in base64, just so that the URN doesn't pretend to have any semantics associated with it. but if we leave the DNS name intact then it's easier to build a resolver for it that uses DNS. that's also why I would like to see the date be an exact length - it's easier (though still ugly) to match date ranges in NAPTR records that way. Keith
Re: DNS based URI without any set access semantics?
On Thu, Jul 25, 2002 at 03:29:33PM -0400, Clark C . Evans wrote: On Thu, Jul 25, 2002 at 01:35:08PM -0400, Keith Moore wrote: | ick. please don't embed URIs in URNs. that will just tempt people | to use the embedded URIs and not treat them as URNs. I'm not set at all on using URIsh syntax. I just thought it'd be the easiest approach. | I can see wanting to have a URN that's based on DNS, but there shouldn't | be any expectation that you can derive a URI from the URN just by | modifying the syntax. that defeats the whole purpose. Great. So, should this thingy be a URN NID? How about using reverse DNS, aka Java package names? urn:dns:com.clarkevans:MyPackage Where the first three components are always small caps. The problem is that URNs are required to be non-reasignable. So if the part between the second and third colons is based off of a domain-name then you will have to timestamp it somehow. -MM -- Michael Mealling| Vote Libertarian! | urn:pin:1 [EMAIL PROTECTED] | | http://www.neonym.net
Re: DNS based URI without any set access semantics?
On Thu, Jul 25, 2002 at 03:40:07PM -0400, Keith Moore wrote: | 1. it doesn't matter whether the components are reversed or not. | 2. you do need a date, because domain names change hands. | 3. it's not a good idea to embed any more human-meaningful content |in a URN than necessary to get uniqueness. Great! | URN:dns:f.q.d.n:date:unique-suffix How about... urn:dns:f.q.d.n,year;unique-suffix where ;unique-syntax is optional | f.q.d.n fully-qualified domain name Yes. And to make sure that these thingys can be compared via strcmp, the f.q.d.n should be using only lower-case letters. | date date in the form MMDD (exactly 8 digits) I was thinking just a year as most registries renew once a year. In particular, how about allowing a person to use year if they are the valid domain name holder at exactly midnight January 1st of that year. | unique-suffix a suffix that is uniquely and permanently assigned to a | particular resource. it's strongly recommended that this |be a string of digits or other meaningless ascii characters | rather than a human-meaningful string. I see no problem with it being human readable. The point is that there isn't a protocol associated with the URI, not that it is a pain to remember. If it is a pain to remember, no one will use it. In this case, why even use DNS? The problem is that I need globally unique URIs that are easy to remember and that don't imply a particular protocol, like http. | I'm tempted to suggest that the f.q.d.n:iso-date portion be hashed with MD5 | and encoded in base64, just so that the URN doesn't pretend to have any | semantics associated with it. but if we leave the DNS name intact then | it's easier to build a resolver for it that uses DNS. that's also why | I would like to see the date be an exact length - it's easier (though | still ugly) to match date ranges in NAPTR records that way. See above. I hope the year suggestion works for you. Clark -- Clark C. Evans Axista, Inc. http://www.axista.com800.926.5525 XCOLLA Collaborative Project Management Software
Re: DNS based URI without any set access semantics?
On Thu, Jul 25, 2002 at 03:48:29PM -0400, Michael Mealling wrote: | | urn:dns:com.clarkevans:MyPackage | | Where the first three components are always small caps. | | The problem is that URNs are required to be non-reasignable. So if | the part between the second and third colons is based off of a domain-name | then you will have to timestamp it somehow. Ok, would this fly? urn:dns:yaml.clarkevans.com,2002;MyPackage Thank you both for humoring me. YAML needs something clean like this for its type identifiers. Best, Clark -- Clark C. Evans Axista, Inc. http://www.axista.com800.926.5525 XCOLLA Collaborative Project Management Software
Re: DNS based URI without any set access semantics?
On Thu, Jul 25, 2002 at 04:36:22PM -0400, Clark C . Evans wrote: On Thu, Jul 25, 2002 at 03:48:29PM -0400, Michael Mealling wrote: | | urn:dns:com.clarkevans:MyPackage | | Where the first three components are always small caps. | | The problem is that URNs are required to be non-reasignable. So if | the part between the second and third colons is based off of a domain-name | then you will have to timestamp it somehow. Ok, would this fly? urn:dns:yaml.clarkevans.com,2002;MyPackage Thank you both for humoring me. YAML needs something clean like this for its type identifiers. I would prefer the NID be something other than 'dns'. As it stands it suggests that it in some way related to DNS when it really isn't except for the firs section. But 'pkg' doesn't seem right either since that suggests Java packages instead of what YAML wants to do with 'em. Got any other suggestions? -MM -- Michael Mealling| Vote Libertarian! | urn:pin:1 [EMAIL PROTECTED] | | http://www.neonym.net
Re: DNS based URI without any set access semantics?
On Thu, Jul 25, 2002 at 01:31:11PM -0700, Karl Auerbach wrote: | On Thu, 25 Jul 2002, Clark C . Evans wrote: | |- it uses DNS to gaurentee uniqueness | | That's not a solid foundation for uniqueness. There are multiple DNS | spaces in use. One is almost completely dominant, but others do exist. It's good enough. | The object identifier space used for MIBS is much more usable for | uniqueness. Too obscure. With the Internet DNS system I can go to one of many sites, pay my $11 ransom and rent a domain name for a year. Even my aged aunt grocks DNS. ;) Clark -- Clark C. Evans Axista, Inc. http://www.axista.com800.926.5525 XCOLLA Collaborative Project Management Software
Re: DNS based URI without any set access semantics?
On Thu, 25 Jul 2002 17:01:45 EDT, Clark C . Evans said: On Thu, Jul 25, 2002 at 01:31:11PM -0700, Karl Auerbach wrote: | That's not a solid foundation for uniqueness. There are multiple DNS | spaces in use. One is almost completely dominant, but others do exist. It's good enough. OK... why do we want to datestamp it in case it changes owners, but it's good enough to discard the existence of alternate DNS roots? Remember to discuss what semantics you wish to assign that would make the different 1997 and 2001 values of '.foobar.com' important to distinguish (given that quite possibly *both* values are no longer valid in the DNS) but you don't care about disambiguating two syntactically identical names that *are* valid in different namespaces. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg08952/pgp0.pgp Description: PGP signature
Re: DNS based URI without any set access semantics?
- it uses DNS to gaurentee uniqueness The DNS does not guarantee uniqueness outside of a TTL; you need a timestamp to accomplish this. - next is a domain name in *small caps* Do you mean lower-cased? - a standard httpish path per URI specification. There are a lot of does this match that rat holes here. as an example, are: pkg://clarkevans.com./ and pkg://clarkevans.com/ the same? How about pkg://clarkevans.com/data-type and pkg://clarkevans.com/data-typ%BC or pkg://clarkevans.com/data-type%bc Saying something other than httpish may be useful here. Examples: pkg://clarkevans.com pkg://clarkevans.com/data-type pkg://clarkevans.com/2002/my-data The end goal is (a) to have a DNS based URN and (b) not have this URN imply any sort of access mechanism (http,ftp,etc.) For XML-DEV people... What do you think? Pretend for a moment that this is 1997 and XML is just about to emerge. Would something like this have helped? Please limit comments to what the URI change will impact, not about general problems with XML namespaces and such soap boxes. Ok. Now, given today, if it took a while to catch on would it improve the situation (mod other namespace problems)? If not, why? Anyway, if you are interested, I'm going to attempt to carry out this conversation over on the ietf's discussion list at http://www1.ietf.org/mail-archive/ietf/Current/index.html in a manner independent of XML. I'll be observant of replys to the xml-dev list, but I'm not at all interested in the xml-namespace soapbox. ;) The URI mailing list may be a better home. Ted Hardie
Re: DNS based URI without any set access semantics?
On Thu, Jul 25, 2002 at 04:39:12PM -0400, Michael Mealling wrote: | On Thu, Jul 25, 2002 at 04:36:22PM -0400, Clark C . Evans wrote: | Ok, would this fly? | | urn:dns:yaml.clarkevans.com,2002;MyPackage | | Thank you both for humoring me. YAML needs something clean | like this for its type identifiers. | | I would prefer the NID be something other than 'dns'. As it stands | it suggests that it in some way related to DNS when it really isn't | except for the firs section. But 'pkg' doesn't seem right either since | that suggests Java packages instead of what YAML wants to do with 'em. | Got any other suggestions? Right on. Hmm. I suppose at the very worst we could use yaml. But something a bit more generic (so XML fellas can use it too) would be preferable. ideas: type domain inet (internet) zoom (just for fun) dbi(domain based identifier) dbn(domain based name) nmsp (namespace... although I don't like this as much) rdns (reverse dns ... urn:rdns:com.clarkevans.yaml,2002;MyPackage) class (object's class) dnscls (domain name system class ) Buggers. This is tough. Clark -- Clark C. Evans Axista, Inc. http://www.axista.com800.926.5525 XCOLLA Collaborative Project Management Software
Re: DNS based URI without any set access semantics?
On Thu, Jul 25, 2002 at 03:40:07PM -0400, Keith Moore wrote: | 1. it doesn't matter whether the components are reversed or not. | 2. you do need a date, because domain names change hands. | 3. it's not a good idea to embed any more human-meaningful content |in a URN than necessary to get uniqueness. Great! | URN:dns:f.q.d.n:date:unique-suffix How about... urn:dns:f.q.d.n,year;unique-suffix where ;unique-syntax is optional better to make it required; it encourages more responsible behavior. you don't want people creating a new prefix for each new URN. at least not if you ever hope to make these things resolvable. | f.q.d.n fully-qualified domain name Yes. And to make sure that these thingys can be compared via strcmp, the f.q.d.n should be using only lower-case letters. fine. | datedate in the form MMDD (exactly 8 digits) I was thinking just a year as most registries renew once a year. In particular, how about allowing a person to use year if they are the valid domain name holder at exactly midnight January 1st of that year. the year is not precise enough as domain ownership doesn't change on year boundaries, and domain ownership can change more than once in a year. | unique-suffix a suffix that is uniquely and permanently assigned to a | particular resource. it's strongly recommended that this |be a string of digits or other meaningless ascii characters | rather than a human-meaningful string. I see no problem with it being human readable. The point is that there isn't a protocol associated with the URI, not that it is a pain to remember. If it is a pain to remember, no one will use it. In this case, why even use DNS? The problem is that I need globally unique URIs that are easy to remember and that don't imply a particular protocol, like http. you're trying to use the wrong tool, then. URNs are intended to to be globally unique and to keep their bindings forever. making them human meaningful degrades their ability to fulfill that function, because the meaning of human languages changes over time. the reason for using DNS is that they're globally unique (at a particular time) and people already understand them and often know how to get a DNS name. also with DNS names there is some potential for using DNS to resolve URNs with those names - at least those for which the domain name holder at the time the URN was assigned is currently the holder of that domain name. | I'm tempted to suggest that the f.q.d.n:iso-date portion be hashed with MD5 | and encoded in base64, just so that the URN doesn't pretend to have any | semantics associated with it. but if we leave the DNS name intact then | it's easier to build a resolver for it that uses DNS. that's also why | I would like to see the date be an exact length - it's easier (though | still ugly) to match date ranges in NAPTR records that way. See above. I hope the year suggestion works for you. sorry, no. Keith
