On Jul 7, 2011, at 6:56 PM, Bjoern Hoehrmann wrote: > * Cullen Jennings wrote: > >We are mandating UTF-8 as the charset which gives us the benefits would > >hope. We don't want to have multiple charsets supported as we have noted > >this reduces interoperability when some implementations don't bother to > >implement charsets other than UTF-8. It's arbitrary choice that > >increases what you need to implement and test, reduces interoperability, > >and provides not benefits to the end user beyond what they get with > >UTF-8. > > I am thinking about this situation: > > Content-Type: application/p2p-overlay+xml;charset=iso-8859-2 > > <?xml version='1.0' encoding='iso-8859-15'?> > ... > > and I am comparing it to this situation: > > Content-Type: application/xml;charset=iso-8859-2 > > <?xml version='1.0' encoding='iso-8859-15'?> > ... > > The question is how implementations determine the encoding. I am saying > there should be no difference between the two cases, so long as you use > the `+xml` convention and an `application` type. That would require to > either define a charset parameter, or remove the `+xml`. I do not care > whether some `application/p2p-overlay+xml` implementations only support > UTF-8, I just do not want this to be the same as: > > Content-Type: application/p2p-overlay+xml;dkjfashdkf=sdjhfaskdjfhas > > <?xml version='1.0' encoding='iso-8859-15'?> > ... > > namely, an unrecognized parameter with an unrecognized value.
We do use this in protocols that don't have a Content-Type header or place to cary the chartset but I see your point with not wanting to treat charset as an unknown parameter. Do you see any problem with saying, if there is a chartset parameter, it MUST be UTF-8? _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
