parameters and response format

[Martin Atkins]

Mario Salzer wrote:
> 
> If the :\n format is kept, then I'd like to see at least a saner
> MIME type used. "text/plain" is not only inappropriate for non-
> human readable data exchanges, but could also be broken up by
> proxies (to sanitize line lengths). A more descriptive type like
> "text/x-openid", "text/prs.fitzpatrick.openid" or "text/directory"
> would furthermore allow interested parties better protocol checking
> and signaling with HTTP error codes.
> 

I can read these responses. Last I checked I was a human.

I agree with your sentiment, though. A more meaningful type would also
allow recievers to easily distinguish between a successful response and
a response created by an intermediate proxy without attempting to parse
the rubbish that will certainly be in the body.

...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.

I normally, when making up MIME types like this, prefer to put them
under application/*. I don't really have any good reasons why, but my
first instinct would have been application/x-openid-message. There must
be a good reason why everyone else's unregistered types end up in
application/*, surely?