Re: [Slim] Resolution to Issue #19

[Nik Tomkinson <[e-mail]>]

Thanks Randall for that suggestion, I will post it to that group today with
those suggested changes.

Bernard, once I have some feedback from the media-types list, I can submit
a new draft and close the ticket.

Nik.

On 25 October 2016 at 19:44, Randall Gellens <[e-mail]>
wrote:

> Please see in-line below for my suggestions. Also, please send a request
> for review to the media-types list if you haven't already done so, and
> include the full text of the registration template.
>
> At 10:41 AM -0700 10/25/16, Bernard Aboba wrote:
>
>  Encoding considerations: ?
>>
>
> I'd suggest something such as:
>
> There are no encoding considerations for this multipart other than that of
> the embedded body parts. The embedded body parts (typically one text/plain
> plus one or more message/*) may contain ASCII or binary.
>
>
>>  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.
>>
>
> I suggest changing "may not" to "might not" or "might fail to" since the
> words "may not" are ambiguous in RFCs.
>
>
>>  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
>>  <mailto:[e-mail]>Ð[e-mail]
>>
>>  Nathaniel Borenstein  <mailto:[e-mail]>Ð[e-mail]
>>
>>  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/medi
>> a-types>Ð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 <http://tools.ietf.org/html/rfc6838>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.
>>
>>
>>  _______________________________________________
>>  SLIM mailing list
>>  [e-mail]
>>  https://www.ietf.org/mailman/listinfo/slim
>>
>
>
> --
> Randall Gellens
> Opinions are personal;    facts are suspect;    I speak for myself only
> -------------- Randomly selected tag: ---------------
> There is only one way to get rid of nuclear weapons -- use them.
>                                                --Rush Limbaugh
>



-- 

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

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