From A.Hoenes@TR-Sys.de Fri Oct 1 00:39:49 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F98F3A6C3B for ; Fri, 1 Oct 2010 00:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.087 X-Spam-Level: X-Spam-Status: No, score=-97.087 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i17lFu1QARYt for ; Fri, 1 Oct 2010 00:39:48 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 77B483A6B5B for ; Fri, 1 Oct 2010 00:39:47 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA259308681; Fri, 1 Oct 2010 09:38:01 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id JAA15951; Fri, 1 Oct 2010 09:38:00 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201010010738.JAA15951@TR-Sys.de> To: barryleiba@computer.org, apps-discuss@ietf.org Date: Fri, 1 Oct 2010 09:37:59 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] WG Review: Applications Area Working Group (APPSAWG) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 07:39:49 -0000 Barry Leiba wrote, regarding the criteria for work items in the draft APPSAWG charter: > ... It might also make sense to use an unordered list (with "*") > instead of an ordered one (with numbers), just to be clear that > it's neither explicitly ordered nor exhaustive. +1 -- Splendid observation! The only downside would be that, in arguing about proposals or -- even more omportantly -- in documenting the decision to refuse a proposal for adoption, the language would become less transparent when it needs to reference some of the criteria. But IMO that is tractable. BR, Alfred. From sm@elandsys.com Fri Oct 1 18:31:34 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 784613A6D39 for ; Fri, 1 Oct 2010 18:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FunnfIKLE6Y for ; Fri, 1 Oct 2010 18:31:33 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id 32FE83A6C43 for ; Fri, 1 Oct 2010 18:31:33 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.232.52]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id o921WCkm006612 for ; Fri, 1 Oct 2010 18:32:18 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1285983139; bh=gDRO8NrDcRhjpAND5dNqD4LdPfM=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type: Content-Transfer-Encoding; b=SZcsBpwRmeAyHZz/a/BTfqHNUdXbqBigXMObfo6Sy0Ts1OvF+XmFokkjAYDafKGwR gVgdSSc3kEg7O1bEJ0zfgY2Zzk7s2uimFNa9NHTi7IlA0avhYzr5pz1OpZ/PmrjQxh mPMxN/+OMgywfZ1k6Trrsgm8oOVL2Lei3p6w06Ew= Message-Id: <6.2.5.6.2.20101001172245.074c0460@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 01 Oct 2010 18:31:01 -0700 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [apps-discuss] Apps Area Review Team Report for September 2010 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 01:31:34 -0000 Hello, The Applications Area Review Team provides=20 semi-formal reviews of Internet-Drafts as a way=20 to improve the quality of IETF=20 specifications. The members of the team are=20 selected from the IETF community, especially from=20 among active participants and recognized experts in the Applications Area. I would like to thank Tim Bray for accepting to=20 join the Applications Area Review Team and Julian=20 Reschke for accepting the reassignment of the=20 review which was requested by the ECRIT WG. The team reviewed 14 Internet-Drafts in September=20 2010. Nine of the I-Ds were from working groups outside the Applications= Area. Reviewer I-D Claudio Allocchio draft-das-mipshop-andsf-dhcp-options-04 Dave Cridland draft-ietf-fecframe-sdp-elements-08 Vijay K. Gurbani draft-ietf-geopriv-arch-02 Eliot Lear draft-ietf-grow-mrt-13 Dave Cridland draft-ietf-tcpm-urgent-data-06 Ted Hardie draft-mavrogiannopoulos-rfc5081bis-06 Murray S. Kucherawy draft-ietf-fecframe-framework-10 Carsten Bormann draft-ietf-netmod-arch-09 Yves Lafon draft-ietf-l3vpn-mvpn-spmsi-joins-01 Mark Nottingham draft-merrick-jms-uri-09 Julian Reschke draft-ietf-ecrit-lost-sync-09 Eran Hammer-Lahav draft-lundberg-app-tei-xml-03 S. Moonesamy draft-arkko-townsley-coexistence-04 Martin D=FCrst draft-ietf-geopriv-policy-21 Pending review: draft-ietf-netmod-dsdl-map-05 assigned to Aaron Stone Reviews that are due this month are not listed above. The team is looking for reviewers with XML=20 expertise as there were several requests for=20 expert review of the use of XML in I-Ds. Please=20 email me if you would like to volunteer. Regards, S. Moonesamy On behalf of the Apps Review Team http://www.apps.ietf.org/content/applications-area-review-team From sm@resistor.net Sat Oct 2 00:38:32 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2A8B3A6C84 for ; Sat, 2 Oct 2010 00:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.721 X-Spam-Level: X-Spam-Status: No, score=-102.721 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQyCGUE6knQZ for ; Sat, 2 Oct 2010 00:38:29 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 642633A6CAD for ; Sat, 2 Oct 2010 00:38:29 -0700 (PDT) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o927cmqM018546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Oct 2010 00:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1286005150; x=1286091550; bh=ROPZJDGOXtYblGvOUNuuRZMOThESLdrKBT1JGC9pD9Y=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=lxqLI+wnj66E3QG1s2p3xcU3mXGf7DJw87Sr5BCH3N7QkpfmDpNcKvn5MnCRrsMmp Z3RW6iq33uafBnGGBuwsbSpm0LW2YNdzsLKU4+PM77398OCa2wUP0+pYVDlvE36iOQ ab3aFCt3pexDRGjrS9Hh/Iyzi6W5OCJedr1v4Qoc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1286005150; x=1286091550; bh=ROPZJDGOXtYblGvOUNuuRZMOThESLdrKBT1JGC9pD9Y=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=m7nha5E9O/x7uU2B8mT/NPnmyZcaDdQkBI5s/MLMKtyKGPQy+hl80CqsPlteW1dqI nqScsOKWI9aQw7OqEVwFIUqHwJdsM+lUPuONkOV4KbhsqD/6DkebffUvytT+3FfOSb PfbBhDcDOuon6KJKUilejzKwqjQ0u5Si/aGE+WDs= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=078SqFQ1yK9Xxh+42zfiR5v0QphSqcFC2Q04EuFIwRap0sK2eLLG1m2SyEuDBniJ9 RhhEbUb5r5e5EYKWbnlTgT1fOz1xSE6MtBvB0jzQjUonjY9+ippumQPGjDP+KeMjHCd K5d4VFWxUSuplMzBUO2iZ+iN89GmlvGZYW5LZYI= Message-Id: <6.2.5.6.2.20101001234611.00d2c6c8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 02 Oct 2010 00:37:23 -0700 To: apps-discuss@ietf.org From: SM In-Reply-To: <4CA118E9.2090203@stpeter.im> References: <4CA118E9.2090203@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] Fwd: I-D Action:draft-hartmann-default-port-for-irc-via-tls-ssl-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 07:38:32 -0000 At 15:21 27-09-10, Peter Saint-Andre wrote: >I'm not sure if IRC counts as Apps or RAI these days, but I figured this >I-D might be of interest here... Send it to RAI. :-) The Abstract section should be the first section. If the document is to establish a "best current practice", it should be published on the Standards Track instead of Informational. If it is only about registering a port, it does not have to be on that track. This draft may attract the attention of the "security" community and the discussions might go on a tangent. How does this document update RFC 1459, RFC 2810, RFC 2811, RFC 2812 and RFC 2813? In Section 1: "Although system port assignments for both plain text (TCP port 194) and TLS/SSL encrypted (TCP port 994) IRC traffic exist [IANALIST], it is common practice amongst IRC networks not to use them for reasons of convenience and general availability on systems where no root access is granted or desired." draft-ietf-tsvwg-iana-ports-06 provides some information about the assignments of port numbers in the past. As the port number space is a limited resource, how can the formal assignments of one more ports be justified? "This is covered by the IRCU assignment of TCP/UDP ports 6665-6669." Although it is common practice to use these ports, they are current listed as unassigned. In Section 2: "This document does not directly discuss security issues, however the lack of a common, well established listening port for IRC via TLS/SSL could lead to end users being unaware of their IRC network of choice supporting TLS/SSL." Please see RFC 2782. Regards, -sm From richih.mailinglist@gmail.com Sat Oct 2 16:29:31 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E70393A6CED for ; Sat, 2 Oct 2010 16:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5onnXTbY6I4X for ; Sat, 2 Oct 2010 16:29:30 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id DAC7E3A6C53 for ; Sat, 2 Oct 2010 16:29:29 -0700 (PDT) Received: by iwn3 with SMTP id 3so6413819iwn.31 for ; Sat, 02 Oct 2010 16:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=39OaybyMUcXJLN6WIyI8LalqKeEQqXbyJELdlHKiXrE=; b=gLxWUC0CkQ9s6IVJ/Auhm2VhLEzJdInbeLqHOh0H2c+xw1j+pdVbOwz78dJI50Z/av qzoKk/xjxetAaiZlcOtAHOb/zH4GB4t6CiMJfwGJ2az6zjrxr1jT0QyldRumPSUBl6jW Fl5UvelPzdndNyyo21YsdctcPvbGWgiuroVWQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=lPKrMyTVZayqUgqDx1M9vc2pZ8cmqAGB1ApMiMQs00legK+z9nPE8cPEGL8GT+ehX0 lEYNgLB5Z5QPeavAk2KfWNhspPInA9LYiS/yDK70nEp7CzrYibWfIY3pmJJmbnuvzJ3C 5TqyCUhDbPBa8MmbtRnaTGE+jj+uPWZiJTuns= Received: by 10.231.160.17 with SMTP id l17mr7846720ibx.102.1286062220965; Sat, 02 Oct 2010 16:30:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.156.16 with HTTP; Sat, 2 Oct 2010 16:29:53 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20101001234611.00d2c6c8@resistor.net> References: <4CA118E9.2090203@stpeter.im> <6.2.5.6.2.20101001234611.00d2c6c8@resistor.net> From: Richard Hartmann Date: Sun, 3 Oct 2010 01:29:53 +0200 Message-ID: To: SM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: I-D Action:draft-hartmann-default-port-for-irc-via-tls-ssl-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Oct 2010 23:29:32 -0000 On Sat, Oct 2, 2010 at 09:37, SM wrote: > Send it to RAI. :-) OK, I will :) > The Abstract section should be the first section. The docs state that the abstract can be put before or after the leading boilerplate, but must be before the TOC. I am fine with either position. > If the document is to establish a "best current practice", it should be > published on the Standards Track instead of Informational. =C2=A0If it is= only > about registering a port, it does not have to be on that track. =C2=A0Thi= s draft > may attract the attention of the "security" community and the discussions > might go on a tangent. I am still unsure about this. Initally, I was told that Informational RFCs = are a lot easier for both author and the RFC editors and that the could be submitted directly. It seems this has changed recently as the RFC editors asked me to start with an I-D, first. As I am going the I-D route anyway, it probably makes sense to switch away from Informational. > How does this document update RFC 1459, RFC 2810, RFC 2811, RFC 2812 and = RFC > 2813? Those are the RFCs referring to IRC. I thought it would be better to err on the save side & include them. > draft-ietf-tsvwg-iana-ports-06 provides some information about the > assignments of port numbers in the past. =C2=A0As the port number space i= s a > limited resource, how can the formal assignments of one more ports be > justified? According to the IANA [1]: "The IESG believes that IANA may allocate an additional port in the 'user port' range to protocols whose current port allocation requires access to a privileged port. This allocation should not be automatic, but may occur upon application by an interested party whose application would otherwise fit IANA's policies." > Although it is common practice to use these ports, they are current liste= d > as unassigned. No, see [2]. > Please see RFC 2782. Realistically speaking, this will not be implemented in IRC. Not ideal, granted. But realistic. Thanks for your feedback, Richard [1] http://www.iana.org/cgi-bin/usr-port-number.pl [2] http://www.iana.org/assignments/port-numbers From sm@resistor.net Sat Oct 2 22:54:48 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 665013A6E43 for ; Sat, 2 Oct 2010 22:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.711 X-Spam-Level: X-Spam-Status: No, score=-102.711 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52hy+4+gr9oH for ; Sat, 2 Oct 2010 22:54:45 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 9F5603A6B40 for ; Sat, 2 Oct 2010 22:54:45 -0700 (PDT) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o935tPi5013920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Oct 2010 22:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1286085334; x=1286171734; bh=p3KxThRV86q6TCdr6d6/aJrWCBMzQOyLyKJZcGleZSQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=QRecUZ8g2MNAgJ0RMy/HteDzJea8e2kg5KlJrvYN7qHqelRtm/lO7S6b4RWgU/Qsd mrK2FW8X0uttzZ/cEWusBHfVykjzzeSZNM0hr00H7QdhWzKANbKgk3fEYNngFPCdCC f8kMeioHnUrQHdcuRnXgoAgpdB1KPL9zrDmD04qw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1286085334; x=1286171734; bh=p3KxThRV86q6TCdr6d6/aJrWCBMzQOyLyKJZcGleZSQ=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=agFv5A2A13QCO40oZ5HgBWvJb3SeaRWsl7ex7iqBgtXNbbNjh0LrNm8A2+hAcn4il q+Yx3QQPsWUXMhi8Abd5elcMH83CpYkp1kchQjl+pvd1EPTFwqIt+ivUGYmPU2wfdk 8gGy6785mxLe3n1KA4Gqzuv91yf6VcLfmEo0oZ7o= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=uqVh+NIOZQBhBiyq3mePflgkOdmmCuxGKr+mmQlsL1RiChnek0C6TbrxdK0BbR+W7 JXQqNlhSOKeg9jzts8CFPz9K7rkB6Xf/diiVhN9N1T6JmE4ct05laBwbrQfAyhHuT0l 3Rrey0FaOiLVyPSpkrq0RGgdN2PXrZ3RQW69zbY= Message-Id: <6.2.5.6.2.20101002212646.0ad637e0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 02 Oct 2010 22:46:29 -0700 To: Richard Hartmann From: SM In-Reply-To: References: <4CA118E9.2090203@stpeter.im> <6.2.5.6.2.20101001234611.00d2c6c8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: I-D Action:draft-hartmann-default-port-for-irc-via-tls-ssl-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Oct 2010 05:54:48 -0000 Hi Richard, At 16:29 02-10-10, Richard Hartmann wrote: >OK, I will :) I see that you got better feedback from RAI. >I am still unsure about this. Initally, I was told that Informational RFCs are >a lot easier for both author and the RFC editors and that the could be >submitted directly. It seems this has changed recently as the RFC editors >asked me to start with an I-D, first. >As I am going the I-D route anyway, it probably makes sense to switch >away from Informational. Documents always start as Internet-Drafts whether they are intended as Informational or Standards Track in the IETF Stream or Informational in the Independent Submissions Stream (RFC 4846). Adam Roach already mentioned [1] that it is going to be a lot of work if the document goes beyond the formal registration of the port. >Those are the RFCs referring to IRC. I thought it would be better to err >on the save side & include them. The status of RFC 1459 is Experimental. That RFC was updated by RFC 2810, RFC 2811, RFC 2812 and RFC 2813 which were published as Informational RFCs. draft-hartmann-default-port-for-irc-via-tls-ssl is somewhat related to Section 7.2 of RFC 2813. >According to the IANA [1]: See below. >No, see [2]. I missed that. Regards, -sm 1. http://www.ietf.org/mail-archive/web/rai/current/msg00943.html From prvs=887a25b37=eric@tibco.com Tue Oct 5 15:46:44 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 467033A6CAB; Tue, 5 Oct 2010 15:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2i8-i2T5t3b; Tue, 5 Oct 2010 15:46:42 -0700 (PDT) Received: from mx2-app.tibco.com (mx2-app.tibco.com [63.100.100.143]) by core3.amsl.com (Postfix) with ESMTP id E2D813A6D62; Tue, 5 Oct 2010 15:46:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.57,286,1283756400"; d="scan'208";a="15621962" Received: from tibco-5.tibco.com (HELO na-pa-fe01.na.tibco.com) ([63.100.100.5]) by mx2-app.tibco.com with ESMTP; 05 Oct 2010 15:45:40 -0700 Received: from koosh.na.tibco.com ([10.105.178.25]) by na-pa-fe01.na.tibco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Oct 2010 15:45:40 -0700 Message-ID: <4CABAACB.3060703@tibco.com> Date: Tue, 05 Oct 2010 15:46:35 -0700 From: Eric Johnson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100913 Lightning/1.0b3pre Thunderbird/3.1.3 MIME-Version: 1.0 To: Mark Nottingham , SOAP-JMS References: <80FDD367-70D7-4EA1-8A03-A560F43024F5@mnot.net> In-Reply-To: <80FDD367-70D7-4EA1-8A03-A560F43024F5@mnot.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Oct 2010 22:45:40.0192 (UTC) FILETIME=[0903CE00:01CB64DF] X-TM-AS-Product-Ver: SMEX-10.0.0.1412-6.500.1024-17686.002 X-TM-AS-Result: No--34.707100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: draft-merrick-jms-uri@tools.ietf.org, IESG IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] APP Area Review of draft-merrick-jms-uri-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 22:46:44 -0000 Hi Mark, Thanks for your feedback. I'm looking to incorporate your changes, and have a few questions. On 09/24/2010 06:52 PM, Mark Nottingham wrote: > Hello, > > I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see ). > > Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. > > Document: draft-merrick-jms-uri-09 > Reviewer: Mark Nottingham > Review Date: 2010-09-25 > > Summary: This draft is not ready for publication as an Informational RFC and should be revised before publication. > > Major Issues: > > 1. Section 3: The proposed syntax reuses "path-rootless" from RFC3986. However, it does not match the "absolute-URI" production from the same RFC, because of the introduction of the extra "jms-variant" rule. This means that URI parsing implementations may not be able to recognise the hierarchical components and expose them meaningfully, and is in conflict section 2.2 of RFC4395. That specification requires that such issues be documented in provisional registrations. Point of confusion - the JMS URI scheme does not have any hierarchical parts, so there is no way to extract them and expose them meaningfully. It is more like a URN in this regard. So far as I can tell, the syntax does match up: (3986): absolute-URI = scheme ":" hier-part [ "?" query ] (jms) jms-uri = "jms:" jms-variant ":" jms-dest [ "?" param *( "&" param ) ] <"jms"> corresponds to <"scheme">. The question the is whether matches . Of the four options for , we've chosen "path-rootless" to match: (3986): path-rootless = segment-nz *( "/" segment ) (jms) .... = jms-variant ":" jms-dest (jms) jms-variant = segment-nz-nc (jms) jms-dest = path-rootless If is taken without any "/" segments, then this seems to patch the production. Did I miss something? Perhaps if we change the production to "segment-nz", will that address your concern? > 2. The proposed URI scheme does allow resources to be located, but does not define a protocol to do so; rather it defines it in terms of an API (JMS). Thus, there is no wire-level protocol that can be used to build an interoperable implementation; rather, one needs to rely on a vendor's mapping of the API to a wire-level protocol (an issue which Section 1 attempts to address). Strictly speaking, this is true. Unfortunately, it is utterly out of our control to actually address this situation, yet we find ourselves with the need to put something like the "jms" URI in WSDL & SCA documents in places that take HTTP URLs in other use cases. Also, some vendors have defined mappings to well known (AMQP) or publicly available protocols [1], so to us, saying there is "no wire-level protocol" for interoperability seems like a generalization, or it depends on your definition of interoperability. I guess I tend to look at the "interoperability" question at two different levels - is the protocol mapping properly documented - in which case interoperability is possible - and at the second level, has the mapping been standardized via a standards development organization. Clearly, we don't have the latter, but we do have the former, at least for some implementations. Also, to cast ourselves in a slightly more favorable light, 99% of the uses of HTTP employ a library that does the real work, and there are only a relatively small collection of those libraries in the world, compared to the number of applications that use HTTP. People who *don't* use those libraries tend to be quite vulnerable to security risks.... This doesn't excuse the lack of a standardized protocol for JMS, but as I mentioned, that situation is out of our control. Is there additional text, or even an outline of key points that would clarify the answer to the concerns you raise here? > It doesn't necessarily follow that the registration is invalid as a result, but allowing a URI scheme to specify an API rather than a protocol for purposes of interoperability is counter to widely-held beliefs in the IETF, and arguably also conflicts with the spirit of the Architecture of the World Wide Web . Besides effectively limiting the use of this URI scheme to one language (Java), it also means that interoperability will be difficult to achieve between implementations. As to conflicting with the "Architecture of the World Wide Web", I agree that it doesn't fit there. In a sense, this question can devolve in an endless discussion on the merits of REST vs. SOAP. The JMS URI identifies a communication endpoint resource, not a document resource. In that sense, it is much like a "mailto:" URI or a "tel" URI - dereferencing those will be just as meaningless. Many JMS implementations do have clients in other languages, so use of this URI is not restricted to a single language. Many JMS clients write to the JMS API, and can transfer between implementations without difficulty, so in that sense, the marketplace has already provided interoperability. The authors of this specification are working on defining a mapping of SOAP over JMS, and in doing so, we are relying on the fact that it will be possible to switch out the underlying JMS implementation as our customers wish. Again, the question - is there specific text, or key points we should touch on that you think we should add? > While it may be appropriate to register widely-used schemes in order to document current use, but that doesn't appear to be the case here (as evident in the abstract). As such, the document should more prominently warn about interoperability issues inherent in this approach. JMS schemes are in current use. Here we are attempting to address the shortcomings of all those existing approaches. I don't know exactly how to define "widely-used", so I won't argue for or against that, but I do note that (as the draft itself notes) there are two standards efforts currently underway that use the draft form of the JMS URI scheme we've defined. The last paragraph of the introduction isn't warning enough? What more do you have in mind? > 3. It's not clear whether this registration reflects the position of all potential users. In particular, the specification of JMS and associated APIs is maintained by the Java Community Process , but this request does not state what its relation to the JCP is. An informal liaison might clarify this issue. So far as we can tell, there is no ongoing work in the JCP for JMS. We've not been successful in finding ways to contact those people involved in the original creation of the specifications. I have thought of contacting all the obviously known implementations of JMS [2] to directly solicit their input, at least where we haven't heard from us already. Would that ameliorate this concern? > Minor Issues: > > 1. The proposed scheme specifies an extensibility point, "jms-variant", but does not specify a registry or other means of disambiguating variants and avoiding collisions. We see very little chance of any registration of jms-variants. What would it mean to specify a registry? What's the infrastructure to do that? How hard is it to register? -Eric > Regards, > > > -- > Mark Nottingham http://www.mnot.net/ [1] http://activemq.apache.org/openwire.html [2] http://en.wikipedia.org/wiki/Java_Message_Service#Provider_implementations > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From richih.mailinglist@gmail.com Wed Oct 6 05:39:15 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13DC83A6F2F for ; Wed, 6 Oct 2010 05:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GdQ2dxITQ6f for ; Wed, 6 Oct 2010 05:39:14 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 1F0FD3A6D93 for ; Wed, 6 Oct 2010 05:39:14 -0700 (PDT) Received: by iwn3 with SMTP id 3so11515986iwn.31 for ; Wed, 06 Oct 2010 05:40:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=0zd4XwQx7U2zBEfaw3XYRA6vGBnnONXqZi0SKVbWWbA=; b=MT/jkmteFdtDgSMnXy8Vg2kuQEOdHRI5+KdiLV4AMa99oTBDL36UEXZIT8Q+Qr1vud sfYEK4YIgAo3ZkUGKg7TogPWhRJ3ofaioDg1V/Db7m+MA8S2gMJgtYSnRmkhQJ4+Vps+ kdVjSoVfPm4SN3NcpClQq6eNhASZT0vPPNhwM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=WbRLxoXWhKjRvkABKrLjNIveO7cevdy8AtBjqSwyXgQk93r/R7hD5U8Smc7qR34Hwr XnGAOG8XVLXYETk6Zu1D2rCmF77j4z25JZ7XoE2Lwkhnk6bYzS3PJ5YveUevrjAQzrXL KPWI4IbD+nKqOBe4tBR/SSUX0TkdWjaAojIwE= Received: by 10.231.33.71 with SMTP id g7mr13822055ibd.54.1286368807787; Wed, 06 Oct 2010 05:40:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.156.16 with HTTP; Wed, 6 Oct 2010 05:39:46 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20101002212646.0ad637e0@resistor.net> References: <4CA118E9.2090203@stpeter.im> <6.2.5.6.2.20101001234611.00d2c6c8@resistor.net> <6.2.5.6.2.20101002212646.0ad637e0@resistor.net> From: Richard Hartmann Date: Wed, 6 Oct 2010 14:39:46 +0200 Message-ID: To: SM Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: I-D Action:draft-hartmann-default-port-for-irc-via-tls-ssl-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 12:39:15 -0000 On Sun, Oct 3, 2010 at 07:46, SM wrote: > I see that you got better feedback from RAI. Indeed. I could not answer yet, but I am about to after I finish this mail. > Documents always start as Internet-Drafts whether they are intended as > Informational or Standards Track in the IETF Stream or Informational in t= he > Independent Submissions Stream (RFC 4846). =C2=A0Adam Roach already menti= oned [1] > that it =C2=A0is going to be a lot of work if the document goes beyond th= e formal > registration of the port. I still not sure how this could be that much work seeing as the I-D is limi= ted to a small subset of the issues. More on that in the other thread, though. > The status of RFC 1459 is Experimental. =C2=A0That RFC was updated by RFC= 2810, > RFC 2811, RFC 2812 and RFC 2813 which were published as Informational RFC= s. > =C2=A0draft-hartmann-default-port-for-irc-via-tls-ssl is somewhat related= to > Section 7.2 of RFC 2813. Afaik, RFC 1459 has been updated but not obsoleted by the other RFCs so I s= till think it should be included unless transitive Updates: are the norm. > See below. As in, you missed that as well? Thanks, Richard From mnot@mnot.net Wed Oct 6 12:56:57 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AF633A7031; Wed, 6 Oct 2010 12:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.24 X-Spam-Level: X-Spam-Status: No, score=-106.24 tagged_above=-999 required=5 tests=[AWL=-4.260, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUiCfN9Igv7h; Wed, 6 Oct 2010 12:56:55 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 1CF843A6FE1; Wed, 6 Oct 2010 12:56:54 -0700 (PDT) Received: from [192.168.22.12] (unknown [209.131.62.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3BA4D509DF; Wed, 6 Oct 2010 15:57:48 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4CABAACB.3060703@tibco.com> Date: Wed, 6 Oct 2010 12:57:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <74287C97-5925-4CB6-B406-E4B382BDC19C@mnot.net> References: <80FDD367-70D7-4EA1-8A03-A560F43024F5@mnot.net> <4CABAACB.3060703@tibco.com> To: Eric Johnson X-Mailer: Apple Mail (2.1081) Cc: SOAP-JMS , draft-merrick-jms-uri@tools.ietf.org, IESG IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] APP Area Review of draft-merrick-jms-uri-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 19:56:57 -0000 Hi Eric, Responses inline. On 05/10/2010, at 3:46 PM, Eric Johnson wrote: > Hi Mark, >=20 > Thanks for your feedback. I'm looking to incorporate your changes, = and > have a few questions. >=20 > On 09/24/2010 06:52 PM, Mark Nottingham wrote: >> Hello, >>=20 >> I have been selected as the Applications Area Review Team reviewer = for this draft (for background on apps-review, please see = ). >>=20 >> Please resolve these comments along with any other Last Call comments = you may receive. Please wait for direction from your document shepherd = or AD before posting a new version of the draft. >>=20 >> Document: draft-merrick-jms-uri-09 >> Reviewer: Mark Nottingham >> Review Date: 2010-09-25 >>=20 >> Summary: This draft is not ready for publication as an Informational = RFC and should be revised before publication. >>=20 >> Major Issues:=20 >>=20 >> 1. Section 3: The proposed syntax reuses "path-rootless" from = RFC3986. However, it does not match the "absolute-URI" production from = the same RFC, because of the introduction of the extra "jms-variant" = rule. This means that URI parsing implementations may not be able to = recognise the hierarchical components and expose them meaningfully, and = is in conflict section 2.2 of RFC4395. That specification requires that = such issues be documented in provisional registrations. >=20 > Point of confusion - the JMS URI scheme does not have any hierarchical > parts, so there is no way to extract them and expose them = meaningfully.=20 > It is more like a URN in this regard. >=20 > So far as I can tell, the syntax does match up: >=20 > (3986): absolute-URI =3D scheme ":" hier-part [ "?" query ] > (jms) jms-uri =3D "jms:" jms-variant ":" jms-dest [ "?" param *( "&" = param ) ] >=20 > <"jms"> corresponds to <"scheme">. The question the is whether > matches . >=20 > Of the four options for , we've chosen "path-rootless" to = match: >=20 > (3986): path-rootless =3D segment-nz *( "/" segment ) > (jms) .... =3D jms-variant ":" jms-dest > (jms) jms-variant =3D segment-nz-nc > (jms) jms-dest =3D path-rootless >=20 > If is taken without any "/" segments, then this seems = to > patch the production. >=20 > Did I miss something? Perhaps if we change the production = to > "segment-nz", will that address your concern? Yes. >> 2. The proposed URI scheme does allow resources to be located, but = does not define a protocol to do so; rather it defines it in terms of an = API (JMS). Thus, there is no wire-level protocol that can be used to = build an interoperable implementation; rather, one needs to rely on a = vendor's mapping of the API to a wire-level protocol (an issue which = Section 1 attempts to address).=20 >=20 > Strictly speaking, this is true. Unfortunately, it is utterly out of > our control to actually address this situation, yet we find ourselves > with the need to put something like the "jms" URI in WSDL & SCA > documents in places that take HTTP URLs in other use cases. >=20 > Also, some vendors have defined mappings to well known (AMQP) or > publicly available protocols [1], so to us, saying there is "no > wire-level protocol" for interoperability seems like a generalization, > or it depends on your definition of interoperability. I guess I tend = to > look at the "interoperability" question at two different levels - is = the > protocol mapping properly documented - in which case interoperability = is > possible - and at the second level, has the mapping been standardized > via a standards development organization. Clearly, we don't have the > latter, but we do have the former, at least for some implementations. >=20 > Also, to cast ourselves in a slightly more favorable light, 99% of the > uses of HTTP employ a library that does the real work, and there are > only a relatively small collection of those libraries in the world, > compared to the number of applications that use HTTP. People who > *don't* use those libraries tend to be quite vulnerable to security > risks.... At the risk of having a tangental discussion, I think you're wrong here. > This doesn't excuse the lack of a standardized protocol for JMS, but = as > I mentioned, that situation is out of our control. >=20 > Is there additional text, or even an outline of key points that would > clarify the answer to the concerns you raise here? See below. >> It doesn't necessarily follow that the registration is invalid as a = result, but allowing a URI scheme to specify an API rather than a = protocol for purposes of interoperability is counter to widely-held = beliefs in the IETF, and arguably also conflicts with the spirit of the = Architecture of the World Wide Web = . Besides effectively = limiting the use of this URI scheme to one language (Java), it also = means that interoperability will be difficult to achieve between = implementations. >=20 > As to conflicting with the "Architecture of the World Wide Web", I = agree > that it doesn't fit there. In a sense, this question can devolve in = an > endless discussion on the merits of REST vs. SOAP. The JMS URI > identifies a communication endpoint resource, not a document resource.=20= > In that sense, it is much like a "mailto:" URI or a "tel" URI - > dereferencing those will be just as meaningless. No; there is a specific concern here that, historically, the IETF has = achieved interoperability on the wire by defining protocols. My purpose = in pointing this out was to make sure that the community was aware of = this aspect of the proposed registration when evaluating the draft. > Many JMS implementations do have clients in other languages, so use of > this URI is not restricted to a single language. >=20 > Many JMS clients write to the JMS API, and can transfer between > implementations without difficulty, so in that sense, the marketplace > has already provided interoperability. The authors of this > specification are working on defining a mapping of SOAP over JMS, and = in > doing so, we are relying on the fact that it will be possible to = switch > out the underlying JMS implementation as our customers wish. >=20 > Again, the question - is there specific text, or key points we should > touch on that you think we should add? It would be helpful if there were a paragraph inserted in the = Introduction, before the last paragraph there: While the "jms" URI scheme allows the location of network resources, it = does not map to a single underlying protocol, unlike most other URI = schemes that do so. Instead, it achieves interoperability through use of = a common Java API for messaging. Because of this, interoperability is = dependent upon the implementation of the API and its capabilities; two = implementations of JMS may or may not interoperate in practice. = Furthermore, it may be impractical to use "jms" URIs in non-Java = environments. >> While it may be appropriate to register widely-used schemes in order = to document current use, but that doesn't appear to be the case here (as = evident in the abstract). As such, the document should more prominently = warn about interoperability issues inherent in this approach. >=20 > JMS schemes are in current use. Here we are attempting to address the > shortcomings of all those existing approaches. I don't know exactly = how > to define "widely-used", so I won't argue for or against that, but I = do > note that (as the draft itself notes) there are two standards efforts > currently underway that use the draft form of the JMS URI scheme we've > defined. >=20 > The last paragraph of the introduction isn't warning enough? What = more > do you have in mind? The text above would achieve this. >> 3. It's not clear whether this registration reflects the position of = all potential users. In particular, the specification of JMS and = associated APIs is maintained by the Java Community Process = , but this request does not state what its relation to = the JCP is. An informal liaison might clarify this issue. >=20 > So far as we can tell, there is no ongoing work in the JCP for JMS.=20 > We've not been successful in finding ways to contact those people > involved in the original creation of the specifications. >=20 > I have thought of contacting all the obviously known implementations = of > JMS [2] to directly solicit their input, at least where we haven't = heard > from us already. Would that ameliorate this concern? I was thinking that the IETF (e.g., the responsible AD) should ping the = JCP to assure they're at least aware of this effort, and to give them an = opportunity to comment. I appreciate you've done your best to gather = consensus on this; it's just good form for the IETF to ask. >> Minor Issues:=20 >>=20 >> 1. The proposed scheme specifies an extensibility point, = "jms-variant", but does not specify a registry or other means of = disambiguating variants and avoiding collisions.=20 >=20 > We see very little chance of any registration of jms-variants. What > would it mean to specify a registry? What's the infrastructure to do > that? How hard is it to register? Normally, IANA is used for IETF registries; see RFC 5226. One additional comment - it sounds like your use cases for these URIs = might need some scheme-specific comparison / canonicalisation = guidelines. If so, it would be appropriate to include those in the = draft. Cheers, -- Mark Nottingham http://www.mnot.net/ From stpeter@stpeter.im Tue Oct 12 04:59:22 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 478F33A67D3 for ; Tue, 12 Oct 2010 04:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFIgk7GG-Nrj for ; Tue, 12 Oct 2010 04:59:21 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 509D13A67A8 for ; Tue, 12 Oct 2010 04:59:21 -0700 (PDT) Received: from squire.local (ip-216-17-182-107.rev.frii.com [216.17.182.107]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 87CF240337 for ; Tue, 12 Oct 2010 06:07:16 -0600 (MDT) Message-ID: <4CB44DE1.4070601@stpeter.im> Date: Tue, 12 Oct 2010 06:00:33 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] reminder: I-D cutoff dates X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 11:59:22 -0000 Just a reminder that the cutoff date for -00 drafts is this Monday, October 18, at 24:00 UTC. The date for drafts with higher version numbers is the following Monday, October 25, also at 24:00 UTC. Yes, IETF 79 is fast approaching! Peter -- Peter Saint-Andre https://stpeter.im/ From vkg@bell-labs.com Tue Oct 12 06:24:59 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFD3E3A67EA; Tue, 12 Oct 2010 06:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qn3utdiYzdx4; Tue, 12 Oct 2010 06:24:58 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id B41083A67AE; Tue, 12 Oct 2010 06:24:58 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o9CDPfT7029171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Oct 2010 08:25:42 -0500 (CDT) Received: from shoonya.ih.lucent.com (Knoppix-135185238233.ih.lucent.com [135.185.238.233]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o9CDPeV1025010; Tue, 12 Oct 2010 08:25:40 -0500 (CDT) Message-ID: <4CB46240.1070102@bell-labs.com> Date: Tue, 12 Oct 2010 08:27:28 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Thunderbird/3.0.7 MIME-Version: 1.0 To: Alissa Cooper References: <4C89558D.4000401@bell-labs.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: rbarnes@bbn.com, draft-ietf-geopriv-arch@tools.ietf.org, "apps-discuss@ietf.org" , IESG IESG Subject: Re: [apps-discuss] Apps-team review of draft-ietf-geopriv-arch-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 13:25:00 -0000 On 10/12/2010 05:13 AM, Alissa Cooper wrote: > Hi Vijay, > > Thanks for your review and apologies for the delayed reply. I've > incorporated changes based on your suggestions into the new draft, which > is at http://tools.ietf.org/html/draft-ietf-geopriv-arch-03.txt (the > diff is at > http://tools.ietf.org/wg/geopriv/draft-ietf-geopriv-arch/draft-ietf-geopriv-arch-03-from-02.diff.html). > I have just a couple of notes of clarification inline: Alissa: Your resolution are fine with me. Thanks for attending to these and I have no further follow-ups. Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From acooper@cdt.org Tue Oct 12 03:12:44 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C22A33A68FC; Tue, 12 Oct 2010 03:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTabyipFFb2d; Tue, 12 Oct 2010 03:12:43 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 4D8333A68F6; Tue, 12 Oct 2010 03:12:43 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Tue, 12 Oct 2010 06:13:46 -0400 Message-Id: From: Alissa Cooper To: Vijay K. Gurbani In-Reply-To: <4C89558D.4000401@bell-labs.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 12 Oct 2010 11:13:44 +0100 References: <4C89558D.4000401@bell-labs.com> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Tue, 12 Oct 2010 08:02:54 -0700 Cc: rbarnes@bbn.com, draft-ietf-geopriv-arch@tools.ietf.org, "apps-discuss@ietf.org" , IESG IESG Subject: Re: [apps-discuss] Apps-team review of draft-ietf-geopriv-arch-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 10:12:44 -0000 Hi Vijay, Thanks for your review and apologies for the delayed reply. I've incorporated changes based on your suggestions into the new draft, which is at http://tools.ietf.org/html/draft-ietf-geopriv-arch-03.txt (the diff is at http://tools.ietf.org/wg/geopriv/draft-ietf-geopriv-arch/draft-ietf-geopriv-arch-03-from-02.diff.html) . I have just a couple of notes of clarification inline: On Sep 9, 2010, at 10:45 PM, Vijay K. Gurbani wrote: > Minor issues: > ------------- > 1) In S2.2 you state that a LO can contain geodetic or civic > location data. Common sense argues that they should be the > same in the sense that they point to the same physical > location. However, is there a requirement to that effect in > the document (if there is, please disregard. But I do not > recall reading such a requirement)? What if they are different? In the paragraph you reference I added a reference to RFC5491, which provides some considerations for including multiple locations in one LO. > > 2) In Figure 3, there is a vertical line from LG to Device. > What information is sent on that interface? It is clear that > the vertical line from the Device to LG is sending some manner > of positioning data that the device wants to transmit. But > I am not sure what information the vertical line from LG to Device > carries. > > There is some text later on --- on the top of page 15 --- that > says "The LG provides assistance data to the Device". If so, > then a label containing this information should be placed > in Figure 3. We are using the term "positioning data" loosely to cover both measurements and assistance data. I made this more clear by inserting the word "positioning" before "information" at the top of page 16. > > Nits: > ------ > 1) S2.2, "Device" definition: Do you mean "The physical device ..." > when you wrote "The technical device ..."? > > 2) S3.2.2, opening sentence. "Some performing ..." What is the > object there? Some what? > Fixed both of these. Thanks, Alissa From ted.ietf@gmail.com Thu Oct 14 10:04:50 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09A013A6B49; Thu, 14 Oct 2010 10:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCWBTy3TZJA4; Thu, 14 Oct 2010 10:04:48 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 96DC33A6B25; Thu, 14 Oct 2010 10:04:47 -0700 (PDT) Received: by qyk8 with SMTP id 8so226081qyk.10 for ; Thu, 14 Oct 2010 10:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=DOQFCisFdfGa2q00u00LNhlj/wwaZmOrfb345hXhtc8=; b=kJlbGkSIpfiSm8ePiHLbJj2gIa+7FX66F9a5K1jK7gX3VccQS71acBPJ+li7xeePsq L5O1Io2Nes8uYCm61oo4OnuP/KwKcBFa4pXHV/OrDZlgpu0CdTpRsK0IueplfYfvRE2r YG11fpqBG78x91l5n4KW1X8ehVA7o0v8KjMsw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=M3TsMDdOGMZsQgd6UamCATRDgqIPDgowlfK1amqjZsUI0t1PVPh6r5l2qnu0VQPpzD k8pgQCHZissCGzV68CdquyU0lr/KvVGr3B1hD23qtwzFEIYjD0qhaBLnt6068QfdwZ06 sF0ylJvN/jGa9BVJnIcRCcfQifr/Nr19DpwBo= MIME-Version: 1.0 Received: by 10.224.130.143 with SMTP id t15mr7935875qas.213.1287075966591; Thu, 14 Oct 2010 10:06:06 -0700 (PDT) Received: by 10.229.213.69 with HTTP; Thu, 14 Oct 2010 10:06:06 -0700 (PDT) Date: Thu, 14 Oct 2010 10:06:06 -0700 Message-ID: From: Ted Hardie To: Apps Discuss , Peter Saint-Andre , Kurt.Zeilenga@isode.com, iesg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] Apps Review Team review of draft-zeilenga-ldap-dontusecopy-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 17:04:50 -0000 I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-zeilenga-ldap-dontusecopy-08 Title: The LDAP Don't Use Copy Control Reviewer: Ted Hardie Review Date: October 14, 2010 Summary: This document is basically ready for publication on the standards track, with one clarification needed and some editorial issues. Major Issues: In section 3, the document currently says: If original (master) information for the target or base object of the operation is not available (either locally or through chaining), the server MUST either return a referral directing the client to a server believed to be better able to service the request or return an appropriate result code (e.g., unwillingToPerform). The LDAP referral syntax permits the use of URIs other than LDAP, provided they are believed capable of performing the operations (see RFC 2251 section 4.1.11). But it is not clear how a referral using a different URI scheme would handle a request for authoritative data only. I believe the author should consider whether restricting referrals to LDAP URIs would be useful in this case or whether real-world deployments make non-LDAP URIs sufficiently rare to make this superfluous. Text describing the case would be useful for either approach. Since the control is based on an X.511/DAP control, it is possible to get this same functionality there, but the IANA does not appear to list any URI scheme for this, making its use in a referral also apparently unlikely. Minor Issues: None seen. Nits: The background section has a number of cases where multiple parenthetical expressions are used. Some re-writing to remove them may increase the readability. For example: If the server has access to the original (master) information (directly or through chaining), it performs the operation against the original (master) information and return compareTrue or compareFalse (or an error). If the server has access to the original (master) information directly or through chaining, it performs the operation against the original (master) information and returns compareTrue, compareFalse, or an error. These can be resolved in cooperation with the RFC Editor's application of the style guide. From lee@cnnic.cn Fri Oct 15 01:34:15 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2B0F3A6C5D for ; Fri, 15 Oct 2010 01:34:15 -0700 (PDT) X-Quarantine-ID: <7vyZVooj2n4U> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vyZVooj2n4U for ; Fri, 15 Oct 2010 01:34:15 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id BD83B3A6877 for ; Fri, 15 Oct 2010 01:34:14 -0700 (PDT) Received: (eyou send program); Fri, 15 Oct 2010 16:35:31 +0800 Message-ID: <487131731.15611@cnnic.cn> X-EYOUMAIL-SMTPAUTH: lee@cnnic.cn Received: from unknown (HELO [172.16.1.57]) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 15 Oct 2010 16:35:31 +0800 Message-ID: <4CB81249.7030407@cnnic.cn> Date: Fri, 15 Oct 2010 16:35:21 +0800 From: Xiaodong Lee Organization: CNNIC User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: apps-discuss@ietf.org, dave.cridland@isode.com, Alexey Melnikov , Peter Saint-Andre , apps-review@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 15 Oct 2010 08:56:47 -0700 Subject: [apps-discuss] [APPS-REVIEW]apps-team review of , draft-cridland-acap-vendor-registry-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lee@cnnic.cn List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 08:34:15 -0000 I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-cridland-acap-vendor-registry-01 Title: The Internet Assigned Number Authority (IANA) Application Configurations Access Protocol (ACAP) Vendor Subtrees Registry Reviewer: Xiaodong Lee Review Date: Oct.15 2010 Review Summary: This draft is ready for publication as an Proposed Standard and should be revised before publication. Major Issues: This document extend the character set from ASCII to UNICODE for internationalization, it only defines the valid character scope of vendor-name, no string-prep procedures are defined, for example, to deal with the full-width and half-width problem, which may cause problems to registry. Minor Issues: section 3.2 "iana-vendor-tag = 1*(ALPHA / DIGIT / SP / "-")". 4 types of characters are chosen. Need explanation why these 4 types? For example, why not "&" (ampersand)? which is also often appears in vendor-name. Nits: title: "... Application Configurations ..." should be "Configuration", according to RFC2244. From barryleiba@gmail.com Sat Oct 16 06:08:02 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC4F73A6AA7 for ; Sat, 16 Oct 2010 06:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.368 X-Spam-Level: X-Spam-Status: No, score=-102.368 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reRS8V-KxeUY for ; Sat, 16 Oct 2010 06:08:01 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id A26763A69F2 for ; Sat, 16 Oct 2010 06:08:01 -0700 (PDT) Received: by iwn10 with SMTP id 10so2347904iwn.31 for ; Sat, 16 Oct 2010 06:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=K2lSAhWdOR40xc1uNjEoq32v/a1LcVsRxciDkyFAAcY=; b=Y/bhHM6tlFHrbDGpGchVa0KKP6J7EYE4k4VSG3MUsrfQDE1fEvj+2LHTjsgvg0P3x2 zeaOfV9xIzRiTySHbJlqn7k0AzmqWmSN1l7IYTnl1ESagEjjv+/I3L0O45suRjrryWrG nY/1Pe12BzeLKVc2DovJvYJwfvLKlQO+gtP/M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; b=XlIVECaSDqgCOC+cd5T7iAyZbpHwqEM5VsCCyN2fZyndUPAwnUm9v7eBLYnq0EHaJZ /0tmf0pUTaoPZD+bz49cZQAQU1nk9jsG9w/BIHrGglEI9BTuR62T2v5EwmA1XI87qH37 SlU0e76HKE5pTJHHNr4bYE/i0hlWXvZ2wk6r0= MIME-Version: 1.0 Received: by 10.42.164.5 with SMTP id e5mr1238898icy.84.1287234564294; Sat, 16 Oct 2010 06:09:24 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.231.30.76 with HTTP; Sat, 16 Oct 2010 06:09:24 -0700 (PDT) Date: Sat, 16 Oct 2010 09:09:24 -0400 X-Google-Sender-Auth: wZPTx44BUPl9FjnPt6TIGajjDek Message-ID: From: Barry Leiba To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-csi-hash-threat.all@tools.ietf.org Subject: [apps-discuss] apps-review team review of draft-ietf-csi-hash-threat-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 13:08:03 -0000 I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-csi-hash-threat-10 Title: SEND Hash Threat Analysis Reviewer: Barry Leiba Review Date: 15 Oct 2010 Summary: This draft is ready for publication as an Informational RFC Major Issues: none Minor Issues: In section 3.3, you say "Since the structure of the Neighbor Discovery messages is well defined, it is not possible to use this vulnerability in real world attacks." That's a strong statement, and it might be *possible* to find a usable hash collision, however unlikely that may be. I'd say "not practical", instead. But this is such a small point that it hardly matters. Nits: There are a few punctuation errors and the like, but the RFC editor will take care of them. Barry -- Barry Leiba=A0 (barryleiba@computer.org) http://internetmessagingtechnology.org/ From alexey.melnikov@isode.com Sat Oct 16 20:52:27 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97F393A6A12; Sat, 16 Oct 2010 20:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.08 X-Spam-Level: X-Spam-Status: No, score=-101.08 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTkVAbmnYSMm; Sat, 16 Oct 2010 20:52:26 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 830083A686B; Sat, 16 Oct 2010 20:52:26 -0700 (PDT) Received: from [192.168.25.41] ((unknown) [203.118.14.76]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 17 Oct 2010 04:52:19 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4CB80E52.1000508@isode.com> Date: Fri, 15 Oct 2010 09:18:26 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Ted Hardie References: <4CA22665.1090008@stpeter.im> <003b01cb5fac$85b2eae0$4001a8c0@gateway.2wire.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, iesg Subject: Re: [apps-discuss] WG Review: Applications Area Working Group (APPSAWG) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Oct 2010 03:52:27 -0000 Ted Hardie wrote: >On Wed, Sep 29, 2010 at 1:01 AM, t.petch wrote: > > >>I think that the order of the list of considerations is unfortunate, as it might >>be read as implying precedence. I think that >>(5) There is no existing related Working Group that is willing to >> >> >>>recharter to take on this work, and the document doesn't justify the >>>formation of a new working group. >>> >>> >>should come top of the list. >> >>And the reference to URI I find unclear - I see that activity best performed on >> uri@w3.org >> >> > >Hi Tom, > >I think you're right that uri@w3.org would be the right place to >discuss something >about the evolution of URIs. The IRI working group is the right place >to discuss the >internationalization issues there, and uri-review@ietf.org the right >place to propose >a new scheme. But when I saw "URIs and XML", I assumed that this working >group would cover questions of how to apply them in a specific >context, rather than taking on work to change them. If it did run across something that >needed a major change, it would likely be moved off into a different (or new) group. > >Does that match others' expectations? > > Yes, that was the intent. From alexey.melnikov@isode.com Sat Oct 16 20:52:27 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDEA63A6A12 for ; Sat, 16 Oct 2010 20:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.32 X-Spam-Level: X-Spam-Status: No, score=-101.32 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCvLAxZDX4a2 for ; Sat, 16 Oct 2010 20:52:27 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id DFC5F3A6984 for ; Sat, 16 Oct 2010 20:52:26 -0700 (PDT) Received: from [192.168.25.41] ((unknown) [203.118.14.76]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 17 Oct 2010 04:53:06 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4CB81371.5040706@isode.com> Date: Fri, 15 Oct 2010 09:40:17 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Barry Leiba References: <201009291949.VAA12840@TR-Sys.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable Cc: iesg@ietf.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] WG Review: Applications Area Working Group (APPSAWG) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Oct 2010 03:52:27 -0000 Barry Leiba wrote: >On Wed, Sep 29, 2010 at 3:49 PM, Alfred H=CEnes wrote: > =20 > >>At Wed, 29 Sep 2010 10:01:24 +0200, Tom Petch wrote: >> =20 >> >>>I think that the order of the list of considerations is >>>unfortunate, as it might be read as implying precedence. >>> =20 >>> >... > =20 > >>This clearly means the list presents a conjunction (all conditions >>must be met), and it it non-exhaustive. >>"AND" is commutative and associative. So the order doesn't matter. >>Thus, the APPSAWG chairs and the APP ADs have to consider all items. >> =20 >> > >Still, it makes sense to put the primary concerns at the top. It >might also make sense to use an unordered list (with "*") instead of >an ordered one (with numbers), just to be clear that it's neither >explicitly ordered nor exhaustive. > Ok, I've changed the list to be unordered. From alexey.melnikov@isode.com Sun Oct 17 23:51:51 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFA6D3A6CB7; Sun, 17 Oct 2010 23:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=-1.154, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTRsqXWtCqNF; Sun, 17 Oct 2010 23:51:51 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id AF3EC3A6CA9; Sun, 17 Oct 2010 23:51:50 -0700 (PDT) Received: from [192.168.20.2] ((unknown) [212.183.140.33]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 18 Oct 2010 07:53:17 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4CBA9722.2050107@isode.com> Date: Sun, 17 Oct 2010 07:26:42 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: lee@cnnic.cn References: <487131731.15611@cnnic.cn> In-Reply-To: <487131731.15611@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-review@ietf.org, apps-discuss@ietf.org, dave.cridland@isode.com Subject: Re: [apps-discuss] [APPS-REVIEW]apps-team review of , draft-cridland-acap-vendor-registry-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 06:51:51 -0000 Hi Xiaodong, Thank you for your review. Xiaodong Lee wrote: > I have been selected as the Applications Area Review Team reviewer > for this draft (for background on apps-review, please see > http://www.apps.ietf.org/content/applications-area-review-team). > > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-cridland-acap-vendor-registry-01 > > Title: The Internet Assigned Number Authority (IANA) Application > Configurations Access Protocol (ACAP) Vendor Subtrees Registry > > Reviewer: Xiaodong Lee > > Review Date: Oct.15 2010 > > Review Summary: This draft is ready for publication as an Proposed > Standard and should be revised before publication. > > Major Issues: > This document extend the character set from ASCII to UNICODE for > internationalization, it only defines the valid character scope of > vendor-name, no string-prep procedures are defined, for example, to > deal with the full-width and half-width problem, which may cause > problems to registry. I think you've misunderstood. RFC 2244 allowed for Unicode here already, but it never specified any Unicode normalization rules. This document actually restricts the allowed characters to a subset of ASCII, because of existing uses in various IMAP (and Sieve) extensions. So no Unicode normalization would be needed. Having said that, the document might not be very clear on this. > Minor Issues: > section 3.2 "iana-vendor-tag = 1*(ALPHA / DIGIT / SP / "-")". > 4 types of characters are chosen. Need explanation why these 4 types? > For example, why not "&" (ampersand)? which is also often appears in > vendor-name. I will let the author comment on this. > Nits: > title: "... Application Configurations ..." should be "Configuration", > according to RFC2244. Good catch. From suresh.krishnan@ericsson.com Mon Oct 18 07:20:19 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20FFF3A6AF1 for ; Mon, 18 Oct 2010 07:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tedrxRov21Tc for ; Mon, 18 Oct 2010 07:20:18 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id E82443A6874 for ; Mon, 18 Oct 2010 07:20:17 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id o9IEdoHZ031734; Mon, 18 Oct 2010 09:39:52 -0500 Received: from [142.133.10.113] (147.117.20.213) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.2.234.1; Mon, 18 Oct 2010 10:21:35 -0400 Message-ID: <4CBC5784.8020500@ericsson.com> Date: Mon, 18 Oct 2010 10:19:48 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 18 Oct 2010 08:39:03 -0700 Cc: "draft-ietf-csi-hash-threat.all@tools.ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] apps-review team review of draft-ietf-csi-hash-threat-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 14:20:19 -0000 Hi Barry, Thanks for the review. On 10-10-16 09:09 AM, Barry Leiba wrote: > Minor Issues: > In section 3.3, you say "Since the structure of the Neighbor Discovery > messages is well defined, it is not possible to use this vulnerability > in real world attacks." That's a strong statement, and it might be > *possible* to find a usable hash collision, however unlikely that may > be. I'd say "not practical", instead. But this is such a small point > that it hardly matters. Good catch. We will make this change. Thanks Suresh From stpeter@stpeter.im Tue Oct 19 11:22:28 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C760E3A690C for ; Tue, 19 Oct 2010 11:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R27sHXdjM7n8 for ; Tue, 19 Oct 2010 11:22:27 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C2A3B3A6902 for ; Tue, 19 Oct 2010 11:22:27 -0700 (PDT) Received: from dhcp-64-101-72-188.cisco.com (dhcp-64-101-72-188.cisco.com [64.101.72.188]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 906A540074 for ; Tue, 19 Oct 2010 12:31:19 -0600 (MDT) Message-ID: <4CBDE23C.7050904@stpeter.im> Date: Tue, 19 Oct 2010 12:23:56 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080101030608010802070903" Subject: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 18:22:28 -0000 This is a cryptographically signed message in MIME format. --------------ms080101030608010802070903 Content-Type: multipart/mixed; boundary="------------020502030300070205090004" This is a multi-part message in MIME format. --------------020502030300070205090004 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I finally got around to updating this one. It's still incomplete, in the sense that it doesn't discuss recommendations or desired changes to behavior. However, I figured a revised I-D was in order because the issue came up recently on the HTTPBIS list -- see thread starting here: http://lists.w3.org/Archives/Public/ietf-http-wg/2010OctDec/0105.html -------- Original Message -------- Subject: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt Date: Tue, 19 Oct 2010 11:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : "X-" Considered Harmful Author(s) : P. Saint-Andre Filename : draft-saintandre-xdash-considered-harmful-01.txt Pages : 6 Date : 2010-10-19 Many application protocols use named parameters to represent data (for example, header fields in Internet mail messages and HTTP requests). Historically, protocol designers and implementers have often differentiated between "standard" and "experimental" parameters by prefixing experimental parameters with the string "X-". This document argues that, on balance, the "X-" convention has more costs than benefits. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-saintandre-xdash-considered-har= mful-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------020502030300070205090004 Content-Type: Message/External-body; name="draft-saintandre-xdash-considered-harmful-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-saintandre-xdash-considered-harmful-01.txt" Content-Type: text/plain Content-ID: <2010-10-19111318.I-D@ietf.org> --------------020502030300070205090004 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSS1ELUFu bm91bmNlIG1haWxpbmcgbGlzdApJLUQtQW5ub3VuY2VAaWV0Zi5vcmcKaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UKSW50ZXJuZXQtRHJhZnQg ZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwKb3IgZnRwOi8v ZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQKCg== --------------020502030300070205090004-- --------------ms080101030608010802070903 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAx OTE4MjM1NlowIwYJKoZIhvcNAQkEMRYEFKm/sbbWFf4aGNRt5uPIqcRJa+t6MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBcXFwADKpuq6ecVIqDkP85daEGScUNS+NCFvNtkDiWhjxTfD38RCdLHEQ+ 7jMl+l6w4gCgiB/yQgO74CvHuAs9Vnl2FYSYJ60U5iwXbdFCbIrL151InxZQXSFnGm7qXcE/ ekuCWDZTKgSnWJWgEEMKLOd2+oaIZGqlMG5Z8UW6e6F/jkjDXi9yQcAL6bKUeb9lprwhQyB2 5GVf9lOyqFSW0/sjmPGyMQmZABDjrQIrehDv6ETzOibzFd+dh+ysroFyPqEL+Zzn2PYir15I /FCOte3UIzDXRiDobnfnybJtmXeoMNrAVmwe0gbFOLuP7Awob77DTdHV0ouWT4/GQu2FAAAA AAAA --------------ms080101030608010802070903-- From xmlscott@gmail.com Tue Oct 19 20:25:06 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E4B43A69A2; Tue, 19 Oct 2010 20:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.609 X-Spam-Level: X-Spam-Status: No, score=-100.609 tagged_above=-999 required=5 tests=[AWL=1.990, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b16ei3-zSQpG; Tue, 19 Oct 2010 20:25:03 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 1A91D3A6997; Tue, 19 Oct 2010 20:25:03 -0700 (PDT) Received: by qwc9 with SMTP id 9so2017244qwc.31 for ; Tue, 19 Oct 2010 20:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=h3o6XG6d+sMzQQHEfhkPYrZ8S6UJj+7fGkim5rEJTBU=; b=pLrgDPErjCaap9G4yQNS41zmtQ8gzoViDlhBVoW9B7eb2eXCBi86tLm0wdQh0KM3wa BFue9e/VmE+v5uSzC9FyFHhBT+RjA0Xp9mbFKGml0GGeG/4rX4ZJ99rLnNOoGYLWKCtH BQ7onzhAcOpD3/uM2OVWPL6jXIozFY4IG5rzA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=u1SYtNjRLh7EOA+UDYfwzPL6Czn816uBj7rS1kOPvm+pNnXrGpD+sVvFyezmRFOgyv oXCT+3t+BTVCYvyYkpAjBs7c43LLqcoO426uH3SsJ9BXBbNEHY8MgMj/g3suVYMS7qLj pEXTFX5f9Zm2fByDHX0zE6bWekMwbxPw/2AUk= Received: by 10.224.209.197 with SMTP id gh5mr5593681qab.135.1287545195040; Tue, 19 Oct 2010 20:26:35 -0700 (PDT) Received: from ybr.home.skrb.org (c-98-229-134-198.hsd1.ma.comcast.net [98.229.134.198]) by mx.google.com with ESMTPS id u2sm4798155qcq.19.2010.10.19.20.26.33 (version=SSLv3 cipher=RC4-MD5); Tue, 19 Oct 2010 20:26:34 -0700 (PDT) Message-ID: <4CBE6167.9050406@gmail.com> Date: Tue, 19 Oct 2010 23:26:31 -0400 From: Scott Lawrence User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: apps-discuss@ietf.org, "iesg@ietf.org" , draft-ietf-geopriv-held-identity-extensions@tools.ietf.org, rbarnes@bbn.com, acooper@cdt.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 19 Oct 2010 20:34:40 -0700 Subject: [apps-discuss] apps-team review of draft-ietf-geopriv-held-identity-extensions-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 03:25:06 -0000 I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-geopriv-held-identity-extensions-04 Title: Use of Device Identity in HTTP-Enabled Location Delivery (HELD) Reviewer: Scott Lawrence Review Date: 2010-10-19 Summary: This draft is almost ready for publication as a Proposed Standard RFC but has a few issues that should be fixed before publication. Major Issues: - Section 6: the included schema does not validate, as it does not define the base type 'digits'. Tested using http://www.w3.org/2001/03/webdata/xsv - (several places) The term "Rule Maker" is used but is never defined. I assume that this is used as defined (however loosely) in RFC 3693; if so, a reference is needed. Minor Issues: - In the Abstract, the phrase "a pointer to the location determination process" is awkward and possibly misleading. The draft says: When a Location Information Server receives a request for location information (using the locationRequest message), described in the base HTTP Enabled Location Delivery (HELD) specification, it uses the source IP address of the arriving message as a pointer to the location determination process. The HELD specification that this draft extends describes the use of the IP address as an identifier: In this document, the IP address of the Device, as reflected by the source IP address in the location request message, is used as the identifier. replacing the awkward phrase quoted above with a use of the same terminology used in the HELD specification ("the identifier of the device whose location is to be determined"). - Section 1, paragraph 6: remove "obviously" from the first sentence. (if it was obvious to the reader, then it's redundant; if it was not, then it's insulting: either way it adds nothing useful) - Section 1.1, final paragraph: Automated mechanisms to ensure privacy constraints are respected are possible. An example would provide useful context for this statement. - Section 4.2, first sentence: The LCP policy does not allow requests made by third parties. I assume that this refers to the "LCP Policy" as described in the preceding sections - this would be clearer if it were quoted as it was in those sections and elsewhere in the document. Nits: - Section 1: When first used, it would be helpful to capitalize the phrases "Location Configuration Protocol", "Location Information Server", and "Location Recipients" so that the reader gets the hint that the subsequent abbreviations ("LCP", "LIS", and "LR") are bound to them. - Figure 2: It would be more clear to use more than one value in the requiredIdentifiers content (since it is a list). - (throughout) I found the hyphenation of 'third-party' to be frequently distracting, and suspect that several such should not have been hyphenated, as in "If an unauthorized third-party falsifies addressing..." in section 1.1. I suggest consulting the RFC Editor for guidelines, but suspect that hyphenation should at most be used when the term in modifying a verb rather than acting as a noun, and it may be clearer to just never use hyphenation. From McQuilWP@pobox.com Wed Oct 20 00:50:42 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CEFD3A69DB for ; Wed, 20 Oct 2010 00:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUTod5bRbaEY for ; Wed, 20 Oct 2010 00:50:36 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id B85333A690E for ; Wed, 20 Oct 2010 00:50:00 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 4128CE05B2; Wed, 20 Oct 2010 03:51:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :message-id:to:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=sasl; bh=DRGrixiTxQqG u0H/uQH4FQY4fgo=; b=aSMYQm+TBdI7IKSGWBhhm/Ivwvpkcow6HcS5K1Ik/UZH PTPQDlq6bYQSJNxPAGsHPlRPnTn9XjRh58RGw9mkfAEtnwNbMAT8hpA9FPiEzOEJ nfd9U74M9LwZCMgT1Dkb9B/8kP3fT6RaSkUDwxkLQal+bvy/S6AT8/JTiT66Z4k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :message-id:to:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=ugCdk/ K0GOJERAGb2bs/S69qZdPcaCp6+TfW3eH1vJwArDF9yQZvvm+l1aMP+x8vVZzvTZ ble8IcpPOBFKFCoNzrs8638GbvqooZ3CkZRVy/q0OICHEaH/LYWHTQyS2ocZq826 jkasL0DcjLKaubgQPDM42/X32A+ZHaZHA0IdE= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 28605E05B1; Wed, 20 Oct 2010 03:51:31 -0400 (EDT) Received: from [192.168.0.2] (unknown [68.107.61.33]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPA id A8D33E05B0; Wed, 20 Oct 2010 03:51:29 -0400 (EDT) Date: Wed, 20 Oct 2010 00:51:27 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <98229955.20101020005127@pobox.com> To: Apps-Discusssion In-Reply-To: <4CBDE23C.7050904@stpeter.im> References: <4CBDE23C.7050904@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: DA24BFCE-DC1E-11DF-8780-030CEE7EF46B-02871704!a-pb-sasl-quonix.pobox.com Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 07:50:42 -0000 I have a concern with the blanket deprecation of the X- convention. The ID presumes that the only use of X- values is for experimentation and rightly point out the problem of eventually trying to transition to a non X- value when the experiment has succeeded. However, in at least the case of Email header fields, there is another reason for X- names: Private Use. Note that neither of the rules quoted in RFC822 and RFC1154 mentions the word "experimental". In the message I'm replying to that Peter Saint-Andre sent to this list contains 16 X- header fields in my local store. Many of these are not intended to be interpreted by the mail system, but by humans for diagnostic purposes or possibly by a SIEVE script. This seems to be an indication that many implementers are not seeing a problem with them. I am especially fond of a header field I saw years ago, "X-NSA-Bait:" which was followed by a bunch of words intended to waste some eavesdropper's time. Thus, I would modify the recommendation of the ID to specify that X- names should not be used for global interoperability experimentation, but that local private use is less of a problem. As a point of reference, the following is a list of the X- header field names in the previous message as I received it: X-VR-Score: X-Authority-Analysis: X-CM-Score: X-Pobox-Orig-Sender: X-Pobox-Delivery-ID: X-Original-To: x-pobox-client-address: x-pobox-client-name: X-Virus-Scanned: X-Spam-Flag: X-Spam-Score: X-Spam-Level: X-Spam-Status: X-Enigmail-Version: X-BeenThere: X-Mailman-Version: -- Bill McQuillan From sm@resistor.net Wed Oct 20 02:43:41 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF3323A63D3 for ; Wed, 20 Oct 2010 02:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.13 X-Spam-Level: X-Spam-Status: No, score=-103.13 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2t6I9KC79-3 for ; Wed, 20 Oct 2010 02:43:40 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 1744D3A6359 for ; Wed, 20 Oct 2010 02:43:39 -0700 (PDT) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o9K9ixXh022257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Oct 2010 02:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1287567910; x=1287654310; bh=05umPuX4nra6WBM3L+7w2ODGIEPhO60h4AmCM3c2Xl4=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=UsSJMTIyxf7s0zLeG4u2HcPtEOLyHpUnjELE2ytSXNRwDnYs7clSh8FUj7juYiZkP yLDOrw/sC5lzBxegDChxZqefwJuRwYXbJUv98IWfjXM1hdwQQNUwfy+grUCrrdvbR0 qtFqTx6gat46IRzYWxVz+TwVR1yuEhK1/R3vgfP0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1287567910; x=1287654310; bh=05umPuX4nra6WBM3L+7w2ODGIEPhO60h4AmCM3c2Xl4=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=fQy5uMKNLLlf0awPYJMos4xOBjW/DXVOguIg4gyLU0g0ekSEq3NNylfTSsOu6hxz+ WeEhjZ8QezCK3PcHqWqv+7/JzlP5cNHvZ59457Gpaw23lTcqt6LYHW56T9yyGREqFR emZqH9xvgi8UADZNjbAp426UTIBPK8QVewbuSoEU= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=irCpcRI5MSSeCQBgdlF/NCa45teTy+d5tyANgmt9sa2S7991o5SZzs3JaKHNesDiR umVajMPJ//z1OL3tSFieGnb7cGNhaunzf7A+mkZZU1/BSAuw1+htApbBZgTJ4cUk2pw locHchtyLnE25evBznD3AfjErIY9sdWm36N5w4w= Message-Id: <6.2.5.6.2.20101019205927.0ae108b8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 20 Oct 2010 02:44:35 -0700 To: Peter Saint-Andre From: SM In-Reply-To: <4CBDE23C.7050904@stpeter.im> References: <4CBDE23C.7050904@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 09:43:41 -0000 Hi Peter, At 11:23 19-10-10, Peter Saint-Andre wrote: >I finally got around to updating this one. It's still incomplete, in the >sense that it doesn't discuss recommendations or desired changes to >behavior. However, I figured a revised I-D was in order because the I read draft-saintandre-considered-harmful. Quoting Section 3.8.1 of RFC 2821 (3.7.1 in RFC 5321): "Other mail systems gatewayed to the Internet often use a subset of the RFC 822 header section or provide similar functionality with a different syntax, but some of these mail systems do not have an equivalent to the SMTP envelope. Therefore, when a message leaves the Internet environment, it may be necessary to fold the SMTP envelope information into the message header section. A possible solution would be to create new header fields to carry the envelope information (e.g., "X-SMTP-MAIL:" and "X-SMTP-RCPT:");" That's not an issue as the Xdash is for private use. The Xdash may be a problem when used over the Internet. I suggest that the draft discusses that angle. The draft mentions a rule in RFC 1154: "Keywords beginning with "X-" are permanently reserved to implementation-specific use. No standard registered encoding keyword will ever begin with "X-". The fact that no standard registration is required and because "everybody does so" might provide an explanation as to why Xdash is in common use. Now, does Xdash stand for Experimental or Extension? It doesn't really matter as there are provisional registries to cater for such usage. Maybe the problem is: (i) people do not know about the registration procedures; or (ii) the registration procedures are too tedious; or (iii) Think local, act global. Section 2.5 of RFC 5064 recommends that: "For backwards compatibility, this document also describes the X-Archived-At header field, a precursor of the Archived-At header field. The X-Archived-At header field MAY also be parsed, but SHOULD not be generated." That's one way to deal with the Xdash issue. One of the arguments for the registration of Xdash is that the implementations have already been deployed and it is too costly to fix. In Section 3, there is a typo for "parameters". I support the recommendation against the creation of new names with the special "X" prefix in IETF protocols. Regards, -sm From paul.hoffman@vpnc.org Wed Oct 20 07:23:03 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD6433A683E for ; Wed, 20 Oct 2010 07:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.2 X-Spam-Level: X-Spam-Status: No, score=-100.2 tagged_above=-999 required=5 tests=[AWL=-0.568, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYoX47NWxYaj for ; Wed, 20 Oct 2010 07:23:03 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id BDA953A6830 for ; Wed, 20 Oct 2010 07:23:02 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o9KEOYBO065868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Oct 2010 07:24:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <98229955.20101020005127@pobox.com> References: <4CBDE23C.7050904@stpeter.im> <98229955.20101020005127@pobox.com> Date: Wed, 20 Oct 2010 07:24:32 -0700 To: Bill McQuillan , Apps-Discusssion From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 14:23:03 -0000 At 12:51 AM -0700 10/20/10, Bill McQuillan wrote: >I have a concern with the blanket deprecation of the X- convention. > >The ID presumes that the only use of X- values is for experimentation and >rightly point out the problem of eventually trying to transition to a non >X- value when the experiment has succeeded. However, in at least the case >of Email header fields, there is another reason for X- names: Private Use. In other WGs, we have had problems with the term "private use" and "vendor specific" and so on. A more descriptive term is "never intended for interoperable use". It's not as easy to say, but it is much more precise for what we want. --Paul Hoffman, Director --VPN Consortium From dave@cridland.net Wed Oct 20 07:28:12 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0FB03A69D9 for ; Wed, 20 Oct 2010 07:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AdNrFR1kni0 for ; Wed, 20 Oct 2010 07:28:11 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id 53FEA3A6830 for ; Wed, 20 Oct 2010 07:28:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 616EE11680E6; Wed, 20 Oct 2010 15:29:43 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2DVevuK1xPE; Wed, 20 Oct 2010 15:29:38 +0100 (BST) Received: from puncture (unknown [217.155.137.60]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 43D4911680CA; Wed, 20 Oct 2010 15:29:38 +0100 (BST) References: <4CBDE23C.7050904@stpeter.im> <98229955.20101020005127@pobox.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <779.1287584978.272414@puncture> Date: Wed, 20 Oct 2010 15:29:38 +0100 From: Dave Cridland To: Paul Hoffman , Bill McQuillan , general discussion of application-layer protocols Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 14:28:13 -0000 On Wed Oct 20 15:24:32 2010, Paul Hoffman wrote: > At 12:51 AM -0700 10/20/10, Bill McQuillan wrote: > >I have a concern with the blanket deprecation of the X- convention. > > > >The ID presumes that the only use of X- values is for > experimentation and > >rightly point out the problem of eventually trying to transition > to a non > >X- value when the experiment has succeeded. However, in at least > the case > >of Email header fields, there is another reason for X- names: > Private Use. > > In other WGs, we have had problems with the term "private use" and > "vendor specific" and so on. A more descriptive term is "never > intended for interoperable use". It's not as easy to say, but it is > much more precise for what we want. Vendor tokens work much better for this kind of thing. ACAP had them, but enterprise OID arcs are an earlier example, too, and very successful in SNMP. (ACAP's are getting - painfully - extracted from RFC 2244 currently, since they're used by IMAP ANNOTATE/ANNOTATEMORE). The problem with X- is that they leak beyond their scope without indication of what their scope might be. FWIW, ACAP had per-user tokens, too. I never found a use for them, but I imagine that if ACAP were more commonplace, it might have found some deployment for personal experiments. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From tony@att.com Wed Oct 20 07:35:02 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13ED83A69E1 for ; Wed, 20 Oct 2010 07:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.407 X-Spam-Level: X-Spam-Status: No, score=-106.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsGLRlwhdanW for ; Wed, 20 Oct 2010 07:33:38 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id E44733A6845 for ; Wed, 20 Oct 2010 07:33:36 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-13.tower-146.messagelabs.com!1287585301!16197441!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 11513 invoked from network); 20 Oct 2010 14:35:04 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-13.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Oct 2010 14:35:04 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o9KEYO65021051 for ; Wed, 20 Oct 2010 10:34:24 -0400 Received: from klpd017.kcdc.att.com (klpd017.kcdc.att.com [135.188.40.86]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o9KEYLGY021014 for ; Wed, 20 Oct 2010 10:34:21 -0400 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.4/8.14.4) with ESMTP id o9KEYvkg011267 for ; Wed, 20 Oct 2010 09:34:57 -0500 Received: from mailgw1.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.4/8.14.4) with ESMTP id o9KEYs4n011253 for ; Wed, 20 Oct 2010 09:34:55 -0500 Received: from [135.70.105.218] (vpn-135-70-105-218.vpn.swst.att.com[135.70.105.218]) by maillennium.att.com (mailgw1) with ESMTP id <20101020143454gw100ei1pte> (Authid: tony); Wed, 20 Oct 2010 14:34:54 +0000 X-Originating-IP: [135.70.105.218] Message-ID: <4CBEFE0D.2090504@att.com> Date: Wed, 20 Oct 2010 10:34:53 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Apps-Discusssion References: <4CBDE23C.7050904@stpeter.im> <98229955.20101020005127@pobox.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 14:35:51 -0000 On 10/20/2010 10:24 AM, Paul Hoffman wrote: > In other WGs, we have had problems with the term "private use" and > "vendor specific" and so on. A more descriptive term is "never > intended for interoperable use". It's not as easy to say, but it is > much more precise for what we want. I've long felt that a large number of header fields that seem to appear as X- should really be vendor specific. I started writing an I-D once defining and registering a "Vendor Specific" header field prefix ala the MIME media type vendor prefix. Is it time to resurrect that idea and actually finish writing the I-D? Tony From paul.hoffman@vpnc.org Wed Oct 20 07:53:33 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 633A73A67EF for ; Wed, 20 Oct 2010 07:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.404 X-Spam-Level: X-Spam-Status: No, score=-101.404 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFlwK4dWKZXp for ; Wed, 20 Oct 2010 07:53:32 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 9F3303A677C for ; Wed, 20 Oct 2010 07:53:32 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o9KEt3R9067842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Oct 2010 07:55:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <779.1287584978.272414@puncture> References: <4CBDE23C.7050904@stpeter.im> <98229955.20101020005127@pobox.com> <779.1287584978.272414@puncture> Date: Wed, 20 Oct 2010 07:55:02 -0700 To: Dave Cridland , Bill McQuillan , general discussion of application-layer protocols From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 14:53:33 -0000 At 3:29 PM +0100 10/20/10, Dave Cridland wrote: >On Wed Oct 20 15:24:32 2010, Paul Hoffman wrote: >>At 12:51 AM -0700 10/20/10, Bill McQuillan wrote: >>>I have a concern with the blanket deprecation of the X- convention. >>> >>>The ID presumes that the only use of X- values is for experimentation and >>>rightly point out the problem of eventually trying to transition to a non >>>X- value when the experiment has succeeded. However, in at least the case >>>of Email header fields, there is another reason for X- names: Private Use. >> >>In other WGs, we have had problems with the term "private use" and "vendor specific" and so on. A more descriptive term is "never intended for interoperable use". It's not as easy to say, but it is much more precise for what we want. > >Vendor tokens work much better for this kind of thing. That has *not* been our experience in the IPsec world. We have had repeated, serious problems with this in IKEv1. >ACAP had them, but enterprise OID arcs are an earlier example, too, and very successful in SNMP. There are many people in the ops world who would disagree with the latter part. Having to follow a dozen vendors OIDs for a feature that eventually becomes widespread is a nightmare. >The problem with X- is that they leak beyond their scope without indication of what their scope might be. Yes, definitely. But that doesn't mean that having a vendor namespace helps. --Paul Hoffman, Director --VPN Consortium From dave@cridland.net Wed Oct 20 08:13:32 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 015923A683E for ; Wed, 20 Oct 2010 08:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTZheX6uGWGQ for ; Wed, 20 Oct 2010 08:13:13 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id F41E73A680A for ; Wed, 20 Oct 2010 08:13:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id E481711680E9; Wed, 20 Oct 2010 16:14:41 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9DTOZY2ld+h; Wed, 20 Oct 2010 16:14:37 +0100 (BST) Received: from puncture (unknown [217.155.137.60]) by peirce.dave.cridland.net (Postfix) with ESMTPA id B3F3C11680E3; Wed, 20 Oct 2010 16:14:37 +0100 (BST) References: <4CBDE23C.7050904@stpeter.im> <98229955.20101020005127@pobox.com> <779.1287584978.272414@puncture> In-Reply-To: MIME-Version: 1.0 Message-Id: <779.1287587677.734633@puncture> Date: Wed, 20 Oct 2010 16:14:37 +0100 From: Dave Cridland To: Paul Hoffman , Bill McQuillan , general discussion of application-layer protocols Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 15:13:32 -0000 On Wed Oct 20 15:55:02 2010, Paul Hoffman wrote: > At 3:29 PM +0100 10/20/10, Dave Cridland wrote: > >On Wed Oct 20 15:24:32 2010, Paul Hoffman wrote: > >>At 12:51 AM -0700 10/20/10, Bill McQuillan wrote: > >>>I have a concern with the blanket deprecation of the X- > convention. > >>> > >>>The ID presumes that the only use of X- values is for > experimentation and > >>>rightly point out the problem of eventually trying to transition > to a non > >>>X- value when the experiment has succeeded. However, in at least > the case > >>>of Email header fields, there is another reason for X- names: > Private Use. > >> > >>In other WGs, we have had problems with the term "private use" > and "vendor specific" and so on. A more descriptive term is "never > intended for interoperable use". It's not as easy to say, but it is > much more precise for what we want. > > > >Vendor tokens work much better for this kind of thing. > > That has *not* been our experience in the IPsec world. We have had > repeated, serious problems with this in IKEv1. > > It'd be useful (to me, and I think the community) to know what those problems are. > >ACAP had them, but enterprise OID arcs are an earlier example, > too, and very successful in SNMP. > > There are many people in the ops world who would disagree with the > latter part. Having to follow a dozen vendors OIDs for a feature > that eventually becomes widespread is a nightmare. > > Yes, I can appreciate that. One always hopes that implementations migrate to the standards, but that's not always easy, and it certainly doesn't always happen. On the other hand, I suspect the alternative - an "X-" oid - would be significantly worse - that just makes my eyes water. > >The problem with X- is that they leak beyond their scope without > indication of what their scope might be. > > Yes, definitely. But that doesn't mean that having a vendor > namespace helps. They do allow for interoperability in spite of a lack of a common [~ly followed] standard, and prevent multiple overlapping uses of the same identifier. So I'd argue that they do help, although I'm willing to admit they don't solve the problems entirely. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From Nicolas.Williams@oracle.com Wed Oct 20 08:13:41 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7F1C3A67D3 for ; Wed, 20 Oct 2010 08:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.256 X-Spam-Level: X-Spam-Status: No, score=-6.256 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcbMKPlCjvSi for ; Wed, 20 Oct 2010 08:13:32 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id CE1583A6802 for ; Wed, 20 Oct 2010 08:13:24 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9KFEtXN020851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Oct 2010 15:14:57 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9KFEr3a023709; Wed, 20 Oct 2010 15:14:54 GMT Received: from abhmt006.oracle.com by acsmt354.oracle.com with ESMTP id 700838381287587631; Wed, 20 Oct 2010 08:13:51 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 20 Oct 2010 08:13:50 -0700 Date: Wed, 20 Oct 2010 10:13:44 -0500 From: Nicolas Williams To: Paul Hoffman Message-ID: <20101020151343.GS1635@oracle.com> References: <4CBDE23C.7050904@stpeter.im> <98229955.20101020005127@pobox.com> <779.1287584978.272414@puncture> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: general discussion of application-layer protocols , Bill McQuillan Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 15:13:41 -0000 On Wed, Oct 20, 2010 at 07:55:02AM -0700, Paul Hoffman wrote: > At 3:29 PM +0100 10/20/10, Dave Cridland wrote: > >On Wed Oct 20 15:24:32 2010, Paul Hoffman wrote: > >>In other WGs, we have had problems with the term "private use" and > >>"vendor specific" and so on. A more descriptive term is "never > >>intended for interoperable use". It's not as easy to say, but it is > >>much more precise for what we want. > > > >Vendor tokens work much better for this kind of thing. > > That has *not* been our experience in the IPsec world. We have had > repeated, serious problems with this in IKEv1. > > >ACAP had them, but enterprise OID arcs are an earlier example, too, > >and very successful in SNMP. > > There are many people in the ops world who would disagree with the > latter part. Having to follow a dozen vendors OIDs for a feature that > eventually becomes widespread is a nightmare. Depending on the protocol, vendor extensions might be unavoidable. Context is everything. For example, the NFSv4 WG maintains very tight control over the protocol, while SSHv2 allows for _some_ vendor extensions; Kerberos V5 has lots of typed holes, and KRB-WG does not maintain tight control over their use (there is a registrar, and it isn't the IANA, but it doesn't require protocol specifications for its assignments), ... For e-mail we can expect vendor extensions to RFC2822 headers for the simple reason that they abound today. Correct MTA implementations ought to filter out such extensions when e-mail crosses administrative domains or gateways that don't understand the forwarding node's vendor extensions. Vendor extensions in delivered e-mail seem OK to me because users can often interpret them in many cases without extra help. > >The problem with X- is that they leak beyond their scope without > >indication of what their scope might be. > > Yes, definitely. But that doesn't mean that having a vendor namespace > helps. Indeed. But maybe we should have a scope identifier. Something like: Z--[-]: ^^^^^^^^ (this is the scope) For example: Z-JoeSixPackSW-spamscore-foo.example: 37 which would be stripped from e-mail being forwarded to MTAs outside foo.example, while this: Z-JoeSixPackSW-spamscore: 51 wouldn't be (though since one administrative domain's MTAs' spam scoring of e-mail isn't likely to be useful to other domains, thus this particular sort of extension header should have a scope ID). Or maybe the scope ID should be more fine grained than just a domainname: Z---[-]: Here the scope would be something like: 'transient' (used only by MTAs, stripped on delivery or when crossing administrative domains) and 'persistent' (persisting all the way until and including delivery). We might also want references to vendor extension specs: Z---spec: Nico -- From stpeter@stpeter.im Wed Oct 20 09:45:06 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 395083A6984 for ; Wed, 20 Oct 2010 09:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZwug7bBEi13 for ; Wed, 20 Oct 2010 09:45:04 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 805663A69CC for ; Wed, 20 Oct 2010 09:44:26 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9DAA940074 for ; Wed, 20 Oct 2010 10:53:25 -0600 (MDT) Message-ID: <4CBF1CC6.7090408@stpeter.im> Date: Wed, 20 Oct 2010 10:45:58 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000400040100090604040604" Subject: [apps-discuss] call for APPSAREA topics at IETF 79 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 16:45:06 -0000 This is a cryptographically signed message in MIME format. --------------ms000400040100090604040604 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If you would like to make a presentation on any apps-related topic during the APPSAREA session at IETF 79, please contact me and Alexey, or just post to the apps-discuss list. Thanks! Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms000400040100090604040604 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAy MDE2NDU1OFowIwYJKoZIhvcNAQkEMRYEFAgnUOq2A5L9mSThPdU05Ku+BwdMMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCgwcrDAey4r1a/tqDMWQNBblvL7PHhRCbSezg1qR0/+KYPAlDOPWktuiBV apvHMkA6YTNS9JSqeMYGT6YWULq1VhKyPPiqNlXFZLIMkJ7kZhtgL02wzK5GPTrqDl/5cbDN 7lIWT/TGv+QC2U10tfvsxnL2A8okhDovDWeETHvWPpldRX7mHzjKV3Bzkg40rOrXGeWrjFkk zPa8fHSK6zEq4lD5OgnpC7nZJ06GGnlFe2LakBFsEh1YfwMP9LbM5C4lA2a5uXxrT/lqicQY rAvUxOgr6BOn2rLE/c2bTk7leRdqSMrkfuqGOAHQ0SO2sWH3GtM44ygMebm5TPYKF8tnAAAA AAAA --------------ms000400040100090604040604-- From Martin.Thomson@andrew.com Wed Oct 20 14:57:47 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 147CC3A6977; Wed, 20 Oct 2010 14:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.892 X-Spam-Level: X-Spam-Status: No, score=-2.892 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIKozLNQhQzc; Wed, 20 Oct 2010 14:57:46 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id E84EA3A65A5; Wed, 20 Oct 2010 14:57:45 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:15397 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S35975915Ab0JTV7T (ORCPT + 1 other); Wed, 20 Oct 2010 16:59:19 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Wed, 20 Oct 2010 16:59:18 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Thu, 21 Oct 2010 05:59:16 +0800 From: "Thomson, Martin" To: Scott Lawrence , "apps-discuss@ietf.org" , "iesg@ietf.org" , "draft-ietf-geopriv-held-identity-extensions@tools.ietf.org" , "rbarnes@bbn.com" , "acooper@cdt.org" Date: Thu, 21 Oct 2010 05:59:15 +0800 Thread-Topic: apps-team review of draft-ietf-geopriv-held-identity-extensions-04 Thread-Index: ActwBqFcIvcl5CHMT6+XKaptYQcMfAAAKSFA Message-ID: <8B0A9FCBB9832F43971E38010638454F03F31EAA35@SISPE7MB1.commscope.com> References: <4CBE6167.9050406@gmail.com> In-Reply-To: <4CBE6167.9050406@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [apps-discuss] apps-team review of draft-ietf-geopriv-held-identity-extensions-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 21:57:47 -0000 VGhhbmtzIGZvciB0aGUgcmV2aWV3IFNjb3R0LCBhbmQgZXNwZWNpYWxseSBmb3IgcGlja2luZyB1 cCB0aGUgc2NoZW1hIGVycm9yIQ0KDQpPbiAyMDEwLTEwLTIwIGF0IDE0OjI2OjMxLCBTY290dCBM YXdyZW5jZSB3cm90ZToNCj4gTWFqb3IgSXNzdWVzOg0KPiANCj4gLSBTZWN0aW9uIDY6IHRoZSBp bmNsdWRlZCBzY2hlbWEgZG9lcyBub3QgdmFsaWRhdGUsIGFzIGl0IGRvZXMgbm90DQo+ICAgIGRl ZmluZSB0aGUgYmFzZSB0eXBlICdkaWdpdHMnLiAgVGVzdGVkIHVzaW5nDQo+ICAgICAgICAgICAg IGh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDMvd2ViZGF0YS94c3YNCg0KT29wcy4gIFRoYXQncyBh biBlZGl0b3JpYWwgYnVnLiAgSXQgd2FzIGNvbGxhdGVyYWwgaW4gYSBjaGFuZ2UgdGhhdCB3YXMg bWFkZSBpbiByZXNwb25zZSB0byBhIHJlY2VudCByZXZpZXcuDQogDQo+IC0gKHNldmVyYWwgcGxh Y2VzKSBUaGUgdGVybSAiUnVsZSBNYWtlciIgaXMgdXNlZCBidXQgaXMgbmV2ZXINCj4gICAgZGVm aW5lZC4gIEkgYXNzdW1lIHRoYXQgdGhpcyBpcyB1c2VkIGFzIGRlZmluZWQgKGhvd2V2ZXIgbG9v c2VseSkgaW4NCj4gICAgUkZDIDM2OTM7IGlmIHNvLCBhIHJlZmVyZW5jZSBpcyBuZWVkZWQuDQoN CkFERDoNCiAgQSBSdWxlIE1ha2VyIGlzIHRoZSB0ZXJtIHVzZWQgZm9yIHRoZSByb2xlIHRoYXQg bWFrZXMgcG9saWN5IGRlY2lzaW9ucyBhYm91dCBhdXRob3JpemF0aW9uLCBkZXRlcm1pbmluZyB3 aGF0IGVudGl0aWVzIGFyZSBwZXJtaXR0ZWQgdG8gcmVjZWl2ZSBsb2NhdGlvbiBhbmQgaG93IHRo YXQgaW5mb3JtYXRpb24gaXMgcHJvdmlkZWQuDQoNCkknbGwgYWRkIHRoaXMgdG8gdGhlIHRlcm1p bm9sb2d5LiAgSSdsbCBhZGQgYSByZWZlcmVuY2UgdG8gdGhlIHVwZGF0ZWQgZ2VvcHJpdi1hcmNo IGRyYWZ0IGluc3RlYWQgZm9yIHRoaXMuDQoNCj4gTWlub3IgSXNzdWVzOg0KPiANCj4gLSBJbiB0 aGUgQWJzdHJhY3QsIHRoZSBwaHJhc2UgImEgcG9pbnRlciB0byB0aGUgbG9jYXRpb24gZGV0ZXJt aW5hdGlvbg0KPiAgICBwcm9jZXNzIiBpcyBhd2t3YXJkIGFuZCBwb3NzaWJseSBtaXNsZWFkaW5n LiAgVGhlIGRyYWZ0IHNheXM6DQouLi4NCj4gICAgcmVwbGFjaW5nIHRoZSBhd2t3YXJkIHBocmFz ZSBxdW90ZWQgYWJvdmUgd2l0aCBhIHVzZSBvZiB0aGUgc2FtZQ0KPiAgICB0ZXJtaW5vbG9neSB1 c2VkIGluIHRoZSBIRUxEIHNwZWNpZmljYXRpb24gKCJ0aGUgaWRlbnRpZmllciBvZiB0aGUNCj4g ICAgZGV2aWNlIHdob3NlIGxvY2F0aW9uIGlzIHRvIGJlIGRldGVybWluZWQiKS4NCg0KVGhhdCdz IGNsZWFyZXIuICBUaGFua3MuDQoNCj4gLSBTZWN0aW9uIDEsIHBhcmFncmFwaCA2OiByZW1vdmUg Im9idmlvdXNseSIgZnJvbSB0aGUgZmlyc3QNCj4gICAgc2VudGVuY2UuICAoaWYgaXQgd2FzIG9i dmlvdXMgdG8gdGhlIHJlYWRlciwgdGhlbiBpdCdzIHJlZHVuZGFudDsgaWYNCj4gICAgaXQgd2Fz IG5vdCwgdGhlbiBpdCdzIGluc3VsdGluZzogZWl0aGVyIHdheSBpdCBhZGRzIG5vdGhpbmcgdXNl ZnVsKQ0KPiANCj4gLSBTZWN0aW9uIDEuMSwgZmluYWwgcGFyYWdyYXBoOg0KPiANCj4gICAgICAg IEF1dG9tYXRlZCBtZWNoYW5pc21zIHRvIGVuc3VyZSBwcml2YWN5IGNvbnN0cmFpbnRzIGFyZSBy ZXNwZWN0ZWQNCj4gICAgICAgIGFyZSBwb3NzaWJsZS4NCj4gDQo+ICAgIEFuIGV4YW1wbGUgd291 bGQgcHJvdmlkZSB1c2VmdWwgY29udGV4dCBmb3IgdGhpcyBzdGF0ZW1lbnQuDQoNCllvdSBhcmVu J3QgdGhlIG9ubHkgb25lIHRvIHBvaW50IHRoaXMgb3V0LiAgSSBwcm9wb3NlZCB0byBhZGQgdGhl IGZvbGxvd2luZyBwcmV2aW91c2x5OyBpdCdzIGp1c3Qgbm90IGluIHRoZSBkcmFmdCB5ZXQuDQog IEZvciBpbnN0YW5jZSwgYSBwb2xpY3kgcnVsZXMgZG9jdW1lbnQgY291bGQgYmUgdXNlZCB0byBl eHByZXNzIHRoZSBhZ3JlZWQgcG9saWN5LiAgRm9ybWFsIHBvbGljeSBkb2N1bWVudHMsIHN1Y2gg YXMgW1JGQzQ3NDVdLCBjYW4gYmUgYXBwbGllZCBpbiBhbiBhdXRvbWF0ZWQgZmFzaGlvbiBieSBh IExJUy4NCg0KPiAtIFNlY3Rpb24gNC4yLCBmaXJzdCBzZW50ZW5jZToNCj4gDQo+ICAgICAgICBU aGUgTENQIHBvbGljeSBkb2VzIG5vdCBhbGxvdyByZXF1ZXN0cyBtYWRlIGJ5IHRoaXJkIHBhcnRp ZXMuDQo+IA0KPiAgICBJIGFzc3VtZSB0aGF0IHRoaXMgcmVmZXJzIHRvIHRoZSAiTENQIFBvbGlj eSIgYXMgZGVzY3JpYmVkIGluIHRoZQ0KPiAgICBwcmVjZWRpbmcgc2VjdGlvbnMgLSB0aGlzIHdv dWxkIGJlIGNsZWFyZXIgaWYgaXQgd2VyZSBxdW90ZWQgYXMgaXQNCj4gICAgd2FzIGluIHRob3Nl IHNlY3Rpb25zIGFuZCBlbHNld2hlcmUgaW4gdGhlIGRvY3VtZW50Lg0KDQpXaWxsIGRvLg0KIA0K PiBOaXRzOg0KDQpUaGFua3MsIGFsbCBmaXhlZC4gIFRoZSB0aGlyZC1wYXJ0eSB0aGluZyBoYXMg YnVnZ2VkIG1lIHRvby4NCg0KQ2hlZXJzLA0KTWFydGluDQo= From dhc@dcrocker.net Wed Oct 20 16:47:59 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDCE33A6904 for ; Wed, 20 Oct 2010 16:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0RnPBg-Iu-F for ; Wed, 20 Oct 2010 16:47:58 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id C28543A68F8 for ; Wed, 20 Oct 2010 16:47:58 -0700 (PDT) Received: from [192.168.1.5] (ppp-68-120-198-81.dsl.pltn13.pacbell.net [68.120.198.81]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o9KNnREJ001098 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 20 Oct 2010 16:49:32 -0700 Message-ID: <4CBF8007.5010609@dcrocker.net> Date: Wed, 20 Oct 2010 16:49:27 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <4CBDE23C.7050904@stpeter.im> <6.2.5.6.2.20101019205927.0ae108b8@resistor.net> In-Reply-To: <6.2.5.6.2.20101019205927.0ae108b8@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 20 Oct 2010 16:49:32 -0700 (PDT) Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 23:48:00 -0000 Disclaimer: I was editor for the document that introduced it, 28 years ago, but am pretty sure the idea came from a participant on the mailing list that was discussing RFC 822 development, rather than coming from my own brain. In any event, during the IETF DRUMS working group, which produced RFC2822, I lobbied for eliminating the construct. I think it was an excellent idea, but I think it's downside is far more significant than its upside. And indeed, the upside has largely been eliminated. /d On 10/20/2010 2:44 AM, SM wrote: > Quoting Section 3.8.1 of RFC 2821 (3.7.1 in RFC 5321): > > "Other mail systems gatewayed to the Internet often use a subset of > the RFC 822 header section ... A possible > solution would be to create new header fields to carry the envelope > information (e.g., "X-SMTP-MAIL:" and "X-SMTP-RCPT:");" > > That's not an issue as the Xdash is for private use. The Xdash may be a problem > when used over the Internet. I suggest that the draft discusses that angle. Hmmm. That's a creative and even thoughtful point, but I suspect it does not really affect much. Essentially, the need for some additonal header fields, for messages being gatewaying in from another system, is merely one more source of "private" content labeling. It does not really ahve any special characteristics. > The draft mentions a rule in RFC 1154: > > "Keywords beginning with "X-" are permanently reserved to > implementation-specific use. No standard registered encoding > keyword will ever begin with "X-". > > The fact that no standard registration is required and because "everybody does > so" might provide an explanation as to why Xdash is in common use. There are two different issues. One is that people like to invent header fields frequently and conveniently. I'd say that's a pretty safe assessment. The second is that they somehow "prefer" using X-, rather than inventing a name that does not use X-. My anecdotal sense of things is that they actually believe they are /required/ to use X-, for any non-standardized header field. Of course, this is not the rule, but they seem to think it is. > Now, does Xdash stand for Experimental or Extension? I don't remember that it had any specific meaning. On 10/20/2010 12:51 AM, Bill McQuillan wrote: > However, in at least the case > of Email header fields, there is another reason for X- names: Private Use. In fact, I believe that 'private use' was the original expectation. But I don't think it matters. What matters is that non-standardized use has a sneaky habit of becoming standardized use. > Thus, I would modify the recommendation of the ID to specify that X- names > should not be used for global interoperability experimentation, First of all, what is now private tends to later become public. What is now local later becomes global. Second, it doesn't matter. The X- does not add or decrease the amount that the header field is "private" or "public" or "experimental" or "production". It makes no difference to the utility of the header field... except to add to the burden of makiing the function of that field a standard. > On 10/20/2010 7:34 AM, Tony Hansen wrote: >> I've long felt that a large number of header fields that seem to appear as X- >> should really be vendor specific. Indeed, it is not unusual for a vendor to create "X--...". In terms of de facto registration, just the will suffice. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From john-ietf@jck.com Wed Oct 20 18:08:42 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 356B23A6359 for ; Wed, 20 Oct 2010 18:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9c306bVlMV0p for ; Wed, 20 Oct 2010 18:08:40 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 2B87F3A6940 for ; Wed, 20 Oct 2010 18:08:40 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1P8jfU-000ASL-C2; Wed, 20 Oct 2010 21:10:08 -0400 Date: Wed, 20 Oct 2010 21:10:07 -0400 From: John C Klensin To: Peter Saint-Andre , apps-discuss@ietf.org Message-ID: <90B61CB6D47AC1BB0F67AD02@PST.JCK.COM> In-Reply-To: <4CBF1CC6.7090408@stpeter.im> References: <4CBF1CC6.7090408@stpeter.im> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [apps-discuss] call for APPSAREA topics at IETF 79 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 01:08:42 -0000 --On Wednesday, October 20, 2010 10:45 -0600 Peter Saint-Andre wrote: > If you would like to make a presentation on any apps-related > topic during the APPSAREA session at IETF 79, please contact > me and Alexey, or just post to the apps-discuss list. Peter and Alexey, I'd like to take a few minutes to briefly discuss a small number of incompatible property changes in Unicode 6.0 and what actions the IETF should take, if any. The relevant document for IDNA is draft-faltstrom-5892bis-00. Note that the change may affect precis and other WGs and protocols that apply special interpretations, preparations, or constraints on Unicode strings. Even if other standards are written in terms of Unicode 6.0, they will probably need to provide a mechanism for dealing with this sort of change. The key question as far as IDNA is concerned is whether to add one of the changed characters to an exception list, thereby keeping it PVALID as it was for Unicode 5.2 or whether to let the character track the correction in Unicode 6.0, thereby making it DISALLOWED. The exception list, known in IDNA2008-speak as Rule G, was provided to deal with changes like this one, but it was expected to be very infrequently used and there are no characters in it today. draft-faltstrom-5892bis-00 (a candidate for the "shortest I-D" record) specifies the change needed to preserve the behavior of the Unicode 5.2 rules, i.e., keeping the relevant character "PVALID". If we conclude that we want to track the change in Unicode property behavior, no change is needed and the I-D can be discarded. john p.s. This note is deliberately as neutral as I was able to make it about what should be done. Similarly, the I-D was posted, not to advocate a particular position but to have a document available for discussion. From john-ietf@jck.com Wed Oct 20 18:24:07 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36C53A692C for ; Wed, 20 Oct 2010 18:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.43 X-Spam-Level: X-Spam-Status: No, score=-102.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDolA+hguA79 for ; Wed, 20 Oct 2010 18:24:06 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id B6CB53A6926 for ; Wed, 20 Oct 2010 18:24:06 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1P8juK-000AkL-UZ; Wed, 20 Oct 2010 21:25:29 -0400 Date: Wed, 20 Oct 2010 21:25:28 -0400 From: John C Klensin To: Paul Hoffman , Bill McQuillan , Apps-Discusssion Message-ID: In-Reply-To: References: <4CBDE23C.7050904@stpeter.im> <98229955.20101020005127@pobox.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 01:24:07 -0000 --On Wednesday, October 20, 2010 07:24 -0700 Paul Hoffman wrote: > At 12:51 AM -0700 10/20/10, Bill McQuillan wrote: >> I have a concern with the blanket deprecation of the X- >> convention. >> >> The ID presumes that the only use of X- values is for >> experimentation and rightly point out the problem of >> eventually trying to transition to a non X- value when the >> experiment has succeeded. However, in at least the case of >> Email header fields, there is another reason for X- names: >> Private Use. > > In other WGs, we have had problems with the term "private use" > and "vendor specific" and so on. A more descriptive term is > "never intended for interoperable use". It's not as easy to > say, but it is much more precise for what we want. Yes. And, even while understanding that things that start out intended as private sometimes become public, I think that narrow usage may be worth preserving... or at least that it deserves a rather careful discussion in the I-D. john From dhc@dcrocker.net Wed Oct 20 18:37:33 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83A2E3A6918 for ; Wed, 20 Oct 2010 18:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nfdh8O0suapr for ; Wed, 20 Oct 2010 18:37:32 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id AF64B3A68E3 for ; Wed, 20 Oct 2010 18:37:32 -0700 (PDT) Received: from [192.168.1.5] (ppp-68-120-198-81.dsl.pltn13.pacbell.net [68.120.198.81]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o9L1d1Rp003610 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 20 Oct 2010 18:39:07 -0700 Message-ID: <4CBF99B6.2060306@dcrocker.net> Date: Wed, 20 Oct 2010 18:39:02 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: John C Klensin References: <4CBDE23C.7050904@stpeter.im> <98229955.20101020005127@pobox.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 20 Oct 2010 18:39:07 -0700 (PDT) Cc: Apps-Discusssion , Paul Hoffman , Bill McQuillan Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 01:37:33 -0000 On 10/20/2010 6:25 PM, John C Klensin wrote: > And, even while understanding that things that start out > intended as private sometimes become public, I think that narrow > usage may be worth preserving X- does not enable, facilitate or preserve private usage. All it does it to make moving to standardized usage (significantly) more difficult. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From mnot@mnot.net Wed Oct 20 18:46:12 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C64E43A692C for ; Wed, 20 Oct 2010 18:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.41 X-Spam-Level: X-Spam-Status: No, score=-105.41 tagged_above=-999 required=5 tests=[AWL=-2.811, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzS4EiGJsGvy for ; Wed, 20 Oct 2010 18:46:12 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id F3AD63A68E3 for ; Wed, 20 Oct 2010 18:46:11 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.52.89]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F172E509D9 for ; Wed, 20 Oct 2010 21:47:39 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Mark Nottingham In-Reply-To: <4CBF8007.5010609@dcrocker.net> Date: Thu, 21 Oct 2010 12:47:36 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CBDE23C.7050904@stpeter.im> <6.2.5.6.2.20101019205927.0ae108b8@resistor.net> <4CBF8007.5010609@dcrocker.net> To: apps-discuss@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 01:46:12 -0000 On 21/10/2010, at 10:49 AM, Dave CROCKER wrote: > The second is that they somehow "prefer" using X-, rather than = inventing a name that does not use X-. >=20 > My anecdotal sense of things is that they actually believe they are = /required/ to use X-, for any non-standardized header field. Of course, = this is not the rule, but they seem to think it is. Exactly. -- Mark Nottingham http://www.mnot.net/ From Claudio.Allocchio@garr.it Wed Oct 20 23:44:08 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 538113A6990 for ; Wed, 20 Oct 2010 23:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.479 X-Spam-Level: X-Spam-Status: No, score=-1.479 tagged_above=-999 required=5 tests=[AWL=1.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojTf9xXG7lPp for ; Wed, 20 Oct 2010 23:44:06 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id 541F53A691C for ; Wed, 20 Oct 2010 23:44:06 -0700 (PDT) Received: from webcam1-all.garrtest.units.it (webcam1-all.garrtest.units.it [140.105.201.5]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id o9L6jOCT026325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Oct 2010 08:45:26 +0200 (CEST) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it o9L6jOCT026325 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=DTbbH4VY3B3T5aPm9qKxOoeQCLQ0noNjlro6r7eGZrHngI9BpAHMLYPfDiRVjI+/M wR85d1nTuWeAnum+gCMM2nOZ+gUO4r3aCRXviV3XDKsMha6tlqBETHE3CgCZA92A7SN l9VRtiL14HQNZm3m2RY8uBVX3CRSKhh3ajOiHtM= Date: Thu, 21 Oct 2010 08:45:23 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@webcam1-all.garrtest.units.it To: dcrocker@bbiw.net In-Reply-To: <4CBF8007.5010609@dcrocker.net> Message-ID: References: <4CBDE23C.7050904@stpeter.im> <6.2.5.6.2.20101019205927.0ae108b8@resistor.net> <4CBF8007.5010609@dcrocker.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 06:44:08 -0000 On Wed, 20 Oct 2010, Dave CROCKER wrote: > Disclaimer: > > I was editor for the document that introduced it, 28 years ago, but am > pretty sure the idea came from a participant on the mailing list that was > discussing RFC 822 development, rather than coming from my own brain. > > In any event, during the IETF DRUMS working group, which produced > RFC2822, I lobbied for eliminating the construct. I think it was an > excellent idea, but I think it's downside is far more significant than its > upside. And indeed, the upside has largely been eliminated. /d > > > On 10/20/2010 2:44 AM, SM wrote: >> Quoting Section 3.8.1 of RFC 2821 (3.7.1 in RFC 5321): >> >> "Other mail systems gatewayed to the Internet often use a subset of >> the RFC 822 header section ... A possible >> solution would be to create new header fields to carry the envelope >> information (e.g., "X-SMTP-MAIL:" and "X-SMTP-RCPT:");" for this one you I can blame guilty, but I share the burden with Steve Kille. It was a workaround to allow SMTP to be the intermediate carrier between 2 non-standard, or "different" standard mail systems: A-type-mail-system-->gw-->SMTP-->gw-->A-type-mail-system > Essentially, the need for some additonal header fields, for messages being > gatewaying in from another system, is merely one more source of "private" > content labeling. It does not really ahve any special characteristics. true. > There are two different issues. One is that people like to invent header > fields frequently and conveniently. I'd say that's a pretty safe assessment. > > The second is that they somehow "prefer" using X-, rather than inventing a > name that does not use X-. > > My anecdotal sense of things is that they actually believe they are > /required/ to use X-, for any non-standardized header field. Of course, this > is not the rule, but they seem to think it is. I agree. people tend to be a bit lazy... "let's use an X-... and tere will be less discussion, no need to follow standards approval procedures.." Some fields which are of general use MUST be considered for standard, thus "no X-" >> Now, does Xdash stand for Experimental or Extension? > > I don't remember that it had any specific meaning. nor do I. all the best! PS: this was the X- section of Dave's message as I received from the ML: X-Sieve: CMU Sieve 2.3 X-DKIM: Sendmail DKIM Filter v2.6.0 lx1.dir.garr.it o9KNneGD015895 X-Original-To: apps-discuss@core3.amsl.com X-Virus-Scanned: clamav-milter 0.96.1 at lx1.dir.garr.it X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-0.4 required=6.0 tests=AWL,BAYES_00,SPF_FAIL shortcircuit=no autolearn=no version=3.3.1 X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (lx1.dir.garr.it [193.206.158.2]); Thu, 21 Oct 2010 01:49:42 +0200 (CEST) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 20 Oct 2010 16:49:32 -0700 (PDT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 as you can see... none of them has any gateway meaning (ok we do not use gateways often anymore), and most of it is for informational purpouses to the human recipient (... and 98% of recipents will never see them). but... at least the "spam information" ones could have easily been standardised, but are we still in time now? :-) ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From nsb@guppylake.com Thu Oct 21 02:22:07 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EB3D3A681A for ; Thu, 21 Oct 2010 02:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0gwSraI61tc for ; Thu, 21 Oct 2010 02:22:05 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by core3.amsl.com (Postfix) with ESMTP id A199C3A681D for ; Thu, 21 Oct 2010 02:22:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=guppylake.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=R6x0zSLV/FMoJgG7VSaAA55coYX1SZjfRIkiIoHMvYnpVVh5YaI9TQI3DkxlD6qtZA9Ml/8QHLjJJ/fNwNlUxQDXtFCfolbkM7rl+3of3Edqa64U1RiKJfEuY2snaabI; Received: from 78-105-10-176.zone3.bethere.co.uk ([78.105.10.176] helo=fiver.config) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1P8rcf-0007lN-Ev; Thu, 21 Oct 2010 05:39:45 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nathaniel Borenstein In-Reply-To: <4CBF99B6.2060306@dcrocker.net> Date: Thu, 21 Oct 2010 10:23:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CBDE23C.7050904@stpeter.im> <98229955.20101020005127@pobox.com> <4CBF99B6.2060306@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server1.netnutz.com X-AntiAbuse: Original Domain - apps.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - guppylake.com Cc: Apps-Discusssion , Paul Hoffman , Bill McQuillan Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 09:22:07 -0000 Clearly this discussion is in need of a contrarian voice, so as a public = service I'll provide one. :-) I disagree strongly with Peter's statement, in the draft, that "The = practice is at best useless and at worst harmful." I think it is both = harmful and useful, and that there's a baby that shouldn't be thrown out = with the bathwater. I'm not a big fan of X-, but if we're going to = discourage/deprecate/eliminate it, we should address at least two cases = for which it has often been viewed as a solution. Saying "don't use X-" = won't accomplish much if we don't spell out clearly just what people = *should* do in these situations, the first of which has already been = discussed on this list: 1. Vendor-specific usage. It's true that X- wasn't intended for this, = but many vendors have gravitated to it in the absence of a preferred = technique. It is not unreasonable for a vendor to want to create a = header field that doesn't need to interoperate, but also doesn't = conflict with other vendors' usages. If two vendors both wanted a = header field to (fancifully) document the cost of security scanning a = message, for use downstream in their own systems, it's arguably fine if = they use completely different syntax and semantics, but it is asking for = trouble if they both call it "Security-cost." Vendors have favored X- = for this purpose simply because they know that interoperability isn't = generally expected, so it seems safer. =20 I'd prefer something like a "VENDOR-vendorname-fieldname" convention, = such as "VENDOR-GuppyLake-SecurityCost." We might even want to define = the syntax so that it gives a clue to anyone who needs/wants to find out = what it means, as in "VENDOR-emailaddress-SecurityCost" or = "VENDOR-url-SecurityCost." 2. Truly experimental usage. It's undoubtedly less common than it once = was, but sometimes a mail system implementor comes up with an idea that = requires a new header field. When you're not sure if it's really going = to be useful or if you've correctly identified what needs to be in it, = you want to conduct some trials, and only go to IANA or write an RFC if = the results justify continued effort. I've done this many times; being = able to just define an X- header myself, without worrying about a = rigorous definition or naming conflicts, facilitates experimental = research. The Internet has matured, but research still matters. Peter correctly asserts that simpler registration rules make this less = onerous, but any registration process can feel onerous for an = early-stage experiment, especially for those who've never registered = anything with IANA nor written an RFC. I fear Peter's proposal would = lead to a proliferation of unregistered types that do NOT start with X-, = a situation worse than the present one. Peter also describes as = problematic cases where both an X- and a non-X- version of a field name = persist, such as "gzip: and "x-gzip". But the solution to this is = typically one or two lines of code, which I find preferable to a = proliferation of unregistered non-X- types. Only using X- for true experiments would be fine with me, but I can also = imagine deciding that it has been so corrupted that a new prefix is = preferable. I would have no problem with deprecating X- in favor of = something like Vendor- and Experiment-. But we should address the = legitimate situations where registering the field name simply doesn't = make sense. Otherwise I fear Peter's draft will at worst create a = proliferation of unregistered non-X- types, and at best will have as = much effect as preaching abstinence to teenagers. -- Nathaniel On Oct 21, 2010, at 2:39 AM, Dave CROCKER wrote: >=20 >=20 > On 10/20/2010 6:25 PM, John C Klensin wrote: >> And, even while understanding that things that start out >> intended as private sometimes become public, I think that narrow >> usage may be worth preserving >=20 >=20 > X- does not enable, facilitate or preserve private usage. >=20 > All it does it to make moving to standardized usage (significantly) = more difficult. >=20 > d/ > --=20 >=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From john-ietf@jck.com Thu Oct 21 07:27:37 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D26B3A698E for ; Thu, 21 Oct 2010 07:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KD0p+1rIAvdo for ; Thu, 21 Oct 2010 07:27:36 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id B02993A67D1 for ; Thu, 21 Oct 2010 07:27:35 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1P8w8k-000Ixx-Gv; Thu, 21 Oct 2010 10:29:10 -0400 Date: Thu, 21 Oct 2010 10:29:09 -0400 From: John C Klensin To: Nathaniel Borenstein Message-ID: <068A5DA471E8E4C21AE40F49@PST.JCK.COM> In-Reply-To: References: <4CBDE23C.7050904@stpeter.im> <98229955.20101020005127@pobox.com> <4CBF99B6.2060306@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Apps-Discusssion Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 14:27:37 -0000 +1. Much better described than my earlier comment. john --On Thursday, October 21, 2010 10:23 +0100 Nathaniel Borenstein wrote: > Clearly this discussion is in need of a contrarian voice, so > as a public service I'll provide one. :-) > > I disagree strongly with Peter's statement, in the draft, that > "The practice is at best useless and at worst harmful." I > think it is both harmful and useful, and that there's a baby > that shouldn't be thrown out with the bathwater. > > I'm not a big fan of X-, but if we're going to > discourage/deprecate/eliminate it, we should address at least > two cases for which it has often been viewed as a solution. > Saying "don't use X-" won't accomplish much if we don't spell > out clearly just what people *should* do in these situations, > the first of which has already been discussed on this list: > > 1. Vendor-specific usage. It's true that X- wasn't intended > for this, but many vendors have gravitated to it in the > absence of a preferred technique. It is not unreasonable for > a vendor to want to create a header field that doesn't need to > interoperate, but also doesn't conflict with other vendors' > usages. If two vendors both wanted a header field to > (fancifully) document the cost of security scanning a message, > for use downstream in their own systems, it's arguably fine if > they use completely different syntax and semantics, but it is > asking for trouble if they both call it "Security-cost." > Vendors have favored X- for this purpose simply because they > know that interoperability isn't generally expected, so it > seems safer. > > I'd prefer something like a "VENDOR-vendorname-fieldname" > convention, such as "VENDOR-GuppyLake-SecurityCost." We might > even want to define the syntax so that it gives a clue to > anyone who needs/wants to find out what it means, as in > "VENDOR-emailaddress-SecurityCost" or > "VENDOR-url-SecurityCost." > > 2. Truly experimental usage. It's undoubtedly less common > than it once was, but sometimes a mail system implementor > comes up with an idea that requires a new header field. When > you're not sure if it's really going to be useful or if you've > correctly identified what needs to be in it, you want to > conduct some trials, and only go to IANA or write an RFC if > the results justify continued effort. I've done this many > times; being able to just define an X- header myself, without > worrying about a rigorous definition or naming conflicts, > facilitates experimental research. The Internet has matured, > but research still matters. > > Peter correctly asserts that simpler registration rules make > this less onerous, but any registration process can feel > onerous for an early-stage experiment, especially for those > who've never registered anything with IANA nor written an RFC. > I fear Peter's proposal would lead to a proliferation of > unregistered types that do NOT start with X-, a situation > worse than the present one. Peter also describes as > problematic cases where both an X- and a non-X- version of a > field name persist, such as "gzip: and "x-gzip". But the > solution to this is typically one or two lines of code, which > I find preferable to a proliferation of unregistered non-X- > types. > > Only using X- for true experiments would be fine with me, but > I can also imagine deciding that it has been so corrupted that > a new prefix is preferable. I would have no problem with > deprecating X- in favor of something like Vendor- and > Experiment-. But we should address the legitimate situations > where registering the field name simply doesn't make sense. > Otherwise I fear Peter's draft will at worst create a > proliferation of unregistered non-X- types, and at best will > have as much effect as preaching abstinence to teenagers. From paul.hoffman@vpnc.org Thu Oct 21 08:00:17 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 171BC3A6A47 for ; Thu, 21 Oct 2010 08:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.409 X-Spam-Level: X-Spam-Status: No, score=-101.409 tagged_above=-999 required=5 tests=[AWL=0.637, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGbVbXhX5HPK for ; Thu, 21 Oct 2010 08:00:16 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id E5AE53A6A24 for ; Thu, 21 Oct 2010 08:00:15 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o9LF1oMo040795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Oct 2010 08:01:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4CBDE23C.7050904@stpeter.im> <98229955.20101020005127@pobox.com> <4CBF99B6.2060306@dcrocker.net> Date: Thu, 21 Oct 2010 08:01:48 -0700 To: Apps-Discusssion From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 15:00:17 -0000 At 10:23 AM +0100 10/21/10, Nathaniel Borenstein wrote: >I disagree strongly with Peter's statement, in the draft, that "The practice is at best useless and at worst harmful." I think it is both harmful and useful, and that there's a baby that shouldn't be thrown out with the bathwater. Maybe "often harmful and rarely useful". >I'm not a big fan of X-, but if we're going to discourage/deprecate/eliminate it, we should address at least two cases for which it has often been viewed as a solution. Saying "don't use X-" won't accomplish much if we don't spell out clearly just what people *should* do in these situations, Agree. > the first of which has already been discussed on this list: > >1. Vendor-specific usage. It's true that X- wasn't intended for this, but many vendors have gravitated to it in the absence of a preferred technique. It is not unreasonable for a vendor to want to create a header field that doesn't need to interoperate, but also doesn't conflict with other vendors' usages. If two vendors both wanted a header field to (fancifully) document the cost of security scanning a message, for use downstream in their own systems, it's arguably fine if they use completely different syntax and semantics, but it is asking for trouble if they both call it "Security-cost." Vendors have favored X- for this purpose simply because they know that interoperability isn't generally expected, so it seems safer. > >I'd prefer something like a "VENDOR-vendorname-fieldname" convention, such as "VENDOR-GuppyLake-SecurityCost." We might even want to define the syntax so that it gives a clue to anyone who needs/wants to find out what it means, as in "VENDOR-emailaddress-SecurityCost" or "VENDOR-url-SecurityCost." It still would be good to say "if you use a vendor name instead of registering a new header, it can never be standardized and will thus never be interoperable; think carefully about whether you really want that outcome". >2. Truly experimental usage. It's undoubtedly less common than it once was, but sometimes a mail system implementor comes up with an idea that requires a new header field. When you're not sure if it's really going to be useful or if you've correctly identified what needs to be in it, you want to conduct some trials, and only go to IANA or write an RFC if the results justify continued effort. I've done this many times; being able to just define an X- header myself, without worrying about a rigorous definition or naming conflicts, facilitates experimental research. The Internet has matured, but research still matters. We fully disagree here. It is *trivial* for an experimenter with any sense to create your own non-conflicting headers for "truly experimental usage": use a random string. md5 is your friend here. Encouraging any sort of structure over-encourages this use. >Peter correctly asserts that simpler registration rules make this less onerous, but any registration process can feel onerous for an early-stage experiment, especially for those who've never registered anything with IANA nor written an RFC. I fear Peter's proposal would lead to a proliferation of unregistered types that do NOT start with X-, a situation worse than the present one. We are trying to guess what experimenters *who never read RFCs* might do, and yet none of us know them. > Peter also describes as problematic cases where both an X- and a non-X- version of a field name persist, such as "gzip: and "x-gzip". But the solution to this is typically one or two lines of code, which I find preferable to a proliferation of unregistered non-X- types. We disagree here as well. As we discovered in the IPsec world, the registered version is usually a bit different than the last experimental (or, in our case, vendor-specific) version, yet some implementers assume exactly what you did and therefore interoperability between the two goes two hell. --Paul Hoffman, Director --VPN Consortium From john-ietf@jck.com Thu Oct 21 08:01:25 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD5FB3A6A4A for ; Thu, 21 Oct 2010 08:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSJLg4Irm9vD for ; Thu, 21 Oct 2010 08:01:24 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 8F3ED3A6A45 for ; Thu, 21 Oct 2010 08:01:24 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1P8wfT-000K3x-Ql; Thu, 21 Oct 2010 11:03:00 -0400 Date: Thu, 21 Oct 2010 11:02:59 -0400 From: John C Klensin To: dcrocker@bbiw.net Message-ID: In-Reply-To: <4CBF99B6.2060306@dcrocker.net> References: <4CBDE23C.7050904@stpeter.im> <98229955.20101020005127@pobox.com> <4CBF99B6.2060306@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Apps-Discusssion Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 15:01:25 -0000 --On Wednesday, October 20, 2010 18:39 -0700 Dave CROCKER wrote: > On 10/20/2010 6:25 PM, John C Klensin wrote: >> And, even while understanding that things that start out >> intended as private sometimes become public, I think that >> narrow usage may be worth preserving > > > X- does not enable, facilitate or preserve private usage. > > All it does it to make moving to standardized usage > (significantly) more difficult. Dave, To add just one thing to Nathaniel's more comprehensive and, IMO, better, note... Uniqueness is good and a unique binding of header name to syntax and semantics is better. Having two header fields in wide use with different definitions but the same name is the biggest impediment to standardization of all: if we want to standardize, we may need to end up changing both of them. If we could somehow guarantee that every header name, including private-use, experimental (and certain to be redesigned somewhat if it ever went public), and vendor-specific ones would be registered --at least to stake a claim on uniqueness even if not a precise definition-- I'd favor doing away with "X-" (or special treatment of "X-" because I think the odds of getting rid of it at this stage are zero). But our track record there is pretty bad, both for the reasons that Nathaniel identifies and because, sooner or later, we seem to always get to the point with IANA registries that someone feels a need to evaluate proposed registrations for quality or desirability and to push back on some of them as a result. Until and unless we can solve those really fundamental problems, it seems to me that it actually is useful to have a flag that says "unless you have external information from other fields or private agreements between particular senders and recipients, you need to treat this header field as if you have no clue what it means or how it should be interpreted". I think it is a problem that we have never made _that_ definition of "X-" quite clear enough. I think Nathaniel's proposals for more structured private/ vendor/ experimental fields are a much better solution. But it doesn't seem to me that "declare harmful; discard bathwater, baby, and sink" without providing any replacement plan for the relevant uses would be a good idea. john From dhc@dcrocker.net Thu Oct 21 09:27:01 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C10D43A6910 for ; Thu, 21 Oct 2010 09:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpFtXIO1xiIo for ; Thu, 21 Oct 2010 09:27:00 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 828893A69F6 for ; Thu, 21 Oct 2010 09:27:00 -0700 (PDT) Received: from [192.168.1.5] (ppp-68-120-198-81.dsl.pltn13.pacbell.net [68.120.198.81]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o9LGSUXc011368 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 21 Oct 2010 09:28:35 -0700 Message-ID: <4CC06A30.7020004@dcrocker.net> Date: Thu, 21 Oct 2010 09:28:32 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: Nathaniel Borenstein References: <4CBDE23C.7050904@stpeter.im> <98229955.20101020005127@pobox.com> <4CBF99B6.2060306@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 21 Oct 2010 09:28:36 -0700 (PDT) Cc: Apps-Discusssion , Paul Hoffman , Bill McQuillan Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 16:27:01 -0000 On 10/21/2010 2:23 AM, Nathaniel Borenstein wrote: > 1. Vendor-specific usage. ... > It is not unreasonable for a vendor to want to create a header field that > doesn't need to interoperate, but also doesn't conflict with other vendors' > usages. X- neither aids nor impedes this. The way that vendors create vendor-specific header fields is by affixing their own clever string to the name, such as their company or product name. This works equally well (or poorly) with or without the X-. > I'd prefer something like a "VENDOR-vendorname-fieldname" convention, such as What is the value add of the prefatory string? Some other vendor can come along and use the same vendorname. (Yes, really.) They won't do this, unless the string is extremely generic and the later developer is extremely naive; but they can, absent a registry. Given a registry, the prefatory string is still not needed. The question then will be why a special registry for vendor stuff is needed, rather than simply having a single, uniform header-field registry, such as we already have. > 2. Truly experimental usage. ... > When you're not sure if it's really going to be useful or > if you've correctly identified what needs to be in it, you want to conduct > some trials, and only go to IANA or write an RFC if the results justify > continued effort. X- neither aids nor impedes this. Anyone may already affix whatever new header-fields they want. Just do it. > Peter correctly asserts that simpler registration rules make this less > onerous, but any registration process can feel onerous for an early-stage And, indeed, there is already no requirement to register the field name. > Peter also describes as problematic cases where both an X- and > a non-X- version of a field name persist, such as "gzip: and "x-gzip". But > the solution to this is typically one or two lines of code, which I find > preferable to a proliferation of unregistered non-X- types. That line (pun) of thinking says that combinatorial explosion isn't a problem. One or two lines of code here; one or two lines of code there. Pretty soon... The only thing that X- accomplishes is to require long-term support for a non-standard name and a standard name, if a feature gets sufficiently popular. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dave@cridland.net Thu Oct 21 09:54:27 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FFE33A69D4 for ; Thu, 21 Oct 2010 09:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzsJOH7INfVt for ; Thu, 21 Oct 2010 09:54:25 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id 4B82C3A699A for ; Thu, 21 Oct 2010 09:54:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 1E93D11680E6; Thu, 21 Oct 2010 17:56:00 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDjduIVNVf3e; Thu, 21 Oct 2010 17:55:54 +0100 (BST) Received: from puncture (unknown [217.155.137.60]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 0555411680CA; Thu, 21 Oct 2010 17:55:54 +0100 (BST) References: <4CBDE23C.7050904@stpeter.im> <98229955.20101020005127@pobox.com> <4CBF99B6.2060306@dcrocker.net> <4CC06A30.7020004@dcrocker.net> In-Reply-To: <4CC06A30.7020004@dcrocker.net> MIME-Version: 1.0 Message-Id: <779.1287680154.003528@puncture> Date: Thu, 21 Oct 2010 17:55:54 +0100 From: Dave Cridland To: Dave CROCKER , general discussion of application-layer protocols , Paul Hoffman , Bill McQuillan , Nathaniel Borenstein Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 16:54:27 -0000 On Thu Oct 21 17:28:32 2010, Dave CROCKER wrote: > On 10/21/2010 2:23 AM, Nathaniel Borenstein wrote: >> 1. Vendor-specific usage. > ... >> It is not unreasonable for a vendor to want to create a header >> field that >> doesn't need to interoperate, but also doesn't conflict with other >> vendors' >> usages. > > X- neither aids nor impedes this. The way that vendors create > vendor-specific header fields is by affixing their own clever > string to the name, such as their company or product name. This > works equally well (or poorly) with or without the X-. > > No, a defined convention encourages people to follow it. By making X-* a free-for-all, nobody is encouraged into adding a vendor prefix that they weren't aware needed adding. >> I'd prefer something like a "VENDOR-vendorname-fieldname" >> convention, such as > > What is the value add of the prefatory string? Some other vendor > can come along and use the same vendorname. (Yes, really.) They > won't do this, unless the string is extremely generic and the later > developer is extremely naive; but they can, absent a registry. > Given a registry, the prefatory string is still not needed. The > question then will be why a special registry for vendor stuff is > needed, rather than simply having a single, uniform header-field > registry, such as we already have. > > You can register just the vendor token, in which case - even if not all vendors register themselves there - it will reduce collisions. In any case, fussing over whether two vendors might choose sufficiently generic names that their choice of vendor token my clash seems to my mind to be reaching - it seems apparent to me that it will be a considerably lesser occurence than a an X- clash, and in addition there is the benefit that someone desiring to find out the semantics of the header mgith be able to deduce a contact to ask. >> 2. Truly experimental usage. > ... >> When you're not sure if it's really going to be useful or >> if you've correctly identified what needs to be in it, you want to >> conduct >> some trials, and only go to IANA or write an RFC if the results >> justify >> continued effort. > > X- neither aids nor impedes this. Anyone may already affix > whatever new header-fields they want. Just do it. But how can one be assured that their header will be treated as, and remain treated as, an private experiment? >> Peter also describes as problematic cases where both an X- and >> a non-X- version of a field name persist, such as "gzip: and >> "x-gzip". But >> the solution to this is typically one or two lines of code, which >> I find >> preferable to a proliferation of unregistered non-X- types. > > That line (pun) of thinking says that combinatorial explosion isn't > a problem. One or two lines of code here; one or two lines of code > there. Pretty soon... I still say that this is the lesser evil compared to a bun-fight in the header. > The only thing that X- accomplishes is to require long-term support > for a non-standard name and a standard name, if a feature gets > sufficiently popular. That's not the only thing it accomplishes at all. X- header field names *do* have a harmful effect. The question is whether this is outweighed by their benefits, and secondly whether there exists a better solution we can promote for those wishing to use X- fields. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From dhc@dcrocker.net Thu Oct 21 10:19:10 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C23813A6A3B for ; Thu, 21 Oct 2010 10:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyTJ-a5C1xAO for ; Thu, 21 Oct 2010 10:18:39 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id ACD063A6A42 for ; Thu, 21 Oct 2010 10:18:01 -0700 (PDT) Received: from [192.168.1.5] (ppp-68-120-198-81.dsl.pltn13.pacbell.net [68.120.198.81]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o9LHJVC4014619 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 21 Oct 2010 10:19:37 -0700 Message-ID: <4CC07625.8010509@dcrocker.net> Date: Thu, 21 Oct 2010 10:19:33 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: Dave Cridland References: <4CBDE23C.7050904@stpeter.im> <98229955.20101020005127@pobox.com> <4CBF99B6.2060306@dcrocker.net> <4CC06A30.7020004@dcrocker.net> <779.1287680154.003528@puncture> In-Reply-To: <779.1287680154.003528@puncture> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 21 Oct 2010 10:19:37 -0700 (PDT) Cc: general discussion of application-layer protocols , Paul Hoffman , Bill McQuillan Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 17:19:10 -0000 On 10/21/2010 9:55 AM, Dave Cridland wrote: > No, a defined convention encourages people to follow it. By making X-* a > free-for-all, nobody is encouraged into adding a vendor prefix that they weren't > aware needed adding. X- has been a free-for-all for 33 years. You aren't likely to change that. If you want to encourage adding a vendor prefix, encourage adding a vendor prefix. X- has nothing to do with this. > You can register just the vendor token, in which case - even if not all vendors > register themselves there - it will reduce collisions. This sounds like a reasonable enhancement to the existing header field registry[1]. X- has nothing to do with this. >>> 2. Truly experimental usage. >> ... >>> When you're not sure if it's really going to be useful or >>> if you've correctly identified what needs to be in it, you want to conduct >>> some trials, and only go to IANA or write an RFC if the results justify >>> continued effort. >> >> X- neither aids nor impedes this. Anyone may already affix whatever new >> header-fields they want. Just do it. > > But how can one be assured that their header will be treated as, and remain > treated as, an private experiment? Nothing can ensure that. >>> Peter also describes as problematic cases where both an X- and >>> a non-X- version of a field name persist, such as "gzip: and "x-gzip". But >>> the solution to this is typically one or two lines of code, which I find >>> preferable to a proliferation of unregistered non-X- types. >> >> That line (pun) of thinking says that combinatorial explosion isn't a problem. >> One or two lines of code here; one or two lines of code there. Pretty soon... > > I still say that this is the lesser evil compared to a bun-fight in the header. Collisions have not been a problem for 33 years. What now makes it a problem? In constrast, combinatorial explosion in email implementation of variants /has/ been a problem. >> The only thing that X- accomplishes is to require long-term support for a >> non-standard name and a standard name, if a feature gets sufficiently popular. > > That's not the only thing it accomplishes at all. > > X- header field names *do* have a harmful effect. Please document the harm, beyond the adoption barrier when a feature becomes a standard. d/ [1] -- Dave Crocker Brandenburg InternetWorking bbiw.net From fanf2@hermes.cam.ac.uk Thu Oct 21 10:26:34 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC0753A69EF for ; Thu, 21 Oct 2010 10:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.277 X-Spam-Level: X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[AWL=-1.278, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uijw43z7NCKW for ; Thu, 21 Oct 2010 10:26:33 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by core3.amsl.com (Postfix) with ESMTP id 7212F3A6866 for ; Thu, 21 Oct 2010 10:26:33 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:59382) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1P8yvt-0003yy-qf (Exim 4.72) (return-path ); Thu, 21 Oct 2010 18:28:05 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1P8yvt-000324-AA (Exim 4.67) (return-path ); Thu, 21 Oct 2010 18:28:05 +0100 Date: Thu, 21 Oct 2010 18:28:05 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Nicolas Williams In-Reply-To: <20101020151343.GS1635@oracle.com> Message-ID: References: <4CBDE23C.7050904@stpeter.im> <98229955.20101020005127@pobox.com> <779.1287584978.272414@puncture> <20101020151343.GS1635@oracle.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: general discussion of application-layer protocols , Paul Hoffman , Bill McQuillan Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 17:26:35 -0000 On Wed, 20 Oct 2010, Nicolas Williams wrote: > > Correct MTA implementations ought to filter out such extensions when > e-mail crosses administrative domains or gateways that don't understand > the forwarding node's vendor extensions. That kind of information loss seems like a bad idea to me. If it were common it would have made it impossible to add features like MIME and MDNs. > Vendor extensions in delivered e-mail seem OK to me because > users can often interpret them in many cases without extra help. That sounds like a contradiction of the previous sentence. If they are OK to deliver, why strip them? > Indeed. But maybe we should have a scope identifier. For example: > > Z-JoeSixPackSW-spamscore-foo.example: 37 > > which would be stripped from e-mail being forwarded to MTAs outside > foo.example If there's a scope tag there's no need to strip since only software within the scope will try to interpret it. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From al@akc.com Thu Oct 21 10:33:31 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED5B33A6A82 for ; Thu, 21 Oct 2010 10:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hemIdMxJPVZr for ; Thu, 21 Oct 2010 10:33:29 -0700 (PDT) Received: from imail.akc.com (unknown [192.188.192.3]) by core3.amsl.com (Postfix) with ESMTP id 53FFD3A6A7E for ; Thu, 21 Oct 2010 10:33:29 -0700 (PDT) Received: from upstairs (upstairs.akc.com [64.253.39.242]) by imail.akc.com with SMTP; Thu, 21 Oct 2010 13:34:38 -0400 Message-ID: From: "Al Costanzo" To: , "Nathaniel Borenstein" References: <4CBDE23C.7050904@stpeter.im> <98229955.20101020005127@pobox.com> <4CBF99B6.2060306@dcrocker.net> <4CC06A30.7020004@dcrocker.net> Date: Thu, 21 Oct 2010 13:34:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Cc: Apps-Discusssion , Paul Hoffman , Bill McQuillan Subject: Re: [apps-discuss] Fwd:I-D Action:draft-saintandre-xdash-considered-harmful-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Al Costanzo List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 17:33:31 -0000 >> I'd prefer something like a "VENDOR-vendorname-fieldname" convention, >> such as > > What is the value add of the prefatory string? Some other vendor can come > along and use the same vendorname. (Yes, really.) They won't do this, > unless the string is extremely generic and the later developer is > extremely naive; but they can, absent a registry. I have had to deal with this "first hand" that a different vendor used our company name (Dynamic Software) We had to trademark the name to stop them. IMHO, I if you are going to be creating an RFC the "Vendor" name needs to be the company name as on the Incorporation papers etc. They just cannot pick the name willy nilly. Regards, Al Costanzo Therefore if you are going to write an RFC ----- Original Message ----- From: "Dave CROCKER" To: "Nathaniel Borenstein" Cc: "Apps-Discusssion" ; "Paul Hoffman" ; "Bill McQuillan" Sent: Thursday, October 21, 2010 12:28 PM Subject: Re: [apps-discuss] Fwd:I-D Action:draft-saintandre-xdash-considered-harmful-01.txt > > > On 10/21/2010 2:23 AM, Nathaniel Borenstein wrote: >> 1. Vendor-specific usage. > ... >> It is not unreasonable for a vendor to want to create a header field that >> doesn't need to interoperate, but also doesn't conflict with other >> vendors' >> usages. > > X- neither aids nor impedes this. The way that vendors create > vendor-specific header fields is by affixing their own clever string to > the name, such as their company or product name. This works equally well > (or poorly) with or without the X-. > > >> I'd prefer something like a "VENDOR-vendorname-fieldname" convention, >> such as > > What is the value add of the prefatory string? Some other vendor can come > along and use the same vendorname. (Yes, really.) They won't do this, > unless the string is extremely generic and the later developer is > extremely naive; but they can, absent a registry. Given a registry, the > prefatory string is still not needed. The question then will be why a > special registry for vendor stuff is needed, rather than simply having a > single, uniform header-field registry, such as we already have. > > >> 2. Truly experimental usage. > ... >> When you're not sure if it's really going to be useful or >> if you've correctly identified what needs to be in it, you want to >> conduct >> some trials, and only go to IANA or write an RFC if the results justify >> continued effort. > > X- neither aids nor impedes this. Anyone may already affix whatever new > header-fields they want. Just do it. > > >> Peter correctly asserts that simpler registration rules make this less >> onerous, but any registration process can feel onerous for an early-stage > > And, indeed, there is already no requirement to register the field name. > > >> Peter also describes as problematic cases where both an X- and >> a non-X- version of a field name persist, such as "gzip: and "x-gzip". >> But >> the solution to this is typically one or two lines of code, which I find >> preferable to a proliferation of unregistered non-X- types. > > That line (pun) of thinking says that combinatorial explosion isn't a > problem. One or two lines of code here; one or two lines of code there. > Pretty soon... > > > The only thing that X- accomplishes is to require long-term support for a > non-standard name and a standard name, if a feature gets sufficiently > popular. > > d/ > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From GK-lists@ninebynine.org Thu Oct 21 13:23:29 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 787C83A683A for ; Thu, 21 Oct 2010 13:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.332 X-Spam-Level: X-Spam-Status: No, score=-6.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKXopQOP7tx2 for ; Thu, 21 Oct 2010 13:23:28 -0700 (PDT) Received: from relay6.mail.ox.ac.uk (relay6.mail.ox.ac.uk [163.1.2.167]) by core3.amsl.com (Postfix) with ESMTP id D4AA73A67F6 for ; Thu, 21 Oct 2010 13:23:27 -0700 (PDT) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay6.mail.ox.ac.uk with esmtp (Exim 4.71) (envelope-from ) id 1P91gz-0005fp-Jv; Thu, 21 Oct 2010 21:24:53 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1P91gy-0007aE-5i; Thu, 21 Oct 2010 21:24:53 +0100 Message-ID: <4CC0A193.9060306@ninebynine.org> Date: Thu, 21 Oct 2010 21:24:51 +0100 From: Graham Klyne User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Nathaniel Borenstein References: <4CBDE23C.7050904@stpeter.im> <98229955.20101020005127@pobox.com> <4CBF99B6.2060306@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: Bill McQuillan , Apps-Discusssion , dcrocker@bbiw.net, Paul Hoffman Subject: Re: [apps-discuss] Fwd: I-D Action:draft-saintandre-xdash-considered-harmful-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 20:23:29 -0000 Hi, Both of the situations you suggest are covered by provisional registration, per http://tools.ietf.org/html/rfc3864. The bar for approval is set deliberately low to facilitate getting some form of public documentation. #g -- Nathaniel Borenstein wrote: > Clearly this discussion is in need of a contrarian voice, so as a public service I'll provide one. :-) > > I disagree strongly with Peter's statement, in the draft, that "The practice is at best useless and at worst harmful." I think it is both harmful and useful, and that there's a baby that shouldn't be thrown out with the bathwater. > > I'm not a big fan of X-, but if we're going to discourage/deprecate/eliminate it, we should address at least two cases for which it has often been viewed as a solution. Saying "don't use X-" won't accomplish much if we don't spell out clearly just what people *should* do in these situations, the first of which has already been discussed on this list: > > 1. Vendor-specific usage. It's true that X- wasn't intended for this, but many vendors have gravitated to it in the absence of a preferred technique. It is not unreasonable for a vendor to want to create a header field that doesn't need to interoperate, but also doesn't conflict with other vendors' usages. If two vendors both wanted a header field to (fancifully) document the cost of security scanning a message, for use downstream in their own systems, it's arguably fine if they use completely different syntax and semantics, but it is asking for trouble if they both call it "Security-cost." Vendors have favored X- for this purpose simply because they know that interoperability isn't generally expected, so it seems safer. > > I'd prefer something like a "VENDOR-vendorname-fieldname" convention, such as "VENDOR-GuppyLake-SecurityCost." We might even want to define the syntax so that it gives a clue to anyone who needs/wants to find out what it means, as in "VENDOR-emailaddress-SecurityCost" or "VENDOR-url-SecurityCost." > > 2. Truly experimental usage. It's undoubtedly less common than it once was, but sometimes a mail system implementor comes up with an idea that requires a new header field. When you're not sure if it's really going to be useful or if you've correctly identified what needs to be in it, you want to conduct some trials, and only go to IANA or write an RFC if the results justify continued effort. I've done this many times; being able to just define an X- header myself, without worrying about a rigorous definition or naming conflicts, facilitates experimental research. The Internet has matured, but research still matters. > > Peter correctly asserts that simpler registration rules make this less onerous, but any registration process can feel onerous for an early-stage experiment, especially for those who've never registered anything with IANA nor written an RFC. I fear Peter's proposal would lead to a proliferation of unregistered types that do NOT start with X-, a situation worse than the present one. Peter also describes as problematic cases where both an X- and a non-X- version of a field name persist, such as "gzip: and "x-gzip". But the solution to this is typically one or two lines of code, which I find preferable to a proliferation of unregistered non-X- types. > > Only using X- for true experiments would be fine with me, but I can also imagine deciding that it has been so corrupted that a new prefix is preferable. I would have no problem with deprecating X- in favor of something like Vendor- and Experiment-. But we should address the legitimate situations where registering the field name simply doesn't make sense. Otherwise I fear Peter's draft will at worst create a proliferation of unregistered non-X- types, and at best will have as much effect as preaching abstinence to teenagers. -- Nathaniel > > > On Oct 21, 2010, at 2:39 AM, Dave CROCKER wrote: > >> >> On 10/20/2010 6:25 PM, John C Klensin wrote: >>> And, even while understanding that things that start out >>> intended as private sometimes become public, I think that narrow >>> usage may be worth preserving >> >> X- does not enable, facilitate or preserve private usage. >> >> All it does it to make moving to standardized usage (significantly) more difficult. >> >> d/ >> -- >> >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From A.Hoenes@TR-Sys.de Thu Oct 21 13:29:28 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7985F3A67F6 for ; Thu, 21 Oct 2010 13:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.151 X-Spam-Level: X-Spam-Status: No, score=-98.151 tagged_above=-999 required=5 tests=[AWL=0.598, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7DoxtgcS9uv for ; Thu, 21 Oct 2010 13:29:27 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id C648C3A6838 for ; Thu, 21 Oct 2010 13:29:19 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA077463047; Thu, 21 Oct 2010 22:30:47 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA26704; Thu, 21 Oct 2010 22:30:46 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201010212030.WAA26704@TR-Sys.de> To: apps-discuss@ietf.org Date: Thu, 21 Oct 2010 22:30:45 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Subject: Re: [apps-discuss] draft-saintandre-xdash-considered-harmful-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 20:29:29 -0000 [[ shortening the Subject to make it more concise ]] In the whole discussion so far I observe an overly strong focus on email header field names, and consequentially some degree of neglection of bad experiences with X-* names in other namespaces. But if I understand the subject draft correctly, this was not the primary, or exclusive target namespace for the considerations. I strongly suspect the origin of the draft has been in , which relates the trouble of standardizing and deploying the Internet media type "application/www-form-urlencoded" as a successor for the media type "application/x-www-form-urlencoded" once specified in the (now Historic[al]) RFC 1866. The latter is deployed at large scale (no experiment!) and cannot be registered (or have the registry entry updated) under the present rules via a new Standards Track document, where it is actually needed. (Note that application/[x-]gzip is similar, but nobody tries to include the non-X- form as a component of a revised Standard so far. The much more severe trouble with compression etc. relates to the matter of fact that the concept of Internet media types does not allow structured nesting -- as with CMS content types --, and it has always been controversial whether compression should be regarded as some kind of [transfer] encoding, although it is also used for storage. But I go astray a bit; hence back to the primary topic ...) I also note that the concept of P-* ("private") header field names in SIP has also been declared a mis-invention now, because these actually were intended for independent, interoperable implementations targeting specific, yet kinda generic deployments. So could we please widen the focus of the discussion accordingly? Thanks in advance! A quick observation and a rough thought based on it (and I try to be neutral below regarding the namespace): It looks like the seminal event for trouble with an X-* name is when a *second* implementation starts to _generate_ that X-* name. As long as only a single implementation of an application/protocol generates the name, there are no interoperability concerns and arguably the purpose is not ripe for standardization -- independent of the possibility that there _might_ happen to be several implementations _consuming_ the entity identified by that name. But as soon as the idea behind such entity and name gains traction and multiple implementations are wanted, that should qualify for a 'normal' registration in the regular namespace. So would it make sense to consider a change in the usage rules for X-* names that STRONGLY RECOMMENDS to change track and register a non-X-* name once more than one implementation considers making active use of a particular X-* name ? Adoption of such rules for specific namespaces should at least help avoid trouble with new X-* names in the future, but it cannot undo the sins of the past, of course. As an ancillary measure, having a simple sub-registry (with FCFS policy) for the respective parent namespace to help avoid name collisions for X-* names might be considered, maybe with automatic aging and removal after a given time span absent active renewal -- IANA reportedly is able to generically support timed events in registries. Just a thought ... Opinions? Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From julian.reschke@gmx.de Fri Oct 22 03:26:01 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E73B3A6855 for ; Fri, 22 Oct 2010 03:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.905 X-Spam-Level: X-Spam-Status: No, score=-104.905 tagged_above=-999 required=5 tests=[AWL=-2.306, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTPSWerm+jAZ for ; Fri, 22 Oct 2010 03:26:00 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 3B39A3A6782 for ; Fri, 22 Oct 2010 03:25:59 -0700 (PDT) Received: (qmail invoked by alias); 22 Oct 2010 10:27:35 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.131]) [217.91.35.233] by mail.gmx.net (mp057) with SMTP; 22 Oct 2010 12:27:35 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+xBcdoIu+xyfbTxrqgKnbs2PLJbR6QQ2BndzW4LA RQOF0EPLBgOxax Message-ID: <4CC16707.5050203@gmx.de> Date: Fri, 22 Oct 2010 12:27:19 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Al Costanzo References: <4CBDE23C.7050904@stpeter.im> <98229955.20101020005127@pobox.com> <4CBF99B6.2060306@dcrocker.net> <4CC06A30.7020004@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Bill McQuillan , Paul Hoffman , dcrocker@bbiw.net, Apps-Discusssion Subject: Re: [apps-discuss] Fwd:I-D Action:draft-saintandre-xdash-considered-harmful-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 10:26:01 -0000 On 21.10.2010 19:34, Al Costanzo wrote: > ... > IMHO, I if you are going to be creating an RFC the "Vendor" name needs > to be the company name as on the Incorporation papers etc. They just > cannot pick the name willy nilly. > ... Incorporation papers in which country? (I note that RFC 2774 uses URIs for disambiguation, essentially copying the design of XML namespaces; just saying...) Best regards, Julian From A.Hoenes@TR-Sys.de Fri Oct 22 10:30:36 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96EE73A6936; Fri, 22 Oct 2010 10:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.268 X-Spam-Level: X-Spam-Status: No, score=-98.268 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDpBH2qehiGj; Fri, 22 Oct 2010 10:30:29 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id D47F828C0E8; Fri, 22 Oct 2010 10:30:26 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA082568713; Fri, 22 Oct 2010 19:31:53 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id TAA28915; Fri, 22 Oct 2010 19:31:51 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201010221731.TAA28915@TR-Sys.de> To: apps-discuss@ietf.org, tsvwg@ietf.org Date: Fri, 22 Oct 2010 19:31:51 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: nfsv4@ietf.org Subject: [apps-discuss] New Version Notification for draft-gudmundsson-dnsext-srv-clarify-02 (fwd) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 17:30:36 -0000 Folks, Apologies for cross-posting, but DNS-based service discovery is such a pervasive subject... We have uploaded a new version of our DNS SRV clarifications draft that, according to an agreement at IETF 76, is planned for coordinated publication with the document that lays the foundation for the upcoming unified IANA "Service Name and Transport Protocol Port Number" Registry, and with another Informational document (still in progress) that will describe cleanup operations for related IANA registries that have become outdated (or will do so due to this major streamlining), and that will give recommendations for how to update use cases of DNS SRV specified in RFCs (or currently being discussed in the IETF) that do not conform to the emerging new rules (and arguably never did so with the previous rules). The new version addresses comments by giving even more background information and providing additional clarifications, and it has been brought in close alignment with the recent updates to the registry document per draft-ietf-tsvwg-iana-ports-07. Beyond that, the revised draft contains numerous editorial improvements. Kind regards, Alfred HÎnes. ----- Forwarded message from IETF I-D Submission Tool ----- > Message-Id: <20101022164123.7AF403A690A@core3.amsl.com> > Date: Fri, 22 Oct 2010 09:41:22 -0700 (PDT) > Subject: New Version Notification for draft-gudmundsson-dnsext-srv-clarify-02 A new version of I-D, draft-gudmundsson-dnsext-srv-clarify-02.txt has been successfully submitted by Alfred Hoenes and posted to the IETF repository. Filename: draft-gudmundsson-dnsext-srv-clarify Revision: 02 Title: DNS SRV Usage Guidelines and Owner Name Recommendations Creation_date: 2010-10-22 WG ID: Independent Submission Number_of_pages: 20 Abstract: The DNS SRV record has been specified in RFC 2052 and RFC 2782 for use in dynamic service discovery for a domain. These two RFCs did not clearly specify an IANA registry for the names of the services and their underlying protocols. This document clarifies RFC 2782 regarding the formation and use of the Service Prefix in the owner name of SRV records, based on the unified IANA "Service Name and Transport Protocol Port Number" registry and provides a few other corrections, clarifications, and usage recommendations. The IETF Secretariat. ----- End of forwarded message from IETF I-D Submission Tool ----- From eburger@standardstrack.com Fri Oct 22 10:49:05 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6131F3A6899 for ; Fri, 22 Oct 2010 10:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRggot4lVqM8 for ; Fri, 22 Oct 2010 10:49:02 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 507483A693B for ; Fri, 22 Oct 2010 10:49:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=fYbeXHobk6OhU7xlkGOr5BtjWiIiz9aSgxZAuZBZmxN1512aLqmBMgLVwRokPkgA7r7EG8fKmT4fJqMS2N/OGznG+gh+YuO7nO7EjF0LPNDKgF0hvAkBjEEuZSJzyoN9; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.134]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1P9Ll9-0007yw-TI; Fri, 22 Oct 2010 10:50:32 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-56-224988261; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: <201010212030.WAA26704@TR-Sys.de> Date: Fri, 22 Oct 2010 13:50:33 -0400 Message-Id: References: <201010212030.WAA26704@TR-Sys.de> To: =?iso-8859-1?Q?Alfred_H=CEnes?= X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-saintandre-xdash-considered-harmful-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 17:49:05 -0000 --Apple-Mail-56-224988261 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Rock and hard place. We want to encourage people to register these sorts of tags, whether for = email, SIP, or fugel-frotz. We want the bar to be very low. Back "in = the day," X-mumble was a free way of getting tags registered: you didn't = have to register them at all. That did cause all sorts of problems. So what do we do now? One of the value propositions for the Internet is = the ability to experiment and try new things with very low overhead. = That would indicate we should make these registries first-come, = first-served. On the other hand, if something gets an IANA tag, the = industry _assumes_ the IETF has blessed it. The IETF wants = interoperable, well-documented, open standards. The problem is, if we = even say "Informational RFC Required," that is a 4-year process, which = basically makes the registry irrelevant. I'm more in the free-love camp, let folks register what they want. = However, I may be in a minority on that point. On Oct 21, 2010, at 4:30 PM, Alfred H=CEnes wrote: > [[ shortening the Subject to make it more concise ]] >=20 >=20 > In the whole discussion so far I observe an overly strong focus > on email header field names, and consequentially some degree of > neglection of bad experiences with X-* names in other namespaces. > But if I understand the subject draft correctly, this was not the > primary, or exclusive target namespace for the considerations. >=20 > I strongly suspect the origin of the draft has been in > , > which relates the trouble of standardizing and deploying the > Internet media type "application/www-form-urlencoded" as a > successor for the media type "application/x-www-form-urlencoded" > once specified in the (now Historic[al]) RFC 1866. >=20 > The latter is deployed at large scale (no experiment!) and > cannot be registered (or have the registry entry updated) > under the present rules via a new Standards Track document, > where it is actually needed. >=20 > (Note that application/[x-]gzip is similar, but nobody tries to > include the non-X- form as a component of a revised Standard so far. > The much more severe trouble with compression etc. relates to the > matter of fact that the concept of Internet media types does not > allow structured nesting -- as with CMS content types --, and it > has always been controversial whether compression should be > regarded as some kind of [transfer] encoding, although it is > also used for storage. > But I go astray a bit; hence back to the primary topic ...) >=20 > I also note that the concept of P-* ("private") header field names > in SIP has also been declared a mis-invention now, because these > actually were intended for independent, interoperable implementations > targeting specific, yet kinda generic deployments. >=20 >=20 > So could we please widen the focus of the discussion accordingly? > Thanks in advance! >=20 >=20 > A quick observation and a rough thought based on it > (and I try to be neutral below regarding the namespace): >=20 > It looks like the seminal event for trouble with an X-* name is > when a *second* implementation starts to _generate_ that X-* name. >=20 > As long as only a single implementation of an application/protocol > generates the name, there are no interoperability concerns and > arguably the purpose is not ripe for standardization -- independent > of the possibility that there _might_ happen to be several > implementations _consuming_ the entity identified by that name. > But as soon as the idea behind such entity and name gains traction > and multiple implementations are wanted, that should qualify for a > 'normal' registration in the regular namespace. >=20 > So would it make sense to consider a change in the usage rules > for X-* names that STRONGLY RECOMMENDS to change track and register > a non-X-* name once more than one implementation considers making > active use of a particular X-* name ? >=20 > Adoption of such rules for specific namespaces should at least > help avoid trouble with new X-* names in the future, but it > cannot undo the sins of the past, of course. >=20 > As an ancillary measure, having a simple sub-registry (with FCFS > policy) for the respective parent namespace to help avoid name > collisions for X-* names might be considered, maybe with automatic > aging and removal after a given time span absent active renewal -- > IANA reportedly is able to generically support timed events in > registries. >=20 > Just a thought ... >=20 > Opinions? >=20 >=20 > Kind regards, > Alfred H=CEnes. >=20 > --=20 >=20 > = +------------------------+--------------------------------------------+ > | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. = | > | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 = | > | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de = | > = +------------------------+--------------------------------------------+ >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail-56-224988261 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPjCCBjow ggUioAMCAQICEQDFwzuU3TOCsDvWZ+r6wbrGMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNF UlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEwMDkw ODAwMDAwMFoXDTExMDkwODIzNTk1OVowgeExNTAzBgNVBAsTLENvbW9kbyBUcnVzdCBOZXR3b3Jr IC0gUEVSU09OQSBOT1QgVkFMSURBVEVEMUYwRAYDVQQLEz1UZXJtcyBhbmQgQ29uZGl0aW9ucyBv ZiB1c2U6IGh0dHA6Ly93d3cuY29tb2RvLm5ldC9yZXBvc2l0b3J5MR8wHQYDVQQLExYoYykyMDAz IENvbW9kbyBMaW1pdGVkMRQwEgYDVQQDEwtFcmljIEJ1cmdlcjEpMCcGCSqGSIb3DQEJARYaZWJ1 cmdlckBzdGFuZGFyZHN0cmFjay5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp 5q4WQSrk+PsAgBoNFtRYimhuVMrKuNxJ9dFoe+OTSNYFOwE97qg5mO50wrRWj0DVKXnYGLEOB/X+ pvZn49PszSapI46xK5wQGJ3jwgy8aLv3GYooBV/mOLIU00BpNlafvp3A0syQp3/4qLR+fyQRtvbM b6AYrJkw0eI1f4ZB8+kfLOjYxPCdvXqVcx8Ymsa/i4tlL+lj08Q10VCfBXQBJmipf4Cu0tjbF64L 6tgb3FALPuqItsmEInNawQYRPIcsOMTls3gcH0Owkq0YUtC451NqfAaKA3P1xUf2ksU1DGKi1q8C i5eCpLjAa9yriYY/3D3NPJyGhSogqwSD04PXAgMBAAGjggIcMIICGDAfBgNVHSMEGDAWgBSJgmd9 xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUCWAQ5WPoeXQtryw9E/fzwcQyJa8wDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEG CWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIB Fh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzCBpQYDVR0fBIGdMIGaMEygSqBIhkZodHRw Oi8vY3JsLmNvbW9kb2NhLmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5k RW1haWwuY3JsMEqgSKBGhkRodHRwOi8vY3JsLmNvbW9kby5uZXQvVVROLVVTRVJGaXJzdC1DbGll bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBsBggrBgEFBQcBAQRgMF4wNgYIKwYBBQUHMAKG Kmh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL1VUTkFBQUNsaWVudENBLmNydDAkBggrBgEFBQcwAYYY aHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVidXJnZXJAc3RhbmRhcmRzdHJh Y2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAJFOmlIRzkMxifxhdxt9ffqJNo0EbDWBS9M1qbRTyl cfQTsffZ3hxOroMQy7mJ8S/EwYGqFTK/SwrFDv5S+0PCuTsqLLYvpNQLjM0SSVlu0Opjv5Z3sRBm Q3iT/PGQwuXPZUghEv8KDjw2sEo/lujWVrvw1MnHybj5UWisux4QFpvExChYH8Y5ULtak7/5EKB3 3eDPof9HNbWGcrRS+7kfcrPscQLdHVCT+wT2ddXNN+gk4wlGfIxLlS3rWaChZKb+RS1zMCVFFiHo gE6HMCVrChfP7KT2EwKF5hEBbHQRqYEGlLO+pePQ3a9dhzra/d7d11wtmdyOIHSlgh8ITezgMYID /zCCA/sCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBM YWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDov L3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6wbrGMAkGBSsOAwIaBQCgggIPMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyMjE3NTAzM1owIwYJKoZI hvcNAQkEMRYEFLZxvUkdhQR9I+Q1Hkakcv/X8GlUMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQDFwzuU3TOCsDvWZ+r6wbrGMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMT LVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRAMXDO5TdM4Kw O9Zn6vrBusYwDQYJKoZIhvcNAQEBBQAEggEAqIPfxKNpHlDht/J4dfkGyY6tPKYZdcZUzFcSahCt D7cMuCqknWT+vyDWBnfrxZCEbActhAOCBI3enOom15GSDiEucO/atEJ5ABUNT5c7GU3dnPa1e7pG 3aKnbE1U1iHmJM3JGqEtxUXGI8/p6ygzJmEGBS3zgUs4UmVVtsSWitwpQBfzBCFiDS3PPwEKRlfa bonXCZxVfHi1WzXftTJO8Fp1LyT39Ke7TJ8nrh+i45R7H0aM9tUVXVkBMhlpwLUU+1JDHV3c22Km bULatmF/Zv8t99jq/uFylqF7JD0cxfBIOZawc8Er80Qvvi+QK4yMslauL2I0RiOFLNot1h7K0QAA AAAAAA== --Apple-Mail-56-224988261-- From Nicolas.Williams@oracle.com Fri Oct 22 11:02:34 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C7A13A68A4 for ; Fri, 22 Oct 2010 11:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jBdzMAar5a8 for ; Fri, 22 Oct 2010 11:02:33 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 76BFB3A6899 for ; Fri, 22 Oct 2010 11:02:33 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9MI4ATB022628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Oct 2010 18:04:11 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9MI49Ip020468; Fri, 22 Oct 2010 18:04:09 GMT Received: from abhmt021.oracle.com by acsmt353.oracle.com with ESMTP id 708091841287770623; Fri, 22 Oct 2010 11:03:43 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 22 Oct 2010 11:03:42 -0700 Date: Fri, 22 Oct 2010 13:03:38 -0500 From: Nicolas Williams To: Eric Burger Message-ID: <20101022180337.GV6536@oracle.com> References: <201010212030.WAA26704@TR-Sys.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: Alfred =?iso-8859-1?Q?H=CEnes?= , apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-saintandre-xdash-considered-harmful-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 18:02:34 -0000 On Fri, Oct 22, 2010 at 01:50:33PM -0400, Eric Burger wrote: > So what do we do now? One of the value propositions for the Internet > is the ability to experiment and try new things with very low > overhead. That would indicate we should make these registries > first-come, first-served. On the other hand, if something gets an > IANA tag, the industry _assumes_ the IETF has blessed it. The IETF > wants interoperable, well-documented, open standards. The problem is, > if we even say "Informational RFC Required," that is a 4-year process, > which basically makes the registry irrelevant. Registries can require documentation in forms other than RFCs. Although I'd prefer to have RFCs. For many X- headers the documentation would be simple enough (a few paragraphs) while others require significant documentation effort. > I'm more in the free-love camp, let folks register what they want. > However, I may be in a minority on that point. I'd be OK with that too, as long as there's a registry and registrations must contain a minimum of documentation as either of free-form text (no more than 500 words, say) or RFCs. I'd prefer something much more formal, if it were realistic (but it's not). Nico -- From duerst@it.aoyama.ac.jp Fri Oct 22 14:15:02 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE10D28C0E1 for ; Fri, 22 Oct 2010 14:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.801 X-Spam-Level: X-Spam-Status: No, score=-99.801 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTeUqeEBXXzn for ; Fri, 22 Oct 2010 14:14:59 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by core3.amsl.com (Postfix) with ESMTP id 7661D3A6922 for ; Fri, 22 Oct 2010 14:14:59 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id o9MLGX3I010771 for ; Sat, 23 Oct 2010 06:16:33 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 63a9_07b3_a51c86e0_de21_11df_9a28_001d096c5782; Sat, 23 Oct 2010 06:16:32 +0900 Received: from [IPv6:::1] ([133.2.210.1]:33045) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 23 Oct 2010 06:16:32 +0900 Message-ID: <4CC1FF1B.90506@it.aoyama.ac.jp> Date: Sat, 23 Oct 2010 06:16:11 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "apps-discuss@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "public-iri@w3.org" Subject: [apps-discuss] Protocol elements and presentation elements (was: Issue #5 of 3987bis) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 21:15:02 -0000 draft-ietf-iri-3987bis-02.txt currently contains the following text: >>>> URIs are used both as a protocol element (for transmission and processing by software) and also a presentation element (for display and handling by people who read, interpret, coin, or guess them). >>>> My personal understanding of the distinction between 'presentation elements' and 'protocol elements' was that this terminology has been used for different things, not for different roles of the same thing. As an example, one would speak of an IDN as a presentation element, whereas the punycode form was the corresponding protocol element. Or one would speak of an IRI as a presentation element when the URI (e.g. on HTTP) was the protocol element. (of course, an IRI can also be a protocol element) I'm wondering what other people think about changing the use to speak about different roles of the same thing. Have you thought about it in these terms all along anyway? Or is it a new use, but doesn't hurt? Or is it at least somewhat confusing? Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From alexey.melnikov@isode.com Sun Oct 24 12:33:55 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5F23A6902 for ; Sun, 24 Oct 2010 12:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.69 X-Spam-Level: X-Spam-Status: No, score=-102.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4VIJZ9LuoWj for ; Sun, 24 Oct 2010 12:33:46 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 9C1333A68F9 for ; Sun, 24 Oct 2010 12:33:44 -0700 (PDT) Received: from [192.168.20.2] ((unknown) [212.183.140.50]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 24 Oct 2010 20:35:24 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4CC48A66.20704@isode.com> Date: Sun, 24 Oct 2010 20:35:02 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Apps Discuss MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: alexey-melnikov-chairs@tools.ietf.org Subject: [apps-discuss] Alexey's Apps Area Activity Report for August-October 2010 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 19:33:55 -0000 Document Status and Progress: Active documents, my action: - draft-merrick-jms-uri-09 (Informational) - need to check the newly proposed IANA consideration section - draft-saintandre-tls-server-id-check (Proposed Standard) - need to review the latest version in order to decide if another IETF LC is needed - draft-hethmon-mcmurray-ftp-hosts (Proposed Standard) - need to finish chartering FTPEXT2 WG, which will work on this document - draft-ietf-tsvwg-iana-ports (BCP) - need to re-review the latest changes. TSVWG WGLC will happen in parallel. - draft-gudmundsson-dns-srv-iana-registry - need to re-review once draft-ietf-tsvwg-iana-ports is done. draft-gudmundsson-dnsext-srv-clarify - need to re-review once draft-ietf-tsvwg-iana-ports is done. - draft-denenberg-mods-etc-media-types (Proposed Standard) - need to help the author address DISCUSSes from IESG Active documents, waiting on others: - draft-burnett-pronunciation-alphabet-registry (None) - waiting for authors to address comments from a Language Tag expert reviewer (Doug Ewell). Assuming the document is dead. - draft-desruisseaux-caldav-sched (Proposed Standard) - performed AD review, new revision needed (since 2009-10-11!) - draft-holsten-about-uri-scheme-04 - performed AD review, new revision needed - draft-ietf-morg-list-specialuse-02 - performed AD review, new revision is needed - draft-zeilenga-ldap-dontusecopy (Proposed Standard) - approved by IESG, but a new revision is needed to address various editorial comments - draft-loreto-http-bidirectional-02 (Informational) - performed AD review, new revision is needed - draft-larmouth-oid-iri (Proposed Standard) - took over the document from Lisa, new revision needed Active documents in IETF LC or IESG review: draft-lundberg-app-tei-xml-06 (Informational) - in IESG review In RFC Editor's queue: - draft-cridland-acap-vendor-registry (Proposed Standard) - approved by IESG - draft-davis-u-langtag-ext (Informational) - draft-presuhn-rfc2482-historic (Informational) - in AUTH48 - draft-elie-nntp-list-additions (Proposed Standard) - in AUTH48 - draft-ietf-eai-frmwrk-4952bis (Infromational) - blocked on completion of various EAI documents - draft-nottingham-http-link-header (Proposed Standard) - in AUTH48. Getting closure on the last remaining issue about licensing for the IANA registry. - draft-roach-sip-http-subscribe (Proposed Standard) - in AUTH48, blocked on draft-nottingham-http-link-header - draft-daboo-srv-caldav (Proposed Standard) - blocked on draft-saintandre-tls-server-id-check - draft-daboo-srv-email (Proposed Standard) - blocked on draft-saintandre-tls-server-id-check - draft-ietf-vcarddav-carddav (Proposed Standard) - blocked on a normative reference (vCard 4.0) - draft-ietf-yam-rfc1652bis (Standard) - temporarily blocked on 5321bis/5322bis Published as RFCs: - RFC 5955 (Infromational) - RFC 5965 (Proposed Standard) - RFC 5987 (Proposed Standard) - RFC 5995 (Proposed Standard) - RFC 6008 (Proposed Standard) - RFC 6019 (Proposed Standard) - replacement for RFC 4049 - RFC 5983 (Experimental) - RFC 6009 (Proposed Standard) - RFC 6068 (Proposed Standard) List of DISCUSSes I am currently holding: Really Old: draft-ietf-dhc-dhcpv4-vendor-message-01.txt - also took over Pasi's DISCUSS draft-ietf-dhc-dhcpv6-vendor-message-01.txt draft-ietf-mediactrl-ivr-control-package-08.txt draft-ietf-mediactrl-mixer-control-package-11.txt Old: draft-juskevicius-datatracker-wgdocstate-reqts-07.txt draft-ogud-iana-protocol-maintenance-words-03.txt draft-ietf-pkix-certimage-10.txt draft-ietf-avt-forward-shifted-red-06.txt New or recently updated (last 4 weeks): draft-ietf-mediactrl-sip-control-framework-12.txt draft-ietf-sip-session-policy-framework-07.txt draft-ietf-mext-nemo-pd-06.txt draft-ietf-fecframe-framework-10.txt Next IESG telechat (Oct 28th): draft-ietf-geopriv-held-identity-extensions-05.txt draft-ietf-netconf-with-defaults-12.txt draft-ietf-ccamp-lsp-hierarchy-bis-08.txt draft-ietf-avt-rapid-acquisition-for-rtp-16.txt Cleared DISCUSSes: draft-ietf-keyprov-symmetrickeyformat-11.txt draft-ietf-keyprov-dskpp-14.txt draft-ietf-keyprov-pskc-09.txt draft-ietf-enum-enumservices-guide-20.txt draft-drage-sipping-service-identification-03.txt draft-gennai-smime-cnipa-pec-06.txt draft-ietf-mext-flow-binding-06.txt draft-ietf-sipping-config-framework-18.txt Other activities/actions: Done: - draft-ietf-calsify-rfc2447bis-11 (my own document) - approved for publication - draft-ietf-kitten-digest-to-historic (my own document) - updated, waiting for IETF LC - issued 2nd IETF Last Call for draft-nottingham-http-link-header - some IANA related changes in AUTH48 - MIME type review of image/ktx - HTTPBIS WG rechartered - APPSAWG WG chartered Ongoing: - verified/rejected several errata items (some of them incorrectly) - agreed to help with "X- prefixes considered harmful" document (together with Peter) - lots of discussion on HYBI WG management with HYBI chairs, editors, WG Secretary [mostly in August] - chartering FTPEXT2 and URNBIS WG My action: - draft-ietf-sieve-external-lists (my own document) - need to address the 2 remaining issues. Thanks to Barry Leiba for helping out with the document editing. - draft-melnikov-imap-postaddress (my own document) - resurrected based on some private feedback. Need to revise to address some private comments from Arnt Gulbrandsen. - draft-ietf-sieve-convert (my own document) - need to be updated to address comments from Maastricht - SIP Sieve notify (my own document) - I need to answer to RAI review. - Volunteered to write an IESG statement on reviewing MIME type registrations from other SDOs (with no draft). - Need to review OAuth document regarding possible reuse of SCRAM - Need to post 4954bis (SMTP AUTH) in order to start moving it to Draft Standard Waiting for others: - Suggestion to move LMTP to Standard Track (Ned Freed agreed to update the document, then responded that John Myers is interested to do this himself. Chris Newman agreed to shepherd it) - Suggestion to convert MIME BNF to ABNF and publish as a separate draft (Ned Freed agreed to do this) WG status: - DECADE - steady progress on requirements - EAI - framework document done, discussion about EAI message format, SMTP extension and SMTP DSN documents - HTTPBIS - steady progress - working through issues on 2616bis. WGLC for the document describing use of Content-Disposition in HTTP just finished. - HYBI - draft-ietf-hybi-thewebsocketprotocol-03 posted. Discussions on the need for versioning (among many other things). - MARF - some discussions on DKIM reporting extension - MORG - quiet - Sieve - some recent discussions on External List document, use of vacation autoreplies for notifications (3 documents) - YAM - suspended, pending resolution to the 3 step/2 step maturity ladder discussion From fluffy@cisco.com Sun Oct 24 15:47:19 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E09E3A6910 for ; Sun, 24 Oct 2010 15:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.222 X-Spam-Level: X-Spam-Status: No, score=-110.222 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+ijO5GPmxEX for ; Sun, 24 Oct 2010 15:47:17 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DF3483A6452 for ; Sun, 24 Oct 2010 15:47:17 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAENUxEyrR7Hu/2dsb2JhbAChXnGedJs1hUgEhFSFeYMG X-IronPort-AV: E=Sophos;i="4.58,233,1286150400"; d="scan'208";a="609154073" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 24 Oct 2010 22:49:01 +0000 Received: from [192.168.4.4] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9OMmxMV027814; Sun, 24 Oct 2010 22:48:59 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F1490AE0@SISPE7MB1.commscope.com> Date: Sun, 24 Oct 2010 16:49:01 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2D0EB56D-F5DF-4BDB-A9AD-16A373BE7CB9@cisco.com> References: <8B0A9FCBB9832F43971E38010638454F03F1490AE0@SISPE7MB1.commscope.com> To: Martin Thomson X-Mailer: Apple Mail (2.1081) Cc: "Apps-Discuss@ietf.org" Subject: Re: [apps-discuss] Draft on representing values of sensors in JSON (draft-jennings-senml) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 22:47:19 -0000 Thanks for the great comments ... more inline. Please have a look at the = one thing below on time representation - really need your input on that.=20= Diff of new draft is at: = http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-jennings-senml.dif= f.html On Sep 21, 2010, at 5:34 PM, Thomson, Martin wrote: >> I'd love to get some feedback on >>=20 >> http://www.ietf.org/id/draft-jennings-senml-03.txt >=20 > Hi Cullen, >=20 > The Unified Code for Units of Measure might be of interest to you. = This is based on ISO 2599 and ANSA X3.50. It might save you the need = for a new registry. >=20 > http://unitsofmeasure.org/ >=20 > I have my own reservations about the grammar (too many special cases), = but it seems a shame to waste all the good effort. Interesting I did not know about that one but I have looked a bunch of = these. They mostly seem around covering the way humans not machine would = want to use units and I wonder how one would get interoperability if = using them. I also had problems with the process to add new things to = some of these existing units lists. I finally gave up and went with the = create a new registry approach. That allows us to add things that are = not really units in the traditional sense but turn out to be really = useful in telling the system reading the JSON object know what to do.=20 >=20 >=20 > You also have a TODO on accuracy/confidence. Additional optional = attributes seem appropriate: in metrology, it's commonplace to describe = a confidence interval. I somehow suspected you might have a well informed opinion on this = topic. When I wrote TODO, I was hoping it was something someone else = would Do. Thank you for the text. It's been inserted.=20 >=20 > Measurement quality attributes can be added: >=20 > unc: the uncertainty in the measurement, that uses the same units as = the base; if absent, the value is unknown (i.e., don't assume that this = is zero) > c: the confidence of the measurement, as a percentage; if absent, you = can pick a default value >=20 > An alternative is to report RMS error, which is a common measure of = quality where there are multiple samples taken, but only a mean value = reported: >=20 > rms: the RMS error in the measurements; if absent: unknown > num: the number of samples taken; if absent: assume either a very = large number such that RMS =3D~ standard deviation, or assume one (pick = one) I asked around on what would be more useful to receive the unc/c or the = rms/num and seemed most people preferred the unc approach for this = stuff. >=20 > In a lot of sensors, uncertainty and confidence are known, but = discrete observations do not necessarily carry specific values for = these. Instead this is a known characteristic of the device. Thus, it = could make sense to carry a base value (a base uncertainty). Within the = format you describe, you will need to associate a base value with each = sensor. >=20 > { q: { [ n: "foo", unc: 0.43, c: 90 ] } } >=20 will think about this one ... >=20 > I don't see any value in providing a valid time interval. This is = going to either be based on predictions that use measured values, or = it's going to be virtually impossible to predict. Any case where a = measurand is time-varying is going to be known by the recipient for that = recipient to do anything reasonable with the data. The problem is more around detecting a dead sensor. Take a power meter = of some sort that is not polled but pushes data - some report every = second, some every minute, some every day, some every week, some = whenever it changes by some threshold not at least once every 10 = minutes. The sensor knows this update schedule but the system receive = the data does not. The receiver would like to be able to indicate when = the data is so stale it should no longer be used. I've been having a = hard time figuring out how to describe this in the draft but I think = some idea of maximum update interval is needed. I agree the sensor = trying to do something like predict how long the temperature would stay = the same for or how long before a location sensor moves sounds pretty = unlikely. =20 >=20 >=20 > Is the intent for the sensors to be labelled with a globally unique = identifier? Yes=20 > If so, why? I would have assumed that the identified source of data = would provide some amount of disambiguation. Clearly on could make it work either way. Its pretty easy to make a = unique name for most sensors - if nothing else one can use the MAC from = where the sensor meets the IP network or a UUID. Adding it later is much = harder and one just gets into all the confusion about if something is a = new measurement or the same measurement reported by multiple paths. = Trying to do broad sensor fusion projects really convinced me of the = value of having a unique identifier.=20 >=20 >=20 > You have a lot of questions. Is it really that much more of a burden = for a constrained device to produce an RFC 3339 date+time? Certainly, = the size isn't going to be a significant burden. Maybe you could have = 'bt' include this value, and 't' can be left as a delta. =20 So theres no way to do timezone on a small device but yes 3339 format is = probably not too big a deal. Leap seconds might turn out to be a bit of = a problem. But is it any easier or better? It seems like this work out = better as long as you assume the end system converts to something human = readable. Arguments either way? The 3339 format looked good for human = readability but just looked like for more of a hassle for any system = producing the or consuming it.=20 > Certainly, I'd like to see a resolution of better than seconds. = Nanosecond resolution would be handy for something like location ;) So I moved this to a floating point double. But that only gives = microseconds precision over the next 100 years or so. How badly do we = need nanoseconds? Aren't nanoseconds times often the result of a sensor = reading and relative? So we could easily say that a device had measured = the reflection delay up a cat 5 cable and it was 72.3 nano seconds but = saying that measurement was made at exactly 3 ns after midnight today is = something we could not do. Thoughts on what is needed here? If we really = do need this, then what I would propose is we have two fields one is the = t (bt) which just gives integer number of seconds and a second sub = second field (perhaps called "st") that has a double float = representation of time that is added to the integer time. This would = give us pico second time precision.=20 >=20 >=20 > (Nit: Your examples have trailing commas. The JSON syntax doesn't = allow this.)'' oops - all example pass JSONLint now >=20 > --Martin >=20 > p.s., I like this: >=20 > ... The number of significant digits in any > measurement is not relevant, so a reading of 1.1 has exactly the = same > semantic meaning as 1.10. ... >=20 From Martin.Thomson@andrew.com Sun Oct 24 16:54:40 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98DAB3A691B for ; Sun, 24 Oct 2010 16:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.883 X-Spam-Level: X-Spam-Status: No, score=-2.883 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHwl4MOUXpho for ; Sun, 24 Oct 2010 16:54:39 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 26D263A67D6 for ; Sun, 24 Oct 2010 16:54:35 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:14389 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S449671Ab0JXX4T (ORCPT ); Sun, 24 Oct 2010 18:56:19 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Sun, 24 Oct 2010 18:56:19 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Mon, 25 Oct 2010 07:56:15 +0800 From: "Thomson, Martin" To: Cullen Jennings Date: Mon, 25 Oct 2010 07:56:12 +0800 Thread-Topic: [apps-discuss] Draft on representing values of sensors in JSON (draft-jennings-senml) Thread-Index: ActzzalUTl131hrsT8Kw5/+zRXHGlQAA5JkA Message-ID: <8B0A9FCBB9832F43971E38010638454F03F31EAD05@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03F1490AE0@SISPE7MB1.commscope.com> <2D0EB56D-F5DF-4BDB-A9AD-16A373BE7CB9@cisco.com> In-Reply-To: <2D0EB56D-F5DF-4BDB-A9AD-16A373BE7CB9@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "Apps-Discuss@ietf.org" Subject: Re: [apps-discuss] Draft on representing values of sensors in JSON (draft-jennings-senml) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 23:54:40 -0000 SGkgQ3VsbGVuLA0KDQpHb29kIHRvIHNlZSB0aGF0IHlvdSdyZSBtYWtpbmcgcHJvZ3Jlc3MgOikN Cg0KQSBmZXcgZm9sbG93LXVwIGNvbW1lbnRzIGJlbG93Lg0KDQpPbiAyMDEwLTEwLTI1IGF0IDA5 OjQ5OjAxLCBDdWxsZW4gSmVubmluZ3Mgd3JvdGU6DQo+IA0KPiA+ICBodHRwOi8vdW5pdHNvZm1l YXN1cmUub3JnLw0KPiAuLi4NCj4gSSAgd29uZGVyIGhvdyBvbmUgd291bGQgZ2V0IGludGVyb3Bl cmFiaWxpdHkgaWYgdXNpbmcgdGhlbS4gDQoNClRoYXQncyB0aGUgY2hhbGxlbmdlLiAgVGhlIGdy YW1tYXIgZG9lc24ndCBzZWVtIGNvbmR1Y2l2ZSB0byBhIHNpbXBsZSBpbXBsZW1lbnRhdGlvbi4g IFRoYXQncyBuZXZlciBnb29kLiAgVGhlIHByb2Nlc3MgZm9yIG5ldyByZWdpc3RyYXRpb25zIGlz bid0IHdlbGwgZW5vdWdoIHVuZGVyc3Rvb2QgZm9yIG1lIGVpdGhlci4NCg0KT24gdGhlIG90aGVy IGhhbmQsIGl0IG1pZ2h0IGJlIHdvcnRod2hpbGUgZG9pbmcgdGhlIHVuaXQgdGhpbmcgcHJvcGVy bHkuICBBIGZvcm1hbCBncmFtbWFyIGlzIHRoZSBuZXh0IHN0ZXAgKGFuZCBub3QgYSBiYWQgaWRl YSBpbiBteSBvcGluaW9uKSwgdGhlbiB0aGVyZSBpcyB0aGUgcXVlc3Rpb24gb2Ygc3RhbmRhcmQg cHJlZml4ZXMgKGssIE0sIEcsIFQsIFAsIC4uLiBtLCDOvCwgcCwgZiwgLi4uKSwgYW5kIGtnIGZv dWxzIHRoYXQgdXAgYSBsaXR0bGUuDQoNCj4gPiBJIGRvbid0IHNlZSBhbnkgdmFsdWUgaW4gcHJv dmlkaW5nIGEgdmFsaWQgdGltZSBpbnRlcnZhbC4NCj4gDQo+IFRoZSBzZW5zb3Iga25vd3MgdGhp cyB1cGRhdGUgc2NoZWR1bGUgYnV0IHRoZSBzeXN0ZW0gcmVjZWl2ZSB0aGUgZGF0YSBkb2VzIG5v dC4gDQoNClRoZSBxdWVzdGlvbiBpcyBob3cgbXVjaCBhIHJlY2VpdmVyIGNhbiBiZSBhc3N1bWVk IHRvIGtub3cgYWJvdXQgYSBzZW5zb3IuICBJIGltYWdpbmUgdGhhdCBpbiBtYW55IGNpcmN1bXN0 YW5jZXMsIHRoZSB1bmlxdWUgaWQgd2lsbCBiZSBzdWZmaWNpZW50IHRvIGNvbnZleSBhIHdlYWx0 aCBvZiBpbmZvcm1hdGlvbiB0aGF0IHlvdSB3b3VsZG4ndCBldmVuIGJvdGhlciBmaW5kaW5nIGNv ZGVwb2ludHMgZm9yOiBtYW51ZmFjdHVyZXIsIHVuY2VydGFpbnR5IGNoYXJhY3RlcmlzdGljcywg cmVwb3J0aW5nIGludGVydmFsLCBhbmQgc28gZm9ydGguICBZb3UgaGF2ZSB0byBhbGxvdyBmb3Ig YSByYW5nZSBvZiBjb25maWd1cmF0aW9ucy4NCg0KSSdtIGFsd2F5cyBsZWVyeSBvZiBhdHRlbXB0 cyB0byBvdmVybG9hZCBzZW1hbnRpY3MuICBUaGUgZGlyZWN0IGFwcHJvYWNoIHRoYXQgeW91IHVz ZSBpcyBnb29kOiBuZXh0IHJlcG9ydCBpbiA8dXQ+IHNlY29uZHMuDQoNCj4gPiBJJ2QgbGlrZSB0 byBzZWUgYSByZXNvbHV0aW9uIG9mIGJldHRlciB0aGFuIHNlY29uZHMuDQo+DQo+IFNvIEkgbW92 ZWQgdGhpcyB0byBhIGZsb2F0aW5nIHBvaW50IGRvdWJsZS4gQnV0IHRoYXQgb25seSBnaXZlcw0K PiBtaWNyb3NlY29uZHMgcHJlY2lzaW9uIG92ZXIgdGhlIG5leHQgMTAwIHllYXJzIG9yIHNvLiBI b3cgYmFkbHkgZG8gd2UNCj4gbmVlZCBuYW5vc2Vjb25kcz8NCg0KSXQncyBhIGJpdCBjcnVkZSwg YnV0IGlzIHNob3VsZCBiZSBwb3NzaWJsZSB0byBtYWtlIGEgcHNldWRvLXNlbnNvciB0aGF0IHJl cG9ydHMgYSB0aW1lIGRlbHRhIHdoZXJlIGJldHRlciBwcmVjaXNpb24gaXMgcmVxdWlyZWQuDQoN Cj4gQXJlbid0IG5hbm9zZWNvbmRzIHRpbWVzIG9mdGVuIHRoZSByZXN1bHQgb2YgYSBzZW5zb3IN Cj4gcmVhZGluZyBhbmQgcmVsYXRpdmU/IA0KDQpUaGF0IGlzIG1vcmUgbGlrZWx5LiAgRm9yIG1l YXN1cmVtZW50cyBvZiB0aGF0IHNpemUsIGEgZG91YmxlIGhhcyBwbGVudHkgb2YgZnJlZSBiaXRz Lg0KDQotLU1hcnRpbg0K From tony@att.com Sun Oct 24 18:12:54 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25C1A3A67FA for ; Sun, 24 Oct 2010 18:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.403 X-Spam-Level: X-Spam-Status: No, score=-106.403 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVh7MbUMMM9o for ; Sun, 24 Oct 2010 18:12:24 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id E73983A677D for ; Sun, 24 Oct 2010 18:12:23 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-5.tower-161.messagelabs.com!1287969246!17102554!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 30745 invoked from network); 25 Oct 2010 01:14:07 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-5.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 25 Oct 2010 01:14:07 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o9P1ENT8015168 for ; Sun, 24 Oct 2010 21:14:23 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o9P1EHCC015130 for ; Sun, 24 Oct 2010 21:14:18 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o9P1DxrI000829 for ; Sun, 24 Oct 2010 21:13:59 -0400 Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o9P1DvHg000812 for ; Sun, 24 Oct 2010 21:13:57 -0400 Received: from [135.70.41.75] (vpn-135-70-41-75.vpn.west.att.com[135.70.41.75]) by maillennium.att.com (mailgw1) with ESMTP id <20101025011356gw100ei17de> (Authid: tony); Mon, 25 Oct 2010 01:13:56 +0000 X-Originating-IP: [135.70.41.75] Message-ID: <4CC4D9D3.2060003@att.com> Date: Sun, 24 Oct 2010 21:13:55 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <201010212030.WAA26704@TR-Sys.de> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060203000007020401020606" Subject: Re: [apps-discuss] draft-saintandre-xdash-considered-harmful-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 01:12:54 -0000 This is a multi-part message in MIME format. --------------060203000007020401020606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable The vendor and personal namespaces used for media types have an=20 extremely low overhead as well and are pretty darn close to your "free=20 love" level. I think adding such namespaces for headers would be cheap, easy to do,=20 and would solve many of the problems people see with X-. Thoughts? Tony Hansen tony@att.com On 10/22/2010 1:50 PM, Eric Burger wrote: > Rock and hard place. > > We want to encourage people to register these sorts of tags, whether fo= r email, SIP, or fugel-frotz. We want the bar to be very low. Back "in = the day," X-mumble was a free way of getting tags registered: you didn't = have to register them at all. That did cause all sorts of problems. > > So what do we do now? One of the value propositions for the Internet i= s the ability to experiment and try new things with very low overhead. T= hat would indicate we should make these registries first-come, first-serv= ed. On the other hand, if something gets an IANA tag, the industry _assu= mes_ the IETF has blessed it. The IETF wants interoperable, well-documen= ted, open standards. The problem is, if we even say "Informational RFC R= equired," that is a 4-year process, which basically makes the registry ir= relevant. > > I'm more in the free-love camp, let folks register what they want. How= ever, I may be in a minority on that point. > > On Oct 21, 2010, at 4:30 PM, Alfred H=CEnes wrote: > > =20 >> [[ shortening the Subject to make it more concise ]] >> >> >> In the whole discussion so far I observe an overly strong focus >> on email header field names, and consequentially some degree of >> neglection of bad experiences with X-* names in other namespaces. >> But if I understand the subject draft correctly, this was not the >> primary, or exclusive target namespace for the considerations. >> >> I strongly suspect the origin of the draft has been in >> , >> which relates the trouble of standardizing and deploying the >> Internet media type "application/www-form-urlencoded" as a >> successor for the media type "application/x-www-form-urlencoded" >> once specified in the (now Historic[al]) RFC 1866. >> >> The latter is deployed at large scale (no experiment!) and >> cannot be registered (or have the registry entry updated) >> under the present rules via a new Standards Track document, >> where it is actually needed. >> >> (Note that application/[x-]gzip is similar, but nobody tries to >> include the non-X- form as a component of a revised Standard so far. >> The much more severe trouble with compression etc. relates to the >> matter of fact that the concept of Internet media types does not >> allow structured nesting -- as with CMS content types --, and it >> has always been controversial whether compression should be >> regarded as some kind of [transfer] encoding, although it is >> also used for storage. >> But I go astray a bit; hence back to the primary topic ...) >> >> I also note that the concept of P-* ("private") header field names >> in SIP has also been declared a mis-invention now, because these >> actually were intended for independent, interoperable implementations >> targeting specific, yet kinda generic deployments. >> >> >> So could we please widen the focus of the discussion accordingly? >> Thanks in advance! >> >> >> A quick observation and a rough thought based on it >> (and I try to be neutral below regarding the namespace): >> >> It looks like the seminal event for trouble with an X-* name is >> when a *second* implementation starts to _generate_ that X-* name. >> >> As long as only a single implementation of an application/protocol >> generates the name, there are no interoperability concerns and >> arguably the purpose is not ripe for standardization -- independent >> of the possibility that there _might_ happen to be several >> implementations _consuming_ the entity identified by that name. >> But as soon as the idea behind such entity and name gains traction >> and multiple implementations are wanted, that should qualify for a >> 'normal' registration in the regular namespace. >> >> So would it make sense to consider a change in the usage rules >> for X-* names that STRONGLY RECOMMENDS to change track and register >> a non-X-* name once more than one implementation considers making >> active use of a particular X-* name ? >> >> Adoption of such rules for specific namespaces should at least >> help avoid trouble with new X-* names in the future, but it >> cannot undo the sins of the past, of course. >> >> As an ancillary measure, having a simple sub-registry (with FCFS >> policy) for the respective parent namespace to help avoid name >> collisions for X-* names might be considered, maybe with automatic >> aging and removal after a given time span absent active renewal -- >> IANA reportedly is able to generically support timed events in >> registries. >> >> Just a thought ... >> >> Opinions? >> >> >> Kind regards, >> Alfred H=CEnes. >> >> --=20 >> >> +------------------------+--------------------------------------------= + >> | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. = | >> | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 = | >> | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de = | >> +------------------------+--------------------------------------------= + >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> =20 > =20 > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > =20 --------------060203000007020401020606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The vendor and personal namespaces used for media types have an extremely low overhead as well and are pretty darn close to your "free love" level.

