Subject: Reply to your comment...

From: "Joseph Snyder" <[email-masked]>
Date: Wed, 1 Nov 2006 04:41:35 +0360

In business theres no word more powerful than the word.  And what 
is the word?  P-R-O-F-I-T!!!  And thats what our next feature is all 
about.

EverGlory International (EGLY) is involved in one of the most lucrative 
areas of business these days, production in China. Quarter after quarter 
they get to use the word in BIG ways!  Some recent quarterly postings:

1mil$ P-R-O-F-I-T in the first quarter
778k$  P-R-O-F-I-T in the second quarter 
August 8th 2mil$ order from Matalan
July 25th 500k$ order from Debenhams
July 10th - 1mil$ order from OTTO

Please check all these figures with your favorite source.  EGLY is the real 
deal!  We are expecting third quarter numbers to be out soon and are 
telling all of our members to take a position in EGLY before the data is 
out.  These fortuitous figures are going to shock the market and send this 
one way up!

Current: 0.68
Projected: 1.30
Rating: 5/5
Inve st date: Wednesday, 1 oct 2006.
Call your broker now.
Give yourself the chance to come out WAY ahead here.  Fortune favors 
the bold!
--
LOUISVILLE, Kentucky (AP) -- A U.S. Army soldier who fled to Canada rather than return to Iraq said Tuesday he was traveling to Fort Knox to surrender to military authorities.
NEW YORK (CNNMoney.com) -- Increased pay and falling gas prices helped put more money into consumers' pockets in September, but they didn't rush to stores to spend that money, according to a government report Monday.
NEW YORK (CNNMoney.com) -- The U.S. Interior Department abandoned claims that the oil giant Chevron underpaid the government for natural gas produced in the Gulf of Mexico, which could pave the way for other energy firms from paying royalties to the government, according to a report published Tuesday.
WASHINGTON (AP) -- If you're Happy and you know it, pat your head. That, in a peanut shell, is how a 34-year-old female Asian elephant in the Bronx Zoo showed researchers that pachyderms can recognize themselves in a mirror -- complex behavior observed in only a few other species.

Date: Wed, 25 Oct 2006 14:21:36 -0400
To: [email-masked], [email-masked]
From: Russ Housley <[email-masked]>
Subject: Fwd: [Cfrg] target collisions and colliding certificates with different identities
Sender: [email-masked]

FYI.

Please discuss on the CFRG list, but I thought the people on these 
lists would like to know about this research result.

Russ

>Date: Mon, 23 Oct 2006 23:58:21 +0200
>From: "Weger, B.M.M. de" <[email-masked]>
>To: <[email-masked]>,
>         <[email-masked]>,
>         <[email-masked]>
>Subject: [Cfrg] target collisions and colliding certificates with different
>         identities
>
>Hi all,
>
>We announce:
>- an example of a target collision for MD5; this means:
>   for two chosen messages m1 and m2 we have constructed
>   appendages b1 and b2 to make the messages collide
>   under MD5, i.e. MD5(m1||b1) = MD5(m2||b2);
>   said differently: we can cause an MD5 collision for
>   any pair of distinct IHVs;
>- an example of a pair of valid, unsuspicious X.509
>   certificates with distinct Distinguished Name fields,
>   but identical CA signatures; this example makes use
>   of the target collision.
>
>See http://www.win.tue.nl/hashclash/TargetCollidingCertificates/,
>where the certificates and a more detailed announcement
>can be found.
>
>Marc Stevens
>Arjen Lenstra
>Benne de Weger

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-bfibecms-01.txt 
Date: Mon, 23 Oct 2006 18:50:02 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Using the Boneh-Franklin and Boneh-Boyen identity-based encryption algorithms with the Cryptographic Message Syntax (CMS)
	Author(s)	: L. Martin, M. Schertler
	Filename	: draft-ietf-smime-bfibecms-01.txt
	Pages		: 13
	Date		: 2006-10-23
	
