RE: draft-ietf-smime-3851bis-02 (notes, part 2)
2008-06-18 08:25:40
For (0), it seems like it might be easiest to add an appendix that says v3.2
is backwards compatible (with the exception of some algorithms) to 2311/2312
and ask that 2311/2312 be moved to Historic. I'll move the references to
numbered sections and put the "move to historic" text in App B in 3851bis
and App A in 3850bis.
For (29), I'll modify Section 5 to register application/pkcs7-mime and
application/pkcs7-signature with some boiler plate that says we're just
updating the pointers in the IANA registry.
I'll post a new version of both IDs before the end of the week.
spt
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Turner,
Sean P.
Sent: Tuesday, June 03, 2008 3:42 PM
To: ietf-smime(_at_)imc(_dot_)org
Subject: RE: draft-ietf-smime-3851bis-02 (notes, part 2)
Alfred,
Thanks again for the review. Responses inline. In the version
I'm about to post I haven't addressed comment (0) or (29).
All,
Curious what others feel about (0) and (29).
spt
-----Original Message-----
(0) Front Matter / Standards Actions
The draft already indicates in its front matter:
Obsoletes: 3851
During supporting investigations, it became clear that, due
to specific
circumstances, this will let us end up with two "valid"
sets of S/MIME specifications -- those for S/MIME v3.2 and those for
S/MIME v2 !
The historic reason for this scenario seems to be buried in
the S/MIME
v2 specifications being published as Informational RFCs and not
expressly being Obsoleted by the S/MIME v3 RFCs.
In Section 1.3, this draft lists RFCs 2311 through 2315 as the
documents originally specifying S/MIME v2. In the RFC index, the
entries for all these RFCs list INFORMATIONAL status,
- RFC 2313 is tagged (Obsoleted by RFC2437),
- RFC 2314 is tagged (Obsoleted by RFC2986), but
- RFCs 2311, 2312, and 2315 look like being current.
Arguably, it would be a matter of CMS to take action for RFC
2315, but
at least RFC 2311 and RFC 2312 are clearly within scope of the S/MIME
v3.2 drafts.
I suggest to take the opportunity to clean up the RFC metadata and
either:
- also formally Obsolete the S/MIME v2 RFCs with the publication
of the corresponding intended S/MIME v3.2 RFCs,
(i.e. add RFC 2311 to the Obsoletes list of this draft,
add RFC 2312 to the Obsoletes list of [CERT32], and
defer action for RFC 2315 to CMS), or
- to explicitely declare the S/MIME v2 RFCs as Historic in
one place.
We should address this one coment (0) and (25) togther seperately.
(29) Section 5
Independent on the decision to be made regarding (0) above,
this section needs to be amended.
(29a) Scenario 1: RFC 2311 *not* Obsoleted / made HISTORIC
In this case, IANA should at least be directed to update the
media type registrations for
"application/pkcs7-mime"
and
"application/pkcs7-signature"
by adding an additional reference to [RFCTHIS], in order to
point the reader to the most current update of the media type
information.
On the other hand, updating an old media type's information
arguably could require updating the registration entirely,
using the new registration template from BCP 13, RFC 4288.
I leave it to the high priests of exegesis (or lawyers) to
figure out whether RFC 4288 in fact even normatively requests
to do so.
(29b) Scenario 2: RFC 2311 beinf Obsoleted or made HISTORIC
In this case, the draft should substantially be amended with
the two new media type registration templates, filled for both
media types, "application/pkcs7-mime" and
"application/pkcs7-signature", and IANA should be directed to
update the registrations to incorporate this new information.
Address this with (0).
|
|