Subject: [Ietf-message-headers] draft-saintandre-header-pres-00.txt etc.

From: Bruce Lilly <[email-masked]>
Date: Tue, 1 Jan 2008 20:57:15 -0500

N.B. replies directed to the ietf-message-headers [sic] mailing list.

On Tuesday 06 November 2007 15:03:13 Peter Saint-Andre wrote:
> Frank Ellermann wrote:

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

You're getting decades ahead of yourself -- see below.

> > 3 - what about Netnews ?
...and telnet and SIP and http...  Are we to see additional drafts for
schemes to cram this information into telnet sessions, web site traffic,
telephone calls, etc.?  Or maybe you'd like to add options to send that
information in every IP packet...:-)

On Tuesday 06 November 2007 16:58:23 Peter Saint-Andre wrote: 

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

With the proposed scheme, you would need to:
1. convince message authors to include such information via your scheme
   instead of or in addition to other mechanisms.
2. convince the authors of all MUAs used by those authors to support your
   scheme (so that the authors CAN include it per #1)
3. convince the authors of your MUA to support your scheme on your platform
   of choice (ask Frank about support for OS/2...)
4. wait a decade or two for users to upgrade to the revised versions of MUAs

...and it still won't help you if you have such information which arrived
via another mechanism unless you also have a way to get that into your MUA
(see below).  Nor will it help you if the information is not current (also
see below).

On Wednesday 07 November 2007 18:49:05 Peter Saint-Andre wrote:

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

But one which is specific to a component of an unrelated *protocol* rather
than being associated with the *human* in question, and is inexplicably
separate from established, standardized, and broadly-implemented
protocol-independent mechanisms for providing such personal (i.e. not
specific to the protocol used for transport of the information) information.

> >   2. are associated with the author of the message

or authors (plural)? -- see the RFC 2822 definition of the From field, which
may specify multiple authors.  Also see Resent-From and Sender and Reply-To.
Now exactly which parts of which of these fields is the proposed information
supposed to apply to?

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

...all information which can be conveyed in the established, standardized
(RFC 2426), broadly-implemented "vCard" mechanism, with which I assume you
are familiar (as it is mentioned in RFC 3921).  Why not simply put the
desired information (as URIs or whatever) in a vCard, which can be
transferred as a MIME attachment to email (and which specifies within the
vCard itself precisely to whom the information applies, rather than
depending on guessing to which of multiple authors, sender, etc. it might
apply), or via transfer by http, ftp, or carrier pigeon (by way of any
physical digital media such as flash memory, magnetic or optical media, or
even ASR-33 punched paper tape).  And if one wishes to make use of that
information in, say, Thunderbird (which already has vCard support, as do
many other MUAs), then you can do so quite easily and it doesn't matter
whether the vCard information came in an email message or was imported
from a file transported by some other mechanism.  If you wish to make use
of the information outside of email, it is only necessary that that
environment support the established, standardized vCard mechanism.
Authors who wish to include such information can do so by putting it in
their vCard and sending it (e.g. by email WITHOUT(N.B.!) having to wait
for MUAs to have special-purpose support added).

Message header fields, like IP packet header fields, ought to convey
information about the message (or packet) which they are part of; not
random unrelated stuff.  It is already the case that a simple short text
message of a few dozen bytes of message text body may be accompanied by
several kilobytes of message header text.  Most of that information is
(supposed to be) related to that message.

Personal contact information belongs in a vCard or something like it, not
in message headers or IP packet headers unless it is specifically and
directly related to the particular message or IP packet in question.

Another reason to put such information in a vCard and NOT in a message
header field:  messages may be archived for years or decades; contact
information may change frequently.  If your scheme were to come to pass
and you were viewing an archived message a decade from now, would it not
be likely to fail to provide the supposed (i.e. then-current, not outdated)
contact/presence information?  Per contra, if the information comes from a
recent vCard (rather than from the header of an old message), would that
not more likely contain up-to-date information?  After all, it is a
relatively simple matter for a recipient to update information from a
vCard, whereas it is impractical to alter message header fields of every
email message that a particular person has sent when some personal contact
information changes.

The three proposals (jabber-id and the current two) strike me as a symptom
of "let's invent a header field to do..." syndrome rather than a careful
and studied consideration of *appropriate* mechanisms to convey the
information concerned.

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 02 Jan 2008 09:34:38 -0700

> You're getting decades ahead of yourself -- see below.

Apple Mail has had a feature like this for years (based on information 
in the address book, not a mail header), so I don't think I'm getting 
decades ahead of myself. In fact perhaps I'm several years behind the 
market.

Peter

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

---

From: Bruce Lilly <[email-masked]>
Date: Wed, 2 Jan 2008 16:19:10 -0500

> decades ahead of myself. In fact perhaps I'm several years behind the 

You may have missed my point, which is precisely that using an address book
or other repository which can be easily updated via VCards (or LDAP, etc.)
is much more likely to yield results quickly as opposed to convincing
software authors to support special-purpose code to extract unrelated
data from message header fields, waiting for such special-purpose code
to be written, waiting for users to upgrade, etc.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 02 Jan 2008 14:29:52 -0700

> to be written, waiting for users to upgrade, etc.

You may have missed the point of the Jabber-ID header, which we defined 
so that the community of Jabber users could experiment with this usage. 
Whether that usage is the most effective way to tie together an email 
identity with a Jabber identity is another issue. We started to define 
the pres and im headers as a more general approach, but it could be that 
neither the general approach nor the specific Jabber approach is needed 
or even desirable.

Thanks for the feedback -- I'll keep it in mind if I ever decide to 
pursue these I-Ds further (which I rather doubt).

Peter

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 3 Jan 2008 05:51:13 +0100

Peter Saint-Andre wrote:

> You may have missed the point of the Jabber-ID header, which we
> defined so that the community of Jabber users could experiment
> with this usage. 
[...]
> Thanks for the feedback -- I'll keep it in mind if I ever decide
> to pursue these I-Ds further (which I rather doubt).

IMO the Jabber-ID header field makes sense, it has a modern syntax,
and might be better than attaching a complete vCard to a message:

Apparently the optional "profile" associated with a JID is more or
less the same as a vCard.   The Last Called Jabber-ID draft (you
have already fixed a minor FWS issue) only needs IESG approval and
an RFC number.  Whatever backchamber conspiracy "persuaded" you to
"withdraw" it - but if it was the "DEA directorate" I'll scream.

 Frank

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Jan 2008 08:50:21 -0700

> "withdraw" it - but if it was the "DEA directorate" I'll scream.

On 2007-12-04 I posted an updated version incorporating your FWS and 
Netnews suggestions, and per my request the IANA has added the header to 
the provisional registry (RFC status is not required for registration, 
in accordance with RFC 3864). It is an open question whether I will ever 
request a standards action regarding this specification. As to the DEA, 
I don't think the Drug Enforcement Administration was involved. ;-)

Peter

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 3 Jan 2008 18:04:17 +0100

Peter Saint-Andre wrote:

OE claims you wrote nothing, phhhtt... fetching MIME part:

> per my request the IANA has added the header to the 
> provisional registry (RFC status is not required for
> registration, in accordance with RFC 3864).

Yes, but a provisional registration based on an expired
draft is "suboptimal", a permanent registration based on
*some kind of public standard* (not necessarily an RFC)
is better.  

My "marauder's map for the IETF labyrinth" (aka Brian's 
procdoc ION) indicates that XMPP is an SDO with some kind
of IETF liaison, an "XEP" might be good enough.  Okay, if
Graham is no Harry Potter or XMPP fan you need an RFC :-)

> It is an open question whether I will ever request a 
> standards action regarding this specification.

Maybe discuss it with the XMPP community or XMPP Council
or whatever it takes - the SPF organization is far simpler,
we have only one RFC to guard, or four counting those that
we never wanted.  If nobody needs the header field anymore
don't waste time with it.

> I don't think the Drug Enforcement Administration was

Good, and what I had in mind doesn't exist anymore, better.

 Frank
-- 
Fixed IAB & DEA links on http://en.wikipedia.org/wiki/MARID