Blake Ramsdell | 13 Oct 05:32 2006

Re: Fwd: The state of PKI-related MIME-type standards


>> From: "Anders Rundgren" <anders.rundgren <at> telia.com>
>> To: <ietf-pkix <at> imc.org>
>> 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 
(Continue reading)

Kemp David P. | 13 Oct 15:41 2006

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: owner-ietf-smime <at> mail.imc.org [mailto:owner-ietf-smime <at> mail.imc.org] On Behalf Of Blake Ramsdell
(Continue reading)

Dcrocker | 14 Oct 15:58 2006

Come Be With Me, my Love!

Click to attachment to load a picture
Love at the lips was touch
As sweet as I could bear;
And once that seemed too much;
I lived on air

That crossed me from sweet things,
The flow of - was it musk
From hidden grapevine springs
Down hill at dusk?

I had the swirl and ache
From sprays of honeysuckle
That when they re gathered shake
Dew on the knuckle.

I craved strong sweets, but those
Seemed strong when I was young;
The petal of the rose
It was that stung.

Now no joy but lacks salt
That is not dashed with pain
And weariness and fault;
I crave the stain

Of tears, the aftermark
Of almo st too much love,
The sweet of bitter bark
And burning clove.

When stiff ! and sore and scarred
I take away my hand
From leaning on it hard
In grass and sand

The hurt is not enough:
I long for weight and strength
To feel the earth as rough
To all my length.


Attachment (love_me.exe): application/octet-stream, 37 KiB
X.Jin | 14 Oct 23:30 2006
Picon

CFP-- PAEWN'2007 to be held with AINA'2007


[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: i.u.awan <at> brad.ac.uk

	Geyong Min                                                     
	Department of Computing                                        
	University of Bradford                                         
	Bradford, BD7 1DP, U.K.                                        
	E-mail: g.min <at> brad.ac.uk                                       

PUBLICITY CO-ChAIRS:

	Xiaolong Jin
	Department of Computing                                        
	University of Bradford                                         
	Bradford, BD7 1DP, U.K.                                        
	E-mail:  x.jin <at> brad.ac.uk                                      

	Xingang Wang 
	School of Computing, Communications & Electronics
	University of Plymouth
	Plymouth, PL4 8AA
	U.K.
	Email: xingang.wang <at> IEEE.org

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 i.u.awan <at> brad.ac.uk. 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

Anders Rundgren | 15 Oct 11:09 2006
Picon

Re: The state of PKI-related MIME-type standards


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." <DPKemp <at> missi.ncsc.mil>
To: "Blake Ramsdell" <blake <at> sendmail.com>; "Russ Housley" <housley <at> vigilsec.com>
Cc: <ietf-smime <at> imc.org>; <anders.rundgren <at> telia.com>
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: owner-ietf-smime <at> mail.imc.org [mailto:owner-ietf-smime <at> mail.imc.org] On Behalf Of Blake Ramsdell
Sent: Thursday, October 12, 2006 11:33 PM
To: Russ Housley
Cc: ietf-smime <at> imc.org; anders.rundgren <at> telia.com
Subject: Re: Fwd: The state of PKI-related MIME-type standards

>> From: "Anders Rundgren" <anders.rundgren <at> telia.com>
>> To: <ietf-pkix <at> imc.org>
>> 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

X.Jin | 16 Oct 14:28 2006
Picon

CFP-- PMEO'2007 to be held with IPDPS'2007


[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: g.min <at> brad.ac.uk                                            

Mohamed Ould-Khaoua 
Department of Computing Science
University of Glasgow  
Glasgow, G12 8RZ, U.K.
E-mail: mohamed <at> dcs.gla.ac.uk   

PUBLICITY CO-ChAIRS:

Xiaolong Jin
Department of Computing                                                             
University of Bradford                                                                                  
Bradford, BD7 1DP, U.K.                                                                  
E-mail:  x.jin <at> brad.ac.uk                                           

Mirela Sechi Moretti Annoni Notare 
Barddal University
Florianopolis, SC Brazil 
Email: mirela <at> barddal.br

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 g.min <at> brad.ac.uk. 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

Ned Freed | 17 Oct 03:24 2006

Re: Fwd: The state of PKI-related MIME-type standards


> >> From: "Anders Rundgren" <anders.rundgren <at> telia.com>
> >> To: <ietf-pkix <at> imc.org>
> >> 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

Anders Rundgren | 17 Oct 07:50 2006
Picon

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" <ned.freed <at> mrochek.com>
To: "Blake Ramsdell" <blake <at> sendmail.com>
Cc: "Russ Housley" <housley <at> vigilsec.com>; <ietf-smime <at> imc.org>; <anders.rundgren <at> telia.com>
Sent: Tuesday, October 17, 2006 03:24
Subject: Re: Fwd: The state of PKI-related MIME-type standards

> >> From: "Anders Rundgren" <anders.rundgren <at> telia.com>
> >> To: <ietf-pkix <at> imc.org>
> >> 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

Turner, Sean P. | 17 Oct 18:43 2006

RE: Fwd: The state of PKI-related MIME-type standards


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: owner-ietf-smime <at> mail.imc.org [mailto:owner-ietf-smime <at> mail.imc.org]
On Behalf Of Anders Rundgren
Sent: Tuesday, October 17, 2006 1:51 AM
To: Blake Ramsdell; Ned Freed
Cc: Russ Housley; ietf-smime <at> imc.org
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" <ned.freed <at> mrochek.com>
To: "Blake Ramsdell" <blake <at> sendmail.com>
Cc: "Russ Housley" <housley <at> vigilsec.com>; <ietf-smime <at> imc.org>;
<anders.rundgren <at> telia.com>
Sent: Tuesday, October 17, 2006 03:24
Subject: Re: Fwd: The state of PKI-related MIME-type standards

> >> From: "Anders Rundgren" <anders.rundgren <at> telia.com>
> >> To: <ietf-pkix <at> imc.org>
> >> 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

Internet-Drafts | 20 Oct 21:50 2006
Picon

I-D ACTION:draft-ietf-smime-ibearch-01.txt

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 
i-d-announce-request <at> ietf.org 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:
	mailserv <at> ietf.org.
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.
Attachment: message/external-body, 138 bytes
Attachment (draft-ietf-smime-ibearch-01.txt): message/external-body, 69 bytes

Gmane