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

["Stastny Richard" <[e-mail]>]

> 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.

I agree, because there is no solution to this problem.

We should also not forget the basic requirement from Patrik:
"A client must be able to decide on the NAPTR to choose without looking
at the URI in the regexp."

OTOH, the problem is not so big, IMO

A jabber client may look for Enumservices XMPP, IM:XMPP, VOICE:XMPP
(and not for SIP)

A user may have only one, or he may either have XMPP or to different
Enumservices pointing to IM:XMPP and VOICE:XMPP

So the originator may choose depending on his client.

Richard



> -----Original Message-----
> From: lconroy [mailto:[e-mail]]
> Sent: Thursday, November 30, 2006 2:35 AM
> To: Alexander Mayrhofer
> Cc: [e-mail]; Otmar Lendl; Duane
> Subject: Re: [Enum] requesting reviewers for draft-ietf-enum-xmpp..
> 
> 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


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