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

[Cullen Jennings <[e-mail]>]

I should have been clearer - sorry.

I have a strong preference for having a simple general mechanisms  
that works for multiple protocols (at least sip and xmpp) instead of  
specialized alternatives. I think all your current proposal meet this  
strong preference.

I have a very weak preference for not requiring the use of im and  
pres URLs just because the support for these is not as widespread as  
the support for sip and xmpp URLs. I perfectly happy to also allow im  
and pres URLS, just slight preference not to require them.

Hope that is clearer - thanks for the work you are doing on this.

Cullen <with my individual contributor hat on>


On Nov 26, 2007, at 3:11 PM, Peter Saint-Andre wrote:

> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-message-headers