Next in thread → Next in month →

Re: IANA registration for Media Type application/xliff+xml

From
David Filip <>
Date
2018-04-07T18:53:26+00:00
ID
CANjYC56UtwOmNe8vT7patN8z21Bqyfm6z1NUN+=
Thread
Re: IANA registration for Media Type application/xliff+xml
Great, thanks for the update! 

On Apr 7, 2018 02:35, "Robin Cover" <> wrote:
Hello David,

About an hour ago I received word from IANA (ICANN) that the IESG/IETF final review of the application for media type registration had now passed expert review, and was approved.  So it's published, per references below.  Thanks for your work supplying the technical content for the registration, and for your patience as we worked through the formal review process.

In a couple early versions of the application, your name (as spec lead editor) was included, but I was asked to remove that content.

The XLIFF spec itself at OS level is still referenced multiple times, by URI reference, where you are named as editor:

http://docs.oasis-open.org/xliff/xliff-core/v2.1/os/xliff-core-v2.1-os.html

Best wishes,

- Robin

-- 

Robin Cover
OASIS, Director of Information Services
Email: 
Staff bio: http://www.oasis-open.org/people/staff/robin-cover

=========== 

Media Types

https://www.iana.org/assignments/media-types/media-types.xhtml

xhtml+xml  application/xhtml+xml  [W3C][Robin_Berjon]

xliff+xml  application/xliff+xml  [OASIS][Robin_Cover]

xml        application/xml        [RFC7303]

Removed: Provisional Registration

Provisional Standard Media Type Registry

https://www.iana.org/assignments/provisional-standard-media-types/provisional-standard-media-types.xhtml

(now null, was:

application/xliff+xml OASIS [Robin_Cover]

Source now:

See: https://www.iana.org/assignments/media-types/application/xliff+xml

(registered 2018-04-06, last updated 2018-04-06)

Name: Robin Cover

Email: robin&oasis-open.org

Media type name: application

Media subtype name: xliff+xml

Required parameters: N/A

Optional parameters: N/A

Encoding considerations: binary

   Same as encoding considerations of application/xml as specified in 

   RFC 7303, Section 3 "Encoding Considerations"

Security considerations: XLIFF is a format used for localization and 

   translation of textual data, and as such does not itself include 

   facilities for executable content.

   Apart from all of the security considerations described in 

   RFC 7303 Section 10 ("Security Considerations"), XLIFF Version 2.0 

   and higher has the following Security considerations:

   Extensibility: XLIFF permits extensions. Hence it is possible 

   that application xliff+xml may describe content that has security 

   implications beyond those described here.

   Direct external reference mechanisms: An XLIFF document has a 

   number of attributes of the type URI or IRI, all of which may be 

   dereferenced and some of them should be dereferenced. Therefore, 

   the security issues of RFC 3987 Section 8 should be considered. 

   In addition, the contents of resources identified by file: URIs 

   can in some cases be accessed, processed and returned as results.

   More details can be found in the Detailed Security Considerations 

   section of the specification "A.1.1 Detailed Security 

   Considerations".

   http://docs.oasis-open.org/xliff/xliff-core/v2.1/os/xliff-core-v2.1-os.html#Detailed_Security_Considerations 

   The XLIFF format does not offer any internal mechanisms to provide 

   privacy, convey trust or verify the integrity of XLIFF documents. 

   If such features are needed varies from case to case. 

   Implementations that will process documents in cases where one or 

   more of these features are required need to implement that outside 

   of the XLIFF format. Transport privacy may for example be provided 

   by SSL/TLS. Storage privacy could be implemented by encrypting the 

   XLIFF content using XML encryption or some other appropriate 

   means. Likewise the trust and integrity checks could be 

   implemented using XML signatures or by some other technology that 

   is appropriate for the particular implementation.

Interoperability considerations: Same as interoperability 

   considerations described in RFC 7303

   Also, interoperability requirements are specified throughout the 

   specification and summarized in its Conformance Section.

   http://docs.oasis-open.org/xliff/xliff-core/v2.1/os/xliff-core-v2.1-os.html#Conformance

Published specification: XLIFF Version 2.1 (OASIS Standard, 

   13-February-2018) at 

   http://docs.oasis-open.org/xliff/xliff-core/v2.1/os/xliff-core-v2.1-os.html

Applications which use this media: XLIFF conformant applications, 

   according to the Conformance Section of the specification

   http://docs.oasis-open.org/xliff/xliff-core/v2.1/os/xliff-core-v2.1-os.html#Conformance

Fragment identifier considerations: Generic XML processors won't be 

   able to resolve XLIFF fragment identifiers, as the fragment 

   identification syntax is specific for XLIFF and has been defined 

   in its Fragment Identification section as of csd03/csprd03 of 

   XLIFF Version 2.0; 

   http://docs.oasis-open.org/xliff/xliff-core/v2.1/os/xliff-core-v2.1-os.html#fragid

Restrictions on usage:: N/A

Additional information:

   1. Deprecated alias names for this type: N/A

   2. Magic number(s): N/A

   3. File extension(s): xlf

   4. Macintosh file type code: "TEXT"

   5. Object Identifiers: N/A

General Comments: N/A

Person to contact for further information:

   1. Name: Robin Cover

   2. Email: robin&oasis-open.org

Intended usage: Common

Author/Change controller: OASIS
Next in thread → Next in month →