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/
<<attachment: smime.p7s>>
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf