Subject: Re: [P2PSIP] [ietf-types] Registration of media type application/p2p-overlay+xml

From: Cullen Jennings <[email-masked]>
Date: Thu, 7 Jul 2011 18:22:47 -0600

On May 28, 2011, at 3:16 AM, Bjoern Hoehrmann wrote:

> * Cullen Jennings wrote:
> >   To:  [email-masked]
> >
> >   Subject:  Registration of media type application/p2p-overlay+xml
> 
> There is no reason to include this part in the specification.

fixed - thanks
 
> 
> >   Type name:  application
> >
> >   Subtype name:  p2p-overlay+xml
> >
> >   Required parameters:  none
> >
> >   Optional parameters:  none
> 
> Why are you using the +xml convention but do not specify the type in a
> manner consistent with application/xml?

I may have missed what part of 3023 part we violate but I read it and could not see anything. Clearly the desire was to support UTF-8 which we do. 

> Without a very good reason I'd
> think you should either add the "charset" parameter

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. 

> or drop the "+xml".

It is xml so it seems like it is useful to use the +xml convention so that systems that process that can use it. 

> 
> >   Encoding considerations:  Must be binary encoded.  The contents MUST
> >   be valid XML compliant with the relax NG grammar specified in RFC-
> >   AAAA and use the UTF-8[RFC3629] character encoding.
> 
> This should either just say "binary" or just reference RFC 3023 as RFC
> 3023 suggests.

Ok - removed this and moved it to additional info as it seems like useful information. 

> 
> >   Interoperability considerations:  Same as application/xml as defined
> >   in [RFC3023].
> 
> If there are no known interoperability issues beyond those of the type
> application/xml, that is what you should say; the considerations here
> are certainly not the same.
> --
> Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 08 Jul 2011 02:56:09 +0200

* 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.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 7 Jul 2011 20:04:48 -0600

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