parameters and response format

[Mario Salzer]

Martin Atkins wrote:
> 
> ...but is text/* really the right thing to use? I'm no expert on this
> stuff, but isn't all of the stuff under text/* charset-sensitive?
> Suddenly we'll find ourselves having to support things like
> "text/x-openid; charset=windows-1251" for the encoding of error messages
> and other human-oriented fields.
> 
> Do we actually have anything in the spec about encodings, by the way? It
> seems to me that the spec should just mandate a particular encoding and
> have done with it, as otherwise every implementation will have to
> support a plethora of encodings.

You're right on the top-level type. It should obviously go into
application/ - but more because of the fact, that it does not contain
textual information. While sure text/ has always charset issues - this
doesn't count for the content in OpenID messages - they are ASCII-only
and wouldn't be hurt by encoding issues (if we for the moment ignore
multi-byte charsets like UTF-16).

My preference still lies with application/x-www-form-urlencoded, which
makes it unneccessary to invent something new here at all. It is pretty
standard and does what is needed.

If the spec somewhen gets more concrete, it should tell something about
ASCII or Latin-1, if at all.
On the other hand, URLs appear in the final hash and signature - so
elaborating about the representation there (UTF-8?) would be nice.