From stpeter@stpeter.im Mon Jan 6 13:07:16 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088BD1AE211 for ; Mon, 6 Jan 2014 13:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_84=0.6, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ix0Z-t6QCew3 for ; Mon, 6 Jan 2014 13:07:14 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 73EE91AE236 for ; Mon, 6 Jan 2014 13:07:14 -0800 (PST) Received: from ergon.local (unknown [64.101.72.104]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7C8BF400AD; Mon, 6 Jan 2014 14:07:04 -0700 (MST) Message-ID: <52CB1AF6.3080208@stpeter.im> Date: Mon, 06 Jan 2014 14:07:02 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: media-types@ietf.org X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Cyrus Daboo , Bert Greevenbosch , Philipp Kewisch , Mike Douglass Subject: [media-types] review requested for calendar+json X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 21:07:16 -0000 Please review the following registration request, which is extracted from draft-ietf-jcardcal-jcal. I am posting as the document shepherd, and I have cc'd the authors and my co-chair in the JCARDCAL WG. Thanks! ### Type name: application Subtype name: calendar+json Required parameters: none Optional parameters: "method", "component" and "optinfo" as defined for the text/calendar media type in [RFC5545], Section 8.1. Encoding considerations: Same as encoding considerations of application/json as specified in [RFC4627], Section 6. Security considerations: See Section 7. Interoperability considerations: This media type provides an alternative format for iCalendar data based on JSON. Published specification: This specification. Applications which use this media type: Applications that currently make use of the text/calendar media type can use this as an alternative. Similarly, Applications that use the application/ json media type to transfer calendaring data can use this to further specify the content. Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): N/A Macintosh file type code(s): N/A Person & email address to contact for further information: calsify@ietf.org Intended usage: COMMON Restrictions on usage: There are no restrictions on where this media type can be used. Author: See the "Author's Address" section of this document. Change controller: IETF ### From David.Filip@ul.ie Thu Jan 16 12:28:10 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2953F1ABBB1 for ; Thu, 16 Jan 2014 12:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.805 X-Spam-Level: X-Spam-Status: No, score=-1.805 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, T_HK_NAME_DR=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQFxdWM06kwF for ; Thu, 16 Jan 2014 12:28:06 -0800 (PST) Received: from MARSHAL4.ul.ie (marshal4.ul.ie [193.1.100.137]) by ietfa.amsl.com (Postfix) with ESMTP id 3853B1A16F0 for ; Thu, 16 Jan 2014 12:28:06 -0800 (PST) Received: from staffexchange7.ul.campus (Not Verified[193.1.101.32]) by MARSHAL4.ul.ie with MailMarshal (v6, 8, 4, 9558) id ; Thu, 16 Jan 2014 20:27:53 +0000 Received: from mail-ie0-f171.google.com ([209.85.223.171]) by staffexchange7.ul.campus over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Jan 2014 20:27:52 +0000 Received: by mail-ie0-f171.google.com with SMTP id to1so4491617ieb.16 for ; Thu, 16 Jan 2014 12:27:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=dmpiJsvV6gIIASuLS3ucVKBjEEbt1BhccPblkh7Ezqo=; b=B33NiOY92fT1qsAIf7nAoyJ0hJHdEXEMmnhi7xKuN73CEVLBc/z1QKoEB4rJ6+KWx7 1RyFkcIP/Gg5f8quGuQDLTEtwo127t5omA1e1r/u8pQ+05i9nF6+sGvCBJ9akIp00min h81GoDGG/uMrt9jj2KjXOBQ7RNA1k+ULSfBlzwnNMHfg/TwlKBtWyeCCwl3gP/I+HyCx 2V7Fotdj9I0NYMP7QdYyKZ4i5gD+iZD/uCgTDzo+VJc3z8WO1eccEhwIMpdEXpRrgKRp YWFhw02oLlTZKQFtG5ePkvXvzm4PUryr34+ff+clwoFanAKY+WeVbXncLyA0EBPC57DX 4b+A== X-Gm-Message-State: ALoCoQlV83H0VawM39JaEsDxT5sViB+H/TWQJA1Mh9Ce1YTPZ16BH+1KHYQKjc1WtMP3PsJKOIfO X-Received: by 10.43.61.196 with SMTP id wx4mr10096838icb.6.1389904071176; Thu, 16 Jan 2014 12:27:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.32.196 with HTTP; Thu, 16 Jan 2014 12:27:11 -0800 (PST) X-Originating-IP: [84.203.70.10] From: "Dr. David Filip" Date: Thu, 16 Jan 2014 20:27:11 +0000 Message-ID: To: media-types@ietf.org Content-Type: multipart/alternative; boundary=bcaec51dd1f16f4bfe04f01c4286 X-OriginalArrivalTime: 16 Jan 2014 20:27:52.0984 (UTC) FILETIME=[6EAA3980:01CF12F9] Subject: [media-types] Potential media type registration for OASIS XLIFF 2.0 X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 20:55:49 -0000 --bcaec51dd1f16f4bfe04f01c4286 Content-Type: text/plain; charset=ISO-8859-1 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: +353-6120-2781 *cellphone: +353-86-0222-158* facsimile: +353-6120-2734 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie ----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, tom@supratext.com; David Filip, David.Filip@ul.ie; Yves Savourel, ysavourel@enlaso.com Change controller: OASIS XML Localisation Interchange File Format (XLIFF) TC https://www.oasis-open.org/committees/xliff/ Bryan Schnabel, bryan.s.schnabel@tektronix.com, Chair Tom Comerford, tom@supratext.com, Secretary David Filip, David.Filip@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 tc-admin@oasis-open.org [the review comments will be monitored by david.filip@ul.ie on this list] ----end of the registration form --bcaec51dd1f16f4bfe04f01c4286 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Reviewers,


<= div>as Secretary of the OASIS XLIFF TC=A0https://www.oasis-open.org/co= mmittees/tc_home.php?wg_abbrev=3Dxliff

I have been mandated by the said TC and OASIS TC admini= stration to run by this list our provisionally completed media type registr= ation template.

All comments in square brackets ar= e not meant as part of the future submission but rather as explanattory not= es for the reviewers within OASIS and on this list.

XLIFF TC is looking forward to receiving your feedback<= /div>

See the filled out template copy-pasted down below= :

Best regards
dF



Dr. David = Filip
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
LRC | CNGL | LT-Web | CSIS
University = of Limerick, Ireland
telephone:=A0+353-6120-2781
cellphone: +353-86-0222-158
facsimile:=A0+353-6120-2734


----start of= the registration form

Registration Template

=A0= =A0Type name: application
[not text, because end users do not li= ke markup]

=A0 =A0Subtype name: xml

=
=A0 =A0Required parameters: N/A

=A0 =A0Option= al parameters: N/A
[charset declared in payload, hence charset pa= rameter SHOULD NOT=A0

be defined]

=A0 =A0Encoding considerations:
Same as encoding considerations o= f application/xml as specified in=A0

RFC 3023
[This media type MAY be encoded as appropriate for the charset and=A0=

the capabilities of the underlying MIME transport. =A0F= or 7-bit transports,=A0

data in UTF-8 MUST be enco= ded in quoted-printable or base64. =A0For 8

-bit c= lean transport (e.g., 8BITMIME[RFC1652] ESMTP or NNTP

[RFC0977]), UTF-8 does not need to be encoded. =A0Over = HTTP

[RFC2616], no content-transfer-encoding is ne= cessary and UTF-16 may=A0

also be used.]

=A0 =A0Security considerations:=A0
All of the secu= rity considerations described in RFC 3023

=A0 =A0I= nteroperability considerations:
Same as interoperability consider= ations described in RFC 3023
[XML has proven to be interoperable across WebDAV clients and=A0
=

servers, and for import and export from =A0 multiple XM= L authoring tools. =A0

For maximum interoperabilit= y,
=A0 =A0 =A0 validating processors are recommended. =A0Although non-val= idating
=A0 =A0 =A0 processors may be more efficient, they are no= t required to handle
=A0 =A0 =A0 all features of XML.]
= Also, interoperability requirements are specified throughout the=A0

specification and summarized in its Conformance section=

=A0 =A0Published specification:
[the cu= rrent latest published version is:
XLIFF Version 2.0 (CSD02)

csd02.html
The relevant p= ublsihed version at the time of submission will be most=A0

likely this:]
XLIFF Version 2.0 (CSD03)
=

csd03.html
[the above will not resolve until = the thrird public review call become s=A0

public, = the csd03 will be largely based on this current working draft:

control/browse/wsvn/xliff/t= runk/xliff-20/xliff-core.pdf]

=A0 =A0Applications = that use this media type:
XLIFF conformant applications, according to the Conformance Section=A0=

of the specification.

= =A0 =A0Fragment identifier considerations:
Generic XML processors= won't be able to resolve XLIFF fragment=A0

identifiers, as the fragment identification syntax is s= pecific for XLIFF=A0

and has been defined in its F= ragment Identification section as of=A0

csprd03 [w= d03] of Version 2.0. [XLIFF 1.2 has never been registered as=A0

a media type, I learn there is a xliff-xml type corresp= onding to XLIFF 1.2=A0

in the private x-tree, whic= h seems to have been ill conceived for,=A0

however= should be irrelevant for this current registration of XLIFF 2.0]=A0
Intended usage:
COMMON
Restrictions on usage: N/A<= /div>

=A0 =A0Author:
OASIS XML Localisation In= terchange File Format (XLIFF) TC
Editors: Tom Comerford, tom@supratext.com; David Filip,=A0


=A0 =A0Change controller:
OASI= S XML Localisation Interchange File Format (XLIFF) TC
Bryan Schnabel, bryan.s.schnabel@tektronix.com, Ch= air

=A0 =A0Provisiona= l registration? (standards tree only): YES
[I assume that the registration becomes fix after we reach the OASIS= =A0

standard stage]


<= /div>
=A0 =A0Additional information:

=A0 =A0 = =A0Deprecated alias names for this type: N/A
=A0 =A0 =A0Magic number(s): N/A
=A0 =A0 =A0File extension(s)= : .xlf
=A0 =A0 =A0Macintosh file type code(s): "TEXT"

=A0 =A0Person & email address to contact for fu= rther information:
OASIS Technical Committee administration
[the review c= omments will be monitored by david.fil= ip@ul.ie on this list]



----end of the regi= stration form

--bcaec51dd1f16f4bfe04f01c4286-- From duerst@it.aoyama.ac.jp Mon Jan 20 02:22:13 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2091A00BD for ; Mon, 20 Jan 2014 02:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.774 X-Spam-Level: X-Spam-Status: No, score=0.774 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPPU81PCZJ_b for ; Mon, 20 Jan 2014 02:22:11 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id AE3C11A00E0 for ; Mon, 20 Jan 2014 02:22:10 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id s0KAM7Z5003850; Mon, 20 Jan 2014 19:22:07 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 092e_bd53_b71d16ec_81bc_11e3_a6bf_001e6722eec2; Mon, 20 Jan 2014 19:22:07 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id ECB3DBF54D; Mon, 20 Jan 2014 19:22:06 +0900 (JST) Message-ID: <52DCF8C4.3070803@it.aoyama.ac.jp> Date: Mon, 20 Jan 2014 19:21:56 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Dr. David Filip" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: media-types@ietf.org Subject: Re: [media-types] Potential media type registration for OASIS XLIFF 2.0 X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 10:22:13 -0000 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: +353-6120-2781 > *cellphone: +353-86-0222-158* > facsimile: +353-6120-2734 > http://www.cngl.ie/profile/?i=452 > mailto: david.filip@ul.ie > > > ----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, tom@supratext.com; David Filip, > > David.Filip@ul.ie; Yves Savourel, ysavourel@enlaso.com > > Change controller: > OASIS XML Localisation Interchange File Format (XLIFF) TC > https://www.oasis-open.org/committees/xliff/ > Bryan Schnabel, bryan.s.schnabel@tektronix.com, Chair > Tom Comerford, tom@supratext.com, Secretary > David Filip, David.Filip@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 > tc-admin@oasis-open.org > [the review comments will be monitored by david.filip@ul.ie on this list] > > > > ----end of the registration form > > > > > _______________________________________________ > media-types mailing list > media-types@ietf.org > https://www.ietf.org/mailman/listinfo/media-types From David.Filip@ul.ie Mon Jan 20 11:02:50 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1D81A0254 for ; Mon, 20 Jan 2014 11:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.535, T_HK_NAME_DR=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxC-fqwqWYXW for ; Mon, 20 Jan 2014 11:02:47 -0800 (PST) Received: from MARSHAL4.ul.ie (marshal4.ul.ie [193.1.100.137]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC601A0251 for ; Mon, 20 Jan 2014 11:02:45 -0800 (PST) Received: from staffexchange7.ul.campus (Not Verified[193.1.101.32]) by MARSHAL4.ul.ie with MailMarshal (v6, 8, 4, 9558) id ; Mon, 20 Jan 2014 19:02:40 +0000 Received: from mail-ie0-f171.google.com ([209.85.223.171]) by staffexchange7.ul.campus over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 20 Jan 2014 19:02:40 +0000 Received: by mail-ie0-f171.google.com with SMTP id as1so1631080iec.16 for ; Mon, 20 Jan 2014 11:02:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oD+DIgT82J4406/j8HcY6LL44i2NeB0ezKmFWu9lbCA=; b=ZZMRS2CUFvM+MPcsNJJekyzNK3fWViOxRdYS9E+v7K1veUppcGjCfDI4XcVDaxx2V5 P+Wy24A/AQwTy2SLmTq/5EiT4+gMEZJHRjuy7qse0D/A55wN3QeApytIc3N3ptx6tHGk loBMvvjfQTZCAsOQrEmhSSV35HiEtq/t92wLShSkaBCNcfeoDp++hzx1MaB1HrBwf14Q LktShozW1aSoTqNK6els+EWg/efuJC2/xwVHrIai/grQjCK/ShwIGSCqC94EZqhV40/+ Xp+aeRdHBGGEydhPbg4ejQfej29F/KBIiQthU6oPP0iogMlG+xRnHsT+HDCLCq9agWVw EZsA== X-Gm-Message-State: ALoCoQldrsmQ0M18p88a147avp+/O80wi1bY/QR6L5X51TxkSiF3lK0AcNZ5oIMu8YOPT/HgBORZ MIME-Version: 1.0 X-Received: by 10.42.226.66 with SMTP id iv2mr15223500icb.11.1390244558857; Mon, 20 Jan 2014 11:02:38 -0800 (PST) Received: by 10.64.32.196 with HTTP; Mon, 20 Jan 2014 11:02:38 -0800 (PST) X-Originating-IP: [84.203.70.10] Received: by 10.64.32.196 with HTTP; Mon, 20 Jan 2014 11:02:38 -0800 (PST) In-Reply-To: <52DCF8C4.3070803@it.aoyama.ac.jp> References: <52DCF8C4.3070803@it.aoyama.ac.jp> Date: Mon, 20 Jan 2014 19:02:38 +0000 Message-ID: From: "Dr. David Filip" To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: multipart/alternative; boundary=001a113323b815019c04f06b89ed X-OriginalArrivalTime: 20 Jan 2014 19:02:40.0303 (UTC) FILETIME=[30EC03F0:01CF1612] Cc: media-types@ietf.org Subject: Re: [media-types] Potential media type registration for OASIS XLIFF 2.0 X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 19:02:51 -0000 --001a113323b815019c04f06b89ed Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thank you, Martin, and sorry for confusion on my end. We intend to have a separate xml based media type with its own extension (.xlf) and fragid behavior. Could you please have a look at the rest of the template? Assuming that the intended subtype is xliff+xml.. Thanks again dF dF is AFK, so that this had to be typed on his tough phone.. Call me at +353860222158 if this answer does not seem sufficient ;) On Jan 20, 2014 10:21 AM, Martin J. D=FCrst wrote: > 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=3Dxliff >> >> I have been mandated by the said TC and OASIS TC administration to run b= y >> 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 OAS= IS >> 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 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> LRC | CNGL | LT-Web | CSIS >> University of Limerick, Ireland >> telephone: +353-6120-2781 >> *cellphone: +353-86-0222-158* >> facsimile: +353-6120-2734 >> http://www.cngl.ie/profile/?i=3D452 >> mailto: david.filip@ul.ie >> >> >> ----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, tom@supratext.com; David Filip, >> >> David.Filip@ul.ie; Yves Savourel, ysavourel@enlaso.com >> >> Change controller: >> OASIS XML Localisation Interchange File Format (XLIFF) TC >> https://www.oasis-open.org/committees/xliff/ >> Bryan Schnabel, bryan.s.schnabel@tektronix.com, Chair >> Tom Comerford, tom@supratext.com, Secretary >> David Filip, David.Filip@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 >> tc-admin@oasis-open.org >> [the review comments will be monitored by david.filip@ul.ie on this list= ] >> >> >> >> ----end of the registration form >> >> >> >> >> _______________________________________________ >> media-types mailing list >> media-types@ietf.org >> https://www.ietf.org/mailman/listinfo/media-types >> > --001a113323b815019c04f06b89ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Thank you, Martin, and sorry for confusion on my end.
We intend to have a separate xml based media type with its own extension=A0= (.xlf) and fragid behavior.
Could you please have a look at the rest of the template?
Assuming that the intended subtype is xliff+xml..
Thanks again
dF

dF is AFK, so that this had to be typed on his tough phone..
Call me at +353860222158 if this answer does not seem sufficient ;)

