RE: [ebxml-msg] Matching procedure for multipart/related parameter "start"and content-id header value,

Dale,

Good analysis.  I concur implementer's advisory note is needed.

What we don't want here is for people to try an enforce a more restrictive need on everyone else.  The least common denominator just makes plain common sense.

Thanks, DW

-------- Original Message --------

Subject: [ebxml-msg] Matching procedure for multipart/related parameter

"start" and content-id header value,

From: "Moberg Dale" <>

Date: Mon, October 05, 2009 2:44 pm

To: <>

Cc: <>

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:" corresponds to

     Content-ID: <>

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.

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail.  Follow this link to all your TCs in OASIS at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php