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

[Bruce Lilly <[e-mail]>]

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