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 D8D6511E8080 for ; Sun, 27 May 2012 23:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.174 X-Spam-Level: X-Spam-Status: No, score=-106.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLWA9ZBlykGj for ; Sun, 27 May 2012 23:43:43 -0700 (PDT) Received: from pechora1.lax.icann.org (unknown [IPv6:2620:0:2d0:201::1:71]) by ietfa.amsl.com (Postfix) with ESMTP id B383B11E807F for ; Sun, 27 May 2012 23:43:43 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id q4S6hMoa009945 for ; Mon, 28 May 2012 06:43:43 GMT X-AuditID: c1b4fb30-b7f606d0000002be-ec-4fc31e899962 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 8E.8E.00702.98E13CF4; Mon, 28 May 2012 08:43:21 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.0; Mon, 28 May 2012 08:43:20 +0200 Message-ID: <4FC31E87.2020202@ericsson.com> Date: Mon, 28 May 2012 08:43:19 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Roni Even References: <17F2F6DB-D3F0-4EA2-9234-F3EFF27E6F11@hoplahup.net> <4fc0a898.8653b40a.27a0.ffffa445@mx.google.com> In-Reply-To: <4fc0a898.8653b40a.27a0.ffffa445@mx.google.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsUyM+JvrW6n3GF/g55tQhbrrp1ismj6spzJ 4tLFs0wWf9uZHVg8ds66y+6xdN0OFo8eeY8lS34yBbBEcdmkpOZklqUW6dslcGW0f3jPWDBV rOLgnq9sDYydQl2MnBwSAiYSLxesY4ewxSQu3FvP1sXIxSEkcIpRouNHKxNIQkhgOaPEt7UC IDavgLbEpH+bmEFsFgFViTdfWxhBbDYBC4mbPxrZQGxRgWCJF3uusELUC0qcnPmEBcQWEVCT eL32M1gNs0CdxNYPXWBzhAWcJdac2MEKsStfYv9siF5OARuJr3saoI6TlDj47xo7RK+exJSr EHuZBeQlmrfOZobo1ZZoaOpgncAoNAvJ6llIWmYhaVnAyLyKUTg3MTMnvdxcL7UoM7m4OD9P rzh1EyMwyA9u+W2wg3HTfbFDjNIcLErivHqq+/2FBNITS1KzU1MLUovii0pzUosPMTJxcEo1 MHZpi/z/KpO8a32QqOri5ydPFJe89eVXsAz8/l784a9ZrjkqK3VK7psbrTPiX3Zf9c/lp8cy ZDNZVq6c11q/1J83Mii9SOb9s523ZCPu75rP/P3eqj9KP97uLqtviuRwlFt8jJ1/e+Dag9vL VTV4pxZt0jgrwXzh0yShl2cs5dNSBP1kzxYqT1diKc5INNRiLipOBADlawpPQAIAAA== X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Mon, 28 May 2012 06:43:43 +0000 (UTC) Cc: 'IANA Media types' , "payload@ietf.org" Subject: Re: [ietf-types] [payload] Video media-types insufficient? 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, 28 May 2012 06:43:44 -0000 Hi, Roni, if I understand correctly this is about the ISO based mp4 file format and not the RTP payload format. Thus not really a question for the Payload WG. My question to Paul, does you and the browser use the codecs and profiles parameter that are defined for this type. Please see http://www.rfc-editor.org/rfc/rfc6381.txt That is intended to more detailed express which profiles and codecs that are included in the media type. Cheers Magnus On 2012-05-26 11:53, Roni Even wrote: > Hi, > I think this should be discussed in payload WG > Roni Even > >> -----Original Message----- >> From: ietf-types-bounces@ietf.org [mailto:ietf-types-bounces@ietf.org] >> On Behalf Of Paul Libbrecht >> Sent: Saturday, May 26, 2012 11:28 AM >> To: IANA Media types >> Subject: [ietf-types] Video media-types insufficient? >> >> >> hello dear Media-types' expert, >> >> the other day, I played with the nifty new video element of HTML5 which >> seems to be fairly well implemented. This element allows a list of >> sources together with their media-type so that the browser can find the >> "video format" that it can play. >> This element is perfectly following the idea of a media-type's >> characterization of an exploitable format. >> >> However, this characterization is insufficient: the same media-type for >> videos can be encode data in multiple codecs and these are not encoded >> in media-types: >> >> I met this while using the video/mp4 media-type and realized that our >> default encoding, the mpeg4 codec, did not play in iPad. >> So I used the same video element, with a src of media-type pointing to >> an mp4 file that uses the h264 codec. This one plays on iPad. >> >> To me, this is a clear failure of the media-type video/mp4: it does not >> express sufficiently the playability on a device. >> >> Is this something well known? >> Are there maybe media-type parameters that could help? >> Are newer video media-types better on this respect? >> >> thanks in advance >> >> Paul >> _______________________________________________ >> ietf-types mailing list >> ietf-types@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-types > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- 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 3E55B21F85E1 for ; Sat, 26 May 2012 02:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.433 X-Spam-Level: X-Spam-Status: No, score=-3.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XktU5E4meqKZ for ; Sat, 26 May 2012 02:55:59 -0700 (PDT) Received: from pechora1.lax.icann.org (unknown [IPv6:2620:0:2d0:201::1:71]) by ietfa.amsl.com (Postfix) with ESMTP id 1593921F85CE for ; Sat, 26 May 2012 02:55:59 -0700 (PDT) Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id q4Q9tcGc001888 for ; Sat, 26 May 2012 09:55:58 GMT Received: by wefh52 with SMTP id h52so1133348wef.28 for ; Sat, 26 May 2012 02:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=z+4n3y7JPaL6jIaGRO6k/izscBJAzzNeeKYgkM/HAQs=; b=0AkIWGtS7Fu8dy+aa3RtyfUuMI8YmNExL8nyh235efK4i4lGpRtQtTywRBmJf6TqT2 c3V+2zCPZnfmVmpaIjleKNgI20qWwk6asV8x5VNyGF97r98oOXAiDrEpovEg+6vf0E/W Zac0NlDTMSRhE++1oHujafLr+Q/uGyHEEtanN1f2EDMwqDacS+e8BoYkFw71g0Y/dRKX j6MTWZlElp6apCeZLRLU3EERT1vJFttbpt+kWpI07YE/qki/QUtLi4jHnbRPYPgnDwcf gUKmuedRCx4Hcqn/SDaM6cRYkhYdpeGaDPEeLcaTe0/t0h8ZtIdUUj2kwJbOwiIxy+hG EFJA== Received: by 10.216.202.14 with SMTP id c14mr1112649weo.63.1338026137768; Sat, 26 May 2012 02:55:37 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-198-116.red.bezeqint.net. [79.177.198.116]) by mx.google.com with ESMTPS id q6sm3788680wiy.0.2012.05.26.02.55.35 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 26 May 2012 02:55:36 -0700 (PDT) From: "Roni Even" To: "'Paul Libbrecht'" , References: <17F2F6DB-D3F0-4EA2-9234-F3EFF27E6F11@hoplahup.net> In-Reply-To: <17F2F6DB-D3F0-4EA2-9234-F3EFF27E6F11@hoplahup.net> Date: Sat, 26 May 2012 12:53:14 +0300 Message-ID: <4fc0a898.8653b40a.27a0.ffffa445@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac07GXqO8m2HLBa4TMCJ2PHU/1RwXQAC7JQA Content-Language: en-us X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Sat, 26 May 2012 09:55:59 +0000 (UTC) Cc: 'IANA Media types' Subject: Re: [ietf-types] Video media-types insufficient? 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: Sat, 26 May 2012 09:55:59 -0000 Hi, I think this should be discussed in payload WG Roni Even > -----Original Message----- > From: ietf-types-bounces@ietf.org [mailto:ietf-types-bounces@ietf.org] > On Behalf Of Paul Libbrecht > Sent: Saturday, May 26, 2012 11:28 AM > To: IANA Media types > Subject: [ietf-types] Video media-types insufficient? > > > hello dear Media-types' expert, > > the other day, I played with the nifty new video element of HTML5 which > seems to be fairly well implemented. This element allows a list of > sources together with their media-type so that the browser can find the > "video format" that it can play. > This element is perfectly following the idea of a media-type's > characterization of an exploitable format. > > However, this characterization is insufficient: the same media-type for > videos can be encode data in multiple codecs and these are not encoded > in media-types: > > I met this while using the video/mp4 media-type and realized that our > default encoding, the mpeg4 codec, did not play in iPad. > So I used the same video element, with a src of media-type pointing to > an mp4 file that uses the h264 codec. This one plays on iPad. > > To me, this is a clear failure of the media-type video/mp4: it does not > express sufficiently the playability on a device. > > Is this something well known? > Are there maybe media-type parameters that could help? > Are newer video media-types better on this respect? > > thanks in advance > > Paul > _______________________________________________ > ietf-types mailing list > ietf-types@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-types 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 1818D21F85F0 for ; Sat, 26 May 2012 01:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwN2qYTLyWEC for ; Sat, 26 May 2012 01:28:03 -0700 (PDT) Received: from pechora1.lax.icann.org (unknown [IPv6:2620:0:2d0:201::1:71]) by ietfa.amsl.com (Postfix) with ESMTP id A797F21F85EA for ; Sat, 26 May 2012 01:28:03 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by pechora1.lax.icann.org (8.13.8/8.13.8) with ESMTP id q4Q8RgHs010349 for ; Sat, 26 May 2012 08:28:02 GMT Received: from [192.168.178.32] (p5DDEC3B6.dip0.t-ipconnect.de [93.222.195.182]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0MUgUR-1SQK6A1kyh-00Qjdd; Sat, 26 May 2012 10:27:41 +0200 From: Paul Libbrecht Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 26 May 2012 10:27:39 +0200 Message-Id: <17F2F6DB-D3F0-4EA2-9234-F3EFF27E6F11@hoplahup.net> To: IANA Media types Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:fhE/29wX1DBoXP9viKVFr19FaL1uGC5qwIXWtMDkl9v HfstCdw4KkSz/V8+bWROKbuY+LMfDa1zXO4E3JywhB8bqvwIAa L6douKDpKZC69oPiS0hYDqHx4g6caCZHgbh9apRpnExOR2jYP5 7/EjXCH2JD4DItLmlZMTiNabzVKe7nV8ab6QCqj9hE9GY/NAYr gfJcEOmPk3EGhJNQ4sjjeu5SPpOTtphK1cAR/RyGGeoLEb8EPX oG8e3reTkMVxJ7Lfopen2jNHa2NzOjSVJi6RZco/Y2BTB/q1Wh jEka9bkjyi+WqZHCwpJCYim8PcW0172OP8sTlMb5Nhg2Wz+i+Q ER1pt8VDI7CQPYEzOqqgb/Ei7VMuoBQMxThwn/lV3feDEcLoim wVxioZGsAAK4g== X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Sat, 26 May 2012 08:28:03 +0000 (UTC) Subject: [ietf-types] Video media-types insufficient? 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: Sat, 26 May 2012 08:28:04 -0000 hello dear Media-types' expert, the other day, I played with the nifty new video element of HTML5 which = seems to be fairly well implemented. This element allows a list of = sources together with their media-type so that the browser can find the = "video format" that it can play. This element is perfectly following the idea of a media-type's = characterization of an exploitable format. However, this characterization is insufficient: the same media-type for = videos can be encode data in multiple codecs and these are not encoded = in media-types: I met this while using the video/mp4 media-type and realized that our = default encoding, the mpeg4 codec, did not play in iPad. So I used the same video element, with a src of media-type pointing to = an mp4 file that uses the h264 codec. This one plays on iPad. To me, this is a clear failure of the media-type video/mp4: it does not = express sufficiently the playability on a device. Is this something well known? Are there maybe media-type parameters that could help? Are newer video media-types better on this respect? thanks in advance 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 D8C9A11E8098 for ; Thu, 24 May 2012 19:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-3.150, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2BfQlfrNgOc for ; Thu, 24 May 2012 19:11:13 -0700 (PDT) Received: from pechora1.lax.icann.org (unknown [IPv6:2620:0:2d0:201::1:71]) by ietfa.amsl.com (Postfix) with ESMTP id DFF2A11E8080 for ; Thu, 24 May 2012 19:11:13 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by pechora1.lax.icann.org (8.13.8/8.13.8) with SMTP id q4P2Aqau005123 for ; Fri, 25 May 2012 02:11:13 GMT Received: (qmail invoked by alias); 25 May 2012 02:10:50 -0000 Received: from dslb-094-223-222-254.pools.arcor-ip.net (EHLO HIVE) [94.223.222.254] by mail.gmx.net (mp028) with SMTP; 25 May 2012 04:10:50 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX194b+JhkY94k6RXGsxS55FelUPG9Eejzx1u6rTDVM MSNa7a9LwtbzLK From: Bjoern Hoehrmann To: ietf-types@iana.org Date: Fri, 25 May 2012 04:10:51 +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 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora1.lax.icann.org [192.0.33.71]); Fri, 25 May 2012 02:11:13 +0000 (UTC) Subject: [ietf-types] Updating registrations (was: Re: minutes, 24 May 2012 SVG WG telcon) 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, 25 May 2012 02:11:15 -0000 * Nikos Andronikos wrote: >Removal of the Media Type Registration chapter from SVG 2 > > CM: I thought that because we have the media type registered > now that we don't need the chapter > ... I asked Chris > ... He thinks we don't > ... unless there are objections, I'll remove it > ... it existed in the spec so the registry could point to > something > ... the media type won't mean anything difference between SVG 1 > and SVG 2. not neccessary to resubmit W3C's http://lists.w3.org/Archives/Public/www-svg/2012May/0084.html SVG Working Group registered image/svg+xml some time ago and is revising the underlying format, and as above there is proposal that the specification defining the new version does not include the registration template, and I assume not "resubmitting" means it is also being proposed that there will be no attempts to update the registration information on file. FYI. -- 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 93A4321F8741 for ; Wed, 23 May 2012 07:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.539 X-Spam-Level: X-Spam-Status: No, score=-109.539 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62rSeFpubuUq for ; Wed, 23 May 2012 07:36:32 -0700 (PDT) Received: from pechora3.lax.icann.org (unknown [IPv6:2620:0:2d0:201::1:73]) by ietfa.amsl.com (Postfix) with ESMTP id 5D48421F8721 for ; Wed, 23 May 2012 07:36:28 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by pechora3.lax.icann.org (8.13.8/8.13.8) with ESMTP id q4NEa2Zl000430 for ; Wed, 23 May 2012 14:36:23 GMT X-IronPort-AV: E=Sophos;i="4.75,645,1330902000"; d="scan'208";a="159565804" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 23 May 2012 16:19:13 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Vincent Roca In-Reply-To: Date: Wed, 23 May 2012 16:19:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <10F4C7A9-BAB1-4E61-98D9-42ED1D1E218A@inria.fr> References: To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1084) X-Greylist: Delayed for 00:16:47 by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Wed, 23 May 2012 14:36:23 +0000 (UTC) Cc: rmt-chairs@tools.ietf.org, draft-ietf-rmt-flute-revised@tools.ietf.org, Vincent Roca , ietf-types@iana.org Subject: Re: [ietf-types] Registration of media type application/fdt+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: Wed, 23 May 2012 14:36:33 -0000 Hello Bjoern, Thanks a lot for your highly valuable comments! My answers and proposal are below. >> The FLUTE-revised I-D = (http://tools.ietf.org/html/ietf-rmt-flute-revised-14), >> currently under IESG review, defines in section 8.2 the = application/fdt+xml >> Media-Type. Comments on this registration would be greatly = appreciated. >=20 >> Optional parameters: none >=20 > There should be a rationale for omitting the 'charset' parameter while > also using the "+xml" convention. The idea of the convention is that = you > can process all "+xml" "the same", but if some "+xml" types have a = char- > set parameter while others do not, applications would handle, say, >=20 > Content-Type: application/fdt+xml;charset=3Dwindows-1252 >=20 > differently, depending on whether they assume it would have a charset > parameter. If I understand the various documents, this is where we need to say that we expect UTF-8. I've kept is as an optional parameter. Is that = appropriate? >> Encoding considerations: The fdt+xml type consists of UTF-8 ASCII >> characters [RFC3629] and must be well-formed XML. >=20 > This should use the text in RFC 3023 section 7.1 or specify one of the > values in RFC 4288 ('binary', '8bit', etc.) If I understand, here we can say that we expect any kind of encoding = (i.e. binary), since FLUTE, as a communication protocol, does not make any restriction on the data it sends. >> Restrictions on usage: Only for usage with FDT Instances which are >> valid according to the XML schema of section 3.4.2. >=20 > This seems to be redundant and possibly misleading, considering that > similar registrations do not tend to have such text. Removed. >> Applications which use this media type: Not restricted to any >> particular application. Any application, FLUTE included, that sends >> an object that consists of an FDT Instance can use this media type. >=20 > This should say something like "spreadsheet applications", "3D = modeling > programs", "bitmap image processors", or whatever, capturing the = general > type of application where this is used. Done. >> Additional information: >>=20 >> Magic number(s): none >> File extension(s): An FDT Instance may use the extension ".fdt" >> but this is not required. >=20 > I would make that simply ".fdt", but don't mind the extra text. I have simplified. >> Person and email address to contact for further information: Toni >> Paila (toni.paila (at) nokia.com) >=20 > This is typically rendered `Toni Paila `. Note > that address harvesters handle obfuscations like this quite well, and > all it takes is one of them getting it right since address lists are > shared and cheap. You're right especially as the full email address is already in the = document. To summarize, here is the new version: NEW: 8.3. Registration of the application/fdt+xml Media-Type IANA is asked to register a new namespace in the IETF XML Registry (http://www.iana.org/assignments/xml-registry/ns.html) [RFC3688], using the following registration template: Type name: application Subtype name: fdt+xml Required parameters: none Optional parameters: charset=3D"utf-8" Encoding considerations: binary (the FLUTE file delivery procol does not impose any restriction on the objects it carries and in particular on the FDT Instance itself) Restrictions on usage: none Security considerations: fdt+xml data is passive, and does not generally represent a unique or new security threat. However, there is some risk in sharing any kind of data, in that unintentional information may be exposed, and that risk applies to fdt+xml data as well. Interoperability considerations: None Published specification: The present document including section 3.4.2. The specified FDT Instance functions as an actual media format of use to the general Internet community and thus media type registration under the Standards Tree is appropriate to maximize interoperability. Applications which use this media type: file and object delivery applications and protocols (e.g., FLUTE). Additional information: Magic number(s): none File extension(s): ".fdt" (e.g., if there is a need to store an FDT Instance as a file); Macintosh File Type Code(s): none Person and email address to contact for further information: Toni Paila (toni.paila@nokia.com) Intended usage: Common Author/Change controller: IETF Cheers, Vincent= 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 A23EE21F8682 for ; Tue, 22 May 2012 18:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZ-VkqpT4lcI for ; Tue, 22 May 2012 18:15:19 -0700 (PDT) Received: from pechora3.lax.icann.org (unknown [IPv6:2620:0:2d0:201::1:73]) by ietfa.amsl.com (Postfix) with ESMTP id E36E721F867B for ; Tue, 22 May 2012 18:15:17 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by pechora3.lax.icann.org (8.13.8/8.13.8) with SMTP id q4N1EuMB030618 for ; Wed, 23 May 2012 01:15:16 GMT Received: (qmail invoked by alias); 23 May 2012 01:14:53 -0000 Received: from dslb-094-223-223-209.pools.arcor-ip.net (EHLO HIVE) [94.223.223.209] by mail.gmx.net (mp010) with SMTP; 23 May 2012 03:14:53 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18T1iR+EL8TGkWFDZrR4XGyKKLIypGocGHyZC76WL S9aWbz7Lrnbh1f From: Bjoern Hoehrmann To: Vincent Roca Date: Wed, 23 May 2012 03:14:56 +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 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora3.lax.icann.org [192.0.33.73]); Wed, 23 May 2012 01:15:17 +0000 (UTC) Cc: rmt-chairs@tools.ietf.org, draft-ietf-rmt-flute-revised@tools.ietf.org, ietf-types@iana.org, Vincent Roca Subject: Re: [ietf-types] Registration of media type application/fdt+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: Wed, 23 May 2012 01:15:20 -0000 * Vincent Roca wrote: >The FLUTE-revised I-D (http://tools.ietf.org/html/ietf-rmt-flute-revised-14), >currently under IESG review, defines in section 8.2 the application/fdt+xml >Media-Type. Comments on this registration would be greatly appreciated. > Optional parameters: none There should be a rationale for omitting the 'charset' parameter while also using the "+xml" convention. The idea of the convention is that you can process all "+xml" "the same", but if some "+xml" types have a char- set parameter while others do not, applications would handle, say, Content-Type: application/fdt+xml;charset=windows-1252 differently, depending on whether they assume it would have a charset parameter. > Encoding considerations: The fdt+xml type consists of UTF-8 ASCII > characters [RFC3629] and must be well-formed XML. This should use the text in RFC 3023 section 7.1 or specify one of the values in RFC 4288 ('binary', '8bit', etc.) > Restrictions on usage: Only for usage with FDT Instances which are > valid according to the XML schema of section 3.4.2. This seems to be redundant and possibly misleading, considering that similar registrations do not tend to have such text. > Applications which use this media type: Not restricted to any > particular application. Any application, FLUTE included, that sends > an object that consists of an FDT Instance can use this media type. This should say something like "spreadsheet applications", "3D modeling programs", "bitmap image processors", or whatever, capturing the general type of application where this is used. > Additional information: > > Magic number(s): none > File extension(s): An FDT Instance may use the extension ".fdt" > but this is not required. I would make that simply ".fdt", but don't mind the extra text. > Person and email address to contact for further information: Toni > Paila (toni.paila (at) nokia.com) This is typically rendered `Toni Paila `. Note that address harvesters handle obfuscations like this quite well, and all it takes is one of them getting it right since address lists are shared and cheap. -- 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 ABD4121F85AC for ; Tue, 22 May 2012 07:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.02 X-Spam-Level: X-Spam-Status: No, score=-109.02 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_20=-0.74, HELO_EQ_FR=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKFshmJbcPuu for ; Tue, 22 May 2012 07:14:26 -0700 (PDT) Received: from pechora2.lax.icann.org (pechora2.icann.org [IPv6:2620:0:2d0:201::1:72]) by ietfa.amsl.com (Postfix) with ESMTP id C74AE21F85D8 for ; Tue, 22 May 2012 07:14:25 -0700 (PDT) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by pechora2.lax.icann.org (8.13.8/8.13.8) with ESMTP id q4MEE4x0026440 for ; Tue, 22 May 2012 14:14:25 GMT X-IronPort-AV: E=Sophos;i="4.75,637,1330902000"; d="scan'208";a="144654047" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 22 May 2012 16:14:02 +0200 From: Vincent Roca Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 22 May 2012 16:14:02 +0200 Message-Id: To: ietf-types@iana.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora2.lax.icann.org [192.0.33.72]); Tue, 22 May 2012 14:14:25 +0000 (UTC) X-Mailman-Approved-At: Tue, 22 May 2012 07:52:08 -0700 Cc: rmt-chairs@tools.ietf.org, draft-ietf-rmt-flute-revised@tools.ietf.org, Vincent Roca Subject: [ietf-types] Registration of media type application/fdt+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: Tue, 22 May 2012 14:14:26 -0000 Hello, The FLUTE-revised I-D (http://tools.ietf.org/html/ietf-rmt-flute-revised-14), currently under IESG review, defines in section 8.2 the application/fdt+xml Media-Type. Comments on this registration would be greatly appreciated. Thanks! Cheers, Vincent --- Type name: application Subtype name: fdt+xml Required parameters: none Optional parameters: none Encoding considerations: The fdt+xml type consists of UTF-8 ASCII characters [RFC3629] and must be well-formed XML. Additional content and transfer encodings may be used with fdt+xml files, with the appropriate encoding for any specific file being entirely dependent upon the deployed application. Restrictions on usage: Only for usage with FDT Instances which are valid according to the XML schema of section 3.4.2. Security considerations: fdt+xml data is passive, and does not generally represent a unique or new security threat. However, there is some risk in sharing any kind of data, in that unintentional information may be exposed, and that risk applies to fdt+xml data as well. Interoperability considerations: None Published specification: The present document including section 3.4.2. The specified FDT Instance functions as an actual media format of use to the general Internet community and thus media type registration under the Standards Tree is appropriate to maximize interoperability. Applications which use this media type: Not restricted to any particular application. Any application, FLUTE included, that sends an object that consists of an FDT Instance can use this media type. Additional information: Magic number(s): none File extension(s): An FDT Instance may use the extension ".fdt" but this is not required. Macintosh File Type Code(s): none Person and email address to contact for further information: Toni Paila (toni.paila (at) nokia.com) Intended usage: Common Author/Change controller: IETF 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 3561821F85B7 for ; Mon, 14 May 2012 19:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbUwxOm-oeSc for ; Mon, 14 May 2012 19:56:57 -0700 (PDT) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) by ietfa.amsl.com (Postfix) with ESMTP id 4220121F851B for ; Mon, 14 May 2012 19:56:57 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by pechora5.dc.icann.org (8.13.8/8.13.8) with SMTP id q4F2uasV006632 for ; Tue, 15 May 2012 02:56:56 GMT Received: (qmail invoked by alias); 15 May 2012 02:56:12 -0000 Received: from dslb-094-222-128-205.pools.arcor-ip.net (EHLO HIVE) [94.222.128.205] by mail.gmx.net (mp040) with SMTP; 15 May 2012 04:56:12 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+Sad8LG9GSISvNZyfMfeu3Q49UvZZbeUH8HOAR5/ qIu5BVDhmWe5Rr From: Bjoern Hoehrmann To: ietf-types@iana.org Date: Tue, 15 May 2012 04:56:17 +0200 Message-ID: References: <20120514211042.15582.57617.idtracker@ietfa.amsl.com> In-Reply-To: <20120514211042.15582.57617.idtracker@ietfa.amsl.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 (pechora5.dc.icann.org [192.0.46.71]); Tue, 15 May 2012 02:56:56 +0000 (UTC) Subject: Re: [ietf-types] Protocol Action: 'Update to MIME regarding Charset Parameter Handling in Textual Media Types' to Proposed Standard (draft-ietf-appsawg-mime-default-charset-04.txt) 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, 15 May 2012 02:56:58 -0000 * The IESG wrote: >The IESG has approved the following document: >- 'Update to MIME regarding Charset Parameter Handling in Textual Media > Types' > (draft-ietf-appsawg-mime-default-charset-04.txt) as Proposed Standard > >This document is the product of the Applications Area Working Group. > >The IESG contact persons are Barry Leiba and Pete Resnick. > >A URL of this Internet Draft is: >http://datatracker.ietf.org/doc/draft-ietf-appsawg-mime-default-charset/ FYI. -- 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 D0B7121F84CD for ; Thu, 10 May 2012 18:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=-0.717, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnDKgGwyLbWg for ; Thu, 10 May 2012 18:22:35 -0700 (PDT) Received: from pechora4.lax.icann.org (pechora4.icann.org [IPv6:2620:0:2d0:201::1:74]) by ietfa.amsl.com (Postfix) with ESMTP id AE1C221F84A0 for ; Thu, 10 May 2012 18:22:34 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by pechora4.lax.icann.org (8.13.8/8.13.8) with SMTP id q4B1MC86024621 for ; Fri, 11 May 2012 01:22:33 GMT Received: (qmail invoked by alias); 11 May 2012 01:22:10 -0000 Received: from dslb-094-223-210-213.pools.arcor-ip.net (EHLO HIVE) [94.223.210.213] by mail.gmx.net (mp030) with SMTP; 11 May 2012 03:22:10 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19P2ecqCWZPPVSkFqvI9OpAogpaBUxt+InFhfEq/9 3HNqoCH3zGwaGB From: Bjoern Hoehrmann To: Kazuyuki Ashimura Date: Fri, 11 May 2012 03:22:10 +0200 Message-ID: References: <4FABECC0.4050805@w3.org> In-Reply-To: <4FABECC0.4050805@w3.org> 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 (pechora4.lax.icann.org [192.0.33.74]); Fri, 11 May 2012 01:22:34 +0000 (UTC) Cc: ietf-types@iana.org, ietf-xml-mime@imc.org, www-multimodal@w3.org Subject: Re: [ietf-types] Request for review of EmotionML media type: application/emotionml+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, 11 May 2012 01:22:35 -0000 * Kazuyuki Ashimura wrote: >W3C has just published a Candidate Recommendation for "Emotion Markup >Language (EmotionML)" at: > > http://www.w3.org/TR/2012/CR-emotionml-20120510/ > >I am sending this request to ask the Ietf-types list for comments on >the Media Type section of the EmotionML specification following the >procedure defined at: > > http://www.w3.org/2002/06/registering-mediatype The procedure requires Working Groups to ask for ietf-types review when making a Last Call announcement. I have not been able to find any such request in the archive. If the Working Group failed to follow the pro- cedure, it would be helpful if you could put that on the record. >MIME media type name: >--------------------- > application This is using an outdated template. The current one is in RFC 4288. In it, some field names are different and some fields are organized in a different manner. >Optional parameters: >-------------------- > charset > > This parameter has identical semantics to the charset parameter >of the application/xml media type as specified in [RFC3023] or its >successor. > >Encoding considerations: >------------------------ > By virtue of EmotionML content being XML, it has the same >considerations when sent as "application/emotionml+xml" as does XML. See >RFC 3023 (or its successor), section 3.2. RFC 3023 has boilerplate for this, but the above seems close enough. -- 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 C98AD11E80CF for ; Thu, 10 May 2012 12:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_32=0.6, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjjzKP4p96ay for ; Thu, 10 May 2012 12:31:29 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id E91EE11E80AB for ; Thu, 10 May 2012 12:31:28 -0700 (PDT) Received: from [192.168.178.32] (p5DDEC430.dip0.t-ipconnect.de [93.222.196.48]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0M7A5y-1SEzxv19a2-00wRnn; Thu, 10 May 2012 21:30:57 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Paul Libbrecht In-Reply-To: <4FABF6EE.80103@w3.org> Date: Thu, 10 May 2012 21:30:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <119C90DA-0C41-4BA0-9FAA-477E6CA610AD@hoplahup.net> References: <4FABF6EE.80103@w3.org> To: Kazuyuki Ashimura X-Mailer: Apple Mail (2.1084) X-Provags-ID: V02:K0:SyDH1SDAuLzpEHUgDpo11HLSf/ZzJPPkoK/QEPJ1UjR 7tS/4RV4AnphyKWK82qxWSZ13DJMxyvwPiTOCWZ3lb/kcqa+CZ agwOS1vUrIAjXA4EDbZevAEQSuewleM6iAhVYLGdcLk75w+f7D wNWOzTTRtm2RP7LDkNtU5f/u9fSqZc9zddhfZrE5f+ye32YxB6 L+52wXjs1CoD9fSD6dj1z7SHm16AjvITBiLqMTuwbekWC9eLPw kivzkS27Qj6BKHHinn2SjRHzXEIvy7slp9cdwiwhzGmwWRW5f+ t0Q9fVHL12fseTcVHHUsM68KF0YRtn40T6zuuzTDfDzUWRaBHV Qv9Ob/Jw0D9C44t6MxwnMBBN26IiVV5uyEvAOIiSbjI/WPcTgC 0Rzqkb4+ve7Pw== Cc: www-multimodal@w3.org, ietf-xml-mime@imc.org, ietf-types@ietf.org Subject: Re: [ietf-types] Request for review of EmotionML media type: application/emotionml+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: Thu, 10 May 2012 19:31:30 -0000 Dear Kazuyuki, would you think as conceivable to put EmotionML into a clipboard? If yes it would be nice to include in this specification: - a Windows clipboard name (more or less, just a string) which = applications would register at start - a Macintosh Uniform Type Identifier (which application descriptors = could register) thanks in advance Paul Le 10 mai 2012 =E0 19:12, Kazuyuki Ashimura a =E9crit : >=20 > Dear list, > # sorry but resending because I used wrong address for my previous = post. >=20 > W3C has just published a Candidate Recommendation for "Emotion Markup > Language (EmotionML)" at: >=20 > http://www.w3.org/TR/2012/CR-emotionml-20120510/ >=20 > I am sending this request to ask the Ietf-types list for comments on > the Media Type section of the EmotionML specification following the > procedure defined at: >=20 > http://www.w3.org/2002/06/registering-mediatype >=20 > --- > The Media Type section of the EmotionML specification is available > at: >=20 > http://www.w3.org/TR/2012/CR-emotionml-20120510/#MIME-type >=20 > and a plain text copy is also available below. >=20 > MIME media type name: > --------------------- > application >=20 > MIME subtype name: > ------------------ > emotionml+xml >=20 > Required parameters: > -------------------- > None. >=20 > Optional parameters: > -------------------- > charset >=20 > This parameter has identical semantics to the charset parameter = of the application/xml media type as specified in [RFC3023] or its = successor. >=20 > Encoding considerations: > ------------------------ > By virtue of EmotionML content being XML, it has the same = considerations when sent as "application/emotionml+xml" as does XML. See = RFC 3023 (or its successor), section 3.2. >=20 > Security considerations: > ------------------------ > EmotionML elements may include arbitrary URIs. Therefore the = security issues of [RFC3986], section 7, should be considered. >=20 > In addition, because of the extensibility features for EmotionML, = it is possible that "application/emotionml+xml" will describe content = that has security implications beyond those described here. However, if = the processor follows only the normative semantics of this = specification, this content will be ignored. Only in the case where the = processor recognizes and processes the additional content, or where = further processing of that content is dispatched to other processors, = would security issues potentially arise. And in that case, they would = fall outside the domain of this registration document. >=20 > Interoperability considerations: > -------------------------------- > This specification describes processing semantics that dictate the = required behavior for dealing with, among other things, unrecognized = elements. >=20 > Because EmotionML is extensible, conformant = "application/emotionml+xml" processors MAY expect that content received = is well-formed XML, but processors SHOULD NOT assume that the content is = valid EmotionML or expect to recognize all of the elements and = attributes in the document. >=20 > Published specification: > ------------------------ > This media type registration is extracted from Appendix B of the = "Emotion Markup Language (EmotionML) 1.0" specification. >=20 > Additional information: > ----------------------- > Magic number(s): >=20 > There is no single initial octet sequence that is always = present in EmotionML documents. >=20 > File extension(s): >=20 > EmotionML documents are most often identified with the = extensions ".emotionml". >=20 > Macintosh File Type Code(s): >=20 > TEXT >=20 > Person & email address to contact for further information: > ---------------------------------------------------------- > Kazuyuki Ashimura, . >=20 > Intended usage: > --------------- > COMMON >=20 > Author/Change controller: > ------------------------- > The EmotionML specification is a work product of the World Wide Web = Consortium's Multimodal Interaction Working Group. The W3C has change = control over these specifications. >=20 >=20 > ---------------------- > Normative References: > ---------------------- >=20 > RFC 3023 > XML Media Types, M. Murata et al., Editors. IETF RFC 3023, January = 2001. >=20 > Sincerely, >=20 > Kazuyuki >=20 > --=20 > Kaz Ashimura, W3C Staff Contact for Web&TV, MMI and Voice > Tel: +81 466 49 1170 >=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 6B54321F84D6 for ; Wed, 9 May 2012 00:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.142 X-Spam-Level: X-Spam-Status: No, score=-106.142 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOPbaI6Zd9A5 for ; Wed, 9 May 2012 00:42:21 -0700 (PDT) Received: from pechora2.lax.icann.org (pechora2.icann.org [IPv6:2620:0:2d0:201::1:72]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5D721F8495 for ; Wed, 9 May 2012 00:42:21 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by pechora2.lax.icann.org (8.13.8/8.13.8) with ESMTP id q497fxaO001863 for ; Wed, 9 May 2012 07:42:20 GMT X-AuditID: c1b4fb2d-b7b76ae0000063d8-51-4faa1fc63c54 Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0237"; auth=fail (cipher=AES128-SHA) Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0237", Issuer "esessmw0237" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 40.DD.25560.6CF1AAF4; Wed, 9 May 2012 09:41:58 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Wed, 9 May 2012 09:41:56 +0200 Message-ID: <4FAA1FC4.5050502@ericsson.com> Date: Wed, 9 May 2012 09:41:56 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <4F99654A.5070600@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (pechora2.lax.icann.org [192.0.33.72]); Wed, 09 May 2012 07:42:20 +0000 (UTC) Cc: "'ietf-types@iana.org'" , "mmusic-chairs@tools.ietf.org" Subject: Re: [ietf-types] Review of text/parameters 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: Wed, 09 May 2012 07:42:22 -0000 Thanks for the review. On 2012-05-05 21:59, Bjoern Hoehrmann wrote: > * Magnus Westerlund wrote: >> https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ > >> 22.16. Media Type Registration for text/parameters >> >> Type name: text >> >> Subtype name: parameters >> >> Required parameters: >> >> Optional parameters: > > Well, text types usually have a 'charset' parameter, and applications > are known to treat, say, a HTTP response with > > Content-Type: text/parameters;charset=iso-8859-1 > > As ISO-8859-1 encoded document, even though I gather they are to use > UTF-8 to decode the document. If you don't want a 'charset' parameter, > this problem should be noted in the Security or Interoperability con- > siderations. Yes, you are correct. I guess having the charset being applicable to the values of the parameters would be very reasonable. The parameters themselves are in this format restricted to visible 7-bit US-ASCII characters. > >> Encoding considerations: > > This field needs a value (probably "8bit" or "binary"). That would be 8bit if I interpret that definition correctly. This will only contain UTF8 text. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- 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 0011121F846F for ; Sat, 5 May 2012 23:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.906 X-Spam-Level: X-Spam-Status: No, score=-98.906 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_48=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHvvGbM51vIy for ; Sat, 5 May 2012 23:21:09 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF9F21F8463 for ; Sat, 5 May 2012 23:21:08 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q466KvVd025056 for ; Sun, 6 May 2012 15:20:57 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 2955_82fd_a48b7a56_9743_11e1_8e85_001d096c566a; Sun, 06 May 2012 15:20:57 +0900 Received: from [IPv6:::1] ([133.2.210.1]:37283) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 6 May 2012 15:21:00 +0900 Message-ID: <4FA6183F.6030301@it.aoyama.ac.jp> Date: Sun, 06 May 2012 15:20:47 +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: Bjoern Hoehrmann References: <20120418153629.GB29120@w3.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf-types@ietf.org Subject: Re: [ietf-types] Request for review of N-Triples (an RDF serialization) media type: application/n-triples 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, 06 May 2012 06:21:10 -0000 On 2012/05/06 5:10, Bjoern Hoehrmann wrote: > * Eric Prud'hommeaux wrote: >> Type name: >> application >> Subtype name: >> n-triples >> Required parameters: >> None >> Optional parameters: >> None >> Encoding considerations: >> The syntax of N-Triples is expressed over code points in Unicode [UNICODE]. The encoding is always UTF-8 [UTF-8]. >> Unicode code points may also be expressed using an \uXXXX (U+0 to U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a hexadecimal digit [0-9A-F] > > This is supposed to simply say something like "8bit" or "binary", see > RFC 4288 for details. I think it's actually very good to say that N-Triples are always in UTF-8 somewhere in the template. This could stay here, changing it e.g. as follows: The character encoding is always UTF-8. This media type therefore has to be transported as "8bit", or futher encoded for "7bit" transport. >> Security considerations: > > I have not look at these, but since this is very long, it might make > more sense to have this as part of the Security Considerations section > of the document that defines the format, and simply put a reference > into the template. > >> Published specification: >> This specification. > > As I recall it, unlike for RFC registrations, IANA would put this in > a document on their site, so this should give a full(er) citation. Yes, please make the registration template self-contained, even if that might look a bit like overkill when it's looked at in the spec. Regards, Martin. > If you want to say anything about fragment identifiers, like what the > `#example` in `http://example.org/example.nt#example` refers to, or > if you want to discourage such usage, that should be included. Not a > requirement currently, but since this is an RDF type, this might be > relevant. 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 724A821F85FF for ; Sat, 5 May 2012 13:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncuJ77tk5rIA for ; Sat, 5 May 2012 13:26:48 -0700 (PDT) Received: from pechora5.dc.icann.org (pechora5.icann.org [IPv6:2620:0:2830:201::1:71]) by ietfa.amsl.com (Postfix) with ESMTP id 80E4821F85A5 for ; Sat, 5 May 2012 13:26:20 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by pechora5.dc.icann.org (8.13.8/8.13.8) with SMTP id q45KPxMx003549 for ; Sat, 5 May 2012 20:26:19 GMT Received: (qmail invoked by alias); 05 May 2012 19:59:17 -0000 Received: from dslb-094-223-209-045.pools.arcor-ip.net (EHLO HIVE) [94.223.209.45] by mail.gmx.net (mp038) with SMTP; 05 May 2012 21:59:17 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+i/JdLOLuivO0s9EURVa1NLN3tuCw2gQ6DK1yjZx aSUy1hhnwrH2pY From: Bjoern Hoehrmann To: Magnus Westerlund Date: Sat, 05 May 2012 21:59:18 +0200 Message-ID: References: <4F99654A.5070600@ericsson.com> In-Reply-To: <4F99654A.5070600@ericsson.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: Delayed for 00:26:39 by milter-greylist-4.0 (pechora5.dc.icann.org [192.0.46.71]); Sat, 05 May 2012 20:26:20 +0000 (UTC) Cc: "'ietf-types@iana.org'" , "mmusic-chairs@tools.ietf.org" Subject: Re: [ietf-types] Review of text/parameters 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: Sat, 05 May 2012 20:26:50 -0000 * Magnus Westerlund wrote: >https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/ >22.16. Media Type Registration for text/parameters > > Type name: text > > Subtype name: parameters > > Required parameters: > > Optional parameters: Well, text types usually have a 'charset' parameter, and applications are known to treat, say, a HTTP response with Content-Type: text/parameters;charset=iso-8859-1 As ISO-8859-1 encoded document, even though I gather they are to use UTF-8 to decode the document. If you don't want a 'charset' parameter, this problem should be noted in the Security or Interoperability con- siderations. > Encoding considerations: This field needs a value (probably "8bit" or "binary"). -- 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 A1FDA21F85D5 for ; Sat, 5 May 2012 13:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HE3srlFt8Kn for ; Sat, 5 May 2012 13:12:30 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id A7F4E21F85C6 for ; Sat, 5 May 2012 13:12:29 -0700 (PDT) Received: (qmail invoked by alias); 05 May 2012 20:12:28 -0000 Received: from dslb-094-223-209-045.pools.arcor-ip.net (EHLO HIVE) [94.223.209.45] by mail.gmx.net (mp030) with SMTP; 05 May 2012 22:12:28 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18krWkHe84kwVMWpRod6vDMoXWw+8XO5Wypk3NbUN uRpGy4dscYNwyI From: Bjoern Hoehrmann To: Shida Schubert Date: Sat, 05 May 2012 22:12:30 +0200 Message-ID: References: <23BBA3A7-A445-43C3-96EE-9497E5F50012@ntt-at.com> In-Reply-To: <23BBA3A7-A445-43C3-96EE-9497E5F50012@ntt-at.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: ietf-types@ietf.org Subject: Re: [ietf-types] Review of application/call-completion registration 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: Sat, 05 May 2012 20:12:30 -0000 * Shida Schubert wrote: > The draft below registers the following new media type: >application/call-completion. Your comments on this registration are >appreciated. > >Thanks & Regards > Shida Schubert > >http://tools.ietf.org/html/draft-ietf-bliss-call-completion-14 > > * RFCXXXX refers to the draft above. > > MIME media type name: application > > MIME subtype name: call-completion This is using an outdated template, the current one is in RFC 4288. Some of the field names are different and differently organized there. > Required parameters: none. > > Optional parameters: none. > > Encoding considerations: Consists of lines of UTF-8-encoded > characters, ended with CR-LF Then this should simply say "8bit" or "binary", see RFC 4288 for the de- finitions. -- 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 1273021F8611 for ; Sat, 5 May 2012 13:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_48=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGAxuw967Z6z for ; Sat, 5 May 2012 13:10:45 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 1413221F860E for ; Sat, 5 May 2012 13:10:44 -0700 (PDT) Received: (qmail invoked by alias); 05 May 2012 20:10:43 -0000 Received: from dslb-094-223-209-045.pools.arcor-ip.net (EHLO HIVE) [94.223.209.45] by mail.gmx.net (mp039) with SMTP; 05 May 2012 22:10:43 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+S5QZiPmiSDVJ7vqvO5itNRenQHxW6dmwM5lcOmg rAeYA3nj3luH+5 From: Bjoern Hoehrmann To: Eric Prud'hommeaux Date: Sat, 05 May 2012 22:10:45 +0200 Message-ID: References: <20120418153629.GB29120@w3.org> In-Reply-To: <20120418153629.GB29120@w3.org> 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] Request for review of N-Triples (an RDF serialization) media type: application/n-triples 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: Sat, 05 May 2012 20:10:57 -0000 * Eric Prud'hommeaux wrote: >Type name: > application >Subtype name: > n-triples >Required parameters: > None >Optional parameters: > None >Encoding considerations: > The syntax of N-Triples is expressed over code points in Unicode [UNICODE]. The encoding is always UTF-8 [UTF-8]. > Unicode code points may also be expressed using an \uXXXX (U+0 to U+FFFF) or \UXXXXXXXX syntax (for U+10000 onwards) where X is a hexadecimal digit [0-9A-F] This is supposed to simply say something like "8bit" or "binary", see RFC 4288 for details. >Security considerations: I have not look at these, but since this is very long, it might make more sense to have this as part of the Security Considerations section of the document that defines the format, and simply put a reference into the template. >Published specification: > This specification. As I recall it, unlike for RFC registrations, IANA would put this in a document on their site, so this should give a full(er) citation. If you want to say anything about fragment identifiers, like what the `#example` in `http://example.org/example.nt#example` refers to, or if you want to discourage such usage, that should be included. Not a requirement currently, but since this is an RDF type, this might be relevant. -- 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/