Subject: [Enum] Sufficient information in NAPTRs, MSG, and VOVI

From: lconroy <[email-masked]>
Date: Sun, 06 Mar 2005 11:08:43 -0500

Hi folks,
  The conf-service thread has pushed me to a couple of general issues
that have been lurking around.
As "whatever happened to VOVI?" is down on the agenda, I offer this
generalisation for your comments, as I think they're related.
Sorry for its length - those with ADD can skip to the last bit starting 
"In short...".
----

*  The web Enumservice is very similar to a TXT resource record - it's
   general. That's good, and TXT records are already being used to show
   a person's name (and/or the textual label one could pop up for this
   E-number). The SIP Enumservice is also general - this generated URI
   "points to" a SIP service and you "do the SIP thing" to negotiate
   further. From a protocol perspective, this is enough information -
   the ENUM client fires up a Web or SIP client and we're done.
    [Of course the provider for that service and the registered SIP
     device set "behind" it may or may not support the communications
     ->mode<- the querying user wants to use. He or she can find out by
     firing up a SIP invite, have their machine spend some CPU cycles
     with any puzzle challenge, and then potentially find out that they
     don't do IM, for example, or that the registrant hasn't told that
     SIP registrar about their IM-capable device and/or their preferred
     presence/IM service with a chained registration.
     It is left as an exercise for the various providers' help desk(s)
     to explain this to their customers. :-]
*  There is potential to carry "higher level" application information in
   NAPTRs. There have also been comments in the past that you might want
   to indicate that a target URL is associated with a mobile device (a
   WiFi phone, in Henry's case :), or with a work phone, or a home
   phone, or ... Conversely, Cullen was worried that you could end up
   indicating an IVR, or VM, or other things that have defeated the
   learned experts of SIP/SIPPING for years - it has proved to be a
   rat's nest. Quelle Surprise.
I suspect that this is not going to go away. Is there any way that this
"higher level extra information" can be encoded into the data published
in ENUM? If so, do we need to *codify* every possible alternative in a
way that a machine can process the entries to come out with a single
result on its own?
3761 allows a nested set of sub*[-sub]-types. It specifies that each
pattern of type (and, optionally, sub-type) is unique, and that these
are required to be processed in deciding on the acceptability/support
for an Enumservice. All of these elements are codified and are
considered by the ENUM client in resolving the NAPTR rrset.
If we have SIP entries and web entries as well as voice telephone
entries, then the program sitting on the querying client's machine (or
on that of their agent server, which is even more interesting) may have
no easy way of telling which mode of communication and which protocol is
the "best" one from that end user's perspective. It may well have to 
ask.
In this case, we already have "a human in the loop".

It seems to me that there is a valid case for someone tagging on some
extra information to an Enumservice that is intended purely for the
querying Human, rather than their machine. From the ENUM client's
perspective, this extra information is not relevant, but if there's no
obvious single answer, it can be presented to the end user for their
edification.
Thus we have Enumservice specifications defining the (mandatory) data
that the ENUM client needs to consider, but "beyond that", any extra
information (in sub-sub-types, or in sub-sub-sub-types) is ignored as
part of the evaluation but can be passed on to the end user if there's a
tie.
----
In the case of the "tel:" URI scheme, we have an issue - it's why we
included MSG and VOVI. The PSTN is used to provide a number of different
Teleservices ->that use different programs on the end user's machine<-.
Someone may well have a voice client on their machine that they use to
place and receive voice calls with E.164 telephone numbers as
destination address - could be via a SIP provider, or if they're rich,
they could be using, say, a direct ISDN connection. They could also have
a fax program that they use to receive and send faxes. They could also
have an SMS program that they use to send and receive texts.
These will be completely different programs, so from an ENUM client
perspective, it would like to know which program to fire up. The URL
scheme is not enough in this case. IMHO, it's mandatory to include an
indication of the Teleservice, so that the ENUM Client can fire up the
right program, as these programs will be associated with discrete
Teleservices.
You *could* just fire up a voice program and when you hear a fax answer
tone realise that this is not what you need. However, whilst it may make
sense for SIP of H323 if the clients have a defined mechanism for mode
negotiation, for for these "legacy support" applications it isn't going
to make the end user very happy.
----
In short, I think that the important thing is whether or not an ENUM
client has the information it needs to fire up the right program.
This information is mandatory for us to include in the Enumservice
specification and for the ENUM client to consider in its resolution.
There may also be "high level application extra information" that is
intended only for a Human rather than a machine, and so the ENUM client
does not need to consider but can present to that Human if they are "in
the loop" for NAPTR rrset evaluation.
Any such information could well be "tagged on" after the mandatory
Enumservice type (and sub-type, if it's there), and is just ignored in
ENUM client evaluation. Thus folk who really want to indicate that this
URL is dedicated to VM can do so, without breaking anything and without
requiring an infinite length Enumservice registration RFC. My vote's for
putting such optional info on the right of an Enumservice.
My vote's also for having the Enumservice as well as the URL scheme for
the different Teleservices associated with a "tel:" URL, as otherwise
the ENUM client will not *know* which program to run. I believe that
this should be on the "left end" of the Enumservice definition (e.g.
sms:tel).
Comments, please.
all the best,
  Lawrence
---------------------------------------
lawrence conroy    |tel:+44-1794-833666
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Richard Shockey <[email-masked]>
Date: Sun, 06 Mar 2005 15:45:27 -0500

At 11:08 AM 3/6/2005, lconroy wrote:
Hi folks,

*  The web Enumservice is very similar to a TXT resource record - it's
   general. That's good, and TXT records are already being used to show
   a person's name (and/or the textual label one could pop up for this
   E-number). The SIP Enumservice is also general - this generated URI
   "points to" a SIP service and you "do the SIP thing" to negotiate
   further. From a protocol perspective, this is enough information -
   the ENUM client fires up a Web or SIP client and we're done.
    [Of course the provider for that service and the registered SIP
     device set "behind" it may or may not support the communications
     ->mode<- the querying user wants to use. He or she can find out by
     firing up a SIP invite, have their machine spend some CPU cycles
     with any puzzle challenge, and then potentially find out that they
     don't do IM, for example, or that the registrant hasn't told that
     SIP registrar about their IM-capable device and/or their preferred
     presence/IM service with a chained registration.
     It is left as an exercise for the various providers' help desk(s)
     to explain this to their customers. :-]
Yes ... we had this debate before remember there was substantial objections 
by the SIP community to adding granular information or hints to the 
registration as in E2U+sip:voice   E2U+sip:im   etc .. personally Ive never 
seen the reason for the objection but I respect the opinion of those who 
see a problem here. I'd be willing to revisit the issue if there was as 
good argument to do so.

Now on the issue of the VOVI draft ..no it is not on the agenda since I did 
not have a request for it..but frankly I dont like it.

What I want is a comprehensive tel registration document and we need that 
now for several reasons.

What I would like to see is where tel is the type and everything else is a 
subtype.

tel:voice
tel:fax
tel:sms
tel:mms
i dont want them reversed  IMHO voice is not a "type" in this  context
maybe

*  ______________
enum mailing list
enum at ietf.org

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141 at fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: lconroy <[email-masked]>
Date: Sun, 06 Mar 2005 18:06:28 -0500

Hi Richard, folks,
Re. application:network identifier vs network identifier:application:
I note that this issue wasn't raised before or during the WGLC or IETF 
LC for MSG,
which includes a registration for 'tel:fax'. Are we really running out 
of reasons
to block/re-assess the MSG draft?

----
Re. do I remember VOVI? - it's indelibly burnt into my brain.
(BTW, I threw this in this originally only so that the Helpdesk crowd 
will know who
 to thank for their full lives - not me :).

SIP was airbrushed out of VOVI-01 way back in 2003 as a reaction to The 
SIP Community
who saw a problem with it. When we next had a chance to talk with Orit 
(who couldn't
be heard in the original meeting for the enthusiasm of The Community :) 
we removed
h323 from the mix as well, in -02 which came out last year after the 
Seoul meeting.
Since then VOVI dealt exclusively with voice and video services using 
E.164 network
identifiers. The only reference to SIP or H323 is to indicate that a 
call to a PLMN
(or PSTN) device may be made indirectly (via a SIP or H323 to PSTN 
gateway).

VOVI-02 has some minor cut-and-paste typos and a reference to RFC2806 
so it needed
a refresh but, as there is an objection, I guess we just let it expire 
in the IETF.
It's in use already so isn't worth the grief.

----
The esteemed co-chair has spoken - I'm not sure in what Language, but I 
get the tone.

all the best,
  Lawrence
On 6 Mar 2005, at 20:43, Richard Shockey wrote:
At 11:08 AM 3/6/2005, lconroy wrote:
Hi folks,
  The conf-service thread has pushed me to a couple of general issues
that have been lurking around.
As "whatever happened to VOVI?" is down on the agenda, I offer this
generalisation for your comments, as I think they're related.
Sorry for its length - those with ADD can skip to the last bit 
starting "In short...".
----

   general. That's good, and TXT records are already being used to 
show

    [Of course the provider for that service and the registered SIP
     device set "behind" it may or may not support the communications
     ->mode<- the querying user wants to use. He or she can find out 
by
     firing up a SIP invite, have their machine spend some CPU cycles
     with any puzzle challenge, and then potentially find out that 
they
     don't do IM, for example, or that the registrant hasn't told that
     SIP registrar about their IM-capable device and/or their 
preferred
     presence/IM service with a chained registration.
     It is left as an exercise for the various providers' help desk(s)
     to explain this to their customers. :-]
Yes ... we had this debate before remember there was substantial 
objections by the SIP community to adding granular information or 
hints to the registration as in E2U+sip:voice   E2U+sip:im   etc .. 
personally Ive never seen the reason for the objection but I respect 
the opinion of those who see a problem here. I'd be willing to revisit 
the issue if there was as good argument to do so.

Now on the issue of the VOVI draft ..no it is not on the agenda since 
I did not have a request for it..but frankly I dont like it.

What I want is a comprehensive tel registration document and we need 
that now for several reasons.

What I would like to see is where tel is the type and everything else 
is a subtype.

tel:voice
tel:fax
tel:sms
tel:mms

*  ______________
enum mailing list
enum at ietf.org

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141 at fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 
815.333.1237
<mailto:richard(at)shockey.us> or 
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<