Subject: [Enum] service field

From: Lawrence Conroy <[email-masked]>
Date: Fri, 28 Jun 2002 19:21:55 +0100

Hi Folks,
- protocol # URI-scheme. Initial reaction - are you kidding? 
Subsequent reaction - obviously not, as it's repeated.
If you want to specify the protocol to be used (or sub-protocol), 
then write up a draft to put this as a URI parameter.

Yes, Rich, you could put this into the service field instead of the 
URI-scheme, IF someone writes the RFCs to define the label for each 
protocol that can be used (and ensures that this fits with the 
URI-scheme generated from the NAPTR), and opens a new protocol-label 
tree with IANA.
However, I WANT the the NAPTR service field to be restricted to 
including URI-scheme, at least for now.
Basically, protocol in the services field over my dead and smoking 
body. Put it in the URI if someone needs it.

Get it through the IETF; convince the OS/Application companies to 
change their URL handler APIs, and then I might look at it, but now?

I understand that urn: does not tell me how to access the resource. 
This probably explains why it's such a stellar success; considering 
all of the "select your nearest mirror to download" pages I traverse, 
there is a definite need out there, and yet...
As for mailto: using either IM or SMTP, so? I have a handler that 
works quite well with such URLs. I don't have a problem putting a 
mailto: URL on a web page, or on clicking on the link and it firing 
up a local handler. Judging from the volume of junk emails I get, 
handling a mailto: URL on my web page works for at least some folks.

Forgive the sting, but I have the rare joy of focusing on making this 
stuff work in real end systems, using real (existing) URL handlers, 
and with real DNS entries, set up by real people using web pages to 
make it all look half intelligible. My last good choice was tracking 
SIP for the PINT work, when that changed syntax every two weeks 
(around the time of mmusic-sip-06). Now it looks like I have the same 
problem here.

Finally, given that Rich (and others) think that the URI-scheme is a 
MUST, PLEASE let's not put the URI-scheme as an addendum on every 
enumservice - it really SHOULD be a separate sub-field on its own in 
the NAPTR service field.
Also, can folks please use examples with more than one 
service/function/category? The syntax choices are more obvious in 
that case, IMHO.

all the best,
   Lawrence
-- 
[email-masked]: +44 1794 833666::<my opinions>:

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Michael Mealling <[email-masked]>
Date: Fri, 28 Jun 2002 14:43:58 -0400

> then write up a draft to put this as a URI parameter.

URI parameter? Are you seriously suggesting we tell the existing
URI schemes to change their definitions when the explicitly _don't_
want something like that in there?

> URI-scheme generated from the NAPTR), and opens a new protocol-label 

You don't define an RFC for each one unless that's what you want to do.
Most already define that. HTTP says "hey, use whatever URI you want
here, that's what its for".

> including URI-scheme, at least for now.

So the working group has to limit the standard to what you're willing
to implement right now?

> body. Put it in the URI if someone needs it.

Ok, here's the typical question we have to ask when a statement
like this comes up: what part of your implementation _breaks_ if it
is in there?

> change their URL handler APIs, and then I might look at it, but now?

Huh? I really don't follow that statement. You do realize that
most (all?) URI specifications make a very distinct seperation between what
they identify and what protocol you can use to talk about them. That's
at the entire core of what URIs are and why they're used. That's the
entire basis of how things like web caching, middle boxes, etc work.

> handling a mailto: URL on my web page works for at least some folks.

The job here is to define protocols that work _in the future_ given
what we know now. Just about everyone here realizes the need for
a protocol and understands why URIs explicitly divorce themselves
from a given transport. I think you are confusing what you happen to 
use in a web browser with web architecure and why things are the way
they are. The web is _not_ constrianed to what you see in your browser.

> stuff work in real end systems, using real (existing) URL handlers, 

Ever written a URL handler? I have....

> (around the time of mmusic-sip-06). Now it looks like I have the same 

I actually don't think we have that problem. So far I think you're voice
is the only one being this adament about 'protocol' vs 'URI scheme' and
it really sounds like its from a misunderstanding of web architecture
and the role of URIs in it. Unless you're suggesting we just through
out the architecture?

> enumservice - it really SHOULD be a separate sub-field on its own in 

What I keep wondering is why you need to know the URI scheme when the
protocol defines what set of URI schemes it can handle. I.e. the protocol
'foo' can handle 'bar:' and 'baz:' URI schemes. Why does it matter which
one is actually in the REGEXP field?

> service/function/category? The syntax choices are more obvious in 

I personally can only see service+protocol. I don't see any
differences between 'service', 'function' or 'category'....

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net