Subject: Re: [ietf-types] [payload] Video media-types insufficient?
From: Magnus Westerlund <[email-masked]>
To: Roni Even <[email-masked]>
Cc: 'IANA Media types' <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 28 May 2012 08:43:19 +0200
List-Id: "Media \(MIME\) type review" <ietf-types.ietf.org>

Hi,

Roni, if I understand correctly this is about the ISO based mp4 file
format and not the RTP payload format. Thus not really a question for
the Payload WG.

My question to Paul, does you and the browser use the codecs and
profiles parameter that are defined for this type. Please see
http://www.rfc-editor.org/rfc/rfc6381.txt

That is intended to more detailed express which profiles and codecs that
are included in the media type.

Cheers

Magnus

On 2012-05-26 11:53, Roni Even wrote:
> Hi,
> I think this should be discussed in payload WG
> Roni Even
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> On Behalf Of Paul Libbrecht
>> Sent: Saturday, May 26, 2012 11:28 AM
>> To: IANA Media types
>> Subject: [ietf-types] Video media-types insufficient?
>>
>>
>> hello dear Media-types' expert,
>>
>> the other day, I played with the nifty new video element of HTML5 which
>> seems to be fairly well implemented. This element allows a list of
>> sources together with their media-type so that the browser can find the
>> "video format" that it can play.
>> This element is perfectly following the idea of a media-type's
>> characterization of an exploitable format.
>>
>> However, this characterization is insufficient: the same media-type for
>> videos can be encode data in multiple codecs and these are not encoded
>> in media-types:
>>
>> I met this while using the video/mp4 media-type and realized that our
>> default encoding, the mpeg4 codec, did not play in iPad.
>> So I used the same video element, with a src of media-type pointing to
>> an mp4 file that uses the h264 codec. This one plays on iPad.
>>
>> To me, this is a clear failure of the media-type video/mp4: it does not
>> express sufficiently the playability on a device.
>>
>> Is this something well known?
>> Are there maybe media-type parameters that could help?
>> Are newer video media-types better on this respect?
>>
>> thanks in advance
>>
>> Paul
>> _______________________________________________
>> ietf-types mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ietf-types
> 
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload
> 
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

From: "Roni Even" <[email-masked]>
To: "'Paul Libbrecht'" <[email-masked]>, <[email-masked]>
Date: Sat, 26 May 2012 12:53:14 +0300
Cc: 'IANA Media types' <[email-masked]>
Subject: Re: [ietf-types] Video media-types insufficient?

Hi,
I think this should be discussed in payload WG
Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Paul Libbrecht
> Sent: Saturday, May 26, 2012 11:28 AM
> To: IANA Media types
> Subject: [ietf-types] Video media-types insufficient?
> 
> 
> hello dear Media-types' expert,
> 
> the other day, I played with the nifty new video element of HTML5 which
> seems to be fairly well implemented. This element allows a list of
> sources together with their media-type so that the browser can find the
> "video format" that it can play.
> This element is perfectly following the idea of a media-type's
> characterization of an exploitable format.
> 
> However, this characterization is insufficient: the same media-type for
> videos can be encode data in multiple codecs and these are not encoded
> in media-types:
> 
> I met this while using the video/mp4 media-type and realized that our
> default encoding, the mpeg4 codec, did not play in iPad.
> So I used the same video element, with a src of media-type pointing to
> an mp4 file that uses the h264 codec. This one plays on iPad.
> 
> To me, this is a clear failure of the media-type video/mp4: it does not
> express sufficiently the playability on a device.
> 
> Is this something well known?
> Are there maybe media-type parameters that could help?
> Are newer video media-types better on this respect?
> 
> thanks in advance
> 
> Paul
> _______________________________________________
> ietf-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-types

From: Paul Libbrecht <[email-masked]>
Date: Sat, 26 May 2012 10:27:39 +0200
To: IANA Media types <[email-masked]>
Subject: [ietf-types] Video media-types insufficient?

