Subject: [URN] Draft pre-release of File Resolver config doc

From: Justin Couch <[email-masked]>
Date: Fri, 12 Mar 1999 10:24:10 +0800

Being a complete newbie to the RFC process, I have a first cut draft of
the doc for the File based resolver available. Before I send it off to
Internet-Drafts would some of you mind casting a quick eye over it and
tell me of anything that I've screwed up.

The doc can be found at

http://www.vlc.com.au/~justin/java/urn/draft-ietf-urn-file-rds-00.txt

If it is all OK, I'll submit it on Monday. 

The multiple RDS handling draft should be following in about a week. 

-- 
Justin Couch                                   Author, Java Hacker
Snr Software Engineer                     [email-masked]
ADI Ltd, Systems Group, CCIS        http://www.vlc.com.au/~justin/
Java3D FAQ:       http://tintoy.ncsa.uiuc.edu/~srp/java3d/faq.html
-------------------------------------------------------------------
"Look through the lens, and the light breaks down into many lights.
 Turn it or move it, and a new set of arrangements appears... is it
 a single light or many lights, lights that one must know how to
 distinguish, recognise and appreciate? Is it one light with many
 frames or one frame for many lights?"      -Subcomandante Marcos
-------------------------------------------------------------------

---

From: "Aaron E. Walsh" <[email-masked]>
Date: Wed, 31 Mar 1999 19:04:44 -0500

Hi Justin,

Ok to pass along to the Universal Media group as well, or would you like
to have it hold here for a while?

Cheers,
Aaron

> The multiple RDS handling draft should be following in about a week.

Date: Wed, 31 Mar 1999 19:04:44 -0500
From: "Aaron E. Walsh" <[email-masked]>
Subject: Re: [URN] Draft pre-release of File Resolver config doc
To: Justin Couch <[email-masked]>
Cc: IETF URN WG <[email-masked]>
Organization: Mantis Development Corp.
Sender: [email-masked]
Reply-To: "Aaron E. Walsh" <[email-masked]>

Hi Justin,

Ok to pass along to the Universal Media group as well, or would you like
to have it hold here for a while?

Cheers,
Aaron

> The multiple RDS handling draft should be following in about a week.

Date: Wed, 31 Mar 1999 19:02:51 -0500
From: "Aaron E. Walsh" <[email-masked]>
Subject: Re: [URN] status
To: Leslie Daigle <[email-masked]>
Cc: [email-masked]
Organization: Mantis Development Corp.
Sender: [email-masked]
Reply-To: "Aaron E. Walsh" <[email-masked]>

Hello Leslie and all,

I'm preparing now to register a few URN namespaces, and wonder if you or
others could point me towards the proper documents to file? I understand
this isn't as simple a process as simply submitting an online form, as
we do for domains through InterNic, so want to make sure I'm heading in
the right direction :)

Cheers,
Aaron

Leslie Daigle wrote:
> 
> Hello again,
> 
> The logical follow-on question to my last mail is: "what's left to do?"
> to which the answer is, blissfully, "not much" -- at least for the Working
> Group.  Clearly, things are picking up steam in the development and
> user communities.
> 
> Specific things left on the table for this working group:
> 
>         A URN Namespace for IETF Documents
> 
> This document is essentially done.  Destined for "informational" status,
> we've been waiting to last-call it to be sure that the "URN Namespace
> Definition Mechanisms" document (to which the above is meant to comply) is
> acceptable to the IESG.  That went up last Fall, and I have not been
> able to get an answer from Keith as to whether it is just stuck
> in the normal backlog of things, or if there are actually issues with it.
> I hope to find out by/at Minneapolis.
> 
> Leslie.
> 
> ------------------------------------------------------------------------------
> 
>   "Never confuse                               Leslie Daigle
>      an appreciation of the simple
>               for                              Bunyip Information Systems Inc.
>      a lack of understanding of the complex."  +1 514 285 0088
>                   -- ThinkingCat               [email-masked]
> 
> ------------------------------------------------------------------------------

Date: Fri, 26 Mar 1999 10:49:49 +0800
From: Justin Couch <[email-masked]>
Organization: ADI Ltd Systems Group
To: IETF URN WG <[email-masked]>
Subject: [URN] ANN: Java URI Code v0.6
Sender: [email-masked]
Reply-To: Justin Couch <[email-masked]>

This is a multi-part message in MIME format.
--------------384232FD988F7C3CB8DF1B82
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

A new update to the URI code is now available.

v0.6 gets me much further along the line of being able to completely
replace the java.net packages with something sane that can handle URNs
That is, I've put in a huge effort to up the number of supported
protocol types to include all of the common ones except FTP. I've added
the changes.txt file below to see the amount of upgrades that I've done.

A new trivial THTTP resolver has been added. The DNS NAPTR resolver has
not yet made it to the public release because the licensing restricts it
from commercial use. I may release that as a separate package.

This release proves the multiple RDS handling concepts that I have been
writing about. The THTTP handler was almost trivial to write once the
HTTP handler was in place (about 14 hours it took). Assuming other
libraries are available, other resolvers should take around the same
time making this an excellent platform for prototyping new resolver
schemes without modifying application code. 

-- 
Justin Couch                                   Author, Java Hacker
Snr Software Engineer                     [email-masked]
ADI Ltd, Systems Group              http://www.vlc.com.au/~justin/
Java3D FAQ:       http://tintoy.ncsa.uiuc.edu/~srp/java3d/faq.html
-------------------------------------------------------------------
"Look through the lens, and the light breaks down into many lights.
 Turn it or move it, and a new set of arrangements appears... is it
 a single light or many lights, lights that one must know how to
 distinguish, recognise and appreciate? Is it one light with many
 frames or one frame for many lights?"      -Subcomandante Marcos
-------------------------------------------------------------------
--------------384232FD988F7C3CB8DF1B82
Content-Type: text/plain; charset=us-ascii; name="changes.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="changes.txt"

URI Class libraries
--------------------

Changes between 0.5 and 0.6
----------------------------

- Rewrote the internals of URL. Now no longer delegates to java.net.URL. All
done internally.

- Added method to strip a file into path, query and reference parts to
URIUtils. Required some heavy reorganisation of URIUtils internally. Lots of
new smaller methods to do stuff.

- Added convenience method to URIUtils to take a string and return a URI
object.

- Made some changes to protocol.file.FileResourceConnection to deal with
query parts. Was handling these wrong and looking for a filename with with ?
as part of it if there was a query string.

- Added last modified time to ResourceConnection. Updated
FileResourceConnection to override this which returns File.lastModified.

- Added text/uri-list content handler

- Added simple data: protocol handler.

- Fixed bug in text/plain content handler for the read from stream. Was reading
too many characters that were being appended to the string buffer.

- HttpResourceConnection now deals with proxy information and fields for
allowing the use of cookies.

