Rahman, Akbar | 21 Jul 06:38 2014

New 'coap-group+json' Internet Media Type

Hi,

 

 

 

We would like to register a new Internet Media Type for CoAP group configuration resource called 'application/coap-group+json' The proposal is described in section 6.2 of

 

http://www.ietf.org/id/draft-ietf-core-groupcomm-20.txt

 

 

Any feedback would be much appreciated.

 

 

Best Regards,

 

 

Akbar & Esko

_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Chet Ensign | 17 Jun 22:45 2014

30-day Public Review for Media Type Registration Template for #XLIFF Version 2.0 - ends July 17th

OASIS members and other interested stakeholders, 

The OASIS XML Localisation Interchange File Format (XLIFF) TC [1] members have recently approved a Committee Specification Draft (CND) and submitted it for 30-day public review:

Media Type Registration Template for XLIFF Version 2.0
Committee Specification Draft 02 /Public Review Draft 01
20 May 2014

Overview:

Standalone media type registration template for XLIFF 2.0 and subsequent minor versions (2.x and 2.x.y).

TC Description:

The purpose of the OASIS XLIFF TC is to define, through extensible XML vocabularies, and promote the adoption of, a specification for the interchange of localisable software and document based objects and related metadata.

For more information, see the TC Charter and FAQ.

Public Review Period:

The public review starts 18 June 2014 at 00:00 GMT and ends 17 July 2014 at 23:59 GMT.

This is an open invitation to comment. OASIS solicits feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of its technical work.

URIs:

The prose specification document and related files are available here:

HTML (Authoritative):

PDF:

Editable source: 

ZIP distribution file (complete):

For your convenience, OASIS provides a complete package of the prose document and related files in a ZIP distribution file. You can download the ZIP file here:


Additional information about the specification and the TGF TC can be found at the TC's public home page:


Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility which can be used by following the instructions on the TC's "Send A Comment" page, or directly at:


Comments submitted by TC non-members for this work and for other work of this TC are publicly archived and can be viewed at:


All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. In connection with this public review of "Media Type Registration Template for XLIFF Version 2.0", we call your attention to the OASIS IPR Policy [2] applicable especially [3] to the work of this technical committee. All members of the TC should be familiar with this document, which may create obligations regarding the disclosure and availability of a member's patent, copyright, trademark and license rights that read on an approved OASIS specification. 

OASIS invites any persons who know of any such claims to disclose these if they may be essential to the implementation of the above specification, so that notice of them may be posted to the notice page for this TC's work.

========== Additional references:

[1] OASIS XML Localisation Interchange File Format (XLIFF) TC


RF on RAND Mode 


--

/chet 
----------------
Chet Ensign
Director of Standards Development and TC Administration 
OASIS: Advancing open standards for the information society
http://www.oasis-open.org

Primary: +1 973-996-2298
Mobile: +1 201-341-1393 

Check your work using the Support Request Submission Checklist at http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html 

TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin

Follow OASIS on:
LinkedIn:    http://linkd.in/OASISopen
Twitter:        http://twitter.com/OASISopen
Facebook:  http://facebook.com/oasis.open
_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Sujoy Gupta | 24 Mar 22:56 2014

Registering our company in the Vendor tree for use in Accepts Header

Hello,

Pursuant to http://tools.ietf.org/html/rfc4288, I am interested in registering "appdirect" in the Vendor tree. This is so that we can use headers such as Content-Type: application/vnd.appdirect.acme.v2+json without conflict with existing vendors.

Looking forward to questions or comments.

Thanks,
Sujoy Gupta
Principal Engineer, AppDirect Inc.
_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
szilva | 8 Mar 16:08 2014
Picon

media type registration of the Slovak national standard for e-forms container e-form+xml, e-form+zip

Dear sirs,

I am an idependent member of working groups of the Committee for  
standardization of information systems of public administration in  
Slovak republic, which defined a national e-forms container and is  
working also on another standards. The Committee works under the  
Ministry of finance of the Slovak republic and its public website is  
here: http://informatizacia.sk/standards-for-is-pa/4632s

The e-forms container will contain all definitions, schemas and  
transformations needed for a visual and other presentations of an  
e-government e-form, for filling an e-form, validation of filled data,  
etc.

We would like to register a mimetype for this national e-forms  
container, but firstly we would like to consult the correct naming.

My questions:

1. Is there any experience with registration of media types for  
national IT or e-government standards? Are there any examples of  
national standards' subtypes?

2. I would like to ask you, what registration tree would you suggest  
for our national e-forms container. "Vendor tree" or "Personal or  
Vanity tree"?

