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

[Peter Saint-Andre <[e-mail]>]

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

Peter

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:
>>
>> 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: [e-mail]
>         Resent-From: [e-mail], [e-mail]
>         From: [e-mail], [e-mail]
>         Sender: (see RFC 3192) "FAX=[phone]"@l.com
>         Reply-To: foo list: [e-mail], [e-mail];
> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-message-headers