- Basic implemetation of HttpResourceConnection using Innovation HTTPClient
classes (LGPL'd) - http://www.innovation.ch/java/HTTPClient/ . Does all the
standard stuff, plus PUT/POST, but nothing special. Can fetch images etc.

- due to the nature of the HTTPClient code, this allows _very_ quick adaption
to include HTTPS and SHTTP as well. Problem is that no authentication system is
currently available (on the TBD list) so it sorta doesn't work. At least it
finds the handlers and loads them

- added x-java/jar content handler to load JAR files from a network

- added JarResourceConnection based class and implementation. JAR URLs are now
extended from the base Sun definition allowing you to describe a JAR file using
a URN as the location eg urn:x-java:myfile.jar!/someclass.class that will use
the URN system to automatically locate a JAR file.
  o Should implement a resolver type that looks in the classpath for these files.
  o Should implement a URNClassLoader to take advantage of this.

- Strip excess constants from URI that were in URIConstants and all the default
port stuff from URI. URI.getDefaultPort marked deprecated - to be removed in
v0.7

- error in URIUtils parsing of authority. When parsing file:/// it worked fine
but for JAR URLs that had jar:file:/// it mistakenly thought that file: was the
authority definition. It now first checks for the existance of // before
looking for the authority section.

- removed dead code in file based resolver Resolver and FileParser

- Added THTTP resolver. Only handles text/uri-list at this stage. HTML handler
to come shortly and same with redirects for N2R. Not tested yet.

Justin Couch
25 March 1999
--------------384232FD988F7C3CB8DF1B82--

Date: Wed, 24 Mar 1999 17:30:14 +0800
From: Justin Couch <[email-masked]>
Organization: ADI Ltd Systems Group
To: IETF URN WG <[email-masked]>
Subject: [URN] Public THTTP test servers?
Sender: [email-masked]
Reply-To: Justin Couch <[email-masked]>

I have an implementation of the THTTP resolver that I'd like to test.
Unfortunately, due to the nature of the environment here at work,
getting an implementation on the intranet is close to impossible or will
happen just before hell freezes over, whichever comes first. 

Would someone mind pointing me at a server and test URNs that I can
resolve please. I'd like to test this and the resolver implementations
before submitting the multiple RDS work.

FYI: URN impl code is screaming along. Handles almost everything now:
data, [s]http[s], file and jar. Only need to finish the FTP impl and we
should be on the way. There's been quite a bit of interest, just under
100 downloads over the past month and a bit. I also have at least one
serious interest in porting the code framework to Win32/C++.  
 
ADI Ltd, Systems Group              http://www.vlc.com.au/~justin/

Date: Fri, 12 Mar 1999 10:24:10 +0800
From: Justin Couch <[email-masked]>
Organization: ADI Ltd Systems Group
To: IETF URN WG <[email-masked]>
Subject: [URN] Draft pre-release of File Resolver config doc
Sender: [email-masked]
Reply-To: Justin Couch <[email-masked]>

The doc can be found at

Date: Thu, 11 Mar 1999 10:16:13 -0500
To: Michael Mealling <[email-masked]>, [email-masked]
From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>
Subject: Re: [URN] status
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>

At 09.45 -0500 1999-03-11, Michael Mealling wrote:
> I suspect that the ADs will identify a set of folx to act as reviewers
> for URN related issues in other documents.

Exactly, any takers?

I.e. I would like to have people "with clue" that can have a look at 
I-Ds that talk about naming of things. If you know about URNs, 
"ordinary URLs" and (the problems with) LDAP DNs and the domainname 
wars...let me know.

You can catch me in Minneapolis in the corridors or the bar if you 
want to talk about it.

And,...when we talk about reviewers in the IETF, we do not talk about 
any commitment from any side. We are only talking about the ADs 
having a list of people which one can ask for reviewing a document. 
At _that_ point, you say yes or no to do the job.

    paf

------------------------------------------------------------------
Area Director, Applications Area               Email: [email-masked]
IETF                                             URL: http://paf.se
                                          PGP Key ID: 0xBD236602

   In theory there is no difference between theory and practice,
   but in practice, there is.

Date: Thu, 11 Mar 1999 10:02:16 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: [URN] status
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

As one further thought to Michael's comments --  I suspect that the first
step is to publish (informational) RFCs; if there is enough momentum or
the need to bring efforts together, I think this will define a work item
worthy of a new working group, specifically focused on resolution services. 

Leslie.

------------------------------------------------------------------------------

  "Never confuse                               Leslie Daigle
     an appreciation of the simple                              
              for                              Bunyip Information Systems Inc.
     a lack of understanding of the complex."  +1 514 285 0088
                  -- ThinkingCat               [email-masked]
 
------------------------------------------------------------------------------

From: Michael Mealling <[email-masked]>
Subject: Re: [URN] status
To: [email-masked]
Date: Thu, 11 Mar 1999 09:45:26 -0500 (EST)
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

Justin Couch said this:
> Leslie Daigle wrote:
> > The logical follow-on question to my last mail is: "what's left to do?"
> > to which the answer is, blissfully, "not much" -- at least for the Working
> > Group.  Clearly, things are picking up steam in the development and
> > user communities.
> 
> I suppose I count myself as one of these.
> 
> As a follow-on to this post, where do we go after this WG? For example,
> what home should we find for building up a collection of RFC's for
> different resolver services? As URNs become popular, resolvers using
> X.500 services, file based and probably many others could do with some
> form of standardisation. Are there plans to form a follow up WG or
> maintain this one for that purpose?

Usually things like this are handled by simply publishing an informational
RFC on that particular subject. As needed the consituency can request
that the RFC be considered a proposed standard but ADs usually want some
review by some knowledgeable group before hand. Sometimes that requires
creating a Working Group, sometimes it doesn't.

I suspect that the ADs will identify a set of folx to act as reviewers
for URN related issues in other documents. If they think that a new
Working Group needs to be formed then we'll go through that process.

If things do get 'busy' then I think we may have to revisit some of the
registration issues in various documents...

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  [email-masked]

Date: Thu, 11 Mar 1999 15:31:08 +0800
From: Justin Couch <[email-masked]>
Organization: ADI Ltd Systems Group
To: Leslie Daigle <[email-masked]>
CC: [email-masked]
Subject: Re: [URN] status
Sender: [email-masked]
Reply-To: Justin Couch <[email-masked]>

Leslie Daigle wrote:

> The logical follow-on question to my last mail is: "what's left to do?"
> to which the answer is, blissfully, "not much" -- at least for the Working
> Group.  Clearly, things are picking up steam in the development and
> user communities.

I suppose I count myself as one of these.

As a follow-on to this post, where do we go after this WG? For example,
what home should we find for building up a collection of RFC's for
different resolver services? As URNs become popular, resolvers using
X.500 services, file based and probably many others could do with some
form of standardisation. Are there plans to form a follow up WG or
maintain this one for that purpose?

ADI Ltd, Systems Group              http://www.vlc.com.au/~justin/

Date: Tue, 9 Mar 1999 17:57:35 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Subject: [URN] status
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Hello again,

The logical follow-on question to my last mail is: "what's left to do?"
to which the answer is, blissfully, "not much" -- at least for the Working
Group.  Clearly, things are picking up steam in the development and
user communities.

Specific things left on the table for this working group:

	A URN Namespace for IETF Documents 

This document is essentially done.  Destined for "informational" status, 
we've been waiting to last-call it to be sure that the "URN Namespace 
Definition Mechanisms" document (to which the above is meant to comply) is
acceptable to the IESG.  That went up last Fall, and I have not been
able to get an answer from Keith as to whether it is just stuck
in the normal backlog of things, or if there are actually issues with it.
I hope to find out by/at Minneapolis.

Leslie.

------------------------------------------------------------------------------

  "Never confuse                               Leslie Daigle
     an appreciation of the simple                              
              for                              Bunyip Information Systems Inc.
     a lack of understanding of the complex."  +1 514 285 0088
                  -- ThinkingCat               [email-masked]
 
------------------------------------------------------------------------------

Date: Tue, 9 Mar 1999 17:52:29 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Subject: [URN] working group last call on 3 documents
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Hello all,

We're ready for working group last call on 3 documents:

	Assignment Procedures for URI Resolution using DNS    
	(draft-ietf-urn-net-procedures-02.txt)
	Target: BCP

	Resolution of Uniform Resource Identifiers using the Domain 
	Name System        
	(draft-ietf-urn-dns-rds-00.txt) 
	Target:  Standards Track

	The Naming Authority Pointer (NAPTR) DNS Resource Record     
	(draft-ietf-urn-naptr-rr-01.txt)
	Target:  Standards Track

Please review these documents and let the working group / author know
of any necessary changes by 5pm EST on Tuesday March 23, 1999 (i.e., 2 weeks
from today).

If there are no substantial problems with these documents, I will
forward them to the IESG for progression to RFCs.

Thanks,
Leslie.

------------------------------------------------------------------------------

  "Never confuse                               Leslie Daigle
     an appreciation of the simple                              
              for                              Bunyip Information Systems Inc.
     a lack of understanding of the complex."  +1 514 285 0088
                  -- ThinkingCat               [email-masked]
 
------------------------------------------------------------------------------

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-net-procedures-02.txt
Date: Mon, 01 Mar 1999 19:01:04 -0500
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Uniform Resource Names Working Group of the IETF.

	Title		: Assignment Procedures for the URI Resolution 
                          using DNS (RFC2168)
	Author(s)	: M. Mealling
	Filename	: draft-ietf-urn-net-procedures-02.txt
	Pages		: 8
	Date		: 26-Feb-99
	
   RFC2168 defines a DNS resource record and an algorithm for using DNS
   as a registry for retrieving URI delegation rules (sometimes called
   resolution hints). That document specifies that the first step in
   that algorithm is to append 'uri.net' to the URI scheme and retrieve
   the NAPTR record for that domain-name.  I.e., the first step in
   resolving 'http://foo.com/' would be to look up a NAPTR record for
   the domain 'http.uri.net'. URN resolution also follows a similar
   procedure but uses the 'urn.net' zone as its root. This document
   describes the procedures for inserting a new rule into the 'uri.net'
   and 'urn.net' zones.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-urn-net-procedures-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-urn-net-procedures-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-urn-net-procedures-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-urn-net-procedures-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-urn-net-procedures-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-net-procedures-02.txt
Date: Mon, 01 Mar 1999 19:01:04 -0500
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Uniform Resource Names Working Group of the IETF.

	Title		: Assignment Procedures for the URI Resolution 
                          using DNS (RFC2168)
	Author(s)	: M. Mealling
	Filename	: draft-ietf-urn-net-procedures-02.txt
	Pages		: 8
	Date		: 26-Feb-99
	
   RFC2168 defines a DNS resource record and an algorithm for using DNS
   as a registry for retrieving URI delegation rules (sometimes called
   resolution hints). That document specifies that the first step in
   that algorithm is to append 'uri.net' to the URI scheme and retrieve
   the NAPTR record for that domain-name.  I.e., the first step in
   resolving 'http://foo.com/' would be to look up a NAPTR record for
   the domain 'http.uri.net'. URN resolution also follows a similar
   procedure but uses the 'urn.net' zone as its root. This document
   describes the procedures for inserting a new rule into the 'uri.net'
   and 'urn.net' zones.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-urn-net-procedures-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-urn-net-procedures-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-urn-net-procedures-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-urn-net-procedures-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-urn-net-procedures-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--