I don't know how to make editorial changes to the spec. So here's the thread from a year or so ago, suggesting that OP responses containing Key-Value Form encoding include a content-type header of application/x-openid-kvf rather than text/plain or whatever else OPs might arbitrarily choose.
-- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre On Fri, Jun 13, 2008 at 5:48 PM, Peter Williams <[email protected]>wrote: > Make an editorial change to a spec, and submit for formal consideration to > the spec list. Need be only 2 lines long, and the std iana declaration. > Nobody recalls emails. > > ________________________________ > From: Andrew Arnott <[email protected]> > Sent: Friday, June 13, 2008 5:45 PM > To: OpenID List <[email protected]> > Subject: Re: [OpenID] Content-Type for Key-Value Form response from OP > > Unless I hear any objection then, I'm going to code up my library to > respond with application/x-openid-kvf as the content-type for Key-Value Form > encoded messages. > > Thanks for the help coming up with this, Martin. > > Andrew Arnott > > On Wed, Jun 11, 2008 at 4:59 PM, Andrew Arnott <[email protected] > <mailto:[email protected]>> wrote: > (Forwarding to entire list since I hit Reply instead of Reply All). > > > Thanks, Martin. It sounds like application/x-kvf is better than text/kvf > then. Perhaps we can also be more descriptive then as say > "application/x-openid-kvf"? > > Andrew Arnott > > On Wed, Jun 11, 2008 at 1:48 PM, Martin Atkins <[email protected] > <mailto:[email protected]>> wrote: > 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 > [email protected]<mailto:[email protected]> > http://openid.net/mailman/listinfo/general > > > >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
