RE: [Enum] enumservices in new version of 2916bis

["Conroy, Lawrence (SMTP)" <[e-mail]>]

Hi Folks,
   whilst on the topic of issues for the agenda...
I am glad that someone has been discussing the format for 
enumservices - it seemed quiet on the list.

BTW, Rudi, Richard, and I have three drafts that are germane here:
The "enum scenarios" draft <draft-stastny-enum-scenarios-00.txt>.
The "enumservice analysis" draft <draft-stastny-enum-services-analysis-00.txt>
The "enumservice categories" draft 
<draft-brandner-enum-categorical-enumservices-00.txt>

 From the above it's pretty obvious that I/we agree with the 
protocol/function matrix.
(Note though that for protocol, we have URI-scheme).

Whether or not the URI-scheme is needed within the service field is a 
question that has been raised in the draft (and on the list), and 
will be raised in the meeting, I'm sure.

I believe that it's just a regexp away, so isn't needed in the 
service field - the NAPTRs will have been filtered on function 
(a.k.a. enumservice category) already so there won't be a lot.

(Further comments on "function" in a separate mail :).

Also, some nasty people have pointed out that one could download 
URI-scheme handlers :(
In that situation, it's not easy to tell what URIs are appropriate.

Thus I *think* I'm with Patrik on this one - we don't NEED the 
URI-scheme to be copied into the services field, and it complicates 
parsing with a non-terminal NAPTR (where there IS no URI-scheme).


The idea that we should specify the eventual session/protocol that 
will result from the Service Resolution Service (i.e. SIP) is 
interesting. However, I have a question and a nightmare::

If I fire up a browser window for the 7cent.com site 
<http://www.clockadial.btinternet.co.uk/starter.html>
where in this URL does it specify the embedded sound that plays as a 
result of opening this URL (no - it won't make your ears bleed)?

Seems that there ARE precedents for not indicating the mess one will 
get into when following a URL; plus this is a nightmare to validate 
and synchronize (between DNS and a SIP registrar/proxy).

Re. a possible "shape" for the category definitions:
- see the enumservice category draft - this includes the URI-schemes 
that will "fit" within each category.

I'm not sure this fits exactly with Patrik's "give the client 
everything he needs" - as that would include the URI-scheme that is 
found after regexp replacement.

-------
Regarding Rich's comments:

*  Whoa - In each NAPTR there is (potentially) a list of 
enumservices. That's in both RFC2916 and draft-2916bis.
All right, Rich - I'll buy you a beer if I don't have to re-write all 
of the drafts that have used this term.
If one beer's not enough, I'm sure that Rudi and Richard will as well  :)
-Please- choose another term for the sub-field you called 
enumservice1/enumservice2.

* Hmm....Just when you thought URI-scheme was bad, we bring in protocols.
Should SMTP read mailto?
(As for rtp - is there an rtp: URI-scheme?)

* Transport....SIP has its own negotiation mechanism for selecting 
between UDP, TCP, and TLS.
(As well as the protocol that will be used for the resulting session 
to be initiated)


* (I think it's topic A and B and C :))

Just my 7 cents for this one.



all the best,
   Lawrence
-- 
[e-mail]: [phone]::<my opinions>: