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

Duane <duane@e164.org> Wed, 29 November 2006 21:29 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWzK-0005Lu-6L; Wed, 29 Nov 2006 16:29:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWzI-0005Gb-3W for enum@ietf.org; Wed, 29 Nov 2006 16:29:04 -0500
Received: from wodka.aus-biz.com ([65.23.153.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpWzE-0008FU-5m for enum@ietf.org; Wed, 29 Nov 2006 16:29:04 -0500
Received: from [172.17.1.113] (unknown [202.10.81.200]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by wodka.aus-biz.com (Postfix) with ESMTP id 56B7F11A678; Wed, 29 Nov 2006 16:28:55 -0500 (EST)
Message-ID: <456DFB91.7040001@e164.org>
Date: Thu, 30 Nov 2006 08:28:49 +1100
From: Duane <duane@e164.org>
User-Agent: Thunderbird 1.5.0.8 (X11/20061115)
MIME-Version: 1.0
To: Alexander Mayrhofer <alexander.mayrhofer@enum.at>
Subject: Re: [Enum] requesting reviewers for draft-ietf-enum-xmpp..
References: <456C52F5.20203@enum.at> <456C9D3C.6040104@e164.org> <456DB5FD.7000501@enum.at>
In-Reply-To: <456DB5FD.7000501@enum.at>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.1 (+)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Cc: enum@ietf.org
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

Alexander Mayrhofer wrote:

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

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.

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

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.

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

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

_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum