Subject: [Enum] enumservices & URI-scheme

From: Lawrence Conroy <[email-masked]>
Date: Sun, 26 May 2002 15:38:03 +0100

Hi again folks,
Now for the URI-schemes that can be used with the functions of the 
SchemaSet strawman.

First, note that these URI-schemes must be specified at least for the 
non-terminal case; if a non-terminal is received, the service field 
is all that the application has. That means, as filtering cannot be 
done on the URI-scheme (there *is* no URI with a non-terminal) the 
enumservice alone must allow the application to know whether or not 
the outcome of following this path is going to be useful. The 
application has to be able to answer the question "does it have 
support for the URIs that may result from 'following' this 
non-terminal to the end"?

A good example of this occurs where a non-terminal NAPTR has the 
enumservice 'talk' and the client only supports the "mailto:" URI. As 
"mailto:" is not in the list of URI-schemes that 'talk' can use, the 
client can discard the NAPTR immediately (I tend to think that a VPIM 
feature is a message rather than a talk function).

So...

'talk'/'phone' can use "sip:", "tel:", or "h323:".

'voice' might use "sip:", "tel:", or "h323:". This may be a pure 
subset of 'talk'

'video'/'see' can use "h323:" or "sip:" and might, I guess, use 
"tel:". Again, this may be a pure subset of 'talk'

'message'/'deliver' can use "mailto:", "tel:" with "svc=fax" or 
"svc=sms" or "svc=mms", or "sip:" (where this leads to a 
non-session-oriented IM message)

'file'/'info' can use "http:" or "ftp:" or "https:" or "sftp:" to 
indicate the address of the information in question. (I strongly 
expect this to be used mostly with "http:" to indicate the "home 
page" of the registrant).

'srs'/'inquire'/'enquire' can be used with "sip:" or with "ldap:". At 
present, we have the "sip-e164" draft to cover this one; someone 
needs to add thought to how "ldap:" or any other srs protocol might 
be used.

'chat'/'textchat' can use "sip:" (where this leads to a 
session-oriented IM exchange), "tel:" with "svc=tdd"

'streaming' can use "rtsp:"

'share' can use, I guess, "h323:" or "wb:" or possibly "sip:"

---- ----

Given the discussion so far on enumservices, I wonder what the service
field syntax should be?

Michael has suggested that we go for:
     <D3S-application-tag>-<enumservice-tag>+<URI-scheme>

As Patrik points out, one of the changes in 2916bis is to allow more than
one enumservice sub-field per NAPTR.

Thus, the syntax gets a little tricky here. I guess that something like:
     <D3S-application-tag> - <URI-scheme> 1*( + <enumservice-tag>)
is better - i.e. have the URI scheme immediately after the 'E2U'
D3S application tag, and before any enumservice list.

It also covers the case where there IS no URI-scheme, as would occur 
with a non-terminal.
(e.g. E2U-+talk).

again, comments gratefully received.

all the best,
   Lawrence

-- 
[email-masked]: +44 1794 833666::<my opinions>:

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

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 26 May 2002 18:55:02 +0200

> 'talk'/'phone' can use "sip:", "tel:", or "h323:".

Note that with sip, the negotiation of functionality happens inside the sip
protocol, and what you can do (talk/see/chat etc) might depend on
authentication, access rights, time of day, availability etc etc.

So, I don't understand how you can promise in a static NAPTR record that a
sip URI scheme might lead to talk.

I.e. what function you can get from a given URI is not very often (as I
understand it) known before you start using the URI.

I have from for example SIP community heard very strong opposition to have
enumservices specify a function.

So, I need more meat from people really defining enumservices before I
continue mentally down this path.

   paf