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

From: Richard Shockey <[email-masked]>
Date: Wed, 22 Feb 2006 20:58:28 -0500

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

-- 

Richard Shockey, Director - Member of Technical Staff
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>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

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

---

From: Bernie Hoeneisen <[email-masked]>
Date: Thu, 23 Feb 2006 10:01:33 +0100 (CET)

Hi Rohan!

I had exactly the same idea mapping E.164 numbers to IM 
addresses and was about to write up an I-D about this...

One of my motivations for having such a mechanism in place
is to help in keeping track of all different IM Identities (Jabber, AIM, 
ICQ, MSN, SIMPLE, ...) a person is using. Especially useful this can be 
for all-in-one clients, such as Gaim (type in E.164 number, get all IM IDs 
of your buddy).

Another area this could be used is Instant Messaging on Mobile Phones, 
where you anyway have the E.164 number as main identifier.

What is not so clear to me is, whether for privacy reasons this should 
be rather done by means of RFC 3953 (indirection), i.e. provide an 
IM-URI (or even re-use the presence URI), where the details (the actual IM 
Identities) can be fetched from. So there would be some means of 
access control in place, unlike in the DNS.

What do you think about?

cheers,
  Bernie

> 	Title		: A Telephone Number Mapping (ENUM) Service 
> Registration for Instant Messaging (IM) Services
>
> 	Author(s)	: R. Mahy
> [email-masked] with the word unsubscribe in the body of the 
> message.

---

From: lconroy <[email-masked]>
Date: Thu, 23 Feb 2006 23:38:26 +0000

Hi Bernie, Rohan, folks,
  first - I've looked at Rohan's draft - good stuff, and exactly what  
I had in mind.
(it's succinct and to the point, so probably better than I had in  
mind :).

Bernie - I think that RFC 3953 is about as indirect as one can get  
without looking out
at the back of one's head. However, a whole authenticated exchange  
with a "presence
protocol" before a client can find out *if* there is an appropriate  
IM cloud (i.e. one
in which he or she has an account that can be used to send an IM, and  
in which the
registrant has an account) is a long long long route. It's also one  
that requires a
end user to have a program that supports that presence protocol as  
well as the IM one
he or she ends up using (if they eventually find that a matching one  
exists).

There's definitely room for another draft to cover the steps in that  
indirect exchange
as it would cover quite a different use case, but please not this one.

If a registrant has an AIM ID, it doesn't mean that I as a client can  
send an IM,
even *if* I have Adium running on my machine. The security section in  
Rohan's draft
spells that out nicely.

I like Rohan's draft as it is, and hope that it can progress quickly on
the standard track. It's certainly going to be in a race with reality.
(we have been using X-IM, but will be happy to change).

all the best,
   Lawrence

On 23 Feb 2006, at 09:01, Bernie Hoeneisen wrote:
> Hi Rohan!
>
> I had exactly the same idea mapping E.164 numbers to IM addresses  
> and was about to write up an I-D about this...
>
> is to help in keeping track of all different IM Identities (Jabber,  
> AIM, ICQ, MSN, SIMPLE, ...) a person is using. Especially useful  
> this can be for all-in-one clients, such as Gaim (type in E.164  
> number, get all IM IDs of your buddy).
>
> Another area this could be used is Instant Messaging on Mobile  
> Phones, where you anyway have the E.164 number as main identifier.
>
> What is not so clear to me is, whether for privacy reasons this  
> should be rather done by means of RFC 3953 (indirection), i.e.  
> provide an IM-URI (or even re-use the presence URI), where the  
> details (the actual IM Identities) can be fetched from. So there  
> would be some means of access control in place, unlike in the DNS.
>
> What do you think about?
>
> cheers,
>  Bernie
>
>
>> 	Title		: A Telephone Number Mapping (ENUM) Service Registration  
>> for Instant Messaging (IM) Services
>>
>> 	Author(s)	: R. Mahy
>> [email-masked] with the word unsubscribe in the  
>> body of the message.

---

From: "chenhui" <[email-masked]>
Date: Fri, 24 Feb 2006 09:37:38 +0800

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

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 24 Feb 2006 12:12:50 +0100 (CET)

Hi Lawrence

On Thu, 23 Feb 2006, lconroy wrote:

> without looking out at the back of one's head.

I had not doubt about RFC 3953 and indirection, but kind of misunderstood 
the proposed mechanism in Rohan's I-D. After Rohan has clarified the 
intension of his draft, I am aware of my misunderstanding, so the issue 
can be settled.

> (we have been using X-IM, but will be happy to change).

I also like Rohan's draft. However I see room for adding further 
clarifications. I will think about and make concrete proposals
at some later time.

cheers,
  Bernie

---

From: lconroy <[email-masked]>
Date: Sat, 25 Feb 2006 22:54:51 +0000

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:
> 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
>
>>> body of the