hello dear Media-types' expert,

the other day, I played with the nifty new video element of HTML5 which =
seems to be fairly well implemented. This element allows a list of =
sources together with their media-type so that the browser can find the =
"video format" that it can play.
This element is perfectly following the idea of a media-type's =
characterization of an exploitable format.

However, this characterization is insufficient: the same media-type for =
videos can be encode data in multiple codecs and these are not encoded =
in media-types:

I met this while using the video/mp4 media-type and realized that our =
default encoding, the mpeg4 codec, did not play in iPad.
So I used the same video element, with a src of media-type pointing to =
an mp4 file that uses the h264 codec. This one plays on iPad.

To me, this is a clear failure of the media-type video/mp4: it does not =
express sufficiently the playability on a device.

Is this something well known?
Are there maybe media-type parameters that could help?
Are newer video media-types better on this respect?

thanks in advance

Paul=

From: Bjoern Hoehrmann <[email-masked]>
To: [email-masked]
Date: Fri, 25 May 2012 04:10:51 +0200
Subject: [ietf-types] Updating registrations (was: Re: minutes, 24 May 2012 SVG WG telcon)

* Nikos Andronikos wrote:
>Removal of the Media Type Registration chapter from SVG 2
>
>   CM: I thought that because we have the media type registered
>   now that we don't need the chapter
>   ... I asked Chris
>   ... He thinks we don't
>   ... unless there are objections, I'll remove it
>   ... it existed in the spec so the registry could point to
>   something
>   ... the media type won't mean anything difference between SVG 1
>   and SVG 2. not neccessary to resubmit

W3C's http://lists.w3.org/Archives/Public/www-svg/2012May/0084.html SVG
Working Group registered image/svg+xml some time ago and is revising the
underlying format, and as above there is proposal that the specification
defining the new version does not include the registration template, and
I assume not "resubmitting" means it is also being proposed that there
will be no attempts to update the registration information on file. FYI.
-- 
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: Vincent Roca <[email-masked]>
Date: Wed, 23 May 2012 16:19:13 +0200
To: Bjoern Hoehrmann <[email-masked]>
Cc: [email-masked], [email-masked], Vincent Roca <[email-masked]>, [email-masked]
Subject: Re: [ietf-types] Registration of media type application/fdt+xml

Hello Bjoern,

Thanks a lot for your highly valuable comments! My answers and proposal
are below.

