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

From: Alexander Mayrhofer <[email-masked]>
Date: Tue, 28 Nov 2006 16:17:09 +0100

Hi,

i'd like to have at least 3 people look over our XMPP Enumservice draft. Any
volunteers? (not just the "usual suspects" perhaps?)

http://www.ietf.org/internet-drafts/draft-ietf-enum-xmpp-00.txt

thanks,

Alex

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

---

From: Niall O'Reilly <[email-masked]>
Date: Tue, 28 Nov 2006 15:51:53 +0000

> volunteers? (not just the "usual suspects" perhaps?)

	I've done this, and it seems good to me, except for the nit mentioned
	below.  I don't recognize myself as a "usual suspect", but I'm not
	sure whether I'm competent either ...

	NIT:

>    In the context of this Enumservice, random clients may discover and
>    use the XMPP URIs/IRIs associated to an E.164 number, hence in most

	s/random/arbitrary/

Best regards,

Niall O'Reilly
University College Dublin IT Services

PGP key ID: AE995ED9 (see www.pgp.net)
Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9

---

From: Duane <[email-masked]>
Date: Wed, 29 Nov 2006 07:34:04 +1100

> volunteers? (not just the "usual suspects" perhaps?)

For consistencies sake I thought XMPP should have been a sub-type of IM
or X-IM or something similar, and grouped all similar IM services
together, just like web services are grouped etc

X-IM:XMPP
X-IM:IRC
X-IM:ICQ
X-IM:YMSGR
X-IM:MSN
X-IM:AIM

Rather then having XMPP as the enumservice type and no sub-type.

-- 

Best regards,
 Duane

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 28 Nov 2006 23:56:46 +0100

> together, just like web services are grouped etc

XMPP isn't just for IM. Google Talk uses XMPP for VoIP.

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

---

From: lconroy <[email-masked]>
Date: Wed, 29 Nov 2006 00:00:59 +0000

Hi Otmar, Duane, folks,

On 28 Nov 2006, at 22:56, Otmar Lendl wrote:
> XMPP isn't just for IM. Google Talk uses XMPP for VoIP.

Well - maybe X-Voice:XMPP as well ?

couldn't resist.
atb,
   Lawrence

---

From: Duane <[email-masked]>
Date: Wed, 29 Nov 2006 11:46:10 +1100

> XMPP isn't just for IM. Google Talk uses XMPP for VoIP.

The same can be said for most if not all IM protocols.

-- 

Best regards,
 Duane

http://www.cacert.org - Free Security Certificates
http://www.nodedb.com - Think globally, network locally
http://www.sydneywireless.com - Telecommunications Freedom
http://e164.org - Because e164.arpa is a tax on VoIP

"In the long run the pessimist may be proved right,
    but the optimist has a better time on the trip."

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 29 Nov 2006 17:31:57 +0100

> together, just like web services are grouped etc

Duane,

thanks for the feedback. Actually, i thought about that, too, especially
considering that a recent registration proposal for "im" has progressed
(similar to the "pres" service). (draft-ietf-enum-im-service-01.txt)

However, XMPP is pretty generic, and not limited to those services (similar
to SIP), so i think it has deserved its own ENUM service. There are a lot of
proposals to use XMPP for other purposes than im and presence..

The other alternative to refer to an XMPP IM service would be using an "im"
Enumservice pointing to a "im:" URI which then resolves to XMPP using
RFC3861 style NAPTRS (that would become a two-stage process), like:

$ORIGIN 1.2.3.4.5.e164.arpa.
 IN NAPTR 10 100 "u" "E2U+im" "!^.*$!im:[email-masked]!" .

together with

$ORIGIN domain.com
_im._xmpp  SRV 0 0 5223 xmpphost.domain.com.

(However, the "_xmpp" protocol label for the "_im" service label is not yet
registered)

Regarding the experimental Enumservice: I have a bit of a problem with "x-"
services as long as anybody can use any of them for any purpose. it would be
 perfectly legal to use an "x-im:xmpp" enumservice for a different protocol
(eg. HTTP, email, or even SIP) - "x-" services are only to be used
privately, and interopability must not be expected.

That might change with a "lightweigth" registration process for experimental
service - but, unfortunately we are not there yet.

So, to conclude, a new "XMPP" Enumservice seemed to be the most logical
thing to do, considerung the flexibility of XMPP itself..

And, it's always the same story about "too much flexibility in the NAPTR -
where to put the protocol, where to put the application"...

comments appreciated.

Alex

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 29 Nov 2006 17:43:20 +0100

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

cheers

Alex

---

From: Duane <[email-masked]>
Date: Thu, 30 Nov 2006 08:28:49 +1100

> proposals to use XMPP for other purposes than im and presence..

