Subject: Question about <draft-ietf-cnrp-uri-00.txt>

From: Graham Klyne <[email-masked]>
Date: Tue, 22 Feb 2000 17:51:02 +0000

I have a question...

>2. Syntax Rules
>
>    The CNRP URI comes in two forms:
>
>       cnrp://<host>:<port>/<path>?<common-name>[;<attribute>=<value>]*

What purpose does it serve to specify the port number wen the protocol is
unknown?

[...]

#g

------------
Graham Klyne
([email-masked])

---

From: Michael Mealling <[email-masked]>
Date: Tue, 22 Feb 2000 13:04:26 -0500

> I have a question...

Great!!!

> What purpose does it serve to specify the port number wen the protocol is

It probably doesn't. That may have been inadvertently left
in there. It just has to be clear who has precedent. If we
want to have this in the SRV record (where the NAPTR algorithm
puts it) then fine. If we decide to not use the whole NAPTR
thing then its gotta be wherever the transport is specified.

I'll remove that bit for now...

-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]

---

From: Keith Moore <[email-masked]>
Date: Thu, 24 Feb 2000 16:24:37 -0500

For that matter, why is the host identifier part of the URI?
I thought cnrp queries were supposed to be independent of any
particular service.

Keith

---

From: Michael Mealling <[email-masked]>
Date: Thu, 24 Feb 2000 16:20:36 -0500

> I thought cnrp queries were supposed to be independent of any

There is a form that has no host portion. The host is so that
someone can point to a particular entry in a particular service.
I.e. with a host and ID in the query you can point to a specific
entry. This allows you to put it in an HREF (or other similar,
navigation oriented places).

IMHO, the case with no host will be more common but others disagree.

-MM

---

From: Michael Mealling <[email-masked]>
Date: Thu, 24 Feb 2000 16:33:49 -0500

On Thu, Feb 24, 2000 at 04:33:55PM -0500, Keith Moore wrote:
> seems like the host should be specified separately, not as part of the URI.
> and you should be able to put the URI in an HREF regardless of whether
> it has a host component.

The desire is to not have multiple hits come back from multiple
services. Yes you can put this in an HREF but you won't know which
common-name the author of the HTML intended for you to use.

Here's a scenario:

I put up a web page about myself. In a section I say this:
<A HREF="cnrp://host/?id=123456">This</A> is my common-name.

Now, since there may be more than one of me I want to be specific
about the entry so that someone can use it and cache it, I have to
specify which "Michael Mealling" I'm talking about. Since IDs are
only unique per host (service), I have to give both the host and
the ID in order to talk excplicity about me.

Now, if I was writing a section of my web page like this:
And <A HREF="cnrp:Michael%20Mealling">here</A> are all of the other
"Michael Meallings" in the world!

Then putting the host in there would be a bad thing since it would
limit my results to some subset of the world which would defeat the
purpose of the whole sentence.

Does that clear it up?

-MM

---

From: Keith Moore <[email-masked]>
Date: Thu, 24 Feb 2000 16:33:55 -0500

---

From: Keith Moore <[email-masked]>
Date: Fri, 25 Feb 2000 01:50:21 -0500

> common-name the author of the HTML intended for you to use.

If common names are *ever* dependent on server hosts then they're
broken, pure and simple.    It's one thing to have a common name
which is dependent on some context, but that context should never
be inherently associated with the server host.

Keith

---

From: Michael Mealling <[email-masked]>
Date: Fri, 25 Feb 2000 06:09:38 -0500

> be inherently associated with the server host.

A "common-name" by itself is never dependent on anything. Its just
a string of syntax free characters. This thing isn't a common-name.
Its a URI for encoding the various aspects the common-name resolution protocol
needed to talk about a specific common-name or set of common-names.

-MM

---

From: Keith Moore <[email-masked]>
Date: Fri, 25 Feb 2000 09:37:11 -0500

> Its a URI for encoding the various aspects the common-name resolution
> protocol needed to talk about a specific common-name or set of
> common-names.

okay fine.  but if you are using a 'host' parameter to distinguish
between one Michael Mealling and another, that still seems like a bug.

Keith

---

From: Michael Mealling <[email-masked]>
Date: Fri, 25 Feb 2000 10:01:06 -0500

> between one Michael Mealling and another, that still seems like a bug.

Correct. It doesn't really distinguish one person from another. It
just allows me to talk about one particular record. Nothing about the
host says whether I'm the _real_ Michael Mealling. That's all in
the actual context of the queries and/or results (if anywhere).

-MM

---

From: Rick H Wesson <[email-masked]>
Date: Fri, 25 Feb 2000 07:18:06 -0800

Is there any resource discovery so that all authortative servers for a
single common name can be discovered?

I don't understand the solution "common names" are solving if we can't
traverse a set of authorative hosts to query.

-rick

---

From: Michael Mealling <[email-masked]>
Date: Fri, 25 Feb 2000 10:14:37 -0500

> single common name can be discovered?

Not in the scope of this group. I also think your question might
be anathema to one of our design assumptions which is that you can't
'own' or be 'authoritative' for a common-name. You can own records
in your database but you can't own or enforce authoritativeness (is that
a word?) for the actual common-name.

> traverse a set of authorative hosts to query.

The solution that CNRP is solving is to standardize access to
servers that contain "common-names". That might sound trivial at
first but its a chunk we can swallow and it allows us to educate
ourselves about the problem space without getting into the endless
political wrangling that "discovery" would cause.

For just a taste of what we're trying to avoid, try and define (to yourself!)
"authoritative" in a way that doesn't make someone mad enough
to leave the room... ;-)

-MM