Subject: Re: [Slim] [slim] #19 (multilangcontent): Use Media Type registration template

From: Nik Tomkinson <[email-masked]>
Date: Thu, 8 Sep 2016 09:59:13 +0100

Is anyone able to help with this? If not, can someone suggest someone who
might?

Nik

On 30 August 2016 at 21:49, slim issue tracker <[email-masked]>
wrote:

> #19: Use Media Type registration template
>
>
> Comment (by [email-masked]):
>
>  Hi All,
>
>  I am working on this template but I need some advice from anyone who knows
>  this sort of this thing well and has experience in this area.
>
>  My initial suggestion would be:
>
>       Media Type name: multipart
>
>       Media subtype name: multilingual
>
>       Required parameters: boundary (defined in RFC2046)
>
>       Optional parameters: N/A
>
>       Encoding considerations: ?
>
>       Security considerations: See the Security Considerations section in
>  this document
>
>       Interoperability considerations:
>           Existing systems that do not treat unknown multipart subtypes
>           as multipart/mixed may not correctly render a
>           multipart/multilingual type.
>
>       Published specification: This document
>
>       Applications that use this media type:
>           Mail Transfer Agents, Mail User Agents, spam detection,
>           virus detection modules and message authentication modules.
>
>       Additional information:
>
>           Deprecated alias names for this type: N/A
>           Magic number(s): N/A
>           File extension(s): N/A
>           Macintosh file type code(s): N/A
>
>       Person & email address to contact for further information:
>           Nik Tomkinson
>           [email-masked]
>
>           Nathaniel Borenstein
>           [email-masked]
>
>       Intended usage: Common
>
>
>
>  But I am not sure about the encoding considerations because the IANA
>  'Application for a Media Type' form at http://www.iana.org/form/media-
>  types includes these options:
>   - 7-bit text
>   - 8-bit text (this media type may require encoding on transports not
>  capable of handling 8-bit text)
>   - binary (this media type may require encoding on transports not capable
>  of handling binary)
>
>  but it also refers to RFC 6838 §4.8
>  which lists:
>   - 7bit:  The content of the media type consists solely of CRLF-delimited
>  7bit US-ASCII text.
>   - 8bit:  The content of the media type consists solely of CRLF-delimited
>  8bit text.
>   - binary:  The content consists of an unrestricted sequence of octets.
>
>  I have seen from examples of other registered MIME types that the wording
>  is not always the same as above but, given that there is a registration
>  form with strict definitions, I am at a bit of a loss which I should
>  specify.
>
>  Can anyone offer a suggestion?
>
>  Thanks in advance,
>
>  Nik.
>
> --
> -------------------------------------+----------------------
> ---------------
>  Reporter:                           |       Owner:
>   [email-masked]        |  [email-masked]
>      Type:  enhancement              |      Status:  assigned
>  Priority:  major                    |   Milestone:
> Component:  multilangcontent         |     Version:
>  Severity:  In WG Last Call          |  Resolution:
>  Keywords:                           |
> -------------------------------------+----------------------
> ---------------
>
> Ticket URL: <https://trac.tools.ietf.org/wg/slim/trac/ticket/19#comment:3>
> slim <https://tools.ietf.org/slim/>
>
>

-- 

-----------------------------------------------------------------
Multiple Language Content Type Internet Draft:

<http://datatracker.ietf.org/doc/draft-tomkinson-multilangcontent/>
https://datatracker.ietf.org/doc/draft-ietf-slim-multilangcontent/
<http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/>

-----------------------------------------------------------------

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 9 Sep 2016 18:01:36 +0900

> Is anyone able to help with this? If not, can someone suggest someone who

Why don't you send it to [email-masked] ?

Regards,   Martin.

> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim
>

-- 
Martin J. Dürst
Department of Intelligent Information Technology
Collegue of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan

---

From: Nik Tomkinson <[email-masked]>
Date: Fri, 9 Sep 2016 13:44:19 +0100

Great suggestion. I didn't know that that list existed.

Email sent.

Nik.

--