On Jan 20, 2014 10:21 AM, Martin J. D=FCrst <= duerst@it.aoyama.ac.jp> wr= ote:
Hello David,

Your registration template starts:

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

This would give an overall type of application/xml. This is already registe= red, 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&= #39;s best to first check the general intent.

Regards, =A0 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=3Dxliff

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<= br> 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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
*cellphone: +353-86-0222-158*
facsimile: +353-6120-2734
http://ww= w.cngl.ie/profile/?i=3D452
mailto: david.filip@= ul.ie


----start of the registration form

Registration Template

=A0 =A0 Type name: application
[not text, because end users do not like markup]

=A0 =A0 Subtype name: xml

=A0 =A0 Required parameters: N/A

=A0 =A0 Optional parameters: N/A
[charset declared in payload, hence charset parameter SHOULD NOT

be defined]

=A0 =A0 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. =A0For 7-bit transports,=

data in UTF-8 MUST be encoded in quoted-printable or base64. =A0For 8

-bit clean transport (e.g., 8BITMIME[RFC1652] ESMTP or NNTP

[RFC0977]), UTF-8 does not need to be encoded. =A0Over HTTP

[RFC2616], no content-transfer-encoding is necessary and UTF-16 may

also be used.]

=A0 =A0 Security considerations:
All of the security considerations described in RFC 3023