>> The FLUTE-revised I-D =
(http://tools.ietf.org/html/ietf-rmt-flute-revised-14),
>> currently under IESG review, defines in section 8.2 the =
application/fdt+xml
>> Media-Type. Comments on this registration would be greatly =
appreciated.
>=20
>>  Optional parameters: none
>=20
> There should be a rationale for omitting the 'charset' parameter while
> also using the "+xml" convention. The idea of the convention is that =
you
> can process all "+xml" "the same", but if some "+xml" types have a =
char-
> set parameter while others do not, applications would handle, say,
>=20
>  Content-Type: application/fdt+xml;charset=3Dwindows-1252
>=20
> differently, depending on whether they assume it would have a charset
> parameter.

If I understand the various documents, this is where we need to say that
we expect UTF-8. I've kept is as an optional parameter. Is that =
appropriate?

>>  Encoding considerations: The fdt+xml type consists of UTF-8 ASCII
>>  characters [RFC3629] and must be well-formed XML.
>=20
> This should use the text in RFC 3023 section 7.1 or specify one of the
> values in RFC 4288 ('binary', '8bit', etc.)

If I understand, here we can say that we expect any kind of encoding =
(i.e.
binary), since FLUTE, as a communication protocol, does not make any
restriction on the data it sends.

>>  Restrictions on usage: Only for usage with FDT Instances which are
>>  valid according to the XML schema of section 3.4.2.
>=20
> This seems to be redundant and possibly misleading, considering that
> similar registrations do not tend to have such text.

Removed.

>>  Applications which use this media type: Not restricted to any
>>  particular application.  Any application, FLUTE included, that sends
>>  an object that consists of an FDT Instance can use this media type.
>=20
> This should say something like "spreadsheet applications", "3D =
modeling
> programs", "bitmap image processors", or whatever, capturing the =
general
> type of application where this is used.

Done.

>>  Additional information:
>>=20
>>      Magic number(s): none
>>      File extension(s): An FDT Instance may use the extension ".fdt"
>>                         but this is not required.
>=20
> I would make that simply ".fdt", but don't mind the extra text.

I have simplified.

>>  Person and email address to contact for further information: Toni
>>  Paila (toni.paila (at) nokia.com)
>=20
> This is typically rendered `Toni Paila <[email-masked]>`. Note
> that address harvesters handle obfuscations like this quite well, and
> all it takes is one of them getting it right since address lists are
> shared and cheap.

You're right especially as the full email address is already in the =
document.

To summarize, here is the new version:

NEW:

8.3.  Registration of the application/fdt+xml Media-Type

   IANA is asked to register a new namespace in the IETF XML Registry
   (http://www.iana.org/assignments/xml-registry/ns.html) [RFC3688],
   using the following registration template:

   Type name: application

   Subtype name: fdt+xml

   Required parameters: none

   Optional parameters: charset=3D"utf-8"

   Encoding considerations: binary (the FLUTE file delivery procol
   does not impose any restriction on the objects it carries and in
   particular on the FDT Instance itself)

   Restrictions on usage: none

   Security considerations: fdt+xml data is passive, and does not
   generally represent a unique or new security threat.  However, there
   is some risk in sharing any kind of data, in that unintentional
   information may be exposed, and that risk applies to fdt+xml data as
   well.

   Interoperability considerations: None

   Published specification: The present document including section
   3.4.2.  The specified FDT Instance functions as an actual media
   format of use to the general Internet community and thus media type
   registration under the Standards Tree is appropriate to maximize
   interoperability.

   Applications which use this media type: file and object delivery
   applications and protocols (e.g., FLUTE).

   Additional information:

       Magic number(s): none
       File extension(s): ".fdt" (e.g., if there is a need to store an
                          FDT Instance as a file);
       Macintosh File Type Code(s): none

   Person and email address to contact for further information: Toni
   Paila ([email-masked])

   Intended usage: Common

   Author/Change controller: IETF

Cheers,

   Vincent=

From: Bjoern Hoehrmann <[email-masked]>
To: Vincent Roca <[email-masked]>
Date: Wed, 23 May 2012 03:14:56 +0200
Cc: [email-masked], [email-masked], [email-masked], Vincent Roca <[email-masked]>
Subject: Re: [ietf-types] Registration of media type application/fdt+xml

* Vincent Roca wrote:
>The FLUTE-revised I-D (http://tools.ietf.org/html/ietf-rmt-flute-revised-14),
>currently under IESG review, defines in section 8.2 the application/fdt+xml
>Media-Type. Comments on this registration would be greatly appreciated.

>   Optional parameters: none

There should be a rationale for omitting the 'charset' parameter while
also using the "+xml" convention. The idea of the convention is that you
can process all "+xml" "the same", but if some "+xml" types have a char-
set parameter while others do not, applications would handle, say,

  Content-Type: application/fdt+xml;charset=windows-1252

differently, depending on whether they assume it would have a charset
parameter.

>   Encoding considerations: The fdt+xml type consists of UTF-8 ASCII
>   characters [RFC3629] and must be well-formed XML.

This should use the text in RFC 3023 section 7.1 or specify one of the
values in RFC 4288 ('binary', '8bit', etc.)

>   Restrictions on usage: Only for usage with FDT Instances which are
>   valid according to the XML schema of section 3.4.2.

This seems to be redundant and possibly misleading, considering that
similar registrations do not tend to have such text.

>   Applications which use this media type: Not restricted to any
>   particular application.  Any application, FLUTE included, that sends
>   an object that consists of an FDT Instance can use this media type.

This should say something like "spreadsheet applications", "3D modeling
programs", "bitmap image processors", or whatever, capturing the general
type of application where this is used.

>   Additional information:
>
>       Magic number(s): none
>       File extension(s): An FDT Instance may use the extension ".fdt"
>                          but this is not required.

I would make that simply ".fdt", but don't mind the extra text.

>   Person and email address to contact for further information: Toni
>   Paila (toni.paila (at) nokia.com)

This is typically rendered `Toni Paila <[email-masked]>`. Note
that address harvesters handle obfuscations like this quite well, and
all it takes is one of them getting it right since address lists are
shared and cheap.
-- 
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: Vincent Roca <[email-masked]>
Date: Tue, 22 May 2012 16:14:02 +0200
To: [email-masked]
Cc: [email-masked], [email-masked], Vincent Roca <[email-masked]>
Subject: [ietf-types] Registration of media type application/fdt+xml

Hello,

The FLUTE-revised I-D (http://tools.ietf.org/html/ietf-rmt-flute-revised-14),
currently under IESG review, defines in section 8.2 the application/fdt+xml
Media-Type. Comments on this registration would be greatly appreciated.

Thanks!
Cheers,

   Vincent

---

   Type name: application

   Subtype name: fdt+xml

   Required parameters: none

   Optional parameters: none

   Encoding considerations: The fdt+xml type consists of UTF-8 ASCII
   characters [RFC3629] and must be well-formed XML.

   Additional content and transfer encodings may be used with fdt+xml
   files, with the appropriate encoding for any specific file being
   entirely dependent upon the deployed application.

   Restrictions on usage: Only for usage with FDT Instances which are
   valid according to the XML schema of section 3.4.2.

   Security considerations: fdt+xml data is passive, and does not
   generally represent a unique or new security threat.  However, there
   is some risk in sharing any kind of data, in that unintentional
   information may be exposed, and that risk applies to fdt+xml data as
   well.

   Interoperability considerations: None

   Published specification: The present document including section
   3.4.2.  The specified FDT Instance functions as an actual media
   format of use to the general Internet community and thus media type
   registration under the Standards Tree is appropriate to maximize
   interoperability.

   Applications which use this media type: Not restricted to any
   particular application.  Any application, FLUTE included, that sends
   an object that consists of an FDT Instance can use this media type.

   Additional information:

       Magic number(s): none
       File extension(s): An FDT Instance may use the extension ".fdt"
                          but this is not required.
       Macintosh File Type Code(s): none

   Person and email address to contact for further information: Toni
   Paila (toni.paila (at) nokia.com)

   Intended usage: Common

   Author/Change controller: IETF

From: Bjoern Hoehrmann <[email-masked]>
To: [email-masked]
Date: Tue, 15 May 2012 04:56:17 +0200
Subject: Re: [ietf-types] Protocol Action: 'Update to MIME regarding Charset Parameter Handling in Textual Media Types' to Proposed Standard (draft-ietf-appsawg-mime-default-charset-04.txt)

* The IESG wrote:
>The IESG has approved the following document:
>- 'Update to MIME regarding Charset Parameter Handling in Textual Media
>   Types'
>  (draft-ietf-appsawg-mime-default-charset-04.txt) as Proposed Standard
>
>This document is the product of the Applications Area Working Group.
>
>The IESG contact persons are Barry Leiba and Pete Resnick.
>
>A URL of this Internet Draft is:
>http://datatracker.ietf.org/doc/draft-ietf-appsawg-mime-default-charset/

FYI.
-- 
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]>
To: Kazuyuki Ashimura <[email-masked]>
Date: Fri, 11 May 2012 03:22:10 +0200
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-types] Request for review of EmotionML media type: application/emotionml+xml

* Kazuyuki Ashimura wrote:
>W3C has just published a Candidate Recommendation for "Emotion Markup
>Language (EmotionML)" at:
>
>  http://www.w3.org/TR/2012/CR-emotionml-20120510/
>
>I am sending this request to ask the Ietf-types list for comments on
>the Media Type section of the EmotionML specification following the
>procedure defined at:
>
>  http://www.w3.org/2002/06/registering-mediatype

The procedure requires Working Groups to ask for ietf-types review when
making a Last Call announcement. I have not been able to find any such
request in the archive. If the Working Group failed to follow the pro-
cedure, it would be helpful if you could put that on the record.

>MIME media type name:
>---------------------
>     application

This is using an outdated template. The current one is in RFC 4288. In
it, some field names are different and some fields are organized in a
different manner.

>Optional parameters:
>--------------------
>     charset
>
>         This parameter has identical semantics to the charset parameter 
>of the application/xml media type as specified in [RFC3023] or its 
>successor.
>
>Encoding considerations:
>------------------------
>     By virtue of EmotionML content being XML, it has the same 
>considerations when sent as "application/emotionml+xml" as does XML. See 
>RFC 3023 (or its successor), section 3.2.

RFC 3023 has boilerplate for this, but the above seems close enough.
-- 
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: Paul Libbrecht <[email-masked]>
Date: Thu, 10 May 2012 21:30:56 +0200
To: Kazuyuki Ashimura <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-types] Request for review of EmotionML media type: application/emotionml+xml

Dear Kazuyuki,

would you think as conceivable to put EmotionML into a clipboard?
If yes it would be nice to include in this specification:
- a Windows clipboard name (more or less, just a string) which =
applications would register at start
- a Macintosh Uniform Type Identifier (which application descriptors =
could register)

thanks in advance

Paul

Le 10 mai 2012 =E0 19:12, Kazuyuki Ashimura a =E9crit :

>=20
> Dear list,
> # sorry but resending because I used wrong address for my previous =
post.
>=20
> W3C has just published a Candidate Recommendation for "Emotion Markup
> Language (EmotionML)" at:
>=20
> http://www.w3.org/TR/2012/CR-emotionml-20120510/
>=20
> I am sending this request to ask the Ietf-types list for comments on
> the Media Type section of the EmotionML specification following the
> procedure defined at:
>=20
> http://www.w3.org/2002/06/registering-mediatype
>=20
> ---
> The Media Type section of the EmotionML specification is available
> at:
>=20
> http://www.w3.org/TR/2012/CR-emotionml-20120510/#MIME-type
>=20
> and a plain text copy is also available below.
>=20
> MIME media type name:
> ---------------------
>    application
>=20
> MIME subtype name:
> ------------------
>    emotionml+xml
>=20
> Required parameters:
> --------------------
>    None.
>=20
> Optional parameters:
> --------------------
>    charset
>=20
>        This parameter has identical semantics to the charset parameter =
of the application/xml media type as specified in [RFC3023] or its =
successor.
>=20
> Encoding considerations:
> ------------------------
>    By virtue of EmotionML content being XML, it has the same =
considerations when sent as "application/emotionml+xml" as does XML. See =
RFC 3023 (or its successor), section 3.2.
>=20
> Security considerations:
> ------------------------
>    EmotionML elements may include arbitrary URIs. Therefore the =
security issues of [RFC3986], section 7, should be considered.
>=20
>    In addition, because of the extensibility features for EmotionML, =
it is possible that "application/emotionml+xml" will describe content =
that has security implications beyond those described here. However, if =
the processor follows only the normative semantics of this =
specification, this content will be ignored. Only in the case where the =
processor recognizes and processes the additional content, or where =
further processing of that content is dispatched to other processors, =
would security issues potentially arise. And in that case, they would =
fall outside the domain of this registration document.
>=20
> Interoperability considerations:
> --------------------------------
>    This specification describes processing semantics that dictate the =
required behavior for dealing with, among other things, unrecognized =
elements.
>=20
>    Because EmotionML is extensible, conformant =
"application/emotionml+xml" processors MAY expect that content received =
is well-formed XML, but processors SHOULD NOT assume that the content is =
valid EmotionML or expect to recognize all of the elements and =
attributes in the document.
>=20
> Published specification:
> ------------------------
>    This media type registration is extracted from Appendix B of the =
"Emotion Markup Language (EmotionML) 1.0" specification.
>=20
> Additional information:
> -----------------------
>    Magic number(s):
>=20
>        There is no single initial octet sequence that is always =
present in EmotionML documents.
>=20
>    File extension(s):
>=20
>        EmotionML documents are most often identified with the =
extensions ".emotionml".
>=20
>    Macintosh File Type Code(s):
>=20
>        TEXT
>=20
> Person & email address to contact for further information:
> ----------------------------------------------------------
>    Kazuyuki Ashimura, <[email-masked]>.
>=20
> Intended usage:
> ---------------
>    COMMON
>=20
> Author/Change controller:
> -------------------------
>    The EmotionML specification is a work product of the World Wide Web =
Consortium's Multimodal Interaction Working Group. The W3C has change =
control over these specifications.
>=20
>=20
> ----------------------
> Normative References:
> ----------------------
>=20
> RFC 3023
> XML Media Types, M. Murata et al., Editors. IETF RFC 3023, January =
2001.
>=20
> Sincerely,
>=20
> Kazuyuki
>=20
> --=20
> Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice
> Tel: +81 466 49 1170
>=20
>=20

Date: Wed, 9 May 2012 09:41:56 +0200
From: Magnus Westerlund <[email-masked]>
To: Bjoern Hoehrmann <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [ietf-types] Review of text/parameters

Thanks for the review.

On 2012-05-05 21:59, Bjoern Hoehrmann wrote:
> * Magnus Westerlund wrote:
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/
> 
>> 22.16.  Media Type Registration for text/parameters
>>
>>   Type name:  text
>>
>>   Subtype name:  parameters
>>
>>   Required parameters:
>>
>>   Optional parameters:
> 
> Well, text types usually have a 'charset' parameter, and applications
> are known to treat, say, a HTTP response with
> 
>   Content-Type: text/parameters;charset=iso-8859-1
> 
> As ISO-8859-1 encoded document, even though I gather they are to use
> UTF-8 to decode the document. If you don't want a 'charset' parameter,
> this problem should be noted in the Security or Interoperability con-
> siderations.

Yes, you are correct. I guess having the charset being applicable to the
values of the parameters would be very reasonable. The parameters
themselves are in this format restricted to visible 7-bit US-ASCII
characters.

> 
>>   Encoding considerations:
> 
> This field needs a value (probably "8bit" or "binary").

That would be 8bit if I interpret that definition correctly. This will
only contain UTF8 text.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

Date: Sun, 06 May 2012 15:20:47 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <[email-masked]>
Organization: Aoyama Gakuin University
To: Bjoern Hoehrmann <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-types] Request for review of N-Triples (an RDF	serialization) media type: application/n-triples

