Re: [media-types] Potential media type registration for OASIS XLIFF 2.0

["Martin J. Dürst" <[e-mail]>]

Hello David,

Your registration template starts:

 >     Type name: application
 > [not text, because end users do not like markup]
 >
 >     Subtype name: xml

This would give an overall type of application/xml. This is already 
registered, and any XML can be labeled as such, without any registration.

If you want an XLIFF-specific registration, you should register a type
such as application/xliff+xml, i.e. the Subtype name should be xliff+xml.

I haven't checked the other items in your template, because I think it's 
best to first check the general intent.

Regards,   Martin.


On 2014/01/17 5:27, Dr. David Filip wrote:
> Hello Reviewers,
>
>
> as Secretary of the OASIS XLIFF TC
> https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xliff
>
> I have been mandated by the said TC and OASIS TC administration to run by
> this list our provisionally completed media type registration template.
>
> All comments in square brackets are not meant as part of the future
> submission but rather as explanattory notes for the reviewers within OASIS
> and on this list.
>
> XLIFF TC is looking forward to receiving your feedback
>
> See the filled out template copy-pasted down below:
>
> Best regards
> dF
>
>
>
> Dr. David Filip
> =======================
> LRC | CNGL | LT-Web | CSIS
> University of Limerick, Ireland
> telephone: [phone]
> *cellphone: [phone]*
> facsimile: [phone]
> http://www.cngl.ie/profile/?i=452
> mailto: [e-mail]
>
>
> ----start of the registration form
>
> Registration Template
>
>     Type name: application
> [not text, because end users do not like markup]
>
>     Subtype name: xml
>
>     Required parameters: N/A
>
>     Optional parameters: N/A
> [charset declared in payload, hence charset parameter SHOULD NOT
>
> be defined]
>
>     Encoding considerations:
> Same as encoding considerations of application/xml as specified in
>
> RFC 3023
> [This media type MAY be encoded as appropriate for the charset and
>
> the capabilities of the underlying MIME transport.  For 7-bit transports,
>
> data in UTF-8 MUST be encoded in quoted-printable or base64.  For 8
>
> -bit clean transport (e.g., 8BITMIME[RFC1652] ESMTP or NNTP
>
> [RFC0977]), UTF-8 does not need to be encoded.  Over HTTP
>
> [RFC2616], no content-transfer-encoding is necessary and UTF-16 may
>
> also be used.]
>
>     Security considerations:
> All of the security considerations described in RFC 3023
>
>     Interoperability considerations:
> Same as interoperability considerations described in RFC 3023
> [XML has proven to be interoperable across WebDAV clients and
>
> servers, and for import and export from   multiple XML authoring tools.
>
> For maximum interoperability,
>        validating processors are recommended.  Although non-validating
>        processors may be more efficient, they are not required to handle
>        all features of XML.]
> Also, interoperability requirements are specified throughout the
>
> specification and summarized in its Conformance section
>
>     Published specification:
> [the current latest published version is:
> XLIFF Version 2.0 (CSD02)
> http://docs.oasis-open.org/xliff/xliff-core/v2.0/csd02/xliff-core-v2.0-
>
> csd02.html
> The relevant publsihed version at the time of submission will be most
>
> likely this:]
> XLIFF Version 2.0 (CSD03)
> http://docs.oasis-open.org/xliff/xliff-core/v2.0/csd02/xliff-core-v2.0-
>
> csd03.html
> [the above will not resolve until the thrird public review call become s
>
> public, the csd03 will be largely based on this current working draft:
> wd03: https://tools.oasis-open.org/version-
>
> control/browse/wsvn/xliff/trunk/xliff-20/xliff-core.pdf]
>
>     Applications that use this media type:
> XLIFF conformant applications, according to the Conformance Section
>
> of the specification.
>
>     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
>
> csprd03 [wd03] of Version 2.0. [XLIFF 1.2 has never been registered as
>
> a media type, I learn there is a xliff-xml type corresponding to XLIFF 1.2
>
> in the private x-tree, which seems to have been ill conceived for,
>
> however should be irrelevant for this current registration of XLIFF 2.0]
> Intended usage:
> COMMON
> Restrictions on usage: N/A
>
>     Author:
> OASIS XML Localisation Interchange File Format (XLIFF) TC
> Editors: Tom Comerford, [e-mail]; David Filip,
>
> [e-mail]; Yves Savourel, [e-mail]
>
>     Change controller:
> OASIS XML Localisation Interchange File Format (XLIFF) TC
> https://www.oasis-open.org/committees/xliff/
> Bryan Schnabel, [e-mail], Chair
> Tom Comerford, [e-mail], Secretary
> David Filip, [e-mail], Secretary
>
>     Provisional registration? (standards tree only): YES
> [I assume that the registration becomes fix after we reach the OASIS
>
> standard stage]
>
>
>     Additional information:
>
>       Deprecated alias names for this type: N/A
>       Magic number(s): N/A
>       File extension(s): .xlf
>       Macintosh file type code(s): "TEXT"
>
>     Person&  email address to contact for further information:
> OASIS Technical Committee administration
> [e-mail]
> [the review comments will be monitored by [e-mail] on this list]
>
>
>
> ----end of the registration form
>
>
>
>
> _______________________________________________
> media-types mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/media-types