3. What should be the "IANA-approved designation of the producer's  
name" in the case of national e-government standard? Are there any  
written rules for the names?

More explanation:

The e-forms container will be primarily used by Slovak national  
e-government portal for publication of all e-forms specifications, but  
it will be also used by vendors/software producers, who will create  
and distribute commercial or freeware software for general public and  
business customers (e.g. economical or accounting software for  
business, software for filling e-forms, software for e-signing of  
e-forms, etc). It could be possibly used by other countries or vendors.

The container has two equal forms: XML structure or ZIP container.
The technical specification of the e-forms container is published as a  
legislative document - "Edict About Standards for Information Systems  
of Public Administration" and use of this specification is imposed by  
the Slovak national legislation. (It is currently available only in  
Slovak language and the requirements for the e-forms container are  
defined in this supplement: 

https://lt.justice.gov.sk/Attachment/Priloha_3_e-formulare.pdf?instEID=-1&attEID=63268&docEID=353297&matEID=6842&langEID=1&tStamp=20140304134546663

)

The e-forms container is based on existing standards: JAR file format,  
DublinCore, Open Packaging Format, OpenDocument format, EPUB Open  
Container Format. The e-forms container also extends these standards  
for specific e-forms usage.

Currently the following nonstandard media types for e-forms containers  
are used in Slovakia:
application/e-form+zip
application/x-eform-xml

Firstly we thought, we can register something like this:
application/vnd.e-form+zip
application/vnd.e-form+xml
(maybe "e-form" will be only "eform")

But if we understand the RFC 6838 correctly, we should create an  
abbreviation for the organization which is responsible for the Slovak  
e-government IT standards and this abbreviation must be incorporated  
in the subtype name.

Maybe something like this ? :
(note, these are only examples that were not approved or consulted by  
our Committee)

application/vnd.gov.sk.e-form+zip
application/vnd.gov.sk.e-form+xml

or something like this :

application/vnd.finance.gov.sk.e-form+zip
application/vnd.finance.gov.sk.e-form+xml

Explanation for the "gov.sk": It is the second-level domain name used  
by the Slovak government organizations, such as www.government.gov.sk,  
www.finance.gov.sk, www.nases.gov.sk, etc.

As an example I filled the registration template for the XML variant  
of the container, but this is not an official registration request:

    Type name: application

    Subtype name: Vendor Tree - vnd.gov.sk.e-form+xml

    Required parameters:   None.

    Optional parameters:  "charset"

          UTF-8 is required for Slovak national e-forms containers.  
This parameter has identical semantics to the charset parameter of the  
"application/xml" media type as specified in RFC3023.

    Encoding considerations:  Identical to those of "application/xml"  
as described in RFC3023, Section 3.2.

    Security considerations:  Files may contain script and other  
active content.

    Interoperability considerations:

    Published specification:  (only in Slovak language)  
https://lt.justice.gov.sk/Attachment/Priloha_3_e-formulare.pdf?instEID=-1&attEID=63268&docEID=353297&matEID=6842&langEID=1&tStamp=20140304134546663

    Applications that use this media type:  Slovak e-government  
portals and (in the future) software from some other vendors.

    Fragment identifier considerations:

    Additional information:

      Deprecated alias names for this type:

      Magic number(s):  As specified for "application/xml" in RFC3023,  
Section 3.2.

      File extension(s):  .xml, .eform

      Macintosh file type code(s):  TEXT

    Person & email address to contact for further information:   
National agency for network and electronic services  -  or  -   
Ministry of Finance of the Slovak republic

    Intended usage: COMMON

    (One of COMMON, LIMITED USE, or OBSOLETE.)

    Restrictions on usage:

    (Any restrictions on where the media type can be used go here.)

    Author:

----

An incomplete e-forms container structure:
- mimetype - e-form mimetype
- META-INF/manifest.xml - references and paths of all of the content  
in the container
- meta.xml - e-form identification, version, name, short description  
and other metadata
- schema.xsd - XML Schema for the data.xml
- data.xml - optional - user data filled in the e-form
- Content/ - presentation schema and transformation schema of the data  
(primarily XSLT file)
- Presentation/ - optional - a presentation containing the data filled  
by an user (a result of the XSLT transformation of data.xml)
- Thumbnails/ - e-form thumbnail
- attachments.xml - optional - list of attachments
- Attachments/ - optional - attachments listed in attachments.xml
- settings.xml - optional - application settings

---

Thank you for any help

Stefan Szilva
Viglasska 7
Bratislava
Slovak republic
szilva <at> changenet.sk
Roni Even | 4 Mar 15:18 2014
Picon

