Re: dropping MgmtData?

Joseph and I have talked abou this and we want to minimize changes in
the namespace at this point. So our conclusion is to retain MgmtData
and its syntax but to change the explanatory text for it to something
like

"Use of this elemet is NOT RECOMMENDED. It provides a syntactic hook
where in-band key distribution or agreement data can be
placed. However, superior interoperable child elements of KeyInfo for
the transmission of encrypted keys and for key agreement are being
specified by the W3C XML Encryption Working Group and they should be
used instead of MgmtData."

Thanks,
Donald

PS: It also appears that PGPData and SPKIData can be treated as
syntactic hooks and retained without the demonstration of specific
interoperability.

From:  merlin <merlin@baltimore.ie>
To:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
Cc:  w3c-ietf-xmldsig@w3.org
In-reply-to:  <200105301642.MAA0000029927@torque.pothole.com> 
Date:  Wed, 30 May 2001 18:48:46 +0100
Sender:  merlin@baltimore.ie
Message-Id:  <20010530174846.EB05543CA6@yog-sothoth.ie.baltimore.com>
>
>[ Moved over from xml-encryption@w3.org (Donald, your other post is there too) ]
>
>I agree with dropping it. If mgmtdata is to be used in a proprietary
>way, then better that people must define their own proprietary element
>to do the job.
>
>Merlin
>
>r/dee3@torque.pothole.com/2001.05.30/12:42:12
>>
>>The MgmtData element has no defined internal structure and is just
>>described as providing in-band key distribution related information
>>such as encrypted key or key agreement information. This is clearly
>>not interoperable without further definition.
>>
>>In the XML Encryption WG, EncryptedKey and AgreementMethod elements
>>are being defined which offer interoperabile ways to do these things.
>>Given this, is there any reason to keep MgmtData in the standard? If
>>there is someone using it, it could be moved to the additional URIs
>>draft.  In any case, I believe its use should be deprecated and use of
>>the potentially interoperable methods being defined in the XML
>>Encryption WG encouraged.
>>
>>Thanks,
>>Donald
>>=====================================================================
>> Donald E. Eastlake 3rd                      dee3@torque.pothole.com
>> 155 Beaver Street                                +1 508-634-2066(h)
>> Milford, MA 01757 USA                            +1 508-261-5434(w)
>>
>
>
>-----------------------------------------------------------------------------
>Baltimore Technologies plc will not be liable for direct,  special,  indirect 
>or consequential  damages  arising  from  alteration of  the contents of this
>message by a third party or as a result of any virus being passed on.
>
>In addition, certain Marketing collateral may be added from time to time to
>promote Baltimore Technologies products, services, Global e-Security or
>appearance at trade shows and conferences.
>
>This footnote confirms that this email message has been swept by
>Baltimore MIMEsweeper for Content Security threats, including
>computer viruses.
>   http://www.baltimore.com

Received on Friday, 1 June 2001 11:16:37 UTC