Subject: Re: [URN] NAPTR to SRV
From: Erik Guttman <[email-masked]>
To: Ron Daniel <[email-masked]>
Cc: "Dirk.vanGulik" <[email-masked]>, [email-masked]
Date: Tue, 10 Sep 1996 13:17:48 -0700

> Thus spoke Dirk.vanGulik (at least at 10:04 AM 9/9/96 +0200)
> 
> >Whould it be an idea to insist on using the IANA registered 
> >service/protocol pairs ?
> >
> >And if this the case one could 'automagically' construct
> >the _service._protocol.hostname query.
> 
> The service/proto fields in SRVs may use either IANA assigned
> or locally assigned identifiers. Since they can use locally
> assigned names, we need to be able to cope with that, so I would
> be very hesitant to impose such a restriction.

For locally defined service types, or cases where there are multiple
services which are not identical, the Service Location Protocol
offers a resolution service.  SLP is intended to be used within
sites to allow lightweight registration and acquisition of service
advertisments.  Have you considered resolving some requests using SLP?

Erik Guttman

Date: Mon, 09 Sep 1996 09:18:23 -0600
To: "Dirk.vanGulik" <[email-masked]>, [email-masked]
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] NAPTR to SRV
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Dirk.vanGulik (at least at 10:04 AM 9/9/96 +0200)

>Whould it be an idea to insist on using the IANA registered 
>service/protocol pairs ?
>
>And if this the case one could 'automagically' construct
>the _service._protocol.hostname query.

The service/proto fields in SRVs may use either IANA assigned
or locally assigned identifiers. Since they can use locally
assigned names, we need to be able to cope with that, so I would
be very hesitant to impose such a restriction.

Ron Daniel Jr.                       email: [email-masked]
Advanced Computing Lab               voice: +1 505 665 0597
MS B287                                fax: +1 505 665 4939
Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM, USA  87545    obscure_term: "hyponym"

From: [email-masked]
To: [email-masked]
Date: 	Fri, 6 Sep 1996 10:04:14 ARG3
Subject: [URN] Priority: normal
Sender: [email-masked]
Reply-To: [email-masked]

Date: Mon, 9 Sep 1996 10:04:51 +0200
From: "Dirk.vanGulik" <[email-masked]>
To: [email-masked]
Subject: [URN] NAPTR to SRV
Sender: [email-masked]
Reply-To: "Dirk.vanGulik" <[email-masked]>

I've been trying to get all integrated; the apache-module,
a small mSQL based resolver and a little glue and display
in html logic.

I've ran into a couple of points.

Whould it be an idea to insist on using the IANA registered 
service/protocol pairs ?

And if this the case one could 'automagically' construct
the _service._protocol.hostname query. I.e. Things get
simplified to

IN NAPTR 10 5 "s" "http+N2L" infoservices.webweaving.org ""
IN NAPTR 10 5 "s" "sftp+N2L" infoservices.webweaving.org ""
IN NAPTR 10 5 "s" "rcds+N2L" infoservices.webweaving.org ""

_http._tcp.infoservices.webweaving.org 
	IN SRV 0 0 80 wwww.infoservices.webweaving.org

_rcds._udp.infoservices.webweaving.org 
	IN SRV 0 0 1112 exp.infoservices.webweaving.org

Just a thought; because I quite dislike the redundancy in
the NAPTR pntr.

Dw.

To: [email-masked]
Subject: [URN] terminating dots
Date: Sun, 08 Sep 1996 17:12:15 +0100
From: Martin Hamilton <[email-masked]>
Sender: [email-masked]
Reply-To: Martin Hamilton <[email-masked]>

The domain names in the sample NAPTR records from draft-daniel-naptr-01
are missing the closing dot ?  Think it should be:

  _dunslink._udp.isi.dandb.com. 

rather than:

  _dunslink._udp.isi.dandb.com

Just nitpicking, but it makes quite a difference if you leave that last
dot out in the DNS server config...

Martin

From: Terry Allen <[email-masked]>
Date: Tue, 3 Sep 1996 11:02:02 PDT
To: Ron Daniel <[email-masked]>, [email-masked]
Subject: Re: [URN] more info on edits for NAPTR draft
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

>[POSIX] IEEE Standard for Information Technology - Portable Operating
        System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1);
        IEEE Std 1003.2-1992; ISBN:1-55937-255-9; The Institute of
        Electrical and Electronics Engineers; New York; 1993.

>OK?

Okay.  I wonder if there is already an FPI for it.  Will ask around.

Regards,