registeration of G7110 media subtype for G.711.0 payload

Hi,

 

draft-ietf-payload-g7110-02 has passed Working Group Last Call in the Payload Working Group.

The document registers media subtype G7110. 

 

The new registrations are in Section 5.1 of the document and is also given bellow.

 

Comments on the registration are welcome.

 

Thanks

Roni Even

Payload WG co-chair

 

 

 

 

Media Type Registration

 

   Type name: audio

 

   Subtype name: G7110

 

   Required parameters:

 

      rate: The RTP timestamp clock rate, which is equal to the sampling

      rate.  The typical rate used with G.711 encoding is 8000, but

      other rates may be specified.  The default rate is 8000.

 

      complaw: Indicates the companding law (A-law or mu-law) employed.

      The case-insensitive values are "al" or "mu" for A-law and mu-law,

      respectively.

 

   Optional parameters:

 

      channels: See RFC 4566 [RFC4566] for definition.  Specifies how

      many audio streams are represented in the G.711.0 payload and MUST

      be present if the number of channels is greater than one.  This

      parameter defaults to 1 if not present (as per RFC 4566) and is

      typically a non-zero small-valued positive integer.  It is

      expected that implementations that specify multiple channels will

      also define a mechanism to map the channels appropriately within

      their system design, otherwise the channel order specified in RFC

      3551 [RFC3551] Section 4.1 will be assumed (e.g., left, right,

      center, ... ).

 

      maxptime: See RFC 4566 [RFC4566] for definition.

 

      ptime: See RFC 4566 [RFC4566] for definition.  The inclusion of

      "ptime" is RECOMMENDED and SHOULD be in the SDP unless there is an

      application specific reason not to include it (e.g., an

      application that has a variable ptime on a packet-by-packet

      basis).  For constant ptime applications, it is considered good

      form to include "ptime" in the SDP for session diagnostic

      purposes.  For the constant ptime multiple channel case described

      in Section 4.2.2, the inclusion of "ptime" can provide a desirable

      payload check.

 

   Encoding considerations:

 

      This media type is framed binary data (see Section 4.8 in RFC 6838

      [RFC6838]) compressed as per ITU-T Rec. G.711.0.

 

   Security considerations:

 

      See Section 10.

 

   Interoperability considerations: none

 

   Published specification:

 

      ITU-T Rec. G.711.0 and RFC XXXX.

 

      [ RFC Editor: please replace XXXXX with a reference to this RFC ]

 

   Applications that use this media type:

 

      Although initially conceived for VoIP, the use of G.711.0, like

      G.711 before it, may find use within audio and video streaming and

      /or conferencing applications for the audio portion of those

      applications.

 

   Additional information:

 

   The following applies to stored-file transfer methods:

 

         Magic numbers: #!G7110A\n or #!G7110M\n (for A-law or MU-law

         encodings respectively, see Section 6).

 

        File Extensions: None

 

         Macintosh file type code: None

 

         Object identifier or OIL: None

 

   Person & email address to contact for further information:

 

      Michael A. Ramalho <mramalho <at> cisco.com> or <mar42 <at> cornell.edu>

 

   Intended usage: COMMON

 

   Restrictions on usage:

 

      This media type depends on RTP framing, and hence is only defined

      for transfer via RTP [RFC3550].  Transport within other framing

      protocols is not defined at this time.

 

   Author: Michael A. Ramalho

 

   Change controller:

 

 

      IETF Payload working group delegated from the IESG.

 

 

_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
ashimura | 27 Feb 09:01 2014
Picon

Request for review of SCXML media type: application/scxml+xml

Dear media-types list,

I am sending this request to ask you review the Media Type section of
the W3C SCXML specification.

The Media Type section of the SCXML specification is available at:

  http://www.w3.org/TR/2013/WD-scxml-20130801/#mimetype

and its plain text copy is available below.

MIME media type name:
---------------------

     application

MIME subtype name:
------------------

     scxml+xml

Required parameters:
--------------------

     None

Optional parameters:
--------------------

     charset

     This parameter has identical semantics to the charset parameter of
     the application/xml media type as specified in [RFC 3023] or its
     successor.

Encoding considerations:
------------------------

     By virtue of SCXML content being XML, it has the same
     considerations when sent as "application/scxml+xml"as does
     XML. See [RFC 3023] (or its successor), section 3.2.

