Re: [media-types] Update of MIME media type application/pkcs7-mime Registration

[Alexey Melnikov <[e-mail]>]

On 17/06/2013 21:42, Sean Turner wrote:
> On 6/15/13 5:34 AM, Sean Turner wrote:
>> On 6/14/13 6:05 AM, Alexey Melnikov wrote:
>>> On 13 Jun 2013, at 15:46, Sean Turner <[e-mail]> wrote:
>>>
>>>> On 6/13/13 10:25 AM, Sean Turner wrote:
>>>>> On 6/13/13 10:18 AM, Alexey Melnikov wrote:
>>>>>> On 13/06/2013 13:51, Sean Turner wrote:
>>>>>>> On 6/13/13 6:47 AM, Bjoern Hoehrmann wrote:
>>>>>>>> * Sean Turner wrote:
>>>>>>>>> The application/pkcs7-mime content type defines the optional
>>>>>>>>> "smime-
>>>>>>>>> type" parameter [RFC5751].  The smime-type parameter for
>>>>>>>>> Server-side
>>>>>>>>> Key Generation Response is server-generated-key.
>>>>>>>>>
>>>>>>>>> smime-type name: server-generated-key
>>>>>>>>>
>>>>>>>>> Required parameters: None
>>>>>>>>
>>>>>>>> This should be preceded by
>>>>>>>>
>>>>>>>>    Type name: application
>>>>>>>>
>>>>>>>>    Subtype name: pkcs7-mime
>>>>>>>>
>>>>>>>> If this is supposed to register the application/pkcs7-mime type.
>>>>>>>> But it
>>>>>>>> seems to me that using the media type registration template here
>>>>>>>> is not
>>>>>>>> correct, I would rather expect "Updates: 5751" and then simply
>>>>>>>> defining
>>>>>>>> the additional smime-type parameter, no need for the template.
>>>>>>>
>>>>>>> It's not registering application/pkcs7-mime is adding a 
>>>>>>> parameter. If
>>>>>>> I understand correctly, if we added "Updates: 5751 (once
>>>>>>> approved)" to
>>>>>>> the header we could just omit the template completely?  I'd argue
>>>>>>> that
>>>>>>> if we don't need the template that's great, but what's more 
>>>>>>> important
>>>>>>> is that people be able to find these subtypes and the way to do 
>>>>>>> that
>>>>>>> is to have them pointed to by the registry not the original 
>>>>>>> document.
>>>>>>> How about if we just omit the template and ask IANA to *also*
>>>>>>> point to
>>>>>>> this document from the application/pkcs7-mime registry?
>>>>>> Sounds sensible to me. (But also see my other email).
>>>>>
>>>>> Other email is about using +der and adding some generic 
>>>>> considerations
>>>>> about parsers.  I'll have to go check on the +der bit with some folks
>>>>> but the other suggestion seems very reasonable.
>>>>
>>>> I don't think we can put +der at the end of this because the others
>>>> don't include it.
>>>
>>> There is no backward compatibility issue here, so I don't understand
>>> your argument.
>>> The +suffix convention is a relatively new, but I think it should e
>>> used for all new registrations that match existing suffixes.
>>
>> So it'd look like this:
>>
>> Content-Type: application/pkcs7-mime+der;
>> smime-type=server-generated-key; name=smime.p7m
>>
>> I'm not sure this will work though.  The certs are definitly use DER and
>> so would any signed attributes but the rest of need not be.
>
> The more I think about adding +ber to the media type for this request 
> the more it doesn't make sense to me.  This is not defining a new 
> top-level media type nor a new sub-type it's defining a new optional 
> parameter.  This might have not been clear now that I look back at the 
> form:
>
> OLD:
>
>   smime-type name: server-generated-key
>
>   Required parameters: None
>
>   Optional parameters: None
>
> NEW:
>
>   Required parameters: None
>
>   Optional parameters: smime-type name: server-generated-key
>
> Adding +ber to application/pkcs7-mime doesn't seem to make sense to me 
> because it would be retro actively changing a widely supported media 
> type.  The other thing would be to use +ber but only when this 
> optional parameter appeared and that also seems a bit odd to me.

One (or both) of us got confused. Of course it doesn't make sense to 
change existing MIME type. I was recommending use of +ber suffix for new 
MIME type registrations.