-- 
       Terry Allen      O'Reilly & Associates, Inc.   [email-masked]
 "In going on with these experiments, how many pretty systems do we build,
  which we soon find ourselves obliged to destroy?"  -  Benjamin Franklin
        A Davenport Group sponsor     http://www.ora.com/davenport/

Date: Tue, 03 Sep 1996 10:34:47 -0600
To: [email-masked]
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] more info on edits for NAPTR draft
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke [email-masked] (at least at 01:08 PM 9/2/96 +0200)
>I like EREs too.
>The draft should probably cite POSIX by chapter, verse, month, day and
>hour of publication about where REGEXP is defined; if we get confusion
>about this, the whole thing falls down.

Right, will do.

The entry for the references section will look like

[POSIX] IEEE Standard for Information Technology - Portable Operating
        System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1);
        IEEE Std 1003.2-1992; ISBN:1-55937-255-9; The Institute of
        Electrical and Electronics Engineers; New York; 1993.

While the citation in the text will point people to section 2.8.4 "Extended
Regular Expressions" of [POSIX].

OK?

Ron Daniel Jr.                       email: [email-masked]
Advanced Computing Lab               voice: +1 505 665 0597
MS B287                                fax: +1 505 665 4939
Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM, USA  87545    obscure_term: "hypernym"

From: Terry Allen <[email-masked]>
Date: Mon, 2 Sep 1996 13:41:41 PDT
To: [email-masked]
Subject: [URN] Re URN concerns
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

[lost my electronic copy, so typed in the quotes from printed version]

Karen Sollins writes:
"I have a couple of concerns ...  It seems that in discussion, whether
 or not in the text of the documents, the authors of the NAPTR framework
 and proposal papers want to provide resolution for all possible 
 namespace schemes."

I hope so.  That is the problem as I see it.  Karen continues:

"Perhaps we would all be better off and have a higher probability of
 success, if we identified a smaller set of namespaces to which we 
 were addressing out attention."

I don't see where there is lack of success brewing.  

 - It is up to namespace resolvers to resolve URNs to something else
   such as URLs.  The NAPTR scheme can't guarantee that will happen,
   only that the client gets pointed at the right resolver.

 - You can make a more elegant solution by restricting the problem,
   but then you haven't solved the real problem.  Suggestions for
   how to create easily manageable name spaces are worth making,
   but people will do what they will do.  Restricting the namespaces
   that the point-client-toward-resolver mechanism can use fails to
   solve the real world problem, and guarantees that the solution
   will fail to cover all real world cases, making it useless.

 - Instead of viewing opaque strings as a problem, it would be useful
   to accept that they exist and can be exploited; regexps (funky though
   they are) appear to this lost soul to be a way to exploit info that
   may be known to reside in opaque strings.

 - It's time to get the show on the road.  I am looking forward to being
   able to provide hands-off resolution of Docbook DTD entities using
   NAPTR and the Docbook FPIs.  When ANSI appoints a formal registration
   authority (currently thought to be the Graphic[al]? Communications
   Association, GCA), the registry that GCA has already set up can point
   to the Davenport site, which already exists, and we can resolve FPIs
   both registered and unregistered.  Talking about how it would be
   nicer if we could constrain how naming schemes work is unrealistic
   (we can't, and no one has offered a counterargument that we can), and 
   dilatory.

   Beyond that, SGML *is* coming to the Internet, and fairly soon.  Modern
   SGML entity resolution depends on FPIs and catalogues containing them.
   FPIs are made up by humans, and beyond the owner identifier and the
   (nonhierarchically placed) field indicating (uselessly) whether an FPI
   applies to an element, entity, DTD, etc., there is a lot of opportunity
   (which has already been taken advantage of) for messiness.  

   There is thus a practical need to be able to resolve any FPI anyone
   may assign or has already assigned.  Constraining FPI construction
   beyond the rules in (I believe) ISO 9070 is a nonstarter.

Regards,

-- 
       Terry Allen      O'Reilly & Associates, Inc.   [email-masked]
 "In going on with these experiments, how many pretty systems do we build,
  which we soon find ourselves obliged to destroy?"  -  Benjamin Franklin
        A Davenport Group sponsor     http://www.ora.com/davenport/

From: [email-masked]
To: Ron Daniel <[email-masked]>
Cc: [email-masked]
Subject: Re: [URN] more info on edits for NAPTR draft
Date: Mon, 02 Sep 1996 13:08:50 +0200
Sender: [email-masked]
Reply-To: [email-masked]

I like EREs too.
The draft should probably cite POSIX by chapter, verse, month, day and
hour of publication about where REGEXP is defined; if we get confusion
about this, the whole thing falls down.

          harald A