Security considerations:
------------------------

     SCXML elements may include arbitrary URIs. Therefore, the security
     issues of [RFC 3986] section 7 should be considered. In addition,
     because of the extensibility features for SCXML, it is possible
     that "application/scxml+xml" may describe content that has
     security implications beyond those described here. However, if the
     processor follows only the normative semantics of this
     specification, this content will be ignored. Only in the case
     where the processor recognizes and processes the additional
     content, or where further processing of that content is dispatched
     to other processors, would security issues potentially arise. And
     in that case, they would fall outside the domain of this
     registration document.

Interoperability considerations:
--------------------------------

     This specification describes processing semantics that dictate
     behavior that must be followed when dealing with, among other
     things, unrecognized elements.Because SCXML is extensible,
     conformant "application/scxml+xml" processors MAY expect that
     content received is well-formed XML, but processors SHOULD NOT
     assume that the content is valid SCXML or expect to recognize all
     of the elements and attributes in the document.

Published specification:
------------------------

     This media type registration is extracted from Appendix H of the
     State Chart XML (SCXML): State Machine Notation for Control
     Abstraction specification.

Additional information:
-----------------------

     Magic number(s):

         There is no single initial octet sequence that is always
         present in SCXML documents.

     File extension(s):

         SCXML documents are most often identified with the extensions
         ".scxml".

     Macintosh File Type Code(s):

         TEXT

Person and email address to contact for further information:
------------------------------------------------------------

     Kazuyuki Ashimura, <ashimura <at> w3.org>.

Intended usage:
---------------

     COMMON

Restrictions on usage:
----------------------

     None

Author:
-------

     The SCXML specification is a work product of the World Wide Web
     Consortium's Voice Browser Working Group.

Change controller:
------------------

     The W3C has change control over these specifications.

Sincerely,

Kazuyuki

--
Kaz Ashimura, W3C Activity Lead for Web&TV, MMI and Voice
Tel: +81 466 49 1170
Jim Schaad | 20 Feb 18:54 2014

Review for new media type registration - application/jose and application/jose+json

The document http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature is completing working group last call.  We are therefore requesting review of the registration of a new media type registration  application/jose and application/jose+json

 

The registration templates can be found in section 9.2 of the document.

 

Jim Schaad

JOSE working group co-chair

 

_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Jim Schaad | 20 Feb 18:54 2014

Review for new media type registration - application/jwk-set+json

The document http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key is completing working group last call.  We are therefore requesting review of the registration of a new media type registration  application/jwk-set+json

 

The registration template can be found in section 7.5.1 of the document.

 

Jim Schaad

JOSE working group co-chair

 

_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
Dr. David Filip | 23 Jan 13:31 2014
Picon

Updated template for Potential media type registration for XLIFF 2.0

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)
The relevant published version at the time of submission will be most likely this:]
XLIFF Version 2.0 (CSD03)
[the above will not resolve until the thrird public review call becomes public, the csd03 will be largely based on this current working draft:

   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, tom <at> supratext.com; David Filip, David.Filip <at> ul.ie; Yves Savourel, ysavourel <at> enlaso.com

   Change controller:
OASIS XML Localisation Interchange File Format (XLIFF) TC
Tom Comerford, tom <at> supratext.com, Secretary
David Filip, David.Filip <at> ul.ie, 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
[the review comments will be monitored by david.filip <at> ul.ie on this list]

</end of the registration template>

  


Dr. David Filip
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types
SM | 20 Jan 23:10 2014
Picon

Re: Potential media type registration for OASIS XLIFF 2.0

Hi David,
At 12:27 16-01-2014, Dr. David Filip wrote:
>as Secretary of the OASIS XLIFF TC 
><https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xliff>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.

[snip]

>----start of the registration form
>
>Registration Template
>
>    Type name: application
>[not text, because end users do not like markup]
>
>    Subtype name: xml

draft-ietf-appsawg-xml-mediatypes-06 [1] intends to obsolete RFC 
3023.  There is a registration request in that draft for the same 
type and subtype.

Regards,
-sm

1. http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-06 
Dr. David Filip | 16 Jan 21:27 2014
Picon

Potential media type registration for OASIS XLIFF 2.0

Hello Reviewers,



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: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734


----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)

csd02.html
The relevant publsihed version at the time of submission will be most 

likely this:]
XLIFF Version 2.0 (CSD03)

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:

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, tom <at> supratext.com; David Filip, 


   Change controller:
OASIS XML Localisation Interchange File Format (XLIFF) TC
Tom Comerford, tom <at> supratext.com, Secretary
David Filip, David.Filip <at> ul.ie, 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
[the review comments will be monitored by david.filip <at> ul.ie on this list]



----end of the registration form

_______________________________________________
media-types mailing list
media-types <at> ietf.org
https://www.ietf.org/mailman/listinfo/media-types

Gmane