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

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Nov 2007 13:03:13 -0700

Frank Ellermann wrote:
> Peter Saint-Andre wrote on the message-headers list:
> 
>> FYI
> 
> Thanks.  Frankly, I hate these drafts.

Great! Honest feedback is appreciated and agreement is overrated. :)

> 1 - why two drafts instead of one ?

Because some people consider IM and presence to be fully separable
features, which is why we have both the pres: and im: URI schemes (as
defined in RFCs 3859 and 3860 respectively). See also RFC 2779.

> 2 - who wants to publish pres URIs in email headers ?

Presumably people who want to show presence icons next to the names of
message authors.

> 3 - what about Netnews ?

Yes, I added that in version -01 this morning (not yet submitted):

http://svn.xmpp.org:18080/browse/XMPP/trunk/internet-drafts/draft-saintandre-header-pres-01.xml?r1=1337&r2=1339

> 4 - what's going on with the nice jabberid draft ?

That is still to be determined.

> 5 - jabberid had an interesting IRI example, the new
>     drafts claim that [email-masked] is an URI.

For good or for ill, the pres: and im: URI schemes reuse the "mailbox"
construct from RFC 2822. Or something like that -- I asked about it once
on the SIMPLE WG list but never received a reply, so the exact meaning
is unclear to me:

http://www1.ietf.org/mail-archive/web/simple/current/msg07163.html

In any case non-US-ASCII characters would need to be handled as is
traditional in email systems, as far as I can see.

> 6 - I've never seen a pres: URI outside of RFC 3859,
>     why should I wish to see this in a mail header ?

Because it is a more generic solution.

> 7 - the jabberid was obviously about xmpp:, what are 
>     im: and pres: about ?

Any instant messaging and presence technology, as registered with the IANA:

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

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

Oddly, the only registered technology is XMPP. But other technologies
could be registered (and I presume that the lack of a SIP registration
is merely an oversight).

> 8 - RFC 3859 still uses RFC 2396 syntax on top of a
>     RFC 2822 <mailbox>.  That's known to be wrong if
>     I recall discussions with Paul and Martin on the
>     URI list about RFC 2368 (mailto) correctly. 

I do not recall that discussion. But, as mentioned, I do admit to being
confused about the exact syntax of the pres: and im: URI schemes.

> 9 - Likewise RFC 3860.  I hope you're not trying to
>     move vCards piecemeal into mail header fields.

By no means. I am trying to address feedback received during the Last
Call on draft-saintandre-jabberid. Part of that feedback raised the
issue of working on a more generic solution that is not tied to a
specific instant messaging and presence technology (in this case, XMPP).
These I-Ds are my good-faith attempt at fulfilling my promise to work on
a more generic solution.

>  Frank
> 
> Cc: general list, after all jabberid was Last Called.

Fair enough, I retain the cc.

Peter

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

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Nov 2007 14:58:23 -0700

Frank Ellermann wrote:
> Peter Saint-Andre wrote:
>> features, which is why we have both the pres: and im: URI schemes
> 
> Two schemes with a semantics somewhere between about: and file: ...
> if I am interested in pres:[email-masked], can say Psi help me ?

Not unless Psi implements resolution of the pres: URI scheme (i.e.,
doing the required SRV lookup). As far as I know, Psi does not yet
implement that.

>> Presumably people who want to show presence icons next to the names
>> of message authors.
> 
> Okay, but Gmail can manage that without a fancy Pres-ID: mail header
> field.  I also don't quite believe in this separation "feature".

Gmail is an integrated service. What if you're using mutt or Thunderbird
or some random MUA and you want to show presence information about a
message author?

>>> 3 - what about Netnews ?
>> Yes, I added that in version -01 this morning (not yet submitted)
> 
> Thanks.
> 
> You've now demonstrated your good will wrt im: and pres:, after
> that exercise please let's continue with the jabberid.  It was
> almost perfect, "experimental" status is also okay.

Version -06 had an intended status of Informational. I have been
convinced that that's most appropriate.

>> For good or for ill, the pres: and im: URI schemes reuse the 
>> "mailbox" construct from RFC 2822. Or something like that
> 
> For ill, they imitate mailto:.  But what I meant in (5) was a
> syntactical nit, [email-masked] is no URI, you forgot the
> scheme, as in im:[email-masked]
> 
>> In any case non-US-ASCII characters would need to be handled
>> as is traditional in email systems, as far as I can see.
> 
> "mailto-ter" (my name for a successor of mailto-bis supporting
> EAI) is a _very_ hard case.  And mailto-bis is also a _very_
> hard case.  Don't hold your breath.
> 
> IFF mailto-bis survives a Last Call, and IFF im/pres follow
> suite, and IFF 2822bis reduces its NO-WS-CTL horrors, and IFF
> EAI reaches "experimental", then might be a good time to look
> at im/pres again.  
> 
> Okay, I've to check if Psi has a "be more generic" option :-)

Probably not yet. You can always request the feature. :)

> Some SRV magic, does it work wrt xmpp ?  Apparently there
> is no _xmpp.stpeter.im.  "SRV" is still a mystery for me.

I don't run an xmpp server at my personal domain, since I use the
jabber.org domain for that. But per RFC 3859 you can type 'dig SRV
_pres._xmpp.jabber.org' and get some results (since we mainly use these
SRV records for server-to-server functionality, the SRV record lists a
port of 5269, which is the server-to-server port for xmpp).

