Re: [Enum] requesting reviewers for draft-ietf-enum-xmpp..

[lconroy <[e-mail]>]

Hi Alex, folks,
  OK - this quest is a long one.
On 29 Nov 2006, at 16:43, Alexander Mayrhofer wrote:
> Duane wrote:
>> Otmar Lendl wrote:
>>> XMPP isn't just for IM. Google Talk uses XMPP for VoIP.
(A puppy is not just for Christmas, it's for ... ?)
>> The same can be said for most if not all IM protocols.
>
> I think we will always have to deal with (at least) two "types" of
> registrations in ENUM.
>
> - The "application" type registration (like, in that case "im"  
> pointing to
> an IM URI, which in turn resolves to an XMPP server). Examples: "im",
> "pres", "voice", "web", "ft"
>
> - The "protocol" registration (like "xmpp" in that case). Examples  
> "sip",
> "h323", etc...
>
> I haven't yet found out which of the two the "holy grail" is - we  
> also try
> to work on this issue in draft-ietf-enumservices-guide.  
> contributions are
> very welcome for that document...

Seriously folks, this request for guideline text is timely. This  
discussion
demonstrates that is it needed.

IMHO, as a client I would like the Enumservice field to answer two  
questions:
  - "What are am going to do if you use this contact?", and
  - "How are you going to do it"?
These map to the Eumservice Type and Subtype - hence 'voice' is the  
kind of
thing you want to do, and 'tel' as the way you do it (by using a  
phone call).

Other examples of answers to what? are "Web", "file transfer",  
"email", "fax",
and "sms", "ems", "mms".
How you do these things are variously to use 'http:','https:','ftp:',  
'mailto:',
and 'tel:' (according to RFC 4002 and RFC 4355).

I guess you could stretch things to say that the "Pres" Enumservice  
tells you
what kind of interaction is going to happen - I think RFC 3861 is the  
start of
the trail for finding out how you do it.

There are some Enumservices where you really have no idea what you're  
going to
do - the joy of anticipation is left until later protocol-specific  
negotiation.

For example, you have no way of knowing that the device you are going  
to get
to by using a SIP URI is going to have a phone capability or not  
before you
do the INVITE. Fortunately, almost all AoRs have phones associated  
with them.
You might get unlucky and find an electric toaster at the other end,  
but it
isn't that likely. If your gateway takes an incoming phone call and  
tries to
connect it to a SIMPLE-only end point, well - life is hard.

You could argue that any "protocol" registration like xmpp merely  
says that
you don't or can't know in advance what kind of interaction is going to
happen if you use this URL. All of these are really subtypes of the same
Enumservice: "Do-You-Feel-Lucky-Punk?"

My only concern is that I have a perfectly reasonable Jabber client  
that can
do IM interaction, but it is not capable of voice (or, strictly,  
GoogleTalk).

If the registrant really wants me to fire up a GoogleTalk client, then
he should really say that this should start as a voice call -  
otherwise how
is my ENUM client supposed to know what program it is supposed to  
fire up
to handle the URI?

I have no problem at all with an Enumservice registration not telling  
the
client what kind of interaction to expect - it may be unknowable, as the
protocol is so wide ranging that it could result in a full exchange  
of IM
messages or World War Three.

However, this does not, in my mind, preclude having another registration
using that protocol that gives a hint on the kind of interaction that  
the
client can expect to start. X-IM:xmpp and Voice:xmpp would help to  
tell me
to fire up my Jabber client or to try to find a working Googletalk voice
program for my Mac (or Linux box, or ...).

As Alex says, you need both.

all the best,
   Lawrence


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