I think adding such namespaces for headers would be cheap, easy to do, and would solve many of the problems people see with X-.

Thoughts?

    Tony Hansen
    tony@att.com

On 10/22/2010 1:50 PM, Eric Burger wrote: 
Rock and hard place.

We want to encourage people to register these sorts of tags, whether for email, SIP, or fugel-frotz.  We want the bar to be very low.  Back "in the day," X-mumble was a free way of getting tags registered: you didn't have to register them at all.  That did cause all sorts of problems.

So what do we do now?  One of the value propositions for the Internet is the ability to experiment and try new things with very low overhead.  That would indicate we should make these registries first-come, first-served.  On the other hand, if something gets an IANA tag, the industry _assumes_ the IETF has blessed it.  The IETF wants interoperable, well-documented, open standards.  The problem is, if we even say "Informational RFC Required," that is a 4-year process, which basically makes the registry irrelevant.

I'm more in the free-love camp, let folks register what they want.  However, I may be in a minority on that point.

On Oct 21, 2010, at 4:30 PM, Alfred HÎnes wrote:

  
[[ shortening the Subject to make it more concise ]]


In the whole discussion so far I observe an overly strong focus
on email header field names, and consequentially some degree of
neglection of bad experiences with X-* names in other namespaces.
But if I understand the subject draft correctly, this was not the
primary, or exclusive target namespace for the considerations.

