[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: IANA registration for Media Type 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]