On 2012/05/06 5:10, Bjoern Hoehrmann wrote:
> * Eric Prud'hommeaux wrote:
>> Type name:
>>     application
>> Subtype name:
>>     n-triples
>> Required parameters:
>>     None
>> Optional parameters:
>>     None
>> Encoding considerations:
>>     The syntax of N-Triples is expressed over code points in Unicode [UNICODE]. The encoding is always UTF-8 [UTF-8].
>>     Unicode code points may also be expressed using an \uXXXX (U+0 to U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a hexadecimal digit [0-9A-F]
>
> This is supposed to simply say something like "8bit" or "binary", see
> RFC 4288 for details.

I think it's actually very good to say that N-Triples are always in 
UTF-8 somewhere in the template. This could stay here, changing it e.g.
as follows:

The character encoding is always UTF-8. This media type therefore has to 
be transported as "8bit", or futher encoded for "7bit" transport.

>> Security considerations:
>
> I have not look at these, but since this is very long, it might make
> more sense to have this as part of the Security Considerations section
> of the document that defines the format, and simply put a reference
> into the template.
>
>> Published specification:
>>     This specification.
>
> As I recall it, unlike for RFC registrations, IANA would put this in
> a document on their site, so this should give a full(er) citation.

Yes, please make the registration template self-contained, even if that 
might look a bit like overkill when it's looked at in the spec.

Regards,   Martin.

> If you want to say anything about fragment identifiers, like what the
> `#example` in `http://example.org/example.nt#example` refers to, or
> if you want to discourage such usage, that should be included. Not a
> requirement currently, but since this is an RDF type, this might be
> relevant.

From: Bjoern Hoehrmann <[email-masked]>
To: Magnus Westerlund <[email-masked]>
Date: Sat, 05 May 2012 21:59:18 +0200
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [ietf-types] Review of text/parameters

* Magnus Westerlund wrote:
>https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/

>22.16.  Media Type Registration for text/parameters
>
>   Type name:  text
>
>   Subtype name:  parameters
>
>   Required parameters:
>
>   Optional parameters:

Well, text types usually have a 'charset' parameter, and applications
are known to treat, say, a HTTP response with

  Content-Type: text/parameters;charset=iso-8859-1

As ISO-8859-1 encoded document, even though I gather they are to use
UTF-8 to decode the document. If you don't want a 'charset' parameter,
this problem should be noted in the Security or Interoperability con-
siderations.

>   Encoding considerations:

This field needs a value (probably "8bit" or "binary").
-- 
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]>
To: Shida Schubert <[email-masked]>
Date: Sat, 05 May 2012 22:12:30 +0200
Cc: [email-masked]
Subject: Re: [ietf-types] Review of application/call-completion registration

