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 ; 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 ; 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 ; Tue, 2 Nov 2004 13:06:33 -0700 (MST)
Message-Id: <200411022006.iA2K6WlN004564@drummondgroup.com>
From: "Kyle Meadors"
To:
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:
List-ID:
List-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-entity cert being exchanged]
--foo
Content-Type: Application/pkcs7-mime; smime-type=certs-only
Content-ID:
[CA cert to complete the trust chain on the end-entity]
--foo--
The CEMRequest XML would be modified. The element would be
replaced with a new element, say , 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 ; 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 ; 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"
To: "'Kyle Meadors'" , 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:
List-ID:
List-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-entity cert being exchanged]
> --foo
> Content-Type: Application/pkcs7-mime; smime-type=certs-only
> Content-ID:
> [CA cert to complete the trust chain on the end-entity]
> --foo--
>
> The CEMRequest XML would be modified. The
> element would be
> replaced with a new element, say , 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 ; 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 ; 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 ; Wed, 3 Nov 2004 18:00:13 -0700 (MST)
Message-Id: <200411040100.iA410Dr4085638@drummondgroup.com>
From: "Kyle Meadors"
To:
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:
List-ID:
List-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-entity cert being exchanged]
> --foo
> Content-Type: Application/pkcs7-mime; smime-type=certs-only
> Content-ID:
> [CA cert to complete the trust chain on the end-entity]
> --foo--
>
> The CEMRequest XML would be modified. The
> element would be
> replaced with a new element, say , 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 ; 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 ; 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:
Thread-Topic: changes to CEM message structure
Thread-Index: AcTBF3NOmdTFsP3DSYmZhi8+VuxCAwAzXwyQ
From: "Richard Bigelow"
To: , "Kyle Meadors \(E-mail\)"
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:
List-ID:
List-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-entity cert being exchanged]
--foo
Content-Type: Application/pkcs7-mime; smime-type=certs-only
Content-ID:
[CA cert to complete the trust chain on the end-entity]
--foo--
The CEMRequest XML would be modified. The element would be
replaced with a new element, say , 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 ; 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 ; 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 ; Wed, 3 Nov 2004 18:48:48 -0700 (MST)
Message-Id: <200411040148.iA41ml5b000177@drummondgroup.com>
From: "Kyle Meadors"
To:
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:
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:
List-ID:
List-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-entity cert being exchanged]
--foo
Content-Type: Application/pkcs7-mime; smime-type=certs-only
Content-ID:
[CA cert to complete the trust chain on the end-entity]
--foo--
The CEMRequest XML would be modified. The element would be
replaced with a new element, say , 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 ; 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 ; 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"
To: "'Kyle Meadors'" ,
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:
List-ID:
List-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-entity cert being exchanged]
> > --foo
> > Content-Type: Application/pkcs7-mime; smime-type=certs-only
> > Content-ID:
> > [CA cert to complete the trust chain on the end-entity]
> > --foo--
> >
> > The CEMRequest XML would be modified. The
> element would
> > be replaced with a new element, say , 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 ; 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
Reply-To: dave_hudson2009@fastermail.com
Subject: Inherittance Claim(Please Read This,Very Urgent)
Message-ID:
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 ; 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
Reply-To: dave_hudson2009@fastermail.com
Subject: Inherittance Claim(Please Read This,Very Urgent)
Message-ID:
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 ; 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
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 ; 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
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 ; 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
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 ; 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:
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
Information
WILLIAM HILL LOTTO, No. 1 S=
tation
Avenue, Dublin Road, Athlone, Co. Westmeath=
, Ireland
FROM: THE D=
ESK OF THE
VICE PRESIDENT
INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPT
REF NO: WHC/2666801029/03
BATCH NO: 16/0017/PAD
ATTN: STICK=
WINNER.
RE: AWARD NOTIFICATION, FINAL NOTICE.
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.
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.
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.
CONGRATULATIONS!
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.
To
begin your claim, please contact your claims agent, 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 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.
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.
----=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 ; 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
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:
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 ; 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 ; 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:
Thread-Topic: Certificate Exchange - Use Cases
Thread-Index: AcS2DZHhg3JUGuvDQ8CwKFJn8Z4QowNdaSFQ
From: "Richard Bigelow"
To: "IETF EDIINT WG \(E-mail\)"
Cc: "Kyle Meadors \(E-mail\)"
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:
List-ID:
List-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 ; 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 ; 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 ; Tue, 23 Nov 2004 06:53:21 -0700 (MST)
Message-Id: <200411231353.iANDr1Xd065787@drummondgroup.com>
From: "Rik Drummond"
To:
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:
List-ID:
List-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