I strongly suspect the origin of the draft has been in
   <http://tools.ietf.org/html/draft-hoehrmann-urlencoded-01> ,
which relates the trouble of standardizing and deploying the
Internet media type  "application/www-form-urlencoded"  as a
successor for the media type  "application/x-www-form-urlencoded"
once specified in the (now Historic[al]) RFC 1866.

The latter is deployed at large scale (no experiment!) and
cannot be registered (or have the registry entry updated)
under the present rules via a new Standards Track document,
where it is actually needed.

(Note that application/[x-]gzip is similar, but nobody tries to
include the non-X- form as a component of a revised Standard so far.
The much more severe trouble with compression etc. relates to the
matter of fact that the concept of Internet media types does not
allow structured nesting -- as with CMS content types --, and it
has always been controversial whether compression should be
regarded as some kind of [transfer] encoding, although it is
also used for storage.
But I go astray a bit; hence back to the primary topic ...)

I also note that the concept of P-* ("private") header field names
in SIP has also been declared a mis-invention now, because these
actually were intended for independent, interoperable implementations
targeting specific, yet kinda generic deployments.


So could we please widen the focus of the discussion accordingly?
Thanks in advance!


A quick observation and a rough thought based on it
(and I try to be neutral below regarding the namespace):

It looks like the seminal event for trouble with an X-* name is
when a *second* implementation starts to _generate_ that  X-* name.

