Hi Peter, hi all, ok. You are right, I was not aware that they are 100% interoperable. "CryptographicMessageSyntax2004 -- FROM [RFC3852]" Interoperable with "ContentInfo FROM PKCS-7" "AlgorithmIdentifier FROM PKIX1Explicit88" Interoperable with "AlgorithmIdentifier FROM AuthenticationFramework" Where I am unsure is whether to A) list the current (version 09) ASN.1 structure and put the other imports that you propose in the appendix or B) vice versa (i.e. as you proposed below). Is there a strong reason/opinion why we should choose option B? Thank you, Tobias > -----Original Message----- > From: Peter Sylvester [mailto:Peter.Sylvester@xxxxxxxxxx] > Sent: Tuesday, January 02, 2007 12:38 PM > To: Tobias Gondrom > Cc: Carl Wallace; ietf-ltans@xxxxxxx > Subject: Re: LTANS summary > > Tobias Gondrom wrote: > > Hi Peter and Carl, > > > > I do not agree: I do not think that two alternative imports is a good > idea. Because the definition and import to the document should be > unambiguous. (How can developers decide which imports to use or have been > used, and how to ensure interoperability of different implementers? For > this we would have to implement an own additional ID just to define which > import has been used.) > > > > But maybe I misunderstood s.th.? > > > > > Indeed, I have this impression: > > The proposal is to have TWO asn1 modules. One is written in current > asn.1 and uses only imports from > modules that are also of that kind. This is the normative module. For > convenience of implementors that > do not dispose of tools that can handle current ASN.1, a module > using 88 syntax could be provided. > > The data structures which are imported are identical. They interoperate. > > > -- > To verify the signature, see http://edelpki.edelweb.fr/ > Cela vous permet de charger le certificat de l'autorité; > die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.
Description: S/MIME cryptographic signature