headers
Bjoern Hoehrmann | 5 May 2012 22:10
Picon

Re: 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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bjoern Hoehrmann | 5 May 2012 22:12
Picon

Re: 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:bjoern <at> hoehrmann.de · http://bjoern.hoehrmann.de
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bjoern Hoehrmann | 5 May 2012 21:59
Picon

Re: 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:bjoern <at> hoehrmann.de · 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/
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin J. Dürst | 6 May 2012 08:20
Picon
Gravatar

Re: 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Magnus Westerlund | 9 May 2012 09:41
Picon
Favicon

Re: 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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Libbrecht | 10 May 2012 21:30
Favicon

Re: 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 à 19:12, Kazuyuki Ashimura a écrit :

> 
> Dear list,
> # sorry but resending because I used wrong address for my previous post.
> 
> 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 Media Type section of the EmotionML specification is available
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bjoern Hoehrmann | 11 May 2012 03:22
Picon

Re: 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bjoern Hoehrmann | 15 May 2012 04:56
Picon

Re: 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:bjoern <at> hoehrmann.de · 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/
Permalink | Reply | 0 comments |
headers
Vincent Roca | 22 May 2012 16:14
Picon
Picon
Favicon

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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bjoern Hoehrmann | 23 May 2012 03:14
Picon

Re: 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
(Continue reading)

Permalink | Reply | 1 comment |

Gmane