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

On Tue September 12 2006 16:22, Peter Saint-Andre wrote:
> The following Internet-Draft defines a header field for encapsulating a
> Jabber Identifier:
> 
> http://www.ietf.org/internet-drafts/draft-saintandre-jabberid-03.txt
> 
> 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: 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;
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
Ietf-message-headers@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-message-headers