Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982F621F8505 for ; Tue, 19 Jul 2011 09:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=-2.400, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZJwAFH76DRm for ; Tue, 19 Jul 2011 09:16:29 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id B66F121F84F9 for ; Tue, 19 Jul 2011 09:16:28 -0700 (PDT) Received: (qmail invoked by alias); 19 Jul 2011 16:16:27 -0000 Received: from dslb-094-222-156-152.pools.arcor-ip.net (EHLO HIVE) [94.222.156.152] by mail.gmx.net (mp069) with SMTP; 19 Jul 2011 18:16:27 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19D81k2tudD9xSB2XjGmH4sxaNtyQtDwh/z0FArkR unqQRQy6mboyy3 From: Bjoern Hoehrmann To: stbryant@cisco.com Date: Tue, 19 Jul 2011 18:16:52 +0200 Message-ID: References: <4DFB534C.6010606@cisco.com> <4E259AAD.60603@cisco.com> In-Reply-To: <4E259AAD.60603@cisco.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: draft-ietf-sidr-rescerts-provisioning@tools.ietf.org, ietf-types@ietf.org Subject: Re: [ietf-types] Review requested for draft-ietf-sidr-rescerts-provisioning X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 16:16:33 -0000 * Stewart Bryant wrote: >Please can I request a review of application/rpki-updown >as specified in draft-ietf-sidr-rescerts-provisioning You've previously asked for a review of application/rpki-manifest and application/rpki-roa. application/rpki-updown has the same problems I already pointed out for the other types. Archives of comments are at: http://www.ietf.org/mail-archive/web/ietf-types/current/maillist.html -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B452A21F889D for ; Tue, 19 Jul 2011 07:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.541 X-Spam-Level: X-Spam-Status: No, score=-110.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jF6qvawdb3bV for ; Tue, 19 Jul 2011 07:54:54 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 69BED21F873D for ; Tue, 19 Jul 2011 07:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=1019; q=dns/txt; s=iport; t=1311087294; x=1312296894; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=LY6dN9JLSsGfUUZgNlnFW91Zsq9E5Bt7iItKZGmSj1w=; b=D5nFN0dWBCv4PiQkZJbFqKClNrayDq6lzLj6g7p03Tyonooa/LNk0ftz qNrAibZROOJO3DM6+ehqoSYx7Nxp0heaDEmdG06gBUh0eMTudWBl+0DSR gfwKTkhkv0MqRZfIVbuuWJHSMGcWXQTkr5AtRx0qTX3llA6jQH2tdn6mG Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAHAHeaJU6Q/khM/2dsb2JhbABUhEqUAY8Cd64XgxUPAYl3kTGBK4QCgQ8EkmeQWw X-IronPort-AV: E=Sophos;i="4.67,228,1309737600"; d="scan'208";a="103279079" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 19 Jul 2011 14:54:52 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6JEsc55002395; Tue, 19 Jul 2011 14:54:52 GMT Received: from dhcp-gpk02-vlan300-64-103-65-77.cisco.com (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p6JEsbiW029425; Tue, 19 Jul 2011 15:54:37 +0100 (BST) Message-ID: <4E259AAD.60603@cisco.com> Date: Tue, 19 Jul 2011 15:54:37 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: ietf-types@ietf.org References: <4DFB534C.6010606@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-sidr-rescerts-provisioning@tools.ietf.org Subject: [ietf-types] Review requested for draft-ietf-sidr-rescerts-provisioning X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 14:54:58 -0000 Please can I request a review of application/rpki-updown as specified in draft-ietf-sidr-rescerts-provisioning ====== 5.1. application/rpki-updown MIME media type name: application MIME subtype name: rpki-updown Required parameters: None Optional parameters: None Encoding considerations: binary Security considerations: Carries an RPKI Provisioning Protocol Message, as defined in this document. Interoperability considerations: None Published specification: This document Applications which use this media type: HTTP [RFC5652] Additional information: Magic number(s): None File extension(s): Macintosh File Type Code(s): Person & email address to contact for further information: Geoff Huston Intended usage: COMMON Author/Change controller: Geoff Huston ======= The document is currently on the IESG agenda for 25th August. Thanks Stewart Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0D621F8570 for ; Mon, 18 Jul 2011 12:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.279 X-Spam-Level: X-Spam-Status: No, score=-9.279 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ew9CGIirbAxy for ; Mon, 18 Jul 2011 12:41:14 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id C394C21F856C for ; Mon, 18 Jul 2011 12:41:14 -0700 (PDT) Received: from ylafon by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1Qitgn-0002Qx-9j; Mon, 18 Jul 2011 15:41:13 -0400 Date: Mon, 18 Jul 2011 15:41:13 -0400 (EDT) From: Yves Lafon To: Bjoern Hoehrmann In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: public-ws-resource-access-comments@w3.org, ietf-xml-mime@imc.org, ietf-types@ietf.org Subject: Re: [ietf-types] Request for review: application/evd+xml media type X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 19:41:15 -0000 On Thu, 7 Jul 2011, Bjoern Hoehrmann wrote: Thanks Bj=F6rn, here is the revised version of the media type definition: Type name: application Subtype name: evd+xml Required parameters: none Optional parameters: charset This parameter has identical semantics to the charset parameter of the= =20 'application/xml' media type as specified in [RFC 3023]. Encoding considerations: Identical to those of 'application/xml' as described in [RFC 3023],=20 section 3.2, as applied to the EventDescriptions document. Security considerations: Same as that of Section 10 in [RFC 3023]. Interoperability considerations: There are no known interoperability issues. Published specification: Web Services Event Descriptions (this specification). Applications which use this media type: No known applications currently use this media type. Additional Information: Magic number(s): None. File extension(s): evd Fragment identifiers: An EventDescriptions fragment identifier references a particular Event= =20 Type within an EventDescriptions document. The Event Type referenced is=20 the Event Type with the @id attribute whose normalized value (per=20 [xml:id]) equals that of the fragment identifier component. For example, if the EventDescriptions document from Example 4-1 were= =20 located at "http://www.example.com/eventtypes/oceanwatch", the following=20 URI references the Event Type defined in lines 12-14:=20 http://www.example.com/eventtypes/oceanwatch#WindReportEvent. Macintosh file type code(s): No Macintosh file type code defined. Person and email address to contact for further information: World Wide Wed Consortium Intended usage: COMMON Restrictions on usage: none. Author/Change controller: The WS-EventDescriptions specification is a work product of the World= =20 Wide Web Consortium's Web Service Resource Access Working Group. The W3C=20 has change control over these specifications. > * Yves Lafon wrote: >> Here is the registration document for the application/evd+xml media >> type [1] by the W3C Web Services Resource Access Working Group [2]. > > Has this been submitted before? It seems to me that the document has had > Candidate Recommendation status for a couple of months, and W3C policy > is to submit on entering Last Call, but there is nothing in my archives. > >> <<< >> This appendix defines the 'application/evd+xml' media type which can be >> used to describe EventDescription documents serialized as XML. >> >> MIME media type name: > > You are using an outdated template, the current template is in RFC 4288. > The current templates structures and names some fields differently. > >> Security considerations: >> >> none > > Well, at the very least you should point out that the ones in RFC 3023 > are likely to apply to implementations of the specific type here aswell. > >> Interoperability considerations: >> >> There are non known interoperability issues. > > This looks like a typo. > >> Fragment identifiers: >> An EventDescriptions fragment identifier references a particular Eve= nt >> Type within an EventDescriptions document. The Event Type referenced is >> the Event Type with the @id attribute whos value equals that of the >> fragment identifier component. > > In addition to the typo, this seems insufficient and I am not sure how > compatible this is other types and what some people would like to change > the existing specifications to. I note in particular that you don't say > whether for instance "#x" would match id=3D' x ' (note the spaces); I als= o > note that you don't define the `id` attribute as ID attribute and don't > say how this works for actual ID attributes or magic ones like xml:id. This has been clarified, both in the media type definition and in the=20 schema associated. >> Base URI: >> As specified in [RFC 3023] section 6. > > The only reason to include this that I can think of is to mislead people > into thinking RFC 3023 has anything to say on that even though it does > not. If you don't want to say anything about Base URIs, then don't. --=20 Baroula que barouleras, au ti=E9u toujou t'entourneras. ~~Yves Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA9921F8AB8; Thu, 14 Jul 2011 17:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncAJXqDf8utO; Thu, 14 Jul 2011 17:34:19 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA4421F8888; Thu, 14 Jul 2011 17:34:18 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:ca2a:14ff:fe11:4ca8] (unknown [IPv6:2001:dc0:a000:4:ca2a:14ff:fe11:4ca8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 61049B68D5; Fri, 15 Jul 2011 10:34:16 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: George Michaelson In-Reply-To: <4DFF2579.2080009@cisco.com> Date: Fri, 15 Jul 2011 10:34:16 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DFB534C.6010606@cisco.com> <4DFF2579.2080009@cisco.com> To: stbryant@cisco.com X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Sat, 16 Jul 2011 10:48:00 -0700 Cc: draft-ietf-sidr-repos-struct@tools.ietf.org, "iesg@ietf.org" , ietf-types@ietf.org Subject: Re: [ietf-types] Review requested for draft-ietf-sidr-repos-struct X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 00:34:20 -0000 As a co-author of the draft, can I get some quality time with people to = work out the following 1) what is the minimum cost text change to the draft(s) which will = satisfy the types registry people about language about the types issue 2) can we confirm a process that I, as a complete NEOPHYTE can use to = request/registr the appropriate types and associated (meta) data about = them 3) Can we please PLEASE avoid descent into some god-awful ontological = discussion about the language being used herre, because this is a very = late stage change in a process which we've tried very hard not to get = side-tracked on. In that context, I think its understood that we have 4 basic file = objects being represented and shared in the repository system a) certificates, expressed as ASN.1 encoded binary data in files = of nameform .cer b) CRLs in classic RFC5280 form in files of nameform .crl c) Manifests, ASN1 structures which complement CRLs, in files of = nameform .mnf d) the first of an expected growing family of binary signed = objects (CMS) specific in context to the needs of RPKI as a space of = signed data. This object is the ROA, the Route Origin Attestation, in a = file of nameform .roa so we have .cer, .crl, .mnf, and .roa.=20 It is understood that drafts either in progress, or forseeable will be = defining new types of signed objects reflecting extra data involved in = s-BGP, or other activities. I have no role to play in that document = process so I am not trying to pre-empt what they need, but arguably it = will be additional file types, and therefore registered type-names. Guys, can you just help me 'get over the hump' on this? -George On 20/06/2011, at 8:48 PM, Stewart Bryant wrote: >=20 > Hi Paul >=20 > Thank you for the suggestion. >=20 > RTG will follow IETF best practice on this and to that end > I will take the advice of my IESG colleges who are have > more experience with ietf-types. >=20 > - Stewart >=20 >=20 > On 18/06/2011 21:37, Paul Libbrecht wrote: >> Stewart, >>=20 >> would you consider adding information in this registration request = about names of the clipboard flavors? >> My modest experience has shown me that importing files with = certificates is rather a painful approach but drag-and-dropping or = copy-and-pasting them worked much better. >>=20 >> If you agree, I would suggest a Windows Flavor Name (e.g. "RPKI = Manifest") and Macintosh Uniform Type Identifier (e.g. = "public.rpki.manifest"). >>=20 >> paul >>=20 >>=20 >> Le 17 juin 2011 =E0 15:14, Stewart Bryant a =E9crit : >>=20 >>> draft-ietf-sidr-repos-struct >>>=20 >>> https://datatracker.ietf.org/doc/draft-ietf-sidr-repos-struct/ >>>=20 >>> Makes the following types request. >>>=20 >>> Review comments by 1 July would be appreciated. >>>=20 >>> Many thanks >>>=20 >>> - Stewart >>>=20 >>>=20 >>>=20 >>> 7.1.1. application/rpki-manifest >>>=20 >>> MIME media type name: application >>> MIME subtype name: rpki-manifest >>> Required parameters: None >>> Optional parameters: None >>> Encoding considerations: binary >>> Security considerations: Carries a RPKI Manifest >>> [I-D.ietf-sidr-rpki-manifests]. >>> Interoperability considerations: None >>> Published specification: This document >>> Applications which use this media type: Any MIME-complaint = transport >>> Additional information: >>> Magic number(s): None >>> File extension(s): .mft >>> Macintosh File Type Code(s): >>> Person& email address to contact for further information: Geoff >>> Huston >>> Intended usage: COMMON >>> Author/Change controller: Geoff Huston >>>=20 >>> 7.1.2. application/rpki-roa >>>=20 >>> MIME media type name: application> >>> MIME subtype name: rpki-roa >>> Required parameters: None >>> Optional parameters: None >>> Encoding considerations: binary >>> Security considerations: Carries a RPKI ROA >>> [I-D.ietf-sidr-roa-format] >>> Interoperability considerations: None >>>=20 >>> Huston, et al. Expires December 10, 2011 [Page = 12] >>> Internet-Draft ResCert Repository Structure June = 2011 >>>=20 >>> Published specification: This document >>> Applications which use this media type: Any MIME-complaint = transport >>> Additional information: >>> Magic number(s): None >>> File extension(s): .roa >>> Macintosh File Type Code(s): >>> Person& email address to contact for further information: Geoff >>> Huston >>> Intended usage: COMMON >>> Author/Change controller: Geoff Huston >>>=20 >>> _______________________________________________ >>> ietf-types mailing list >>> ietf-types@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-types >>=20 >=20 >=20 > --=20 > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF50321F8D93 for ; Thu, 14 Jul 2011 10:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.515 X-Spam-Level: X-Spam-Status: No, score=-103.515 tagged_above=-999 required=5 tests=[AWL=1.084, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hKs+4T7Ua8J for ; Thu, 14 Jul 2011 10:18:45 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A656721F8D8D for ; Thu, 14 Jul 2011 10:18:45 -0700 (PDT) Received: from dhcp-64-101-72-201.cisco.com (unknown [64.101.72.201]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A7C37410EE; Thu, 14 Jul 2011 11:19:10 -0600 (MDT) Message-ID: <4E1F24F2.2050409@stpeter.im> Date: Thu, 14 Jul 2011 11:18:42 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Paul Libbrecht References: <4DFB534C.6010606@cisco.com> <4E15ECD9.5050706@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: draft-ietf-sidr-repos-struct@tools.ietf.org, ietf-types@ietf.org Subject: Re: [ietf-types] Review requested for draft-ietf-sidr-repos-struct X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 17:18:50 -0000 On 7/8/11 5:37 AM, Paul Libbrecht wrote: > Hello Peter, > > > Le 7 juil. 2011 à 19:28, Peter Saint-Andre a écrit : > >> On 6/18/11 2:37 PM, Paul Libbrecht wrote: >>> would you consider adding information in this registration >>> request about names of the clipboard flavors? My modest >>> experience has shown me that importing files with certificates is >>> rather a painful approach but drag-and-dropping or >>> copy-and-pasting them worked much better. >> >> Stewart can clarify the matter for us, but as far as I can see >> RPKI certificates, manifest files, and route origin authorizations >> aren't exactly the kind of things that would be imported and >> exported by end users, since they are used for improved security of >> BGP routing (not web sites, email messages, and the like)... >> http://tools.ietf.org/html/draft-ietf-sidr-arch-13 >> http://tools.ietf.org/html/draft-ietf-sidr-rpki-manifests-13 >> http://tools.ietf.org/html/draft-ietf-sidr-roa-format-12 >> >> Is there really a use case for copying such entities to the >> clipboard of an end-user-oriented operating system such as Windows >> of Macintosh? > > I leave to you the probability, I still feel it's better to have a > name agreed-upon even if not used of use now. Administrating such a > router is a matter of "editing a config". My experience was with > certificates for end user to go in and out of the certificate store > on Mac. Right, but these are not certificates for end users, they're RPKI (not normal PKI) certificates for routers, plus associated manifest files and route origin authorizations. I don't see the potential for much if any user interaction with these beasts. Authors? >> If there is such a use case, then I have one further question... >> >>> If you agree, I would suggest a Windows Flavor Name (e.g. "RPKI >>> Manifest") and Macintosh Uniform Type Identifier (e.g. >>> "public.rpki.manifest"). >> >> The following UTIs make sense to me (if we decide that we need >> them). >> >> For the application/rpki-manifest media type... >> >> Macintosh file type code(s): A uniform type identifier (UTI) of >> "public.rpki.manifest" is suggested. > > You are mistaking Macintosh file type code(s) which is the pre-MacOSX > Apple-owned registry of four-letter codes for file-types and > clipboard types. This is all dead now as far as I know. You're right, the Macintosh file type codes are old-style things: http://support.apple.com/kb/TA25699?viewlocale=en_US > What is not dead is that clipboard flavours are named using a simple > string in Windows and uniform type identifier for MacOSX. I believe > adding the two lines (per declaration) avoids attempts of naming > things that are put in clipboard. > >> For the application/rpki-roa media type... >> >> Macintosh file type code(s): A uniform type identifier (UTI) of >> "public.rpki.roa" is suggested. >> >> However, it's not clear to me what you mean by a Windows Flavor >> Name, and I don't see examples of that in any existing media type >> registrations at iana.org or in RFCs. There is one example in the >> MathML spec: >> >> http://www.w3.org/TR/2009/WD-MathML3-20090604/chapter6.html >> >> Could you clarify where you think such a definition would go in an >> IANA registration? > > Correct, MathML is such an example. SVG as well: > http://www.w3.org/TR/SVG/mimereg.html and a few others (not many yet > indeed). > > I have unfortunately not been able to find a specification for the > Windows flavor names. The closest URL at MSDN, as of today, is > http://msdn.microsoft.com/en-us/library/ms649049.aspx I'd prefer not to add things to IANA registrations for which there is no precedent in the IETF, and no real documentation. Other folks on the ietf-types list might have different opinions, but I've not seen any discussion about Windows flavor names or Macintosh uniform type identifier on this list over the last few years. Furthermore, I'm not even sure where such information would go in the registration template per RFC 4288. Perhaps in the interoperability considerations, although my understanding has always been that those are supposed to cover known problems with interop. As far as I know, there are no such issues with the media types being registered. Peter -- Peter Saint-Andre https://stpeter.im/ Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED49511E8163 for ; Mon, 11 Jul 2011 12:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.041 X-Spam-Level: X-Spam-Status: No, score=-102.041 tagged_above=-999 required=5 tests=[AWL=-2.343, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MANGLED_WORKNG=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5Z8-67qx+PX for ; Mon, 11 Jul 2011 12:13:12 -0700 (PDT) Received: from pechora3.lax.icann.org (pechora3.icann.org [208.77.188.38]) by ietfa.amsl.com (Postfix) with ESMTP id 2F80911E8114 for ; Mon, 11 Jul 2011 12:13:12 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id p6BJCYne032359 for ; Mon, 11 Jul 2011 12:12:56 -0700 Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO600BJWNAO9L@szxga05-in.huawei.com> for ietf-types@iana.org; Tue, 12 Jul 2011 02:56:48 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO600JU2NAMY5@szxga05-in.huawei.com> for ietf-types@iana.org; Tue, 12 Jul 2011 02:56:48 +0800 (CST) Received: from windows8d787f9 (bzq-79-179-32-59.red.bezeqint.net [79.179.32.59]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LO600LEINA6NV@szxml12-in.huawei.com>; Tue, 12 Jul 2011 02:56:46 +0800 (CST) Date: Mon, 11 Jul 2011 21:53:58 +0300 From: Roni Even To: ietf-types@iana.org Message-id: <00c201cc3ffb$ec0da480$c428ed80$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_kUZGE9fzU915ZZLtux4GQQ)" Content-language: en-us Thread-index: Acw/++NrLX+2OlvpS3OJHyUSrZ73ag== X-Greylist: Delayed for 00:15:45 by milter-greylist-4.0 (pechora3.lax.icann.org [208.77.188.38]); Mon, 11 Jul 2011 12:12:56 -0700 (PDT) Cc: draft-ietf-payload-rfc3189bis.all@tools.ietf.org, "'Ali C. Begen \(abegen\)'" , payload@ietf.org Subject: [ietf-types] Updating the registration of audio and video DV media subtype X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 19:13:14 -0000 This is a multi-part message in MIME format. --Boundary_(ID_kUZGE9fzU915ZZLtux4GQQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, draft-ietf-payload-rfc3189bis-01 has passed Working Group Last Call in the Payload Working Group. Note that it an update to existing RFC3189 registrations http://www.iana.org/assignments/rtp-parameters for DV media subtype. The new registrations are in Section 3.1 of the document. http://tools.ietf.org/html/draft-ietf-payload-rfc3189bis-01#section-3.1 The information is also available below. I noticed that there is a need to change the change controller from " IETF Audio/Video Transport working group delegated from the IESG" to " IETF Payload working group delegated from the IESG" Other comments on the registration are welcome. Thanks Roni Even Payload co-chair 3.1.1. Media Type Registration for DV Video Type name: video Subtype name: DV Required parameters: encode: type of DV format. Permissible values for encode are SD-VCR/525-60, SD-VCR/625-50, HD-VCR/1125-60, HD-VCR/1250-50, SDL-VCR/525-60, SDL-VCR/625-50, 314M-25/525-60, 314M-25/625-50, 314M-50/525-60, 314M-50/625-50, 370M/1080-60i, 370M/1080-50i, 370M/720-60p, 370M/720-50p, 306M/525-60 (for backward compatibility), and 306M/625-50 (for backward compatibility). Optional parameters: audio: whether the DV stream includes audio data or not. Permissible values for audio are bundled and none. Defaults to none. Encoding considerations: DV video can be transmitted with RTP as specified in RFCXXXX(This document). Other transport methods are not specified. Security considerations: See Section 4 of RFCXXXX (This document). Interoperability considerations: NONE Public specification: IEC 61834 Standard SMPTE 314M SMPTE 370M RFCXXXX (This document) SMPTE 306M (for backward compatibility). Applications that use this media type: Audio and video streaming and conferencing tools. Additional information: NONE Person & email address to contact for further information: Katsushi Kobayashi e-mail: ikob@ni.aist.go.jp Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550). Transfer within other framing protocols is not defined at this time. Author: Katsushi Kobayashi Change controller: IETF Audio/Video Transport working group delegated from the IESG 3.1.2. Media Type Registration for DV Audio Type name: audio Subtype name: DV Required parameters: encode: type of DV format. Permissible values for encode are SD-VCR/525-60, SD-VCR/625-50, HD-VCR/1125-60, HD-VCR/1250-50, SDL-VCR/525-60, SDL-VCR/625-50, 314M-25/525-60, 314M-25/625-50, 314M-50/525-60, 314M-50/625-50, 370M/1080-60i, 370M/1080-50i, 370M/720-60p, 370M/720-50p, 306M/525-60 (for backward compatibility), and 306M/625-50 (for backward compatibility). Optional parameters: audio: whether the DV stream includes audio data or not. Permissible values for audio are bundled and none. Defaults to none. Encoding considerations: DV audio can be transmitted with RTP as specified in RFCXXXX(This document). Other transport methods are not specified. Security considerations: See Section 4 of RFCXXXX (This document). Interoperability considerations: NONE Published specification: IEC 61834 Standard SMPTE 314M SMPTE 370M RFCXXXX (This document) SMPTE 306M (for backward compatibility). Applications that use this media type: Audio and video streaming and conferencing tools. Additional information: NONE Person & email address to contact for further information: Katsushi Kobayashi e-mail: ikob@ni.aist.go.jp Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550). Transfer within other framing protocols is not defined at this time. Author: Katsushi Kobayashi Change controller: IETF Audio/Video Transport working group delegated from the IESG --Boundary_(ID_kUZGE9fzU915ZZLtux4GQQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

 

