- From: Paul Hoffman <ietf-lists@proper.com>
- Date: Wed, 14 Jun 1995 20:35:40 -0700
- To: uri@bunyip.com
- Cc: weibel@oclc.org
About a week ago, in my response to the OCLC proposal, I said: >RPs >I like this idea very much. Assuming that the RPs are generated >by the client software resolving a registered NA and seeing >which of the hosts it prefers, this has many big advantages over >our DNS-only scheme. More kudos for this. On further thought, I'd like to retract my "I like this idea very much". I believe that RPs (resolution paths) that are specified as part of an electronic or printed URN string are a Bad Idea. Basically, including RPs in electronic or printed URN strings can lead to incorrect resolution of the URNs. Consider the short example of a URN with an RP from the original text: N2L:/ncsa.uiuc.edu:120/RFC/paper1.1995 Now consider the situation five years from now. What if the owner of the name "RFC" no longer wants ncsa.uiuc.edu to keep resolving its names, but the people at ncsa.uiuc.edu choose to do so against the wishes of the owner of RFC? People resolving the URN would be getting the resolution from a source now known to be bad, possibly even malicious (apologies to anyone at UIUC!). If ncsa.uiuc.edu stops resolving URNs for RFC, the resolution will continue correctly. However, even in this case, every access to that URN will cause wasted bandwidth and wasted user time because they will contact ncsa.uiuc.edu and get a negative response or, worse, a timeout. Make the RP list three or four out-of-date hosts and resolving a URN will become a tedious process. I believe that we should avoid putting any such list in URN representations. --Paul Hoffman --Proper Publishing
Received on Wednesday, 14 June 1995 23:47:23 UTC