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

[Sean Turner <[e-mail]>]

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.

spt