Richard,
That is a good point. The multipart/related RFC indicates that the root
media type would be the "type" parameter. Since there is only one CEM
Request in the multipart, this would be implicit root without using the
start parameter. If it will reduce confusion, we could require the start
parameter. But like you said, I am not sure if the root designation and is
particularly important in this case since there will only be one CEM Request
element per message.
Kyle Meadors
DGI
-----Original Message-----
From: Richard Bigelow [mailto:richard.bigelow@xxxxxxxxxx]
Sent: Wednesday, November 03, 2004 7:26 PM
To: ietf-ediint@xxxxxxx; Kyle Meadors (E-mail)
Subject: RE: changes to CEM message structure
Kyle,
Will the multipart have a start parameter? RFC 2112 "The MIME
Multipart/Related Content-type" says
3.2. The Start Parameter
The start parameter, if given, is the content-ID of the compound
object's "root". If not present the "root" is the first body part in
the Multipart/Related entity. The "root" is the element the
applications processes first.
Normally, the root is the CEM request. Making that explicit might avoid
problems where parts are reordered or generated out of order. For example,
someone might generate the cert parts first and then the request, so the IDs
are already generated when the request is built. Of course, one could
generate the IDs while building the request and then use them in the later
cert parts, so either order works.
If a profile is included, the root should still be the CEM Request. The
profile should be just another part with a distinguished type. Receivers
should be able to ignore this part. (Logically, the profile should be the
root, since the request is subsidiary to that. But the format should be the
same, so that profiles can be ignored.)
Perhaps you don't want to have a root. Just process the request and
certs-only parts and any profiles that are understood, and ignore the rest.
Order and root don't matter.
Richard Bigelow
Inovis
-----Original Message-----
From: owner-ietf-ediint@xxxxxxxxxxxx
[mailto:owner-ietf-ediint@xxxxxxxxxxxx]
Sent: Tuesday, November 02, 2004 12:07 PM
To: ietf-ediint@xxxxxxx
Subject: changes to CEM message structure
Per the CEM draft review by the IETF area directors, the draft editors were
informed the need to modify the format of the digital certificate
distribution to the PKCS#7 SMIME certs-only media type since this is a well
established standard.
Based on this, the draft editors would like to modify the CEM message
structure to something like this:
Content-Type: Multpart/related; type=”ediint-cert-exchange+xml”;
boundary=foo
--foo
Content-Type: Ediint-cert-exchange+xml
[CEMRequest XML]
--foo
Content-Type: Application/pkcs7-mime; smime-type=certs-only
Content-ID: <end-entity123@xxxxxxxxxxx>
[end-entity cert being exchanged]
--foo
Content-Type: Application/pkcs7-mime; smime-type=certs-only
Content-ID: <ca-cert123@xxxxxxxxxxx>
[CA cert to complete the trust chain on the end-entity]
--foo--
The CEMRequest XML would be modified. The <ds:X509Data> element would be
replaced with a new element, say <Content-Id>, which would reference the
MIME Content-ID of the certificate in the multipart-related structure. No
other parts of the XML body would need to be altered.
The use of multipart/related is a natural choice since this was the future
direction of the profile exchange described in section 5 of the draft.
Does the list have comments on this suggestion? Are there other alternatives
we should consider? Unless there is reservations about this choice, the
draft editors will implement this multipart/related structure and resubmit
the updated draft both to the EDIINT list and the IETF area directors end of
next week.
Kyle Meadors
Program Manager
Drummond Group Inc.
615.384.5006
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.784 / Virus Database: 530 - Release Date: 10/27/2004
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.784 / Virus Database: 530 - Release Date: 10/27/2004
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.784 / Virus Database: 530 - Release Date: 10/27/2004
|