=A0 =A0 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 =A0 multiple XML authoring tools.
For maximum interoperability,
=A0 =A0 =A0 =A0validating processors are recommended. =A0Although non-valid= ating
=A0 =A0 =A0 =A0processors may be more efficient, they are not required to h= andle
=A0 =A0 =A0 =A0all features of XML.]
Also, interoperability requirements are specified throughout the

specification and summarized in its Conformance section

=A0 =A0 Published specification:
[the current latest published version is:
XLIFF Version 2.0 (CSD02)
http://docs.oasis-open.org/xliff/xliff-co= re/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-co= re/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: h= ttps://tools.oasis-open.org/version-

control/browse/wsvn/xliff/trunk/xliff-20/xliff-core.pdf]

=A0 =A0 Applications that use this media type:
XLIFF conformant applications, according to the Conformance Section

of the specification.

=A0 =A0 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<= br>
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

=A0 =A0 Author:
OASIS XML Localisation Interchange File Format (XLIFF) TC
Editors: Tom Comerford, tom@supratext.com; David Filip,

David.Filip@ul.ie; Yves Savourel, ysavourel@enlaso.com

=A0 =A0 Change controller:
OASIS XML Localisation Interchange File Format (XLIFF) TC
= https://www.oasis-open.org/committees/xliff/
Bryan Schnabel, bryan.s.schnabel@tektronix.com, Chair
Tom Comerford, tom@s= upratext.com, Secretary
David Filip, David.F= ilip@ul.ie, Secretary

