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

Peter Saint-Andre <> Thu, 28 September 2006 20:06 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GT29V-0005Og-Fc; Thu, 28 Sep 2006 16:06:37 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1GT29T-0005OO-GQ for; Thu, 28 Sep 2006 16:06:35 -0400
Received: from ([] by with esmtp (Exim 4.43) id 1GT29R-0007Tc-On for; Thu, 28 Sep 2006 16:06:35 -0400
Received: from [] (localhost []) by (Postfix) with ESMTP id F3C9F524A4E for <>; Thu, 28 Sep 2006 14:06:17 -0600 (MDT)
Message-ID: <>
Date: Thu, 28 Sep 2006 14:06:17 -0600
From: Peter Saint-Andre <>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv: Gecko/20060909 Thunderbird/ Mnenhy/
MIME-Version: 1.0
Subject: Re: [Ietf-message-headers] Jabber-ID header field
References: <> <>
In-Reply-To: <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Discussion list for header fields used in Internet messaging applications." <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============1305070695=="

Thanks for the feedback. I probably won't have time to reply for about a
week or two, but will do so then.


Bruce Lilly wrote:
> On Tue September 12 2006 16:22, Peter Saint-Andre wrote:
>> The following Internet-Draft defines a header field for encapsulating a
>> Jabber Identifier:
>> In accordance with RFC 3864, feedback from this list is requested.
> There are several issues with the proposal and with the draft, and I
> can suggest a method to avoid the issues.  First, issues with the
> draft:
> [N.B. I recommend reading to the end of this message before reading
> referenced RFCs, as many points may be moot if a different approach,
> such as the one suggested near the end of this message, is taken]
> 1. the draft has apparently been replaced [the URI above results in a 402
>    error], so I'll comment on -04
> 2. See RFC 4249 and its references, paying particular attention to sections
>    3.1.1, 3.2.1, 3.2.2, 3.3.1, 3.3.2, 3.3.3, and 3.4.1.  Section 3.4.4 might
>    or might not be applicable (it is unclear from the draft).  Some
>    specifics:
>    a) note that some proposed syntax conflicts with RFC 2822 (e.g. ';' is
>       an RFC 2822 "special").
>    b) I believe that the peculiarity of use of an obs- construct in a
>       proposed new field has already been noted.
>    c) the security considerations section seems rather light.
>    d) the draft wording could use improvement for clarity and to remove
>       ambiguities (e.g. "Message headers are an existing standard"; is that
>       supposed to be plural or singular?)
> Issues with the proposal per se:
> A. [Abstract] "associating the email message or sender with a particular
>    Extensible Messaging and Presence Protocol (XMPP) address".  Curiously,
>    this is not discussed in the body of the draft per se.  Several
>    questions:
>    a) what exactly does it mean to associate an ID of this type with a
>       message?
>    b) how does a recipient determine whether an ID is supposed to be
>       associated with a message or with "sender"?
>    c) given the following snippet of fields from a message, and assuming
>       that the ID is supposed to be associated with "sender" rather than
>       with the message per se, exactly which mailbox or set of mailboxes
>       corresponds to the draft use of the word "sender"?
>         Resent-Sender:
>         Resent-From:,
>         From:,
>         Sender: (see RFC 3192) "FAX=+33-1-88335215"
>         Reply-To: foo list:,;
> B. There appears to be no provision for line folding within an ID (RFC
>    4622 "pathxmpp" production).
> C. There appears to be no upper bound on the length of an ID, either in
>    raw form or when "converted".
> D. What happens when an ID exceeds 998 octets in length (N.B. maximum
>    header field line length in RFC 2822 is 998 octets; also note the
>    recommended maximum of 78 octets)?
> E. Why not start with registration in the provisional registry rather than
>    the permanent registry (see BCP 90 (a.k.a. RFC 3864) section 2.1)?  Is
>    it the author's assertion that this field is now in widespread use?
> A possible solution to the issues noted above: instead of a message header
> field, specify a media type (presumably under the "application" IETF tree;
> see BCP 13 ,a.k.a. RFC 4288).  Advantages:
> i.   no content restriction if binary transfer is used or if a transfer
>      encoding is applied
> ii.  no need to "convert" ID under the above conditions
> iii. no conflicts with RFC 2822 syntax (RFC 2822 "specials", line length
>      limits, parentheses vs. comments, etc.)
> iv.  a media type (applicable parameters or content) can be defined to
>      specify whether an ID is to be associated with a message, with some
>      mailbox, or with some other object.
> v.   transfer is possible via any mechanism which uses MIME (e.g. HTTP)
>      and perhaps via some mechanisms which use MIME media types but not
>      MIME per se (RTP), not limited to email.
> vi.  in MIME contexts, additional MIME fields can be used to affect
>      presentation and/or to provide auxiliary information (e.g.
>      Content-Disposition, Content-Description fields)
> security issues would still need to be more fully fleshed out (see RFC
> 3552).

Ietf-message-headers mailing list