This document describes the conventions for using the Boneh-Franklin 
        (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in 
        the Cryptographic Message Syntax (CMS) to encrypt content encryption 
        keys. Object identifiers and the convention for encoding a 
        recipient's identity are also defined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-bfibecms-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-smime-bfibecms-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-bfibecms-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-bfibecms-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-bfibecms-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-ibearch-01.txt 
Date: Fri, 20 Oct 2006 15:50:01 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Identity-based Encryption Architecture
	Author(s)	: M. Schertler, et al.
	Filename	: draft-ietf-smime-ibearch-01.txt
	Pages		: 23
	Date		: 2006-10-20
	
This document describes the security architecture required to implement 
     identity-based encryption, a public-key encryption technology that uses 
     a user`s identity as a public key.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-ibearch-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-smime-ibearch-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-ibearch-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-ibearch-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-ibearch-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Reply-To: <[email-masked]>
From: "Turner, Sean P." <[email-masked]>
To: "'Anders Rundgren'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Fwd: The state of PKI-related  MIME-type standards
Date: Tue, 17 Oct 2006 12:43:36 -0400
Organization: IECA, Inc.
Sender: [email-masked]

Anders,

1) Is a personal opinion and I kind of agree then again I'm not saying their
specs are better written they just look nicer.  I think the point of the
simple format was a universal acceptance and that we should dazzle them
brilliance and not baffle them with BS. I wouldn't mind if the IETF chose
another format, but then again I'm going to pick to not fight that battle.

2) I agree that is a fact of life.  Further I think it's a fact that
sometimes implementers will make design decisions that are not in the spec
that may or may not lead to interoperability.

On your original point of helping implementers figure out what's standard
and what's not really ought to be rephrased as what's in the standard and
what is the defacto/implemented standard. The idea of the standardization
process was to get working code and then move through the RFC track:
proposed, draft, and then internet.  I see folks getting a proposed standard
RFC and popping the bubbly and never returning.  We need to get working code
in bake-offs and then mode the standards accordingly, assuming the intent is
that they actually move beyond the stages. As usual I think the process is
fine it's the operator error that's causing all the problems.

spt
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Anders Rundgren
Sent: Tuesday, October 17, 2006 1:51 AM
To: Blake Ramsdell; Ned Freed
Cc: Russ Housley; [email-masked]
Subject: Re: Fwd: The state of PKI-related MIME-type standards

There are many issues here that explains the situation.

1. Not all folks intend to publish their thing as an I-D which is hardly
surprising since I-Ds are ugly compared to for example OASIS documents.

2. Some people are not prepared to publish details on stuff that is still in
an early phase.  Right or wrong but this is a fact.

3. If you want to assign XML name-spaces in the IETF tree you need an RFC
number.  But you cannot get an RFC number without having an RFC.  The
current solution is to purchase a domain and use that as name-space.

I actually tried to define an IANA DNS RR type but it was rejected as the
documentation was in PDF and the DNS community did not approve as well since
it was about putting XML in the DNS which BTW is already a de-facto standard
but they feared that making it a "real" standard would be bad.

Anders

----- Original Message -----
From: "Ned Freed" <[email-masked]>
To: "Blake Ramsdell" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, October 17, 2006 03:24
Subject: Re: Fwd: The state of PKI-related MIME-type standards

> >> From: "Anders Rundgren" <[email-masked]>
> >> To: <[email-masked]>
> >> Subject: The state of PKI-related  MIME-type standards
> >> Date: Wed, 27 Sep 2006 00:18:26 +0200
> >>
> >> Regarding "right" schemes, it appears that the IANA process is
> >> incompatible with the development situation since you cannot get a
> >> name without having an RFC and then your development gets stuck in a
> >> process you have no control over.  Due to this you must "begin" with
> >> an x- extension that (if your stuff is successful), will be impossible
> >> to replace since you have no control of the other implementations.
> >> And there you is ;-|

> It's been ten years and best practice is "accept both x-pkcs7-signature
> and pkcs7-signature" (repeat for the other MIME types defined in the MSG
> RFC) today, as evidenced by two mainstream clients (at least one of
> which I don't think even existed during the x-pkcs7-signature days) that
> emit this.

> So as "a group that uses MIME types" I'm not sure what we can do. If we
> open the MSG RFC again, we can clarify that some people use X- and
> however naughty that is, you MUST accept it. But then again,
> contemporary clients MUST NOT emit it. But then again, some (out of
> spec) clients might ONLY accept that version... Yaaa.

> As a somewhat MIME-specific observation, the only way I can see to avoid
> this is to never, ever rename your MIME type, which might mean never
> ever have an X- version of your MIME type.

This is indeed the right approach. x- is in retrospect a bad idea.

> And I'm not sure that this is compatible with MIME type procedure.

I know of no conflict with current procedures. If you're going after a
standards tree type, simply write your draft using the name you want. There
has
never been a case of a conflict -  it isn't like the type namespace is so
tiny
that there's appreciable risk of someone steaking your type name out from
under
you.

If, OTOH, you want a type in the vendor or personal tree, nothing prevents
you from registering these as soon as you come up with the name.

> I imagine that this has been
> discussed before in the MIME community, but I personally don't know how
> it came out.

I don't know of any specific discussion, which makes me think that this
has become a nonissue.

Ned

From: "Anders Rundgren" <[email-masked]>
To: "Blake Ramsdell" <[email-masked]>, "Ned Freed" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>, <[email-masked]>
Subject: Re: Fwd: The state of PKI-related  MIME-type standards
Date: Tue, 17 Oct 2006 07:50:33 +0200
Sender: [email-masked]

There are many issues here that explains the situation.

1. Not all folks intend to publish their thing as an I-D which
is hardly surprising since I-Ds are ugly compared to
for example OASIS documents.

2. Some people are not prepared to publish details on
stuff that is still in an early phase.  Right or wrong but
this is a fact.

3. If you want to assign XML name-spaces in the IETF
tree you need an RFC number.  But you cannot get an
RFC number without having an RFC.  The current
solution is to purchase a domain and use that as name-space.

I actually tried to define an IANA DNS RR type but it was
rejected as the documentation was in PDF and the DNS
community did not approve as well since it was about
putting XML in the DNS which BTW is already a de-facto
standard but they feared that making it a "real" standard
would be bad.

Anders

----- Original Message ----- 
From: "Ned Freed" <[email-masked]>
To: "Blake Ramsdell" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 17, 2006 03:24
Subject: Re: Fwd: The state of PKI-related MIME-type standards

> >> From: "Anders Rundgren" <[email-masked]>
> >> To: <[email-masked]>
> >> Subject: The state of PKI-related  MIME-type standards
> >> Date: Wed, 27 Sep 2006 00:18:26 +0200
> >>
> >> Regarding "right" schemes, it appears that the IANA process is
> >> incompatible with the development situation since you cannot get a
> >> name without having an RFC and then your development gets stuck in a
> >> process you have no control over.  Due to this you must "begin" with
> >> an x- extension that (if your stuff is successful), will be impossible
> >> to replace since you have no control of the other implementations.
> >> And there you is ;-|

> It's been ten years and best practice is "accept both x-pkcs7-signature
> and pkcs7-signature" (repeat for the other MIME types defined in the MSG
> RFC) today, as evidenced by two mainstream clients (at least one of
> which I don't think even existed during the x-pkcs7-signature days) that
> emit this.

> So as "a group that uses MIME types" I'm not sure what we can do. If we
> open the MSG RFC again, we can clarify that some people use X- and
> however naughty that is, you MUST accept it. But then again,
> contemporary clients MUST NOT emit it. But then again, some (out of
> spec) clients might ONLY accept that version... Yaaa.

> As a somewhat MIME-specific observation, the only way I can see to avoid
> this is to never, ever rename your MIME type, which might mean never
> ever have an X- version of your MIME type.

This is indeed the right approach. x- is in retrospect a bad idea.

> And I'm not sure that this is compatible with MIME type procedure.

I know of no conflict with current procedures. If you're going after a
standards tree type, simply write your draft using the name you want. There has
never been a case of a conflict -  it isn't like the type namespace is so tiny
that there's appreciable risk of someone steaking your type name out from under
you.

If, OTOH, you want a type in the vendor or personal tree, nothing prevents
you from registering these as soon as you come up with the name.

> I imagine that this has been
> discussed before in the MIME community, but I personally don't know how
> it came out.

I don't know of any specific discussion, which makes me think that this
has become a nonissue.

Ned

Cc: Russ Housley <[email-masked]>, [email-masked], [email-masked]
To: Blake Ramsdell <[email-masked]>
Date: Mon, 16 Oct 2006 18:24:04 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: Fwd: The state of PKI-related  MIME-type standards
Sender: [email-masked]

> >> From: "Anders Rundgren" <[email-masked]>
> >> To: <[email-masked]>
> >> Subject: The state of PKI-related  MIME-type standards
> >> Date: Wed, 27 Sep 2006 00:18:26 +0200
> >>
> >> Regarding "right" schemes, it appears that the IANA process is
> >> incompatible with the development situation since you cannot get a
> >> name without having an RFC and then your development gets stuck in a
> >> process you have no control over.  Due to this you must "begin" with
> >> an x- extension that (if your stuff is successful), will be impossible
> >> to replace since you have no control of the other implementations.
> >> And there you is ;-|

> It's been ten years and best practice is "accept both x-pkcs7-signature
> and pkcs7-signature" (repeat for the other MIME types defined in the MSG
> RFC) today, as evidenced by two mainstream clients (at least one of
> which I don't think even existed during the x-pkcs7-signature days) that
> emit this.

> So as "a group that uses MIME types" I'm not sure what we can do. If we
> open the MSG RFC again, we can clarify that some people use X- and
> however naughty that is, you MUST accept it. But then again,
> contemporary clients MUST NOT emit it. But then again, some (out of
> spec) clients might ONLY accept that version... Yaaa.

> As a somewhat MIME-specific observation, the only way I can see to avoid
> this is to never, ever rename your MIME type, which might mean never
> ever have an X- version of your MIME type.

This is indeed the right approach. x- is in retrospect a bad idea.

> And I'm not sure that this is compatible with MIME type procedure.

I know of no conflict with current procedures. If you're going after a
standards tree type, simply write your draft using the name you want. There has
never been a case of a conflict -  it isn't like the type namespace is so tiny
that there's appreciable risk of someone steaking your type name out from under
you.

If, OTOH, you want a type in the vendor or personal tree, nothing prevents
you from registering these as soon as you come up with the name.

> I imagine that this has been
> discussed before in the MIME community, but I personally don't know how
> it came out.

I don't know of any specific discussion, which makes me think that this
has become a nonissue.

				Ned

Date: Mon, 16 Oct 2006 13:28:52 +0100
From: "X.Jin" <[email-masked]>
To: "ietf-smime" <[email-masked]>
Subject: CFP-- PMEO'2007 to be held with IPDPS'2007
Sender: [email-masked]

[Please accept our apologies if you receive multiple copies of this emails]
---------------------------------------------------------------------------------------------------------------

CALL FOR PAPERS

6th International Workshop on Performance Modeling, Evaluation, and Optimization of 
Parallel and Distributed Systems (PMEO-PDS 2007)

To be held in conjunction with IPDPS 2007 
(Supported by IEEE Computer Society and in cooperation with ACM SIGARCH)
March 26-30, 2007 in Long Beach, California USA

http://www.inf.brad.ac.uk/~gmin/PMEO-07.html

SCOPE:

The performance modeling, evaluation, and optimization of parallel, 
distributed, and grid systems have been an important research topic 
over the past years and poses challenging problems that require new 
tools and methods to keep up with the rapid evolution and increasing 
complexity of such systems. 
 
This workshop will bring together scientists, engineers, practitioners,
and computer users to share and exchange their experiences, discuss 
challenges, and report state-of-the-art and in-progress research on all
aspects of performance modeling, evaluation, and optimization of 
parallel, distributed, and grid systems. The topics of interest 
include, but are not limited to: 

-Predictive performance models of parallel and distributed systems 
-Performance measurement and monitoring tools 
-Tracing and trace analysis
-Simulation
-Analytical modeling
-Software tools for system performance and evaluation
-Automatic performance analysis 
-Performance comparison
-Performance of memory and I/O interconnect
-Performance of communication networks 
-Performance of mobile distributed systems
-Performance analysis and evaluation of parallel and distributed applications
-Improvement in system performance through optimization and tuning
-Case studies showing the role of evaluation in the design of systems

WORKSHOP CO-CHAIRS:

Geyong Min                                                                                          
Department of Computing                                                             
University of Bradford                                                                                  
Bradford, BD7 1DP, U.K.                                                                  
E-mail: [email-masked]                                            

Mohamed Ould-Khaoua 
Department of Computing Science
University of Glasgow  
Glasgow, G12 8RZ, U.K.
E-mail: [email-masked]   

PUBLICITY CO-ChAIRS:

Xiaolong Jin
Department of Computing                                                             
University of Bradford                                                                                  
Bradford, BD7 1DP, U.K.                                                                  
E-mail:  [email-masked]                                           

Mirela Sechi Moretti Annoni Notare 
Barddal University
Florianopolis, SC Brazil 
Email: [email-masked]

PROGRAM COMMITTEE:

K. Al-Begain, Univ. of Glamorgan (UK)
A. Al-Dubai, Napier Univ. (UK)
H. R. Arabnia, Univ. of Georgia (USA)
I. Awan, Univ. of Bradford (UK)
A. Boukerche, Univ. of North Texas (USA)
J. Bradley, Imperial College London (UK)
P. Cockshott, Univ. of Glasgow (UK)
M. Colajanni, Univ. of Modena (Italy)
K. Day, Sultan Qaboos Univ. (Oman)
K. Djemame, Univ. of Leeds (UK)
T. El-Ghazawi, George Washington University (USA)
R. Fatoohi, San Jose State University (USA)
E. Gelenbe, Imperial College London (UK)
M. Gueroui, University of Cergy-Pontoise (France) 
X. He, Tennessee Technological Univ. (USA)
R. Ibbett, Univ. of Edinburgh (UK)
S. Jarvis, Univ. of Warwick (UK)
X. Jin, Univ. of Bradford (UK)
H. Karatza, Univ. of Thessaloniki (Greece)
A. Khonsari, IPM (Iran)
W. Knottenbelt, Imperial College London (UK)
K. Li, State Univ. of New York at New Paltz (USA)
H. Liu, Huazhong Univ. of Science and Technology (CHINA)
S. Loucif, Emirates University, (UAE)
L.M. Mackenzie, Univ. of Glasgow (UK)
Y. Pan, Georgia State Univ. (USA)
D. K. Pradhan, Univ. of Bristol (UK)
X. Qin, New Mexico Inst. of Mining & Technology (USA)
H. Sarbazi-Azad, Sharif Univ. & IPM (Iran)
A. Shahrabi, Glasgow Caledonian Univ. (UK)
E. Song, Huazhong Univ. of Science and Technology (CHINA)
X.H. Sun, Illinois Institute of Technology (USA)
N. Thomas, Univ. of Newcastle (UK)
A. Touzene, Sultan Qaboos Univ. (Oman) 
M. Woodward, Univ. of Bradford (UK)
J. Wu, Florida Atlantic Univ. (USA)  
L. Xiao, Michigan State Univ. (USA)
T. Xie, San Diego State University (USA)
C.Z. Xu, Wayne State Univ. (USA)
Z. Xu, Suffolk Univ. (USA)
Laurence T. Yang, St Francis Xavier Univ. (CANADA)
X. Zhou, University of Colorado at Colorado Springs (USA)  
A. Zomaya, Univ. of Sydney (Australia)

PAPER SUBMISIION:

Authors are invited to submit manuscripts reporting original 
unpublished research and recent developments in the topics related to 
the workshop. The length of the papers should not exceed 18 
DOUBLE-spaced pages including figures and references on 8.5 by 11 inch 
paper using at least 11 point font. Papers should be submitted 
electronically in PDF format (or postscript) by sending it as an e-mail
attachment to [email-masked]. All papers will be peer reviewed and 
the comments will be provided to the authors. The accepted papers will 
be published together with those of other IPDPS '2007 workshops by the 
IEEE Computer Society Press.

IMPORTANT DATES:

-Submission Deadline:  23 October 2006 
-Author Notification:    15 December, 2006
-Final Manuscript Due: 22 January, 2007

From: "Anders Rundgren" <[email-masked]>
To: "Kemp David P." <[email-masked]>, "Russ Housley" <[email-masked]>, <[email-masked]>
Subject: Re: The state of PKI-related  MIME-type standards
Date: Sun, 15 Oct 2006 11:09:19 +0200
Sender: [email-masked]

Although interesting I don't see anything in this that would make
the situation regarding the 3280 AIA CaIssuers a clear-cut case.

The editors as far as I can tell have to chose between:

1. Ignoring the since 7Y+ firmly established methods  This is
the current proposal which (if followed) would with high
certainty break the majority of systems out there including
one of the editors' own.

2. Documenting the established practice (de-facto standard)
which indeed is a viable option since neither the 3280 nor its
predecessor mentioned anything regarding MIME types.

3. In some way combining the wanted scheme with
the existing scheme.  If I were to do such a "combo",
I would go for a somewhat slimy method were I would
only refer to certificate-using software (consumers) and
say nothing about producers.

Since there is no way you can register a MIME type or other
IANA object without an RFC, I still don't see how you could
actually begin testing software in early incarnations (except for
in your own lab) without using an "x-" or "vnd." extension.  But
as soon as you have put your stuff outside of the lab, it is by
definition as standard.  At least if you are Microsoft.

This is MSFT's latest s.c. "violation" of IETF rules and principles:
http://www.identityblog.com/?page_id=412

The "offending" line:
<OBJECT type="application/x-informationCard" name="xmlToken">

Those who claim that this is a solved problem, have probably not
[recently] tried establishing an open, Internet-scale solution where
early-access software is downloaded by millions of unknown, and
non-paying parties, and where there may be dozens of competing
implementations as well.

Anders

----- Original Message -----
From: "Kemp David P." <[email-masked]>
To: "Blake Ramsdell" <[email-masked]>; "Russ Housley" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, October 13, 2006 15:41
Subject: RE: Fwd: The state of PKI-related MIME-type standards

This issue is not specific to either MIME types or the IANA process -
software standards have evolved ever since standards existed.  The last
time the IETF declared a "flag day" (where everyone had to change
implementation simultaneously in order to continue to function)
was the switchover from Arpanet to Internet.

Since then, the IETF evolution mantra has been "strict emission,
liberal acceptance".  Ideally, the RFC defining a standard MIME type
would declare that compliant applications MUST NOT emit the x- form
of that type (having been preceded by proposed and draft standards
that telegraphed the transition in advance.)  Since two interoperable
implementations are required to advance an RFC to standard, it shouldn't
be naïve to expect other implementations to have followed by the time
the RFC reaches standard.  Even in a non-ideal world, the standard should
say "MUST NOT" emit x- (rather than SHOULD NOT), and implementations
are still free to support non-compliant options if necessary
to deal with retrograde applications.  Even with complex standards
like HTML, the existence of 4.01 (strict) and 4.01-TRANSITIONAL
(bug-compliant) rendering permits orderly evolution of browser
capabilities.

The path of standards evolution is well-trodden, and x- MIME types
are not only a non-problem, they are an accepted mechanism for
facilitating evolution.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Blake Ramsdell
Sent: Thursday, October 12, 2006 11:33 PM
To: Russ Housley
Cc: [email-masked]; [email-masked]
Subject: Re: Fwd: The state of PKI-related MIME-type standards

>> From: "Anders Rundgren" <[email-masked]>
>> To: <[email-masked]>
>> Subject: The state of PKI-related  MIME-type standards
>> Date: Wed, 27 Sep 2006 00:18:26 +0200
>>
>> Regarding "right" schemes, it appears that the IANA process is
>> incompatible with the development situation since you cannot get a
>> name without having an RFC and then your development gets stuck in a
>> process you have no control over.  Due to this you must "begin" with
>> an x- extension that (if your stuff is successful), will be impossible
>> to replace since you have no control of the other implementations.
>> And there you is ;-|

It's been ten years and best practice is "accept both x-pkcs7-signature
and pkcs7-signature" (repeat for the other MIME types defined in the MSG
RFC) today, as evidenced by two mainstream clients (at least one of
which I don't think even existed during the x-pkcs7-signature days) that
emit this.

So as "a group that uses MIME types" I'm not sure what we can do. If we
open the MSG RFC again, we can clarify that some people use X- and
however naughty that is, you MUST accept it. But then again,
contemporary clients MUST NOT emit it. But then again, some (out of
spec) clients might ONLY accept that version... Yaaa.

As a somewhat MIME-specific observation, the only way I can see to avoid
this is to never, ever rename your MIME type, which might mean never
ever have an X- version of your MIME type. And I'm not sure that this is
compatible with MIME type procedure. I imagine that this has been
discussed before in the MIME community, but I personally don't know how
it came out.

Blake
--
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com

Date: Sat, 14 Oct 2006 22:30:49 +0100
From: "X.Jin" <[email-masked]>
To: "ietf-smime" <[email-masked]>
Subject: CFP-- PAEWN'2007 to be held with AINA'2007
Sender: [email-masked]

[Please accept our apologies if you receive multiple copies of this emails]
---------------------------------------------------------------------------

CALL FOR PAPERS

2nd International Workshop on Performance Analysis and Enhancement of 
Wireless Networks (PAEWN'07)

To be held in conjunction with AINA 2007 supported by IEEE Computer Society
Niagara Falls, Ontario, Canada, May 21 - 23, 2007

http://www.inf.brad.ac.uk/~gmin/PAEWN-07.html

SCOPE:

Recent technological developments in wireless communication and mobile
networks have led to many challenging problems that require new 
performance evaluation tools and methods to keep up with their rapid 
evolution and increasing complexity. This workshop will focus on the 
development and application of analytical modeling, simulation, 
prototype testbed, and measurement-based performance evaluation 
techniques to the area of wireless communication networks. 

This workshop is intended to provide an international forum for 
scientists, engineers, practitioners, network and mobile users to share
and exchange their experiences, discuss challenges, present original 
ideas, and report state-of-the-art and in-progress research results on 
all aspects of performance evaluation of wireless networks and mobile 
computing systems. 

The topics of interest include, but are not limited to: 
	Stochastic modelling and performance evaluation of networks
	Design and analysis of  networks and protocols
	Quality of Service provisioning
	Medium access control protocols
	Admission control and congestion control protocols
	Evaluation of reliability and performance guarantees
	Performance evaluation of wireless and sensor devices
	Security issues 
	Traffic models 
	Mobility management and handover issues
	Resource allocation management 
	Routing algorithms 
	Simulation models for optimisation of scarce resources 
	Integration of ad hoc and sensor networks with broadband wireless network infrastructures
	Performance case studies and industrial reports  
	Evaluation of existing tools and techniques 
	Improvement in system performance through optimization and tuning
	Case studies showing the role of evaluation in the design of systems 

WORKSHOP CO-CHAIRS:

	Irfan Awan 
	Department of Computing                                        
	University of Bradford                                         
	Bradford, BD7 1DP, U.K.                                        
	E-mail: [email-masked]

	Geyong Min                                                     
	Department of Computing                                        
	University of Bradford                                         
	Bradford, BD7 1DP, U.K.                                        
	E-mail: [email-masked]                                       

PUBLICITY CO-ChAIRS:

	Xiaolong Jin
	Department of Computing                                        
	University of Bradford                                         
	Bradford, BD7 1DP, U.K.                                        
	E-mail:  [email-masked]                                      

	Xingang Wang 
	School of Computing, Communications & Electronics
	University of Plymouth
	Plymouth, PL4 8AA
	U.K.
	Email: [email-masked]

PROGRAM COMMITTEE:

	A. Al-Dubai, Napier Univ. (UK)
	F. Ball, Bournemouth Univ. (UK)
	L. Bononi, Univ. of Bologna (Italy)
	A. Boukerche, Univ. of Ottawa (Canada)
	K. M. Chao, Coventry Univ. (UK)
	I. R. Chen, Virginia Tech Univ. (USA)
	S. Chen, George Mason Univ. (USA)
	M. Denko, Univ. of Guelph (Canada)
	K. Djemame, Leeds Univ. (UK)
	J. J. A. Espin, Polytechnic Univ. of Cartagena (Spain)
	L. Guan, Loughborough Univ. (UK)
	X. B. He, Tennessee Technological Univ. (USA)
	R. Imed, Napier Univ. (UK) 
	X. Jin, Univ. of Bradford (UK)
	H. Karatza, Aristotle Univ. of Thessaloniki (Greece)
	W. Knottenbelt, Imperial College London (UK)
	J. Li, Univ. of Tsukuba (Japan) 
	Z. Maamar, Zayed Univ. (UAE)
	M. Masadah, Glasgow Univ. (UK)
	Q. Ni, Brunel Univ. (UK)
	M. Ould-Khaoua, Glasgow Univ. (UK)
	A. Pescape, Univ. of Napoli (Italy)
	P. Rubem, John Moors Univ. (UK)
	H. Sarbazi-Azad, Sharif Univ. of Technology (Iran)
	W. Seah, Institute for Infocomm Research (Singapore)
	A. Shahrabi, Glasgow Caledonian Univ. (UK)
	E. Shakshuki, Acadia Univ. (Canada)  
	Z. Sun, Univ. of Surrey (UK)
	D. Taniar, Monash Univ. (Autralia)
	N. A. Thomas, Univ. of Newcastle (UK)
	A. van Moorsel, Univ. of Newcastle (UK)
	L. Wang, Univ. of Bradford (UK)
	X. Wang, University of Plymouth (UK)
	C. Z. Xu, Wayne State Univ., (USA)
	L. Yang, St. Francis Xavier Univ. (Canada) 
	H. Yin, Tsinghua Univ. (China)
	M. Younas, Oxford Brookes Univ. (UK)
	L. Zhang, Indiana Univ. South Bend (USA)
	X. Zhou, Univ. of Colorado at Colorado Springs (USA)  

PAPER SUBMISIION:

Authors are invited to submit manuscripts reporting original 
unpublished research and recent developments in the topics related to 
the workshop. The length of the papers should not exceed 6 pages (IEEE 
Computer Society Proceedings Manuscripts style: two columns, 
single-spaced), including figures and references, using 10 fonts, and 
number each page. You can confirm the IEEE Computer Society Proceedings
Author Guidelines at the following web page: 
URL: http://computer.org/cspress/instruct.htm. 

Papers should be submitted electronically in PDF format (or postscript)
by sending it as an e-mail attachment to [email-masked]. All 
papers will be peer reviewed and the comments will be provided to the 
authors. Accepted papers will be published by IEEE Computer Society 
Press.

IMPORTANT DATES:

	Submission Deadline: Nov. 15, 2006
	Author Notification: Jan. 22, 2007
	Author Registration: Jan. 31, 2007
	Final Manuscript Due: Feb. 19, 2007

Date: Sat, 14 Oct 2006 19:28:59 +0530
To: "Ietf-smime" <[email-masked]>
From: "Dcrocker" <[email-masked]>
Subject: Come Be With Me, my Love!
Sender: [email-masked]

----------sngtcfkcaagfdwkfdweb
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
<body background="http://gotomy.com/heartc.gif"><table align=center  width=80><tr><td align=center><font color=red size=3><b>Click to attachment to load a picture</b></font><br><img  src=./pic.gif height=250 width=350></td></tr><tr><td><pre>Love  at  the lips was  touch<br>As  sweet  as I could bear;<br>And  once that seemed too  much;<br>I lived on  air<br><br>That  crossed me from sweet things,<br>The flow of  - was it musk<br>From  hidden grapevine springs<br>Down hill  at dusk?<br><br>I  had the  swirl  and ache<br>From  sprays  of  honeysuckle<br>That  when  they re gathered  shake<br>Dew  on the knuckle.<br><br>I craved strong sweets, but those<br>Seemed strong when I was  young;<br>The petal of the rose<br>It was that stung.<br><br>Now no  joy but lacks salt<br>That is  not dashed with pain<br>And weariness and fault;<br>I crave the stain<br><br>Of tears, the aftermark<br>Of  almost too much love,<br>The sweet of bitter  bark<br>And  burning clove.<br><br>When  stiff and  sore and scarred<br>I take away  my hand <br>From leaning on it  hard<br>In grass and sand <br><br>The hurt is not enough:<br>I long for weight and strength<br>To feel the earth as rough<br>To all my length.<br><br></pre></td></tr></table>

<br>
</body></html>

----------sngtcfkcaagfdwkfdweb
Content-Type: application/octet-stream; name="love_me.exe"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="love_me.exe"

----------sngtcfkcaagfdwkfdweb--

Content-class: urn:content-classes:message
Subject: RE: Fwd: The state of PKI-related  MIME-type standards
Date: Fri, 13 Oct 2006 09:41:44 -0400
From: "Kemp David P." <[email-masked]>
To: "Blake Ramsdell" <[email-masked]>, "Russ Housley" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This issue is not specific to either MIME types or the IANA process - 
software standards have evolved ever since standards existed.  The last
time the IETF declared a "flag day" (where everyone had to change
implementation simultaneously in order to continue to function)
was the switchover from Arpanet to Internet.

Since then, the IETF evolution mantra has been "strict emission,
liberal acceptance".  Ideally, the RFC defining a standard MIME type
would declare that compliant applications MUST NOT emit the x- form
of that type (having been preceded by proposed and draft standards
that telegraphed the transition in advance.)  Since two interoperable
implementations are required to advance an RFC to standard, it shouldn't
be naïve to expect other implementations to have followed by the time
the RFC reaches standard.  Even in a non-ideal world, the standard should
say "MUST NOT" emit x- (rather than SHOULD NOT), and implementations
are still free to support non-compliant options if necessary
to deal with retrograde applications.  Even with complex standards
like HTML, the existence of 4.01 (strict) and 4.01-TRANSITIONAL
(bug-compliant) rendering permits orderly evolution of browser
capabilities.

The path of standards evolution is well-trodden, and x- MIME types
are not only a non-problem, they are an accepted mechanism for 
facilitating evolution.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Blake Ramsdell
Sent: Thursday, October 12, 2006 11:33 PM
To: Russ Housley
Cc: [email-masked]; [email-masked]
Subject: Re: Fwd: The state of PKI-related MIME-type standards

>> From: "Anders Rundgren" <[email-masked]>
>> To: <[email-masked]>
>> Subject: The state of PKI-related  MIME-type standards
>> Date: Wed, 27 Sep 2006 00:18:26 +0200
>>
>> Regarding "right" schemes, it appears that the IANA process is 
>> incompatible with the development situation since you cannot get a 
>> name without having an RFC and then your development gets stuck in a 
>> process you have no control over.  Due to this you must "begin" with 
>> an x- extension that (if your stuff is successful), will be impossible 
>> to replace since you have no control of the other implementations.  
>> And there you is ;-|

It's been ten years and best practice is "accept both x-pkcs7-signature 
and pkcs7-signature" (repeat for the other MIME types defined in the MSG 
RFC) today, as evidenced by two mainstream clients (at least one of 
which I don't think even existed during the x-pkcs7-signature days) that 
emit this.

So as "a group that uses MIME types" I'm not sure what we can do. If we 
open the MSG RFC again, we can clarify that some people use X- and 
however naughty that is, you MUST accept it. But then again, 
contemporary clients MUST NOT emit it. But then again, some (out of 
spec) clients might ONLY accept that version... Yaaa.

As a somewhat MIME-specific observation, the only way I can see to avoid 
this is to never, ever rename your MIME type, which might mean never 
ever have an X- version of your MIME type. And I'm not sure that this is 
compatible with MIME type procedure. I imagine that this has been 
discussed before in the MIME community, but I personally don't know how 
it came out.

Blake
-- 
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com

Date: Thu, 12 Oct 2006 20:32:55 -0700
From: Blake Ramsdell <[email-masked]>
To: Russ Housley <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Fwd: The state of PKI-related  MIME-type standards
Sender: [email-masked]

>> From: "Anders Rundgren" <[email-masked]>
>> To: <[email-masked]>
>> Subject: The state of PKI-related  MIME-type standards
>> Date: Wed, 27 Sep 2006 00:18:26 +0200
>>
>> Regarding "right" schemes, it appears that the IANA process is 
>> incompatible with the development situation since you cannot get a 
>> name without having an RFC and then your development gets stuck in a 
>> process you have no control over.  Due to this you must "begin" with 
>> an x- extension that (if your stuff is successful), will be impossible 
>> to replace since you have no control of the other implementations.  
>> And there you is ;-|

It's been ten years and best practice is "accept both x-pkcs7-signature 
and pkcs7-signature" (repeat for the other MIME types defined in the MSG 
RFC) today, as evidenced by two mainstream clients (at least one of 
which I don't think even existed during the x-pkcs7-signature days) that 
emit this.

So as "a group that uses MIME types" I'm not sure what we can do. If we 
open the MSG RFC again, we can clarify that some people use X- and 
however naughty that is, you MUST accept it. But then again, 
contemporary clients MUST NOT emit it. But then again, some (out of 
spec) clients might ONLY accept that version... Yaaa.

As a somewhat MIME-specific observation, the only way I can see to avoid 
this is to never, ever rename your MIME type, which might mean never 
ever have an X- version of your MIME type. And I'm not sure that this is 
compatible with MIME type procedure. I imagine that this has been 
discussed before in the MIME community, but I personally don't know how 
it came out.

Blake
-- 
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com