I think you are over engineering things, basically if someone lists an
IM address, regardless if it is MSN, YMGSR, XMPP, or whatever,
everything else will need to be negotiated at the client level due to a
number of reasons including privacy and security.

IMHO, it is much better to make things simpler then to require users to
add 50 different types to specify the capabilities in DNS which is
merely a duplication of what is available from the information within
the client.

> privately, and interopability must not be expected.

Perhaps I shouldn't have suggested x-im so easily, but instead use
E2U+IMSGR instead, or anything really, the point is clients are capable
to send information more securly on their capabilities, rather then
specify all aspects that it can support which no one will ever use.

> where to put the protocol, where to put the application"...

I disagree, people already find each other and the software tells them
what the person they are conversing with is capable of already without
the help of NAPTR, they do this using the XMPP address, or ICQ number,
or email address registered with passport or any of the other
established mechanisms.

However what would be nice for things like GAIM and other clients that
support multiple protocols is an easier way to filter for all IM
services available.

>From there the application can display to the end user not only the
services that match what the user is signed up and/or currently
registered against, but so the user can pick and choose which they
actually want added.

-- 

Best regards,
 Duane

---

From: Duane <[email-masked]>
Date: Thu, 30 Nov 2006 08:35:22 +1100

> very welcome for that document...

As far as I can see, virtually all current enumservices use subtype
except h323, sip and pres, everything else has subtypes.

Richard pointed out to me privately, that the only time it makes sense
not to use a subtype is when there is duplication, eg sip:sip, but there
is no subtype for sips, just the possibility of a different URI type.

Perhaps e2u+pstn:sip, e2u+pstn:sips etc would have made more sense?
e2u+pstn:sip is exists, well the sip part does, or maybe e2u+voip:sip
would have made more sense.

-- 

Best regards,
 Duane

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 29 Nov 2006 22:57:04 +0100

>would have made more sense.

I faintlycan  remember voice:sip and voice:h323, what's left is voice:tel

this was two years ago
 
I have given up this discussion ;-)

Richard

________________________________

Von: Duane [mailto:[email-masked]]
Gesendet: Mi 29.11.2006 22:35
An: Alexander Mayrhofer
Cc: [email-masked]; Otmar Lendl
Betreff: Re: [Enum] requesting reviewers for draft-ietf-enum-xmpp..

--

Best regards,
 Duane

---

From: Duane <[email-masked]>
Date: Thu, 30 Nov 2006 09:17:18 +1100

> I have given up this discussion ;-)

Perhaps Ed Guy should be using this as a template for IAX2, rather then
rushing through yet another enumservice that can't easily be grouped
with others...

-- 

Best regards,
 Duane

---

From: lconroy <[email-masked]>
Date: Thu, 30 Nov 2006 01:35:26 +0000

Hi Alex, folks,
  OK - this quest is a long one.
>>> XMPP isn't just for IM. Google Talk uses XMPP for VoIP.
(A puppy is not just for Christmas, it's for ... ?)
> I think we will always have to deal with (at least) two "types" of
> registrations in ENUM.
>

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

---

From: Duane <[email-masked]>
Date: Thu, 30 Nov 2006 17:33:09 +1100

lconroy wrote:

> 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

As I wrote in a previous email, people won't enter every possible type
of enum service and how they can be contacted.

This isn't how these services are used now, and I don't see it happening
in future for 2 simple reasons, people are lazy, and more importantly
what if I use MSN at work and at home, I use the MS client at work which
supports all the bells and whistles, yet at home I use gaim which
doesn't, yet both instances I use the same login details but I can't be
bothered updating DNS 2 or more times a day just to update what the
current client abilities are.

While it might be possible to get some clients to interact with some
enum roots, I doubt they will interact with all so people may in some
cases be left doing manual updates and this just won't happen, so a
simple I can be contacted by MSN with these details are the best way to
attack this problem due to people being lazy.

So if you make things too complicated people will end up ignoring enum
completely and just falling back to what they already know and use all
the time which makes this whole exercise a complete waste of time.

-- 

Best regards,
 Duane

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 30 Nov 2006 10:02:45 +0100

> 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:[email-masked]]
> Sent: Thursday, November 30, 2006 2:35 AM
> To: Alexander Mayrhofer
> Cc: [email-masked]; Otmar Lendl; Duane
> Subject: Re: [Enum] requesting reviewers for draft-ietf-enum-xmpp..
> 
> Hi Alex, folks,

---

From: Bernie Hoeneisen <[email-masked]>
Date: Thu, 30 Nov 2006 22:12:31 +0100 (CET)

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

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 30 Nov 2006 22:40:49 +0100

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:[email-masked]]
Gesendet: Do 30.11.2006 22:12
An: [email-masked]
Betreff: RE: [Enum] requesting reviewers for draft-ietf-enum-xmpp..

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

  e2ec:h323
  e2ec:iax2

cheers,
  Bernie