draft-ietf-payload-rfc3189bis-01 has passed Working Group Last Call in the Payload Working Group.

 

Note that it an update to existing RFC3189 registrations http://www.iana.org/assignments/rtp-parameters for DV media subtype.

 

The new registrations are in Section 3.1 of the document. http://tools.ietf.org/html/draft-ietf-payload-rfc3189bis-01#section-3.1

nbsp;

The information is also available below.

 

I noticed that there is a need to change the change controller from " IETF Audio/Video Transport working group delegated from the   IESG"  to " IETF Payload  working group delegated from the   IESG"

 

 

Other comments on the registration are welcome.

 

Roni Even

Payload co-chair

 

 

3.1.1.  Media Type Registration for DV Video

  

 

Type name:  video

 

   Subtype name:  DV

 

 

      encode:  type of DV format.  Permissible values for encode are

         SD-VCR/525-60,

         SD-VCR/625-50,

         HD-VCR/1125-60,

         HD-VCR/1250-50,

  &nbs! p; & DL-VCR/525-60,

         SDL-VCR/625-50,

         314M-25/525-60,

         314M-25/625-50,

         314M-50/525-60,

         314M-50/625-50,

         370M/1080-60i,

&nbs! p; & bsp;  370M/1080-50i,

         370M/720-60p,

         370M/720-50p,

         306M/525-60 (for backward compatibility),

         and 306M/625-50 (for backward compatibility).

 

   Optional parameters:

 

      audio:  whether the DV stream includes audio data or not.

         Permissible values for audio are bundled and none.  Defaults to  none.

 

   Encoding considerations:

 

         DV video can be transmitted with RTP as specified in RFCXXXX(This document).  Other transport methods are not specified.

    Security considerations:

 

         See Section 4 of RFCXXXX (This document).

 

   Interoperability considerations:  NONE

 

   Public specification:

 

     &nb! sp;  FR style='font-family:"Courier New"'>IEC 61834 Standard

         SMPTE 314M

         SMPTE 370M

         RFCXXXX (This document)

         SMPTE 306M (for backward compatibility).

 

   Applications that use this media type:  Audio and video ! streaming o:p>

 

   Additional information:  NONE

 

   Person & email address to contact for further information:

 

         Katsushi Kobayashi

 

         e-mail: ikob@ni.aist.go.jp

 

   Intended usage:  COMMON

 

   Restrictions on usage:  This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550).  Transfer within other framing protocols is not defined at this time.

 

   Author:

 

         Katsushi Kobayashi

