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

Luther Martin martin at voltage.com
Fri Oct 3 20:52:27 CEST 2008


> -----Original Message-----
> From: mark at coactus.com [mailto:mark at coactus.com] On Behalf Of Mark
> Baker
> Sent: Friday, October 03, 2008 11:49 AM
> To: Luther Martin
> Cc: Chris Newman; Turner, Sean P.; ietf-types at iana.org;
> tim.polk at nist.gov
> Subject: Re: Review for media types: application/ibe-pp-data,
> application/ibe-key-request+xml, and application/ibe-pkg-reply+xml
>
> On Fri, Oct 3, 2008 at 2:18 PM, Luther Martin <martin at voltage.com>
> wrote:
> >> -----Original Message-----
> >> From: mark at coactus.com [mailto:mark at coactus.com] On Behalf Of Mark
> >> Baker
> >> > In the case of IBE, the public key is the identity, so the content
> of
> >> the proposed application/ibe-key-request is really just a subset of
> >> what's encoded with application/pkcs10. (It's not-self signed, etc.,
> >> but that's really a minor difference.)
> >> >
> >> > What's the fundamental difference between these two that warrants
> >> greatly different processing?
> >>
> >> It's the two mandatory media type parameters as described in sec
> 5.4,
> >> and (unmentioned until now) the mandatory parameter in 5.7.
> >
> > So if the mandatory parameter sections are deleted, then it would be
> OK? That's the way that the media types application/pkcs10 and
> application/pkcs7-mime are defined.
>
> Right.

No problem.

Communicating by e-mail just isn't as efficient as communicating in person, is it?


More information about the Ietf-types mailing list