RE: draft-ietf-smime-3851bis-02 (notes, part 2)

["Turner, Sean P." <turners@xxxxxxxx>]

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@xxxxxxxxxxxx 
>[mailto:owner-ietf-smime@xxxxxxxxxxxx] On Behalf Of Turner, Sean P.
>Sent: Tuesday, June 03, 2008 3:42 PM
>To: ietf-smime@xxxxxxx
>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).
>