OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Content-Id cid: References

Here are the statements I quoted from the relevant RFCs that
eventually caused the WSS TC (at the request of the WS-I BSP WG) to
revisit the issue of how to accomplish attachment security.

First, some definitions from RFC 2045 (Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies,

  The term "entity", refers specifically to the MIME-defined header
  fields and contents of either a message or one of the parts in the
  body of a multipart entity.

  The term "body part" refers to an entity inside of a multipart

  The term "body", when not further qualified, means the body of an
  entity, that is, the body of either a message or of a body part.

So a "body part" consists of header fields and a "body" (contents).

RFC 2392 (Content-ID and Message-ID Uniform Resource Locators,
http://www.ietf.org/rfc/rfc2392.txt), says:

  The "mid" (Message-ID) and "cid" (Content-ID) URL schemes provide
  identifiers for messages and their body parts.  ...  The "cid"
  scheme refers to a specific body part of a message; its use is
  generally limited to references to other body parts in the same
  message as the referring body part.

  A note on terminology.  The terms "body part" and "MIME entity" are
  used interchangeably.  They refer to the headers and body of a MIME
  message, either the message itself or one of the body parts
  contained in a Multipart message.

So when talking about an entity inside a MIME message, 2392's
terminology is consistent with 2045, to which it refers, and it
clearly intends cid: to refer to the entire body part, which includes
headers, not just the body.

In my opinion, referring to just the body of an entity is of limited
utility.  The Content-* headers contain metadata that should not
simply be discarded during the dereferencing process, because they
give important hints about how to process the body itself.

Pete Wenzel <pete@seebeyond.com>
Senior Architect, SeeBeyond
Standards & Product Strategy
+1-626-471-6311 (US-Pacific)

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]