[OpenID] Content-Type for Key-Value Form response from OP

[Peter Williams]

Since openid has its own discovery protocol (leveraging iana registered mime types) we can stick with x- labels. We know from discovey what the application context is (openid auth protocol, yadis protocol, extension protocols, hxri url resolution). We don't need iana to give to context with a registered mime type for the wire protocol . One thus avoids being beholden to iana/ietf processes, and its security area directorate. The independence is worth it, at this stage of development of the movement: as ietf layer8 politics would eat openid alive. Like ssl, once mature and unavoidable, then let ietf bring its engineering process to bear, for the long term viability of the standard.

-----Original Message-----
From: Martin Atkins <mart at degeneration.co.uk>
Sent: Wednesday, June 11, 2008 1:48 PM
To: OpenID List <general at openid.net>
Subject: Re: [OpenID] Content-Type for Key-Value Form response from OP


Andrew Arnott wrote:
> In that case, I move that we adopt text/kvf as the official Content-Type
> for Key-Value Form encoding response messages.
>

Hi Andrew,

Sorry I didn't see your messages until now.

I believe the convention for unregistered MIME types is to prefix the
subtype part with "x-", giving something like text/x-kvf.

However, since the spec mandates UTF-8 for this message format, it may
be more appropriate to use an "application/" type; text types generally
support a "charset" attribute allowing the content to be in an arbitrary
character encoding, which is not appropriate here.

_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general