Re: [Ietf-message-headers] Re: I-DAction:draft-saintandre-header-pres-00.txt

Peter Saint-Andre <stpeter@stpeter.im> Mon, 26 November 2007 23:10 UTC

Return-path: <ietf-message-headers-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwn5b-0003HI-LM; Mon, 26 Nov 2007 18:10:07 -0500
Received: from ietf-message-headers by megatron.ietf.org with local (Exim 4.43) id 1Iwn5a-0003Gv-Hp for ietf-message-headers-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 18:10:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwn5a-0003Ge-7f for ietf-message-headers@lists.ietf.org; Mon, 26 Nov 2007 18:10:06 -0500
Received: from dizzyd.com ([207.210.219.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwn5X-0004qJ-DX for ietf-message-headers@lists.ietf.org; Mon, 26 Nov 2007 18:10:06 -0500
Received: from wrk225.corp.jabber.com (dencfw1.jabber.com [207.182.164.5]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTP id CFF0340369; Mon, 26 Nov 2007 16:10:01 -0700 (MST)
Message-ID: <474B52B3.5010506@stpeter.im>
Date: Mon, 26 Nov 2007 16:11:47 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
Subject: Re: [Ietf-message-headers] Re: I-DAction:draft-saintandre-header-pres-00.txt
References: <47308BA7.3080204@stpeter.im> <fgq9pj$ksq$1@ger.gmane.org> <4730C881.4040101@stpeter.im> <6.2.5.6.2.20071106124213.03069a38@resistor.net> <47318BC3.7050009@stpeter.im> <6.2.5.6.2.20071107081447.03037770@resistor.net> <47376CA5.2050309@isode.com> <F6C8C8C8-639F-4CB3-B05F-F9B9C9A5A630@cisco.com>
In-Reply-To: <F6C8C8C8-639F-4CB3-B05F-F9B9C9A5A630@cisco.com>
X-Enigmail-Version: 0.95.5
OpenPGP: id=7BBD0573; url=http://www.saint-andre.com/me/stpeter.asc
Jabber-ID: stpeter@jabber.org
X-Spam-Score: -0.0 (/)
X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964
Cc: Alexey Melnikov <alexey.melnikov@isode.com>, ietf@ietf.org, ietf-message-headers@lists.ietf.org
X-BeenThere: ietf-message-headers@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Discussion list for header fields used in Internet messaging applications." <ietf-message-headers.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-message-headers>, <mailto:ietf-message-headers-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf-message-headers@ietf.org>
List-Help: <mailto:ietf-message-headers-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-message-headers>, <mailto:ietf-message-headers-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0757333184=="
Errors-To: ietf-message-headers-bounces@ietf.org

Cullen Jennings wrote:
> 
> On Nov 11, 2007, at 12:57 PM, Alexey Melnikov wrote:
> 
>> I also don't see any particular reason for prohibiting direct use of
>> XMPP or SIP URIs here. There is no need in extra resolution step if an
>> email author only supports one type of IM application.
> 
> +1
> 
> (thought I am fine either way - this does resolve the concerns I had)

It's still not clear to me what the "construct" is here. Is it one of
the following?

1. "Presence ID" -- a URI where you can find out whether I'm online or
not (if you have appropriate permissions). Your MUA could used this to
show a little green icon or other presence indicator next to my name in
 if I'm online. But you can't necessarily communicate with me this way,
since this URI provides only presence information. We might as well use
pres: URIs for this, since they're already defined in RFC 3859.

2. "Instant Messaging ID" or "IM ID" -- a URI where you can interact
with me textually in (close to) real time. But you won't necessarily
know whether I'm online or not (which, if you want to interact in real
time, seems of dubious utility). We might as well use im: URIs for this,
since they're already defined in RFC 3860. Also note that most existing
IM services do not have URI schemes or even use DNS, so end users won't
be able to include such addresses here -- only addresses for services
based on the technologies registered here:

http://www.iana.org/assignments/im-srv-labels

3. "Real Time Communications ID" or "RTC ID" -- a URI where you can
interact with me using any sort of real time communication modality,
whether it be text, voice, video, whiteboarding, or who knows what.
Maybe you get presence this way, maybe you don't. Maybe you can send me
a text message, maybe you can't. Maybe you can start a voice chat with
me, maybe you can't. So how exactly can you interact with me if I
include such a URI? Unknown. But this seems to be what folks here want.

The in-use "Jabber-ID" header lets you know that you can IM with me and,
if you have information based on a presence subscription, that you I'm
online right now. So presence and IM are core "XMPP things". You might
be able to do more based on some capabilities lookup, but those are the
basics.

Including a SIP URI would enable you to know that you can do "SIP
things" with me, which might be the wonderful range of SIP things that
are implemented and deployed (again based on capabilities discovery).

It strikes me that real people know if they have a Jabber ID or if they
have a SIP address. They may or may not know if they have a "Presence
ID" since presence is a kind of plumbing that underlies all sorts of
real time communication modalities. They may think they have a proper
"IM ID" but they will be mightily frustrated once they figure out that
they can't include their AIM Screen Name or ICQ number or Yahoo! ID,
since those systems don't play nice with im: URIs. But I submit that
real people certainly don't know if they have an "RTC ID" since the
range of possible systems meeting the relevant (and still undefined)
criteria is so broad as to be void for vagueness.

The im: and pres: URIs are known quantities, if a bit obscure. XMPP URIs
and SIP URIs are even better known, and map to technologies we have
defined fairly well. But there is no RTC URI scheme, no requiremets
document for generic RTC functionality (as we have RFC 2779 for IM and
presence), and no clear construct here.

So Cullen, when you say "+1" to Alexey's statement "I also don't see any
particular reason for prohibiting direct use of XMPP or SIP URIs here",
does that mean you're in favor of separate headers for XMPP URIs and SIP
URIs, or does it mean that you would like to define a general-purpose
"RTC ID" in which it would be allowable to plug in an XMPP URI, a SIP
URI, or (presumably) other URIs for services or technologies (say,
Skype) that meet some yet-to-be-defined criteria for real-time interaction?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

_______________________________________________
Ietf-message-headers mailing list
Ietf-message-headers@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-message-headers