As long as only a single implementation of an application/protocol
generates the name, there are no interoperability concerns and
arguably the purpose is not ripe for standardization -- independent
of the possibility that there _might_ happen to be several
implementations _consuming_ the entity identified by that name.
But as soon as the idea behind such entity and name gains traction
and multiple implementations are wanted, that should qualify for a
'normal' registration in the regular namespace.

So would it make sense to consider a change in the usage rules
for X-* names that STRONGLY RECOMMENDS to change track and register
a non-X-* name once more than one implementation considers making
active use of a particular X-* name ?

Adoption of such rules for specific namespaces should at least
help avoid trouble with new X-* names in the future, but it
cannot undo the sins of the past, of course.

As an ancillary measure, having a simple sub-registry (with FCFS
policy) for the respective parent namespace to help avoid name
collisions for X-* names might be considered, maybe with automatic
aging and removal after a given time span absent active renewal --
IANA reportedly is able to generically support timed events in
registries.

Just a thought ...

Opinions?


Kind regards,
 Alfred HÎnes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
    
  

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
--------------060203000007020401020606-- From john-ietf@jck.com Sun Oct 24 23:56:49 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B9783A680A for ; Sun, 24 Oct 2010 23:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uV+rxhTxvkQv for ; Sun, 24 Oct 2010 23:56:48 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 40B293A6936 for ; Sun, 24 Oct 2010 23:56:48 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PAH0o-000CvU-Sq; Mon, 25 Oct 2010 02:58:31 -0400 Date: Mon, 25 Oct 2010 02:58:30 -0400 From: John C Klensin To: Tony Hansen , apps-discuss@ietf.org Message-ID: <0077AC96FF0947F4AE87DFA7@PST.JCK.COM> In-Reply-To: <4CC4D9D3.2060003@att.com> References: <201010212030.WAA26704@TR-Sys.de> <4CC4D9D3.2060003@att.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [apps-discuss] draft-saintandre-xdash-considered-harmful-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 06:56:49 -0000 --On Sunday, October 24, 2010 21:13 -0400 Tony Hansen wrote: > The vendor and personal namespaces used for media types have > an extremely low overhead as well and are pretty darn close to > your "free love" level. Of course, they depend on structuring the type name. Optional-field in RFC 5322 Section 3.6.8 does not anticipate such structuring, but does not prohibit it either (nor does it prohibit "X-"; it just doesn't give it any special interpretation). I don't believe I've seen enough use of, e.g., header field names with periods in them to prevent our making that sort of structuring now. But it is a little late in the game and I wonder how long such a convention would require to be widely deployed and recognized. > I think adding such namespaces for headers would be cheap, > easy to do, and would solve many of the problems people see > with X-. > > Thoughts? For the reasons above, I question "cheap" and "easy to do", although it certainly strikes me as a good idea. john From eburger@standardstrack.com Mon Oct 25 08:48:50 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D40413A689B for ; Mon, 25 Oct 2010 08:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.451 X-Spam-Level: X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IttA73wZwjDk for ; Mon, 25 Oct 2010 08:48:49 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id B425E3A6A32 for ; Mon, 25 Oct 2010 08:48:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:From:Mime-Version:Content-Type:Subject:Date:In-Reply-To:To:References:Message-Id:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=LRYD+CKtBBni2HBlmkb3lIjnfwWbk7GSWWUnBtGJEcLSg/InTeHSqKjdzqZ3aIjU/FHMQ3L3FXfXlc/OFqwcObQomnjTCZtT3BEZFzCNSmEy+/Lme2kT5iUPZ6dG8IF0; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.134]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PAPJ3-0002L8-O5 for apps-discuss@ietf.org; Mon, 25 Oct 2010 08:49:54 -0700 From: Eric Burger Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-6-476985890; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 25 Oct 2010 11:50:31 -0400 In-Reply-To: <0077AC96FF0947F4AE87DFA7@PST.JCK.COM> To: Discuss Apps IETF References: <201010212030.WAA26704@TR-Sys.de> <4CC4D9D3.2060003@att.com> <0077AC96FF0947F4AE87DFA7@PST.JCK.COM> Message-Id: <3F3180D3-2925-47E9-92FD-3ED11FAD6D34@standardstrack.com> X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [apps-discuss] draft-saintandre-xdash-considered-harmful-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 15:48:50 -0000 --Apple-Mail-6-476985890 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Well... Is not the problem that a proprietary extension becomes = standard? What is the difference between X-mumble and Eric-mumble? Does private = namespaces really help the fundamental problem? On Oct 25, 2010, at 2:58 AM, John C Klensin wrote: >=20 >=20 > --On Sunday, October 24, 2010 21:13 -0400 Tony Hansen > wrote: >=20 >> The vendor and personal namespaces used for media types have >> an extremely low overhead as well and are pretty darn close to >> your "free love" level. >=20 > Of course, they depend on structuring the type name. > Optional-field in RFC 5322 Section 3.6.8 does not anticipate > such structuring, but does not prohibit it either (nor does it > prohibit "X-"; it just doesn't give it any special > interpretation). I don't believe I've seen enough use of, e.g., > header field names with periods in them to prevent our making > that sort of structuring now. But it is a little late in the > game and I wonder how long such a convention would require to be > widely deployed and recognized. >=20 >> I think adding such namespaces for headers would be cheap, >> easy to do, and would solve many of the problems people see >> with X-. >>=20 >> Thoughts? >=20 > For the reasons above, I question "cheap" and "easy to do", > although it certainly strikes me as a good idea. >=20 > john >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail-6-476985890 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPjCCBjow ggUioAMCAQICEQDFwzuU3TOCsDvWZ+r6wbrGMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNF UlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UE AxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTEwMDkw ODAwMDAwMFoXDTExMDkwODIzNTk1OVowgeExNTAzBgNVBAsTLENvbW9kbyBUcnVzdCBOZXR3b3Jr IC0gUEVSU09OQSBOT1QgVkFMSURBVEVEMUYwRAYDVQQLEz1UZXJtcyBhbmQgQ29uZGl0aW9ucyBv ZiB1c2U6IGh0dHA6Ly93d3cuY29tb2RvLm5ldC9yZXBvc2l0b3J5MR8wHQYDVQQLExYoYykyMDAz IENvbW9kbyBMaW1pdGVkMRQwEgYDVQQDEwtFcmljIEJ1cmdlcjEpMCcGCSqGSIb3DQEJARYaZWJ1 cmdlckBzdGFuZGFyZHN0cmFjay5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp 5q4WQSrk+PsAgBoNFtRYimhuVMrKuNxJ9dFoe+OTSNYFOwE97qg5mO50wrRWj0DVKXnYGLEOB/X+ pvZn49PszSapI46xK5wQGJ3jwgy8aLv3GYooBV/mOLIU00BpNlafvp3A0syQp3/4qLR+fyQRtvbM b6AYrJkw0eI1f4ZB8+kfLOjYxPCdvXqVcx8Ymsa/i4tlL+lj08Q10VCfBXQBJmipf4Cu0tjbF64L 6tgb3FALPuqItsmEInNawQYRPIcsOMTls3gcH0Owkq0YUtC451NqfAaKA3P1xUf2ksU1DGKi1q8C i5eCpLjAa9yriYY/3D3NPJyGhSogqwSD04PXAgMBAAGjggIcMIICGDAfBgNVHSMEGDAWgBSJgmd9 xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUCWAQ5WPoeXQtryw9E/fzwcQyJa8wDgYDVR0PAQH/ BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEG CWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIB Fh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzCBpQYDVR0fBIGdMIGaMEygSqBIhkZodHRw Oi8vY3JsLmNvbW9kb2NhLmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5k RW1haWwuY3JsMEqgSKBGhkRodHRwOi8vY3JsLmNvbW9kby5uZXQvVVROLVVTRVJGaXJzdC1DbGll bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBsBggrBgEFBQcBAQRgMF4wNgYIKwYBBQUHMAKG Kmh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL1VUTkFBQUNsaWVudENBLmNydDAkBggrBgEFBQcwAYYY aHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVidXJnZXJAc3RhbmRhcmRzdHJh Y2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAJFOmlIRzkMxifxhdxt9ffqJNo0EbDWBS9M1qbRTyl cfQTsffZ3hxOroMQy7mJ8S/EwYGqFTK/SwrFDv5S+0PCuTsqLLYvpNQLjM0SSVlu0Opjv5Z3sRBm Q3iT/PGQwuXPZUghEv8KDjw2sEo/lujWVrvw1MnHybj5UWisux4QFpvExChYH8Y5ULtak7/5EKB3 3eDPof9HNbWGcrRS+7kfcrPscQLdHVCT+wT2ddXNN+gk4wlGfIxLlS3rWaChZKb+RS1zMCVFFiHo gE6HMCVrChfP7KT2EwKF5hEBbHQRqYEGlLO+pePQ3a9dhzra/d7d11wtmdyOIHSlgh8ITezgMYID /zCCA/sCAQEwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBM YWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDov L3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6wbrGMAkGBSsOAwIaBQCgggIPMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAyNTE1NTAzMVowIwYJKoZI hvcNAQkEMRYEFN2rdcKHsDPhvgdCYyNK20N0zGQbMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQDFwzuU3TOCsDvWZ+r6wbrGMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMT LVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRAMXDO5TdM4Kw O9Zn6vrBusYwDQYJKoZIhvcNAQEBBQAEggEAQ4lfeuBUSwwne93ykSuIGloCfe1JO6Fn3jhvSpEG ZJ8E7qGAk3BmRdgMrxHgpmtrDgQwCXlmlrdIvwFKJ3sVdWpsEzND1bkmQ15FYspAbB7QJ1JlCLbw VzPjnwLMDCkvyik6nALk7lQy/JwFGfAd4VnRrFVYviMML0NRlqtjv8RJM9DBJ8UKGQHQokZ0ecIW rNWg7TG/0RT/I9vqeW7Iw1ISmoY+KdJj5uNgtIPRrHuP3CjKnIGJG2AhizwW6wvtmbFNkpbjNWdn yMnniXjOPRoLMr8SMsxqmgntzbsMXea/g++yFnaX1WpbNIpZgn6+ReWY49PEmy8AKmWV9FTlHAAA AAAAAA== --Apple-Mail-6-476985890-- From john-ietf@jck.com Mon Oct 25 10:07:02 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 567353A6A62 for ; Mon, 25 Oct 2010 10:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahAZMJOxNFin for ; Mon, 25 Oct 2010 10:06:51 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id A1CB13A6B62 for ; Mon, 25 Oct 2010 10:06:48 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PAQXB-0009Ev-Gs; Mon, 25 Oct 2010 13:08:33 -0400 Date: Mon, 25 Oct 2010 13:08:32 -0400 From: John C Klensin To: Eric Burger , Discuss Apps IETF Message-ID: In-Reply-To: <3F3180D3-2925-47E9-92FD-3ED11FAD6D34@standardstrack.com> References: <201010212030.WAA26704@TR-Sys.de> <4CC4D9D3.2060003@att.com> <0077AC96FF0947F4AE87DFA7@PST.JCK.COM> <3F3180D3-2925-47E9-92FD-3ED11FAD6D34@standardstrack.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [apps-discuss] draft-saintandre-xdash-considered-harmful-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 17:07:02 -0000 --On Monday, October 25, 2010 11:50 -0400 Eric Burger wrote: > Well... Is not the problem that a proprietary extension > becomes standard? The problem may be that there is no consensus yet on what problem we are trying to solve :-( > What is the difference between X-mumble and Eric-mumble? Does > private namespaces really help the fundamental problem? The problem I'd like to solve is to be able to bind every header field name to a definition of that header and to be sure those definitions are unique (i.e., exactly one definition per header field name), either via registration of the field name or via one level of indirection (knowing whom to ask). >From that perspective, X-mumble was intended to solve a differentm but collateral, problem, i.e., providing a specific warning that there was no reliable name <-> definition binding, at least in the absence of significant out-of-band information. I think there is little or no disagreement that "X-" has not been successful in meeting that objective. The controversy appears only to be (1) whether it is enough worse than nothing to be considered harmful and deprecated without another plan to address the definition binding or warning issues and (2) whether we do have a plan to replace it. I read Tony's proposal and Nathaniel's earlier remarks as the beginnings of such a plan. As far as whether Eric-mumble would be significantly better, the answer in the general case is "no". But Tony's comment was about the mechanism used for media types. The vendor and personal namespaces there have a very specific structure. If we adopted that model (plus or minus fine-tuning): o X-mumble would essentially be invalid on its face, because it could not be registered. o Eric-mumble would be invalid unless you conformed to the registration procedure (if we followed the general media type model, that would require standards action or formal IESG recognition, presumably supported by an RFC or stable, public, document) o vnd.eric.mumble would be valid if "eric" were registered and pointed to you so that (i) you could be consulted about what "mumble" meant and (ii) no one else would use "vnd.eric." o pers.eric.mumble would be valid with or without registration, but would effectively carry the same disclaimer than "X-" has tried to carry, i.e., that I'd better be very confident that I know who "eric" is before assuming that I can interpret "mumble". Ignoring the obvious small issues with syntax, using vnd.URI.field-name or vnd.FQDN.field-name would have the advantage over vnd.Registered-Vendor-Name.field-name of not requiring an IANA registry... and the disadvantage of being somewhat less stable. Of course, we could punt that tradeoff by having both Registered-Vendor-Name and something URI or DNS-based with different first-facet prefixes and letting the vendor choose between long-term stability and the convenience of avoiding dealing with IANA at all. john From john-ietf@jck.com Mon Oct 25 10:53:18 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F3CF3A67B3 for ; Mon, 25 Oct 2010 10:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xx1mqEqNKlxj for ; Mon, 25 Oct 2010 10:53:17 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 92F123A67F9 for ; Mon, 25 Oct 2010 10:53:16 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1PARG7-000AYv-So; Mon, 25 Oct 2010 13:55:00 -0400 Date: Mon, 25 Oct 2010 13:54:59 -0400 From: John C Klensin To: Cullen Jennings , Martin Thomson Message-ID: In-Reply-To: <2D0EB56D-F5DF-4BDB-A9AD-16A373BE7CB9@cisco.com> References: <8B0A9FCBB9832F43971E38010638454F03F1490AE0@SISPE7MB1.commscope.com> <2D0EB56D-F5DF-4BDB-A9AD-16A373BE7CB9@cisco.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Apps-Discuss@ietf.org Subject: Re: [apps-discuss] Draft on representing values of sensors in JSON (draft-jennings-senml) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 17:53:18 -0000 --On Sunday, October 24, 2010 16:49 -0600 Cullen Jennings wrote: >... >> You also have a TODO on accuracy/confidence. Additional >> optional attributes seem appropriate: in metrology, it's >> commonplace to describe a confidence interval. > > I somehow suspected you might have a well informed opinion on > this topic. When I wrote TODO, I was hoping it was something > someone else would Do. Thank you for the text. It's been > inserted. >... >> Measurement quality attributes can be added: >> >> unc: the uncertainty in the measurement, that uses the same >> units as the base; if absent, the value is unknown (i.e., >> don't assume that this is zero) c: the confidence of the >> measurement, as a percentage; if absent, you can pick a >> default value Cullen, Confidence expressed as a single probability and uncertainty expressed as a single value inherently assume that the distribution of the measure is central, symmetric and, for most purposes, unimodal. While it does not assume normality, one might end up making that assumption to interpret the numbers. The difficulty is that, while most measurements of physical phenomena obey that constraint, many other phenomena (especially many biological and socio-economic ones) are characterized by asymmetrical distributions with one very long tail or even multimodal distributions... and the biological ones, at least, are often measured using sensor-based technologies. Independently, if you are going to express uncertainty as a scalar, you get involved with the question of whether you are providing absolute bound/limits or values at some confidence/ probability function. The latter would imply that "c" and "unc" would need to be used together or not at all. I think the text above (and now in the draft) assumed that pairing, but it isn't clear in context (and doesn't eliminate the central-symmetric-unimodal assumption). If you are going to describe uncertainty or confidence in situations where either the sensor or the underlying phenomenon exhibit asymmetric behavior, you should make provision for either a description of the distribution, multiple (identified) values, or both (but see the last comment below). >> An alternative is to report RMS error, which is a common >> measure of quality where there are multiple samples taken, >> but only a mean value reported: A different set of distributional assumptions, noting that just about anything based on mean values is of dubious value with asymmetric distributions. While you excluded this on the basis of the preferences of the people you polled, it is the standard measure for some situations and fields. In addition, if you are going to deal with "integrated sums" and their definition, I suspect that you should be prepared to deal with moving averages and autocorrelation functions: even if few sensors produce those today, they can be extremely valuable statistically for measurements of some types of phenomena, especially when deviations from some norm are more significant than the norm itself or when measurements are to be used predictively. >> In a lot of sensors, uncertainty and confidence are known, >> but discrete observations do not necessarily carry specific >> values for these. Instead this is a known characteristic of >> the device. Thus, it could make sense to carry a base value >> (a base uncertainty). Within the format you describe, you >> will need to associate a base value with each sensor. >> >> { q: { [ n: "foo", unc: 0.43, c: 90 ] } } >> > > will think about this one ... >... I don't think the fairly subtle statistical considerations I've pointed to above ought to need treatment in the present document. Indeed, although I could provide some references to systems that tried, to do so would, IMO, take you down a rat hole. But I think the document should be very clear about expansion paths so that adding additional/alternate distributional information or the like does not end up requiring an entirely new Media Type. Or, if you think a new Media Type would be the right solution for such expansion, I think the document should explain that. best, john From GK@ninebynine.org Mon Oct 25 11:52:00 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E57023A68FD for ; Mon, 25 Oct 2010 11:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.997 X-Spam-Level: X-Spam-Status: No, score=-5.997 tagged_above=-999 required=5 tests=[AWL=0.602, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqDRc+C7a-ui for ; Mon, 25 Oct 2010 11:51:59 -0700 (PDT) Received: from relay2.mail.ox.ac.uk (relay2.mail.ox.ac.uk [163.1.2.161]) by core3.amsl.com (Postfix) with ESMTP id 243EC3A6804 for ; Mon, 25 Oct 2010 11:51:58 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay2.mail.ox.ac.uk with esmtp (Exim 4.71) (envelope-from ) id 1PASAg-0001f6-8y; Mon, 25 Oct 2010 19:53:26 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PASAg-0000vY-1k; Mon, 25 Oct 2010 19:53:26 +0100 Message-ID: <4CC5CF18.1070606@ninebynine.org> Date: Mon, 25 Oct 2010 19:40:24 +0100 From: Graham Klyne User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Eric Burger References: <201010212030.WAA26704@TR-Sys.de> <4CC4D9D3.2060003@att.com> <0077AC96FF0947F4AE87DFA7@PST.JCK.COM> <3F3180D3-2925-47E9-92FD-3ED11FAD6D34@standardstrack.com> In-Reply-To: <3F3180D3-2925-47E9-92FD-3ED11FAD6D34@standardstrack.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: Discuss Apps IETF Subject: Re: [apps-discuss] draft-saintandre-xdash-considered-harmful-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 18:52:01 -0000 Eric Burger wrote: > What is the difference between X-mumble and Eric-mumble? Does private namespaces really help the fundamental problem? I think not. Or not much. I keep wondering why RFC3864 [1] isn't more visible in this discussion: provisional registration is cheap and easy. Where's the problem here that I'm not seeing? [[ The main requirements for a header field to be included in the provisional repository are that it MUST have a citable specification, and there MUST NOT be a corresponding entry (with same field name and protocol) in the permanent header field registry. ]] -- RFC3864, section 4.2.2 #g -- [1] http://tools.ietf.org/html/rfc3864 Eric Burger wrote: > Well... Is not the problem that a proprietary extension becomes standard? > > What is the difference between X-mumble and Eric-mumble? Does private namespaces really help the fundamental problem? > > On Oct 25, 2010, at 2:58 AM, John C Klensin wrote: > >> >> --On Sunday, October 24, 2010 21:13 -0400 Tony Hansen >> wrote: >> >>> The vendor and personal namespaces used for media types have >>> an extremely low overhead as well and are pretty darn close to >>> your "free love" level. >> Of course, they depend on structuring the type name. >> Optional-field in RFC 5322 Section 3.6.8 does not anticipate >> such structuring, but does not prohibit it either (nor does it >> prohibit "X-"; it just doesn't give it any special >> interpretation). I don't believe I've seen enough use of, e.g., >> header field names with periods in them to prevent our making >> that sort of structuring now. But it is a little late in the >> game and I wonder how long such a convention would require to be >> widely deployed and recognized. >> >>> I think adding such namespaces for headers would be cheap, >>> easy to do, and would solve many of the problems people see >>> with X-. >>> >>> Thoughts? >> For the reasons above, I question "cheap" and "easy to do", >> although it certainly strikes me as a good idea. >> >> john >> >> >> >> >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > ------------------------------------------------------------------------ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From ajs@shinkuro.com Mon Oct 25 12:01:20 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C107C3A6957 for ; Mon, 25 Oct 2010 12:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.154 X-Spam-Level: X-Spam-Status: No, score=-102.154 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnB6PubNH8Ou for ; Mon, 25 Oct 2010 12:01:12 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 492D13A6AD7 for ; Mon, 25 Oct 2010 12:01:08 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 3F1661ECB408 for ; Mon, 25 Oct 2010 19:02:53 +0000 (UTC) Date: Mon, 25 Oct 2010 15:02:51 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20101025190249.GZ45134@shinkuro.com> References: <201010212030.WAA26704@TR-Sys.de> <4CC4D9D3.2060003@att.com> <0077AC96FF0947F4AE87DFA7@PST.JCK.COM> <3F3180D3-2925-47E9-92FD-3ED11FAD6D34@standardstrack.com> <4CC5CF18.1070606@ninebynine.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CC5CF18.1070606@ninebynine.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [apps-discuss] draft-saintandre-xdash-considered-harmful-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 19:01:20 -0000 On Mon, Oct 25, 2010 at 07:40:24PM +0100, Graham Klyne wrote: > I keep wondering why RFC3864 [1] isn't more visible in this discussion: > provisional registration is cheap and easy. Where's the problem here > that I'm not seeing? > > [[ > The main requirements for a header field to be included in the > provisional repository are that it MUST have a citable specification, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ People have come to think that getting an RFC actually published is hard, probably because we have made it hard. For people who aren't used to the IETF, simply publishing something here is like being nibbled to death by ducks. Note that I-Ds aren't citable specifications, according to the process rules. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From Joe.Hildebrand@webex.com Mon Oct 25 12:20:44 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF5DE3A688A for ; Mon, 25 Oct 2010 12:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.387 X-Spam-Level: X-Spam-Status: No, score=-104.387 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vW227yUDO8T4 for ; Mon, 25 Oct 2010 12:20:43 -0700 (PDT) Received: from gw2.webex.com (gw2.webex.com [64.68.122.209]) by core3.amsl.com (Postfix) with SMTP id A6D493A69B7 for ; Mon, 25 Oct 2010 12:18:17 -0700 (PDT) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw2.webex.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Oct 2010 12:20:02 -0700 Received: from 66.114.169.7 ([66.114.169.7]) by SRV-EXSC03.webex.local ([192.168.252.200]) via Exchange Front-End Server mailus.webex.com ([66.114.175.11]) with Microsoft Exchange Server HTTP-DAV ; Mon, 25 Oct 2010 19:20:02 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 25 Oct 2010 13:20:01 -0600 From: Joe Hildebrand To: John C Klensin , Eric Burger , Discuss Apps IETF Message-ID: Thread-Topic: [apps-discuss] draft-saintandre-xdash-considered-harmful-01 Thread-Index: Act0eZ6LmpJrVoHcmU6NQUGuPUg0ug== In-Reply-To: IM-ID: xmpp:jhildebr@cisco.com Presence-ID: xmpp:jhildebr@cisco.com Jabber-ID: jhildebr@cisco.com Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 25 Oct 2010 19:20:02.0538 (UTC) FILETIME=[9F7634A0:01CB7479] Subject: Re: [apps-discuss] draft-saintandre-xdash-considered-harmful-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 19:20:44 -0000 On 10/25/10 11:08 AM, "John C Klensin" wrote: > Ignoring the obvious small issues with syntax, using > vnd.URI.field-name or vnd.FQDN.field-name would have the > advantage over vnd.Registered-Vendor-Name.field-name of not > requiring an IANA registry... and the disadvantage of being > somewhat less stable. Of course, we could punt that tradeoff by > having both Registered-Vendor-Name and something URI or > DNS-based with different first-facet prefixes and letting the > vendor choose between long-term stability and the convenience of > avoiding dealing with IANA at all. For syntax, base64 generates sequences that are valid according to the field-name production of 5322. Clark notation is a nice fit for the URI/field tuple. As such, this should work: "B64-" + base64({uri}field-name) + ": " + value The person/group that owns the URI owns the change control over that uri/field tuple, and is responsible for forward- and backward-compatibility, or changing the uri or field for incompatible changes. The B64- prefix is intended to ensure that we don't overlap an existing header by mistake, and to give a hint to third parties that if they base64-decode the field name, they should get something interesting. -- Joe Hildebrand From GK@ninebynine.org Mon Oct 25 13:10:00 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D84D3A68E8 for ; Mon, 25 Oct 2010 13:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.147 X-Spam-Level: X-Spam-Status: No, score=-6.147 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myjY1pTXZfeN for ; Mon, 25 Oct 2010 13:09:59 -0700 (PDT) Received: from relay6.mail.ox.ac.uk (relay6.mail.ox.ac.uk [163.1.2.167]) by core3.amsl.com (Postfix) with ESMTP id 025613A67B3 for ; Mon, 25 Oct 2010 13:09:59 -0700 (PDT) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay6.mail.ox.ac.uk with esmtp (Exim 4.71) (envelope-from ) id 1PATOR-0008V5-LJ; Mon, 25 Oct 2010 21:11:43 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PATOR-0001mo-0r; Mon, 25 Oct 2010 21:11:43 +0100 Message-ID: <4CC5E45C.6080505@ninebynine.org> Date: Mon, 25 Oct 2010 21:11:08 +0100 From: Graham Klyne User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Andrew Sullivan References: <201010212030.WAA26704@TR-Sys.de> <4CC4D9D3.2060003@att.com> <0077AC96FF0947F4AE87DFA7@PST.JCK.COM> <3F3180D3-2925-47E9-92FD-3ED11FAD6D34@standardstrack.com> <4CC5CF18.1070606@ninebynine.org> <20101025190249.GZ45134@shinkuro.com> In-Reply-To: <20101025190249.GZ45134@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-saintandre-xdash-considered-harmful-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 20:10:00 -0000 Hi Andrew, Thanks for explaining this perception. The "citable specification" does not have to be an RFC - any document, e.g., on the web would do (though I tend to remind registrants that that internet drafts time out after 6 months). So it seems the problem is with interpretation of "citable specification". It was not intended to be restricted to "formally citable specifications" or suchlike, just something that could be referenced and retrieved by anyone. This should be easily fixable. Or is there a deeper problem? #g -- Andrew Sullivan wrote: > On Mon, Oct 25, 2010 at 07:40:24PM +0100, Graham Klyne wrote: >> I keep wondering why RFC3864 [1] isn't more visible in this discussion: >> provisional registration is cheap and easy. Where's the problem here >> that I'm not seeing? >> >> [[ >> The main requirements for a header field to be included in the >> provisional repository are that it MUST have a citable specification, > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > People have come to think that getting an RFC actually published is > hard, probably because we have made it hard. For people who aren't > used to the IETF, simply publishing something here is like being > nibbled to death by ducks. > > Note that I-Ds aren't citable specifications, according to the process > rules. > > A > From eric@tibco.com Mon Oct 25 13:46:55 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C34833A6822 for ; Mon, 25 Oct 2010 13:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nn1lkCxJgzcy for ; Mon, 25 Oct 2010 13:46:54 -0700 (PDT) Received: from mx2-app.tibco.com (mx2-app.tibco.com [63.100.100.143]) by core3.amsl.com (Postfix) with ESMTP id D09D73A6978 for ; Mon, 25 Oct 2010 13:46:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,237,1286175600"; d="scan'208";a="16281561" Received: from tibco-5.tibco.com (HELO na-pa-fe01.na.tibco.com) ([63.100.100.5]) by mx2-app.tibco.com with ESMTP; 25 Oct 2010 13:48:24 -0700 Received: from Eric-Johnsons-MacBook-Pro.local ([10.98.32.26]) by na-pa-fe01.na.tibco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Oct 2010 13:48:23 -0700 Message-ID: <4CC5ED17.5010400@tibco.com> Date: Mon, 25 Oct 2010 13:48:23 -0700 From: Eric Johnson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <201010212030.WAA26704@TR-Sys.de> <4CC4D9D3.2060003@att.com> <0077AC96FF0947F4AE87DFA7@PST.JCK.COM> <3F3180D3-2925-47E9-92FD-3ED11FAD6D34@standardstrack.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2010 20:48:24.0026 (UTC) FILETIME=[F76513A0:01CB7485] X-TM-AS-Product-Ver: SMEX-10.0.0.1412-6.500.1024-17724.006 X-TM-AS-Result: No--23.410900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: Re: [apps-discuss] draft-saintandre-xdash-considered-harmful-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 20:46:55 -0000 I've a current interest in this, because I'm trying to craft language around IANA registration at pretty much the exact time that this draft came up. One thought below: On 10/25/10 10:08 AM, John C Klensin wrote: [snip] > > The problem I'd like to solve is to be able to bind every header > field name to a definition of that header and to be sure those > definitions are unique (i.e., exactly one definition per header > field name), either via registration of the field name or via > one level of indirection (knowing whom to ask). That just about describes what I want to see out of registration, with minimal overhead to the person defining the extension. [snip] > > o Eric-mumble would be invalid unless you conformed to > the registration procedure (if we followed the general > media type model, that would require standards action or > formal IESG recognition, presumably supported by an RFC > or stable, public, document) > > o vnd.eric.mumble would be valid if "eric" were > registered and pointed to you so that (i) you could be > consulted about what "mumble" meant and (ii) no one else > would use "vnd.eric." > > o pers.eric.mumble would be valid with or without > registration, but would effectively carry the same > disclaimer than "X-" has tried to carry, i.e., that I'd > better be very confident that I know who "eric" is > before assuming that I can interpret "mumble". > > Ignoring the obvious small issues with syntax, using > vnd.URI.field-name or vnd.FQDN.field-name would have the > advantage over vnd.Registered-Vendor-Name.field-name of not > requiring an IANA registry... and the disadvantage of being > somewhat less stable. Of course, we could punt that tradeoff by > having both Registered-Vendor-Name and something URI or > DNS-based with different first-facet prefixes and letting the > vendor choose between long-term stability and the convenience of > avoiding dealing with IANA at all. Please excuse me for any mistakes of protocol in contributing the following, since I'm still very much unfamiliar with the workings/culture of the IETF. My brain immediately leapt to wondering whether the following make sense: vnd.____.mumble dns.____.mumble If you want something in the "personal" category, it is so simple to get a DNS name (either as a sub-domain, or as a "top-level"), then why not just collapse those scenarios? Also, being a long time Java programmer, I find it easier to read reverse-DNS names, as in "dns.org.ietf.mumble", rather than "dns.ietf.org.mumble". In this case, the more general info comes at the front, and the more specific at the end, which a human reader might find easier? "dns.com.foo.mumble" "dns.uk.co.foo.mumble" "dns.com.foo.mumble2" "dns.uk.co.foo.mumble3" as compared to: "dns.foo.com.mumble" "dns.foo.co.uk.mumble" "dns.foo.com.mumble2" "dns.foo.co.uk.mumble3" -Eric. From Martin.Thomson@andrew.com Mon Oct 25 15:40:44 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79DDF3A6BA9 for ; Mon, 25 Oct 2010 15:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.878 X-Spam-Level: X-Spam-Status: No, score=-2.878 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhExoItCXTY0 for ; Mon, 25 Oct 2010 15:40:42 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id B89373A6856 for ; Mon, 25 Oct 2010 15:40:42 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:2231 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S468246Ab0JYWm2 (ORCPT ); Mon, 25 Oct 2010 17:42:28 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 25 Oct 2010 17:42:28 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 26 Oct 2010 06:42:24 +0800 From: "Thomson, Martin" To: Discuss Apps IETF Date: Tue, 26 Oct 2010 06:42:22 +0800 Thread-Topic: [apps-discuss] draft-saintandre-xdash-considered-harmful-01 Thread-Index: Act0XGChLDNWBlovRHaSCopiknsfqAANc0gg Message-ID: <8B0A9FCBB9832F43971E38010638454F03F31EAE5F@SISPE7MB1.commscope.com> References: <201010212030.WAA26704@TR-Sys.de> <4CC4D9D3.2060003@att.com> <0077AC96FF0947F4AE87DFA7@PST.JCK.COM> <3F3180D3-2925-47E9-92FD-3ED11FAD6D34@standardstrack.com> In-Reply-To: <3F3180D3-2925-47E9-92FD-3ED11FAD6D34@standardstrack.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [apps-discuss] draft-saintandre-xdash-considered-harmful-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 22:40:44 -0000 T24gMjAxMC0xMC0yNiBhdCAwMjo1MDozMSwgRXJpYyBCdXJnZXIgd3JvdGU6DQo+IFdoYXQgaXMg dGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBYLW11bWJsZSBhbmQgRXJpYy1tdW1ibGU/ICBEb2VzIHBy aXZhdGUNCj4gbmFtZXNwYWNlcyByZWFsbHkgaGVscCB0aGUgZnVuZGFtZW50YWwgcHJvYmxlbT8N Cg0KTmFtZXNwYWNlcyBhcmUgdGhlIHJvb3Qgb2YgdGhlIHByb2JsZW0sIGFyZW4ndCB0aGV5Pw0K DQpYLSBpcyBqdXN0IGEgKHNsdW0pIG5hbWVzcGFjZS4gIE5vdGhpbmcgd29ya3MgaGVyZS4NCg0K RXJpYy1tdW1ibGUgaXMgd29yc2UgYmVjYXVzZSBBbGJlcnQgZG9lc24ndCBsaWtlIEVyaWMgYW5k IHNvIGhlIGR1cGxpY2F0ZXMgdGhlIGZ1bmN0aW9ucyBpbiBoaXMgb3duIG5hbWVzcGFjZSByYXRo ZXIgdGhhbiBjZWRlIGNvbnRyb2wgdG8gRXJpYy4gIChCVFcsIHRoYXQncyBhbiBhcmd1bWVudCBJ IGRvbid0IHNlZSBpbiB0aGUgZHJhZnQuKQ0KDQpCZXR0ZXIgdG8gbWFrZSB5b3VyIGV4dGVuc2li aWxpdHkgc2ltcGxlLiAgSG93IGFib3V0IGhhdmluZyB0aHJlZSB0aWVycyBvZiAiaW50ZXJvcGVy YWJpbGl0eSBwcm90ZWN0aW9uIjoNCg0KIElQLUM6IEFueW9uZSBjYW4gdXNlIGEgaGVhZGVyIHdp dGggYW55IG5hbWUgdGhleSBjaG9vc2UuICANCiANCiAgICAgICBVc2UgYXQgb3duIHJpc2suDQoN CiBJUC1SOiBBbnlvbmUgY2FuIHJlZ2lzdGVyIGEgaGVhZGVyIHdpdGggYW55IG5hbWUuDQoNCiAg ICAgICBDb2xsaXNpb25zIGFyZSBsZXNzIGxpa2VseSwgbm90IGltcG9zc2libGUuDQoNCiBJUC1T OiBSRkNzKiByZWdpc3RlciBoZWFkZXJzIHdpdGggYWJzb2x1dGUgZXhjbHVzaXZpdHkuDQoNCiAg ICAgICBTYWZlIHRvIHVzZS4NCg0KQmVjYXVzZSB0aGUgbmFtZSBpc24ndCBzY29wZSBvciBxdWFs aWZpZWQsIGhlYWRlcnMgY2FuIGluY3JlYXNlIHRoZWlyIGludGVyb3BlcmFiaWxpdHkgcHJvdGVj dGlvbiBzdGF0dXMgd2l0aG91dCBicmVha2luZyBpbXBsZW1lbnRhdGlvbnMgdGhhdCBhbHJlYWR5 IHVzZSBpdC4gIFRoaXMgZW5jb3VyYWdlcyB0aGUgcmVnaXN0cmF0aW9uIG9mIGhlYWRlcnMgd2l0 aCBhcHByb3ByaWF0ZSBuYW1lcy4NCg0KVGhlIHJlZ2lzdHJ5IHByb3ZpZGVzIGEgbGltaXRlZCBn dWFyYW50ZWUgb2YgdW5pcXVlbmVzcy4NCg0KKiBBbiBzdGFuZGFyZHMgdHJhY2sgcmVnaXN0cmF0 aW9uIC0gb3Igc29tZXRoaW5nIHNpbWlsYXJseSBzdHJvbmcgLSBjYXVzZXMgZXhpc3RpbmcgcmVn aXN0cmF0aW9ucyBmb3IgdGhlIHNhbWUgbmFtZSBnZXQgc3dlcHQgYXdheS4gIFRoZSByZXZpZXcg cHJvY2VzcyBjYW4gZGV0ZXJtaW5lIGlmIHRoaXMgaXMgYXBwcm9wcmlhdGUuDQoNCi0tTWFydGlu DQo= From stpeter@stpeter.im Mon Oct 25 15:44:51 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C04873A6AEC for ; Mon, 25 Oct 2010 15:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CENtyEZ6kB4 for ; Mon, 25 Oct 2010 15:44:45 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id E38D03A6A63 for ; Mon, 25 Oct 2010 15:44:44 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7D33F40D1E; Mon, 25 Oct 2010 16:54:24 -0600 (MDT) Message-ID: <4CC608C4.8040209@stpeter.im> Date: Mon, 25 Oct 2010 16:46:28 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: "Thomson, Martin" References: <201010212030.WAA26704@TR-Sys.de> <4CC4D9D3.2060003@att.com> <0077AC96FF0947F4AE87DFA7@PST.JCK.COM> <3F3180D3-2925-47E9-92FD-3ED11FAD6D34@standardstrack.com> <8B0A9FCBB9832F43971E38010638454F03F31EAE5F@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F31EAE5F@SISPE7MB1.commscope.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090102000307050204030302" Cc: Discuss Apps IETF Subject: Re: [apps-discuss] draft-saintandre-xdash-considered-harmful-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 22:44:51 -0000 This is a cryptographically signed message in MIME format. --------------ms090102000307050204030302 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/25/10 4:42 PM, Thomson, Martin wrote: > On 2010-10-26 at 02:50:31, Eric Burger wrote: >> What is the difference between X-mumble and Eric-mumble? Does >> private namespaces really help the fundamental problem? >=20 > Namespaces are the root of the problem, aren't they? >=20 > X- is just a (slum) namespace. Nothing works here. >=20 > Eric-mumble is worse because Albert doesn't like Eric and so he > duplicates the functions in his own namespace rather than cede > control to Eric. (BTW, that's an argument I don't see in the > draft.) Many arguments are not yet in the draft, and I shan't have time to update it before the cutoff. But perhaps a discussion at the appsarea meeting in Beijing would be productive. > Better to make your extensibility simple. How about having three > tiers of "interoperability protection": >=20 > IP-C: Anyone can use a header with any name they choose. >=20 > Use at own risk. >=20 > IP-R: Anyone can register a header with any name. >=20 > Collisions are less likely, not impossible. >=20 > IP-S: RFCs* register headers with absolute exclusivity. >=20 > Safe to use. Could you compare / contrast to provisional vs. permanent registrations? The latter distinction might give us most or all of what we need (depending on which problem we're trying to solve). > Because the name isn't scope or qualified, headers can increase their > interoperability protection status without breaking implementations > that already use it. This encourages the registration of headers > with appropriate names. >=20 > The registry provides a limited guarantee of uniqueness. >=20 > * An standards track registration - or something similarly strong - > causes existing registrations for the same name get swept away. The > review process can determine if this is appropriate. Fun. :) Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms090102000307050204030302 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAy NTIyNDYyOFowIwYJKoZIhvcNAQkEMRYEFB5T5GNm1u95EuJOEUcfYmXwPWcAMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBtyK7v24/YkcnxN7novoniCojKlqZVekphqus6HfL7zVepaBH/SjI4JTjD XCXg2d2IgpIzEZZ8yBvHOx/sDetlg5Jmk4VuPSLgAKgIdm6F1ny4fBJNnnf2OggkJrvHI0/+ zL1E6GQGW+tTSdZVN2FrEhL3MDJwdggzRCJ0Gztc7lq1Uo7PXSxntZZ3EGgGr+1ikn6/dRtD GAcJzkyvNlunnDKqTZb5PPqNoeUUq117QaAT73cNFYlbXNW9kTtVn3X4EQLRrK/qs+2x7RWn O0OOGkdRTZ57o510YemwPnA4QdWmzhyOU8z7XvIVfSP6inl8KnMuZ8VcK0IauVYIFeuTAAAA AAAA --------------ms090102000307050204030302-- From Martin.Thomson@andrew.com Mon Oct 25 15:54:15 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71FBE3A690C for ; Mon, 25 Oct 2010 15:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qgpJ+hwr1Tf for ; Mon, 25 Oct 2010 15:54:14 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 50DFB3A6826 for ; Mon, 25 Oct 2010 15:54:14 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:16848 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S468253Ab0JYW4A (ORCPT ); Mon, 25 Oct 2010 17:56:00 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 25 Oct 2010 17:56:00 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 26 Oct 2010 06:55:57 +0800 From: "Thomson, Martin" To: Peter Saint-Andre Date: Tue, 26 Oct 2010 06:55:55 +0800 Thread-Topic: [apps-discuss] draft-saintandre-xdash-considered-harmful-01 Thread-Index: Act0lnmFX7UAgii+SSmLM9vbu6/9ZgAAC+Gg Message-ID: <8B0A9FCBB9832F43971E38010638454F03F31EAE68@SISPE7MB1.commscope.com> References: <201010212030.WAA26704@TR-Sys.de> <4CC4D9D3.2060003@att.com> <0077AC96FF0947F4AE87DFA7@PST.JCK.COM> <3F3180D3-2925-47E9-92FD-3ED11FAD6D34@standardstrack.com> <8B0A9FCBB9832F43971E38010638454F03F31EAE5F@SISPE7MB1.commscope.com> <4CC608C4.8040209@stpeter.im> In-Reply-To: <4CC608C4.8040209@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: Discuss Apps IETF Subject: Re: [apps-discuss] draft-saintandre-xdash-considered-harmful-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 22:54:15 -0000 T24gMjAxMC0xMC0yNiBhdCAwOTo0NjoyOCwgUGV0ZXIgU2FpbnQtQW5kcmUgd3JvdGU6DQo+ID4g QmV0dGVyIHRvIG1ha2UgeW91ciBleHRlbnNpYmlsaXR5IHNpbXBsZS4gIEhvdyBhYm91dCBoYXZp bmcgdGhyZWUNCj4gPiB0aWVycyBvZiAiaW50ZXJvcGVyYWJpbGl0eSBwcm90ZWN0aW9uIjoNCj4g Pg0KPiA+IElQLUM6IEFueW9uZSBjYW4gdXNlIGEgaGVhZGVyIHdpdGggYW55IG5hbWUgdGhleSBj aG9vc2UuDQo+ID4NCj4gPiBVc2UgYXQgb3duIHJpc2suDQo+ID4NCj4gPiBJUC1SOiBBbnlvbmUg Y2FuIHJlZ2lzdGVyIGEgaGVhZGVyIHdpdGggYW55IG5hbWUuDQo+ID4NCj4gPiBDb2xsaXNpb25z IGFyZSBsZXNzIGxpa2VseSwgbm90IGltcG9zc2libGUuDQo+ID4NCj4gPiBJUC1TOiBSRkNzKiBy ZWdpc3RlciBoZWFkZXJzIHdpdGggYWJzb2x1dGUgZXhjbHVzaXZpdHkuDQo+ID4NCj4gPiBTYWZl IHRvIHVzZS4NCj4gDQo+IENvdWxkIHlvdSBjb21wYXJlIC8gY29udHJhc3QgdG8gcHJvdmlzaW9u YWwgdnMuIHBlcm1hbmVudA0KPiByZWdpc3RyYXRpb25zPw0KPiBUaGUgbGF0dGVyIGRpc3RpbmN0 aW9uIG1pZ2h0IGdpdmUgdXMgbW9zdCBvciBhbGwgb2Ygd2hhdCB3ZSBuZWVkDQo+IChkZXBlbmRp bmcgb24gd2hpY2ggcHJvYmxlbSB3ZSdyZSB0cnlpbmcgdG8gc29sdmUpLg0KDQpBIHByb3Zpc2lv bmFsIHJlZ2lzdHJhdGlvbiB3b3VsZCBiZSBzaW1pbGFyIHRvIElQLVIuICBUaGUgb25seSBkaWZm ZXJlbnQgaXMgdGhhdCB0d28gcGVvcGxlIGNhbiBjb21wZXRlIGZvciB0aGUgc2FtZSBuYW1lIHdp dGggSVAtUjsgcHJvdmlzaW9uYWwgcmVnaXN0cmF0aW9ucyBzdGlsbCBoYXZlIGV4Y2x1c2l2aXR5 Lg0KDQpQcm92aXNpb25hbCByZWdpc3RyYXRpb25zIGRvIHRoZSBqb2IgcHJldHR5IHdlbGwuICBC dXQgZXhjbHVzaXZpdHkgc2VlbXMgdW5uZWNlc3NhcnkgYXQgdGhpcyBsZXZlbCBvZiBwcm90ZWN0 aW9uLiAgVGhlIG1haW4gcHJvYmxlbXMgSSB3YXMgdHJ5aW5nIHRvIGFkZHJlc3Mgd2VyZToNCg0K IC0gaW5mb3JtYXRpb25hbCByZWdpc3RyYXRpb25zIC0gaXQgbWFrZXMgc2Vuc2UgdG8gaGF2ZSB0 aGUgcmVnaXN0cnkgZG9jdW1lbnQgZXhpc3RpbmcgY3VycmVudCBwcmFjdGljZSwgZXZlbiBpZiB0 aGVyZSBpcyBubyBpbnRlbnQgdG8gc3RhbmRhcmRpemUgYSB2YWx1ZSwgb3IgaW50ZW50IHRvIGlu dGVyb3BlcmF0ZQ0KIC0gb2xkIHVzZXMgYW5kIGN1cnJlbnQgb25lcyAtIHNvbWUgcmVnaXN0cmF0 aW9ucyBtaWdodCBmYWxsIG91dCBvZiBjb21tb24gdXNlOyByYXRoZXIgdGhhbiBwcmV2ZW50IHRo ZSBuYW1lIGZyb20gYmVpbmcgcGlja2VkIHVwLCB0aGlzIHdvdWxkIGxldCBzb21lb25lIHN1cHBs YW50IHRoZSBvbGQgbmFtZQ0KDQo+ID4gKiBBbiBzdGFuZGFyZHMgdHJhY2sgcmVnaXN0cmF0aW9u IC0gb3Igc29tZXRoaW5nIHNpbWlsYXJseSBzdHJvbmcgLQ0KPiA+IGNhdXNlcyBleGlzdGluZyBy ZWdpc3RyYXRpb25zIGZvciB0aGUgc2FtZSBuYW1lIGdldCBzd2VwdCBhd2F5LiAgVGhlDQo+ID4g cmV2aWV3IHByb2Nlc3MgY2FuIGRldGVybWluZSBpZiB0aGlzIGlzIGFwcHJvcHJpYXRlLg0KPiAN Cj4gRnVuLiA6KQ0KDQpDYW4geW91IHRoaW5rIG9mIGEgYmV0dGVyIHJlYXNvbj8NCgkNCi0tTWFy dGluDQoNCj4gUGV0ZXINCg0KDQoNCg== From Martin.Thomson@andrew.com Mon Oct 25 16:25:06 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F9CB3A6A44 for ; Mon, 25 Oct 2010 16:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.874 X-Spam-Level: X-Spam-Status: No, score=-2.874 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eA1cq5U6OF+n for ; Mon, 25 Oct 2010 16:25:04 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id C20953A6452 for ; Mon, 25 Oct 2010 16:25:04 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:59181 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S467787Ab0JYX0u (ORCPT ); Mon, 25 Oct 2010 18:26:50 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 25 Oct 2010 18:26:50 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 26 Oct 2010 07:26:46 +0800 From: "Thomson, Martin" To: John C Klensin , Cullen Jennings Date: Tue, 26 Oct 2010 07:26:43 +0800 Thread-Topic: [apps-discuss] Draft on representing values of sensors in JSON (draft-jennings-senml) Thread-Index: Act0bcD0lKf+hhkSTTmyeUcoRIAB9gAKHGkw Message-ID: <8B0A9FCBB9832F43971E38010638454F03F31EAE73@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03F1490AE0@SISPE7MB1.commscope.com> <2D0EB56D-F5DF-4BDB-A9AD-16A373BE7CB9@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "Apps-Discuss@ietf.org" Subject: Re: [apps-discuss] Draft on representing values of sensors in JSON (draft-jennings-senml) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 23:25:06 -0000 SGkgSm9obiwgQ3VsbGVuLA0KDQpPbiAyMDEwLTEwLTI2IGF0IDA0OjU0OjU5LCBKb2huIEMgS2xl bnNpbiB3cm90ZToNCj4gQ29uZmlkZW5jZSBleHByZXNzZWQgYXMgYSBzaW5nbGUgcHJvYmFiaWxp dHkgYW5kIHVuY2VydGFpbnR5DQo+IGV4cHJlc3NlZCBhcyBhIHNpbmdsZSB2YWx1ZSBpbmhlcmVu dGx5IGFzc3VtZSB0aGF0IHRoZQ0KPiBkaXN0cmlidXRpb24gb2YgdGhlIG1lYXN1cmUgaXMgY2Vu dHJhbCwgc3ltbWV0cmljIGFuZCwgZm9yIG1vc3QNCj4gcHVycG9zZXMsIHVuaW1vZGFsLiAgV2hp bGUgaXQgZG9lcyBub3QgYXNzdW1lIG5vcm1hbGl0eSwgb25lDQo+IG1pZ2h0IGVuZCB1cCBtYWtp bmcgdGhhdCBhc3N1bXB0aW9uIHRvIGludGVycHJldCB0aGUgbnVtYmVycy4NCg0KQSByZWNlaXZl ciBtYWtlcyBzdWNoIGFzc3VtcHRpb25zIGVpdGhlciBiZWNhdXNlIHRoZXkga25vdyB0aGV5IGNh biAob3V0IG9mIGJhbmQgaW5mb3JtYXRpb24pLCBiZWNhdXNlIHRoZXkgYXJlIGlnbm9yYW50IG9m IHRoZSBwb3NzaWJpbGl0eSwgb3IgYmVjYXVzZSB0aGV5IGtub3cgdGhlIGNvbnNlcXVlbmNlcyBh bmQgYXJlIHByZXBhcmVkIHRvIGFjY2VwdCB0aGVtLg0KDQpUaGlzIGZvcm1hdCBjb3VsZCBjb252 ZXkgYSB3ZWFsdGggb2YgaW5mb3JtYXRpb24gb24gdGhlIG9ic2VydmVkIG9yIHRoZW9yZXRpY2Fs IHByb2JhYmlsaXR5IGRpc3RyaWJ1dGlvbiBvZiB0aGUgbWVhc3VyYW5kLiAgVGhhdCdzIHByb2Jh Ymx5IG92ZXJraWxsIGluIHRoZXNlIHNvcnRzIG9mIHVzZSBjYXNlcy4gIFRoZSB1bmMgYW5kIGMg cGFyYW1ldGVycyBhcmUgdGhlcmUgd2hlbiBjaGVhcCBpcyBnb29kIGVub3VnaC4NCg0KSW4gY2Fz ZXMgd2hlcmUgaXQncyBpbXBvcnRhbnQsIGEgc2Vuc29yIGNhbiByZXBvcnQgZGlzY3JldGUgb2Jz ZXJ2YXRpb25zLg0KDQo+IFRoZSBsYXR0ZXIgd291bGQgaW1wbHkgdGhhdCAiYyIgYW5kICJ1bmMi IHdvdWxkIG5lZWQgdG8gYmUgdXNlZCB0b2dldGhlciBvciBub3QgYXQgYWxsLiAgDQoNClllcywg dGhlcmUgaXMgYSBwYWlyaW5nLiAgVXN1YWxseSBpdCBnb2VzIGxpa2UgdGhpczogIGMgaGFzIGEg ZGVmYXVsdCB2YWx1ZSAoMC45NSk7IHVuYyBkb2Vzbid0LCBhbmQgaXMgYXNzdW1lZCB0byBiZSB1 bmtub3duIGluIGl0cyBhYnNlbmNlLg0KDQpbSSBqdXN0IG5vdGljZWQgdGhhdCB0aGUgdXBkYXRl ZCBkcmFmdCBzYXlzIHRoYXQgY29uZmlkZW5jZSBzaG91bGQgYmUgYXNzdW1lZCB0byBiZSAiYXBw cm94aW1hdGVseSAxIi4gIEJldHRlciB0byBzYXkgImV4YWN0bHkgMC45NSIuICAxIGlzIGltcG9z c2libGU7IDAuOTUgaXMgcGxlbnR5IGhpZ2gsIGFuZCBwbGF1c2libGUuXQ0KDQo+IEluIGFkZGl0 aW9uLCBpZiB5b3UgYXJlIGdvaW5nIHRvIGRlYWwgd2l0aCAiaW50ZWdyYXRlZCBzdW1zIiBhbmQN Cj4gdGhlaXIgZGVmaW5pdGlvbiwgSSBzdXNwZWN0IHRoYXQgeW91IHNob3VsZCBiZSBwcmVwYXJl ZCB0byBkZWFsDQo+IHdpdGggbW92aW5nIGF2ZXJhZ2VzIGFuZCBhdXRvY29ycmVsYXRpb24gZnVu Y3Rpb25zOiBldmVuIGlmIGZldw0KPiBzZW5zb3JzIHByb2R1Y2UgdGhvc2UgdG9kYXksIHRoZXkg Y2FuIGJlIGV4dHJlbWVseSB2YWx1YWJsZQ0KPiBzdGF0aXN0aWNhbGx5IGZvciBtZWFzdXJlbWVu dHMgb2Ygc29tZSB0eXBlcyBvZiBwaGVub21lbmEsDQo+IGVzcGVjaWFsbHkgd2hlbiBkZXZpYXRp b25zIGZyb20gc29tZSBub3JtIGFyZSBtb3JlIHNpZ25pZmljYW50DQo+IHRoYW4gdGhlIG5vcm0g aXRzZWxmIG9yIHdoZW4gbWVhc3VyZW1lbnRzIGFyZSB0byBiZSB1c2VkDQo+IHByZWRpY3RpdmVs eS4NCg0KTW92aW5nIGF2ZXJhZ2VzIGFuZCB0aGUgbGlrZSB3ZXJlIGNlcnRhaW5seSBjb25zaWRl cmVkLiAgQSBzZW5zb3IgdGhhdCBydW5zIGEgS2FsbWFuIG9yIHBhcnRpY2xlIGZpbHRlciBpcyBu b3Qgb3V0c2lkZSB0aGUgcmVhbG1zIG9mIHBvc3NpYmlsaXR5Lg0KIA0KPiBJIGRvbid0IHRoaW5r IHRoZSBmYWlybHkgc3VidGxlIHN0YXRpc3RpY2FsIGNvbnNpZGVyYXRpb25zIEkndmUNCj4gcG9p bnRlZCB0byBhYm92ZSBvdWdodCB0byBuZWVkIHRyZWF0bWVudCBpbiB0aGUgcHJlc2VudA0KPiBk b2N1bWVudC4gIEluZGVlZCwgYWx0aG91Z2ggSSBjb3VsZCBwcm92aWRlIHNvbWUgcmVmZXJlbmNl cyB0bw0KPiBzeXN0ZW1zIHRoYXQgdHJpZWQsIHRvIGRvIHNvIHdvdWxkLCBJTU8sIHRha2UgeW91 IGRvd24gYSByYXQNCj4gaG9sZS4gIEJ1dCBJIHRoaW5rIHRoZSBkb2N1bWVudCBzaG91bGQgYmUg dmVyeSBjbGVhciBhYm91dA0KPiBleHBhbnNpb24gcGF0aHMgLi4uDQoNClNvdW5kcyByZWFzb25h YmxlIHRvIG1lLiAgUmF0IGhvbGVzIHN3YWxsb3cgYSBsb3Qgb2YgZ29vZCB3b3JrLg0KDQotLU1h cnRpbg0K From dhc@dcrocker.net Mon Oct 25 17:50:16 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4262E3A6C64 for ; Mon, 25 Oct 2010 17:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4edlEAjk+Kfs for ; Mon, 25 Oct 2010 17:50:13 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 17C4A3A6C63 for ; Mon, 25 Oct 2010 17:50:13 -0700 (PDT) Received: from [192.168.1.5] (ppp-68-120-198-81.dsl.pltn13.pacbell.net [68.120.198.81]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o9Q0poVC007035 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 25 Oct 2010 17:51:56 -0700 Message-ID: <4CC62620.6050206@dcrocker.net> Date: Mon, 25 Oct 2010 17:51:44 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: "Thomson, Martin" References: <201010212030.WAA26704@TR-Sys.de> <4CC4D9D3.2060003@att.com> <0077AC96FF0947F4AE87DFA7@PST.JCK.COM> <3F3180D3-2925-47E9-92FD-3ED11FAD6D34@standardstrack.com> <8B0A9FCBB9832F43971E38010638454F03F31EAE5F@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F31EAE5F@SISPE7MB1.commscope.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 25 Oct 2010 17:51:56 -0700 (PDT) Cc: Discuss Apps IETF Subject: Re: [apps-discuss] draft-saintandre-xdash-considered-harmful-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 00:50:16 -0000 On 10/25/2010 3:42 PM, Thomson, Martin wrote: > Eric-mumble is worse because Albert doesn't like Eric and so he duplicates > the functions in his own namespace rather than cede control to Eric. (BTW, > that's an argument I don't see in the draft.) Sorry, but that's a reasonable theoretical argument that has no practical application in this space. If there were a practical problem, here, we'd have experienced it sometime in the past 28 years. The actual experience is that fields become popular or they don't. If they become popular, their name is not an -- or the -- issue. The problem with X- is that a name beginning with that is prohibited from becoming a formal standard, even when every system in the world is using it. That's pretty dumb. > Better to make your extensibility simple. How about having three tiers of > "interoperability protection": Why? Why add structure where the market has demonstrated no need? Really folks, as Graham noted, anyone wishing to reserve a name can do so easily: d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From salvatore.loreto@ericsson.com Mon Oct 25 22:12:55 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 239DE3A67E4 for ; Mon, 25 Oct 2010 22:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.847 X-Spam-Level: X-Spam-Status: No, score=-105.847 tagged_above=-999 required=5 tests=[AWL=0.752, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggMDIcXSMlOx for ; Mon, 25 Oct 2010 22:12:51 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id CEFBC3A67E2 for ; Mon, 25 Oct 2010 22:12:50 -0700 (PDT) X-AuditID: c1b4fb3d-b7b28ae00000135b-96-4cc663bc523d Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 04.8C.04955.CB366CC4; Tue, 26 Oct 2010 07:14:36 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Oct 2010 07:14:36 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 Oct 2010 07:14:35 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 97262254C; Tue, 26 Oct 2010 08:14:35 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5CFC450175; Tue, 26 Oct 2010 08:14:35 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 06E5E50167; Tue, 26 Oct 2010 08:14:34 +0300 (EEST) Message-ID: <4CC663BA.3020403@ericsson.com> Date: Tue, 26 Oct 2010 08:14:34 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: "apps-discuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 26 Oct 2010 05:14:35.0912 (UTC) FILETIME=[AE731880:01CB74CC] X-Brightmail-Tracker: AAAAAA== Cc: Greg Wilkins Subject: [apps-discuss] draft-loreto-http-bidirectional-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 05:12:55 -0000 Hi there, we have submitted a new version of the drat-loreto-http-bidirectional to address all the comments we have received on the previous one http://datatracker.ietf.org/doc/draft-loreto-http-bidirectional/ feedback, comments and suggestions are very welcome. cheers /Sal -- Salvatore Loreto www.sloreto.com From GK@ninebynine.org Tue Oct 26 04:15:32 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 093EE3A694A for ; Tue, 26 Oct 2010 04:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.348 X-Spam-Level: X-Spam-Status: No, score=-6.348 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11wx4Uhc+70e for ; Tue, 26 Oct 2010 04:15:30 -0700 (PDT) Received: from relay3.mail.ox.ac.uk (relay3.mail.ox.ac.uk [163.1.2.165]) by core3.amsl.com (Postfix) with ESMTP id 7E48D3A6938 for ; Tue, 26 Oct 2010 04:15:30 -0700 (PDT) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay3.mail.ox.ac.uk with esmtp (Exim 4.71) (envelope-from ) id 1PAhWl-0005xC-BF; Tue, 26 Oct 2010 12:17:15 +0100 Received: from tinos.zoo.ox.ac.uk ([129.67.24.47]) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PAhWl-0007Ia-3l; Tue, 26 Oct 2010 12:17:15 +0100 Message-ID: <4CC693BE.7050302@ninebynine.org> Date: Tue, 26 Oct 2010 09:39:26 +0100 From: Graham Klyne User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Thomson, Martin" References: <201010212030.WAA26704@TR-Sys.de> <4CC4D9D3.2060003@att.com> <0077AC96FF0947F4AE87DFA7@PST.JCK.COM> <3F3180D3-2925-47E9-92FD-3ED11FAD6D34@standardstrack.com> <8B0A9FCBB9832F43971E38010638454F03F31EAE5F@SISPE7MB1.commscope.com> <4CC608C4.8040209@stpeter.im> <8B0A9FCBB9832F43971E38010638454F03F31EAE68@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F31EAE68@SISPE7MB1.commscope.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635@OX.AC.UK Cc: Discuss Apps IETF Subject: Re: [apps-discuss] draft-saintandre-xdash-considered-harmful-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 11:15:32 -0000 Thomson, Martin wrote: > A provisional registration would be similar to IP-R. The only different is that two people can compete for the same name with IP-R; provisional registrations still have exclusivity. Actually, for message headers they don't: [[ The main requirements for a header field to be included in the provisional repository are that it MUST have a citable specification, and there MUST NOT be a corresponding entry (with same field name and protocol) in the **permanent** header field registry. ]] -- http://tools.ietf.org/html/rfc3864#section-4.2 (note my ** emphasis). >>> * An standards track registration - or something similarly strong - >>> causes existing registrations for the same name get swept away. The >>> review process can determine if this is appropriate. >> Fun. :) > > Can you think of a better reason? FWIW: [[ When a new entry is recorded in the permanent message header field registry, IANA will remove any corresponding entries (with the same field name and protocol) from the provisional registry. ]] -- http://tools.ietf.org/html/rfc3864#section-4.3 (The main point here, as I recall, was that the provisional registry can't be used to make an unsupported "land grab" on the namespace: community review trumps. #g -- From stpeter@stpeter.im Tue Oct 26 07:47:42 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CF633A6972 for ; Tue, 26 Oct 2010 07:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pt+2kutvgeNs for ; Tue, 26 Oct 2010 07:47:41 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id E55583A67D4 for ; Tue, 26 Oct 2010 07:47:40 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 41BAE40D1E; Tue, 26 Oct 2010 08:57:25 -0600 (MDT) Message-ID: <4CC6EA74.3070802@stpeter.im> Date: Tue, 26 Oct 2010 08:49:24 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010604030701060909040609" Cc: Olaf Kolkman , Leslie Daigle , olsona@dc37a.nci.nih.gov Subject: [apps-discuss] helping our friends in the timezone community X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 14:47:42 -0000 This is a cryptographically signed message in MIME format. --------------ms010604030701060909040609 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Apps folks, You might recall from previous IETF meetings that the "timezone database" and worldwide timezone community are looking for a new home because of the planned retirement of the longtime maintainer, Arthur Olson. It's safe to say that we have all relied on the timezone database in one way or another for years, probably without even knowing it. Thus it's important to help the timezone community find the right place to continue its important work. One option, outlined in a new Internet-Draft, is for the IANA and IETF to provide that home: https://datatracker.ietf.org/doc/draft-lear-iana-timezone-database/ Feedback and discussion would be helpful among folks in the IETF applications area, both here on the apps-discuss@ietf.org list and at the upcoming Beijing meeting. Note: discussion is also happening on the primary TZ, to which you can subscribe by sending email to mailto:tz-request@elsie.nci.nih.gov Thanks! Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms010604030701060909040609 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAy NjE0NDkyNFowIwYJKoZIhvcNAQkEMRYEFHgzVdRdvJ3o8nzJTbQQveMNOhRBMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCJ7lx4QQB33owbK8qNKrTEau3TCbkbbtSdav2GEqwZ8bs/q3rCHHV/amjv gR45A7nwTQfaxGgkBxqnfCfDJc6t2rYj0SSlVAIHewe9d4HvvdrUZ63ej/VNbFAZNMw7kPfN 22U6AKDKkavmOT6e5yZAtOk6AllRO2I9HEjLfouXfHYUmWDj5WQb72uIoeaKDIa2BgV2CAxG xJJWG2CgvWGiX2+wmmkTc1SKgNF5agXUArSCYB7Ofbn4XWWO2BIPvCsgP14vux7uLDd8Gg8W UB0SwfrmbERjE0zd6N8SaQSRKK+e6oCRccMKj/xjHbxxJnQQTFLotKOVHsD0QYS+6cJlAAAA AAAA --------------ms010604030701060909040609-- From masinter@adobe.com Mon Oct 25 14:10:01 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14C0F3A68E5 for ; Mon, 25 Oct 2010 14:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.112 X-Spam-Level: X-Spam-Status: No, score=-106.112 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 930R1w6WyoIM for ; Mon, 25 Oct 2010 14:09:58 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by core3.amsl.com (Postfix) with ESMTP id 5930C3A684C for ; Mon, 25 Oct 2010 14:09:57 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKTMXyj6gNfRTUZy6MFRR0Yd/oakI8i0ZC@postini.com; Mon, 25 Oct 2010 14:11:43 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id o9PLBefx007147 for ; Mon, 25 Oct 2010 14:11:41 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id o9PLBVtv027536 for ; Mon, 25 Oct 2010 14:11:39 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Mon, 25 Oct 2010 14:10:41 -0700 From: Larry Masinter To: "apps-discuss@ietf.org" Date: Mon, 25 Oct 2010 14:10:40 -0700 Thread-Topic: MIME and the Web Thread-Index: Act0h0ekUiotQ863R3mibfor+/vMiAAAOZaw Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C68CB012D9182D408CED7B884F441D4D0476B4FEA1nambxv01acorp_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 26 Oct 2010 08:03:03 -0700 Subject: [apps-discuss] MIME and the Web X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 21:10:01 -0000 --_000_C68CB012D9182D408CED7B884F441D4D0476B4FEA1nambxv01acorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've been discussing MIME, its role in web architecture, and some of the pr= oblems using MIME types in the web. Primarily focusing discussion with W3C = Technical Architecture Group (TAG), but comments from all welcome. latest draft: http://www.ietf.org/id/draft-masinter-mime-web-info-01.txt (HTML version to appear http://tools.ietf.org/id/draft-masinter-mime-web-in= fo-01.html in a bit). Larry -- http://larry.masinter.net --_000_C68CB012D9182D408CED7B884F441D4D0476B4FEA1nambxv01acorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve been discussi= ng MIME, its role in web architecture, and some of the problems using MIME types in = the web. Primarily focusing discussion with W3C Technical Architecture Group (T= AG), but comments from all welcome.

 =