* Shida Schubert wrote:
> The draft below registers the following new media type:
>application/call-completion. Your comments on this registration are
>appreciated.
>
>Thanks & Regards
>  Shida Schubert
>
>http://tools.ietf.org/html/draft-ietf-bliss-call-completion-14
>
>  * RFCXXXX refers to the draft above.
>
>   MIME media type name: application
>
>   MIME subtype name: call-completion

This is using an outdated template, the current one is in RFC 4288. Some
of the field names are different and differently organized there.

>   Required parameters: none.
>
>   Optional parameters: none.
>
>   Encoding considerations: Consists of lines of UTF-8-encoded
>   characters, ended with CR-LF

Then this should simply say "8bit" or "binary", see RFC 4288 for the de-
finitions.
-- 
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]>
To: Eric Prud'hommeaux <[email-masked]>
Date: Sat, 05 May 2012 22:10:45 +0200
Cc: [email-masked]
Subject: Re: [ietf-types] Request for review of N-Triples (an RDF serialization) media type: application/n-triples

* Eric Prud'hommeaux wrote:
>Type name:
>    application
>Subtype name:
>    n-triples
>Required parameters:
>    None
>Optional parameters:
>    None
>Encoding considerations:
>    The syntax of N-Triples is expressed over code points in Unicode [UNICODE]. The encoding is always UTF-8 [UTF-8].
>    Unicode code points may also be expressed using an \uXXXX (U+0 to U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a hexadecimal digit [0-9A-F]

This is supposed to simply say something like "8bit" or "binary", see
RFC 4288 for details.

>Security considerations:

I have not look at these, but since this is very long, it might make
more sense to have this as part of the Security Considerations section
of the document that defines the format, and simply put a reference
into the template.

>Published specification:
>    This specification.

As I recall it, unlike for RFC registrations, IANA would put this in
a document on their site, so this should give a full(er) citation.

If you want to say anything about fragment identifiers, like what the
`#example` in `http://example.org/example.nt#example` refers to, or
if you want to discourage such usage, that should be included. Not a
requirement currently, but since this is an RDF type, this might be
relevant.
-- 
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/