=A0 =A0 Provisional registration? (standards tree only): YES
[I assume that the registration becomes fix after we reach the OASIS

standard stage]


=A0 =A0 Additional information:

=A0 =A0 =A0 Deprecated alias names for this type: N/A
=A0 =A0 =A0 Magic number(s): N/A
=A0 =A0 =A0 File extension(s): .xlf
=A0 =A0 =A0 Macintosh file type code(s): "TEXT"

=A0 =A0 Person& =A0email address to contact for further information: OASIS Technical Committee administration
tc-admin@oasis= -open.org
[the review comments will be monitored by david.filip@ul.ie on this list]



----end of the registration form




_______________________________________________
media-types mailing list
media-types@ietf.= org
https://www.ietf.org/mailman/listinfo/media-types
--001a113323b815019c04f06b89ed-- From sm@resistor.net Mon Jan 20 14:19:32 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8371A024D for ; Mon, 20 Jan 2014 14:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z79-JiZnMXe4 for ; Mon, 20 Jan 2014 14:19:31 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 089B51A01F2 for ; Mon, 20 Jan 2014 14:19:30 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s0KMJNQf006156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jan 2014 14:19:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1390256370; bh=SBizdf2AyXCvwYCUPaU93JLb4sOFmLwBt2Eh/rxnHEg=; h=Date:To:From:Subject:In-Reply-To:References; b=Eal72waxBlvDhNB3/SUUXFTAA6DyZl8AOQ+vOYmxg8tZxw6/60sM6gUmUW+0qUhKy meuASrllIhhcWKGB2LYxbMEM5q3x18x72Sk7tFeZiWB5/Ar0BPmA8lU4Z2jcw4bYR3 VJEfFopWbLMaicqPE5jvcNv6tRfHVRNDb85YSOS4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1390256370; i=@resistor.net; bh=SBizdf2AyXCvwYCUPaU93JLb4sOFmLwBt2Eh/rxnHEg=; h=Date:To:From:Subject:In-Reply-To:References; b=JDw3OUBHIDI7hIEaPXgla4v7GZGMIzCh98tou7EVWwgVfqXG97RNDog+4c0jnEtBl ABuvfca3OR2SNmsi5Ok6fS/oSsIpOHmd/xE5H1YIt+N30KRuRw0KqFF4MQlnu9p8Ld 6hOLYXrxD+BJVvIxhFfjrCzxJJmcYfZHGiJ/uIMs= Message-Id: <6.2.5.6.2.20140120140616.0b2240f0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 20 Jan 2014 14:10:11 -0800 To: "Dr. David Filip" , media-types@ietf.org From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [media-types] Potential media type registration for OASIS XLIFF 2.0 X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 22:19:33 -0000 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 > >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 From David.Filip@ul.ie Thu Jan 23 04:32:28 2014 Return-Path: X-Original-To: media-types@ietfa.amsl.com Delivered-To: media-types@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC8B1A03E6 for ; Thu, 23 Jan 2014 04:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.802 X-Spam-Level: X-Spam-Status: No, score=-1.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, T_HK_NAME_DR=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-rR227EDr9i for ; Thu, 23 Jan 2014 04:32:24 -0800 (PST) Received: from MARSHAL4.ul.ie (marshal4.ul.ie [193.1.100.137]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1781A02C2 for ; Thu, 23 Jan 2014 04:32:22 -0800 (PST) Received: from staffexchange7.ul.campus (Not Verified[193.1.101.32]) by MARSHAL4.ul.ie with MailMarshal (v6, 8, 4, 9558) id ; Thu, 23 Jan 2014 12:32:10 +0000 Received: from mail-ig0-f170.google.com ([209.85.213.170]) by staffexchange7.ul.campus over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Jan 2014 12:32:10 +0000 Received: by mail-ig0-f170.google.com with SMTP id m12so1772887iga.1 for ; Thu, 23 Jan 2014 04:32:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=OG4neKkyhe+gxixia8TuaOKogBuPm10yvGMiSWjK29A=; b=PevoZtpatlWP1GbIG4jb+/A+7x2uA3/ULsMha4r1vhHFGJEgXrxYnp9OXuvhjlfKU6 0Vk2MvwRlwlbdDeD3dT7XyB8I3bgUNwL8uRHQJTdWz0pDCvL0tAony/bg920aJOZgQYj UG356XSqWS79PF1occCqRk/5y4N1ZwvhRD4ZMySx3/dbD9jfALpNQZJx8n72qAcu3mlU KZEZuGYr0h2iS13wrBncOMrKAJSOO+teNpCFSJg9Qu99M0w8wYySMy9wk+P5XON8m96D Yoprj5t1Cu5r6K5gq9mR2YJheEwnokOJy2uUldsr+1sjl67p8eGC03jt4ymtZSKJbFgs GrQg== X-Gm-Message-State: ALoCoQmJLBoFiSXExw7uGz3+/JP+T7RtZ6lELK8UaF9Cvgq5MnZvg7TFK1r5A3S4oYH6Y/qyhvzj X-Received: by 10.43.138.8 with SMTP id iq8mr5796782icc.37.1390480329120; Thu, 23 Jan 2014 04:32:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.32.196 with HTTP; Thu, 23 Jan 2014 04:31:28 -0800 (PST) X-Originating-IP: [95.83.250.188] From: "Dr. David Filip" Date: Thu, 23 Jan 2014 12:31:28 +0000 Message-ID: To: media-types@ietf.org Content-Type: multipart/alternative; boundary=001a11c2036415c68e04f0a26e5f X-OriginalArrivalTime: 23 Jan 2014 12:32:10.0579 (UTC) FILETIME=[22F51A30:01CF1837] Subject: [media-types] Updated template for Potential media type registration for XLIFF 2.0 X-BeenThere: media-types@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "IANA mailing list for reviewing Media Type \(MIME Type, Content Type\) registration requests." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 12:32:28 -0000 --001a11c2036415c68e04f0a26e5f Content-Type: text/plain; charset=ISO-8859-1 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 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, tom@supratext.com; David Filip, David.Filip@ul.ie; Yves Savourel, ysavourel@enlaso.com Change controller: OASIS XML Localisation Interchange File Format (XLIFF) TC https://www.oasis-open.org/committees/xliff/ Bryan Schnabel, bryan.s.schnabel@tektronix.com, Chair Tom Comerford, tom@supratext.com, Secretary David Filip, David.Filip@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 tc-admin@oasis-open.org [the review comments will be monitored by david.filip@ul.ie on this list] 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 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie --001a11c2036415c68e04f0a26e5f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks everyone, for commenting on the previous provi= sional template.

I have changed the subtype to xli= ff+xml and corrected few typos.

Please let us know= if you think that the template would be in your opinion ready for a IANA r= egistration 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.
<= div>
Thanks and regards
dF

<start of the registration template>

Registration Template

=A0 =A0Type name: applica= tion
[not text, because end users do not like markup]

=A0 =A0Subtype name: xliff+xml
[based on media-types l= ist experts feedback]

=A0 =A0Required parameters: = N/A

=A0 =A0Optional parameters: N/A
[cha= rset declared in payload, hence charset parameter SHOULD NOT be defined]


=A0 =A0Encoding considerations:
Same as encoding considerations of application/xml as specified in RFC 30= 23
[This media type MAY be encoded as appropriate for the charset= and the capabilities of the underlying MIME transport. =A0For 7-bit transp= orts, data in UTF-8 MUST be encoded in quoted-printable or base64. =A0For 8= -bit clean transport (e.g., 8BITMIME[RFC1652] ESMTP or NNTP[RFC0977]), UTF-= 8 does not need to be encoded. =A0Over HTTP[RFC2616], no content-transfer-e= ncoding is necessary and UTF-16 may also be used.]

=A0 =A0Security considerations:=A0
All of the= security considerations described in RFC 3023

=A0= =A0Interoperability considerations:
Same as interoperability con= siderations described in RFC 3023
[XML has proven to be interoperable across WebDAV clients and servers,= and for import and export from =A0 multiple XML authoring tools. =A0For ma= ximum interoperability,
=A0 =A0 =A0 validating processors are rec= ommended. =A0Although non-validating
=A0 =A0 =A0 processors may be more efficient, they are not required to= handle
=A0 =A0 =A0 all features of XML.]
Also, interop= erability requirements are specified throughout the specification and summa= rized in its Conformance section

=A0 =A0Published 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 become= s public, the csd03 will be largely based on this current working draft:

=A0 =A0Applications that use this media type:
XLIFF conformant applications, according to the Conformance Section of the= specification.

=A0 =A0Fragment identifier conside= rations:
Generic XML processors won't be able to resolve XLIFF fragment ide= ntifiers, as the fragment identification syntax is specific for XLIFF and h= as 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 le= arn there is a xliff+xml type corresponding to XLIFF 1.2 in the private x-t= ree, which seems to have been ill conceived for an OASIS standard, however = should be irrelevant for this current registration of XLIFF 2.0]=A0
Intended usage:
COMMON
Restrictions on usage: N/A<= /div>

=A0 =A0Author:
OASIS XML Localisation In= terchange File Format (XLIFF) TC
Editors: Tom Comerford, tom@supratext.com; David Filip, David.Filip@ul.ie; Yves Savourel, ysavourel@enlaso.com

=A0 =A0Change controller:
OASIS XML Localisat= ion Interchange File Format (XLIFF) TC
Bryan Schnabel, brya= n.s.schnabel@tektronix.com, Chair
Tom Comerford, tom@supratext.com, Secretary
David F= ilip, David.Filip@ul.ie, Secretary=

=A0 =A0Provisional registration? (standards tree only):= YES
[I assume that the registration becomes fix after we reach t= he OASIS standard stage]


=A0 =A0Add= itional information:

=A0 =A0 =A0Deprecated alias names for this type: N/A
=A0 =A0 =A0Magic number(s): N/A
=A0 =A0 =A0File extension= (s): .xlf
=A0 =A0 =A0Macintosh file type code(s): "TEXT"= ;

=A0 =A0Person & email address to contact for further information:<= /div>
OASIS Technical Committee administration
[the rev= iew comments will be monitored by davi= d.filip@ul.ie on this list]

</end of the registration template>

=A0=A0


Dr. David Filip
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone:=A0+353-6120-2781
cellphone: +353-86-02= 22-158
facsimile:=A0+353-6120-2734
--001a11c2036415c68e04f0a26e5f--