[Ietf-message-headers] Re: Jabber-ID header field

Frank Ellermann <nobody@xyzzy.claranet.de> Thu, 28 September 2006 22:59 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT4qR-0003m2-0I; Thu, 28 Sep 2006 18:59:07 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GT4qP-0003k4-T4 for ietf-message-headers@lists.ietf.org; Thu, 28 Sep 2006 18:59:05 -0400
Received: from main.gmane.org ([] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GT4qM-0001ch-BM for ietf-message-headers@lists.ietf.org; Thu, 28 Sep 2006 18:59:05 -0400
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GT4q9-0003Ov-WC for ietf-message-headers@lists.ietf.org; Fri, 29 Sep 2006 00:58:50 +0200
Received: from pd9fba8b5.dip0.t-ipconnect.de ([]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-message-headers@lists.ietf.org>; Fri, 29 Sep 2006 00:58:49 +0200
Received: from nobody by pd9fba8b5.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <ietf-message-headers@lists.ietf.org>; Fri, 29 Sep 2006 00:58:49 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: ietf-message-headers@lists.ietf.org
From: Frank Ellermann <nobody@xyzzy.claranet.de>
Date: Fri, 29 Sep 2006 00:54:04 +0200
Organization: <URL:http://purl.net/xyzzy>
Lines: 69
Message-ID: <451C528C.2680@xyzzy.claranet.de>
References: <45071704.6020400@jabber.org> <200609280321.25180@mail.blilly.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: pd9fba8b5.dip0.t-ipconnect.de
X-Mailer: Mozilla 3.0 (OS/2; U)
Jabber-ID: xyzzy@ursine.ca
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Subject: [Ietf-message-headers] Re: Jabber-ID header field
X-BeenThere: ietf-message-headers@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Discussion list for header fields used in Internet messaging applications." <ietf-message-headers.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-message-headers>, <mailto:ietf-message-headers-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf-message-headers@ietf.org>
List-Help: <mailto:ietf-message-headers-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-message-headers>, <mailto:ietf-message-headers-request@ietf.org?subject=subscribe>
Errors-To: ietf-message-headers-bounces@ietf.org

Bruce Lilly wrote:

  [Peter wrote]
>> In accordance with RFC 3864, feedback from this list is
>> requested.

BTW, that's not required for header fields with a proper RFC,
but obviously a good idea.

> some proposed syntax conflicts with RFC 2822 (e.g. ';' is
> an RFC 2822 "special").

Grmbl, yes.  Do you have a tool for this ?  My experiments
in this direction are not in a state where I could simply
put ABNF in and get conflicts out.

All of <unreserved> and <pct-encoded> is <atext>, so far no
problem.  But <node-allow> and <res-allow> run into troubles.

> I believe that the peculiarity of use of an obs- construct
> in a proposed new field has already been noted.

That's just the known issue of "no folding in a FWS directly
before a CRLF" combined with the 2822 accept obs-FWS MUSTard
in a pending erratum.

> exactly which mailbox or set of mailboxes corresponds to the
> draft use of the word "sender"?
>         Resent-Sender: a@b.org
>         Resent-From: c@d.net, e@f.gov
>         From: g@h.edu, i@j.org
>         Sender: (see RFC 3192) "FAX=+33-1-88335215"@l.com
>         Reply-To: foo list: m@n.org, o@p.edu;

It's no Resent-Jabber-ID, the Resent-* are out.  The Reply-To
is for mail replies, the Jabber-ID for jabber replies.  The
I-D says that the Sender sets the Jabber-ID.  Like it sets
the Reply-To.  Per message.  From that I'd expect that I can
discuss the given message per mail on foo list, with m@n org,
or with o@p edu.  Or I can discuss it via jabber with JID.

Testing that theory with JID stpeter@ it worked as expected.

> There appears to be no provision for line folding within an
> ID (RFC 4622 "pathxmpp" production).

Yes, same issue as for <msg-id> and <addr-spec> in RFC 2822.
What do you propose, a statement "make sure that a Jabber-ID
isn't longer than 997 octets" ?

> What happens when an ID exceeds 998 octets in length

The nice MSA will reject the message as specified in RFC 4409.

> Why not start with registration in the provisional registry

Permanent and RFC is better for MUA implementors.

Your media type proposal strikes me as odd, the JID could then
be also added to some existing vcard or similar "attachment"...

Nobody would use it, and we're back at square one.  With the
JID as header field you implicitly have the vcard, if you have
an UA suppporting to retrieve the user info of the given JID.

Some hen and egg issue here, the JID is an egg.


Ietf-message-headers mailing list