><snip> >> The main advantage is to get the RFC referenced on the >> S-MIME WG main page.
>If this is really the main advantage, talking with [EMAIL PROTECTED] >would be easier than publishing an RFC. I have difficulties to understand what you mean here. Currently all the documents that are referenced are only RFCs. ><snip> >> >At any rate, the document abstract and/or introduction should >> >briefly explain the relationship with ETSI, including who is >> >responsible for maintaining the spec, and the reasons for >> >publishing it in two document series. >> The current text has been reviewed by the lawyers from ETSI and >> an agreement was not that easy. :-( >> Any change would need to be resubmmited to the ETSI laywers. I did not explained myself sufficiently. I was not meaning the whole document, but only the following text : from the abstract: The contents of this Informational RFC amounts to a transposition of the ETSI TS 101 733 V.1.7.3 (CMS Advanced Electronic Signatures - CAdES) [TS101733] and is technically equivalent to it. and the following text from the Intellectual property section: ETSI takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ETSI Intellectual Property Rights Policy may be obtained from <http://www.etsi.org/legal/home.htm>. The document is an extract from Annex 6 of the ETSI Rules of Procedure that are available at : <http://portal.etsi.org/directives/home.asp>. The ETSI IPR database http://webapp.etsi.org/IPR/home.asp contains IPRs, particularly patents and patent applications, which have been notified to ETSI as being essential, or potentially essential, to ETSI standards. Unless otherwise specified, all IPRs contained herein have been notified to ETSI, with an undertaking from the owner to grant licenses according to the terms and conditions of Article 6.1 of Annex 6 of the ETSI Rules of the ETSI IPR Policy. The ETSI IPR database provides data that is based on the information received. ETSI has not checked the validity of the information, nor the relevance of the identified patents/patent applications to the ETSI Standards and cannot confirm, or deny, that the patents/patent applications are, in fact, essential, or potentially essential. No investigation, or IPR searches, have been carried out by ETSI and therefore no guarantee can be given concerning the existence of other IPRs which are, or may become, essential. Potential Licensees should use the information in this database at their discretion and should contact the patent holder. >Err... if it's not possible even to add a sentence saying >"This document is maintained by ETSI", why is this document >going through IETF last call? If the IETF community is asked >to comment the document, certainly changes should be possible. The ETSI TS is maintained by ETSI. We have no commitment to publish an RFC every time a new version from the TS is published. In fact we waited several versions before issuing a new RFC. To be positive, I would rather think that an additional sentence might be needed to say something like: "Further updates to the ETSI TS will be available at : http://www.etsi.org/services_products/freestandard/home.htm"; Not all of the comments will be accepted, since this document is on the Informational track rather than on Standard track. Errors ands lacks of explanations are certainly taken into consideration. ><snip> >> >4) The document slightly changes the section ordering/numbering >> >compared to the ETSI TS. I'd suggest keeping them exactly the >> >same to save work and hassle (or, at the very least, explicitly >> >giving the mapping between ETSI section numbers and section >> >numbers used here). >> This is unfortunately not possible because the RFC mandates >> some clauses in a certain order, while the ETSI TS does something >> different. >The RFC editor recommends a particular section ordering, but for >most sections, does not absolute require it. If there's a good >reason (and in this case, there is), I think there's some room >for keeping the section order identical to the ETSI TS. For the main body of the document, the text is perfectly aligned, I mean sections 3 to 8. Readers will not be lost between one text or the other. For sections 1 to 2, each document respects its own structure. Sections 9 and beyond only exist for the RFC document. The ETSI TS structure: Introduction 1 Scope 2 References up to section 8. The RFC structure: 1. Introduction 2. Scope (...) 9. Security considerations 9.1 Protection of private key 9.2 Choice of algorithms 10. IANA Considerations 11. References 11.1 Normative references 11.2 Informative references Regards, Denis >Best regards, >Pasi _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
