OASIS XML Localisation Interchange File Format (XLIFF) TC

 View Only
  • 1.  IANA registration for Media Type application/xliff+xml

    Posted 04-07-2018 00:36
      |   view attached
    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: robin@oasis-open.org 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 (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

    Attachment(s)



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

    Posted 04-07-2018 18:53
    Great, thanks for the update!  On Apr 7, 2018 02:35, "Robin Cover" < robin@oasis-open.org > 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: robin@oasis-open.org 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