>>> if I recall discussions with Paul and Martin on the
>> I do not recall that discussion.
> 
> <http://article.gmane.org/gmane.org.w3c.uri/578>  Sorry,
> it was Bruce and Paul, Matin was in other mailto-threads.

Thanks.

Peter

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

---

From: SM <[email-masked]>
Date: Tue, 06 Nov 2007 17:13:48 -0800

>defined in RFCs 3859 and 3860 respectively). See also RFC 2779.

I read draft-saintandre-header-im-00.  I must have missed 
draft-saintandre-header-pres-00.

I hope there's not going to be a new header each time there's a new 
feature. :-)

>These I-Ds are my good-faith attempt at fulfilling my promise to work on

Could we have only one I-D which is extensible to encompass all these 
schemes?  I assume that will be draft-saintandre-header-pres-01.

BTW, the Author's address in your draft seems incomplete.

Regards,
-sm

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Nov 2007 02:56:19 -0700

> draft-saintandre-header-pres-00.

I submitted both of the following:

http://tools.ietf.org/html/draft-saintandre-header-im-00

http://tools.ietf.org/html/draft-saintandre-header-pres-00

> I hope there's not going to be a new header each time there's a new

I'm not sure what you mean by "feature". According to RFC 2779, IM and
presence are separate domains of functionality, which is why there is an
im: URI scheme and a pres: URI scheme. I don't foresee other such URIs.

> schemes?  I assume that will be draft-saintandre-header-pres-01.

What are "these schemes"? What is the category under which it is
perceived that the im: scheme and the pres: scheme are the same? Again,
according to RFC 2779, RFC 3859, and RFC 3860, these are separate and
distinct domains of functionality, which just happen to often be
implemented and deployed in the same systems or services.

> BTW, the Author's address in your draft seems incomplete.

Because it doesn't include every URI scheme under the sun? ;-)

Peter

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

---

From: SM <[email-masked]>
Date: Wed, 07 Nov 2007 09:47:15 -0800

Thanks.

>im: URI scheme and a pres: URI scheme. I don't foresee other such URIs.

Quoting the drafts:

    Because almost all human users of instant messaging systems are users
    of email systems, it can be helpful for such users to specify their
    (IM/presence) URIs in the email messages they author.

Although IM and presence are separate domains of functionality, the 
proposed mail headers for them :-

   1. provides a standard location for the exchange of such information

   2. are associated with the author of the message

   3. uses similar syntax for the URI

>implemented and deployed in the same systems or services.

You are viewing the im: scheme and the pres: scheme from the point of 
view of their RFCs which is different from the functionality offered 
by the mail header.  In a previous email, you mentioned a generic 
solution.  My point is that it is better to have a generic mail 
header to encompass pres:, im: and other schemes that would use URIs 
in such a manner.

We could have, for example, the following header:

Contact-ID: pres:[email-masked]; im:[email-masked]

The MUA would process the header to determine whether there is a 
presence URI or IM URI and take appropriate action.

>Because it doesn't include every URI scheme under the sun? ;-)

No, it's because it doesn't contain a snail mail address to support 
legacy communication channels. :-)

Regards,
-sm

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Nov 2007 16:49:05 -0700

> view of their RFCs which is different from the functionality offered by
> the mail header.  In a previous email, you mentioned a generic
> solution.  My point is that it is better to have a generic mail header
> to encompass pres:, im: and other schemes that would use URIs in such a
> manner.
> 

But what is a Contact-ID? Any means by which you could contact me might
be included in that category -- email, telephone, voicemail, fax, post
office box, various IM addresses, IRC channels where I hang out, etc.

And in fact a pres: URI does not provide a means of contact. It provides
a way for you to know about my network availability, but you can't
communicate with me via that URI, so it's not a Contact-ID at all.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 08 Nov 2007 09:01:58 -0700

SM wrote:
> At 15:49 07-11-2007, Peter Saint-Andre wrote:
> A contact can be a channel of communication.  In the case of your
> drafts, it's a channel which can be associated with a URI.  If you find
> the header name inappropriate, you can invent another term for it.
> 
> The pres: URI provides a means to retrieve presence information.  It's
> indirectly a means of contact.

I don't think it makes sense for me to say "contact me at my presence
URI" because there's no way for me to receive inbound communications at
that URI. It is purely outbound from me to the world.

I wrote draft-saintandre-header-im and draft-saintandre-header-pres (now
both in version -01) to address some feedback I received during IETF LC
regarding draft-saintandre-jabberid. I think now it would be appropriate
for those who provided that feedback to say whether they think these new
I-Ds address that feedback, whether they think the drafts needs to be
consolidated as you have suggested, etc.

Peter

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 08 Nov 2007 12:51:01 -0500

Personally I think I liked the original jabberid concept better, but
all of these concepts seem acceptable and the important thing in my
mind is for us to pick one and standardize it.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 11 Nov 2007 20:57:09 +0000

> At 01:56 07-11-2007, Peter Saint-Andre wrote: 

 [...]

> to encompass pres:, im: and other schemes that would use URIs in such 
> a manner.

+1. I don't see why 2 nearly identical header fields are needed.

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.

Regarding the recommended syntax: it is worth considering syntax used by 
List-Archive/List-Unsubscribe/... (RFC 2369) header fields, which are 
surrounded by '<' and '>', e.g.:

List-Archive: <http://www.imc.org/ietf-imapext/mail-archive/>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 22 Nov 2007 15:30:32 -0800

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)

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 26 Nov 2007 16:11:47 -0700

> (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:

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/