latest draft:=

 =

http://= www.ietf.org/id/draft-masinter-mime-web-info-01.txt

(HTML version to appear = http= ://tools.ietf.org/id/draft-masinter-mime-web-info-01.html in a bit).

 =

Larry<= /p>

--

http://larry.masinter.ne= t

 

--_000_C68CB012D9182D408CED7B884F441D4D0476B4FEA1nambxv01acorp_-- From wwwrun@core3.amsl.com Tue Oct 26 11:52:25 2010 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id E5A1E3A6877; Tue, 26 Oct 2010 11:52:24 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20101026185224.E5A1E3A6877@core3.amsl.com> Date: Tue, 26 Oct 2010 11:52:24 -0700 (PDT) Cc: yaojk@cnnic.cn, barryleiba@computer.org, apps-discuss@ietf.org Subject: [apps-discuss] WG Action: Applications Area Working Group (appsawg) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 18:52:25 -0000 A new IETF working group has been formed in the Applications Area. For additional information, please contact the Area Directors or the WG Chairs. Applications Area Working Group (appsawg) --------------------------------------------------- Current Status: Active Working Group Chairs: Barry Leiba Jiankang YAO Applications Area Directors: Alexey Melnikov Peter Saint-Andre Applications Area Advisor: Alexey Melnikov Mailing Lists: General Discussion: apps-discuss@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/apps-discuss Archive: http://www.ietf.org/mail-archive/web/apps-discuss/ Description of Working Group: The Applications Area sometimes receives proposals for the development of specifications dealing with application-related topics that are not in scope for an existing working group and do not justify the formation of a new working group. The Applications Area Working Group (APPSAWG) can serve as a forum for such work in the IETF. The APPSAWG accepts work items in accordance with the consensus of the Working Group and the best judgment of the Applications Area Directors, who are responsible for updating the working group milestones as needed. The working group meets if there are active proposals that require intensive discussion. Work items that are appropriate for the APPSAWG mostly fall under the following topics: (A) Well-defined security issues that are relevant to multiple application technologies (e.g., draft-saintandre-tls-server-id-check). (B) Small-scale additions to the protocol stack for HTTP and other application technologies, mostly related to service discovery and meta-data (e.g., RFC 5785, draft-nottingham-http-link-header, and draft-hammer-hostmeta). (C) Selected other work items addressing topics that historically fall within the Applications Area, such as calendaring, date and time formats, HTTP, internationalization, language tags, MIME, URIs and XML. When considering whether to accept a proposed work item, the APPSAWG and the Applications Area Directors shall take into account the following factors, among others: * There is no existing related Working Group that is willing to recharter to take on this work, and the document doesn't justify the formation of a new working group. * Whether the WG has consensus on the suitability, importance, and projected quality of the proposed work item. * Whether there is a core team of WG participants with sufficient energy and expertise to advance the proposed work item according to the proposed schedule. * Whether there are enough WG participants who are willing to review the work produced by the document authors or editors. * Whether the Area Directors judge that wider input is needed before accepting the proposed work item (e.g., from the IESG, IAB, or another standards development organization). From Martin.Thomson@andrew.com Tue Oct 26 14:48:47 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8282E3A680B for ; Tue, 26 Oct 2010 14:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.871 X-Spam-Level: X-Spam-Status: No, score=-2.871 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOAgd9UdbD-B for ; Tue, 26 Oct 2010 14:48:45 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 78CBF3A68D2 for ; Tue, 26 Oct 2010 14:48:45 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:24705 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S460352Ab0JZVud (ORCPT ); Tue, 26 Oct 2010 16:50:33 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 26 Oct 2010 16:50:33 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 27 Oct 2010 05:50:30 +0800 From: "Thomson, Martin" To: Graham Klyne Date: Wed, 27 Oct 2010 05:50:28 +0800 Thread-Topic: [apps-discuss] draft-saintandre-xdash-considered-harmful-01 Thread-Index: Act0/1qzRIh4jn+fRdC7BfuZrGPFmgAWDnjA Message-ID: <8B0A9FCBB9832F43971E38010638454F03F31EB022@SISPE7MB1.commscope.com> References: <201010212030.WAA26704@TR-Sys.de> <4CC4D9D3.2060003@att.com> <0077AC96FF0947F4AE87DFA7@PST.JCK.COM> <3F3180D3-2925-47E9-92FD-3ED11FAD6D34@standardstrack.com> <8B0A9FCBB9832F43971E38010638454F03F31EAE5F@SISPE7MB1.commscope.com> <4CC608C4.8040209@stpeter.im> <8B0A9FCBB9832F43971E38010638454F03F31EAE68@SISPE7MB1.commscope.com> <4CC693BE.7050302@ninebynine.org> In-Reply-To: <4CC693BE.7050302@ninebynine.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: Discuss Apps IETF Subject: Re: [apps-discuss] draft-saintandre-xdash-considered-harmful-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 21:48:47 -0000 T24gMjAxMC0xMC0yNiBhdCAxOTozOToyNiwgR3JhaGFtIEtseW5lIHdyb3RlOg0KPiBUaG9tc29u LCBNYXJ0aW4gd3JvdGU6DQo+ID4gcHJvdmlzaW9uYWwgcmVnaXN0cmF0aW9ucyBzdGlsbCBoYXZl IGV4Y2x1c2l2aXR5Lg0KPiANCj4gQWN0dWFsbHksIGZvciBtZXNzYWdlIGhlYWRlcnMgdGhleSBk b24ndDoNCg0KTXkgYXBvbG9naWVzLCBJIGp1c3QgcmUtaW52ZW50ZWQgdGhlIHdoZWVsLiAgSSBz aG91bGQgUlRGUkZDLg0KDQpUaGUgY3VycmVudCBwcm9jZXNzIGlzIGZpbmUuDQoNCg== From julian.reschke@gmx.de Thu Oct 28 06:00:02 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FF8E3A69C6 for ; Thu, 28 Oct 2010 06:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.935 X-Spam-Level: X-Spam-Status: No, score=-104.935 tagged_above=-999 required=5 tests=[AWL=-2.336, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UySBv4a1BY4O for ; Thu, 28 Oct 2010 06:00:01 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id AAD303A69C4 for ; Thu, 28 Oct 2010 06:00:00 -0700 (PDT) Received: (qmail invoked by alias); 28 Oct 2010 13:01:49 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.146]) [217.91.35.233] by mail.gmx.net (mp044) with SMTP; 28 Oct 2010 15:01:49 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+ZDPx1ACOZJLvKrZgZtwzOo18SXDc4+UuZQ1nvc8 0NohSHk3nCvcF5 Message-ID: <4CC97437.8010002@gmx.de> Date: Thu, 28 Oct 2010 15:01:43 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: HTTP Working Group , IETF Apps Discuss Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [apps-discuss] Call for feedback: HTML application cache X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2010 13:00:02 -0000 Hi, the HTML5 spec contains a mechanism for offline web applications, see . There are concerns that this may be a use case which could better be handled using existing HTTP caching mechanisms (potentially + extensions). Also, Section 5.6.4 () states: "Note: HTTP caching rules, such as Cache-Control: no-store, are ignored for the purposes of the application cache download process." which might be interpreted as a violation of HTTP requirements (see ): "If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests." The HTML WG has an open issue related to this (), with a CP (Change Proposal) due October 30. Is anybody with *both* HTTP and Web Application background willing to review this section and help with a Change Proposal if needed? (We probably can negotiate a deadline extension if there's a chance to get this right). Best regards, Julian From nomcom2010@gmail.com Thu Oct 28 20:59:13 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ED733A69EC for ; Thu, 28 Oct 2010 20:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.476 X-Spam-Level: X-Spam-Status: No, score=-103.476 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJkQOEzlvNVY for ; Thu, 28 Oct 2010 20:59:11 -0700 (PDT) Received: from mail-qw0-f49.google.com (mail-qw0-f49.google.com [209.85.216.49]) by core3.amsl.com (Postfix) with ESMTP id 82FE83A69F3 for ; Thu, 28 Oct 2010 20:59:11 -0700 (PDT) Received: by qwh6 with SMTP id 6so2716572qwh.22 for ; Thu, 28 Oct 2010 21:01:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=SGIwT1Hf5VGLR+RTMpiG3/diVhRiCweq4JVck5hf97Q=; b=DXHggXYmK5fmd/FnJyglfcK42Utp3XuX8hB61Mab2XGcZGWZMaW7N8OVpcggMWuN6c 8PTtXkmZZtRX4hhkETyRo5dAUGTLFXwQ2tj1JBbsixa64YWNZHz1M4aoES4AUQnLFdg1 ZLS7D7VVZLWZJWEmLduZ0ADdNl4FPpc/4PhTg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=ZDo2XpXLGJQu0PBiScEYI6DDdXw4hEXOfahqdZkxbvkwKqUYJ507ITZu6F2F+8TR95 Wa2lyHqg27Hau3p5bcKKkVVhrtfAC2Sg1joCqY0UEulEKVtdDkQR23Dsrd3lLy9iATA8 pnK2dFCwU0U+qCXVv3sIuClPKW0sVIlbXuqts= MIME-Version: 1.0 Received: by 10.229.96.130 with SMTP id h2mr10143109qcn.284.1288324864439; Thu, 28 Oct 2010 21:01:04 -0700 (PDT) Sender: nomcom2010@gmail.com Received: by 10.220.72.74 with HTTP; Thu, 28 Oct 2010 21:01:04 -0700 (PDT) Date: Thu, 28 Oct 2010 21:01:04 -0700 X-Google-Sender-Auth: ChdaKG7zm8SnWLZ8AiqdYXSvobk Message-ID: From: NomCom-Chair To: nomcom-chair@ietf.org Content-Type: multipart/alternative; boundary=001636426cebe675f90493b98147 X-Mailman-Approved-At: Fri, 29 Oct 2010 09:40:45 -0700 Subject: [apps-discuss] Invitation to provide IETF Nominee Feedback X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 03:59:13 -0000 --001636426cebe675f90493b98147 Content-Type: text/plain; charset=ISO-8859-1 Nomcom 2010-2011 requests your input on the willing nominees for the IETF open positions. We request that as much as possible, comments are provided within two weeks of the receipt of this email. Please provide comments as soon as possible and no later than November 12th. Comments received after the Beijing meeting may receive less consideration, although we will make every effort to consider any and all input. The feedback form is available at the following URL: https://wiki.tools.ietf.org/group/nomcom/10/input/ Note, you must have an IETF tools login to respond to this invitation. If you do not have one, http://www1.tools.ietf.org/newlogin can be used to get one. The web-based feedback tool gives the NomCom an automated process for collecting input on the nominees. Your input will be encrypted before it is stored by the feedback tool, and can only be decrypted by the NomCom. When you access the feedback form, you will see a list of all of the willing nominees. By clicking on a nominee's name, you will be presented with a text-input form into which you can type your input. While we encourage feedback through the form, you may send feedback to the nomcom list, nomcom10@ietf.org, directly. Community feedback is essential for the nomcom process to be effective. Notes on comparison of nominees to each other are also useful to the nomcom. You are also encouraged to provide notes on how a nominee satisfies the IESG/IAB/IAOC's desired expertise; if you feel that the nominee has a different set of skills necessary for the job and those skills are different from the posted requirements, please provide details. If you prefer to provide anonymous input, please send it directly to the nomcom chair, Tom Walsh, or any other member of the nomcom and request them to anonymize your input. All information provided to the nomcom and the sources of such information are confidential. Thanks in advance for your feedback. Regards, Thomas Walsh NomCom 2010-11 nomcom10@ietf.org nomcom-chair@ietf.org --001636426cebe675f90493b98147 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Nomcom 2010-2011 requests your input on the willing nominees for the IETF open positions.

We request that as much as possible, comments are provided within two weeks of the receipt of this email.=A0 Please provide comments as soon as=
possible and no later than November 12th.=A0 Comments received after t= he
Beijing meeting may receive less consideration, although we will make every=
effort to consider any and all input.

The feedback form is available at the following URL:
=A0 https://wiki.tools.ietf.= org/group/nomcom/10/input/

Note, you must have an IETF tools login to respond to this invitation. <= br>If you do not have one,
=A0=A0=A0 http://www1.tools.ietf.org/newlogin
can be used to get= one.

The web-based feedback tool gives the NomCom an automated process for collecting input on the nominees.=A0 Your input will be encrypted before =
it is stored by the feedback tool, and can only be decrypted by the Nom= Com.=A0

When you access the feedback form, you will see a list of all of the willing nominees.=A0 By clicking on a nominee's name, you will be pres= ented
with a text-input form into which you can type your input.=A0

While we encourage feedback through the form, you may send feedback to <= br>the nomcom list, nomcom10@ietf.org<= /a>, directly.

Community feedback is essential for the nomcom process to be effective. =
Notes on comparison of nominees to each other are also useful to the nomcom. You are also encouraged to provide notes on how a nominee
satisfies the IESG/IAB/IAOC's desired expertise; if you feel that the <= br>nominee has a different set of skills necessary for the job and those skills are different from the posted requirements, please provide
details.

If you prefer to provide anonymous input, please send it directly to the nomcom chair, Tom Walsh, or any other member of the nomcom and
req= uest them to anonymize your input.=A0 All information provided to the
nomcom and the sources of such information are confidential.
Thanks in = advance for your feedback.

Regards,
Thomas Walsh
NomCom 2010-11 nomcom10@ietf.org
nomcom-chair@ietf.org


=A0

--001636426cebe675f90493b98147-- From barryleiba.mailing.lists@gmail.com Sun Oct 31 02:21:26 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F34F83A67E5 for ; Sun, 31 Oct 2010 02:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.38 X-Spam-Level: X-Spam-Status: No, score=-102.38 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lRswu9QGSaE for ; Sun, 31 Oct 2010 02:21:25 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 13B943A63EB for ; Sun, 31 Oct 2010 02:21:25 -0700 (PDT) Received: by iwn40 with SMTP id 40so5989958iwn.31 for ; Sun, 31 Oct 2010 02:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=fyIGsun8XTCAI1FwJKQvszU91hY/rYLdQZ2+4LN0C0w=; b=hI17E7kHk2keHIMSoxImApyIwXtoMxURANfzGc5GLH4shrrV7WMfgpUWfAG1Js0RVR AtPD+d6S8lP9wkQHwe9oflvsMXeLARUNkNGIpOZ/JBluL1yyN++L/a+ExZzLHhcSSoxG 9KSzcerlcexYebw9irUCk3X+rp6NKSYpte5NQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=uOhDoKD+sly5xLyMt+/TwX4dQDm/dJuH5A9dchWanJ9W60/hbfPSxB3M2r4NUf8uyH saFUnPtRb3WIw0WlZyF3SgZJ2QI2vy3EveBwx/2Z5Q3nyhsgnXwMif1L4KAESplgmfjw 7o1mYqMYQE3NGIeXqKWL5FjPTjszlndt2Yc0g= MIME-Version: 1.0 Received: by 10.42.207.202 with SMTP id fz10mr10503137icb.374.1288517003574; Sun, 31 Oct 2010 02:23:23 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.42.229.200 with HTTP; Sun, 31 Oct 2010 02:23:23 -0700 (PDT) Date: Sun, 31 Oct 2010 17:23:23 +0800 X-Google-Sender-Auth: G1AYBBLuc9Pw8Avcge9l1D8A668 Message-ID: From: Barry Leiba To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] Startup of the APPSAWG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 09:21:26 -0000 As y'all may have seen, the IESG approved the creation of the Applications Area Working Group (appsawg), and appointed Jiankang Yao and me as working group chairs. The charter is here: http://www.ietf.org/dyn/wg/charter/appsawg-charter In order to get things started, we need to do two things: 1. Set up procedures for how the working group will operate. 2. Choose some documents to work on. To that end, we'll be having the first face-to-face meeting of the appsawg during (as part of) the Applications Area open meeting at IETF 79, in the Monday morning slot (9 to 11:30 a.m., 8 Nov). Email discussion related to appsawg will happen on this mailing list, the apps-discuss list. For item 1, here's a set of sub-items the chairs think we need to decide: 1a. What criteria will we use to decide that a document should be handled by appsawg? Implicit in this is how we decide that the document doesn't belong in an existing working group, and that the authors shouldn't be working on forming a new one. I note that it may be the case that the ADs are already, by suggesting a document to us, advising that they don't want a new working group for the work. I suggest that sometimes, part of this working group's job may be to push back on that and say, "We disagree. The scope of this work is beyond what appsawg should be taking up, and you should reconsider your advice to the authors." 1b. How can we ensure that we provide a reasonable level of review and discussion of documents that come to us? Who is willing to actively participate? 1c. What will the exit criteria for documents be? How will we be satisfied that a document is done? As for initial documents, the ADs have suggested the following ones, and if there's time in Beijing to go over them and have some initial discussion about adoption, we'll put them on the agenda. Please try to review them before then. 2a. draft-merrick-jms-uri 2b. draft-nottingham-http-portal 2c. draft-faltstrom-5892bis (update of IDNA to handle Unicode 6.0) Comments on any of this prior to IETF 79 are also, of course, welcome. Barry and Jiankang, your friendly neighbourhood chairs From GK@ninebynine.org Sun Oct 31 03:41:24 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2696C3A681F for ; Sun, 31 Oct 2010 03:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.238 X-Spam-Level: X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EDRFQxe7vSZ for ; Sun, 31 Oct 2010 03:41:23 -0700 (PDT) Received: from relay0.mail.ox.ac.uk (relay0.mail.ox.ac.uk [129.67.1.161]) by core3.amsl.com (Postfix) with ESMTP id BC2683A67B7 for ; Sun, 31 Oct 2010 03:41:22 -0700 (PDT) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay0.mail.ox.ac.uk with esmtp (Exim 4.71) (envelope-from ) id 1PCVNc-0001Mh-1c; Sun, 31 Oct 2010 10:43:16 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PCVNc-0003Ry-49; Sun, 31 Oct 2010 10:43:16 +0000 Message-ID: <4CCD4428.9000005@ninebynine.org> Date: Sun, 31 Oct 2010 10:25:44 +0000 From: Graham Klyne User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Startup of the APPSAWG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 10:41:24 -0000 Hi, I won't be at your meeting, but some thoughts I have about your questions: Barry Leiba wrote: > 1a. What criteria will we use to decide that a document should be > handled by appsawg? Implicit in this is how we decide that the > document doesn't belong in an existing working group, and that the > authors shouldn't be working on forming a new one. I note that it may > be the case that the ADs are already, by suggesting a document to us, > advising that they don't want a new working group for the work. I > suggest that sometimes, part of this working group's job may be to > push back on that and say, "We disagree. The scope of this work is > beyond what appsawg should be taking up, and you should reconsider > your advice to the authors." My first thought was that the criteria shouldn't be too rigid - there should be scope for judgement. But having reasonably transparent grounds for rejection is also helpful. Aside from any technical criteria, I'd suggest that having a reasonable expectation that the work can be completed in (say) 6 months (or some other reasonable figure) - if not, then a dedicated WG probably should be considered. I think 1b and 1c also suggest acceptance criteria: * interested and willing reviewers should be identified * exit criteria should be clear before a documented is accepted. > 1b. How can we ensure that we provide a reasonable level of review and > discussion of documents that come to us? Who is willing to actively > participate? > > 1c. What will the exit criteria for documents be? How will we be > satisfied that a document is done? Among other things, I'd suggest a time-box, so that if the work is not complete within a specified time, and support cannot be mustered again for re-acceptance of the work-in-progress documents according to the original accptance criteria, it automatically be dropped. #g From alexey.melnikov@isode.com Sun Oct 31 06:10:13 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A06473A696B for ; Sun, 31 Oct 2010 06:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.627 X-Spam-Level: X-Spam-Status: No, score=-102.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ro1VELZDoU6l for ; Sun, 31 Oct 2010 06:10:10 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id A984F3A696C for ; Sun, 31 Oct 2010 06:10:09 -0700 (PDT) Received: from [192.168.20.2] ((unknown) [212.183.140.39]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 31 Oct 2010 13:12:05 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4CCD6B0B.5040804@isode.com> Date: Sun, 31 Oct 2010 13:11:39 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: apps-discuss@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------070008000808000709070507" Subject: [apps-discuss] [Fwd: Fwd: WGLC Announcement for draft-ietf-tsvwg-iana-ports-08 - 26th November 2010] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 13:10:13 -0000 This is a multi-part message in MIME format. --------------070008000808000709070507 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit FYI. --------------070008000808000709070507 Content-Type: message/rfc822; name="Fwd: WGLC Announcement for draft-ietf-tsvwg-iana-ports-08 - 26th November2010.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Fwd: WGLC Announcement for draft-ietf-tsvwg-iana-ports-08 - 26th November2010.eml" Return-Path: Received: from rufus.isode.com ([62.3.217.251]) by canine.isode.net (Isode M-Box/14.6a5) with LMTP; Sat, 30 Oct 2010 09:01:04 +0100 (BST) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [139.133.204.82]) by rufus.isode.com (smtp external) via TCP with ESMTP id for ; Sat, 30 Oct 2010 09:01:04 +0100 Received: from Gorry-Fairhursts-MacBook-Pro.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id o9U80wnl027211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 30 Oct 2010 09:00:59 +0100 (BST) Message-ID: <4CCBD0BB.4050100@erg.abdn.ac.uk> Date: Sat, 30 Oct 2010 09:00:59 +0100 From: Gorry Fairhurst User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "tsvwg-chairs@tools.ietf.org" , Alexey Melnikov Subject: Fwd: WGLC Announcement for draft-ietf-tsvwg-iana-ports-08 - 26th November 2010 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk X-Spam-Status: No Alexey, Could you please cross post (as the responsible AD to Apps and IESG)? Thanks, Gorry -------- Original Message -------- Subject: WGLC Announcement for draft-ietf-tsvwg-iana-ports-08 - 26th November 2010 Date: Sat, 30 Oct 2010 08:59:35 +0100 From: Gorry Fairhurst To: tsvwg list CC: tsvwg-chairs@tools.ietf.org This email announces the beginning of a working group last call for draft-ietf-tsvwg-iana-ports-08, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry". This document is now thought to be ready to proceed to be published as a BCP. Please send any comments to the TSVWG list. The draft is available at: http://tools.ietf.org/html/draft-ietf-tsvwg-iana-ports-08 The document will be forwarded in parallel to the Apps Area for review. The last call will run for FOUR weeks, ending Friday, 26th November 2010 (this LC period will cover an IETF meeting). Emails saying "I support" or "I don't support" publication are also most helpful in judging the WG consensus. James and Gorry (TSVWG Chairs) --------------070008000808000709070507--