RE: Last Call: Compressed Data Content Type for S/MIME to Proposed Standard

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

"Jim Schaad" <jimsch5@xxxxxxxx> writes:
 
>I have one minor comment.
>
>To be consistant with all of the other drafts coming out with
>SMimeCapability values, I would like to see the following text added to the
>end of Section 2.
>
>The SMIMECapability SEQUENCE representing the ability to process compressed
>content MUST be DER-encoded as the following hexadecimal string:
>       30 0D 06 0B 2A 86 48 86 F7 0D 01 09 10 01 09.
 
Someone else made that comment as well earlier on (or was it you, I can't 
remember?).  I can't imagine why you'd need that, it's a completely redundant 
comment, if you want to know how to DER encode something, see the DER.  By 
that logic every new standard would have to contain dozens (or in the case of 
something like son-of-2459, hundreds) of extra lines of text specifying the 
DER encoding of each element.  
 
Was there some historical reason why this was included originally and then 
everyone copied it without knowing why (I smell a vendor-specific bugfix/hack)?
 
Peter.