Subject: Re: [Enum] Re: I-D ACTION:draft-mahy-enum-im-service-00.txt

From: "Stastny Richard" <[email-masked]>
Date: Sun, 26 Feb 2006 00:30:50 +0100

I am a bit confused
 
>For the rest of us, it looks like (X-IM:aim, X-IM:ymsgr, X-IM:icq, X- IM:msim, X-IM:jabber,
>X-IM:xmpp X-IM:skype) is still the quick answer to fire up IM clients 
>and send messages to people. It certainly works for me.

>For Skype voice calls a number of us have been using X-Skype:callto, 
>as the Skype client registers itself as handling the "Callto:" URL scheme, and will place 
>a voice call if you send the URL to Windows (or MacOS). That works for me as well :). 
...
 
What is the difference between am IM-session, and a voice or video session,
not to mention presenence. Some of these clients allow to change between
IM and voice during the session, some dont, but are planning to add this soon
(Tello ;-). Some also provide file tranfer, desktop sharing, white-boards.
Some are standards, some are not (e.g. skype)
 
I do not complete understand the differnence between IM, pres etc URIs
How does sip fit into this. Should there be a session URI? and a 
related Enumservice?
 
Could anybody please explain how to get aout of these mess
 
Richard

________________________________

Von: lconroy [mailto:[email-masked]]
Gesendet: Sa 25.02.2006 23:54
An: chenhui
Cc: [email-masked]; Stastny Richard; IETF ENUM WG
Betreff: Re: [Enum] Re: I-D ACTION:draft-mahy-enum-im-service-00.txt

Hi Chenhui, Rohan, folks,
  First, thanks Chenhui - from your comment I went back and re-read 
Rohan's draft *and the
RFCs it references*. I had missed a couple of crucial features in the 
references. Now it
makes much more sense.

However, with regret I withdraw my comment on re-writing our clients 
and provisioning
systems to fit - this draft has a completely different model from the 
one in use.
Does anyone use the scheme proposed in RFC 2778/2779 and in RFC 3861?
IIRC, several large systems *nearly* did in 2001, but will they now?

Rohan's draft is the missing bit in the IETF RAI (SIP/...) 
architecture - now there's
an anointed way to do with IM what was done to Presence. As such, I'm 
sure that it WILL
progress quickly on the standards track.

Somehow I don't think that the existing IM system URI schemes will 
ever be registered, so
I do not think it will be feasible to move an Enumservice like 
(im:<im-system-URI-scheme>)
through the IETF process - the IM system URIs in use in the World 
still are not registered,
so a standards track document can't refer to their specifications, so 
it won't be acceptable.

For the rest of us, it looks like (X-IM:aim, X-IM:ymsgr, X-IM:icq, X-
IM:msim, X-IM:jabber,
X-IM:xmpp X-IM:skype) is still the quick answer to fire up IM clients 
and send messages
to people. It certainly works for me.

For Skype voice calls a number of us have been using X-Skype:callto, 
as the Skype client
registers itself as handling the "Callto:" URL scheme, and will place 
a voice call if you
send the URL to Windows (or MacOS). That works for me as well :).
But...of course, in that case if you have Windoz and have installed 
Microsoft's NetMeeting
but *don't* have Skype installed, then your computer will try to 
place an H.323 call when
it sees a "Callto:" URL, and will fail. However, these days that is a 
VERY rare problem.

all the best,
   Lawrence

On 24 Feb 2006, at 01:37, chenhui wrote:
> Hi Rohan,
>
> The draft is a great progress to push ENUM IM service.
>
> We have also been considering the ENUM-IM service and developing 
> some ENUM-IM application.
> As we know, there are so many kinds of IM clients and different IM 
> protocols, so how to intercommunication between different clients 
> is a problem.
>
> "Service Type" field is used to mark the registration of IM 
> service, but it seems limited to present the information of IM. 
> Therefore, we suggest to add the "subtype" field.
>
> Regards!
> Chenhui
>
>>> -------- Original Message --------
>>> Subject: I-D ACTION:draft-mahy-enum-im-service-00.txt
>>> Date: Wed, 22 Feb 2006 15:50:02 -0500
>>> From: [email-masked]
>>> Reply-To: [email-masked]
>>> To: [email-masked]
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>
>>>
>>> Title : A Telephone Number Mapping (ENUM) Service
>>> Registration for Instant Messaging (IM) Services
>>>
>>> Author(s) : R. Mahy
>>> Filename : draft-mahy-enum-im-service-00.txt
>>> Pages : 5
>>> Date : 2006-2-22
>>> This document registers a Telephone Number Mapping (ENUM) service 
>>> for
>>> Instant Messaging (IM).  Specifically, this document focuses on
>>> provisioning im: URIs in ENUM.
>>>
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-mahy-enum-im-
>>> service-00.txt
>>>
>>> To remove yourself from the I-D Announcement list, send a message to
>>> [email-masked] with the word unsubscribe in the 
>>> body of the
>>> message.
>>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-
>>> announce
>>> to change your subscription settings.
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP. Login with 
>>> the username
>>> "anonymous" and a password of your e-mail address. After logging in,
>>> type "cd internet-drafts" and then
>>> "get draft-mahy-enum-im-service-00.txt".
>>>
>>> A list of Internet-Drafts directories can be found in
>>> http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>>
>>> Internet-Drafts can also be obtained by e-mail.
>>>
>>> Send a message to:
>>> [email-masked].
>>> In the body type:
>>> "FILE /internet-drafts/draft-mahy-enum-im-service-00.txt".
>>> NOTE: The mail server at ietf.org can return the document in
>>> MIME-encoded form by using the "mpack" utility.  To use this
>>> feature, insert the command "ENCODING mime" before the "FILE"
>>> command.  To decode the response(s), you will need "munpack" or
>>> a MIME-compliant mail reader.  Different MIME-compliant mail readers
>>> exhibit different behavior, especially when dealing with
>>> "multipart" MIME messages (i.e. documents which have been split
>>> up into multiple messages), so check your local documentation on
>>> how to manipulate these messages.
>>> Below is the data which will enable a MIME
>>> compliant mail reader
>>> implementation to automatically retrieve the ASCII version of the
>>> Internet-Draft.
>>
>> _______________________________________________
>> enum mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/enum
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum

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

---

From: lconroy <[email-masked]>
Date: Sat, 25 Feb 2006 23:52:34 +0000

Hi Richard, folks,

First, do what I should have done before hitting the send key - read
RFC 2778, 2779, and 3861. Then go have a drink. Whilst you're doing
that, think of the IM systems "out there" that people use that support
this architecture. You may want to have another drink at this point.

As the esteemed author of ETSI TS 102 172, you recall your definition
of a "generic client" - with this client, an end user will look up the
available contacts, select one, and use it to set up some kind of
communication. Given the generic ENUM client can "fire up" an  
appropriate
IM/Voice/Video/... program, that program will do exactly what you want.
Hence including the X-IM NAPTRs is "a way into a mutually acceptable
session", assuming that a suitable program exists and the end user has
an account with that system. The X-Skype NAPTR merely gives a different
way of starting the session - the effect is similar once the program is
"up and running".

For the session URI - it's called SIP. If you look at section 3 of Jon's
RFC 3764 - the SIP Enumservice spec - it goes on at length about the SIP
AoR and its purpose in life, and from this mailing list archive, you  
know
that SIP is all you need for a session.
I'm afraid I still don't quite understand the dance all of these  
protocols
make, but (after a brief libation) I'm back to 2778/2779 & 3861.
I live in hope of enlightenment from these standards.

all the best,
   Lawrence