< n style='font-family:"Courier New"'> 

   Change controller:

 

         IETF Audio/Video Transport working group delegated from the

         IESG

 

 

3.1.2.  Media Type Registration for DV Audio

 <    Type name:  audio

 

   Subtype name:  DV

 

   Required parameters:

 

      encode:  type of DV format.  Permissible values for encode are

         SD-VCR/525-60,

         HD-VCR/1125-60,

         HD-VCR/1250-50,

         SDL-VCR/525-60,

         SDL-VCR/625-50,

         314M-25/525-60,

         314M-25/625-50,

         314M-50/625-50,

         370M/1080-60i,

         370M/1080-50i,

         370M/720-60p,

         370M/720-50p,

         306M/525-60 (for backward compatibility),

         and 306M/625-50 (for backward compatibility).

 

   Optional parameters:

 

      audio:  whether the DV stream includes audio data or not.

         Permissible values for audio are bundled and none.  Defaults to none.

 

   Encodi! ng consid n>

 

         DV audio can be transmitted with RTP as specified in RFCXXXX(This document).  Other transport methods are not specified.

 

   Security considerations:

 

         See Section 4 of RFCXXXX (This document).

 

 &n! bsp; Inte ns:  NONE

 

   Published specification:

 

         IEC 61834 Standard

         SMPTE 314M

         SMPTE 370M

         RFCXXXX (This document)!

         SMPTE 306M (for backward compatibility).

 

   Applications that use this media type:  Audio and video streaming and conferencing tools.

 

   Additional information:  NONE

 

   Person & email address to contact for further information:

         Katsushi Kobayashi

 

         e-mail: ikob@ni.aist.go.jp

 

   Intended usage:  COMMON

 

   Restrictions on usage:  This media type depends on RTP framing, and hence is only defined for transfer via RTP (RFC 3550).  Transfer      within other framing! protocol time.

 

 

   Author:

 

         Katsushi Kobayashi

 

   Change controller:

 

         IETF Audio/Video Transport work! ing group /o:p>

         IESG

 

 

