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

Mark Baker distobj at acm.org
Wed Oct 1 19:12:09 CEST 2008


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.


More information about the Ietf-types mailing list