Subject: [Slim] non-real-time: Translation-Type as parameter of Content-Language not a separate field

From: Nik Tomkinson <[email-masked]>
Date: Fri, 14 Aug 2015 10:05:47 +0100

Hi,

After a suggestion by Randy, I am thinking that the new Translation-Type
field that appears in each of the language message parts may be better
suited to being a parameter of the existing Content-Language field. There
are a number of reasons for this:

 - the Translation-Type field is coupled to the Content-Language field to
some extent because the Translation-Type value is only applicable where the
Content-Language value is also applicable
 - they both concern the language that a piece of the message content is in
so they are naturally related
 - there are no additional issues with having multiple languages combined
with multiple translation types than there were with two separate fields
 - I don't think that there will be any backwards compatibility issues with
existing implementations of Content-Language as it would be a new parameter

For example:

Content-Language: en; translation-type=original

instead of:

Content-Language: en
Translation-Type: original

So, does anyone have any compelling reason that I may have missed why this
is not a better solution? If not, I will adjust the I-D accordingly.

Thanks in advance,

Nik.

-- 

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

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

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