ietf-smime
[Top] [All Lists]

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).

        

<Prev in Thread] Current Thread [Next in Thread>