--Boundary_(ID_kUZGE9fzU915ZZLtux4GQQ)-- Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C92121F8CE8 for ; Fri, 8 Jul 2011 13:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.966 X-Spam-Level: X-Spam-Status: No, score=-102.966 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNo+4X5ZvZlI for ; Fri, 8 Jul 2011 13:23:54 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF0F21F8D00 for ; Fri, 8 Jul 2011 13:23:54 -0700 (PDT) Received: by pzk5 with SMTP id 5so2319452pzk.31 for ; Fri, 08 Jul 2011 13:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=XhrtXhs4W6W2velUrWgC0E7ROMw7Mpx53Kfc/ol6OAQ=; b=OYX/WYefYAMnK9AJupppycsHwaUvEb4M3ZO2LCx7avW3bRy/bOv15ZBttBLz2nbstz TONw+7KabFzLGMaIdAEEdxcD0oJeAhyEVOSAwGDDpWm+8jC95YC6VOpSZX2cdqsVQkTF TG3uhzx9Gt/m3d3PYJDCV3BngmutOd0EQYztY= Received: by 10.142.150.13 with SMTP id x13mr496159wfd.294.1310156634124; Fri, 08 Jul 2011 13:23:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.88.9 with HTTP; Fri, 8 Jul 2011 13:23:34 -0700 (PDT) In-Reply-To: References: From: Frank Ellermann Date: Fri, 8 Jul 2011 22:23:34 +0200 Message-ID: To: Yves Lafon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: public-ws-resource-access-comments@w3.org, ietf-xml-mime@imc.org, ietf-types@ietf.org Subject: Re: [ietf-types] Request for review: application/evd+xml media type X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 20:23:55 -0000 On 7 July 2011 15:47, Yves Lafon wrote: > Published specification: > =A0 =A0Web Services Event Descriptions (this specification). Just in case an obvious point, this would appear "as is" (out of a "this" context) in the registry, better use an URI when you fix Bj=F6rn's nits. -Frank Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29FA21F89A0 for ; Fri, 8 Jul 2011 04:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVIU2Gqxkh57 for ; Fri, 8 Jul 2011 04:37:48 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9718421F87CC for ; Fri, 8 Jul 2011 04:37:48 -0700 (PDT) Received: from ip-77-25-194-164.web.vodafone.de (ip-77-25-194-164.web.vodafone.de [77.25.194.164]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0Lg4uF-1RKVsu1qKR-00pF0S; Fri, 08 Jul 2011 13:37:40 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Paul Libbrecht In-Reply-To: <4E15ECD9.5050706@stpeter.im> Date: Fri, 8 Jul 2011 13:37:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DFB534C.6010606@cisco.com> <4E15ECD9.5050706@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:DoVY9CPDD1VD9fb0nBnN9BDAyegZYRnYoWFe1Suk7gM 06Fq3zP+YTOkbD3Dy6s1ORmbWxODB/QtPZf/7VObgpfWI9QZZa +balLsaIrUTIBual+uF/D9ChWY5TWuqH1o0E8eC8PX07nKxYgs W8AOspiDPdVGezbhlsWclLNJXMLsJ5cQR2+w7UJuVJGLrlgOQQ 3PPUxcaHnL4DH744P1LKsfkVtVUhr4MorN2q4E/fFY= Cc: draft-ietf-sidr-repos-struct@tools.ietf.org, ietf-types@ietf.org Subject: Re: [ietf-types] Review requested for draft-ietf-sidr-repos-struct X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 11:37:49 -0000 Hello Peter, Le 7 juil. 2011 =E0 19:28, Peter Saint-Andre a =E9crit : > On 6/18/11 2:37 PM, Paul Libbrecht wrote: >> would you consider adding information in this registration request >> about names of the clipboard flavors? My modest experience has shown >> me that importing files with certificates is rather a painful >> approach but drag-and-dropping or copy-and-pasting them worked much >> better. >=20 > Stewart can clarify the matter for us, but as far as I can see RPKI > certificates, manifest files, and route origin authorizations aren't > exactly the kind of things that would be imported and exported by end > users, since they are used for improved security of BGP routing (not = web > sites, email messages, and the like)... > http://tools.ietf.org/html/draft-ietf-sidr-arch-13 > http://tools.ietf.org/html/draft-ietf-sidr-rpki-manifests-13 > http://tools.ietf.org/html/draft-ietf-sidr-roa-format-12 >=20 > Is there really a use case for copying such entities to the clipboard = of > an end-user-oriented operating system such as Windows of Macintosh? I leave to you the probability, I still feel it's better to have a name = agreed-upon even if not used of use now. Administrating such a router is a matter of "editing a config". My experience was with certificates for end user to go in and out of the = certificate store on Mac. > If there is such a use case, then I have one further question... >=20 >> If you agree, I would suggest a Windows Flavor Name (e.g. "RPKI >> Manifest") and Macintosh Uniform Type Identifier (e.g. >> "public.rpki.manifest"). >=20 > The following UTIs make sense to me (if we decide that we need them). >=20 > For the application/rpki-manifest media type... >=20 > Macintosh file type code(s): A uniform type identifier (UTI) of > "public.rpki.manifest" is suggested. You are mistaking Macintosh file type code(s) which is the pre-MacOSX = Apple-owned registry of four-letter codes for file-types and clipboard = types. This is all dead now as far as I know. What is not dead is that clipboard flavours are named using a simple = string in Windows and uniform type identifier for MacOSX. I believe adding the two lines (per declaration) avoids attempts of = naming things that are put in clipboard. > For the application/rpki-roa media type... >=20 > Macintosh file type code(s): A uniform type identifier (UTI) of > "public.rpki.roa" is suggested. >=20 > However, it's not clear to me what you mean by a Windows Flavor Name, > and I don't see examples of that in any existing media type > registrations at iana.org or in RFCs. There is one example in the = MathML > spec: >=20 > http://www.w3.org/TR/2009/WD-MathML3-20090604/chapter6.html >=20 > Could you clarify where you think such a definition would go in an = IANA > registration? Correct, MathML is such an example. SVG as well: http://www.w3.org/TR/SVG/mimereg.html and a few others (not many yet indeed). I have unfortunately not been able to find a specification for the = Windows flavor names.=20 The closest URL at MSDN, as of today, is = http://msdn.microsoft.com/en-us/library/ms649049.aspx=20 hope it helps. paul= Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC2A21F891A for ; Fri, 8 Jul 2011 02:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gU5kb7fzQrOy for ; Fri, 8 Jul 2011 02:16:16 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id B599C21F88FE for ; Fri, 8 Jul 2011 02:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=2469; q=dns/txt; s=iport; t=1310116575; x=1311326175; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=m9W/JI7se6V8a7xxQH19JDt/dAXzUkXBaD9AE7RqM/s=; b=LRwXgG5jDvkuR6FeLjE7aJFBmCte/QrBA3ydP+HKYYGOJppxLHhwhr/D ymEXZ6edO/nJ8EHM3bpqpTpbhCPZDAbUH4bRjxHFfyS4fYS4XH8YG3Aiz V97cJR8ybnFopSHM/k+cqXmgS7MUkfUCYGIVF2oAG9mfnHdQ9vqNZ6p3k A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPbJFk6Q/khR/2dsb2JhbABThEKjAXeuS4MVDwGJeJBrgSuEAIENBJJMkEU X-IronPort-AV: E=Sophos;i="4.65,498,1304294400"; d="scan'208";a="41202111" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 08 Jul 2011 09:16:14 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p689G61j032309; Fri, 8 Jul 2011 09:16:09 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id p689G4Rf002641; Fri, 8 Jul 2011 10:16:05 +0100 (BST) Message-ID: <4E16CB20.2060301@cisco.com> Date: Fri, 08 Jul 2011 10:17:20 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <4DFB534C.6010606@cisco.com> <4E15ECD9.5050706@stpeter.im> In-Reply-To: <4E15ECD9.5050706@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-sidr-repos-struct@tools.ietf.org, ietf-types@ietf.org Subject: Re: [ietf-types] Review requested for draft-ietf-sidr-repos-struct X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 09:16:16 -0000 On 07/07/2011 18:28, Peter Saint-Andre wrote: > Hi Paul, Stewart asked me to take a look at this issue... > > On 6/18/11 2:37 PM, Paul Libbrecht wrote: >> Stewart, >> >> would you consider adding information in this registration request >> about names of the clipboard flavors? My modest experience has shown >> me that importing files with certificates is rather a painful >> approach but drag-and-dropping or copy-and-pasting them worked much >> better. > Stewart can clarify the matter for us, but as far as I can see RPKI > certificates, manifest files, and route origin authorizations aren't > exactly the kind of things that would be imported and exported by end > users, since they are used for improved security of BGP routing (not web > sites, email messages, and the like)... > > http://tools.ietf.org/html/draft-ietf-sidr-arch-13 > http://tools.ietf.org/html/draft-ietf-sidr-rpki-manifests-13 > http://tools.ietf.org/html/draft-ietf-sidr-roa-format-12 > > Is there really a use case for copying such entities to the clipboard of > an end-user-oriented operating system such as Windows of Macintosh? Well, I can imagine that in configuring a router in an ops center cut/paste might be the method used. I will leave the next to the authors. Stewart > > If there is such a use case, then I have one further question... > >> If you agree, I would suggest a Windows Flavor Name (e.g. "RPKI >> Manifest") and Macintosh Uniform Type Identifier (e.g. >> "public.rpki.manifest"). > The following UTIs make sense to me (if we decide that we need them). > > For the application/rpki-manifest media type... > > Macintosh file type code(s): A uniform type identifier (UTI) of > "public.rpki.manifest" is suggested. > > For the application/rpki-roa media type... > > Macintosh file type code(s): A uniform type identifier (UTI) of > "public.rpki.roa" is suggested. > > However, it's not clear to me what you mean by a Windows Flavor Name, > and I don't see examples of that in any existing media type > registrations at iana.org or in RFCs. There is one example in the MathML > spec: > > http://www.w3.org/TR/2009/WD-MathML3-20090604/chapter6.html > > Could you clarify where you think such a definition would go in an IANA > registration? > > Thanks! > > Peter > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3429821F86BC for ; Thu, 7 Jul 2011 19:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.908 X-Spam-Level: X-Spam-Status: No, score=-104.908 tagged_above=-999 required=5 tests=[AWL=-2.309, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ig2o38z-FX5v for ; Thu, 7 Jul 2011 19:05:29 -0700 (PDT) Received: from pechora8.dc.icann.org (pechora8.icann.org [192.0.46.74]) by ietfa.amsl.com (Postfix) with ESMTP id E691721F8678 for ; Thu, 7 Jul 2011 19:05:28 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id p6824pJV004938 for ; Thu, 7 Jul 2011 22:05:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1861; q=dns/txt; s=iport; t=1310090712; x=1311300312; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=H2vmYQwIFaojUrSj55IyiIlCvOySUmYFDRlbCJP5BVY=; b=CUA1kQtUvj5GMAQWcMP9xc47UPQxMZn1I04CMqVHKDl51Kwh1Dz+5TF/ O0vkRTU/v1/FNweXHi5/CNASfjff6WWiV+riOPXmCWercmay5/jPkJ8qa 6KY+ObiJRLiri+X8mu/XGhUEx3CmzkkSfmWhwQX0//3jES61gT2wnYt+J Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANVkFk6rRDoG/2dsb2JhbABTpz53rmudeYY4BIdJinyEfIti X-IronPort-AV: E=Sophos;i="4.65,496,1304294400"; d="scan'208";a="889258" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-3.cisco.com with ESMTP; 08 Jul 2011 02:04:50 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6824m3g021230; Fri, 8 Jul 2011 02:04:48 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <2mjc179va7kqeh3qn9755immj91mdgug0n@hive.bjoern.hoehrmann.de> Date: Thu, 7 Jul 2011 20:04:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <71C1C9E3-27E5-43D5-801D-01256609DC79@cisco.com> References: <48AF46F9-5E4A-4D62-8DE0-EE6916D30F98@cisco.com> <21f1u6hael1utmpg3svvn2a6s3agncb5ov@hive.bjoern.hoehrmann.de> <45B798A3-37AD-49C9-99AC-A9B3A587B55A@cisco.com> <2mjc179va7kqeh3qn9755immj91mdgug0n@hive.bjoern.hoehrmann.de> To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1084) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Thu, 07 Jul 2011 22:05:12 -0400 (EDT) Cc: ietf-types@iana.org, P2PSIP Mailing List Subject: Re: [ietf-types] Registration of media type application/p2p-overlay+xml X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 02:05:29 -0000 On Jul 7, 2011, at 6:56 PM, Bjoern Hoehrmann wrote: > * Cullen Jennings wrote: > >We are mandating UTF-8 as the charset which gives us the benefits = would > >hope. We don't want to have multiple charsets supported as we have = noted > >this reduces interoperability when some implementations don't bother = to > >implement charsets other than UTF-8. It's arbitrary choice that > >increases what you need to implement and test, reduces = interoperability, > >and provides not benefits to the end user beyond what they get with > >UTF-8. >=20 > I am thinking about this situation: >=20 > Content-Type: application/p2p-overlay+xml;charset=3Diso-8859-2 >=20 > > ... >=20 > and I am comparing it to this situation: >=20 > Content-Type: application/xml;charset=3Diso-8859-2 >=20 > > ... >=20 > The question is how implementations determine the encoding. I am = saying > there should be no difference between the two cases, so long as you = use > the `+xml` convention and an `application` type. That would require to > either define a charset parameter, or remove the `+xml`. I do not care > whether some `application/p2p-overlay+xml` implementations only = support > UTF-8, I just do not want this to be the same as: >=20 > Content-Type: application/p2p-overlay+xml;dkjfashdkf=3Dsdjhfaskdjfhas >=20 > > ... >=20 > namely, an unrecognized parameter with an unrecognized value. We do use this in protocols that don't have a Content-Type header or = place to cary the chartset but I see your point with not wanting to = treat charset as an unknown parameter. Do you see any problem with = saying, if there is a chartset parameter, it MUST be UTF-8? Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D811621F88FE for ; Thu, 7 Jul 2011 17:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.663 X-Spam-Level: X-Spam-Status: No, score=-3.663 tagged_above=-999 required=5 tests=[AWL=-1.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GstKGf0OnOER for ; Thu, 7 Jul 2011 17:56:41 -0700 (PDT) Received: from pechora3.lax.icann.org (pechora3.icann.org [208.77.188.38]) by ietfa.amsl.com (Postfix) with ESMTP id A0C1421F8702 for ; Thu, 7 Jul 2011 17:56:38 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by pechora3.lax.icann.org (8.13.8/8.13.8) with SMTP id p680u1wP009813 for ; Thu, 7 Jul 2011 17:56:22 -0700 Received: (qmail invoked by alias); 08 Jul 2011 00:55:58 -0000 Received: from dslb-094-223-185-199.pools.arcor-ip.net (EHLO HIVE) [94.223.185.199] by mail.gmx.net (mp003) with SMTP; 08 Jul 2011 02:55:58 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/UCcI8lbjUEXVMFdICV/wxC6JqJ+FMMf0pho1p+Z PwgIio2R2yG2Vj From: Bjoern Hoehrmann To: Cullen Jennings Date: Fri, 08 Jul 2011 02:56:09 +0200 Message-ID: <2mjc179va7kqeh3qn9755immj91mdgug0n@hive.bjoern.hoehrmann.de> References: <48AF46F9-5E4A-4D62-8DE0-EE6916D30F98@cisco.com> <21f1u6hael1utmpg3svvn2a6s3agncb5ov@hive.bjoern.hoehrmann.de> <45B798A3-37AD-49C9-99AC-A9B3A587B55A@cisco.com> In-Reply-To: <45B798A3-37AD-49C9-99AC-A9B3A587B55A@cisco.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [208.77.188.38]); Thu, 07 Jul 2011 17:56:23 -0700 (PDT) Cc: ietf-types@iana.org, P2PSIP Mailing List Subject: Re: [ietf-types] Registration of media type application/p2p-overlay+xml X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 00:56:42 -0000 * Cullen Jennings wrote: >We are mandating UTF-8 as the charset which gives us the benefits would >hope. We don't want to have multiple charsets supported as we have noted >this reduces interoperability when some implementations don't bother to >implement charsets other than UTF-8. It's arbitrary choice that >increases what you need to implement and test, reduces interoperability, >and provides not benefits to the end user beyond what they get with >UTF-8. I am thinking about this situation: Content-Type: application/p2p-overlay+xml;charset=iso-8859-2 ... and I am comparing it to this situation: Content-Type: application/xml;charset=iso-8859-2 ... The question is how implementations determine the encoding. I am saying there should be no difference between the two cases, so long as you use the `+xml` convention and an `application` type. That would require to either define a charset parameter, or remove the `+xml`. I do not care whether some `application/p2p-overlay+xml` implementations only support UTF-8, I just do not want this to be the same as: Content-Type: application/p2p-overlay+xml;dkjfashdkf=sdjhfaskdjfhas ... namely, an unrecognized parameter with an unrecognized value. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2E221F8920 for ; Thu, 7 Jul 2011 17:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.99 X-Spam-Level: X-Spam-Status: No, score=-104.99 tagged_above=-999 required=5 tests=[AWL=-2.391, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNtX3bw6Bspy for ; Thu, 7 Jul 2011 17:23:26 -0700 (PDT) Received: from pechora8.dc.icann.org (pechora8.icann.org [192.0.46.74]) by ietfa.amsl.com (Postfix) with ESMTP id 11F7B21F871B for ; Thu, 7 Jul 2011 17:23:25 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by pechora8.dc.icann.org (8.13.8/8.13.8) with ESMTP id p680MoTw001331 for ; Thu, 7 Jul 2011 20:23:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2392; q=dns/txt; s=iport; t=1310084590; x=1311294190; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=T0L43djz0uTvmvIw+DvzbyLOKfpjzpj0NjN3wdO7IR0=; b=CxeIZ/CAFYYSTMpC4WU9q4jWcjgcnkWC8eUXLsIVtr3IZrSU4+i4roo6 I9T0nRK5ViHfgqoDQlRjMGX1gIemZT5FxWyLn5m78CaV0wu3GImtfCmXS nFLGc2iQiS9RDhgJ3Y7H5YYuMem9Ic/U0uJ415FJAHfoUrfMoSZMCCIgs M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACJNFk6rRDoG/2dsb2JhbABTpz53iHulTp10hjgEh0mKfIR8i2I X-IronPort-AV: E=Sophos;i="4.65,496,1304294400"; d="scan'208";a="870514" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-5.cisco.com with ESMTP; 08 Jul 2011 00:22:49 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p680Mlmf028568; Fri, 8 Jul 2011 00:22:48 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: <21f1u6hael1utmpg3svvn2a6s3agncb5ov@hive.bjoern.hoehrmann.de> Date: Thu, 7 Jul 2011 18:22:47 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <45B798A3-37AD-49C9-99AC-A9B3A587B55A@cisco.com> References: <48AF46F9-5E4A-4D62-8DE0-EE6916D30F98@cisco.com> <21f1u6hael1utmpg3svvn2a6s3agncb5ov@hive.bjoern.hoehrmann.de> To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1084) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.3 (pechora8.dc.icann.org [192.0.46.74]); Thu, 07 Jul 2011 20:23:10 -0400 (EDT) Cc: ietf-types@iana.org, P2PSIP Mailing List Subject: Re: [ietf-types] Registration of media type application/p2p-overlay+xml X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 00:23:26 -0000 On May 28, 2011, at 3:16 AM, Bjoern Hoehrmann wrote: > * Cullen Jennings wrote: > > To: ietf-types@iana.org > > > > Subject: Registration of media type application/p2p-overlay+xml >=20 > There is no reason to include this part in the specification. fixed - thanks =20 >=20 > > Type name: application > > > > Subtype name: p2p-overlay+xml > > > > Required parameters: none > > > > Optional parameters: none >=20 > Why are you using the +xml convention but do not specify the type in a > manner consistent with application/xml? I may have missed what part of 3023 part we violate but I read it and = could not see anything. Clearly the desire was to support UTF-8 which we = do.=20 > Without a very good reason I'd > think you should either add the "charset" parameter We are mandating UTF-8 as the charset which gives us the benefits would = hope. We don't want to have multiple charsets supported as we have noted = this reduces interoperability when some implementations don't bother to = implement charsets other than UTF-8. It's arbitrary choice that = increases what you need to implement and test, reduces interoperability, = and provides not benefits to the end user beyond what they get with = UTF-8.=20 > or drop the "+xml". It is xml so it seems like it is useful to use the +xml convention so = that systems that process that can use it.=20 >=20 > > Encoding considerations: Must be binary encoded. The contents = MUST > > be valid XML compliant with the relax NG grammar specified in RFC- > > AAAA and use the UTF-8[RFC3629] character encoding. >=20 > This should either just say "binary" or just reference RFC 3023 as RFC > 3023 suggests. Ok - removed this and moved it to additional info as it seems like = useful information.=20 >=20 > > Interoperability considerations: Same as application/xml as = defined > > in [RFC3023]. >=20 > If there are no known interoperability issues beyond those of the type > application/xml, that is what you should say; the considerations here > are certainly not the same. > -- > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 = http://bjoern.hoehrmann.de > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 = http://www.bjoernsworld.de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 = http://www.websitedev.de/ >=20 Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5082F21F87D9 for ; Thu, 7 Jul 2011 10:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iveZnRerK3mE for ; Thu, 7 Jul 2011 10:29:00 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6B47F21F8796 for ; Thu, 7 Jul 2011 10:29:00 -0700 (PDT) Received: from dhcp-64-101-72-207.cisco.com (unknown [64.101.72.207]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6A2E240F84; Thu, 7 Jul 2011 11:29:06 -0600 (MDT) Message-ID: <4E15ECD9.5050706@stpeter.im> Date: Thu, 07 Jul 2011 11:28:57 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Paul Libbrecht References: <4DFB534C.6010606@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-sidr-repos-struct@tools.ietf.org, ietf-types@ietf.org Subject: Re: [ietf-types] Review requested for draft-ietf-sidr-repos-struct X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 17:29:01 -0000 Hi Paul, Stewart asked me to take a look at this issue... On 6/18/11 2:37 PM, Paul Libbrecht wrote: > Stewart, > > would you consider adding information in this registration request > about names of the clipboard flavors? My modest experience has shown > me that importing files with certificates is rather a painful > approach but drag-and-dropping or copy-and-pasting them worked much > better. Stewart can clarify the matter for us, but as far as I can see RPKI certificates, manifest files, and route origin authorizations aren't exactly the kind of things that would be imported and exported by end users, since they are used for improved security of BGP routing (not web sites, email messages, and the like)... http://tools.ietf.org/html/draft-ietf-sidr-arch-13 http://tools.ietf.org/html/draft-ietf-sidr-rpki-manifests-13 http://tools.ietf.org/html/draft-ietf-sidr-roa-format-12 Is there really a use case for copying such entities to the clipboard of an end-user-oriented operating system such as Windows of Macintosh? If there is such a use case, then I have one further question... > If you agree, I would suggest a Windows Flavor Name (e.g. "RPKI > Manifest") and Macintosh Uniform Type Identifier (e.g. > "public.rpki.manifest"). The following UTIs make sense to me (if we decide that we need them). For the application/rpki-manifest media type... Macintosh file type code(s): A uniform type identifier (UTI) of "public.rpki.manifest" is suggested. For the application/rpki-roa media type... Macintosh file type code(s): A uniform type identifier (UTI) of "public.rpki.roa" is suggested. However, it's not clear to me what you mean by a Windows Flavor Name, and I don't see examples of that in any existing media type registrations at iana.org or in RFCs. There is one example in the MathML spec: http://www.w3.org/TR/2009/WD-MathML3-20090604/chapter6.html Could you clarify where you think such a definition would go in an IANA registration? Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39AC121F87B6 for ; Thu, 7 Jul 2011 08:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDFP3Y2EEWwh for ; Thu, 7 Jul 2011 08:22:07 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id A376E21F87A2 for ; Thu, 7 Jul 2011 08:22:07 -0700 (PDT) Received: from ylafon by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1QeqP0-0001ku-Iw; Thu, 07 Jul 2011 11:22:06 -0400 Date: Thu, 7 Jul 2011 11:22:06 -0400 (EDT) From: Yves Lafon To: Bjoern Hoehrmann In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: public-ws-resource-access-comments@w3.org, Bob Freund , ietf-xml-mime@imc.org, ietf-types@ietf.org Subject: Re: [ietf-types] Request for review: application/evd+xml media type X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 15:22:08 -0000 On Thu, 7 Jul 2011, Bjoern Hoehrmann wrote: > * Yves Lafon wrote: >> Here is the registration document for the application/evd+xml media >> type [1] by the W3C Web Services Resource Access Working Group [2]. > > Has this been submitted before? It seems to me that the document has had > Candidate Recommendation status for a couple of months, and W3C policy > is to submit on entering Last Call, but there is nothing in my archives. It hasn't, unfortunately. A missed step that we are trying to recover=20 from. >> <<< >> This appendix defines the 'application/evd+xml' media type which can be >> used to describe EventDescription documents serialized as XML. >> >> MIME media type name: > > You are using an outdated template, the current template is in RFC 4288. > The current templates structures and names some fields differently. > >> Security considerations: >> >> none > > Well, at the very least you should point out that the ones in RFC 3023 > are likely to apply to implementations of the specific type here aswell. > >> Interoperability considerations: >> >> There are non known interoperability issues. > > This looks like a typo. > >> Fragment identifiers: >> An EventDescriptions fragment identifier references a particular Eve= nt >> Type within an EventDescriptions document. The Event Type referenced is >> the Event Type with the @id attribute whos value equals that of the >> fragment identifier component. > > In addition to the typo, this seems insufficient and I am not sure how > compatible this is other types and what some people would like to change > the existing specifications to. I note in particular that you don't say > whether for instance "#x" would match id=3D' x ' (note the spaces); I als= o > note that you don't define the `id` attribute as ID attribute and don't > say how this works for actual ID attributes or magic ones like xml:id. > >> Base URI: >> As specified in [RFC 3023] section 6. > > The only reason to include this that I can think of is to mislead people > into thinking RFC 3023 has anything to say on that even though it does > not. If you don't want to say anything about Base URIs, then don't. > --=20 Baroula que barouleras, au ti=E9u toujou t'entourneras. ~~Yves Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E3921F885C for ; Thu, 7 Jul 2011 08:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.632 X-Spam-Level: X-Spam-Status: No, score=-3.632 tagged_above=-999 required=5 tests=[AWL=-1.633, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oM7ua4BtIbNt for ; Thu, 7 Jul 2011 08:13:26 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id BD81521F87A3 for ; Thu, 7 Jul 2011 08:13:24 -0700 (PDT) Received: (qmail invoked by alias); 07 Jul 2011 15:13:22 -0000 Received: from dslb-094-223-185-199.pools.arcor-ip.net (EHLO HIVE) [94.223.185.199] by mail.gmx.net (mp057) with SMTP; 07 Jul 2011 17:13:22 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/ROPYamV3RAGOrKGWz+XPZHwivQdecppCRx6ryTw BLzUAmtREXWjDW From: Bjoern Hoehrmann To: Yves Lafon Date: Thu, 07 Jul 2011 17:13:32 +0200 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: public-ws-resource-access-comments@w3.org, Bob Freund , ietf-xml-mime@imc.org, ietf-types@ietf.org Subject: Re: [ietf-types] Request for review: application/evd+xml media type X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 15:13:27 -0000 * Yves Lafon wrote: >Here is the registration document for the application/evd+xml media >type [1] by the W3C Web Services Resource Access Working Group [2]. Has this been submitted before? It seems to me that the document has had Candidate Recommendation status for a couple of months, and W3C policy is to submit on entering Last Call, but there is nothing in my archives. ><<< >This appendix defines the 'application/evd+xml' media type which can be >used to describe EventDescription documents serialized as XML. > >MIME media type name: You are using an outdated template, the current template is in RFC 4288. The current templates structures and names some fields differently. >Security considerations: > > none Well, at the very least you should point out that the ones in RFC 3023 are likely to apply to implementations of the specific type here aswell. >Interoperability considerations: > > There are non known interoperability issues. This looks like a typo. > Fragment identifiers: > An EventDescriptions fragment identifier references a particular Event >Type within an EventDescriptions document. The Event Type referenced is >the Event Type with the @id attribute whos value equals that of the >fragment identifier component. In addition to the typo, this seems insufficient and I am not sure how compatible this is other types and what some people would like to change the existing specifications to. I note in particular that you don't say whether for instance "#x" would match id=' x ' (note the spaces); I also note that you don't define the `id` attribute as ID attribute and don't say how this works for actual ID attributes or magic ones like xml:id. > Base URI: > As specified in [RFC 3023] section 6. The only reason to include this that I can think of is to mislead people into thinking RFC 3023 has anything to say on that even though it does not. If you don't want to say anything about Base URIs, then don't. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8734121F86C8 for ; Thu, 7 Jul 2011 06:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_111=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yc7DeZM5I-wX for ; Thu, 7 Jul 2011 06:47:51 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id B316221F85F5 for ; Thu, 7 Jul 2011 06:47:51 -0700 (PDT) Received: from ylafon by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1Qeovl-0001l4-P1; Thu, 07 Jul 2011 09:47:49 -0400 Date: Thu, 7 Jul 2011 09:47:49 -0400 (EDT) From: Yves Lafon To: ietf-types@ietf.org Message-ID: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: public-ws-resource-access-comments@w3.org, Bob Freund , ietf-xml-mime@imc.org Subject: [ietf-types] Request for review: application/evd+xml media type X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 13:47:52 -0000 All, Here is the registration document for the application/evd+xml media=20 type [1] by the W3C Web Services Resource Access Working Group [2]. Cheers, <<< This appendix defines the 'application/evd+xml' media type which can be=20 used to describe EventDescription documents serialized as XML. MIME media type name: application MIME subtype name: evd+xml Required parameters: none Optional parameters: charset This parameter has identical semantics to the charset parameter of the= =20 'application/xml' media type as specified in [RFC 3023]. Encoding considerations: Identical to those of 'application/xml' as described in [RFC 3023],=20 section 3.2, as applied to the EventDescriptions document. Security considerations: none Interoperability considerations: There are non known interoperability issues. Published specification: Web Services Event Descriptions (this specification). Applications which use this media type: No known applications currently use this media type. Additional Information: File extension: evd Fragment identifiers: An EventDescriptions fragment identifier references a particular Event= =20 Type within an EventDescriptions document. The Event Type referenced is=20 the Event Type with the @id attribute whos value equals that of the=20 fragment identifier component. For example, if the EventDescriptions document from Example 4-1 were= =20 located at "http://www.example.com/eventtypes/oceanwatch", the following=20 URI references the Event Type defined in lines 12-14:=20 http://www.example.com/eventtypes/oceanwatch#WindReportEvent. Base URI: As specified in [RFC 3023] section 6. Person and email address to contact for further information: World Wide Wed Consortium Intended usage: COMMON Author/Change controller: The WS-EventDescriptions specification is a work product of the World= =20 Wide Web Consortium's Web Service Resource Access Working Group. The W3C=20 has change control over these specifications. >>> [1] http://www.w3.org/TR/2011/CR-ws-event-descriptions-20110428/#EVD_MIME [2] http://www.w3.org/2002/ws/ra/ --=20 Baroula que barouleras, au ti=E9u toujou t'entourneras. ~~Yves Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1302321F85EB for ; Sun, 3 Jul 2011 16:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHWOqk+GV-eH for ; Sun, 3 Jul 2011 16:24:36 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 0C42821F85EA for ; Sun, 3 Jul 2011 16:24:35 -0700 (PDT) Received: (qmail invoked by alias); 03 Jul 2011 23:24:34 -0000 Received: from dslb-094-222-157-022.pools.arcor-ip.net (EHLO HIVE) [94.222.157.22] by mail.gmx.net (mp005) with SMTP; 04 Jul 2011 01:24:34 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18r4xtiOcUrezwKq3Gzt7Z8fjvj5NUl5oNSEFLRoE FY4NnoEQ8Ryqu3 From: Bjoern Hoehrmann To: Peter Saint-Andre Date: Mon, 04 Jul 2011 01:24:41 +0200 Message-ID: References: <4DFB534C.6010606@cisco.com> <4DFB6A27.2010500@stpeter.im> In-Reply-To: <4DFB6A27.2010500@stpeter.im> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: ietf-types@ietf.org Subject: Re: [ietf-types] outdated template (was: Re: Review requested for draft-ietf-sidr-repos-struct) X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 23:24:37 -0000 * Peter Saint-Andre wrote: >Bjoern, I notice that many of your reviews start with "this uses an >outdated template". Do we need to update pointers somewhere so that >people know which template to use? There are a number of things that are rather repetitive, but if we re- moved all of them, I would not offer any feedback at all, and going by the archives, nobody else would. Knowing that someone actually looked at some proposal is rather important for people wishing to register a type, and I assume that is true for the IESG aswell, so I do not mind saying the same things again and again all that much. I would rather look at this from the perspective of people who wish to register a type. What one should put in the "Applications that use this media type" field is rather unclear, I don't really know anything about "Macintosh file type code(s)", for almost all types I might know I have no idea what the Windows Clipboard type might be, I think all text and +xml types should have a charset parameter... those are things I'd like to not talk about for individual registrations, from either perspective. More broadly I do not think the "Encoding considerations" is useful as "7bit" is no longer meaningful to most people and the difference between "8bit" and "binary" is lost to most people (including myself going by my past registration efforts), I don't think anybody expects that they can contact the "Person & email address to contact for further information" and actually get useful information, and decent Security considerations are hard to come by to say the least. So in terms of what we can improve, whether you say "Type name" or "MIME Type name" or whatever the old field was, that's almost irrelevant. I'd think I personally, primarily, care about going from a name to something that offers more information on the format, and that being easy for most of the type names (possible for most types). I don't really care who authored the template or if the intended usage is COMMON or LIMITED USE. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ Return-Path: X-Original-To: ietf-types@ietfa.amsl.com Delivered-To: ietf-types@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF26C21F8523 for ; Fri, 1 Jul 2011 08:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8-CNPh5O2mL for ; Fri, 1 Jul 2011 08:12:58 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 717349E8045 for ; Fri, 1 Jul 2011 08:12:54 -0700 (PDT) Received: by fxe4 with SMTP id 4so4215207fxe.27 for ; Fri, 01 Jul 2011 08:12:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=WmYgKFllclMEKV86y2M88EzEYOYgMHpFY5xAJfFuRfU=; b=BAAZzj6uTS/9CYmoZ0ieYaKGSv6svpIC+2PayalD7fQVxOV8/Y0UmnCICp6ZatphwB 1stIETkeJvE4dWNL9zeUQGDmUdlDboSkszOO2gxaNHrFjqCeirQF/SXFLWOWbVyOMQxs GgfM36stUP6GBypkaRWh1rvA0p8QerlWnrsIc= Received: by 10.223.36.89 with SMTP id s25mr4981097fad.9.1309533171708; Fri, 01 Jul 2011 08:12:51 -0700 (PDT) Received: from tmp4.logic.tuwien.ac.at (tmp4.logic.tuwien.ac.at [128.130.175.54]) by mx.google.com with ESMTPS id q14sm2424323faa.3.2011.07.01.08.12.50 (version=SSLv3 cipher=OTHER); Fri, 01 Jul 2011 08:12:50 -0700 (PDT) Message-ID: <4E0DE3F0.3060800@gmail.com> Date: Fri, 01 Jul 2011 17:12:48 +0200 From: Jesse Alama User-Agent: Postbox 2.5.0 (Macintosh/20110628) MIME-Version: 1.0 To: Paul Libbrecht References: <71BDC73D-2C29-4F42-9229-9D079D57D227@hoplahup.net> <4E0DB874.5000906@gmail.com> <6614772E-806C-4E29-8B7A-9DE82235739F@hoplahup.net> <4E0DDE62.2030908@gmail.com> <4E0DE3AB.7000906@gmail.com> In-Reply-To: <4E0DE3AB.7000906@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 03 Jul 2011 16:28:21 -0700 Cc: Adam Naumowicz , ietf-types@ietf.org Subject: Re: [ietf-types] request for review: text/mizar X-BeenThere: ietf-types@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Media \(MIME\) type review" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 15:15:58 -0000 Paul Libbrecht wrote: > If you say ASCII then I would suggest to keep ascii. That is, you recommend that I specify a 7-bit encoding for the proposed media type? > Is the CRLF requirement also a requirement? I'm not sure I understand what you're asking. > The reason I asked about charset is that the media-type parameter > charset is the cause of numerous communication around here, > especially in the xml world, i'd just like to avoid any error here if > possible. Ah, OK. I think this kind of encoding question doesn't apply to mizar texts. >>> - can the specification be indicated with a publicly accessible >>> URL? >> One candidate might be >> >> http://www.mizar.org/language/ which gives some information about >> the language. Adam, do you have a better suggestion here? > > Such things as ASCII is not there.... this specifies the vocabulary > not really the file format. True, it doesn't specify the file format. Broadly, any ASCII document is, potentially, a mizar text. Of course, only those texts that adhere to the rules of the mizar language are acceptable to the mizar suite of tools. But in principle they can operate on any ASCII text. Does that clarify things? Jesse -- Jesse Alama http://centria.di.fct.unl.pt/~alama/