Billy Biggs wrote:
>
> Even if the remote end does not indicate that they accept text/plain,
> I'd send the message anyways. It's not like you're going to put a
> session description in a 400 response, You might as well give whatever
> aids you can to the poor person debugging the conversation.
>
> I wouldn't send text/html, but text/plain.....
I wouldn't send text/plain either. Accept headers are there for a
reason. If you can accept it, list it.
Anyway, my two cents on this whole discussion is that we must remember
*both* sides of the IETF design philosophy - "strict on send and liberal
on receive". The argument I am hearing is that liberal on receiving will
cultivate implementations that are also liberal on sending. But, if each
implementor is aiming at maximizing their own interoperability, that is
done by being both strict on send and liberal on receive. An
implementation which is liberal on sending because they think it will
work with implementations anyway cannot be certain of this, and things
will fail at an inopportune time (and be there fault) because of this
poor engineering judgement call. "strict on send and liberal on receive"
has the great advantage of maximizing both individual interoperability
(plus minimizing culpability) and overall protocol interoperability.
-Jonathan R.
--
Jonathan D. Rosenberg 72 Eagle Rock Ave.
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
[EMAIL PROTECTED] FAX: (732) 741-4778
http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244
http://www.dynamicsoft.com
