Review for media types: application/ibe-pp-data, application/ibe-key-request+xml, and application/ibe-pkg-reply+xml

[Turner, Sean P.]

I'll certainly pass them to the editor.

spt 

>-----Original Message-----
>From: mark at coactus.com [mailto:mark at coactus.com] On Behalf Of 
>Mark Baker
>Sent: Wednesday, October 01, 2008 1:12 PM
>To: Chris Newman
>Cc: Turner, Sean P.; ietf-types at iana.org
>Subject: Re: Review for media types: application/ibe-pp-data, 
>application/ibe-key-request+xml, and application/ibe-pkg-reply+xml
>
>On Tue, Sep 30, 2008 at 10:57 PM, Chris Newman 
><Chris.Newman at sun.com> wrote:
>> --On September 29, 2008 15:31:20 -0400 Mark Baker 
><distobj at acm.org> wrote:
>>>
>>> - as an observation, the mandatory parameters for 
>>> application/ibe-key-request+xml and application/ibe-pkg-reply+xml 
>>> both seem to be message control data rather than representation 
>>> metadata, so this seems a misuse of the media type 
>framework.  Is it 
>>> too late to fix this?
>>
>> Mark,
>>
>> Can you go into more detail on what you think would fix this issue?
>
>It's not really germane to the media type registration, but 
>since you ask ...  Perhaps Sean could forward these comments to SMIME.
>
>The draft as a whole does a very poor job at using HTTP, 
>opting to use it as a transport protocol rather than a 
>transfer protocol.  For example, it mints new IBE-specific 
>error codes - including a "server error" code - and returns 
>those in HTTP 200 response messages.
>
>Regarding the use of the media type parameters, on 
>application/ibe-key-request+xml, they are defined as;
>
>"The required parameters are the
>  identity for which an IBE private key is being requested
>  and an object identifier that identifies which
>  cryptographic algorithm the key is being requested for."
>
>In other words, it identifies the logical target of the 
>request message, which, for HTTP, is supposed to be placed in 
>the Request-URI field of the HTTP envelope.  HTTP GET should 
>also be used to retrieve it, rather than HTTP POST which is 
>the only allowed method per the draft.
>
>I also notice that RFC 3205/BCP 56 isn't referenced.
>
>Mark.