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

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

Bernie,
 
the problem with ENUM and URIs is that all options are valid
 
Your proposal is ok, but covers only URIs which are used for protocols
that allow negotiation
 
There is different types of URIs which
a) do not allow negotiation. One example is tel
one may use tel for voice, sms, mms, but there is
no way until you try and it works or fails
 
b) may be used for different applications e.g mms:mailto
 
In addition we have the user, who may want to use one protocol
for voice, another one for video, one for presence and one for messaging, etc.
 
We had this discussion for years now, with no result. Everybody
proposing a solution like you covers only part of the spectrum,
the does not exist a perfect solution - or we would already have
found it in 4 years
 
I think we have to live with this mess
 
Richard
PS: Infrastructure ENUM will anyways only use sip, voice:tel, sms:mailto and mms:mailto ;-)

________________________________

Von: Bernie Hoeneisen [mailto:[e-mail]]
Gesendet: Do 30.11.2006 22:12
An: [e-mail]
Betreff: RE: [Enum] requesting reviewers for draft-ietf-enum-xmpp..



Following these discussions, we seem to lack the all-in-one ENUMservice
for end-to-end communication; applicable for URIs that can be used for any
of presence, IM, Voice, Video, application sharing or whatever people use
the URI for.

Spreading the same subtye to different types, e.g. im:xmpp, pres:xmpp,
voice:xmpp and so on does not make much sense to me.

To me it looks that the right solution is to specify an all-in-one
ENUMservice type that can take different subtypes for the different
"multi-service" protocols.
In following examples lets call it e2ec (for end-2-end communication).

Here some examples for services that offer at least presence and IM:

  e2ec:xmpp
  e2ec:icq
  e2ec:aim
  e2ec:ymsgr
  e2ec:skype
  e2ec:sip

Here some examples of services used with audio and video:

  e2ec:h323
  e2ec:iax2

As someone stated earlier in this thread, it is not really important, to
get more information out of ENUM about the capabilities a user supports.
This can be negotiated on the application protocol (XMPP, SIP, ...) level.

This would deprecate some of the existing ENUMservices,
e.g. sip, h323, ...

What do you think about this idea?
(appart from the backward-compatibiliy issues)

cheers,
  Bernie

PS: If people like this idea I might take the effort to write 'em down
after returning from the Southern Hemisphere...



On Thu, 30 Nov 2006, Stastny Richard wrote:

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

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




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