Hi David. Please see the communication below (received today) and the 30-day expectation formulated for a response to the IESG reviewer via the ticket system.
They offer to answer questions, if necessary ("If you have any questions, please don't hesitate to contact us.")
The IESG-designated expert has reviewed this request and returned the inline comments below. Please reply to this message within 30 days of 27 January with a revised version of the security considerations section and a response to the reviewer's question about encoding considerations.
If you have any questions, please don't hesitate to contact us.
IANA Request Specialist
> Name : Robin Cover
> MIME media type name : Application
> MIME subtype name : Standards Tree -xliff+xml
> Required parameters : N/A
> Optional parameters :
> Encoding considerations : 8bit
This implies the XML only uses charsets such as utf-8, and never utf-16. Are
you sure this is what you want? I don't see anything in the specification that
limits things to utf-8, although the examples are all in utf-8. If
utf-16 and similar charsets can be used this needs to change to binary.
> Security considerations :
> All of the security considerations described in RFC 7303
This isn't close to adequate. All RFC 7303 is describe the generic security
considerations for XML; you need to document those that are specific to this
type or explain why there aren't any.
In discussing the security considerations for a media type it is
necessary to cover at least these points:
(1) State whether or not the media type contains active or executable
content. If the media type does contain executable content explain
what measures have been taken to insure that it can be executed
safely, e.g. a sandbox, safe operation set, signed content, etc.
(2) State whether or not the information contained in the media type
needs privacy or integrity services.
(3) If the answer to (2) is yes, elaborate on any privacy or integrity
services the media type itself provides, or if it doesn't provide such
services, explain how they should be provided externally, e.g., through
the use of SSL/TLS.
I don't see anything about executable content in the specification, but this
needs to be written by someone who knows for sure. I also note that XML
vocabularies are sometimes extensible (I didn't see that anywhere but I could
have missed it) and if so that needs to be noted as a source of possible
I would expect there to be content of this sort that requires privacy or
integrity protection; it may or may not be appropriate to specify how that
would be provided (e.g., externally with SSL/TLS or internally with XML
> Interoperability considerations :
> Same as interoperability considerations described in RFC 7303; also,
> interoperability requirements are specified throughout the XLIFF specification
> and summarized in its Conformance section
> Published specification :
> (a) XLIFF Version 2.0 (OASIS Standard, 05 August 2014 -
> Applications which use this media :
> XLIFF conformant applications, according to the Conformance Section of the
> Fragment identifier considerations :
> Generic XML processors will not 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.
> Restrictions on usage :
> Provisional registration? (standards tree only) :
> 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
> Note with respect to field "5. Encoding considerations": The same as encoding considerations for application/xml as specified in RFC 7303
> Person to contact for further information :
> 1. Name : Robin Cover
> Intended usage : Common
> [No additional comment on "Intended usage"]