From owner-ietf-ediint@mail.imc.org  Tue Nov  2 15:40:02 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09309
	for <ediint-archive@lists.ietf.org>; Tue, 2 Nov 2004 15:40:02 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2K6dCo063820;
	Tue, 2 Nov 2004 12:06:39 -0800 (PST)
	(envelope-from owner-ietf-ediint@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id iA2K6dId063819;
	Tue, 2 Nov 2004 12:06:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f
Received: from drummondgroup.com (drummondgroup.com [161.58.166.198])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id iA2K6cxn063728
	for <ietf-ediint@imc.org>; Tue, 2 Nov 2004 12:06:39 -0800 (PST)
	(envelope-from kyle@drummondgroup.com)
Received: from KYLEDGILAPTOP (pcp517486pcs.nash01.tn.comcast.net [68.53.139.87])
	by drummondgroup.com (8.12.11/8.12.11) with ESMTP id iA2K6WlN004564
	for <ietf-ediint@imc.org>; Tue, 2 Nov 2004 13:06:33 -0700 (MST)
Message-Id: <200411022006.iA2K6WlN004564@drummondgroup.com>
From: "Kyle Meadors" <kyle@drummondgroup.com>
To: <ietf-ediint@imc.org>
Subject: changes to CEM message structure
Date: Tue, 2 Nov 2004 14:06:34 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcTBF3NOmdTFsP3DSYmZhi8+VuxCAw==
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA2K6dxn063814
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit


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@example.org>
     [end-entity cert being exchanged]
    --foo
   Content-Type: Application/pkcs7-mime; smime-type=certs-only
   Content-ID: <ca-cert123@example.org>
     [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
 




From owner-ietf-ediint@mail.imc.org  Wed Nov  3 08:06:24 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05826
	for <ediint-archive@lists.ietf.org>; Wed, 3 Nov 2004 08:06:24 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3Clvit018938;
	Wed, 3 Nov 2004 04:47:57 -0800 (PST)
	(envelope-from owner-ietf-ediint@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id iA3ClvsJ018937;
	Wed, 3 Nov 2004 04:47:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f
Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id iA3CluIk018830
	for <ietf-ediint@imc.org>; Wed, 3 Nov 2004 04:47:56 -0800 (PST)
	(envelope-from sah@428cobrajet.net)
Received: from dul1shollenbl1 ([::ffff:216.168.239.87])
  (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5)
  by mail.verisignlabs.com with esmtp; Wed, 03 Nov 2004 07:47:46 -0500
  id 00540183.4188D372.00001219
From: "Scott Hollenbeck" <sah@428cobrajet.net>
To: "'Kyle Meadors'" <kyle@drummondgroup.com>, ietf-ediint@imc.org
Subject: RE: changes to CEM message structure
Date: Wed, 3 Nov 2004 07:47:41 -0500
Message-ID: <7468147AEE316B41B3B55152959CE218129194@dul1wnexm05.vcorp.ad.vrsn.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <200411022006.iA2K6WlN004564@drummondgroup.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Kyle,

Which working group document is the proposal below referring to?  The only
document currently under consideration by the IESG is the AS2 document, and
I can't find any mention of a CEMRequest element in that document.

-Scott-

> -----Original Message-----
> From: Kyle Meadors [mailto:kyle@drummondgroup.com] 
> Sent: Tuesday, November 02, 2004 3:07 PM
> To: ietf-ediint@imc.org
> 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@example.org>
>      [end-entity cert being exchanged]
>     --foo
>    Content-Type: Application/pkcs7-mime; smime-type=certs-only
>    Content-ID: <ca-cert123@example.org>
>      [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



From owner-ietf-ediint@mail.imc.org  Wed Nov  3 20:18:26 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10188
	for <ediint-archive@lists.ietf.org>; Wed, 3 Nov 2004 20:18:24 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id iA410IM8017011;
	Wed, 3 Nov 2004 17:00:18 -0800 (PST)
	(envelope-from owner-ietf-ediint@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id iA410IH1017010;
	Wed, 3 Nov 2004 17:00:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f
Received: from drummondgroup.com (drummondgroup.com [161.58.166.198])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id iA410GeH016928
	for <ietf-ediint@imc.org>; Wed, 3 Nov 2004 17:00:17 -0800 (PST)
	(envelope-from kyle@drummondgroup.com)
Received: from KYLEDGILAPTOP (pcp517486pcs.nash01.tn.comcast.net [68.53.139.87])
	by drummondgroup.com (8.12.11/8.12.11) with ESMTP id iA410Dr4085638
	for <ietf-ediint@imc.org>; Wed, 3 Nov 2004 18:00:13 -0700 (MST)
Message-Id: <200411040100.iA410Dr4085638@drummondgroup.com>
From: "Kyle Meadors" <kyle@drummondgroup.com>
To: <ietf-ediint@imc.org>
Subject: RE: changes to CEM message structure
Date: Wed, 3 Nov 2004 19:00:10 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <7468147AEE316B41B3B55152959CE218129194@dul1wnexm05.vcorp.ad.vrsn.com>
x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcTBpP5k4zhN3m+MQamP8Zt564ipEAAZDdmA
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Scott,

I was referring to the draft-ediint-certificate-exchange-00 which I
submitted last month. Russ Housley express some concerns this overlapped
with efforts in PKIX. Dale Moberg spoke with Russ about implementing the
pkcs7 certs-only type as the format for distributing the certificate.

Kyle Meadors
DGI

-----Original Message-----
From: owner-ietf-ediint@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org]
On Behalf Of Scott Hollenbeck
Sent: Wednesday, November 03, 2004 6:48 AM
To: 'Kyle Meadors'; ietf-ediint@imc.org
Subject: RE: changes to CEM message structure


Kyle,

Which working group document is the proposal below referring to?  The only
document currently under consideration by the IESG is the AS2 document, and
I can't find any mention of a CEMRequest element in that document.

-Scott-

> -----Original Message-----
> From: Kyle Meadors [mailto:kyle@drummondgroup.com] 
> Sent: Tuesday, November 02, 2004 3:07 PM
> To: ietf-ediint@imc.org
> 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@example.org>
>      [end-entity cert being exchanged]
>     --foo
>    Content-Type: Application/pkcs7-mime; smime-type=certs-only
>    Content-ID: <ca-cert123@example.org>
>      [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


---
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
 



From owner-ietf-ediint@mail.imc.org  Wed Nov  3 20:34:09 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11479
	for <ediint-archive@lists.ietf.org>; Wed, 3 Nov 2004 20:34:09 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id iA41PD3u027844;
	Wed, 3 Nov 2004 17:25:13 -0800 (PST)
	(envelope-from owner-ietf-ediint@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id iA41PDEO027843;
	Wed, 3 Nov 2004 17:25:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f
Received: from atlrelay1.inovisinc.com (atlrelay1.inovisinc.com [206.113.209.242])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id iA41PCNC027787
	for <ietf-ediint@imc.org>; Wed, 3 Nov 2004 17:25:12 -0800 (PST)
	(envelope-from richard.bigelow@inovis.com)
Received: from alfexfe1.itlogon.com (atlrelay1.itlogon.com [127.0.0.1])
	by atlrelay1.inovisinc.com (8.11.6/8.11.6) with ESMTP id iA40ZVB08213;
	Wed, 3 Nov 2004 19:35:31 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: changes to CEM message structure
Date: Wed, 3 Nov 2004 20:26:11 -0500
Message-ID: <EAEB90549BF1D445A923FD7C692534DBCE9581@npbexmb1.itlogon.com>
Thread-Topic: changes to CEM message structure
Thread-Index: AcTBF3NOmdTFsP3DSYmZhi8+VuxCAwAzXwyQ
From: "Richard Bigelow" <richard.bigelow@inovis.com>
To: <ietf-ediint@imc.org>, "Kyle Meadors \(E-mail\)" <kyle@drummondgroup.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA41PDNC027838
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit


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@mail.imc.org
[mailto:owner-ietf-ediint@mail.imc.org]
Sent: Tuesday, November 02, 2004 12:07 PM
To: ietf-ediint@imc.org
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@example.org>
     [end-entity cert being exchanged]
    --foo
   Content-Type: Application/pkcs7-mime; smime-type=certs-only
   Content-ID: <ca-cert123@example.org>
     [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
 





From owner-ietf-ediint@mail.imc.org  Wed Nov  3 20:58:15 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13386
	for <ediint-archive@lists.ietf.org>; Wed, 3 Nov 2004 20:58:14 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id iA41mjit038776;
	Wed, 3 Nov 2004 17:48:45 -0800 (PST)
	(envelope-from owner-ietf-ediint@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id iA41mj9j038775;
	Wed, 3 Nov 2004 17:48:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f
Received: from drummondgroup.com (drummondgroup.com [161.58.166.198])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id iA41miWG038748
	for <ietf-ediint@imc.org>; Wed, 3 Nov 2004 17:48:45 -0800 (PST)
	(envelope-from kyle@drummondgroup.com)
Received: from KYLEDGILAPTOP (pcp517486pcs.nash01.tn.comcast.net [68.53.139.87])
	by drummondgroup.com (8.12.11/8.12.11) with ESMTP id iA41ml5b000177
	for <ietf-ediint@imc.org>; Wed, 3 Nov 2004 18:48:48 -0700 (MST)
Message-Id: <200411040148.iA41ml5b000177@drummondgroup.com>
From: "Kyle Meadors" <kyle@drummondgroup.com>
To: <ietf-ediint@imc.org>
Subject: RE: changes to CEM message structure
Date: Wed, 3 Nov 2004 19:48:45 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <EAEB90549BF1D445A923FD7C692534DBCE9581@npbexmb1.itlogon.com>
x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcTBF3NOmdTFsP3DSYmZhi8+VuxCAwAzXwyQAAqpQOA=
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iA41mjWG038770
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit


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@inovis.com] 
Sent: Wednesday, November 03, 2004 7:26 PM
To: ietf-ediint@imc.org; 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@mail.imc.org
[mailto:owner-ietf-ediint@mail.imc.org]
Sent: Tuesday, November 02, 2004 12:07 PM
To: ietf-ediint@imc.org
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@example.org>
     [end-entity cert being exchanged]
    --foo
   Content-Type: Application/pkcs7-mime; smime-type=certs-only
   Content-ID: <ca-cert123@example.org>
     [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
 




From owner-ietf-ediint@mail.imc.org  Wed Nov  3 21:30:43 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15680
	for <ediint-archive@lists.ietf.org>; Wed, 3 Nov 2004 21:30:42 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id iA42DcdZ050238;
	Wed, 3 Nov 2004 18:13:38 -0800 (PST)
	(envelope-from owner-ietf-ediint@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id iA42DcBb050237;
	Wed, 3 Nov 2004 18:13:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f
Received: from lakermmtao10.cox.net (lakermmtao10.cox.net [68.230.240.29])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id iA42Dbls050179
	for <ietf-ediint@imc.org>; Wed, 3 Nov 2004 18:13:37 -0800 (PST)
	(envelope-from sah@428cobrajet.net)
Received: from A31P ([68.100.55.187]) by lakermmtao10.cox.net
          (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP
          id <20041104021336.FDBN2581.lakermmtao10.cox.net@A31P>;
          Wed, 3 Nov 2004 21:13:36 -0500
From: "Scott Hollenbeck" <sah@428cobrajet.net>
To: "'Kyle Meadors'" <kyle@drummondgroup.com>, <ietf-ediint@imc.org>
Subject: RE: changes to CEM message structure
Date: Wed, 3 Nov 2004 21:13:35 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <200411040100.iA410Dr4085638@drummondgroup.com>
Thread-Index: AcTBpP5k4zhN3m+MQamP8Zt564ipEAAZDdmAAAInnnA=
Message-Id: <20041104021336.FDBN2581.lakermmtao10.cox.net@A31P>
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Kyle,

OK, then a different question.  Is this supposed to be working group draft?

If it is:

1. When it was first brought to my attention I expressed concern that this
document was focused on a topic that isn't part of the charter of the
working group as far as I can tell.  The IESG review you've experienced so
far is part of the concern that I and the security ADs have with the
document.  In short, we haven't yet resolved the charter/topic question to
my satisfaction.

2. The document is improperly named for it to be a working group document.
It isn't showing up in the I-D tracker as a work product of this group.
Point 1 needs to be resolved, though, before this point should be addressed.

If it isn't:

1. It should be renamed to clearly identify it as an individual submission.

Document naming guidelines are described here:

http://www.ietf.org/ietf/1id-guidelines.txt

in the section titled "Submitting".

We can talk live about the scope and the charter at the meeting next week if
anyone happens to be coming to DC.  Summaries will of course be shared here.

-Scott-

> -----Original Message-----
> From: Kyle Meadors [mailto:kyle@drummondgroup.com] 
> Sent: Wednesday, November 03, 2004 8:00 PM
> To: ietf-ediint@imc.org
> Subject: RE: changes to CEM message structure
> 
> 
> Scott,
> 
> I was referring to the draft-ediint-certificate-exchange-00 
> which I submitted last month. Russ Housley express some 
> concerns this overlapped with efforts in PKIX. Dale Moberg 
> spoke with Russ about implementing the
> pkcs7 certs-only type as the format for distributing the certificate.
> 
> Kyle Meadors
> DGI
> 
> -----Original Message-----
> From: owner-ietf-ediint@mail.imc.org 
> [mailto:owner-ietf-ediint@mail.imc.org]
> On Behalf Of Scott Hollenbeck
> Sent: Wednesday, November 03, 2004 6:48 AM
> To: 'Kyle Meadors'; ietf-ediint@imc.org
> Subject: RE: changes to CEM message structure
> 
> 
> Kyle,
> 
> Which working group document is the proposal below referring 
> to?  The only document currently under consideration by the 
> IESG is the AS2 document, and I can't find any mention of a 
> CEMRequest element in that document.
> 
> -Scott-
> 
> > -----Original Message-----
> > From: Kyle Meadors [mailto:kyle@drummondgroup.com]
> > Sent: Tuesday, November 02, 2004 3:07 PM
> > To: ietf-ediint@imc.org
> > 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@example.org>
> >      [end-entity cert being exchanged]
> >     --foo
> >    Content-Type: Application/pkcs7-mime; smime-type=certs-only
> >    Content-ID: <ca-cert123@example.org>
> >      [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
> 
> 
> ---
> 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
>  
> 
> 



From davepharoah@oracleinternet.net  Fri Nov  5 09:14:08 2004
Received: from mail.oracleinternet.net (host-83-170-55-131.customer.teleport-iabg.de [83.170.55.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14934
	for <ediint-archive@odin.ietf.org>; Fri, 5 Nov 2004 09:14:01 -0500 (EST)
Received: from localhost ([127.0.0.1])
        by mail.oracleinternet.net (Merak 7.2.0) with SMTP id JNV88343;
        Fri, 05 Nov 2004 17:42:53 +0330
Date: Fri, 05 Nov 2004 17:42:49 +0430
From: dave pharoah <davepharoah@oracleinternet.net>
Reply-To: dave_hudson2009@fastermail.com
Subject: Inherittance Claim(Please Read This,Very Urgent)
Message-ID: <fe372aa36cf120f7965543516d1ec1a2@oracleinternet.net>
X-Mailer: IceWarp Web Mail 5.2.2
X-Originating-IP: 81.199.6.5
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Dear Friend, 

              INHERITTANCE CLAIM.
May The Almighty God Give You The Wisdom To Understnd My Predicament.
I, DAVE PHAROAH OKADIGBO,The Eldest Surviving Son Of Late Dr CHUBA OKADIGBO[May His Soul Rest In Peace]Hereby Solicit For Your Help.  I Have A Bussiness Proposal For You Which I Hope By The Special Grace Of God Will Be Beneficial To You And Me.This Bussiness Proposal Is Not An Illusion But Achievable If Giving Your Maximum Support And co-operation.I Have To Assure You That This Bussiness Proposal Is Risk Free.
My Father[Dr Chuba Okadigbo]Was The Senate President Of The Federal Republic Of Nigeria And Also The All Peoples Party Vice Presidential Flagbearer Of 2003 General Election In The Country Befor he was killed by                    
this Wicked Government.On The Dying Days Of My Father,He Confessed To Me Of About $1.5m[One Million ,Five Hundrend Thousand US Dollars] Kept In A Financial
Security Company And He Directed Me To Transfer This Money To A Foreign Account Before The Government Knows Of It .My Mother And I Are Left With No Other Option Than To Invest This Money Outside The Country Where It Will Be Safe. I Hereby Propose This To You If And Only If I Can Count On You.
1]That You Take 35%Of The Money
2]I Take 55%
3]The Remaing 10% Will Be For A Joint Bussiness In
Your Country.
  Finally,What I Need From You Is Your Telephone Number And Your Contact Address For Onward Transfer Of This Fund.I Seriously Count  On Your Support And Cooperation.
   God Bless You.
   Yours Faithfully,
  DAVE  OKADIGBO PHAROAH.







From davepharoah@oracleinternet.net  Fri Nov  5 09:14:12 2004
Received: from mail.oracleinternet.net (host-83-170-55-131.customer.teleport-iabg.de [83.170.55.131])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14933
	for <ediint-archive@lists.ietf.org>; Fri, 5 Nov 2004 09:14:01 -0500 (EST)
Received: from localhost ([127.0.0.1])
        by mail.oracleinternet.net (Merak 7.2.0) with SMTP id JNV88343;
        Fri, 05 Nov 2004 17:42:53 +0330
Date: Fri, 05 Nov 2004 17:42:49 +0430
From: dave pharoah <davepharoah@oracleinternet.net>
Reply-To: dave_hudson2009@fastermail.com
Subject: Inherittance Claim(Please Read This,Very Urgent)
Message-ID: <fe372aa36cf120f7965543516d1ec1a2@oracleinternet.net>
X-Mailer: IceWarp Web Mail 5.2.2
X-Originating-IP: 81.199.6.5
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Dear Friend, 

              INHERITTANCE CLAIM.
May The Almighty God Give You The Wisdom To Understnd My Predicament.
I, DAVE PHAROAH OKADIGBO,The Eldest Surviving Son Of Late Dr CHUBA OKADIGBO[May His Soul Rest In Peace]Hereby Solicit For Your Help.  I Have A Bussiness Proposal For You Which I Hope By The Special Grace Of God Will Be Beneficial To You And Me.This Bussiness Proposal Is Not An Illusion But Achievable If Giving Your Maximum Support And co-operation.I Have To Assure You That This Bussiness Proposal Is Risk Free.
My Father[Dr Chuba Okadigbo]Was The Senate President Of The Federal Republic Of Nigeria And Also The All Peoples Party Vice Presidential Flagbearer Of 2003 General Election In The Country Befor he was killed by                    
this Wicked Government.On The Dying Days Of My Father,He Confessed To Me Of About $1.5m[One Million ,Five Hundrend Thousand US Dollars] Kept In A Financial
Security Company And He Directed Me To Transfer This Money To A Foreign Account Before The Government Knows Of It .My Mother And I Are Left With No Other Option Than To Invest This Money Outside The Country Where It Will Be Safe. I Hereby Propose This To You If And Only If I Can Count On You.
1]That You Take 35%Of The Money
2]I Take 55%
3]The Remaing 10% Will Be For A Joint Bussiness In
Your Country.
  Finally,What I Need From You Is Your Telephone Number And Your Contact Address For Onward Transfer Of This Fund.I Seriously Count  On Your Support And Cooperation.
   God Bless You.
   Yours Faithfully,
  DAVE  OKADIGBO PHAROAH.







From apache@pienpi.it  Tue Nov  9 21:48:41 2004
Received: from mail.pienpi.it ([213.199.26.129])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13626
	for <ediint-archive@lists.ietf.org>; Tue, 9 Nov 2004 21:48:39 -0500 (EST)
Received: by mail.pienpi.it (Postfix, from userid 72)
	id 74F7894B36; Tue,  9 Nov 2004 22:48:40 -0500 (EST)
Subject: RE: HELLO/RESPOND PLEASE
From: williams <williams.eg@caramail.com>
X-Priority: 3 (Normal)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: RLSP Mailer
Message-Id: <20041110034840.74F7894B36@mail.pienpi.it>
Date: Tue,  9 Nov 2004 22:48:40 -0500 (EST)
Content-Transfer-Encoding: 7bit


Please send your reply to
williams.eg@caramail.com
Alternative e.mail
williams_e20002004@yahoo.com

MR WILLIAMS M EGO
ECOBANK OF AFRICA PLC
21/14 FALOMO WAY
IKOYI/LAGOS
NIGERIA

I am  Manager in charge of bills and
exchange of Ecobank Plc, Africa. I have
urgent and very confidential business proposition for
you.

On June 6, 1998, an oil consultant/contractor
with the Nigerian Mining Corporation, Mr. Charles
Anderson made a numbered time (Fixed) Deposit for
twelve calendar months, valued at US$28,500,000.00
(Twenty- eight Million five hundred thousand Dollars)
in my branch. Upon
maturity, I sent a routine notification to his
forwarding address but got no reply. After a month,
we sent a reminder and finally we discovered from his
contract employers, the Nigerian Mining
Corporation that Mr. Charles Anderson died from an
automobile accident. On further investigation, I found
out that he died without making a WILL and all
attempts to trace his next of kin was fruitless.

I therefore made further investigation and discovered
that Mr. Charles Anderson did not declare any kin or
relations in all his official documents, including his
Bank Deposit paperwork in my Bank. This sum of
US$28,500,000.00 is still sitting in my Bank and the
interest is being rolled over with the principal sum
at the end of each year. No one will ever come
forward to claim it. According to the bank's
guidelines and regulations,
at the expiration of 5 (five) years, the money will
revert to the ownership of the bank
if nobody applies to claim the fund.
Consequently, my proposal is that I will like you to
stand in as the next of kin to Mr. Charles Anderson so
that the fruits of this old man's labor will not get
into the hands of some corrupt government officials.
This is simple, I will like you to provide immediately
your full names and address so that the Attorney will
prepare the necessary documents and affidavits which
will put you in place as the next of kin. We shall
employ the service of two Attorneys for drafting and
notarization of the WILL and to obtain the necessary
documents and letter of probate/administration in your
favor for the transfer. A bank account in any part of
the world, which you will provide, will then
facilitate
the transfer of this money to you as the
beneficiary/next of kin. The money will be paid into
your account for us to share in the ratio of 60% for
me and 30% for you. 10% will be left for expenses.

There is no risk at all as all the paperwork for this
transaction will be done by the Attorney and my
position as the manager in charge of bills and
exchange guarantees the
successful execution of this transaction. If you are
interested, please reply immediately via the private
email address below. Upon your response, I shall then
provide you with more details. .

Please observe utmost confidentiality, and rest
assured that this transaction would be most profitable
for both of us because I shall require your assistance
to invest my share in your country.

Sincerely,

MR WILLIAMS M EGO
Please send your reply to
williams.eg@caramail.com
Alternative e.mail
williamse2020@yahoo.com


___________________________________________________________________________
Questa mail č stata spedita dal sito: P&P WEBPORTAL - http://www.pienpi.it


From apache@pienpi.it  Tue Nov  9 21:48:42 2004
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13650
	for <ediint-archive@ietf.org>; Tue, 9 Nov 2004 21:48:42 -0500 (EST)
Received: from [213.199.26.129] (helo=mail.pienpi.it)
	by ietf-mx.ietf.org with esmtp (Exim 4.33)
	id 1CRiYE-0005gr-69
	for ediint-archive@ietf.org; Tue, 09 Nov 2004 21:49:39 -0500
Received: by mail.pienpi.it (Postfix, from userid 72)
	id 74F7894B36; Tue,  9 Nov 2004 22:48:40 -0500 (EST)
Subject: RE: HELLO/RESPOND PLEASE
From: williams <williams.eg@caramail.com>
X-Priority: 3 (Normal)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: RLSP Mailer
Message-Id: <20041110034840.74F7894B36@mail.pienpi.it>
Date: Tue,  9 Nov 2004 22:48:40 -0500 (EST)
X-Spam-Score: 7.2 (+++++++)
X-Spam-Flag: YES
X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48
Content-Transfer-Encoding: 7bit


Please send your reply to

williams.eg@caramail.com

Alternative e.mail

williams_e20002004@yahoo.com



MR WILLIAMS M EGO

ECOBANK OF AFRICA PLC

21/14 FALOMO WAY

IKOYI/LAGOS

NIGERIA



I am  Manager in charge of bills and

exchange of Ecobank Plc, Africa. I have

urgent and very confidential business proposition for

you.



On June 6, 1998, an oil consultant/contractor

with the Nigerian Mining Corporation, Mr. Charles

Anderson made a numbered time (Fixed) Deposit for

twelve calendar months, valued at US$28,500,000.00

(Twenty- eight Million five hundred thousand Dollars)

in my branch. Upon

maturity, I sent a routine notification to his

forwarding address but got no reply. After a month,

we sent a reminder and finally we discovered from his

contract employers, the Nigerian Mining

Corporation that Mr. Charles Anderson died from an

automobile accident. On further investigation, I found

out that he died without making a WILL and all

attempts to trace his next of kin was fruitless.



I therefore made further investigation and discovered

that Mr. Charles Anderson did not declare any kin or

relations in all his official documents, including his

Bank Deposit paperwork in my Bank. This sum of

US$28,500,000.00 is still sitting in my Bank and the

interest is being rolled over with the principal sum

at the end of each year. No one will ever come

forward to claim it. According to the bank's

guidelines and regulations,

at the expiration of 5 (five) years, the money will

revert to the ownership of the bank

if nobody applies to claim the fund.

Consequently, my proposal is that I will like you to

stand in as the next of kin to Mr. Charles Anderson so

that the fruits of this old man's labor will not get

into the hands of some corrupt government officials.

This is simple, I will like you to provide immediately

your full names and address so that the Attorney will

prepare the necessary documents and affidavits which

will put you in place as the next of kin. We shall

employ the service of two Attorneys for drafting and

notarization of the WILL and to obtain the necessary

documents and letter of probate/administration in your

favor for the transfer. A bank account in any part of

the world, which you will provide, will then

facilitate

the transfer of this money to you as the

beneficiary/next of kin. The money will be paid into

your account for us to share in the ratio of 60% for

me and 30% for you. 10% will be left for expenses.



There is no risk at all as all the paperwork for this

transaction will be done by the Attorney and my

position as the manager in charge of bills and

exchange guarantees the

successful execution of this transaction. If you are

interested, please reply immediately via the private

email address below. Upon your response, I shall then

provide you with more details. .



Please observe utmost confidentiality, and rest

assured that this transaction would be most profitable

for both of us because I shall require your assistance

to invest my share in your country.



Sincerely,



MR WILLIAMS M EGO

Please send your reply to

williams.eg@caramail.com

Alternative e.mail

williamse2020@yahoo.com



___________________________________________________________________________
Questa mail č stata spedita dal sito: P&P WEBPORTAL - http://www.pienpi.it


From apache@pienpi.it  Tue Nov  9 21:48:44 2004
Received: from mail.pienpi.it ([213.199.26.129])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13662
	for <ediint-archive@odin.ietf.org>; Tue, 9 Nov 2004 21:48:43 -0500 (EST)
Received: by mail.pienpi.it (Postfix, from userid 72)
	id 74F7894B36; Tue,  9 Nov 2004 22:48:40 -0500 (EST)
Subject: RE: HELLO/RESPOND PLEASE
From: williams <williams.eg@caramail.com>
X-Priority: 3 (Normal)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: RLSP Mailer
Message-Id: <20041110034840.74F7894B36@mail.pienpi.it>
Date: Tue,  9 Nov 2004 22:48:40 -0500 (EST)
Content-Transfer-Encoding: 7bit


Please send your reply to
williams.eg@caramail.com
Alternative e.mail
williams_e20002004@yahoo.com

MR WILLIAMS M EGO
ECOBANK OF AFRICA PLC
21/14 FALOMO WAY
IKOYI/LAGOS
NIGERIA

I am  Manager in charge of bills and
exchange of Ecobank Plc, Africa. I have
urgent and very confidential business proposition for
you.

On June 6, 1998, an oil consultant/contractor
with the Nigerian Mining Corporation, Mr. Charles
Anderson made a numbered time (Fixed) Deposit for
twelve calendar months, valued at US$28,500,000.00
(Twenty- eight Million five hundred thousand Dollars)
in my branch. Upon
maturity, I sent a routine notification to his
forwarding address but got no reply. After a month,
we sent a reminder and finally we discovered from his
contract employers, the Nigerian Mining
Corporation that Mr. Charles Anderson died from an
automobile accident. On further investigation, I found
out that he died without making a WILL and all
attempts to trace his next of kin was fruitless.

I therefore made further investigation and discovered
that Mr. Charles Anderson did not declare any kin or
relations in all his official documents, including his
Bank Deposit paperwork in my Bank. This sum of
US$28,500,000.00 is still sitting in my Bank and the
interest is being rolled over with the principal sum
at the end of each year. No one will ever come
forward to claim it. According to the bank's
guidelines and regulations,
at the expiration of 5 (five) years, the money will
revert to the ownership of the bank
if nobody applies to claim the fund.
Consequently, my proposal is that I will like you to
stand in as the next of kin to Mr. Charles Anderson so
that the fruits of this old man's labor will not get
into the hands of some corrupt government officials.
This is simple, I will like you to provide immediately
your full names and address so that the Attorney will
prepare the necessary documents and affidavits which
will put you in place as the next of kin. We shall
employ the service of two Attorneys for drafting and
notarization of the WILL and to obtain the necessary
documents and letter of probate/administration in your
favor for the transfer. A bank account in any part of
the world, which you will provide, will then
facilitate
the transfer of this money to you as the
beneficiary/next of kin. The money will be paid into
your account for us to share in the ratio of 60% for
me and 30% for you. 10% will be left for expenses.

There is no risk at all as all the paperwork for this
transaction will be done by the Attorney and my
position as the manager in charge of bills and
exchange guarantees the
successful execution of this transaction. If you are
interested, please reply immediately via the private
email address below. Upon your response, I shall then
provide you with more details. .

Please observe utmost confidentiality, and rest
assured that this transaction would be most profitable
for both of us because I shall require your assistance
to invest my share in your country.

Sincerely,

MR WILLIAMS M EGO
Please send your reply to
williams.eg@caramail.com
Alternative e.mail
williamse2020@yahoo.com


___________________________________________________________________________
Questa mail č stata spedita dal sito: P&P WEBPORTAL - http://www.pienpi.it


From BruceOwens_bounce@mymailgenie.com  Sat Nov 13 01:15:16 2004
Received: from gr3.Georapid.com (gr3.georapid.com [216.198.244.42])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03309
	for <ediint-archive@odin.ietf.org>; Sat, 13 Nov 2004 01:15:14 -0500 (EST)
Received: from gr3 ([216.198.244.45]) by gr3.Georapid.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Sat, 13 Nov 2004 00:38:00 -0600
From: <bruceowens@accountant.com>
To: ediint-archive@ietf.org
Subject: Information for you!
Date: Sat, 13 Nov 2004 00:37:55 -0600
Message-ID: <20041113-00375589-1418-0@gr3>
X-GEO-REPORTID: 9157
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="--=3F944FB4BFCF433BA912_EEC2_AAA5_CE0D"
X-OriginalArrivalTime: 13 Nov 2004 06:38:00.0578 (UTC) FILETIME=[51D3C620:01C4C94B]

----=3F944FB4BFCF433BA912_EEC2_AAA5_CE0D
Content-Type: text/html;charset="iso-8859-1"
Content-Transfer-Encoding: Quoted-Printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml"
xmlns:o=3D"urn:schemas-microsoft-com:office:office"
xmlns:w=3D"urn:schemas-microsoft-com:office:word"
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows=
-1252">
<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"inform_files/filelist.xml">
<link rel=3DEdit-Time-Data href=3D"inform_files/editdata.mso">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Information</title>
<!--[if gte mso 9]><xml>
 <o:DocumentProperties>
  <o:Author>system</o:Author>
  <o:Template>Normal</o:Template>
  <o:LastAuthor>Giganet</o:LastAuthor>
  <o:Revision>2</o:Revision>
  <o:TotalTime>24</o:TotalTime>
  <o:Created>2004-11-12T11:31:00Z</o:Created>
  <o:LastSaved>2004-11-12T11:31:00Z</o:LastSaved>
  <o:Pages>1</o:Pages>
  <o:Words>406</o:Words>
  <o:Characters>2319</o:Characters>
  <o:Company>obe and nkem</o:Company>
  <o:Lines>19</o:Lines>
  <o:Paragraphs>5</o:Paragraphs>
  <o:CharactersWithSpaces>2720</o:CharactersWithSpaces>
  <o:Version>10.2625</o:Version>
 </o:DocumentProperties>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DoNotShowRevisions/>
  <w:DoNotPrintRevisions/>
  <w:DoNotShowMarkup/>
  <w:DoNotHyphenateCaps/>
  <w:PunctuationKerning/>
  <w:DrawingGridHorizontalSpacing>6 pt</w:DrawingGridHorizontalSpacing>=

  <w:DrawingGridVerticalSpacing>6 pt</w:DrawingGridVerticalSpacing>
  <w:DisplayHorizontalDrawingGridEvery>0</w:DisplayHorizontalDrawingGri=
dEvery>
  <w:DisplayVerticalDrawingGridEvery>3</w:DisplayVerticalDrawingGridEve=
ry>
  <w:UseMarginsForDrawingGridOrigin/>
  <w:DoNotShadeFormData/>
  <w:Compatibility>
   <w:FootnoteLayoutLikeWW8/>
   <w:ShapeLayoutLikeWW8/>
   <w:AlignTablesRowByRow/>
   <w:ForgetLastTabAlignment/>
   <w:LayoutRawTableWidth/>
   <w:LayoutTableRowsApart/>
   <w:UseWord97LineBreakingRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
h1
	{mso-style-next:Normal;
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:1;
	font-size:9.5pt;
	font-family:"Times New Roman";
	mso-font-kerning:0pt;}
h2
	{mso-style-next:Normal;
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:2;
	font-size:9.0pt;
	font-family:Arial;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
 /* Page Definitions */
 @page
	{mso-page-border-surround-header:no;
	mso-page-border-surround-footer:no;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.5in 27.0pt 49.5pt .5in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]--><!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"2050"/>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1"/>
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3D"#CCFFFF" lang=3DEN-US style=3D'tab-interval:.5in;text-=
justify-trim:
punctuation'>

<div class=3DSection1>

<p class=3DMsoNormal style=3D'margin-top:5.0pt;margin-right:0in;margin-=
bottom:5.0pt;
margin-left:0in;mso-pagination:none;mso-layout-grid-align:none;text-aut=
ospace:
none'><!--[if gte vml 1]><v:shapetype id=3D"_x0000_t75" coordsize=3D"21=
600,21600"
 o:spt=3D"75" o:preferrelative=3D"t" path=3D"m@4@5l@4@11@9@11@9@5xe" fi=
lled=3D"f"
 stroked=3D"f">
 <v:stroke joinstyle=3D"miter"/>
 <v:formulas>
  <v:f eqn=3D"if lineDrawn pixelLineWidth 0"/>
  <v:f eqn=3D"sum @0 1 0"/>
  <v:f eqn=3D"sum 0 0 @1"/>
  <v:f eqn=3D"prod @2 1 2"/>
  <v:f eqn=3D"prod @3 21600 pixelWidth"/>
  <v:f eqn=3D"prod @3 21600 pixelHeight"/>
  <v:f eqn=3D"sum @0 0 1"/>
  <v:f eqn=3D"prod @6 1 2"/>
  <v:f eqn=3D"prod @7 21600 pixelWidth"/>
  <v:f eqn=3D"sum @8 21600 0"/>
  <v:f eqn=3D"prod @7 21600 pixelHeight"/>
  <v:f eqn=3D"sum @10 21600 0"/>
 </v:formulas>
 <v:path o:extrusionok=3D"f" gradientshapeok=3D"t" o:connecttype=3D"rec=
t"/>
 <o:lock v:ext=3D"edit" aspectratio=3D"t"/>
</v:shapetype><v:shape id=3D"_x0000_s1026" type=3D"#_x0000_t75" style=3D=
'position:absolute;
 margin-left:0;margin-top:-61.3pt;width:246pt;height:60pt;z-index:-3;
 mso-position-horizontal:left' wrapcoords=3D"-68 0 -68 21282 21600 2128=
2 21600 0 -68 0">
 <v:imagedata src=3D"inform_files/image001.png" o:title=3D""/>
 <w:wrap type=3D"square"/>
</v:shape><![endif]--><![if !vml]><img width=3D328 height=3D80
src=3D"inform_files/image002.jpg" align=3Dleft hspace=3D12 v:shapes=3D"=
_x0000_s1026"><![endif]><!--[if gte vml 1]><v:shape
 id=3D"_x0000_s1027" type=3D"#_x0000_t75" alt=3D"" style=3D'position:ab=
solute;
 margin-left:0;margin-top:-61.3pt;width:264pt;height:60pt;z-index:3;
 mso-wrap-edited:f;mso-position-horizontal:left' wrapcoords=3D"-69 0 -6=
9 21388 21600 21388 21600 0 -69 0">
 <v:imagedata src=3D"inform_files/image003.jpg" o:href=3D"http://www.li=
ttlewoodscasino.com/images/head_1.jpg"/>
 <w:wrap type=3D"square"/>
</v:shape><![endif]--><![if !vml]><img width=3D352 height=3D80
src=3D"inform_files/image004.jpg" align=3Dleft hspace=3D12 v:shapes=3D"=
_x0000_s1027"><![endif]><b><span
style=3D'font-size:9.0pt;font-family:Arial'>WILLIAM HILL LOTTO, No. 1 S=
tation
Avenue, Dublin Road, <span class=3DSpellE>Athlone</span>, Co. Westmeath=
, Ireland</span></b><span
style=3D'font-size:9.0pt;font-family:Arial'> <o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-top:5.0pt;margin-right:0in;margin-=
bottom:5.0pt;
margin-left:0in;mso-pagination:none;mso-layout-grid-align:none;text-aut=
ospace:
none'><b><span style=3D'font-size:11.0pt;font-family:Arial'>FROM: THE D=
ESK OF THE
VICE PRESIDENT<br>
INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPT<br>
REF NO: WHC/2666801029/03<br>
BATCH NO: 16/0017/PAD<o:p></o:p></span></b></p>

<p class=3DMsoNormal style=3D'margin-top:5.0pt;margin-right:0in;margin-=
bottom:5.0pt;
margin-left:0in;mso-pagination:none;mso-layout-grid-align:none;text-aut=
ospace:
none'><b><span style=3D'font-size:11.0pt;font-family:Arial'>ATTN: STICK=
 WINNER.<o:p></o:p></span></b></p>

<p class=3DMsoNormal align=3Dcenter style=3D'margin-top:5.0pt;margin-ri=
ght:0in;
margin-bottom:5.0pt;margin-left:0in;text-align:center;mso-pagination:no=
ne;
mso-layout-grid-align:none;text-autospace:none'><b><u><span style=3D'fo=
nt-family:
Arial'>RE: AWARD NOTIFICATION, FINAL NOTICE.</span></u></b><b><span
style=3D'font-family:Arial'><o:p></o:p></span></b></p>

<p class=3DMsoNormal style=3D'margin-top:5.0pt;margin-right:0in;margin-=
bottom:5.0pt;
margin-left:0in;text-align:justify;mso-pagination:none;mso-layout-grid-=
align:
none;text-autospace:none'><span style=3D'font-size:11.0pt;font-family:A=
rial'>We
are pleased to inform you of the release today of the results of the WI=
LLIAM
HILL SWEEPSTAKE LOTTERY/END OF YEAR HIGHSTAKE INTERNATIONAL PROGRAM hel=
d on 10th
of November 2004. <o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-top:5.0pt;margin-right:0in;margin-=
bottom:5.0pt;
margin-left:0in;text-align:justify;mso-pagination:none;mso-layout-grid-=
align:
none;text-autospace:none'><span style=3D'font-size:11.0pt;font-family:A=
rial'>Your
name attached to the ticket number 5 - 12 - 26 - 29 - 36 - 49 - 56 - 89=
 with
serial number 2115 - 05 drew the lucky numbers 7 - 9 - 14 - 16 - 29 - 3=
3 which
consequently won the lottery in the 3rd category. <o:p></o:p></span></p=
>

<p class=3DMsoNormal style=3D'margin-top:5.0pt;margin-right:0in;margin-=
bottom:5.0pt;
margin-left:0in;text-align:justify;mso-pagination:none;mso-layout-grid-=
align:
none;text-autospace:none'><span style=3D'font-size:11.0pt;font-family:A=
rial'>You
have therefore been approved for a lump sum payout of =A3666,810.00 in =
cash
credited to file REF.NO: WHC/2666801029/03. This is from a total cash p=
rize of
=A311,335,770.00 POUNDS shared among the 17 international winners in th=
is
category.<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-top:5.0pt;margin-right:0in;margin-=
bottom:5.0pt;
margin-left:0in;text-align:justify;mso-pagination:none;mso-layout-grid-=
align:
none;text-autospace:none'><span style=3D'font-size:11.0pt;font-family:A=
rial'>CONGRATULATIONS!<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-top:5.0pt;margin-right:0in;margin-=
bottom:5.0pt;
margin-left:0in;text-align:justify;mso-pagination:none;mso-layout-grid-=
align:
none;text-autospace:none'><span style=3D'font-size:11.0pt;font-family:A=
rial'>Your
fund is now deposited with a security company insured in your name. Due=
 to the
mix up of some numbers and names, we ask that you keep this award from =
public
notice until your claim has been processed and your money remitted to y=
our
nominated account, as this is a part of our security protocol to avoid =
double
claiming or unwarranted taking advantage of this program by participant=
s. All
participants were selected through a computer ballot system drawn from =
25,000
names from USA, New Zealand, Europe, Africa, Pacific and Asia as part o=
f our
end of year international program, which we conduct once every year. We=
 hope
with a part of your prize money, you will take part in our mid year (su=
mmer)
high stake =A3 1.6 billion pounds international lottery.<o:p></o:p></sp=
an></p>

<p class=3DMsoNormal style=3D'margin-top:5.0pt;margin-right:0in;margin-=
bottom:5.0pt;
margin-left:0in;text-align:justify;mso-pagination:none;mso-layout-grid-=
align:
none;text-autospace:none'><span style=3D'font-size:11.0pt;font-family:A=
rial'>To
begin your claim, please contact your claims agent, <b>MR. FOREST ANDER=
SON,
Foreign Operations Manager, PIONEER SECURITY AND DEPOSIT COMPANY, UK ON=
 Fax No:
=2B44 709 2840872 or E-mail: pioneerdeposit@netscape.net </b>by providi=
ng your
winning details, contact information including your phone and fax numbe=
rs for
processing and remittance of your prize money to a designated account o=
f your
choice. Remember, all prize money must be claimed not later than Novemb=
er 30th
2004. After this date all funds will be returned to the WILLIAM HILL EC=
ONOMICAL
RESERVES as unclaimed.<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-top:5.0pt;margin-right:0in;margin-=
bottom:5.0pt;
margin-left:0in;text-align:justify;mso-pagination:none;mso-layout-grid-=
align:
none;text-autospace:none'><span style=3D'font-size:11.0pt;font-family:A=
rial'>NOTE:
In order to avoid unnecessary delays and complications, please remember=
 to
quote your reference and batch numbers in every of your correspondence =
with us
or your agent Furthermore, should there be any change of your address, =
do
inform your claims agent as soon as possible. Congratulations again fro=
m all
members of our staff and thank you for being a part of our promotion pr=
ogram.<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-top:5.0pt;margin-right:0in;margin-=
bottom:5.0pt;
margin-left:0in;text-align:justify;mso-pagination:none;mso-layout-grid-=
align:
none;text-autospace:none'><span style=3D'font-size:11.0pt;font-family:A=
rial'>Sincerely,</span><!--[if gte vml 1]><v:shape
 id=3D"_x0000_s1028" type=3D"#_x0000_t75" alt=3D"" style=3D'position:ab=
solute;left:0;
 text-align:left;margin-left:379.05pt;margin-top:2.95pt;width:2in;heigh=
t:82.95pt;
 z-index:2;mso-position-horizontal-relative:text;
 mso-position-vertical-relative:text'>
 <v:imagedata src=3D"inform_files/image005.jpg" o:href=3D"http://www.el=
gordo.com/new/ishop/021222.jpg"/>
</v:shape><![endif]--><![if !vml]><span style=3D'mso-ignore:vglayout;po=
sition:
absolute;z-index:2;left:0px;margin-left:505px;margin-top:4px;width:192p=
x;
height:111px'><img width=3D192 height=3D111 src=3D"inform_files/image00=
6.jpg" v:shapes=3D"_x0000_s1028"></span><![endif]><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'mso-pagination:none;mso-layout-grid-align=
:none;
text-autospace:none'><!--[if gte vml 1]><v:shape id=3D"_x0000_i1025" ty=
pe=3D"#_x0000_t75"
 style=3D'width:143.25pt;height:33.75pt;mso-wrap-edited:f' wrapcoords=3D=
"-104 0 -104 21600 21600 21600 21600 0 -104 0"
 o:allowoverlap=3D"f">
 <v:imagedata src=3D"inform_files/image007.wmz" o:title=3D""/>
</v:shape><![endif]--><![if !vml]><img width=3D191 height=3D45
src=3D"inform_files/image008.gif" v:shapes=3D"_x0000_i1025"><![endif]><=
span
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></p>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:Ari=
al'>MRS
SILVIA DUKE.<span style=3D'mso-spacerun:yes'>=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 </span><o:p></o:p></span></b=
></p>

<h1><span class=3DGramE><span style=3D'font-size:10.0pt'>VICE PRESIDENT=
.</span></span><span
style=3D'font-size:10.0pt'><o:p></o:p></span></h1>

<h2><span style=3D'font-size:10.0pt'>WILLIAM HILL LOTTO.<o:p></o:p></sp=
an></h2>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal style=3D'mso-pagination:none;mso-layout-grid-align=
:none;
text-autospace:none'><span style=3D'font-size:10.0pt;font-family:Arial'=
><o:p>&nbsp;</o:p></span></p>

</div>

<p align=3Dcenter><font face=3Darial size=3D1><br><p align=3D"left"><fo=
nt size=3D"1"> <font face=3D"Verdana, Arial, Helvetica, sans-serif">Thi=
s=20
  email was sent to ediint-archive@odin.ietf.org.  </font><font size=3D=
"1"><font face=3D"Verdana, Arial, Helvetica, sans-serif"><a href=3D"htt=
p://myMailGenie.com/v3/editprofile.aspx?cclientid=3D1497&cemailid=3Dedi=
int-archive@odin.ietf.org">Edit=20
  your profile</a></font></font><font face=3D"Verdana, Arial, Helvetica=
, sans-serif"><br>
  <br>
     ::<a href=3D"http://myMailGenie.com/v3/unsubscribe.aspx?email_id=3D=
ediint-archive@odin.ietf.org&client_id=3D1497">Unsubscribe</a>::   ::<a=
 href=3D"http://myMailGenie.com/v3/tell_friend.aspx?from_email=3Dediint=
-archive@odin.ietf.org&client_id=3D1497&signOff_id=3Dbruceowens@account=
ant.com&campaign_id=3D5723&datesent=3D11/13/2004&rep_id=3D9157&affiliat=
ename=3DmyMailGenie.com">Forward=20
  to a friend</a>::   ::<a href=3D"#">Privacy Policy</a>:: <br>
  <br>
  BruceOwens<br>34 Allen Avenue<br>Ikeja<br>Rhode Island - 25541<br>US<=
br>Contact No.7187745300<br>
  <br>
  </font> <b><font face=3D"Verdana, Arial, Helvetica, sans-serif">Power=
ed by  <a target=3D_blank href=3D"http://myMailGenie.com">myMailGenie.c=
om</a>
  </font></b> </font> </p></font></p><img src=3D'http://www.mymailgenie=
.com/v3/count_mailopened.aspx?client_id=3D1497&email_id=3Dediint-archiv=
e@odin.ietf.org&date_sent=3D11-13-2004&campaign_id=3D5723&rep_id=3D9157=
' width=3D1 height=3D1></body></html>

----=3F944FB4BFCF433BA912_EEC2_AAA5_CE0D--


From nobody@pluto.hostsurreal.com  Mon Nov 15 16:46:35 2004
Received: from pluto.hostsurreal.com (228.67-18-27.reverse.theplanet.com [67.18.27.228] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14113
	for <ediint-archive@odin.ietf.org>; Mon, 15 Nov 2004 16:46:33 -0500 (EST)
Received: from nobody by pluto.hostsurreal.com with local (Exim 4.43)
	id 1CTo1H-0008MY-6e; Mon, 15 Nov 2004 15:04:15 -0600
Subject: GOOD DAY
From: liucha <liucha@telkom.net>
X-Priority: 3 (Normal)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: RLSP Mailer
Message-Id: <E1CTo1H-0008MY-6e@pluto.hostsurreal.com>
Date: Mon, 15 Nov 2004 15:04:15 -0600
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - pluto.hostsurreal.com
X-AntiAbuse: Original Domain - odin.ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12]
X-AntiAbuse: Sender Address Domain - pluto.hostsurreal.com
Content-Transfer-Encoding: 7bit


Dear Sir/Madam,
               We are group of  business men who deal on raw materials and export into america\ canada  and europe.
We are searching for representatives who can help us establish a medium of getting to our costumers in the america /canada and europe as well as making payments through you to us.
Please if you are interested in transacting business with us we will be very glad,
Please contact us for more information.
Subject to your satisfaction you will be given the opportunity to negotiate your mode of which we will pay for your services as our representative in america/europe.
Please if you are interested forward to us your phone number and your full contact addresses to this company.
Thanks,
Vice President
Mr liu Cha

___________________________________________________________________________
Mail sent from WebMail service at PHP-Nuke Powered Site berigsbridge.comr
- http://berigsbridge.com


From owner-ietf-ediint@mail.imc.org  Mon Nov 22 13:22:23 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29243
	for <ediint-archive@lists.ietf.org>; Mon, 22 Nov 2004 13:22:22 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id iAMHwkx0052118;
	Mon, 22 Nov 2004 09:58:46 -0800 (PST)
	(envelope-from owner-ietf-ediint@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id iAMHwkdn052117;
	Mon, 22 Nov 2004 09:58:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f
Received: from atlrelay1.inovisinc.com (atlrelay1.inovisinc.com [206.113.209.242])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id iAMHwagO051919
	for <ietf-ediint@imc.org>; Mon, 22 Nov 2004 09:58:40 -0800 (PST)
	(envelope-from richard.bigelow@inovis.com)
Received: from alfexfe1.itlogon.com (atlrelay1.itlogon.com [127.0.0.1])
	by atlrelay1.inovisinc.com (8.11.6/8.11.6) with ESMTP id iAMHXdS26479;
	Mon, 22 Nov 2004 12:33:39 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: RE: Certificate Exchange - Use Cases
Date: Mon, 22 Nov 2004 12:59:29 -0500
Message-ID: <EAEB90549BF1D445A923FD7C692534DBCE95E6@npbexmb1.itlogon.com>
Thread-Topic: Certificate Exchange - Use Cases
Thread-Index: AcS2DZHhg3JUGuvDQ8CwKFJn8Z4QowNdaSFQ
From: "Richard Bigelow" <richard.bigelow@inovis.com>
To: "IETF EDIINT WG \(E-mail\)" <ietf-ediint@imc.org>
Cc: "Kyle Meadors \(E-mail\)" <kyle@drummondgroup.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id iAMHwfgO052095
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 8bit


Comment on draft-ediint-certificate-exchange-00.txt.

In part 2 of a comment submitted 10/19/2004, I interpreted these statements in 4.2.1 and 4.2.2 to mean that the receiver of a request or response message must accept the message if it is signed even if the receiver cannot validate the signing certifiate.
4.2.1 says
	If the receiver supports this use case, they MUST accept this message 
	regardless of the presence of a signature. 
and 4.2.2 says
	The initiator MUST accept this response, regardless of if it is signed.  

This puts a burden on the message receiver, and requires changes in the signature validation.  I now think that the burden should be on the message sender.  The sender should not sign a message if the sender knows that the receiver does not possess the signing certificate.  This can be implemented manually or with a simple status.  The sender can keep track of whether it has sent a signing certificate to each partneer and received an acceptance from that partner.  If not, don't sign the CEM message.  Senders may already keep track of which signing certificate each partner has accepted, so the sender knows whether to use the old or new certificate when switching.  Such senders just need a NO_CERTIFICATE value.  Senders who switch based solely on the RespondByDate will need a new status per partner, or could use manual or other means.

So I now propose to replace part 2 of my 10/19/2004 comment with the following:


4.2.1 says
	If the receiver supports this use case, they MUST accept this message 
	regardless of the presence of a signature. 
and 4.2.2 says
	The initiator MUST accept this response, regardless of if it is signed.  

I interpret these requirements to mean that the receiver of a Request/Response message must accept a signed message, even if the receiver cannot validate the signing certificate.  This puts a burden on the receiver, and requires the receiver to handle these messages in a special way during S/MIME processing.  It is better to put the burden on the sender, and require that senders do not sign messages if they know the receiver does not possess the sender's signing certificate.  This requirement should be stated in section 2.3.  

In the first paragraph of section 2.3, after this sentence

   After obtaining the desired certificate, the initiator of the 
   certificate exchange transmits the certificate in the CEM Request 
   message. 

insert
   If the initiator does not possess the receiver's signature 
   certificate, the initiator SHOULD NOT request a signed MDN. 

After the second paragraph of 2.3 insert

If the initiator does not have an established signing certificate 
for use with this partner, the initiator MUST NOT sign the CEM Request.  

A message sender has established a signing certificate for use 
with a receiver if the sender has previously sent the certificate 
to the receiver by some means and the receiver has indicated acceptance 
of that certificate.  For example, the certificate was sent in a 
previous CEM Request and either the receiver accepted it in a response 
or the RespondByDate of that request has passed.  There may be other 
means of establishing a signing certificate, including manual means.

--------end insert

The recipient might sign the Request's MDN or the Response, and the initiator may not yet possess any signing certificate of the recipient.  (Note that the AS2 specification permits the recipient to sign the MDN even if the initiator did not request a signed MDN.)  So the same requirements apply to the recipient when sending the Response message.  Add to the end of 2.3:


If the recipient does not have an established signing certificate for 
use with the initiator, then 1. the recipient MUST NOT sign the CEM Response,
and 2. if the initiator did not request a signed MDN, 
the recipient MUST NOT sign the MDN for the Request.  


Sections 4.2.1 and 4.2.2 should be modified as follows.  MUST and SHOULD are replaced by other words, and the requirements for sending signed messages are modified in accordance with the language above.

   4.2.1.  Step 1 
    
   Initiator creates an EDIINTCertificateExchangeRequest as described in 
   Section 2.0 Message Format and Section 3.0 XML Schema.  The initiator 
   sends it according to EDIINT-AS2 protocol.  The message is not signed,
   because the initiator does not have an established signing certificate
   for this partner.  Because the initiator does not
   possess the receiver's encryption certificate, encryption is not
   used.  Because the initiator does not possess the receiver's signature 
   certificate, the initiator does not request a signed MDN.  If the MDN is 
   not signed, there is no legal proof the receiver received the message.  
   The receiver accepts this message in accordance with AS2 protocol.  
   In addition, a positive MDN received during this step gives some 
   indication of successful transmission of the message, but does not 
   imply successful action on the certificate.  In the case of an 
   encryption certificate, the initiator must be immediately ready to 
   receive documents encrypted with the new certificate.  In the case of 
   a signing certificate, the initiator can begin signing documents with 
   the new certificate at the RespondByDate or upon receipt of an 
   EDIINTCertificateExchangeResponse from the partner indicating they 
   are ready. If an acceptance response is not received by the 
   RespondByDate, the initiator may or may not begin signing with the 
   new certificate, depending on the implementation's capabilities and 
   the policies of the initiator. 
    
   4.2.2.   Step 2 
    
   Receiver validates the EDIINTCertificateExchangeRequest message at 
   the AS2 level and returns an MDN according to the EDIINT-AS2 
   protocol.  Because the initiator did not request a signed MDN, and also
   because the receiver does not have an established signing certificate
   for the initiator, the MDN
   is not signed.  If the message is a proper AS2 document, the receiver 
   automatically accepts or rejects the new certificate(s), or requires 
   manual intervention.  Caution should be used in automatically 
   accepting the certificate, as it may be impossible to verify the 
   sender is authentic.  If the certificate is automatically accepted or 
   rejected, an EDIINTCertificateExchangeResponse is generated and 
   returned to the initiator.  Since the trading relationship could be 
   hindered if action is not taken prior to the RespondByDate, manual 
   intervention must be done before that date. When the manual 
   intervention determines to accept or reject the certificate, an 
   EDIINTCertificateExchangeResponse is generated and returned to 
   the initiator.  
    
   In both the automatic and manual case, the 
   EDIINTCertificateExchangeResponses are formatted according to 
   Section 2. Message Processing and Section 3. XML Schema Description 
   and sent according to EDIINT-AS2 protocol.  If the original CEM Request
   included the encryption certificate, or if the receiver has the 
   initiator encryption certificate on file, it may be used to encrypt 
   the AS2 message including the EDIINTCertificateExchangeResponse.  
   Otherwise, it may be necessary to send this 
   EDIINTCertificateExchangeResponse unencrypted.  The message is not 
   signed, because the receiver does not have an established signing
   certificate for the initiator.  
   The initiator accepts this response in accordance with AS2 protocol.
   A positive MDN received for the response message 
   indicates successful transmission of the response message. 

   After the receiver accepts the certificate and returns an acceptance 
   response, the receiver may encrypt messages to the initiator with the 
   encryption certificate.  The receiver begins to accept messages from 
   the initiator that are signed with the signing certificate.  The 
   initiator may start signing with the certificate when it receives the 
   acceptance response, or when it receives acceptance responses from 
   all its partners, or after the RespondByDate. 
    


-----Original Message-----
From: owner-ietf-ediint@mail.imc.org
[mailto:owner-ietf-ediint@mail.imc.org]
Sent: Tuesday, October 19, 2004 11:58 AM
To: IETF EDIINT WG (E-mail)
Subject: Certificate Exchange - Use Cases



Comment on draft-ediint-certificate-exchange-00.txt.

I have 2 comments on section 4.

1. The beginning of section 4 says that it is "only illustrative".  However, section 4 contains several uses of MUST and SHOULD, which are prescriptive words.  These words should be in lower case, to indicate that they are not stating additional requirements, or different language should be used.
2. Section 4.2 does state some requirements that were not stated earlier in section 2 or 3.  These requirements should be in section 2.  The requirements in 4.2 on accepting signed messages should be modified.

1.
In 4.1.1 Step 1, change
   In the case of an encryption certificate, the initiator MUST be 
   immediately ready to receive documents encrypted with the new 
   certificate. 
to
   In the case of an encryption certificate, the initiator is
   immediately ready to receive documents encrypted with the new 
   certificate. 

Change the first paragraph of 4.1.2 to
   Receiver validates the EDIINTCertificateExchangeRequest message at 
   the AS2 level and returns a correct MDN.  If the message is a proper 
   AS2 document, the receiver automatically accepts or rejects the 
   new certificate(s) or requires manual intervention. If the certificate 
   is automatically accepted or rejected, an 
   EDIINTCertificateExchangeResponse is generated and returned to 
   the initiator.  Since the trading relationship could be hindered if 
   action is not taken prior to the RespondByDate, manual intervention 
   must be done before that date. When the manual intervention 
   determines to accept or reject the new certificate, an 
   EDIINTCertificateExchangeResponse is generated and returned to 
   the initiator. Both automatic and manual 
   EDIINTCertificateExchangeResponses are formatted according to 
   Section 2. Message Processing and Section 3. XML Schema Description 
   and sent according to EDIINT-AS2 protocol.  A positive MDN received 
   for the response message indicates successful transmission of the 
   response message. 

2.
4.2.1 says
	If the receiver supports this use case, they MUST accept this message 
	regardless of the presence of a signature. 
and 4.2.2 says
	The initiator MUST accept this response, regardless of if it is signed.  

I interpret these requirements to mean that the receiver of a Request/Response message must accept a signed message, even if the receiver cannot validate the signing certificate.  This requirement should be stated in section 2.3.  

In the first paragraph of section 2.3, after this sentence

   After obtaining the desired certificate, the initiator of the 
   certificate exchange transmits the certificate in the CEM Request 
   message. 

insert
   If the initiator does not possess the receiver's signature 
   certificate, the initiator SHOULD NOT request a signed MDN. 

Change the first sentence of paragraph 3 of section 2.3 from

   Upon receipt of the CEM Request, the recipient trading partner 
   processes the transport message as normal and returns the MDN. 
to

   Upon receipt of the CEM Request, the recipient trading partner 
   processes the transport message as described below and returns the MDN. 

Add the following to the end of 2.3:

	If the initiator signs the CEM Request, the initiator SHOULD include the signing certificate in the signature.  If the recipient partner receives a signed CEM Request, but the recipient does not possess a currently valid signing certificate for the initiator, then the recipient partner may ignore the signature without processing it in any way, return a positive MDN if one is requested, and go on to process the Request.  However, it is RECOMMENDED that the recipient partner process the signature as much as possible, to detect possible corruption of the Request message, as follows.  If the signing certificate is in the signature, or if the recipient possesses the signing certificate, the recipient SHOULD verify that the digest of the message equals the digest in the signature.  If the signing certificate is issued by a CA Certificate that the recipient trusts, the recipient SHOULD verify that the issuer did issue the signing certificate.  If either of these checks is done and!
  fails, the recipient MUST return a negative MDN.  If the recipient does not trust the signing certificate because the signing certificate or one of its issuers has been revoked or has expired or is explicitly not trusted, the recipient SHOULD return a negative MDN.  If the recipient already trusts the signing certificate or one of its issuers and all other tests pass, then the recipient MUST return a positive MDN.  If the recipient has no basis to either trust or not trust the signing certificate, then the recipient MUST return a positive MDN.  (This is contrary to the behavior for non-CEM messages, where the recipient returns a negative MDN if it cannot validate the trust of the signing certificate.)  In this case, the recipient SHOULD require manual intervention to accept the certificates in the Request.

The recipient returns a positive MDN even when it cannot validate trust of the signing certificate because this CEM Request may be the initial distribution of the signing certificate.  The recipient might not yet possess any certificates of the initiator or have any means to validate the signing certificate.  After the initial distribution, the initiator will normally sign the CEM Request with the existing signing certificate, which the recipient can validate.

The burden for the initial distribution is placed on the recipient, as in section 4.2.  The initiator can always send CEM Requests in the same way.

The recipient might sign the Request's MDN or the Response, and the initiator may not yet possess any signing certificate of the recipient.  (Note that the AS2 specification permits the recipient to sign the MDN even if the initiator did not request a signed MDN.)  So the same requirements apply to the initiator when processing the MDN or Response message.  Add to the end of 2.3, after the paragraph above:

	If the recipient signs the MDN for the CEM Request, the recipient SHOULD include the signing certificate in the signature.  If the initiator receives a signed MDN for the CEM Request, but the initiator does not possess a currently valid signing certificate for the recipient, then the initiator may ignore the signature without processing it in any way, and accept the MDN.  However, it is RECOMMENDED that the initiator process the signature as much as possible, to detect possible corruption of the MDN message, as follows.  If the signing certificate is in the signature, or if the initiator possesses the signing certificate, the initiator SHOULD verify that the digest of the message equals the digest in the signature.  If the signing certificate is issued by a CA Certificate that the initiator trusts, the initiator SHOULD verify that the issuer did issue the signing certificate.  If either of these checks is done and fails, the initiator MUST reject the MDN.  If the initiator !
 does not trust the signing certificate because the signing certificate or one of its issuers has been revoked or has expired or is explicitly not trusted, the initiator SHOULD reject the MDN.  The behavior when the initiator rejects the MDN is not defined.  If the initiator already trusts the signing certificate or one of its issuers and all other tests pass, then the initiator MUST accept the MDN.  If the initiator has no basis to either trust or not trust the signing certificate, then the initiator MUST accept the MDN.  (This is contrary to the behavior for non-CEM messages, where the initiator rejects a MDN if it cannot validate the trust of the signing certificate.)  

	If the recipient signs the CEM Response, the recipient SHOULD include the signing certificate in the signature.  If the initiator receives a signed CEM Response, but the initiator does not possess a currently valid signing certificate for the recipient, then the initiator may ignore the signature without processing it in any way, return a positive MDN if one is requested, and go on to process the Response.  However, it is RECOMMENDED that the initiator process the signature as much as possible, to detect possible corruption of the Response message, as follows.  If the signing certificate is in the signature, or if the initiator possesses the signing certificate, the initiator SHOULD verify that the digest of the message equals the digest in the signature.  If the signing certificate is issued by a CA Certificate that the initiator trusts, the initiator SHOULD verify that the issuer did issue the signing certificate.  If either of these checks is done and fails, the initiato!
 r MUST return a negative MDN.  If the initiator does not trust the signing certificate because the signing certificate or one of its issuers has been revoked or has expired or is explicitly not trusted, the initiator SHOULD return a negative MDN.  If the initiator already trusts the signing certificate or one of its issuers and all other tests pass, then the initiator MUST return a positive MDN.  If the initiator has no basis to either trust or not trust the signing certificate, then the initiator MUST return a positive MDN.  (This is contrary to the behavior for non-CEM messages, where the initiator returns a negative MDN if it cannot validate the trust of the signing certificate.)  

Sections 4.2.1 and 4.2.2 should be modified as follows.  MUST and SHOULD are replaced by other words, and the requirements for accepting signed messages are modified in accordance with the language above.

   4.2.1.  Step 1 
    
   Initiator creates an EDIINTCertificateExchangeRequest as described in 
   Section 2.0 Message Format and Section 3.0 XML Schema.  The initiator 
   sends it according to EDIINT-AS2 protocol.  Using a digital signature 
   on the AS2 message is optional, as the receiver will not be able to 
   verify until after accepting the signature certificate.  The 
   receiver accepts this message in accordance with section 2.3.
   Unless the initiator 
   possesses the receiver's encryption certificate, encryption is not
   used.  Unless the initiator possesses the receiver's signature 
   certificate, the initiator does not request a signed MDN.  If the MDN is not 
   signed, there is no legal proof the receiver received the message.  
   In addition, a positive MDN received during this step gives some 
   indication of successful transmission of the message, but does not 
   imply successful action on the certificate.  In the case of an 
   encryption certificate, the initiator must be immediately ready to 
   receive documents encrypted with the new certificate.  In the case of 
   a signing certificate, the initiator can begin signing documents with 
   the new certificate at the RespondByDate or upon receipt of an 
   EDIINTCertificateExchangeResponse from the partner indicating they 
   are ready. If an acceptance response is not received by the 
   RespondByDate, the initiator may or may not begin signing with the 
   new certificate, depending on the implementation's capabilities and 
   the policies of the initiator. 
    
   4.2.2.   Step 2 
    
   Receiver validates the EDIINTCertificateExchangeRequest message at 
   the AS2 level and returns an MDN according to the EDIINT-AS2 
   protocol and section 2.3.  If the message is a proper AS2 document, the receiver 
   automatically accepts or rejects the new certificate(s), or requires 
   manual intervention.  Caution should be used in automatically 
   accepting the certificate, as it may be impossible to verify the 
   sender is authentic.  If the certificate is automatically accepted or 
   rejected, an EDIINTCertificateExchangeResponse is generated and 
   returned to the initiator.  Since the trading relationship could be 
   hindered if action is not taken prior to the RespondByDate, manual 
   intervention must be done before that date. When the manual 
   intervention determines to accept or reject the certificate, an 
   EDIINTCertificateExchangeResponse is generated and returned to 
   the initiator.  
    
   In both the automatic and manual case, the 
   EDIINTCertificateExchangeResponses are formatted according to 
   Section 2. Message Processing and Section 3. XML Schema Description 
   and sent according to EDIINT-AS2 protocol.  If the original CEM Request
   included the encryption certificate, or if the receiver has the 
   initiator encryption certificate on file, it may be used to encrypt 
   the AS2 message including the EDIINTCertificateExchangeResponse.  
   Otherwise, it may be necessary to send this 
   EDIINTCertificateExchangeResponse unencrypted.  The message may be 
   signed, but it is possible the initiator will have no way to verify 
   the signature.  The initiator accepts this response in accordance with section 2.3.
   A positive MDN received for the response message 
   indicates successful transmission of the response message. 
    
 




From owner-ietf-ediint@mail.imc.org  Tue Nov 23 09:14:51 2004
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12858
	for <ediint-archive@lists.ietf.org>; Tue, 23 Nov 2004 09:14:51 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id iANDrWZC091178;
	Tue, 23 Nov 2004 05:53:32 -0800 (PST)
	(envelope-from owner-ietf-ediint@mail.imc.org)
Received: (from majordom@localhost)
	by above.proper.com (8.12.11/8.12.9/Submit) id iANDrWnY091177;
	Tue, 23 Nov 2004 05:53:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f
Received: from drummondgroup.com (drummondgroup.com [161.58.166.198])
	by above.proper.com (8.12.11/8.12.9) with ESMTP id iANDrV5g091118
	for <ietf-ediint@imc.org>; Tue, 23 Nov 2004 05:53:31 -0800 (PST)
	(envelope-from rvd2@drummondgroup.com)
Received: from VaioDesktop (68.189.209.146.sbi.ftwrth.tx.charter.com [68.189.209.146] (may be forged))
	(authenticated bits=0)
	by drummondgroup.com (8.12.11/8.12.11) with ESMTP id iANDr1Xd065787
	for <ietf-ediint@imc.org>; Tue, 23 Nov 2004 06:53:21 -0700 (MST)
Message-Id: <200411231353.iANDr1Xd065787@drummondgroup.com>
From: "Rik Drummond" <rvd2@drummondgroup.com>
To: <ietf-ediint@imc.org>
Subject: Status of AS2 as an RFC
Date: Tue, 23 Nov 2004 07:53:02 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcTRY7+Ua8a5jg7rSTKVQhqo8cZFuw==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-ediint/mail-archive/>
List-ID: <ietf-ediint.imc.org>
List-Unsubscribe: <mailto:ietf-ediint-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Dale and Kyle are editing the draft for comments from IESG. As soon as these
is taken into account, it should move on to RFC status.... I hope. After
several years work on this we are almost done. If you have any questions
please contact me... Best regards, rik