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

["Dr. David Filip" <[e-mail]>]

Hello, everyone,

there seem to be no comments for the new version of our registration
template, and AFAIK we've addressed all actionable comments from the first
round.
As a newbie on the list, I wonder, does that mean that our registration
template is OK so or should we get an explicit OK from a senior reviewer
who is now pondering some subtle points that might make our registration
unlikely to succeed?

Thanks again
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]


On Thu, Jan 23, 2014 at 12:31 PM, Dr. David Filip <[e-mail]> wrote:

> Thanks everyone, for commenting on the previous provisional template.
>
> I have changed the subtype to xliff+xml and corrected few typos.
>
> Please let us know if you think that the template would be in your opinion
> ready for a IANA registration submission in its current state, ignoring any
> content in square brackets that is provided just for context of the review.
>
> As soon as the template seems OK to the experts on this list I will take
> it back to the XLIFF TC for registration approval.
>
> Thanks and regards
> dF
>
> <start of the registration template>
>
> Registration Template
>
>    Type name: application
> [not text, because end users do not like markup]
>
>    Subtype name: xliff+xml
> [based on media-types list experts feedback]
>
>    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 published 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 becomes
> 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 an OASIS
> standard, 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 template>
>
>
>
>
> Dr. David Filip
> =======================
> LRC | CNGL | LT-Web | CSIS
> University of Limerick, Ireland
> telephone: [phone]
> *cellphone: [phone] <%2B353-86-0222-158>*
> facsimile: [phone]
> http://www.cngl.ie/profile/?i=452
>  mailto: [e-mail]
>