Matching procedure for multipart/related parameter "start" and content-id header value,

["Moberg Dale" <dmoberg@axway.com>]

The RFC 2387 defining multipart/related doesn't say too much about the
procedure for matching the parameter "start"'s value with the value in
the content-id header, unlike what is said for matching/resolving a
cid:x@y URI to its body part by means of the content-id field.

The abnf in 2387 says

  related-param   := [ ";" "start" "=" cid ]
                        [ ";" "start-info"  "="
                           ( cid-list / value ) ]
                        [ ";" "type"  "=" type "/" subtype ]
                        ; order independent
 
     cid-list        := cid cid-list
 
     cid             := msg-id     ; c.f. [822]

and [822] said 

msg-id      =  "<" addr-spec ">"            ; Unique message id

But [2822] says

  The message identifier (msg-id) is similar in syntax to an angle-addr
   construct without the internal CFWS.

(so comments and whitespace are not allowed as they would be in
addr-spec)

and, most importantly,

Semantically, the angle bracket characters are not part of the
   msg-id; the msg-id is what is contained between the two angle bracket
   characters.

(The abnf for msg-id in [2822] differs from [822] but I don't think
those differences are relevant here.)


It is very clear what the matching procedure is for the cid scheme in
cid URIs in RFC 2392

A "cid" URL is converted to the corresponding Content-ID message
header [MIME] by removing the "cid:"; prefix, converting the % encoded
character to their equivalent US-ASCII characters, and enclosing the
remaining parts with an angle bracket pair, "<" and ">".  For
example, "cid:foo4%25foo1@bar.net"; corresponds to

     Content-ID: <foo4%25foo1@bar.net>

Reversing the process and converting URL special characters to their
% encodings produces the original cid.


So, the content-id MIME header's value needs to have angle brackets
around it according to both [822 & 2822].

So the safest matching procedure for the "start" parameter value and the
content-id value would be an "angle-bracket-insensitive" one, it seems
to me and taking [2822] seriously when it says that "Semantically, the
angle bracket characters are not part of the msg-id; the msg-id is what
is contained between the two angle bracket characters." So removing
leading 
or trailing angle brackets on the content-id value and the "start"
parameter value (if they are present), and comparing the strings
(case-sensitively) should promote interoperability and semantic
alignment. 

ebMS examples are not normative. But maybe the TC should at least
consider whether to issue an errata on the examples, and maybe suggest
the "angle-bracket-insensitive" comparison method for implementers to
use (not normative though).

I think that is unclear whether the angle brackets should be included in
the start parameter value, and if you are used to the CID URI procedure
from, for example, WSS SOAP with Attachment profile, then there is a
tradition for not including the angle brackets. All told, it might be
best not to 
count on them being present in the start parameter value. Unfortunately
ebMS cannot really resolve the ambiguity in the multipart/related RFC
that we normatively referenced. So an implementer's advisory might be
the best ebMS TC could do.