From dev+ietf@seantek.com Sat Nov 2 23:47:49 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F56821E80AB; Sat, 2 Nov 2013 23:47:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sMZ0XTutQrA; Sat, 2 Nov 2013 23:47:43 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 2714611E819C; Sat, 2 Nov 2013 23:47:43 -0700 (PDT) Received: from [172.20.10.2] (unknown [70.208.69.85]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9432C509B5; Sun, 3 Nov 2013 01:47:41 -0500 (EST) From: Sean Leonard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <5116BF35-064E-435C-A2BE-9113DE25D44D@seantek.com> Date: Sat, 2 Nov 2013 23:47:40 -0700 To: urn-nid@ietf.org, saag@ietf.org, apps-discuss@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [apps-discuss] New version of certspec (01); request review and URN assignment X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 06:47:53 -0000 Hello URN/Apps folks, and SAAG folks: A new version of the Internet-Draft draft-seantek-certspec (01) has been = posted to the IETF repository. I would like to notify this list for = commentary, and utlimately to apply for the URN NID 'cert'. Compared to 00 last year, this version adds discussion of the need for a = uniform way to identify certificates by name in a URI/URN, the = differences between this naming scheme and the ni: URI scheme (RFC = 6920), and a methodology to /resolve/ certain various classes of cert = URNs to ni, http, ldap, and other URI schemes. Kind regards, Sean ************** A new version of I-D, draft-seantek-certspec-01.txt has been successfully submitted by Sean Leonard and posted to the IETF repository. Filename: draft-seantek-certspec Revision: 01 Title: A Uniform Resource Name (URN) Namespace for = Certificates Creation date: 2013-10-21 Group: Individual Submission Number of pages: 13 URL: = http://www.ietf.org/internet-drafts/draft-seantek-certspec-01.txt Status: http://datatracker.ietf.org/doc/draft-seantek-certspec Htmlized: http://tools.ietf.org/html/draft-seantek-certspec-01 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-seantek-certspec-01 Abstract: Digital certificates are used in many systems and protocols to identify and authenticate parties. This document describes a Uniform Resource Name (URN) namespace that identifies certificates. These URNs can be used when certificates need to be identified by value or reference. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From superuser@gmail.com Sat Nov 2 23:52:57 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25EF011E819C for ; Sat, 2 Nov 2013 23:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VndOsp6NLeVp for ; Sat, 2 Nov 2013 23:52:56 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9A26111E81AC for ; Sat, 2 Nov 2013 23:52:55 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id b13so968074wgh.15 for ; Sat, 02 Nov 2013 23:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ccbCa+f9WHnFzZKdkYITt5QcmEJ6Sm1G8WNCquSnE4A=; b=J5HN0G0W2dhWvYYRM6rFGV45agOP/pvTJynfI/XhrRTr7E+GQyXYANkB8OAGoWCdhY zSVxETu060PF8KTBugVZgC4f2CJWGWBDHy05nE1mV8nexgbLQdKXrPGJJBfgdDUDXTPk SaUV73IBSm+T6UDzqbGp4xdwBmjFv8hPM3M7cwSSetG/ZnGaiV1c9Nhh7zHpZdwyULyU FFR8+/6YyGM1A8t/JJyceaZvWunXRcBKowit60g4iONiRflzP7GB9dASV4BUB7JNQPBd e4zLlXqYkLXgQ942i967V1jys6RTwpegaWu0Oo6dYxbKvHkicHAm9QNqZ1ocuCdUFgFO QK6Q== MIME-Version: 1.0 X-Received: by 10.180.19.133 with SMTP id f5mr8051145wie.60.1383461574700; Sat, 02 Nov 2013 23:52:54 -0700 (PDT) Received: by 10.180.18.202 with HTTP; Sat, 2 Nov 2013 23:52:54 -0700 (PDT) Date: Sat, 2 Nov 2013 23:52:54 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=bcaec53f37e5b8797004ea403f79 Subject: [apps-discuss] Slides! (was Re: Revised IETF 88 APPSAWG/APPAREA agenda posted) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 06:52:57 -0000 --bcaec53f37e5b8797004ea403f79 Content-Type: text/plain; charset=ISO-8859-1 Reminder: Those of you on the agenda, please submit your slides by 10pm Pacific time tomorrow if you want them used during the meeting or included in the proceedings. -MSK On Thu, Oct 31, 2013 at 12:05 PM, Murray S. Kucherawy wrote: > http://www.ietf.org/proceedings/88/agenda/agenda-88-appsawg > > We are still finalizing the security-related presentations, so there may > be one small update between now and Monday. > > See you all there! > > -MSK, APPSAWG co-chair > --bcaec53f37e5b8797004ea403f79 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Reminder: Those of you on the agenda, please submit y= our slides by 10pm Pacific time tomorrow if you want them used during the m= eeting or included in the proceedings.

-MSK


On Thu, Oct 31, 2013 at 12:05 PM, Murray= S. Kucherawy <superuser@gmail.com> wrote:
We are still finalizing the sec= urity-related presentations, so there may be one small update between now a= nd Monday.

See you all there!

-MSK, APPSAWG co-chair

--bcaec53f37e5b8797004ea403f79-- From david.black@emc.com Fri Nov 1 18:32:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C6211E80E9; Fri, 1 Nov 2013 18:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azARdMI8AdOg; Fri, 1 Nov 2013 18:32:43 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 6053F11E80E7; Fri, 1 Nov 2013 18:32:43 -0700 (PDT) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rA21WXvh031172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Nov 2013 21:32:33 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com rA21WXvh031172 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1383355954; bh=vFy9Uc7OwUUY6NR5/3KmfYthlb0=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=YYSo0+oB9/4ThNeBBEccASLa7pGuEvsT/5Efhe32fPanFha1AmGPBiX2IIJQxDoQ2 hAf5CgVfjYALlQ0OUAqZQRJ1sKYMTgQKDQlwPYKHek/LSc4A9wQ4fKJ7q13ZBcoZQ1 qeQSbyoEMwlApbGzJhgc5koc4ixLRSq75yqKGFbU= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com rA21WXvh031172 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd55.lss.emc.com (RSA Interceptor); Fri, 1 Nov 2013 21:32:25 -0400 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rA21WOUm014873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Nov 2013 21:32:24 -0400 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Fri, 1 Nov 2013 21:32:24 -0400 From: "Black, David" To: "Murray S. Kucherawy (superuser@gmail.com)" , "gshapiro@proofpoint.com" , "ned.freed@mrochek.com" , "General Area Review Team (gen-art@ietf.org)" Date: Fri, 1 Nov 2013 21:32:23 -0400 Thread-Topic: Gen-ART review of draft-ietf-appsawg-malformed-mail-09 Thread-Index: Ac7Xa12dzFVGhnZdR0m8P/d5wkHADg== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026AAEBA81@MX15A.corp.emc.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public X-Mailman-Approved-At: Sun, 03 Nov 2013 00:57:07 -0700 Cc: "Black, David" , "Barry Leiba \(barryleiba@computer.org\)" , "ietf@ietf.org" , "apps-discuss@ietf.org" Subject: [apps-discuss] Gen-ART review of draft-ietf-appsawg-malformed-mail-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 01:32:47 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-appsawg-malformed-mail-09 Reviewer: David L. Black Review Date: November 1, 2013 IETF LC End Date: October 29, 2013 IESG Telechat date: November 21, 2013 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This draft discusses common errors in mail message syntax and provides useful guidance on handling them. The draft is well written and likely to be of significant value to implementers. Most of my comments relate to clarity, but none of them seem important enough to be characterized as issues that really have to be fixed, although the sloppy terminology usage in Sections 7.1.* comes close. I apologize for this review appearing slightly after the end of IETF Last Call - there is too much going on in the weeks immediately before this IETF meeting. Nits/editorial comments: The word "naked" is used a few times to refer to something that occurs in isolation, without enclosure in another construct, e.g., a naked CR. This idiomatic use of "naked" should be explained before it is used. In Section 1.1, I have always heard Postel's law as: - Be conservative in what you send, and - Be liberal in what you accept. The change from "do" in this draft to "send" (above) seems useful, as it should help focus the discussion in the second paragraph of Section 1.1 - Postel's law, as I have understood it, has never blessed anything remotely resembling there being "no limits to the liberties that a sender might take." Section 5's section title "Mail Submission Agents" doesn't seem to be connected to its MHS and MTA content. It would be useful to add a sentence to remind readers, including this one ;-), of what Mail Submission Agents are. Sections 7.1.* offers degrees of advice qualified by "safely", "usually", "reasonably" and "should". There appear to be only two concepts: - "safely": Do this all the time. - "usually", "reasonably", "should": This is the recommended course of action, but there may be exceptions. While RFC 2119 is not intended for Informational documents, this is an example of the sort of sloppiness that RFC 2119 is intended to clean up. At the very least, the use of three words for essentially the same concept is poor form, and RFC 2119 can be used in an Informational document when appropriate caveats are provided in the terminology section that references it. In Section 7.1.4, "Likewise" is not a good way to associate the second example with the first, because it handles the missing parenthesis in a rather different fashion (adds quotes instead of inserting the missing parenthesis character). In Section 7.7, the first use of "8bit" occurs in "8bit material" but some = of the subsequent occurrences omit the word "material" - that word should be used with all occurrences. idnits 2.13.00 generated a couple of warnings about obsolete references: -- Obsolete informational reference (is this intentional?): RFC 1113 (ref= . 'PEM') (Obsoleted by RFC 1421) -- Obsolete informational reference (is this intentional?): RFC 733 (Obsoleted by RFC 822) In both cases, the reference appears to be intentional, and the warning should be ignored. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From sm@elandsys.com Sun Nov 3 07:06:53 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE8321E8096; Sun, 3 Nov 2013 07:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.533 X-Spam-Level: X-Spam-Status: No, score=-103.533 tagged_above=-999 required=5 tests=[AWL=-0.934, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JV-A+k3cYkiP; Sun, 3 Nov 2013 07:06:52 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E77A21E80AA; Sun, 3 Nov 2013 07:06:48 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.135.62]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rA3F6TkU020305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Nov 2013 07:06:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1383491201; bh=pPOa4jALFBTeN5M53rZC/w6zk1VicoewdOczN283kBg=; h=Date:To:From:Subject:Cc; b=eyNLukKLUB+hoXZGzRlhWULTh4mcBI5XSSwjjluPOvOjjpOSmBzNXv5yjWFKx1U70 OMlYbk13lUo7RDqtoGu41MvGIEe7DylZ36Rl4TJxVGcR9LvO2Y2y8HKmwTM1jCASjG Jw6Vz1w16wI43yRlFbFfkWjz2zGFITABuBGmKnG4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1383491201; i=@elandsys.com; bh=pPOa4jALFBTeN5M53rZC/w6zk1VicoewdOczN283kBg=; h=Date:To:From:Subject:Cc; b=NS3+vSAAVO24U6Bl5mcuMYQQyW99PLmBoZKy1p6PJhJudyhWhBJpFdDp/l/vIZ49c XPzuARR9rAJZeRtF/FRZpcC2ivIWbSjVbkPUQpwMsuzurezCXwitbcUoeiLLIn894/ J9DeYYcv58TO+sCIvjSQIoEz6lkP70lGR9VFS2Uw= Message-Id: <6.2.5.6.2.20131103061113.0db92cb8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 03 Nov 2013 07:01:22 -0800 To: apps-discuss@ietf.org, draft-ietf-httpbis-method-registrations.all@tools.ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ietf-http-wg@w3.org, iesg@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-httpbis-method-registrations-13 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 15:06:54 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). 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-httpbis-method-registrations-13 Title: Initial Hypertext Transfer Protocol (HTTP) Method Registrations Reviewer: S. Moonesamy Review Date: November 3, 2013 IETF Last Call Date: October 21, 2013 Summary: This draft is nearly reading for publication as an Informational RFC. The document registers those Hypertext Transfer Protocol (HTTP) methods which have been defined in standards-track RFCs before the IANA HTTP Method Registry was established. The methods listed in the document is generally used for WebDAV. Some of the HTTP methods are extensions to HTTP. The (new) registry does not provide any information to distinguish between a method which is part of basic HTTP features and a method which is part of an extension to HTTP. Major Issues: None Minor Issues: I suggest having the HTTP method names being registered in Section 3 instead of Appendix A as the document is not of much use with that main information. Nits: The LINK and UNLINK HTTP methods are defined in RFC 2068 which was obsoleted by RFC 2616. I gather that they are listed so that the method name is not reused. Editorial nits are not included in this review. Regards, S. Moonesamy From dret@berkeley.edu Sun Nov 3 09:27:48 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844AD11E821D for ; Sun, 3 Nov 2013 09:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Qsydtxdrdcy for ; Sun, 3 Nov 2013 09:27:44 -0800 (PST) Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3C35511E8196 for ; Sun, 3 Nov 2013 09:27:43 -0800 (PST) Received: from [207.194.238.3] (helo=dretair.local) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1Vd1Sg-0007Ng-Gt for apps-discuss@ietf.org; Sun, 03 Nov 2013 09:27:43 -0800 Message-ID: <5276878A.6000802@berkeley.edu> Date: Sun, 03 Nov 2013 09:27:38 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "apps-discuss@ietf.org application-layer protocols" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] proposal: adding profile support to JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 17:27:48 -0000 hello. seeing that http://tools.ietf.org/html/draft-ietf-json-rfc4627bis is making good progress, i wanted to raise the question of maybe adding profile support to the JSON media type. http://tools.ietf.org/html/draft-wilde-atom-profile is a proposal for adding profile support to the atom media type, and the "profile" optional media type parameter (http://tools.ietf.org/html/draft-wilde-atom-profile-02#section-4.1.1) is what could be added to JSON as well. the advantage would be that different JSON-based formats could be distinguished by their (mediatype+profile). this would allow JSON-based formats to become more visible on the web level, instead of always just saying "i am JSON", without any ability to differentiate. thanks and cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From daniel.spangler@gmail.com Sun Nov 3 19:40:14 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507CD11E8281 for ; Sun, 3 Nov 2013 19:40:14 -0800 (PST) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Po2GYlASc5cC for ; Sun, 3 Nov 2013 19:40:12 -0800 (PST) Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7D60311E828E for ; Sun, 3 Nov 2013 19:40:08 -0800 (PST) Received: by mail-bk0-f49.google.com with SMTP id w14so2616200bkz.36 for ; Sun, 03 Nov 2013 19:40:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/uhLQuRmg0NwvNPpRLWty43B6b7mhYdO4Wc2svvJT7M=; b=ZO/Wxrg0VLUP/vhMNFXDfPqqsTOhveb7UXY+w/PNU+fQk8DdFimzz0I+z1Lu/MNvRp JBfaDaz9rAmd2hHN2tt1x2pbeJ4+M/U+bddhLx6MG5nCSoGrml+8FPcpWIUYPjAidBoX cgKu4gSJ5N90z8vi1fzapRi6tTWaXULCUxO4xMxVXvXkwTq46vZxThUJ79JYzX8ohDHD Xo2Uiqh2BshdZc1sVxiwIJ6aMCQUHW880mtlGu1kgkUzbaEgZV537Z9/6mwDMLUsT5QT LVUBJXbGZwJDtmwcDXRE3UaHg9nh2C9ah63IO8KX2zML/1FaNWc8TB22cMHuDuxk5okg uuMA== MIME-Version: 1.0 X-Received: by 10.204.245.4 with SMTP id ls4mr136083bkb.33.1383536406211; Sun, 03 Nov 2013 19:40:06 -0800 (PST) Received: by 10.205.36.70 with HTTP; Sun, 3 Nov 2013 19:40:06 -0800 (PST) Date: Sun, 3 Nov 2013 22:40:06 -0500 Message-ID: From: Daniel Spangler To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=f46d041c5fa807d2b104ea51acbc Subject: [apps-discuss] draft-nottingham-http-problem-04 and content types X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2013 03:41:52 -0000 --f46d041c5fa807d2b104ea51acbc Content-Type: text/plain; charset=ISO-8859-1 Hi, I recently stumbled upon this and am very excited about it, because I feel like I've built something like this several times in an ad hoc way. I've been thinking about implementing a version of it for fun, and was curious to get your opinion on how you think content type negotiation should occur. The spec introduces two new content types application/api-problem+xml and application/api-problem+json that an error response would contain. How do you envision knowing which one of these to return? Would it be something statically defined, derived from the accept type, or specifically declared in the accept type? Is there any concern with returning a content type that is not explicitly defined in the accept header? Sincerely, Daniel Spangler --f46d041c5fa807d2b104ea51acbc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,=A0

I recently stumbled upon this an= d am very excited about it, because I feel like I've built something li= ke this several times in an ad hoc way. =A0I've been thinking about imp= lementing a version of it for fun, and was curious to get your opinion on h= ow you think content type negotiation should occur.

The spec introduces two new content types application/<= span style=3D"color:rgb(0,0,0);font-size:1em">api-problem+xml and applicati= on/api-problem+json t= hat an error response would contain.

<= font color=3D"#000000">How do you envision kn= owing which one of these to return? =A0Would it be something statically def= ined, derived from the accept type, or specifically declared in the accept = type? =A0Is there any concern with returning a content type that is not=A0<= /span>explicitly=A0defined in the accept head= er?

<= span style=3D"color:rgb(0,0,0);font-size:1em">Sincerely,
<= span style=3D"color:rgb(0,0,0);font-size:1em">
Daniel Spangler



--f46d041c5fa807d2b104ea51acbc-- From dret@berkeley.edu Sun Nov 3 19:54:44 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6923121E8089 for ; Sun, 3 Nov 2013 19:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOLGjy9oj50e for ; Sun, 3 Nov 2013 19:54:40 -0800 (PST) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 40CB611E817B for ; Sun, 3 Nov 2013 19:54:40 -0800 (PST) Received: from [207.194.238.3] (helo=dretair.local) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1VdBFJ-0000ww-Bd; Sun, 03 Nov 2013 19:54:34 -0800 Message-ID: <52771A72.8090604@berkeley.edu> Date: Sun, 03 Nov 2013 19:54:26 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Daniel Spangler , apps-discuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] draft-nottingham-http-problem-04 and content types X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2013 03:54:44 -0000 hello daniel. On 2013-11-03, 19:40 , Daniel Spangler wrote: > The spec introduces two new content types application/api-problem+xml > and application/api-problem+json that an error response would contain. > How do you envision knowing which one of these to return? Would it be > something statically defined, derived from the accept type, or > specifically declared in the accept type? Is there any concern with > returning a content type that is not explicitly defined in the accept > header? i don't think there's anything special about the HTTP problem types here. if a server supports both variants, and a client does not specify a preferred variant, or does not distinguish which one it prefers when asking for both, then it's up to the server to respond which whatever it thinks is the better default choice: - maybe JSON because on average, people seem to like JSON better these days. - maybe XML, because you can associate it with an XSLT and thus render a nice human-readable response in a browser. it really is up to the server to decide what to do; it could even serve XML/XSLT to browser clients, and JSON to non-browser clients. as http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-24#section-5.3.2 puts it: "A request without any Accept header field implies that the user agent will accept any media type in response." cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From julian.reschke@greenbytes.de Sun Nov 3 22:25:51 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B51A11E81A0; Sun, 3 Nov 2013 22:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8sYvN6UOBKl; Sun, 3 Nov 2013 22:25:46 -0800 (PST) Received: from central.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by ietfa.amsl.com (Postfix) with ESMTP id C4B4311E8178; Sun, 3 Nov 2013 22:25:42 -0800 (PST) Received: from [31.133.150.89] (unknown [31.133.150.89]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by central.greenbytes.de (Postfix) with ESMTPSA id 8638010C03EE; Mon, 4 Nov 2013 07:25:35 +0100 (CET) Message-ID: <52773DDE.8010807@greenbytes.de> Date: Mon, 04 Nov 2013 07:25:34 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: S Moonesamy , apps-discuss@ietf.org, draft-ietf-httpbis-method-registrations.all@tools.ietf.org References: <6.2.5.6.2.20131103061113.0db92cb8@elandnews.com> In-Reply-To: <6.2.5.6.2.20131103061113.0db92cb8@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ietf-http-wg@w3.org, iesg@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-httpbis-method-registrations-13 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2013 06:25:51 -0000 On 2013-11-03 16:01, S Moonesamy wrote: > ... > The document registers those Hypertext Transfer Protocol (HTTP) methods > which have been defined in standards-track RFCs before the IANA HTTP > Method Registry was established. The methods listed in the document is > generally used for WebDAV. > > Some of the HTTP methods are extensions to HTTP. The (new) registry All of them (for some value of "extension"). > does not provide any information to distinguish between a method which > is part of basic HTTP features and a method which is part of an > extension to HTTP. There is no such distinction. > Major Issues: None > > Minor Issues: > > I suggest having the HTTP method names being registered in Section 3 > instead of Appendix A as the document is not of much use with that main > information. Already done in . > Nits: > > The LINK and UNLINK HTTP methods are defined in RFC 2068 which was > obsoleted by RFC 2616. I gather that they are listed so that the > method name is not reused. They are listed in order to provide a reference to the best description that we have today. > Editorial nits are not included in this review. > > Regards, > S. Moonesamy Best regards, Julian -- bytes GmbH, Hafenweg 16, D-48155 Münster, Germany Amtsgericht Münster: HRB5782 From ray.polk@oracle.com Sun Nov 3 22:45:19 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D845B21F9FC3; Sun, 3 Nov 2013 22:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeKmwc3D2T3Z; Sun, 3 Nov 2013 22:45:14 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id A8A2021E8131; Sun, 3 Nov 2013 22:45:09 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA46j2HH014963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Nov 2013 06:45:03 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA46j13W024255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Nov 2013 06:45:01 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA46j1Ig024240; Mon, 4 Nov 2013 06:45:01 GMT MIME-Version: 1.0 Message-ID: <4bff41ab-7997-429a-83f5-dae237ec7899@default> Date: Sun, 3 Nov 2013 22:45:00 -0800 (PST) From: Ray Polk To: , X-Mailer: Zimbra on Oracle Beehive Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: ietf-http-wg@w3.org, iesg@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-httpbis-p4-conditional-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2013 06:45:20 -0000 I have been selected as the Applications Area Directorate reviewer for this= draft (for background on APPSDIR, please see http://trac.tools.ietf.org/ar= ea/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you m= ay receive. Please wait for direction from your document shepherd or AD bef= ore posting a new version of the draft. Document: draft-ietf-httpbis-p4-conditional-24 Title: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests Reviewer: Ray Polk Review Date: November 3, 2013 Major Issues: None Minor Issues: 1) This section is slightly vague: 2.1. Weak versus Strong -- "A strong validator might change for other reaso= ns, such as when a semantically significant part of the representation meta= data is changed (e.g., Content-Type), but it is in the best interests of th= e origin server to only change the value when it is necessary to invalidate= the stored responses held by remote caches" It might benefit from clarification and an example: clarification - "for other reasons" to "for reasons other than changes to t= he body" example of a change to Contet-Type that wouldn't result in change to the bo= dy (e.g. /text/json to /application/json) 2) relax SHOULD to MAY for Last-Modified when ETag is also supplied in the = following sections: 2.2.1. Generation "An origin server SHOULD send Last-Modified for any selected representation= for which a last modification date can be reasonably and consistently dete= rmined," 2.4. When to Use=E2=80=A6 -- also says origin servers SHOULD send both ETag & Last-Modified; consider= relaxing the SHOULD for Last-Modified or make the SHOULD contingent on abs= ence of ETag. Given that headers aren't currently compressed, unnecessary headers can lea= d to unexpected impact on payload sizes. Given that Last-Modified is redun= dant with weak ETags and inferior to strong ETags, when an ETag is supplied= by the origin-server, origin-servers should be allowed the discretion of M= AY provide Last-Modified instead of SHOULD. Subpoint 2 in "2.4. A client" supports the "SHOULD only respond with Last-M= odified if no ETag is available" point of view ("SHOULD send the Last-Modif= ied value in non-subrange cache validation requests (using If-Modified-Sinc= e) if only a Last-Modified value has been provided by the origin server.") 6. Precedence Section six further supports this point of view. When both are sent by the= user agent, Last-Modified is always ignored. If the provision for sending both headers both directions all the time is t= o support HTTP/1.0 caches, be sure to state that as the reasoning in the re= levant places. 3) shared weak ETags 2.3.3. Note An encoded representation and an un-encoded representation can share a weak= entity tag. Right? Nits: None From superuser@gmail.com Sun Nov 3 23:29:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D88111E8192 for ; Sun, 3 Nov 2013 23:29:18 -0800 (PST) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9l9KOL+3J-qv for ; Sun, 3 Nov 2013 23:29:17 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 9387111E80DC for ; Sun, 3 Nov 2013 23:29:17 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id x12so1660957wgg.28 for ; Sun, 03 Nov 2013 23:29:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=OfHCQQVI+1nGunDd1luf4fpXaNaatMs/O8Vy/rT++qc=; b=nuzhoM09gPIVsuibUPpzfh9+I61H1wCsdqH9w1dJRkCJ46de14NcUKK46KaEL4pQ6/ uELyy/iARc9Ou/+hBNj0phMjVBcEeTL5egKCb4d0gSJWpbEAqDY87AggVWaULIzGaFbV DeAEa4PLe4zx7BT292t0iQ13JIG6f0Z37Im+K3rFIXge/dm0B7ERDXXfsCQaHTnQeUE7 ig4197Ntm3btp1h2sbx8fml/HB2bXSCdOCZiHcaJf7jTOW3+6V2mfok8sc6ftR+ziaUw ts3NQTzqJD2w/2LyBFGT5GV0lSQpvOXP+91B+JI5PHuH9+5uV/Lkhf6uEz1xCBCh2MX4 cwJw== MIME-Version: 1.0 X-Received: by 10.180.83.194 with SMTP id s2mr11207213wiy.60.1383550156666; Sun, 03 Nov 2013 23:29:16 -0800 (PST) Received: by 10.180.18.202 with HTTP; Sun, 3 Nov 2013 23:29:16 -0800 (PST) Date: Sun, 3 Nov 2013 23:29:16 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d0434bc149dffb704ea54df43 Subject: [apps-discuss] Materials uplodaded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2013 07:29:18 -0000 --f46d0434bc149dffb704ea54df43 Content-Type: text/plain; charset=ISO-8859-1 I have uploaded all of the presentations I've received so far. You can see them all here: --f46d0434bc149dffb704ea54df43 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have uploaded all of the presentations I've received= so far.=A0 You can see them all here:

--f46d0434bc149dffb704ea54df43-- From superuser@gmail.com Sun Nov 3 23:31:16 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D5C11E80DC for ; Sun, 3 Nov 2013 23:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PuUKAF4zBv3 for ; Sun, 3 Nov 2013 23:31:16 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7D05E11E8192 for ; Sun, 3 Nov 2013 23:31:11 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id ez12so97354wid.17 for ; Sun, 03 Nov 2013 23:31:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=o6E9XNQGw6CyW+3jP5oB7hVDMEesrU8tQ+JSndtiKMM=; b=xp3dG649wsg7rxyN4TIyGBq7drM6lQPxxwTBNri/HxPfVCgKYa+OM/CTwfJCTAKqRX FyMdhcCzy6PpqQrcp8q0uMmhIsY7TglYMTiwcuEOY5FzCKzGesccvHq9Htsl/a99s8BF cEMNuZLtGGMcATbQGOuKZ0pI1W4xeiRRQUPeczK1kUXDb14yPfuShhLDcUV8Owkiohx4 SMgOVvbVZWDHmBiDdJePTidaH2gF2mnPbYcBExpT/qtXMueQuL3bOKP+6QbI6bJeGJ6H fzxD8X+JUJXICgbn/rq2dw8NIS2FvEk2Z2tcqOAOpnMPN74/WMST5dyMjfra98XXocdb Ny5g== MIME-Version: 1.0 X-Received: by 10.180.19.133 with SMTP id f5mr11408835wie.60.1383550270514; Sun, 03 Nov 2013 23:31:10 -0800 (PST) Received: by 10.180.18.202 with HTTP; Sun, 3 Nov 2013 23:31:10 -0800 (PST) Date: Sun, 3 Nov 2013 23:31:10 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=bcaec53f37e5672cd404ea54e60d Subject: [apps-discuss] IETF 88 materials uploaded X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2013 07:31:17 -0000 --bcaec53f37e5672cd404ea54e60d Content-Type: text/plain; charset=ISO-8859-1 I have uploaded all of the materials I've received from presenters for tomorrow morning's meeting. They should be visible here: https://datatracker.ietf.org/meeting/88/materials.html#app If you are presenting, please check there to ensure that (a) I have your presentation, and (b) if you sent me multiple versions, the right one is there. Drop me a note right away if something's wrong or missing. -MSK --bcaec53f37e5672cd404ea54e60d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have uploaded all of the materials I've re= ceived from presenters for tomorrow morning's meeting.=A0 They should b= e visible here:

https://datatracker.ietf.org/meeting/88/materials.html#a= pp

If you are presenting, please check there to ensure that (a) I ha= ve your presentation, and (b) if you sent me multiple versions, the right o= ne is there.=A0 Drop me a note right away if something's wrong or missi= ng.

-MSK
--bcaec53f37e5672cd404ea54e60d-- From internet-drafts@ietf.org Mon Nov 4 04:42:58 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2196911E8165; Mon, 4 Nov 2013 04:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kChOLwH4m5sl; Mon, 4 Nov 2013 04:42:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F2911E8167; Mon, 4 Nov 2013 04:42:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.82 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131104124257.10133.43752.idtracker@ietfa.amsl.com> Date: Mon, 04 Nov 2013 04:42:57 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 12:42:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : XML Media Types Author(s) : Henry S. Thompson Chris Lilley Filename : draft-ietf-appsawg-xml-mediatypes-04.txt Pages : 27 Date : 2013-11-04 Abstract: This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types. This specification also standardizes the '+xml' suffix for naming media types outside of these five types when those media types represent XML MIME entities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-xml-mediatypes There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-xml-mediatypes-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ht@inf.ed.ac.uk Mon Nov 4 04:56:33 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991DB11E81BF; Mon, 4 Nov 2013 04:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.041 X-Spam-Level: X-Spam-Status: No, score=-6.041 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sb0H-vmzKImc; Mon, 4 Nov 2013 04:56:20 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 9220D11E81C8; Mon, 4 Nov 2013 04:56:09 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rA4Cu2jG022918; Mon, 4 Nov 2013 12:56:02 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rA4Cu1dj025852; Mon, 4 Nov 2013 12:56:01 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rA4Cu1k0001984; Mon, 4 Nov 2013 12:56:01 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rA4Cu1Pq001980; Mon, 4 Nov 2013 12:56:01 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: apps-discuss@ietf.org References: <20131016131142.32211.49752.idtracker@ietfa.amsl.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 04 Nov 2013 12:56:01 +0000 In-Reply-To: (Henry S. Thompson's message of "Tue\, 22 Oct 2013 16\:13\:56 +0100") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: xml-mime@ietf.org, public-xml-core-wg@w3.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2013 12:56:34 -0000 This is the IETF official version of the 22 October draft (it missed the official cutoff for publishing new drafts before Vancouver), which contains only one (moderately large) change from -03, agreed in discussion with my fellow editor Chris Lilley. Please see in particular therefore http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-04#section-3.6 http://www.w3.org/XML/2012/10/3023bis/draft-ietf-appsawg-xml-mediatypes-04_diff.html#charset for substantial clarifications to the rework of Section 3.6 _Charset considerations_ given in version -03. Any existing reviewing work on any _other_ section based on version -03 is still relevant, as no other section has changed in any significant way. Note also accordingly that the diffs in the above -04_diff.html are still against version -02. A thorough exposition of all comments received on version -02, and their resolution, is available at http://www.w3.org/XML/2012/10/3023bis/02-comments.html ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From internet-drafts@ietf.org Mon Nov 4 07:12:59 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5625421E81AB; Mon, 4 Nov 2013 07:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7dFj2ZY6rgI; Mon, 4 Nov 2013 07:12:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 288E821E8196; Mon, 4 Nov 2013 07:12:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.82 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131104151258.10152.67864.idtracker@ietfa.amsl.com> Date: Mon, 04 Nov 2013 07:12:58 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-sieve-duplicate-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 15:12:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Sieve Email Filtering: Detecting Duplicate Deliveries Author(s) : Stephan Bosch Filename : draft-ietf-appsawg-sieve-duplicate-01.txt Pages : 11 Date : 2013-11-04 Abstract: This document defines a new test command "duplicate" for the "Sieve" email filtering language. This test adds the ability to detect duplicate message deliveries. The main application for this new test is handling duplicate deliveries commonly caused by mailing list subscriptions or redirected mail addresses. The detection is normally performed by matching the message ID to an internal list of message IDs from previously delivered messages. For more complex applications, the "duplicate" test can also use the content of a specific header or other parts of the message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-sieve-duplicate-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-sieve-duplicate-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ht@inf.ed.ac.uk Mon Nov 4 07:44:57 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE95511E8227; Mon, 4 Nov 2013 07:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CCs1mNCkoD8; Mon, 4 Nov 2013 07:44:45 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 10AE521E817C; Mon, 4 Nov 2013 07:42:02 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rA4FfOCh018829; Mon, 4 Nov 2013 15:41:29 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rA4FfNbG001302; Mon, 4 Nov 2013 15:41:23 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rA4FfNEr006861; Mon, 4 Nov 2013 15:41:23 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rA4FfMu5006857; Mon, 4 Nov 2013 15:41:22 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Mark Nottingham References: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> <526E8B9E.8030006@gmx.de> <6.2.5.6.2.20131029050405.0caf8b40@elandnews.com> <526FC24D.7060704@gmx.de> <6.2.5.6.2.20131030060359.0cb29068@elandnews.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 04 Nov 2013 15:41:22 +0000 In-Reply-To: (Mark Nottingham's message of "Thu\, 31 Oct 2013 14\:31\:28 +1100") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: ietf@ietf.org, apps-discuss@ietf.org, Julian Reschke , S Moonesamy , draft-ietf-httpbis-p2-semantics.all@tools.ietf.org, ietf-http-wg@w3.org Subject: Re: [apps-discuss] content inspection in absence of media type, was: APPSDIR review of draft-ietf-httpbis-p2-semantics-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2013 15:45:13 -0000 Mark Nottingham writes: > Consensus around this text was particularly hard-won; unless there > is a very good reason to make a change, I'd rather not risk falling > into that rat-hole again. And, I should add in case it helps at all, that the W3C TAG was involved in the extensive discussions which resulted in this text. I also think the fact that it is where it is, in 3.1.1.5, does matter. But recapitulating and/or referencing it in the Security Considerations section would of course be fine, and indeed probably desireable. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From masinter@adobe.com Mon Nov 4 08:11:53 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A3911E82EF; Mon, 4 Nov 2013 08:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.291 X-Spam-Level: X-Spam-Status: No, score=-6.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnV6S8KevrqO; Mon, 4 Nov 2013 08:11:48 -0800 (PST) Received: from exprod6og122.obsmtp.com (exprod6og122.obsmtp.com [64.18.1.238]) by ietfa.amsl.com (Postfix) with ESMTP id 8570A11E8221; Mon, 4 Nov 2013 08:10:57 -0800 (PST) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob122.postini.com ([64.18.5.12]) with SMTP ID DSNKUnfGt+xnDl4VyRhs7L1te7JGwXPdgUog@postini.com; Mon, 04 Nov 2013 08:10:57 PST Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id rA4G5ht2016016; Mon, 4 Nov 2013 08:05:43 -0800 (PST) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id rA4G9QOU017867; Mon, 4 Nov 2013 08:09:26 -0800 (PST) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Mon, 4 Nov 2013 08:09:26 -0800 From: Larry Masinter To: "Henry S. Thompson" , Mark Nottingham Date: Mon, 4 Nov 2013 08:09:24 -0800 Thread-Topic: [apps-discuss] content inspection in absence of media type, was: APPSDIR review of draft-ietf-httpbis-p2-semantics-24 Thread-Index: Ac7ZdRIp7v0v0HGOSIeeV+mqfknXLAAAgKJA Message-ID: References: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> <526E8B9E.8030006@gmx.de> <6.2.5.6.2.20131029050405.0caf8b40@elandnews.com> <526FC24D.7060704@gmx.de> <6.2.5.6.2.20131030060359.0cb29068@elandnews.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf@ietf.org" , "apps-discuss@ietf.org" , "julian.reschke@gmx.de" , S Moonesamy , "draft-ietf-httpbis-p2-semantics.all@tools.ietf.org" , "ietf-http-wg@w3.org" Subject: Re: [apps-discuss] content inspection in absence of media type, was: APPSDIR review of draft-ietf-httpbis-p2-semantics-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2013 16:11:53 -0000 I'd like to point out that the topic of consistent content inspection was d= iscussed in the websec working group via: http://tools.ietf.org/html/draft-ietf-websec-mime-sniff-03 which was abandoned in the IETF and taken up by WHATWG in=20 http://mimesniff.spec.whatwg.org/. The "bugs" filed in IETF tracker: http://trac.tools.ietf.org/wg/websec/trac/query?component=3Dmime-sniff and discussed at IETF 82 Taipei http://tools.ietf.org/agenda/82/slides/websec-2.pdf were subsequently reproduced in the WHATWG tracker https://www.w3.org/Bugs/Public/show_bug.cgi?id=3D19746 Ideally, the "magic number" entry in the Media Type registry would be retar= geted to give instructions and prioritization for content recognition, espe= cially in cases (such as ftp: and file: access) where there is no channel f= or content-type transmission. =20 Fixing content-type sniffing goes beyond http and should be addressed direc= tly.=20 Larry -- http://larry.masinter.net From ht@inf.ed.ac.uk Mon Nov 4 08:54:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE2F21E81DD for ; Mon, 4 Nov 2013 08:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.5 X-Spam-Level: X-Spam-Status: No, score=-6.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iq4BrvqVW7Bn for ; Mon, 4 Nov 2013 08:54:27 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8C04921E81AE for ; Mon, 4 Nov 2013 08:53:49 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rA4GrVvi012473; Mon, 4 Nov 2013 16:53:36 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rA4GrUGO005242; Mon, 4 Nov 2013 16:53:30 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rA4GrUcb008772; Mon, 4 Nov 2013 16:53:30 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rA4GrUPt008768; Mon, 4 Nov 2013 16:53:30 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: ietf-http-wg@w3.org From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 04 Nov 2013 16:53:30 +0000 Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: www-tag@w3.org, apps-discuss@ietf.org Subject: [apps-discuss] Request that the WG reconsider section 3.4: Content Negotiation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2013 16:54:32 -0000 It's my impression that content negotiation hasn't turned out to play the kind of significant role in Web Architecture in general, or in HTTP use in particular, that was expected for it. I think the section on conneg in p2-semantics [1] is so out-of-step with actually deployment, usage and expectations that to publish it as it stands would be a serious mistake. In particular, the discussion of the relative disadvantages of the newly (re-)named 'proactive' and 'reactive' variants are not only out-of-date, but also this discussion appears to at least this reader to amount to a recommendation for 'reactive' negotiation. Yet as far as I can tell no user agents _or_ servers actually support this approach today, as it's described here. I was sufficiently concerned about this question to undertake a moderately extensive empirical investigation [2]. To summarise perhaps too briefly, I found _no_ evidence of the use of reactive conneg in over 75 million HTTP request/response exchanges. I think 3.4 can and should be substantially simplified, with all the evaluative/speculative prose removed, focussing simply on the semantics of the Accept... headers and the 300 and 406 status codes, perhaps also making clear that 'proactive' conneg is the only form of conneg with any signficant degree of server-side support. [2] discusses all this at more length -- I hope it will be helpful. I am of course aware that personal experience, backed up by one small study, may well be misleading, but I did look moderately hard to find any other relevant experimental results without success. It is less likely, but not impossible, that what I report in [2] about what is implemented in IIS, Apache and the major web browsers is also mistaken. On either count, I would welcome concrete evidence of where I've misunderstood or misrepresented the actual situation. ht [1] http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-24#section-3.4 [2] http://www.ltg.ed.ac.uk/~ht/reactive_conneg.html -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From stephan@rename-it.nl Mon Nov 4 09:20:31 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C1D11E82B7 for ; Mon, 4 Nov 2013 09:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoVyRKQkFRnf for ; Mon, 4 Nov 2013 09:20:26 -0800 (PST) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id 6A01221E822B for ; Mon, 4 Nov 2013 09:11:41 -0800 (PST) Received: from klara.student.utwente.nl ([130.89.162.218]:64334 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1VdNgd-0008Le-NU for apps-discuss@ietf.org; Mon, 04 Nov 2013 18:11:38 +0100 Message-ID: <5277D513.6040907@rename-it.nl> Date: Mon, 04 Nov 2013 18:10:43 +0100 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20131104151258.10152.67864.idtracker@ietfa.amsl.com> In-Reply-To: <20131104151258.10152.67864.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-sieve-duplicate-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2013 17:20:31 -0000 On 11/4/2013 4:12 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Applications Area Working Group Working Group of the IETF. > > Title : Sieve Email Filtering: Detecting Duplicate Deliveries > Author(s) : Stephan Bosch > Filename : draft-ietf-appsawg-sieve-duplicate-01.txt > Pages : 11 > Date : 2013-11-04 > > Abstract: > This document defines a new test command "duplicate" for the "Sieve" > email filtering language. This test adds the ability to detect > duplicate message deliveries. The main application for this new test > is handling duplicate deliveries commonly caused by mailing list > subscriptions or redirected mail addresses. The detection is > normally performed by matching the message ID to an internal list of > message IDs from previously delivered messages. For more complex > applications, the "duplicate" test can also use the content of a > specific header or other parts of the message. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-appsawg-sieve-duplicate-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-sieve-duplicate-01 The following changes were made in the draft: - Documented that the expiry time of entries in the duplicate tracking list is measured relative to the initial message. When needed, this can also be performed relative to the last received duplicate by specifying the new `:last' argument. - Mentioned interaction with "imapsieve" extension and marked providing the "duplicate" test in the context of "imapsieve" as NOT RECOMMENDED. I've made a separate section for interaction with other Sieve extensions in the process. - The draft now explicitly states that the message ID value is tracked independent from its source, meaning that it doesn't matter whether it is the value of the Message-ID header, the value of some other arbitrary header specified using `:header', or a explicit string value provided using the `:uniqueid' argument. - Addressed a few editorial comments by Ned Freed. Any comments are welcome! Regards, Stephan. From dret@berkeley.edu Mon Nov 4 11:21:37 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3901D11E82B9 for ; Mon, 4 Nov 2013 11:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jHUzFoumZ2u for ; Mon, 4 Nov 2013 11:21:28 -0800 (PST) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id D8E7F11E827E for ; Mon, 4 Nov 2013 11:21:22 -0800 (PST) Received: from dhcp-a1c6.meeting.ietf.org ([31.133.161.198]) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1VdPiB-0005C8-At for discuss@apps.ietf.org; Mon, 04 Nov 2013 11:21:22 -0800 Message-ID: <5277F3AE.3050702@berkeley.edu> Date: Mon, 04 Nov 2013 11:21:18 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Apps Discuss References: <20130829040129.13080.29347.idtracker@ietfa.amsl.com> <151E2428-3EC4-4F1E-AE6E-3747B06BB62A@mnot.net> <1B4DD8AA-61B5-475C-B8F4-13CF24A9068C@tzi.org> <6E89F982-B6A3-4C74-A881-6CED10DABDE7@mnot.net> In-Reply-To: <6E89F982-B6A3-4C74-A881-6CED10DABDE7@mnot.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Standardising Structure in URIs: one more anti-pattern X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2013 19:21:37 -0000 hello. following up the conversation in today's APP meeting: it seems that the goal for this document might remain to focus on what shouldn't be done, as opposed to also provide comprehensive guidance on what to actually do. i think that's a good direction, and as tim bray pointed out, maybe getting the "you shouldn't be doing this" could be a very good motivation and starting point to start with "and here's what you should do" in a variety of areas. here's one pattern that could be added to the current draft: there are various services that depend on clients adding "URI parameters" to a URI, often by simply appending a string. this amounts to clients "generating URIs" based on scenarios that often assume that there's some way in which those parameters are "tunneled" through services (and get ignored if servers don't support the parameter). this assumes that (a) URI parameters can be reliably parsed, instead of (as the current draft mentions) accepting the fact that URI parameters are neither defined by the URI, nor by the HTTP spec. it also assumes that a request to http://example.com/resource can also be sent to http://example.com/resource&par=value, and things will still work (which they may, but things may also break, depending on how requests are being handled by the server). maybe adding the anti-pattern to the draft might be useful? ideally, i'd like to see as many of these typical anti-patterns in the draft as possible. if people propose them, it should be possible to simply link to http://tools.ietf.org/html/rfc7xxx#section-3.xxx that will describe the anti-pattern, and explains why it's a bad idea. thanks and cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From julian.reschke@gmx.de Mon Nov 4 14:55:36 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A626911E816D for ; Mon, 4 Nov 2013 14:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVVtSnxGqZWT for ; Mon, 4 Nov 2013 14:55:31 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id F3AF521F9EBE for ; Mon, 4 Nov 2013 14:55:26 -0800 (PST) Received: from [31.133.150.89] ([31.133.150.89]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lhwgc-1W08cx1fTG-00n9kt for ; Mon, 04 Nov 2013 23:55:26 +0100 Message-ID: <527825DB.6010105@gmx.de> Date: Mon, 04 Nov 2013 23:55:23 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Henry S. Thompson" , ietf-http-wg@w3.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:nIimVwys13JuLoWKjn0upGyNr8erOpagWnhRkfCT+T7goi1XSCc JBgfby2d07ucrI4O726FArDZq2TvYUUXwlfHumabzztMbU5ktu4pEypi1PKH/LrBAELfNo2 LcNSXD3ZsaREjt3C74rPpE7tz/+N/eTbC/DQYW6Mhl43yESA/qK9D0NpAg7ZsMa6OasW8t+ okf7+qESnEd08mF0qU98A== Cc: www-tag@w3.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Request that the WG reconsider section 3.4: Content Negotiation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2013 22:55:36 -0000 On 2013-11-04 17:53, Henry S. Thompson wrote: > It's my impression that content negotiation hasn't turned out to play > the kind of significant role in Web Architecture in general, or in > HTTP use in particular, that was expected for it. > > I think the section on conneg in p2-semantics [1] is so out-of-step > with actually deployment, usage and expectations that to publish it as > it stands would be a serious mistake. > > In particular, the discussion of the relative disadvantages of the > newly (re-)named 'proactive' and 'reactive' variants are not only > out-of-date, but also this discussion appears to at least this reader > to amount to a recommendation for 'reactive' negotiation. Yet as far > as I can tell no user agents _or_ servers actually support this > approach today, as it's described here. > > I was sufficiently concerned about this question to undertake a > moderately extensive empirical investigation [2]. To summarise > perhaps too briefly, I found _no_ evidence of the use of reactive > conneg in over 75 million HTTP request/response exchanges. > ... Reactive conneg isn't just about 300s and 406s. Another example would be a representation returned with a 200 response that contains links to alternate versions of the content. That's what the "If the user agent is not satisfied by the initial response representation, it can perform a GET request on one or more of the alternative resources, selected based on metadata included in the list, to obtain a different form of representation for that response. Selection of alternatives might be performed automatically by the user agent or manually by the user selecting from a generated (possibly hypertext) menu." in is about. Best regards, Julian From mnot@mnot.net Mon Nov 4 15:12:52 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44ABF11E821A for ; Mon, 4 Nov 2013 15:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyleWlBij4iw for ; Mon, 4 Nov 2013 15:12:47 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id F15ED21E826E for ; Mon, 4 Nov 2013 15:12:38 -0800 (PST) Received: from dhcp-9109.meeting.ietf.org (unknown [31.133.145.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6D08A509B5; Mon, 4 Nov 2013 18:12:36 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Mark Nottingham In-Reply-To: <527825DB.6010105@gmx.de> Date: Mon, 4 Nov 2013 15:12:34 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <527825DB.6010105@gmx.de> To: "Julian F. Reschke" X-Mailer: Apple Mail (2.1816) Cc: "www-tag@w3.org WG" , "apps-discuss@ietf.org Discuss" , HTTP Working Group Subject: Re: [apps-discuss] Request that the WG reconsider section 3.4: Content Negotiation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2013 23:12:52 -0000 What Julian says. Reactive negotiation is very common; formats are = coming up with mechanisms for it all the time (e.g., the work on srcset, = etc. in the W3C web perf WG). Cheers, On 4 Nov 2013, at 2:55 pm, Julian Reschke wrote: > On 2013-11-04 17:53, Henry S. Thompson wrote: >> It's my impression that content negotiation hasn't turned out to play >> the kind of significant role in Web Architecture in general, or in >> HTTP use in particular, that was expected for it. >>=20 >> I think the section on conneg in p2-semantics [1] is so out-of-step >> with actually deployment, usage and expectations that to publish it = as >> it stands would be a serious mistake. >>=20 >> In particular, the discussion of the relative disadvantages of the >> newly (re-)named 'proactive' and 'reactive' variants are not only >> out-of-date, but also this discussion appears to at least this reader >> to amount to a recommendation for 'reactive' negotiation. Yet as far >> as I can tell no user agents _or_ servers actually support this >> approach today, as it's described here. >>=20 >> I was sufficiently concerned about this question to undertake a >> moderately extensive empirical investigation [2]. To summarise >> perhaps too briefly, I found _no_ evidence of the use of reactive >> conneg in over 75 million HTTP request/response exchanges. >> ... >=20 > Reactive conneg isn't just about 300s and 406s. Another example would = be a representation returned with a 200 response that contains links to = alternate versions of the content. That's what the >=20 > "If the user agent is not satisfied by the initial response = representation, it can perform a GET request on one or more of the = alternative resources, selected based on metadata included in the list, = to obtain a different form of representation for that response. = Selection of alternatives might be performed automatically by the user = agent or manually by the user selecting from a generated (possibly = hypertext) menu." >=20 > in = is about. >=20 > Best regards, Julian -- Mark Nottingham http://www.mnot.net/ From julian.reschke@gmx.de Mon Nov 4 15:29:05 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5854921E82C8 for ; Mon, 4 Nov 2013 15:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPZ9AHMHYepJ for ; Mon, 4 Nov 2013 15:28:59 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4C67A21E81E5 for ; Mon, 4 Nov 2013 15:28:57 -0800 (PST) Received: from [31.133.150.89] ([31.133.150.89]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MexaL-1VFd4207Y1-00ObCW for ; Tue, 05 Nov 2013 00:28:56 +0100 Message-ID: <52782DB5.8050301@gmx.de> Date: Tue, 05 Nov 2013 00:28:53 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ray Polk , apps-discuss@ietf.org, draft-ietf-httpbis-p4-conditional.all@tools.ietf.org References: <4bff41ab-7997-429a-83f5-dae237ec7899@default> In-Reply-To: <4bff41ab-7997-429a-83f5-dae237ec7899@default> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:pnYx79fbuMa+jiIypbcamU4AyAFa0mahyVyfvp0PM/jchylTAmY z8ISq8p/mbxUDZViVFaQr/UhdeYk9dPJHBo/0g6NFKKbxpHEMRPKKGbpuyC43NpNCqIWD4i ZUfkUhWUpjowO0Drew4OtGpk/JX1MX+9muobjd2vzwLpuw2IyWSjXj0jMCXAawE72g6JusU prN6NfCo9rmqnVPB6e6Fg== Cc: ietf-http-wg@w3.org, iesg@ietf.org Subject: [apps-discuss] relax SHOULD send Last-Modified?, was: APPSDIR review of draft-ietf-httpbis-p4-conditional-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2013 23:29:05 -0000 On 2013-11-04 07:45, Ray Polk wrote: > ... > 2) relax SHOULD to MAY for Last-Modified when ETag is also supplied in the following sections: > > 2.2.1. Generation > "An origin server SHOULD send Last-Modified for any selected representation for which a last modification date can be reasonably and consistently determined," > ... ...and it continues with... "...since its use in conditional requests and evaluating cache freshness ([Part6]) results in a substantial reduction of HTTP traffic on the Internet and can be a significant factor in improving service scalability and reliability..." I believe that's the reason why it is a SHOULD. Best regards, Julian From mnot@mnot.net Mon Nov 4 15:40:20 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC3621E819A; Mon, 4 Nov 2013 15:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28eS2f6HEV4m; Mon, 4 Nov 2013 15:40:03 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 23B8621E8082; Mon, 4 Nov 2013 15:40:03 -0800 (PST) Received: from dhcp-9109.meeting.ietf.org (unknown [31.133.145.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 03B5750A87; Mon, 4 Nov 2013 18:39:58 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Mark Nottingham In-Reply-To: <52782DB5.8050301@gmx.de> Date: Mon, 4 Nov 2013 15:39:57 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <92B3C683-D8FE-482C-9E9F-B2BF2016EC31@mnot.net> References: <4bff41ab-7997-429a-83f5-dae237ec7899@default> <52782DB5.8050301@gmx.de> To: "Julian F. Reschke" X-Mailer: Apple Mail (2.1816) Cc: draft-ietf-httpbis-p4-conditional.all@tools.ietf.org, "apps-discuss@ietf.org Discuss" , "iesg@ietf.org IESG" , HTTP Working Group Subject: Re: [apps-discuss] relax SHOULD send Last-Modified?, was: APPSDIR review of draft-ietf-httpbis-p4-conditional-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2013 23:40:20 -0000 On 4 Nov 2013, at 3:28 pm, Julian Reschke wrote: > On 2013-11-04 07:45, Ray Polk wrote: >> ... >> 2) relax SHOULD to MAY for Last-Modified when ETag is also supplied = in the following sections: >>=20 >> 2.2.1. Generation >> "An origin server SHOULD send Last-Modified for any selected = representation for which a last modification date can be reasonably and = consistently determined," > > ... >=20 > ...and it continues with... >=20 > "...since its use in conditional requests and evaluating cache = freshness ([Part6]) results in a substantial reduction of HTTP traffic = on the Internet and can be a significant factor in improving service = scalability and reliability..." >=20 > I believe that's the reason why it is a SHOULD. Yes. This was discussed extensively; it was felt that the benefit to the = network was significant enough to include a =93social SHOULD.=94 Cheers, -- Mark Nottingham http://www.mnot.net/ From duerst@it.aoyama.ac.jp Tue Nov 5 00:41:52 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 655C811E819C for ; Tue, 5 Nov 2013 00:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.966 X-Spam-Level: X-Spam-Status: No, score=-101.966 tagged_above=-999 required=5 tests=[AWL=-2.176, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1tYxJni3Vvs for ; Tue, 5 Nov 2013 00:41:47 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id A7F2521E80AB for ; Tue, 5 Nov 2013 00:41:41 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id rA58fZam021781; Tue, 5 Nov 2013 17:41:35 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 4432_cbc5_141eaade_45f6_11e3_8d77_001e6722eec2; Tue, 05 Nov 2013 17:41:34 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 9A920BF4E3; Tue, 5 Nov 2013 17:41:34 +0900 (JST) Message-ID: <5278AF21.90605@it.aoyama.ac.jp> Date: Tue, 05 Nov 2013 17:41:05 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Erik Wilde References: <5276878A.6000802@berkeley.edu> In-Reply-To: <5276878A.6000802@berkeley.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] proposal: adding profile support to JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 08:41:52 -0000 Hello Erik, On 2013/11/04 2:27, Erik Wilde wrote: > hello. > > seeing that http://tools.ietf.org/html/draft-ietf-json-rfc4627bis is > making good progress, i wanted to raise the question of maybe adding > profile support to the JSON media type. > > http://tools.ietf.org/html/draft-wilde-atom-profile is a proposal for > adding profile support to the atom media type, and the "profile" > optional media type parameter > (http://tools.ietf.org/html/draft-wilde-atom-profile-02#section-4.1.1) > is what could be added to JSON as well. > > the advantage would be that different JSON-based formats could be > distinguished by their (mediatype+profile). this would allow JSON-based > formats to become more visible on the web level, instead of always just > saying "i am JSON", without any ability to differentiate. I don't understand this. JSON-based formats can be distinguished by registering a mime type. E.g., application/foo+json can be distinguished from application/bar+json. If that's not what you mean, can you give some examples of what you mean? In general, adding a parameter doesn't work very well, because the infrastructure (e.g. setting mechanisms on the server side,...) isn't developped. With respect to your atom profile proposal, it contains ideas for actual usage, but they all use "would". I think you should wait to pursue that draft until you have an *actual* use case, i.e. an actual profile parameter value. Just defining protocol slots without values isn't something that's done in the IETF, and isn't something that makes sense to spend IETF resources on. Regards, Martin. > thanks and cheers, > > dret. > From ht@inf.ed.ac.uk Tue Nov 5 04:18:57 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C2711E8277 for ; Tue, 5 Nov 2013 04:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.891 X-Spam-Level: X-Spam-Status: No, score=-6.891 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifi-tKVO6d2p for ; Tue, 5 Nov 2013 04:18:52 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 26CBE11E8296 for ; Tue, 5 Nov 2013 04:18:45 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rA5CINJL015341; Tue, 5 Nov 2013 12:18:23 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rA5CINkI020987; Tue, 5 Nov 2013 12:18:23 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rA5CINS5010506; Tue, 5 Nov 2013 12:18:23 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rA5CING3010502; Tue, 5 Nov 2013 12:18:23 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Julian Reschke References: <527825DB.6010105@gmx.de> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 05 Nov 2013 12:18:23 +0000 In-Reply-To: <527825DB.6010105@gmx.de> (Julian Reschke's message of "Mon\, 04 Nov 2013 23\:55\:23 +0100") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Cc: www-tag@w3.org, ietf-http-wg@w3.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Request that the WG reconsider section 3.4: Content Negotiation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 12:18:57 -0000 Julian Reschke writes: > On 2013-11-04 17:53, Henry S. Thompson wrote: >> ... > > Reactive conneg isn't just about 300s and 406s. Another example would > be a representation returned with a 200 response that contains links > to alternate versions of the content. That's what the How is this in scope for discussion _in the HTTP spec._? People (not user agents, note) use 200 responses for a huge range of interesting, powerful, innovative things. We don't look in the HTTP spec. to find a discussion of them. > "If the user agent is not satisfied by the initial response > representation, it can perform a GET request on one or more of the > alternative resources, selected based on metadata included in the > list, to obtain a different form of representation for that > response. Selection of alternatives might be performed automatically > by the user agent or manually by the user selecting from a generated > (possibly hypertext) menu." "based on metadata included in the list"! That's a specific reference to a 300 response. There is no "list" in a 200 response, not that a user agent can detect anyway. And, as I said in the last message, I'm not aware of _any_ user agent that does _anything_ specific to 300 responses. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From ht@inf.ed.ac.uk Tue Nov 5 04:45:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE8511E8296 for ; Tue, 5 Nov 2013 04:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[AWL=-0.401, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ie9Dm0ePvoV for ; Tue, 5 Nov 2013 04:45:13 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFDF11E8127 for ; Tue, 5 Nov 2013 04:45:11 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rA5Cj4wp007499; Tue, 5 Nov 2013 12:45:04 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rA5Cj4m5022327; Tue, 5 Nov 2013 12:45:04 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rA5Cj4AE011304; Tue, 5 Nov 2013 12:45:04 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rA5Cj4B3011300; Tue, 5 Nov 2013 12:45:04 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Mark Nottingham References: <527825DB.6010105@gmx.de> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 05 Nov 2013 12:45:04 +0000 In-Reply-To: (Mark Nottingham's message of "Mon\, 4 Nov 2013 15\:12\:34 -0800") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Cc: "Julian F. Reschke" , "www-tag@w3.org WG" , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Request that the WG reconsider section 3.4: Content Negotiation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 12:45:21 -0000 Mark Nottingham writes: > What Julian says. What I said in reply to Julian :-). > Reactive negotiation is very common; formats are coming up with > mechanisms for it all the time (e.g., the work on srcset, etc. in > the W3C web perf WG). I'm still looking for a _single_ example of user agent support for reactive conneg _at the HTTP level_. srcset, as far as I can see, has entirely HTML-language-level semantics, and has nothing to do with HTTP. It also, at first glance anyway, seems to be exactly the kind of conneg anti-pattern which got such a bad review from the HTTP WG in the thread on Mike Kelly's suggestions about changing the semantics in HTML of a/@type and/or adding a/@accept, starting at [1]. ht [1] http://lists.w3.org/Archives/Public/public-html/2009Oct/0527.html -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From Peter.Rushforth@NRCan-RNCan.gc.ca Tue Nov 5 06:15:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4933F11E8141 for ; Tue, 5 Nov 2013 06:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvCFR-EGDbUy for ; Tue, 5 Nov 2013 06:15:50 -0800 (PST) Received: from nrcan.gc.ca (s-bsc-edge1.nrcan.gc.ca [132.156.238.13]) by ietfa.amsl.com (Postfix) with ESMTP id 682F911E8140 for ; Tue, 5 Nov 2013 06:15:50 -0800 (PST) Received: from S-BSC-CAS2.nrn.nrcan.gc.ca (132.156.238.12) by S-BSC-EDGE1.nrcan.gc.ca (132.156.238.13) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 5 Nov 2013 09:15:46 -0500 Received: from S-BSC-MBX1.nrn.nrcan.gc.ca ([169.254.1.186]) by S-BSC-CAS2.nrn.nrcan.gc.ca ([fe80::48d4:f168:78ba:d4e8%19]) with mapi id 14.02.0342.003; Tue, 5 Nov 2013 09:15:46 -0500 From: "Rushforth, Peter" To: "Henry S. Thompson" Thread-Topic: [apps-discuss] Request that the WG reconsider section 3.4: Content Negotiation Thread-Index: AQHO2iTzLS3EeVKd0EaLxFEjXODeM5oWpxYg Date: Tue, 5 Nov 2013 14:15:45 +0000 Message-ID: <1CD55F04538DEA4F85F3ADF7745464AF24A88EFD@S-BSC-MBX1.nrn.nrcan.gc.ca> References: <527825DB.6010105@gmx.de> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.156.238.22] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Request that the WG reconsider section 3.4: Content Negotiation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 14:15:56 -0000 Hi Henry, I see the reviews, but I don't know that I agree it's an anti-pattern.=20 For example in atom, the existing ability to list several atom:link[@rel=3D= 'alternate'] which only differ by @type value is something similar to what Mike was suggesting for html. Not that there are many user agents which support atom, but unless you *for= ce* the resource to return the media type suggested by @type (which couples format = and identity/location),=20 the only reasonable way to get that advertised media type back is by conneg= , wherein the user-agent reads the metadata from the hypertext and negotiates for that. In HTML, the author can force the *display* of the links they want in the m= anner they want, but they can't force the user agent to negotiate for anything, it is hard-coded= to 'negotiate' for a list of media type preferences (based on the a or img),=20 which I think is the anti-pattern. Not that any of this affects the discussion of 300 Multiple Choices, I can = see your point there. But I would say that 200 OK with user-selectable alternates is a common pattern= . And it would be nice if user-agents did 'help' with the interaction by negotiating for t= he advertised media type. By hard-coding the negotiation, they aren't supporting the web= ; as a result there is no web which reaches across format (well across associated formats anywa= y).=20 Regards, Peter Rushforth > -----Original Message----- > From: apps-discuss-bounces@ietf.org=20 > [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Henry S. Thompson > Sent: November 5, 2013 07:45 > To: Mark Nottingham > Cc: Julian F. Reschke; www-tag@w3.org WG;=20 > apps-discuss@ietf.org Discuss > Subject: Re: [apps-discuss] Request that the WG reconsider=20 > section 3.4: Content Negotiation >=20 > Mark Nottingham writes: >=20 > > What Julian says. >=20 > What I said in reply to Julian :-). >=20 > > Reactive negotiation is very common; formats are coming up with=20 > > mechanisms for it all the time (e.g., the work on srcset,=20 > etc. in the=20 > > W3C web perf WG). >=20 > I'm still looking for a _single_ example of user agent=20 > support for reactive conneg _at the HTTP level_. srcset, as=20 > far as I can see, has entirely HTML-language-level semantics,=20 > and has nothing to do with HTTP. It also, at first glance=20 > anyway, seems to be exactly the kind of conneg anti-pattern=20 > which got such a bad review from the HTTP WG in the thread on=20 > Mike Kelly's suggestions about changing the semantics in HTML=20 > of a/@type and/or adding a/@accept, starting at [1]. >=20 > ht >=20 > [1] http://lists.w3.org/Archives/Public/public-html/2009Oct/0527.html > --=20 > Henry S. Thompson, School of Informatics, University=20 > of Edinburgh > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44)=20 > 131 650-4440 > Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ =20 > [mail from me _always_ has a .sig like this -- mail without=20 > it is forged spam] _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > = From tbray@textuality.com Tue Nov 5 07:58:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390EA11E8212 for ; Tue, 5 Nov 2013 07:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=-0.889, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id affQx3QwV3ki for ; Tue, 5 Nov 2013 07:57:49 -0800 (PST) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFB721E816A for ; Tue, 5 Nov 2013 07:57:48 -0800 (PST) Received: by mail-ve0-f178.google.com with SMTP id db12so2617249veb.37 for ; Tue, 05 Nov 2013 07:57:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KdPlajyl+oKN8OzeILaYK6CTYvv5kauuYrSnfrYlWQs=; b=bxCXUFM44f88pB6gsMz3iPZXPyeKFKOL0ch754zZbMu6gGnnEUMJ2dB5c4VcQ2kyaN CT0lEKJNSfItKbVCxxa+DSQjyif7e4jL17G+C6MkAmuSSj+xvxMmeEyxY3foQnT4RB62 M6G1YRSufuOiAaJg5A3KCAHKAkLaxuxaRf2tbl31TJP3lm5NXY1oyUmYJLsUX4jCrwJG wVj2DUsH01k9TUCQt8zIE0A4B2VDrwhmHm3dJCX5WLp+Mfdvmtr3XVMO7iqawNQWlNl7 fyENYYCYkK13IHmdBrVOlpn2wK4pbYtaUNhUPVZZgD+kYzFnIsQ608GGF64lJ3T+6N1N eZoQ== X-Gm-Message-State: ALoCoQmmqpGeERFA7ILPyvFOvIRW+IfuDYmb92WS2AtAhIxuASD+ZH+Lq4BqQ3PB+yyCUJU1Duf+ MIME-Version: 1.0 X-Received: by 10.58.180.227 with SMTP id dr3mr387750vec.36.1383667067405; Tue, 05 Nov 2013 07:57:47 -0800 (PST) Received: by 10.220.110.134 with HTTP; Tue, 5 Nov 2013 07:57:47 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <5278AF21.90605@it.aoyama.ac.jp> References: <5276878A.6000802@berkeley.edu> <5278AF21.90605@it.aoyama.ac.jp> Date: Tue, 5 Nov 2013 07:57:47 -0800 Message-ID: From: Tim Bray To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=047d7b66fbcf0a7d8504ea70182d Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] proposal: adding profile support to JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 15:58:05 -0000 --047d7b66fbcf0a7d8504ea70182d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Well, for example, http://www.tbray.org/tmp/draft-bray-i-json-01.html On Tue, Nov 5, 2013 at 12:41 AM, "Martin J. D=C3=BCrst" wrote: > Hello Erik, > > > On 2013/11/04 2:27, Erik Wilde wrote: > >> hello. >> >> seeing that http://tools.ietf.org/html/draft-ietf-json-rfc4627bis is >> making good progress, i wanted to raise the question of maybe adding >> profile support to the JSON media type. >> >> http://tools.ietf.org/html/draft-wilde-atom-profile is a proposal for >> adding profile support to the atom media type, and the "profile" >> optional media type parameter >> (http://tools.ietf.org/html/draft-wilde-atom-profile-02#section-4.1.1) >> is what could be added to JSON as well. >> >> the advantage would be that different JSON-based formats could be >> distinguished by their (mediatype+profile). this would allow JSON-based >> formats to become more visible on the web level, instead of always just >> saying "i am JSON", without any ability to differentiate. >> > > I don't understand this. JSON-based formats can be distinguished by > registering a mime type. E.g., application/foo+json can be distinguished > from application/bar+json. If that's not what you mean, can you give some > examples of what you mean? > > In general, adding a parameter doesn't work very well, because the > infrastructure (e.g. setting mechanisms on the server side,...) isn't > developped. > > With respect to your atom profile proposal, it contains ideas for actual > usage, but they all use "would". I think you should wait to pursue that > draft until you have an *actual* use case, i.e. an actual profile paramet= er > value. Just defining protocol slots without values isn't something that's > done in the IETF, and isn't something that makes sense to spend IETF > resources on. > > Regards, Martin. > > thanks and cheers, >> >> dret. >> >> _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --047d7b66fbcf0a7d8504ea70182d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 5, 2013 at 12:41 AM, "Martin J. D=C3=BCrst" <d= uerst@it.aoyama.ac.jp> wrote:
Hello Erik,


On 2013/11/04 2:27, Erik Wilde wrote:
hello.

seeing that http://tools.ietf.org/html/draft-ietf-json-rfc4= 627bis is
making good progress, i wanted to raise the question of maybe adding
profile support to the JSON media type.

http://tools.ietf.org/html/draft-wilde-atom-profile is a = proposal for
adding profile support to the atom media type, and the "profile"<= br> optional media type parameter
(http://tools.ietf.org/html/draft-wilde-atom= -profile-02#section-4.1.1)
is what could be added to JSON as well.

the advantage would be that different JSON-based formats could be
distinguished by their (mediatype+profile). this would allow JSON-based
formats to become more visible on the web level, instead of always just
saying "i am JSON", without any ability to differentiate.

I don't understand this. JSON-based formats can be distinguished by reg= istering a mime type. E.g., application/foo+json can be distinguished from = application/bar+json. If that's not what you mean, can you give some ex= amples of what you mean?

In general, adding a parameter doesn't work very well, because the infr= astructure (e.g. setting mechanisms on the server side,...) isn't devel= opped.

With respect to your atom profile proposal, it contains ideas for actual us= age, but they all use "would". I think you should wait to pursue = that draft until you have an *actual* use case, i.e. an actual profile para= meter value. Just defining protocol slots without values isn't somethin= g that's done in the IETF, and isn't something that makes sense to = spend IETF resources on.

Regards, =C2=A0 Martin.

thanks and cheers,

dret.

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

--047d7b66fbcf0a7d8504ea70182d-- From phk@phk.freebsd.dk Mon Nov 4 09:11:53 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86B521E8227 for ; Mon, 4 Nov 2013 09:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.095 X-Spam-Level: X-Spam-Status: No, score=-6.095 tagged_above=-999 required=5 tests=[AWL=-4.505, BAYES_00=-2.599, HELO_EQ_DK=1.009] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+ikqpbW-h+t for ; Mon, 4 Nov 2013 09:11:43 -0800 (PST) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3C411E830C for ; Mon, 4 Nov 2013 09:08:11 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 189693EB5C; Mon, 4 Nov 2013 17:07:51 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.7/8.14.7) with ESMTP id rA4H7onp065800; Mon, 4 Nov 2013 17:07:50 GMT (envelope-from phk@phk.freebsd.dk) To: ht@inf.ed.ac.uk (Henry S. Thompson) In-reply-to: From: "Poul-Henning Kamp" References: Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 04 Nov 2013 17:07:50 +0000 Message-ID: <65799.1383584870@critter.freebsd.dk> X-Mailman-Approved-At: Tue, 05 Nov 2013 08:03:39 -0800 Cc: www-tag@w3.org, ietf-http-wg@w3.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Request that the WG reconsider section 3.4: Content Negotiation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2013 17:11:54 -0000 In message , Henry S. Thompson writes: >I think 3.4 can and should be substantially simplified, Seconded. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From tjc@ecs.soton.ac.uk Mon Nov 4 16:51:41 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169D121F9CFB; Mon, 4 Nov 2013 16:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9YATGwEFqpR; Mon, 4 Nov 2013 16:51:39 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id D5A5121F9CED; Mon, 4 Nov 2013 16:49:44 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rA50nFiF006677; Tue, 5 Nov 2013 00:49:15 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk rA50nFiF006677 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1383612556; bh=kD1Mnhpch31U63iJDnFlMekat0k=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=4EZcnskNgXLA6JW/u9KOe/j3+/QB3eT4xmH1PHTlfS6zQp14jiTR4Wnoxu+L2fDjl /FI7i5zQMx8RssaIyI5WfRwmUasug+wVAAnqXBwDqajvs4Hyf0AZlAX/ynJODvmvZd UBZ2RG1e/wdlnA2fyKaiwM2iOUlNbixuEVPli7EU= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id pA40nF09596347704z ret-id none; Tue, 05 Nov 2013 00:49:15 +0000 Received: from wireless-v6.meeting.ietf.org (wireless-v6.meeting.ietf.org [IPv6:2001:67c:370:160:dc36:f9fb:865b:22c5] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rA50l6Lw007907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Nov 2013 00:48:55 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_DE41C7E7-E82D-40D8-86C2-FAF1DD5DAE2E" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Tim Chown In-Reply-To: Date: Tue, 5 Nov 2013 00:48:54 +0000 Message-ID: References: <6A3161F9-AD16-4305-8690-D530511DCFE8@ecs.soton.ac.uk> To: Dave Cridland X-Mailer: Apple Mail (2.1816) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=pA40nF095963477000; tid=pA40nF09596347704z; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=7:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: rA50nFiF006677 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-Mailman-Approved-At: Tue, 05 Nov 2013 08:04:07 -0800 Cc: "" , S Moonesamy , The IESG , draft-ietf-homenet-arch.all@tools.ietf.org, "homenet@ietf.org Group" , Ted Lemon Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 00:51:41 -0000 --Apple-Mail=_DE41C7E7-E82D-40D8-86C2-FAF1DD5DAE2E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 19 Sep 2013, at 14:24, Dave Cridland wrote: > Ted Lemon wrote: >> On Sep 19, 2013, at 6:59 AM, S Moonesamy = wrote: >> > The Chairs have already agreed about the five topics to be = covered. It's not a problem. The next step would be to take these = topics, make them accessible to the average reader, and organize = them. This may require avoiding too many details if it is doable. >>=20 >> I think that you are interpreting this document to be something that = it is not, and cannot yet be. What this document is is an architecture = for the homenet working group=97a crib sheet that tells us what we are = trying to accomplish. I don't think it's intended to be something that = a random person who is not implementing home gateways would find useful. = The working group is hoping that subsequent versions of this document = will evolve over time, and I think it would be good for the working = group to evolve the document into something that meets the goals that = you've set out above. >>=20 >> However, I think that if the working group attempts to do that now, = two things will happen. First, the working group won't actually get to = the work it's supposed to be doing, because completing the architecture = document will continue to be an all-consuming effort. Second, the = document that is produced will be purely theoretical, not based on = actual practice, and probably useless. >>=20 >> So I would like you to consider whether you can accept this = restatement of the purpose of the document. Do you feel that this = document cannot be of use until it meets the goals you've set out above, = or does the different purpose I've expressed here make sense to you? = If the latter, can you reconsider your review in light of this new = stated purpose for the document? Is part of the problem that the goals = of the document are poorly expressed in the document? Given the goals = I've stated, do all of your comments still apply, or would you have = responded differently to the document if you'd been evaluating it on the = basis I'm proposing? >>=20 > Then the title ought to call itself Requirements, or Proposed, or = something. >=20 > Actually, I genuinely struggle to understand the purpose of publishing = documents which are intended as working documents for a particular = Working Group as an RFC, but on the basis that it's required for some = reason I don't understand, then calling it the "Home Networking = Architecture for IPv6" is confusing - I read that, perhaps terribly = naively, as being a document defining the Home Networking Architecture = for IPv6. Partly because, right at the top, it says "The goal of this = document is to define a general architecture for IPv6-based home = networking". It really had me fooled. >=20 > I appreciate I'm obviously foolish and easily mislead, but perhaps = calling entitling it "Architectural Requirements for IPv6 Home = Networking", or "Proposals and Considerations for Home Networking = Architecture for IPv6", might give the reader the hint that it's not = defining an architecture as such. >=20 > Dave. The title was amended slightly for -11: The diff for the -11 is available here: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-homenet-arch-11.txt Tim= --Apple-Mail=_DE41C7E7-E82D-40D8-86C2-FAF1DD5DAE2E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 19 Sep 2013, at 14:24, Dave = Cridland <dave@cridland.net> = wrote:

Ted Lemon wrote:
On Sep 19, = 2013, at 6:59 AM, S Moonesamy <sm+ietf@elandsys.com> = wrote:
   > The Chairs have already agreed about = the five topics to be covered.     It's not a = problem.  The next step would be to take these topics, make =     them accessible to the average reader, and = organize them.  This may     require avoiding = too many details if it is doable.

I think that you are = interpreting this document to be something that it is not, and cannot = yet be.   What this document is is an architecture for the = homenet working group=97a crib sheet that tells us what we are trying to = accomplish.   I don't think it's intended to be something that = a random person who is not implementing home gateways would find useful. =   The working group is hoping that subsequent versions of this = document will evolve over time, and I think it would be good for the = working group to evolve the document into something that meets the goals = that you've set out above.

However, I think that if the working = group attempts to do that now, two things will happen.  First, the = working group won't actually get to the work it's supposed to be doing, = because completing the architecture document will continue to be an = all-consuming effort.   Second, the document that is produced = will be purely theoretical, not based on actual practice, and probably = useless.

So I would like you to consider whether you can accept = this restatement of the purpose of the document.   Do you feel = that this document cannot be of use until it meets the goals you've set = out above, or does the different purpose I've expressed here make sense = to you?   If the latter, can you reconsider your review in = light of this new stated purpose for the document? Is part of the = problem that the goals of the document are poorly expressed in the = document?   Given the goals I've stated, do all of your = comments still apply, or would you have responded differently to the = document if you'd been evaluating it on the basis I'm = proposing?

Then the title ought to call itself = Requirements, or Proposed, or something.

Actually, I genuinely = struggle to understand the purpose of publishing documents which are = intended as working documents for a particular Working Group as an RFC, = but on the basis that it's required for some reason I don't understand, = then calling it the "Home Networking Architecture for IPv6" is confusing = - I read that, perhaps terribly naively, as being a document defining = the Home Networking Architecture for IPv6. Partly because, right at the = top, it says "The goal of this document is to define a general = architecture for IPv6-based home networking". It really had me = fooled.

I appreciate I'm obviously foolish and easily mislead, = but perhaps calling entitling it "Architectural Requirements for IPv6 = Home Networking", or "Proposals and Considerations for Home Networking = Architecture for IPv6", might give the reader the hint that it's not = defining an architecture as = such.

Dave.

The title was amended = slightly for -11:

Tim
= --Apple-Mail=_DE41C7E7-E82D-40D8-86C2-FAF1DD5DAE2E-- From mark@coactus.com Tue Nov 5 08:59:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292C521F9EED for ; Tue, 5 Nov 2013 08:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIwPzznEmPTf for ; Tue, 5 Nov 2013 08:59:06 -0800 (PST) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) by ietfa.amsl.com (Postfix) with ESMTP id 022B711E8167 for ; Tue, 5 Nov 2013 08:59:05 -0800 (PST) Received: by mail-pd0-f170.google.com with SMTP id v10so8826465pde.29 for ; Tue, 05 Nov 2013 08:59:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mg2Wcbx/E21SCETye0/q9wMYW7UWhTOlUCcOGgLsJC8=; b=mPhycbdXg8QipP1c+Fdftz8uQJTM+fLoK1oAQWC4YAp84eLX3xyAhxO8+YWY0NF1k9 Chb/FrCiC2jglcXbKL78XhXeQeIsvZUns9STTKpDLZFBtKlS3JT0mrBFlW7pXlMfICwW nGQkftlv8TOJ0IBYCXEMYES0GDpYYVDZiK/nb5hDpOpG9h62Dg7fSGUZakZyrnfzi9pl CeuIpi47vv7i2DBwsRZMaErQibwvWJ2Cg0/K6S+1r9wZd51aygvrXtQ/EiZeKD/jL9HM uRpghRd26lg8NQ6ftc1o/TVm8xrvCEdTT9kvuGyAYtwqx2OwO+etnEMmAjXVBZUyvSO6 xwGg== X-Gm-Message-State: ALoCoQmWQGGF41Cw/tfBugEO8WfGQmqibKIuTXT7wzNR20mx8SLPIPEh/ElA8K2Tosz1rUkxneVp MIME-Version: 1.0 X-Received: by 10.68.191.3 with SMTP id gu3mr8737028pbc.142.1383670745340; Tue, 05 Nov 2013 08:59:05 -0800 (PST) Sender: mark@coactus.com Received: by 10.70.25.67 with HTTP; Tue, 5 Nov 2013 08:59:05 -0800 (PST) X-Originating-IP: [192.0.216.13] In-Reply-To: References: <5276878A.6000802@berkeley.edu> <5278AF21.90605@it.aoyama.ac.jp> Date: Tue, 5 Nov 2013 11:59:05 -0500 X-Google-Sender-Auth: m7j6V84b6Z17W2etjUChww-xhbs Message-ID: From: Mark Baker To: Tim Bray Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] proposal: adding profile support to JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 16:59:11 -0000 On Tue, Nov 5, 2013 at 10:57 AM, Tim Bray wrote: > Well, for example, http://www.tbray.org/tmp/draft-bray-i-json-01.html I'm with Martin. What that spec is trying to do with profiles is to supplant the typical role of a media type. If it's representative of what Erik has in mind for the use of a profile parameter with Atom (or anywhere), then I think that needs to be reconsidered too. Mark. From mca@amundsen.com Tue Nov 5 09:19:36 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B4911E8178 for ; Tue, 5 Nov 2013 09:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIKDlrid3Qvn for ; Tue, 5 Nov 2013 09:19:32 -0800 (PST) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id CC70D21E81D5 for ; Tue, 5 Nov 2013 09:19:11 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id b13so3813767wgh.22 for ; Tue, 05 Nov 2013 09:19:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=esKgBdT8sgPQyWMqtHKpAr43/ASX970eOozg6EFrCN8=; b=KAGR0Km1RCoy7bPH46NuU1g/zJT9PyXqZaXk906OjSRHIFoBmBsShh5bSza1WQWzng JbcvxeLycfm7s5icD5cI1Pmv2gxRpOBd6UZzu9vWoeaxeSHBMjshHE9eGuh4wj/E8XJ6 gG/tMeQADwPzTY2Ql6oZETST3b2yejHeA6JQsNxgoU6Gr/03GYZNozQi/boUWmdqROhK dmXNONimFLH1sBqICERe21hL2A7m3ovBV9OWmlKmFLhcBFOG3OkCQig/KjmXeecB3GSu G5AYoK8xvVYDz19JxObnlus+mrqfbP85vLaodMi8ebyNAhvUwVhlTKQ5sPzC9hgz4ZQi v5uw== X-Gm-Message-State: ALoCoQnWTZ1djPwlHeDnI7LFKhFeSmCs4NZzwnvgRAswqzQJrI0JGMHvjqGM4FvF86TbE6xptnOW X-Received: by 10.180.99.99 with SMTP id ep3mr17622163wib.11.1383671948610; Tue, 05 Nov 2013 09:19:08 -0800 (PST) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.55.195 with HTTP; Tue, 5 Nov 2013 09:18:48 -0800 (PST) In-Reply-To: References: <5276878A.6000802@berkeley.edu> <5278AF21.90605@it.aoyama.ac.jp> From: mike amundsen Date: Tue, 5 Nov 2013 12:18:48 -0500 X-Google-Sender-Auth: V80GQeMZ5dMA5BQfme5fcXjZX7s Message-ID: To: Mark Baker Content-Type: multipart/alternative; boundary=f46d044283c0fba40904ea713ad1 Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] proposal: adding profile support to JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 17:19:36 -0000 --f46d044283c0fba40904ea713ad1 Content-Type: text/plain; charset=ISO-8859-1 I'm using the profile link rel (currently in-message) to add domain semantics (not protocol semantics) to Collection+JSON representations. This does not, IMO, "supplant the typical role of a media type." Of course, that's a bit of a bike shed since "typical" is a quality term. ;) mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://www.linkedin.com/in/mamund On Tue, Nov 5, 2013 at 11:59 AM, Mark Baker wrote: > On Tue, Nov 5, 2013 at 10:57 AM, Tim Bray wrote: > > Well, for example, http://www.tbray.org/tmp/draft-bray-i-json-01.html > > I'm with Martin. What that spec is trying to do with profiles is to > supplant the typical role of a media type. If it's representative of > what Erik has in mind for the use of a profile parameter with Atom (or > anywhere), then I think that needs to be reconsidered too. > > Mark. > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --f46d044283c0fba40904ea713ad1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm using the profile link rel (currently in-message) = to add domain semantics (not protocol semantics) to Collection+JSON represe= ntations.

This does not, IMO, "supplant the typical= role of a media type."=A0

Of course, that's a bit of a bike shed since "= typical" is a quality term. ;)





On Tue, Nov 5, 2013 at 11:59 AM, Mark Ba= ker <distobj@acm.org> wrote:
On Tue, Nov 5, 2013 at 10:57 AM, Tim Bray <tbray@textuality.com> wrote:
> Well, for example, http://www.tbray.org/tmp/draft-bray-i-json-01= .html

I'm with Martin. What that spec is trying to do with profiles is = to
supplant the typical role of a media type. If it's representative of what Erik has in mind for the use of a profile parameter with Atom (or
anywhere), then I think that needs to be reconsidered too.

Mark.
_____________________= __________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--f46d044283c0fba40904ea713ad1-- From gonzalo.camarillo@ericsson.com Tue Nov 5 09:46:06 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A5C21F9EB6; Tue, 5 Nov 2013 09:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.581 X-Spam-Level: X-Spam-Status: No, score=-105.581 tagged_above=-999 required=5 tests=[AWL=0.668, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgJfvXhpxiSb; Tue, 5 Nov 2013 09:45:57 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6760421F8445; Tue, 5 Nov 2013 09:45:57 -0800 (PST) X-AuditID: c1b4fb30-b7eff8e000006d14-5d-52792ed395ab Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 90.2F.27924.3DE29725; Tue, 5 Nov 2013 18:45:55 +0100 (CET) Received: from [131.160.126.80] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.2.328.9; Tue, 5 Nov 2013 18:45:54 +0100 Message-ID: <52792ECE.80006@ericsson.com> Date: Tue, 5 Nov 2013 09:45:50 -0800 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Vijay K. Gurbani" References: <52432012.9070104@bell-labs.com> In-Reply-To: <52432012.9070104@bell-labs.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUyM+Jvje5lvcogg1ObzSxWv1zBZnFwUrDF jD8TmS12rCm0OH9hA5NFwxo5BzaPvssuHlN+b2T1WLLkJ5NHw76j7B5fLn9mC2CN4rJJSc3J LEst0rdL4Mr4NWM9S8FWlop1i84xNjBuYO5i5OSQEDCROHr4FpQtJnHh3nq2LkYuDiGBQ4wS V7s2M0E4qxklXk/9ygZSxSugKXFs8RZ2EJtFQEViwrapYHE2AQuJLbfus4DYogJREhu2X2CB qBeUODnzCZgtIqAlMbHpCthQZoEDjBLXHj1mBUkIC4RIfLrxH6xISCBGomvuASYQm1NAV+JO +yI2iPMkJba8aAdbzAx0ROv231C2vMT2t3OYIXq1JZY/a2GZwCg0C8nuWUhaZiFpWcDIvIqR PTcxMye93HwTIzDYD275bbCDcdN9sUOM0hwsSuK8H946BwkJpCeWpGanphakFsUXleakFh9i ZOLglGpgNGQJeHIhQDj531efTZP4p35IyWH04t/SfmB6Rn3Sg7aok9fyHhxevKCgLURtaq1x pNxXxsrw0PXH58YFHTH4ET/NgGkfw5FnHh8eNq+4PTng52dpw3UvbC2WpSjaK1lrpP/bvVBy WU3za4NZSoIvz24LmybQdpy9lGfRHqEl58IOXtt3X+eFrBJLcUaioRZzUXEiAKslLBNEAgAA Cc: draft-ietf-insipid-session-id-reqts.all@tools.ietf.org, 'James Polk' , 'IESG IESG' , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-insipid-session-id-reqts-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 17:46:06 -0000 Hi Vijay, Paul has just revised the draft to address your comments (see his separate email about the discussions that took place within the WG). Could you please let us know if you are happy with the new revision? Thanks, Gonzalo On 25/09/2013 10:40 AM, Vijay K. Gurbani wrote: > On 09/24/2013 07:47 PM, Paul E. Jones wrote: >> Vijay, >> >> Thanks for the additional feedback. I will consult with a few of the >> folks in the WG to see how we can best address your points. > > Paul: Sure, no worries. Thanks for your time. > > - vijay From dret@berkeley.edu Tue Nov 5 10:11:00 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E6A11E81F8 for ; Tue, 5 Nov 2013 10:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rHTE+6kHFoc for ; Tue, 5 Nov 2013 10:10:56 -0800 (PST) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id E305D21F9AA1 for ; Tue, 5 Nov 2013 10:10:21 -0800 (PST) Received: from dhcp-a1c6.meeting.ietf.org ([31.133.161.198]) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1Vdl4r-00030q-Ci for apps-discuss@ietf.org; Tue, 05 Nov 2013 10:10:12 -0800 Message-ID: <52793480.6010006@berkeley.edu> Date: Tue, 05 Nov 2013 10:10:08 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 CC: "apps-discuss@ietf.org application-layer protocols" References: <5276878A.6000802@berkeley.edu> <5278AF21.90605@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [apps-discuss] proposal: adding profile support to JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 18:11:00 -0000 another existing example is http://lists.geojson.org/pipermail/geojson-geojson.org/2013-November/thread.html On 2013-11-05, 07:57 , Tim Bray wrote: > Well, for example, http://www.tbray.org/tmp/draft-bray-i-json-01.html > > > On Tue, Nov 5, 2013 at 12:41 AM, "Martin J. Dürst" > > wrote: > > Hello Erik, > > > On 2013/11/04 2:27, Erik Wilde wrote: > > hello. > > seeing that > http://tools.ietf.org/html/__draft-ietf-json-rfc4627bis > is > making good progress, i wanted to raise the question of maybe adding > profile support to the JSON media type. > > http://tools.ietf.org/html/__draft-wilde-atom-profile > is a > proposal for > adding profile support to the atom media type, and the "profile" > optional media type parameter > (http://tools.ietf.org/html/__draft-wilde-atom-profile-02#__section-4.1.1 > ) > is what could be added to JSON as well. > > the advantage would be that different JSON-based formats could be > distinguished by their (mediatype+profile). this would allow > JSON-based > formats to become more visible on the web level, instead of > always just > saying "i am JSON", without any ability to differentiate. > > > I don't understand this. JSON-based formats can be distinguished by > registering a mime type. E.g., application/foo+json can be > distinguished from application/bar+json. If that's not what you > mean, can you give some examples of what you mean? > > In general, adding a parameter doesn't work very well, because the > infrastructure (e.g. setting mechanisms on the server side,...) > isn't developped. > > With respect to your atom profile proposal, it contains ideas for > actual usage, but they all use "would". I think you should wait to > pursue that draft until you have an *actual* use case, i.e. an > actual profile parameter value. Just defining protocol slots without > values isn't something that's done in the IETF, and isn't something > that makes sense to spend IETF resources on. > > Regards, Martin. > > thanks and cheers, > > dret. > > _________________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/__listinfo/apps-discuss > > > -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From jasnell@gmail.com Tue Nov 5 10:15:23 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D98921F9E26 for ; Tue, 5 Nov 2013 10:15:22 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iACZlW4QZV6U for ; Tue, 5 Nov 2013 10:15:20 -0800 (PST) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7660821F9E51 for ; Tue, 5 Nov 2013 10:15:19 -0800 (PST) Received: by mail-oa0-f41.google.com with SMTP id m1so961145oag.14 for ; Tue, 05 Nov 2013 10:15:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SJoBpkGB3u2jdAkzPhFSZoaE1TyftkpUCTddOPBgnLk=; b=YnQTc+4Tapx5C7rURf7II3blAtLv8mez1PGh4N7lIqe2pCb8944+hUVZ5VaOuVVXXN DPmbWdkYwwN442UPTfIu29KDqqdNG9Lv4pee7rID6gHjn9kG1TdMkWAjVej9Yx6chm3n gvxCg2QLdtsiWGVYv6pkTYVZfEDnp2WkPq6nrGpgFd2YwGOsYEP6lVvs5LyQIGL+3OtO YeylHchrgeOcu7/yjzVnjfZ9IRHBpV9L8t5Zmfdj4+3Ue0FEOVqqAeKeBPkG1DbuUCH2 JBnTd7RhcDOpiudNjn2/TsQWtI+G1pVhaHkAhz2yKW4rtvO9y4cR7aGaj9pdCvTVq4Vn uq2Q== X-Received: by 10.182.196.3 with SMTP id ii3mr20204968obc.11.1383675318909; Tue, 05 Nov 2013 10:15:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.124.137 with HTTP; Tue, 5 Nov 2013 10:14:58 -0800 (PST) In-Reply-To: <5276878A.6000802@berkeley.edu> References: <5276878A.6000802@berkeley.edu> From: James M Snell Date: Tue, 5 Nov 2013 10:14:58 -0800 Message-ID: To: Erik Wilde Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] proposal: adding profile support to JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 18:15:24 -0000 +1. Adding support for "profile" is harmless. It can safely be ignored by anyone who feels it is unnecessary and introducing new profiles is far less complicated than getting a new media sub-type accepted. On Sun, Nov 3, 2013 at 9:27 AM, Erik Wilde wrote: > hello. > > seeing that http://tools.ietf.org/html/draft-ietf-json-rfc4627bis is making > good progress, i wanted to raise the question of maybe adding profile > support to the JSON media type. > > http://tools.ietf.org/html/draft-wilde-atom-profile is a proposal for adding > profile support to the atom media type, and the "profile" optional media > type parameter > (http://tools.ietf.org/html/draft-wilde-atom-profile-02#section-4.1.1) is > what could be added to JSON as well. > > the advantage would be that different JSON-based formats could be > distinguished by their (mediatype+profile). this would allow JSON-based > formats to become more visible on the web level, instead of always just > saying "i am JSON", without any ability to differentiate. > > thanks and cheers, > > dret. > > -- > erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | > | UC Berkeley - School of Information (ISchool) | > | http://dret.net/netdret http://twitter.com/dret | > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From dret@berkeley.edu Tue Nov 5 10:34:22 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FBF21E80BE for ; Tue, 5 Nov 2013 10:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.63 X-Spam-Level: X-Spam-Status: No, score=-5.63 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgiqdTG3mk7I for ; Tue, 5 Nov 2013 10:34:07 -0800 (PST) Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id 10EE911E80DE for ; Tue, 5 Nov 2013 10:34:07 -0800 (PST) Received: from dhcp-a1c6.meeting.ietf.org ([31.133.161.198]) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1VdlRy-0004Gm-4m for apps-discuss@ietf.org; Tue, 05 Nov 2013 10:34:06 -0800 Message-ID: <52793A16.8060301@berkeley.edu> Date: Tue, 05 Nov 2013 10:33:58 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 CC: "apps-discuss@ietf.org application-layer protocols" References: <5276878A.6000802@berkeley.edu> <5278AF21.90605@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] proposal: adding profile support to JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 18:34:22 -0000 hello mark. On 2013-11-05, 08:59 , Mark Baker wrote: > On Tue, Nov 5, 2013 at 10:57 AM, Tim Bray wrote: >> Well, for example, http://www.tbray.org/tmp/draft-bray-i-json-01.html > I'm with Martin. What that spec is trying to do with profiles is to > supplant the typical role of a media type. If it's representative of > what Erik has in mind for the use of a profile parameter with Atom (or > anywhere), then I think that needs to be reconsidered too. i understand your concerns, but profiles do not attempt to "replace media types", even though they could be (mis-)used to try to do just that. [1] tries to explain the goal: they are for specializing and/or constraining existing media types; representing both the nature of the underlying type ("this is an atom feed and can be processed as a generic feed") as well as the specialized/constrained profile ("this feed carries podcast data, and can be processed as a podcast feed"). james snell blogged about the bigger problem [2] that media types as they are today are not a terribly well-designed concept. i think that's correct, and profiles are just a minor "patch" in that space. what james suggests would be much more comprehensive and much more involved, but would affect so may parts of internet/web architecture that maybe using profiles as a stepping stone is a useful first step. cheers, dret. [1] http://dret.typepad.com/dretblog/2013/03/on-profiles.html [2] http://www.chmod777self.com/2012/04/more-on-future-of-mime-media-types.html -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From jasnell@gmail.com Tue Nov 5 11:17:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8635011E81BB for ; Tue, 5 Nov 2013 11:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9X5ZIVyTx5xR for ; Tue, 5 Nov 2013 11:17:46 -0800 (PST) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 83DA511E8117 for ; Tue, 5 Nov 2013 11:17:44 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id gq1so9066765obb.31 for ; Tue, 05 Nov 2013 11:17:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=53soQimZs5HHg7kJz1eh4x0b74fkeddHGYvrXvXs+F4=; b=vQVEKFCOvMJNu6uOE7OkL/xcacxU+Jsiwt2W1LRi74Rfogp1isSeujYmaJYjvKU+fp 2E7MX/MmRYL0IVvD3WSD2Uhfo7+KtlDlQy7d7szQBcoa1jmDRG6YT8yQXXsfAHvjHQQF lWv9+gneAP/NTHfqpZGCEibASkF7QAUDEx44/otXxt2OLgbr7nERH5aYu5qcc00en8uM 8cvj2CLkNFRCcWJdTFtnWSXrBADeScdhfUs77wjjxH0/+kg3WBCw616EfOCxE6UfLhg/ 8jZfplbO0tgoNOGR2XfdIFJVFYEg87bcPeZ2URYVXbsxvwD8GNjiM2/JypIpYh/X7H0D E5vA== X-Received: by 10.182.243.138 with SMTP id wy10mr28375obc.83.1383679063902; Tue, 05 Nov 2013 11:17:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.124.137 with HTTP; Tue, 5 Nov 2013 11:17:23 -0800 (PST) In-Reply-To: <52793A16.8060301@berkeley.edu> References: <5276878A.6000802@berkeley.edu> <5278AF21.90605@it.aoyama.ac.jp> <52793A16.8060301@berkeley.edu> From: James M Snell Date: Tue, 5 Nov 2013 11:17:23 -0800 Message-ID: To: Erik Wilde Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] proposal: adding profile support to JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 19:17:47 -0000 On Tue, Nov 5, 2013 at 10:33 AM, Erik Wilde wrote: > hello mark. >[snip] > > james snell blogged about the bigger problem [2] that media types as they > are today are not a terribly well-designed concept. i think that's correct, > and profiles are just a minor "patch" in that space. what james suggests > would be much more comprehensive and much more involved, but would affect so > may parts of internet/web architecture that maybe using profiles as a > stepping stone is a useful first step. > heh... why do I suddenly have the sense that Erik is defending the profile proposal as a significantly less crazy idea than what I was suggesting ;-) ... Stepping back a bit, it ought to be recognized that media types are being asked to do far more today than they have been in the past. XML and JSON are generic data formats used for a very broad range of purposes. Falling back on the simple application/json and application/xml media types is certainly not sufficient and attempting to come up with an application/[variation]+[base] media type for every possible variation simply is not a scalable approach in the long run. Allowing for "profile" provides a useful escape hatch by eliminating the need to register and track every possible variation. That said, even profile is limited in a sense. The "Content Profile" approach I suggested in my blog post (as radically different it may appear) would deal with scalability issues inherent in the current media type scheme... but I suspect that the likelihood of making such changes is exceedingly low. - James > cheers, > > dret. > > [1] http://dret.typepad.com/dretblog/2013/03/on-profiles.html > [2] > http://www.chmod777self.com/2012/04/more-on-future-of-mime-media-types.html > > > -- > erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | > | UC Berkeley - School of Information (ISchool) | > | http://dret.net/netdret http://twitter.com/dret | > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From dret@berkeley.edu Tue Nov 5 13:47:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D88B21F9B10 for ; Tue, 5 Nov 2013 13:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.168 X-Spam-Level: X-Spam-Status: No, score=-6.168 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9w69jTzlp6PL for ; Tue, 5 Nov 2013 13:47:34 -0800 (PST) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFF611E80E3 for ; Tue, 5 Nov 2013 13:47:32 -0800 (PST) Received: from dhcp-a1c6.meeting.ietf.org ([31.133.161.198]) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1VdoTC-0001O1-CM; Tue, 05 Nov 2013 13:47:32 -0800 Message-ID: <52796772.7030000@berkeley.edu> Date: Tue, 05 Nov 2013 13:47:30 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Tim Bray , "apps-discuss@ietf.org application-layer protocols" References: <5276878A.6000802@berkeley.edu> <5278AF21.90605@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] proposal: adding profile support to JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 21:47:42 -0000 hello. On 2013-11-05, 07:57 , Tim Bray wrote: > Well, for example, http://www.tbray.org/tmp/draft-bray-i-json-01.html while i of course like the idea of I-JSON being a profile of JSON, if that's supposed to work in the same way as RFC 6906 ("The 'profile' Link Relation Type") specifies, then http://tools.ietf.org/html/draft-bray-i-json-00.html#section-2.1 and http://tools.ietf.org/html/rfc6906#section-3.1 are in conflict. that's because RFC-6906 profile identifiers must be URIs. one option therefore might be to use something like urn:ietf:rfc:XXXX as the profile identifier (or something else, if it should be stable before the RFC number is assigned). cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From mnot@mnot.net Tue Nov 5 15:45:43 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE9E21F9E99 for ; Tue, 5 Nov 2013 15:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.313 X-Spam-Level: X-Spam-Status: No, score=-104.313 tagged_above=-999 required=5 tests=[AWL=-1.714, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnhMHBpE9slk for ; Tue, 5 Nov 2013 15:45:39 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id D4A6221E815D for ; Tue, 5 Nov 2013 15:45:13 -0800 (PST) Received: from dhcp-9109.meeting.ietf.org (unknown [31.133.145.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D9FBD50AA4; Tue, 5 Nov 2013 18:45:10 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Mark Nottingham In-Reply-To: Date: Tue, 5 Nov 2013 15:45:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <93E08AC0-9D97-4296-B139-DE439D3DE8B2@mnot.net> References: <527825DB.6010105@gmx.de> To: "Henry S. Thompson" X-Mailer: Apple Mail (2.1816) Cc: "Julian F. Reschke" , "apps-discuss@ietf.org Discuss" , HTTP Working Group , "www-tag@w3.org WG" Subject: Re: [apps-discuss] Request that the WG reconsider section 3.4: Content Negotiation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 23:45:43 -0000 Hi Henry, On 5 Nov 2013, at 4:18 am, Henry S. Thompson wrote: >> Reactive conneg isn't just about 300s and 406s. Another example would >> be a representation returned with a 200 response that contains links >> to alternate versions of the content. That's what the >=20 > How is this in scope for discussion _in the HTTP spec._? People (not > user agents, note) use 200 responses for a huge range of interesting, > powerful, innovative things. We don't look in the HTTP spec. to find > a discussion of them. You seem to be thinking of HTTP as a separate layer from the = application; as section 3.4 of p2 says, it=92s defining a pattern of = use, and that is certainly in scope for this specification, given that = it was also in scope for RF2616. > "If the user agent is not satisfied by the initial response >> representation, it can perform a GET request on one or more of the >> alternative resources, selected based on metadata included in the >> list, to obtain a different form of representation for that >> response. Selection of alternatives might be performed automatically >> by the user agent or manually by the user selecting from a generated >> (possibly hypertext) menu." >=20 > "based on metadata included in the list"! That's a specific reference > to a 300 response. There is no "list" in a 200 response, not that a > user agent can detect anyway. If there is more than one link in the response in *some* format that=92s = tied together in some fashion (e.g., with a link relation, as per = RF5988), there certainly is a list available. We talked about this issue at the WG meeting yesterday. Based upon that = discussion, we decided to close this issue. Looking at = , I can=92t see any immediate = clarifications that would help; if you can suggest some, please do bring = them to our attention. Regards, -- Mark Nottingham http://www.mnot.net/ From ietf@rozanak.com Tue Nov 5 15:58:52 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D1111E811A for ; Tue, 5 Nov 2013 15:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLnq7T9G07GV for ; Tue, 5 Nov 2013 15:58:48 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id C432611E8160 for ; Tue, 5 Nov 2013 15:58:47 -0800 (PST) Received: from kopoli (dhcp-a798.meeting.ietf.org [31.133.167.152]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MZUCj-1VKwl22RWn-00LQTd; Tue, 05 Nov 2013 18:58:44 -0500 From: "Hosnieh Rafiee" To: Date: Wed, 6 Nov 2013 00:58:38 +0100 Message-ID: <002101ceda82$f49bd4e0$ddd37ea0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7aguvIJzWW0Fl+Ta2sGcfnv9ol+w== Content-Language: en-us X-Provags-ID: V02:K0:HPs4AV71NtMZ2Knw63BNPlqWXapfkz7ckMYSu+XCZQh S/WKYXGfZ9zTx1iHfsgJcqzAWdNh2lPiUHQrm6zoGeDgtvIg68 QiuHKaV9MFBPnV53/r6qgByDtIbGE1Hhtr2/ZkVwjvYDtmt54O H0y50pRh6wiaRJTR53K/UGL3yVNpXetZ6aAPzUSGmFAXvhgiJH brNnVZPcmvV7h/Fpl1cXODVcVk/gMehaVWOx1w8hARsTWjGoma 25TGMvQ6C+Ub1m7FcxDOtwDciO1U8+tK2SHYVqudECXNzTXUar ZYA1i57r/9G90+RmtNEtsc4BrtzgQNHl4B/94iIWtNPMsZ4Iro QDW/tTRWYCptH1RGwqbo= Cc: Erik Nordmark Subject: [apps-discuss] privacy in applications - anybody working in this area or interested? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 23:58:52 -0000 Hello, We're looking for enhancing applications with privacy features by assigning different Interface ID (IID) to them. We're looking for people who work on privacy in applications. We have a presentation in v6ops tomorrow and we ask the people who works in this area to contact us and if possible for them to attend to our presentation "iid-lifetime". https://tools.ietf.org/html/draft-rafiee-v6ops-iid-lifetime Thank you -----------smile---------- Hosnieh . success is a journey, not a destination.. You cannot change your destination overnight, but you can change your direction ... Focus on the journey From julian.reschke@gmx.de Tue Nov 5 17:02:46 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9758F21F9D19 for ; Tue, 5 Nov 2013 17:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.199 X-Spam-Level: X-Spam-Status: No, score=-104.199 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzQ884qyinPj for ; Tue, 5 Nov 2013 17:02:41 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC7321F9D35 for ; Tue, 5 Nov 2013 17:02:41 -0800 (PST) Received: from [31.133.162.78] ([31.133.162.78]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lk7T8-1WBHef0U0I-00cC3k for ; Wed, 06 Nov 2013 02:02:40 +0100 Message-ID: <5279952E.5040402@gmx.de> Date: Wed, 06 Nov 2013 02:02:38 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: James M Snell , Mark Nottingham References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:6EVad/f13+NhleTNLs3sd6U8BdgarrMgWgfofYHSlRIVwRZAJjg pwGpti9iubZkKNNH/junsMAAAcNCwqMqYTCRU99RMVIXbbtyKWbNZiD1WBLK4X9tfsTiXXD NQ1avapiurI6pihFzMeUlTE2TO1M3elVPM7EeIFjkV8E96VtlKX5VyTQ5DFUy0p2qJQyDcv H5MfEBBU1KRfyYexKJRPg== Cc: ietf-http-wg@w3.org, IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 01:02:46 -0000 On 2013-10-29 06:59, James M Snell wrote: > > On Oct 28, 2013 10:48 PM, "Mark Nottingham" > wrote: > > > > > > On 24/09/2013, at 5:17 AM, James M Snell > wrote: > > > > > Just a general FYI... I have submitted iteration -04 of the > > > LINK/UNLINK draft with a few minor editorial fixes... and, I have > > > formally requested Last Call status as an Independent Submission on > > > the Standards Track. > > > > > > http://tools.ietf.org/html/draft-snell-link-method-04 > > > > In Section 2 of -05: > > > > "For any pair of resources, exactly one relationship of any given > type can exist." > > > > That's a new and apparently backwards-incompatible change to the > model of linking on the Web... e.g., consider "stylesheet". > > > > No, read it again, as a uniqueness constraint on the tuple (resource, > link relation, resource). That's not new or novel. > ... Not convinced. Consider the various target attributes, or extension parameters. If they do not contribute to the uniqueness constraint, you *are* constraining the linking model. Best regards, Julian From scott.brim@gmail.com Tue Nov 5 17:03:50 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52C821F9D8D for ; Tue, 5 Nov 2013 17:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.295 X-Spam-Level: X-Spam-Status: No, score=-102.295 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+pmUrQ4uUm1 for ; Tue, 5 Nov 2013 17:03:50 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 575C721F9D56 for ; Tue, 5 Nov 2013 17:03:50 -0800 (PST) Received: by mail-ob0-f173.google.com with SMTP id gq1so9380390obb.18 for ; Tue, 05 Nov 2013 17:03:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O6J8zI22DusfrAVFASjXVa3mIiExUYgHmbfCESt7fnY=; b=HOhGuKeJzzUazMK0VKP7pT/wjble5/XmczlX73KvJCBPj9JpjggdlPiY+AsYHM7bq1 cSBEsnp544jD7L3quPphsq7iAgsawpeGrRmOvCsdK0mzIjpYKX6RLR4xXnHZ0riimpBK N+hCY63HdJaZTrd3nSOB3wKL1KQQgspSDrFvbMi9U1kbLcMc5LUa7Nz9e1WJ65fkH9G+ /YOSjieO6m+H0ZvSD3aunMaTRmlQWuBt5Wy+WVVthNRJYMfeh2FAhZj8TUC3w28Hh2h4 794sAwIiJlYFHz6VGQmDaA+daC2UD/Ry6+ls78ja8yePWN3traAiU1mj0cgUzQ9iBmPe SQjw== MIME-Version: 1.0 X-Received: by 10.182.104.36 with SMTP id gb4mr324468obb.43.1383699829831; Tue, 05 Nov 2013 17:03:49 -0800 (PST) Received: by 10.182.2.134 with HTTP; Tue, 5 Nov 2013 17:03:49 -0800 (PST) In-Reply-To: <002101ceda82$f49bd4e0$ddd37ea0$@rozanak.com> References: <002101ceda82$f49bd4e0$ddd37ea0$@rozanak.com> Date: Tue, 5 Nov 2013 17:03:49 -0800 Message-ID: From: Scott Brim To: Hosnieh Rafiee Content-Type: multipart/alternative; boundary=089e013a215ad58e7c04ea77b8f7 Cc: Erik Nordmark , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] privacy in applications - anybody working in this area or interested? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 01:03:50 -0000 --089e013a215ad58e7c04ea77b8f7 Content-Type: text/plain; charset=ISO-8859-1 On Tuesday, November 5, 2013, Hosnieh Rafiee wrote: > Hello, > We're looking for enhancing applications with privacy features by assigning > different Interface ID (IID) to them. We're looking for people who work on > privacy in applications. We have a presentation in v6ops tomorrow and we > ask > the people who works in this area to contact us and if possible for them to > attend to our presentation "iid-lifetime". > https://tools.ietf.org/html/draft-rafiee-v6ops-iid-lifetime Hosnieh, You've opened up a multi-layer issue here. If each application gets a separate IID, that could make privacy more difficult, in that it could be easier to track and correlate the behavior of applications even with low layer encryption. Your proposal could be okay if each application (or session, actually) could request a new IID at an arbitrary time, and if there were a general way for sessions to let each other know this was happening, like multihomed transport. Fun yet? Scott --089e013a215ad58e7c04ea77b8f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tuesday, November 5, 2013, Hosnieh Rafiee wrote:
Hello,
We're looking for enhancing applications with privacy features by assig= ning
different Interface ID (IID) to them. We're looking for people who work= on
privacy in applications. We have a presentation in v6ops tomorrow and we as= k
the people who works in this area to contact us and if possible for them to=
attend to our presentation "iid-lifetime".
https://tools.ietf.org/html/draft-rafiee-v6ops-iid-lifetime<= /a>



Scott

--089e013a215ad58e7c04ea77b8f7-- From jasnell@gmail.com Tue Nov 5 17:06:49 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE8011E818C for ; Tue, 5 Nov 2013 17:06:49 -0800 (PST) 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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHmoLKC4mLHk for ; Tue, 5 Nov 2013 17:06:48 -0800 (PST) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id F122211E8163 for ; Tue, 5 Nov 2013 17:06:43 -0800 (PST) Received: by mail-oa0-f48.google.com with SMTP id h16so1452429oag.21 for ; Tue, 05 Nov 2013 17:06:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wv3H9nR6REIUoJsgFylkH8Ryj9UtcEWVGMahrHxp12Q=; b=Lw1OUA0Eyf/pcC6DEHIm90Ss1kbnRJhIm7UXWIuj2r2B7qL8H6yaD0zdCNPJxURiwE 1KPa+B//h/xE1qnk76z2q+ZldPbax+9s14KbLEaHrNkkwr7dyaVzsVoxMy8wBG2BeCjK HyLR3CCLbBD1Sf+t5XAhhMI/pRwNnM6nevuf3GSG2Gb5w/Y3aUo9LcCUxpUfWyVGXGiG b5u8aQmAtxdpZKrSPYBHjUrDkOMjISFQkbH0BAoP8ziailFnAEg5RNbpm8N+4o2M7+Zv q/GUox52IzhNL5H/nFGKavN9YNtnS2P73t+0GQZDgK2HUtIe6ISE1+Hpns6z/OopmMyI Aorg== MIME-Version: 1.0 X-Received: by 10.60.149.169 with SMTP id ub9mr331180oeb.39.1383700003513; Tue, 05 Nov 2013 17:06:43 -0800 (PST) Received: by 10.60.124.137 with HTTP; Tue, 5 Nov 2013 17:06:43 -0800 (PST) Received: by 10.60.124.137 with HTTP; Tue, 5 Nov 2013 17:06:43 -0800 (PST) In-Reply-To: <5279952E.5040402@gmx.de> References: <5279952E.5040402@gmx.de> Date: Tue, 5 Nov 2013 17:06:43 -0800 Message-ID: From: James M Snell To: Julian Reschke Content-Type: multipart/alternative; boundary=047d7b41c0ba2f6eeb04ea77c380 Cc: Mark Nottingham , ietf-http-wg@w3.org, IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 01:06:49 -0000 --047d7b41c0ba2f6eeb04ea77c380 Content-Type: text/plain; charset=UTF-8 Give me a viable, non theoretical use case where the other target attributes and extension parameters would make a difference and I'll reconsider that constraint. On Nov 5, 2013 5:02 PM, "Julian Reschke" wrote: > On 2013-10-29 06:59, James M Snell wrote: > >> >> On Oct 28, 2013 10:48 PM, "Mark Nottingham" > > wrote: >> > >> > >> > On 24/09/2013, at 5:17 AM, James M Snell > > wrote: >> > >> > > Just a general FYI... I have submitted iteration -04 of the >> > > LINK/UNLINK draft with a few minor editorial fixes... and, I have >> > > formally requested Last Call status as an Independent Submission on >> > > the Standards Track. >> > > >> > > http://tools.ietf.org/html/draft-snell-link-method-04 >> > >> > In Section 2 of -05: >> > >> > "For any pair of resources, exactly one relationship of any given >> type can exist." >> > >> > That's a new and apparently backwards-incompatible change to the >> model of linking on the Web... e.g., consider "stylesheet". >> > >> >> No, read it again, as a uniqueness constraint on the tuple (resource, >> link relation, resource). That's not new or novel. >> ... >> > > Not convinced. > > Consider the various target attributes, or extension parameters. If they > do not contribute to the uniqueness constraint, you *are* constraining the > linking model. > > Best regards, Julian > --047d7b41c0ba2f6eeb04ea77c380 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Give me a viable, non theoretical use case where the other t= arget attributes and extension parameters would make a difference and I'= ;ll reconsider that constraint.

On Nov 5, 2013 5:02 PM, "Julian Reschke&quo= t; <julian.reschke@gmx.de&g= t; wrote:
On 2013-10-29 06:59, James M Snell wrote:

On Oct 28, 2013 10:48 PM, "Mark Nottingham" <mnot@mnot.net
<mailto:mnot@mnot.net= >> wrote:
=C2=A0>
=C2=A0>
=C2=A0> On 24/09/2013, at 5:17 AM, James M Snell <jasnell@gmail.com
<mailto:jasnell@g= mail.com>> wrote:
=C2=A0>
=C2=A0> > Just a general FYI... I have submitted iteration -04 of the=
=C2=A0> > LINK/UNLINK draft with a few minor editorial fixes... and, = I have
=C2=A0> > formally requested Last Call status as an Independent Submi= ssion on
=C2=A0> > the Standards Track.
=C2=A0> >
=C2=A0> > http://tools.ietf.org/html/draft-snell-link= -method-04
=C2=A0>
=C2=A0> In Section 2 of -05:
=C2=A0>
=C2=A0> "For any pair of resources, exactly one relationship of any= given
type can exist."
=C2=A0>
=C2=A0> That's a new and apparently backwards-incompatible change to= the
model of linking on the Web... e.g., consider "stylesheet".
=C2=A0>

No, read it again, as a uniqueness constraint on the tuple (resource,
link relation, resource). That's not new or novel.
...

Not convinced.

Consider the various target attributes, or extension parameters. If they do= not contribute to the uniqueness constraint, you *are* constraining the li= nking model.

Best regards, Julian
--047d7b41c0ba2f6eeb04ea77c380-- From julian.reschke@gmx.de Tue Nov 5 17:09:28 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAB621E80CD for ; Tue, 5 Nov 2013 17:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.313 X-Spam-Level: X-Spam-Status: No, score=-104.313 tagged_above=-999 required=5 tests=[AWL=-1.714, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOlNUWcahUkf for ; Tue, 5 Nov 2013 17:09:23 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4448D21E80C9 for ; Tue, 5 Nov 2013 17:09:14 -0800 (PST) Received: from [31.133.162.78] ([31.133.162.78]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MWSwU-1V7VZq49d4-00XZM0 for ; Wed, 06 Nov 2013 02:09:13 +0100 Message-ID: <527996B8.50802@gmx.de> Date: Wed, 06 Nov 2013 02:09:12 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: James M Snell , "ietf-http-wg@w3.org" , IETF Apps Discuss References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:tSMe/wxCoVQ5n1lLf/7EeqCU7UwyDSbARln7pCNY+4fRIWFdpaC ARsl/IiSJNFquIyN3W4Yrl1A/Z2VnV9dMpB2wX8A43EPB3K+C7H6RazA7vR83/DAcVAIMIe 8f2GF54gEMMQl9jOJFInmAVnt9YN8mS0a2tKwkw3sQIGuyw6pWNdEV4jhueJm63UgFIXcUx Vz14v5qy//BpZObAjYWXQ== Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 01:09:28 -0000 On 2013-09-23 21:17, James M Snell wrote: > Just a general FYI... I have submitted iteration -04 of the > LINK/UNLINK draft with a few minor editorial fixes... and, I have > formally requested Last Call status as an Independent Submission on > the Standards Track. > > http://tools.ietf.org/html/draft-snell-link-method-04 Hi James, some feedback: - you may want to talk about what kind of processing of the link target happens, such as: is the server allowed or even required to check the target's existence (thus can LINK create "dangling" links?) If it does, an example would help (status code etc) - clarify whether an anchor parameter should either be ignored or be an error - you and I know that success could be 200 or 204, but if you don't have it at least in the examples, at least some people will be confused (and argue whether it should be 201 :-) - is it an error to try to remove a link that doesn't exist? What if I try to UNLINK one existing and one non-existing one? Best regards, Julian From jasnell@gmail.com Tue Nov 5 17:12:59 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8DB21E8168 for ; Tue, 5 Nov 2013 17:12:59 -0800 (PST) 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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxQDxsvgTgMl for ; Tue, 5 Nov 2013 17:12:58 -0800 (PST) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 99F8E21E80CA for ; Tue, 5 Nov 2013 17:12:56 -0800 (PST) Received: by mail-ob0-f175.google.com with SMTP id va2so1618837obc.34 for ; Tue, 05 Nov 2013 17:12:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jB8i+ngtXIshRRwQvbq6d9Wzo57PdjsRO3GBw52rwro=; b=W1MIfkagxJHGZ9XVoxGyeoESrtc/oODG7L5NNM3tY5lersODGFQucy6XBgQ9q5ExRo mzCTdFMM8WjVuxMeFqWv86fn1KG3b3sHtaLxBT9I86VHA8/khnXBpG+hDG/thLRD0uul cpTJdkd0AX2QXOn9HaDpSlZN+NV6vaxJbEnwiYrsW+OXitfVW2taEnjvCf9213f0Z0LB +YS0ouBV+fv0P5k4OZlx8RszOnpQ3/UywZTSDx4uB3Ykav68X1UQnMW45yeCFtwT9LZQ FxnxV2HZ2pFfkaWCSdo1CUOGta2sMuKWI9yooWgV7guMBhNY4Cj6Ri9qGsv6XiWN7xIV qh2Q== MIME-Version: 1.0 X-Received: by 10.60.56.3 with SMTP id w3mr357306oep.37.1383700376095; Tue, 05 Nov 2013 17:12:56 -0800 (PST) Received: by 10.60.124.137 with HTTP; Tue, 5 Nov 2013 17:12:56 -0800 (PST) Received: by 10.60.124.137 with HTTP; Tue, 5 Nov 2013 17:12:56 -0800 (PST) In-Reply-To: <527996B8.50802@gmx.de> References: <527996B8.50802@gmx.de> Date: Tue, 5 Nov 2013 17:12:56 -0800 Message-ID: From: James M Snell To: Julian Reschke Content-Type: multipart/alternative; boundary=001a11c20a7264961604ea77d9d7 Cc: ietf-http-wg@w3.org, IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 01:12:59 -0000 --001a11c20a7264961604ea77d9d7 Content-Type: text/plain; charset=UTF-8 Excellent feedback. Thank you. Will incorporate it. On Nov 5, 2013 5:09 PM, "Julian Reschke" wrote: > On 2013-09-23 21:17, James M Snell wrote: > >> Just a general FYI... I have submitted iteration -04 of the >> LINK/UNLINK draft with a few minor editorial fixes... and, I have >> formally requested Last Call status as an Independent Submission on >> the Standards Track. >> >> http://tools.ietf.org/html/draft-snell-link-method-04 >> > > Hi James, > > some feedback: > > - you may want to talk about what kind of processing of the link target > happens, such as: is the server allowed or even required to check the > target's existence (thus can LINK create "dangling" links?) If it does, an > example would help (status code etc) > > - clarify whether an anchor parameter should either be ignored or be an > error > > - you and I know that success could be 200 or 204, but if you don't have > it at least in the examples, at least some people will be confused (and > argue whether it should be 201 :-) > > - is it an error to try to remove a link that doesn't exist? What if I try > to UNLINK one existing and one non-existing one? > > Best regards, Julian > > --001a11c20a7264961604ea77d9d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Excellent feedback. Thank you. Will incorporate it.

On Nov 5, 2013 5:09 PM, "Julian Reschke&quo= t; <julian.reschke@gmx.de&g= t; wrote:
On 2013-09-23 21:17, James M Snell wrote:
Just a general FYI... I have submitted iteration -04 of the
LINK/UNLINK draft with a few minor editorial fixes... and, I have
formally requested Last Call status as an Independent Submission on
the Standards Track.

=C2=A0 =C2=A0http://tools.ietf.org/html/draft-snell-link-me= thod-04

Hi James,

some feedback:

- you may want to talk about what kind of processing of the link target hap= pens, such as: is the server allowed or even required to check the target&#= 39;s existence (thus can LINK create "dangling" links?) If it doe= s, an example would help (status code etc)

- clarify whether an anchor parameter should either be ignored or be an err= or

- you and I know that success could be 200 or 204, but if you don't hav= e it at least in the examples, at least some people will be confused (and a= rgue whether it should be 201 :-)

- is it an error to try to remove a link that doesn't exist? What if I = try to UNLINK one existing and one non-existing one?

Best regards, Julian

--001a11c20a7264961604ea77d9d7-- From julian.reschke@gmx.de Tue Nov 5 17:14:07 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A5F11E818C for ; Tue, 5 Nov 2013 17:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.377 X-Spam-Level: X-Spam-Status: No, score=-104.377 tagged_above=-999 required=5 tests=[AWL=-1.778, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUOpXFLHUZsc for ; Tue, 5 Nov 2013 17:14:02 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id BC5B421E808F for ; Tue, 5 Nov 2013 17:13:57 -0800 (PST) Received: from [31.133.162.78] ([31.133.162.78]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LjIBr-1WC6Jf2B5z-00dV3O for ; Wed, 06 Nov 2013 02:13:56 +0100 Message-ID: <527997D3.4010108@gmx.de> Date: Wed, 06 Nov 2013 02:13:55 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: James M Snell References: <5279952E.5040402@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:lMgX4Nlw0WEergS4kDEABTtoSliGzmpiGSI+oOvwwqPZ2A5VcCZ raJP9jKzl6i4IbyMy6P0MZ1W/0jgeZJ5umqHVjFu3AUBG0uXoZ0HILQ8TvGt4MFNMG0k6yC cik+530Is8DebFbZcKQCrprkXoklWCBEz/mDDSnS0wJIjkjeAc5U/Oi+G128VLm+cOQUbgZ VX8zVnft6wp7mZo+NbFKw== Cc: Mark Nottingham , ietf-http-wg@w3.org, IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 01:14:08 -0000 On 2013-11-06 02:06, James M Snell wrote: > Give me a viable, non theoretical use case where the other target > attributes and extension parameters would make a difference and I'll > reconsider that constraint. > ... I'll try, but in the meantime it would be good if you could explain why the constraint is there in the first place :-) Best regards, Julian From vkg@bell-labs.com Tue Nov 5 17:17:07 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC32511E818C; Tue, 5 Nov 2013 17:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ey3WnsEDgkyj; Tue, 5 Nov 2013 17:17:03 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 0256521F9CAC; Tue, 5 Nov 2013 17:17:02 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rA61GvkS026738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 5 Nov 2013 19:16:57 -0600 (CST) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id rA61Gulo010482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Nov 2013 19:16:57 -0600 Received: from shoonya.ih.lucent.com (vkg.lra.lucent.com [135.244.18.43]) by umail.lucent.com (8.13.8/TPES) with ESMTP id rA61Gt9Y023649; Tue, 5 Nov 2013 19:16:56 -0600 (CST) Message-ID: <5279987E.6080803@bell-labs.com> Date: Tue, 05 Nov 2013 19:16:46 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: Gonzalo Camarillo References: <52432012.9070104@bell-labs.com> <52792ECE.80006@ericsson.com> In-Reply-To: <52792ECE.80006@ericsson.com> 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 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: draft-ietf-insipid-session-id-reqts.all@tools.ietf.org, 'James Polk' , 'IESG IESG' , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-insipid-session-id-reqts-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 01:17:08 -0000 On 11/05/2013 11:45 AM, Gonzalo Camarillo wrote: > Hi Vijay, > > Paul has just revised the draft to address your comments (see his > separate email about the discussions that took place within the WG). > Could you please let us know if you are happy with the new revision? Gonzalo: I saw Paul's email on the insipid list. I am fine with the outcome. I have no further comments on the draft. Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From jasnell@gmail.com Tue Nov 5 17:18:55 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BD811E8205 for ; Tue, 5 Nov 2013 17:18:55 -0800 (PST) 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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YQdKNLMJcM5 for ; Tue, 5 Nov 2013 17:18:54 -0800 (PST) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB2011E81F9 for ; Tue, 5 Nov 2013 17:18:54 -0800 (PST) Received: by mail-oa0-f50.google.com with SMTP id j17so1443014oag.23 for ; Tue, 05 Nov 2013 17:18:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qoZfz5gi4PPtQsxPT0eVQO8NnVD0B1JqY8srISywNeU=; b=SaJgDM7OeRIqTfJPu7grONDo5U6yGuqmrMjTgAh2M/OObhII+7vaZ9HtfqXOKASO1X NKzTapAEOvZMo50I121PRoQ8PEYg2mmTux19yYYC7svlPXYfRCVJ69iurBV2JRcqhLK8 K2Rc+7rFnoJyaj80Ix5Y7iVTdwxGUkixDUI+3vpg7SJONwJIWOz3gi3Gy4PiMfY6tugF 0tGs3bLlSc2g5Oko6ZiETJAmmh1/qy1ES+Cw24lttgdLTNJ4lSeOtP2/oDdpO3YVdgU9 3SbVpFApZVivtPLCR5AIxJEJPxZYwMJxyl/+xogEHwGzMmkWW+C72nQHjGxjn5sXhFHD +A8g== MIME-Version: 1.0 X-Received: by 10.60.58.166 with SMTP id s6mr444381oeq.40.1383700734092; Tue, 05 Nov 2013 17:18:54 -0800 (PST) Received: by 10.60.124.137 with HTTP; Tue, 5 Nov 2013 17:18:54 -0800 (PST) Received: by 10.60.124.137 with HTTP; Tue, 5 Nov 2013 17:18:54 -0800 (PST) In-Reply-To: <527997D3.4010108@gmx.de> References: <5279952E.5040402@gmx.de> <527997D3.4010108@gmx.de> Date: Tue, 5 Nov 2013 17:18:54 -0800 Message-ID: From: James M Snell To: Julian Reschke Content-Type: multipart/alternative; boundary=089e0139faa8bb376f04ea77eef3 Cc: Mark Nottingham , ietf-http-wg@w3.org, IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 01:18:55 -0000 --089e0139faa8bb376f04ea77eef3 Content-Type: text/plain; charset=UTF-8 It exists because (a) I couldn't come up with any viable, non theoretical use cases where other attributes would really matter and (b) the current model works in practice for everything I've done with it. On Nov 5, 2013 5:13 PM, "Julian Reschke" wrote: > On 2013-11-06 02:06, James M Snell wrote: > >> Give me a viable, non theoretical use case where the other target >> attributes and extension parameters would make a difference and I'll >> reconsider that constraint. >> ... >> > > I'll try, but in the meantime it would be good if you could explain why > the constraint is there in the first place :-) > > Best regards, Julian > --089e0139faa8bb376f04ea77eef3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

It exists because (a) I couldn't come up with any viable= , non theoretical use cases where other attributes would really matter and = (b) the current model works in practice for everything I've done with i= t.

On Nov 5, 2013 5:13 PM, "Julian Reschke&quo= t; <julian.reschke@gmx.de&g= t; wrote:
On 2013-11-06 02:06, James M Snell wrote:
Give me a viable, non theoretical use case where the other target
attributes and extension parameters would make a difference and I'll reconsider that constraint.
...

I'll try, but in the meantime it would be good if you could explain why= the constraint is there in the first place :-)

Best regards, Julian
--089e0139faa8bb376f04ea77eef3-- From mnot@mnot.net Tue Nov 5 17:22:40 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA5811E811A for ; Tue, 5 Nov 2013 17:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.873 X-Spam-Level: X-Spam-Status: No, score=-103.873 tagged_above=-999 required=5 tests=[AWL=-1.874, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POoZHiFmXyof for ; Tue, 5 Nov 2013 17:22:35 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4450B21F9DF6 for ; Tue, 5 Nov 2013 17:22:35 -0800 (PST) Received: from dhcp-b641.meeting.ietf.org (unknown [31.133.182.65]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5DAD722E259; Tue, 5 Nov 2013 20:22:27 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Mark Nottingham In-Reply-To: Date: Tue, 5 Nov 2013 17:22:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5279952E.5040402@gmx.de> <527997D3.4010108@gmx.de> To: James M Snell X-Mailer: Apple Mail (2.1816) Cc: "Julian F. Reschke" , HTTP Working Group , IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 01:22:40 -0000 My understanding (perhaps misplaced) was that it was there so you could = replace existing links in a deterministic way. The only other way that comes to mind is to mint a new =91id=92 (or = similar) attribute that identifies the instance of the link; e.g., Link: ; rel=3D=93bar=94; title=3D=93whatever=94; id=3Dabc Link: ; rel=3D=93bar=94; title=3D=93the other link to whatever=94; = id=3Ddef I will point out that in some use cases, it=92s not unknown to have = multiple links of the same type and same target URI in the same = document, but with different target attributes. In these cases, Julian=92s= concern is valid. Regards, On 5 Nov 2013, at 5:18 pm, James M Snell wrote: > It exists because (a) I couldn't come up with any viable, non = theoretical use cases where other attributes would really matter and (b) = the current model works in practice for everything I've done with it. >=20 > On Nov 5, 2013 5:13 PM, "Julian Reschke" = wrote: > On 2013-11-06 02:06, James M Snell wrote: > Give me a viable, non theoretical use case where the other target > attributes and extension parameters would make a difference and I'll > reconsider that constraint. > ... >=20 > I'll try, but in the meantime it would be good if you could explain = why the constraint is there in the first place :-) >=20 > Best regards, Julian -- Mark Nottingham http://www.mnot.net/ From julian.reschke@gmx.de Tue Nov 5 17:22:59 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8667921E808F for ; Tue, 5 Nov 2013 17:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.417 X-Spam-Level: X-Spam-Status: No, score=-104.417 tagged_above=-999 required=5 tests=[AWL=-1.818, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDxKTiU+owdk for ; Tue, 5 Nov 2013 17:22:53 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 706AC21F9DF6 for ; Tue, 5 Nov 2013 17:22:53 -0800 (PST) Received: from [31.133.162.78] ([31.133.162.78]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M4002-1Vvwsg0Pgo-00rawN for ; Wed, 06 Nov 2013 02:22:52 +0100 Message-ID: <527999EA.9050401@gmx.de> Date: Wed, 06 Nov 2013 02:22:50 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: James M Snell References: <5279952E.5040402@gmx.de> <527997D3.4010108@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:X37VUM4+SKP3qFfL19aPMPYt62t7zR4bi10TMf9fuaDODCP7UeA qPj6Xsdhn0v6QPsNk83QsEHTkMB62DoF+ffgcsYfsdJ9aGQnnamE4tZsBg6sZ5X9vC8f4uv Uphfr7nhkG6sYdWXiov+vCfxbyqyaRRMztkL3Qkh7uIU101rCAO1pvNd/Bt1jX4OuSQqTRm 0wUAEEaVqwyf/XrzfRp1A== Cc: Mark Nottingham , ietf-http-wg@w3.org, IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 01:22:59 -0000 On 2013-11-06 02:18, James M Snell wrote: > It exists because (a) I couldn't come up with any viable, non > theoretical use cases where other attributes would really matter and (b) > the current model works in practice for everything I've done with it. James, that's an explanation why you think it's ok to add that constraint, but it doesn't explain why it's *needed*. If you took it out, would that cause any problems somewhere else? Best regards, Julian From julian.reschke@gmx.de Tue Nov 5 17:33:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639B721E817B for ; Tue, 5 Nov 2013 17:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.145 X-Spam-Level: X-Spam-Status: No, score=-104.145 tagged_above=-999 required=5 tests=[AWL=-2.146, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIUu8dBqN2Lb for ; Tue, 5 Nov 2013 17:32:58 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id DF57521E80C9 for ; Tue, 5 Nov 2013 17:32:57 -0800 (PST) Received: from [31.133.162.78] ([31.133.162.78]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M9s2y-1VStdn2EjQ-00B0CR for ; Wed, 06 Nov 2013 02:32:56 +0100 Message-ID: <52799C46.8070902@gmx.de> Date: Wed, 06 Nov 2013 02:32:54 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Mark Nottingham , James M Snell References: <5279952E.5040402@gmx.de> <527997D3.4010108@gmx.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:Sbb9zPalhraRSzNM3T0pMT+SAAi6joGMQo0lEVTsFXhJmgb9b1m Jwh5Fzl8XpMtycDOYs23xty9kVlm1ifJeOi1augQgyySdyRwLLQXvKe0J9yMAIl86xsocU5 a2hVxhLeSdX09nwioFJlfCkUg8idbeAUHDPJPq9AETwopeuF57mN7vaJf2FjBG3Au1HiQqh 9M/TQb9JdbTmBJ6/F0W8g== Cc: HTTP Working Group , IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 01:33:04 -0000 On 2013-11-06 02:22, Mark Nottingham wrote: > My understanding (perhaps misplaced) was that it was there so you could replace existing links in a deterministic way. You can only replace a link by UNLINKing it first, right? > The only other way that comes to mind is to mint a new ‘id’ (or similar) attribute that identifies the instance of the link; e.g., > > Link: ; rel=“bar”; title=“whatever”; id=abc > Link: ; rel=“bar”; title=“the other link to whatever”; id=def Or by giving it its own URI... :-) > ... Best regards, Julian From nordmark@acm.org Tue Nov 5 17:55:07 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6987B21F9D9C for ; Tue, 5 Nov 2013 17:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHgg9DaKI1hL for ; Tue, 5 Nov 2013 17:54:57 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 14E3F21E80A3 for ; Tue, 5 Nov 2013 17:54:56 -0800 (PST) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id rA61srCH020668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Nov 2013 17:54:53 -0800 Received: from [31.133.180.117] (dhcp-b475.meeting.ietf.org [31.133.180.117]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id rA61srXO023428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Nov 2013 17:54:53 -0800 Message-ID: <5279A16D.6040706@acm.org> Date: Tue, 05 Nov 2013 17:54:53 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Scott Brim References: <002101ceda82$f49bd4e0$ddd37ea0$@rozanak.com> <5279A0BC.6030506@sonic.net> In-Reply-To: <5279A0BC.6030506@sonic.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;oD8jboZG4xGWiD29zN2kxQ== M;hOcoboZG4xGWiD29zN2kxQ== Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] privacy in applications - anybody working in this area or interested? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 01:55:07 -0000 On 11/5/13 5:03 PM, Scott Brim wrote: > You've opened up a multi-layer issue here. If each application gets a > separate IID, that could make privacy more difficult, in that it could > be easier to track and correlate the behavior of applications even with > low layer encryption. Your proposal could be okay if each application > (or session, actually) could request a new IID at an arbitrary time, and > if there were a general way for sessions to let each other know this was > happening, like multihomed transport. Fun yet? Scott, I'm not sure I understand. An example of what Hosnieh and I have been talking about is an application (like a web browser) having some privacy-enhancing feature (such as incognito browsing sessions/tabs). In such a case it would seem to make sure to pick a different IPv6 IID for traffic originated due to the separate session. But the user presumably would want to make it hard to link that traffic with other traffic from the box, hence a multihomed transport (which links multiple sessions together) would seem to be the opposite of what they'd expect. Regards, Erik From jasnell@gmail.com Tue Nov 5 18:53:25 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E8B11E81D6 for ; Tue, 5 Nov 2013 18:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_63=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRfGMrFDaWis for ; Tue, 5 Nov 2013 18:53:24 -0800 (PST) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4600511E81E0 for ; Tue, 5 Nov 2013 18:53:20 -0800 (PST) Received: by mail-ob0-f175.google.com with SMTP id va2so1672233obc.6 for ; Tue, 05 Nov 2013 18:53:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=OvTVuAKchfZq6J6FHOGBeXrYCqsqUnbZlf3A0hOuMqo=; b=gAGd/RmfiYZ9wERFMkRQLuEhZ/IdJL/S78Qoq7nnmBEidn9grWSRFCgHgwU7zFZ1Pv WvyTP7myGxGAD6RHo7sVPrIvvIv6A65zvgGCqyAovSwp0sJTC1t/4GiY9c4wVyqtPFj6 LmeHaky/dIWWBa5LusSBaEnkldteoyBWdqxLQx5oyE9WBJpYiZg+gshhHR+vXElh9wPx EHp6ojVvodmH2M5gJiWO4AgqtGec1T9npbNK+7D+/ICVpksALc1qo9RSlwXJ6P3SfPMs nNUmNgDaMwyLLvFNskiLsZXB3DCLskdwB3RU7zC+geS4jIVY22PzHWM/HPJkoXKu+ezH v2rQ== X-Received: by 10.182.213.97 with SMTP id nr1mr721347obc.48.1383706399869; Tue, 05 Nov 2013 18:53:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.124.137 with HTTP; Tue, 5 Nov 2013 18:52:59 -0800 (PST) In-Reply-To: <527999EA.9050401@gmx.de> References: <5279952E.5040402@gmx.de> <527997D3.4010108@gmx.de> <527999EA.9050401@gmx.de> From: James M Snell Date: Tue, 5 Nov 2013 18:52:59 -0800 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Cc: Mark Nottingham , "ietf-http-wg@w3.org" , IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 02:53:25 -0000 Sorry, my answer was a bit abbreviated as I was heading out to help coach the kids soccer practice... Mark's answer touched on the more complete answer. The way this is defined, LINK (and UNLINK) are idempotent requests. If I send the following request twice, the link (/my/resource,"foo",/other/resource) still only exists once. LINK /my/resource HTTP/1.1 Host: example.org Link: ; rel="foo" I could send a separate LINK request connecting the same two resources using a different link relation.. creating a separate link... LINK /my/resource HTTP/1.1 Host: example.org Link: ; rel="bar" No matter how many times I send that request, there is only one link established. Whether or not additional target attributes and extension parameters are considered is entirely up to how the server chooses to utilize the link relationship. If, after I send the second request above, I send another: LINK /my/resource HTTP/1.1 Host: example.org Link: ; rel="bar"; title="this is the bar link" I would expect that -- if the server treats the target attributes as something worth paying attention to -- the existing bar link (if one exists) would be modified using the new attributes. Per your specific question, yes, we could take all of the target attributes and extension parameters into consideration when determining uniqueness of the link, but doing so would introduce significantly more complexity, especially when one comes back later and attempts to do an UNLINK -- the client would be required to duplicate *all* of the target attributes/extension parameters used to establish the original link. For instance, suppose I did: LINK /my/resource HTTP/1.1 Host: example.org Link: ; rel="foo"; hreflang="en"; ext=foo Link: ; rel="foo"; hreflang="fr"; ext=bar And suppose that later on I want to UNLINK the second of the two, I would have to send: UNLINK /my/resource HTTP/1.1 Host: example.org Link: ; rel="foo"; hreflang="fr"; ext=bar Which implies that my UNLINK'ing client has full knowledge of the complete set of attributes used to establish the link in the first place ... which it may not (remember, we currently have no standardized way of enumerating all of the links that have been established). So, by defining the uniqueness constraint as (context,link rel,target), we greatly simplify the model... and yes, that simplification comes at the cost of some functionality -- but given that I have not yet seen a viable, non-theoretical use case, I view that loss as acceptable. I'm definitely open to be convinced otherwise (for instance, I could quite easily be convinced that the hreflang and type attributes ought to be considered part of the uniqueness constraint) Is that a better answer? - James On Tue, Nov 5, 2013 at 5:22 PM, Julian Reschke wrote: > On 2013-11-06 02:18, James M Snell wrote: >> >> It exists because (a) I couldn't come up with any viable, non >> theoretical use cases where other attributes would really matter and (b) >> the current model works in practice for everything I've done with it. > > > James, that's an explanation why you think it's ok to add that constraint, > but it doesn't explain why it's *needed*. > > If you took it out, would that cause any problems somewhere else? > > Best regards, Julian > From jasnell@gmail.com Tue Nov 5 19:03:39 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059BC11E81E1 for ; Tue, 5 Nov 2013 19:03:39 -0800 (PST) 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.075, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cK0IGQ1w3NNZ for ; Tue, 5 Nov 2013 19:03:38 -0800 (PST) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6172711E81D6 for ; Tue, 5 Nov 2013 19:03:38 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id gq1so9566913obb.31 for ; Tue, 05 Nov 2013 19:03:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LvMEMfuCgaJFjcTWRv3FADtREROXpMc44Ilz7mQwycY=; b=nYlnF/TDV0dK6pdm5RWuAwhbvNaMsNK2B4x/xB7Cohxy4RlL6xJMUYs0yf8Ge97uD3 t2k94IySdc8BM0apn9nNHs3VTLaHIM82NeyfwdQ6VSrtbNvjwKT1tiMC1B6U3UvSRGJO woe3j5kagvKKMKXbGmIrHuvImrOVf8sRRfyYX+tjLJ/fhQhWR/kCu1EWnZcAejnmnMi5 gq/1x4z2lCZqjHJXY2dPKuYDPPkStH+POntTSEW1fqhEQpHbMpK4YUwLHciyN932HIxh yY5wPmx4wrkJVWRcpUNlsUiO/mvfdC/dI+mS1+m1SWAKbVQKLfk/VLCFsVnCDjGh9Tos kIWw== X-Received: by 10.60.62.136 with SMTP id y8mr780963oer.20.1383707017935; Tue, 05 Nov 2013 19:03:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.124.137 with HTTP; Tue, 5 Nov 2013 19:03:17 -0800 (PST) In-Reply-To: <527996B8.50802@gmx.de> References: <527996B8.50802@gmx.de> From: James M Snell Date: Tue, 5 Nov 2013 19:03:17 -0800 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Cc: "ietf-http-wg@w3.org" , IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 03:03:39 -0000 Some specific answers, On Tue, Nov 5, 2013 at 5:09 PM, Julian Reschke wrote: [snip] > some feedback: > > - you may want to talk about what kind of processing of the link target > happens, such as: is the server allowed or even required to check the > target's existence (thus can LINK create "dangling" links?) If it does, an > example would help (status code etc) > No specific processing steps are required by the server. It MAY check to see if the target exists but is not required to do so (and, in some cases, such checks could be impractical or impossible). > - clarify whether an anchor parameter should either be ignored or be an > error > You mean fragment identifier, correct? If so, the answer is: No, fragment identifiers MUST NOT be ignored. The target URL ought to be considered exactly as given (with proper consideration given to relative URL's, of course). For instance, the following would create two separate links: LINK /my/resource HTTP/1.1 Host: example.org Link: ; rel="baz" Link: ; rel="baz" > - you and I know that success could be 200 or 204, but if you don't have it > at least in the examples, at least some people will be confused (and argue > whether it should be 201 :-) > 201 implies that a resource is being created... which might not actually be the case. I could take some time to draw that out in the draft, if necessary. > - is it an error to try to remove a link that doesn't exist? What if I try > to UNLINK one existing and one non-existing one? > Nope, it's not. The UNLINK request is idempotent and always has the same result... If I send an UNLINK that identifies one existing link and one non-existing link, the result in the end is the same... neither link between the two resources will exist (which is the exact intent of the request). The server would simply ignore the request to unlink the non-existent link. And no, there is no need to UNLINK before replacing/updating an existing LINK. - James > Best regards, Julian > From sm@resistor.net Tue Nov 5 21:26:40 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7583721E80A8 for ; Tue, 5 Nov 2013 21:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.282 X-Spam-Level: X-Spam-Status: No, score=-102.282 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFbor8xbIh73 for ; Tue, 5 Nov 2013 21:26:38 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD80121E80AE for ; Tue, 5 Nov 2013 21:26:38 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rA65QXkh015806; Tue, 5 Nov 2013 21:26:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1383715598; bh=bCRPHSykISmZtEHVfdaziojjgV+84yrVuWnbIVLIl2E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=fHMGi5KX6feSQfT0TbuiTZfvCBS1cZPxKyyO612E9LCJSXE6Gwq3P5P3lQKXQMAHZ +DFBNOFlGoUaz+ZR0juhrVpO6aWBn7eewyM2b68ZnXOYkZvH66QAvc78Saq9HVFA1B /EOTphQP5u4YHhz1PtxzeZjIyKmaf571HIekPywg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1383715598; i=@resistor.net; bh=bCRPHSykISmZtEHVfdaziojjgV+84yrVuWnbIVLIl2E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Qn8sT3LQYCe3fmK8md8ZQdGte8xTu78YJp2Wlgm9JsC7rAm2LbP9Xy76cBJHxlsZd HZUFcFpmHG5qBdTT5XnyNTr5i0hgUWJK8Q4sWBhUSw0/HM6BzeVYa8WnBLNS6CcAhA VyqxiBqNmMmWH/0/gDCW6Wgf5fBrDGsd9sLc+258= Message-Id: <6.2.5.6.2.20131105210233.0d495e28@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 05 Nov 2013 21:20:12 -0800 To: Hosnieh Rafiee From: SM In-Reply-To: <002101ceda82$f49bd4e0$ddd37ea0$@rozanak.com> References: <002101ceda82$f49bd4e0$ddd37ea0$@rozanak.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Erik Nordmark , apps-discuss@ietf.org Subject: Re: [apps-discuss] privacy in applications - anybody working in this area or interested? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 05:26:40 -0000 Hi Hosnieh, At 15:58 05-11-2013, Hosnieh Rafiee wrote: >We're looking for enhancing applications with privacy features by assigning >different Interface ID (IID) to them. We're looking for people who work on >privacy in applications. We have a presentation in v6ops tomorrow and we ask >the people who works in this area to contact us and if possible for them to >attend to our presentation "iid-lifetime". >https://tools.ietf.org/html/draft-rafiee-v6ops-iid-lifetime If I understood correctly the problem is: "This is also gives this ability to attackers to obtain user's information by using simple approaches such as creating a fake website and use it as trap to find the user's IP addresses." The proposed solution in the draft is to use a temporary Interface ID. It mentions having a lifetime per application. If I understood correctly the proposal introduces an application identifier. How does the application identify itself to the lower layer when it needs to use an IPv6 address? Regards, -sm From ht@inf.ed.ac.uk Wed Nov 6 03:07:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957CD21F9B9F for ; Wed, 6 Nov 2013 03:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.175 X-Spam-Level: X-Spam-Status: No, score=-7.175 tagged_above=-999 required=5 tests=[AWL=-0.576, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JV7dxlAxWmnH for ; Wed, 6 Nov 2013 03:07:14 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id CCACA21F9D39 for ; Wed, 6 Nov 2013 03:07:02 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rA6B6ieB018485; Wed, 6 Nov 2013 11:06:44 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rA6B6iF1012543; Wed, 6 Nov 2013 11:06:44 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rA6B6ill006165; Wed, 6 Nov 2013 11:06:44 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rA6B6iHs006161; Wed, 6 Nov 2013 11:06:44 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Mark Nottingham References: <527825DB.6010105@gmx.de> <93E08AC0-9D97-4296-B139-DE439D3DE8B2@mnot.net> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Wed, 06 Nov 2013 11:06:43 +0000 In-Reply-To: <93E08AC0-9D97-4296-B139-DE439D3DE8B2@mnot.net> (Mark Nottingham's message of "Tue\, 5 Nov 2013 15\:45\:08 -0800") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Cc: "Julian F. Reschke" , "apps-discuss@ietf.org Discuss" , "www-tag@w3.org WG" Subject: Re: [apps-discuss] Request that the WG reconsider section 3.4: Content Negotiation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 11:07:18 -0000 Mark Nottingham writes: > On 5 Nov 2013, at 4:18 am, Henry S. Thompson wrote: > >>> Reactive conneg isn't just about 300s and 406s. Another example would >>> be a representation returned with a 200 response that contains links >>> to alternate versions of the content. That's what the >>=20 >> How is this in scope for discussion _in the HTTP spec._? People (not >> user agents, note) use 200 responses for a huge range of interesting, >> powerful, innovative things. We don't look in the HTTP spec. to find >> a discussion of them. > > You seem to be thinking of HTTP as a separate layer from the > application; as section 3.4 of p2 says, it=A2s defining a pattern of > use, and that is certainly in scope for this specification, given > that it was also in scope for RF2616. I guess it's statements such as "HTTP provides mechanisms for content negotiation" (1st para of 3.4) and "patterns . . . visible within the protocol" (2nd para) which suggest that we're talking about the HTTP layer, not a more general functionality. > We talked about this issue at the WG meeting yesterday. Based upon > that discussion, we decided to close this issue. Looking at > , > I can=A2t see any immediate clarifications that would help; if you can > suggest some, please do bring them to our attention. Thanks for your time. Here's a quick redraft of 3.4 (the first para is nearly unchanged) -- this is the direction I think would be a helpful change. -------- 3.4 MSc Content Negotiation When responses convey payload information, whether indicating a success or an error, the origin server often has different ways of representing that information; for example, in different formats, languages, or encodings. Likewise, different users or user agents might have differing capabilities, characteristics, or preferences that could influence which representation, among those available, would be best to deliver. For this reason, HTTP provides mechanisms supporting content negotiation, that is, means for clients and servers to select, or involve users and user agents in selecting, among alternative representations. Note that, in all cases, HTTP is not aware of resource semantics. The consistency with which an origin server responds to requests, over time and over the varying dimensions of content negotiation, and thus the "sameness" of a resource's observed representations over time, is determined entirely by whatever entity or algorithm selects or generates those responses. HTTP pays no attention to the man behind the curtain. In particular, this specification defines headers and response codes for use in exchanges where multiple representations are, or may be, involved. Accept headers in requests (Section 5.3) allow clients to signal preferred alternatives. Such explicit preferences may derive from user agent capabilities (for example with respect to image format support), user preferences (for example with respect to natural language) or local context (for example with respect to media type). Servers may also infer implicit preferences from other properties of requests such as the network address or User-Agent header. Response codes (Sections 6.4.1 and 6.5.6) and response headers (Sections 7.1.4 and 7.1.2) allow servers (and proxies) to signal the success or failure in any attempt to satisfy client preferences (implicit or explicit) as well as the availability of alternatives. Although the most common use of these mechanisms is for clients to include Accept headers in requests, and servers (or proxies) to select among available alternatives based on those headers, a wide range of other patterns of use exist, including ones where the initiative is all on the server side, where for example a 300 response may accompany a payload offering what amounts to spelling correction, as an alternative to a 404. Many of these patterns depend on particular media types and/or user agents. ------------------ and leave it at that. Some corresponding changes to the referenced sections would likely be necessary to pick up a few of the details from the now-deleted 3.4.1 and 3.4.2. ht "Whereof one cannot speak, thereof one must be silent" --=20 Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged s= pam] From ietf@rozanak.com Wed Nov 6 03:40:13 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6B621E811E for ; Wed, 6 Nov 2013 03:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auJOJKRIQs+S for ; Wed, 6 Nov 2013 03:40:07 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 74D4721E8088 for ; Wed, 6 Nov 2013 03:40:07 -0800 (PST) Received: from kopoli (S0106d8fee37c1b5f.vc.shawcable.net [174.6.112.7]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MTAxK-1VED9W2XGI-00RhSf; Wed, 06 Nov 2013 06:39:52 -0500 From: "Hosnieh Rafiee" To: "'SM'" References: <002101ceda82$f49bd4e0$ddd37ea0$@rozanak.com> <6.2.5.6.2.20131105210233.0d495e28@resistor.net> In-Reply-To: <6.2.5.6.2.20131105210233.0d495e28@resistor.net> Date: Wed, 6 Nov 2013 12:39:45 +0100 Message-ID: <003701cedae4$e7494360$b5dbca20$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKkV7ZzhCzbQYGFezj5ycrrtI8nuQIR459XmFyKC9A= Content-Language: en-us X-Provags-ID: V02:K0:gilFYw+EaGv/OoGZQCJ6e+SoZnb3g7lAapc/7Hp5+Gf 4RnIxZiHSQa3bRbdposzkj9Djl1US710nBXG8VTR+GShxs+r65 i87R6v724i+13z3iXXVGnRKeRxt3CbNFfGIUrn0JuAxNT4RAib sf8HxlxHMLIHEt0I6PDX32pKBW98A63aNC47y0kTWrk7oqdrVY 1WQvCz8wYYEgm8iIdHmmLC2V3+aSMNd92tf0j2QaIM1CHa5aNm qUQ1mVCDQJMiUk0hy6KkXdZ8v8JV2TAq+lWmG34nUq0989lT/H XaqwCcS9sKi/2wpO0VKPB+28SHD+v75ntZM2nnOgk0jkqNKGpf 3E24CkyoKuwklmLwO3Fc= Cc: 'Erik Nordmark' , apps-discuss@ietf.org Subject: Re: [apps-discuss] privacy in applications - anybody working in this area or interested? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 11:40:13 -0000 Hi, > If I understood correctly the problem is: > > "This is also gives this ability to attackers to obtain user's > information by using simple approaches such as creating a fake > website and use it as trap to find the user's IP addresses." > > The proposed solution in the draft is to use a temporary Interface ID. It > mentions having a lifetime per application. If I understood correctly the > proposal introduces an application identifier. How does the application > identify itself to the lower layer when it needs to use an IPv6 address? This is like an intermediate framework between network layer and application layer. There is two possibilities. Firstly, the framework checks the current available processes in the list of tasks and if any processes wants to use internet it assigns a IID. Secondly, the application can trigger a function to ask for an IID and it is transparent for it how this happen. But this is actually implementation issue. I implemented the first option for Windows to check the performance. The second option is easier since the application calls the function and this application layer lifetime does not need to care about the processes in the node. Does it answer your concern? Thanks, -----------smile---------- Hosnieh . success is a journey, not a destination.. You cannot change your destination overnight, but you can change your direction ... Focus on the journey From mark@coactus.com Wed Nov 6 06:21:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB07521E8114 for ; Wed, 6 Nov 2013 06:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.477 X-Spam-Level: X-Spam-Status: No, score=-4.477 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qx0HirwmsVOZ for ; Wed, 6 Nov 2013 06:20:59 -0800 (PST) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF3321E80E8 for ; Wed, 6 Nov 2013 06:20:59 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id kp14so10572810pab.4 for ; Wed, 06 Nov 2013 06:20:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rXawdPQQnxEyST1HFpGaKfXJ/Eq9o5azQLIK3sOZ8Ms=; b=XiL4H/UKEwuCRAdpPTDWRKN6LOMS3n0WSZIJ0a0cy5pC+5Oz8DehkM5/8H8asJQFNK PWdXGFnWtrrXXrxbvJWMBUBbgGhhCmXklLcCGP+QpExZkrZOavgE8kPeyq8SFwHTvt0S 9f6oQMyH24P3R4/5zf8eSeqI97rBc0vGSrgEkU+BdFPFLt+I8hwZG1cqYfQq0Z4jonU/ UveMjMpWF/oMPWJrUPQxm0qWuSgyRFebp51AJTjw7WWAmHburc99d/jzgjrZVGXCIkHx OABaaex7d9Wyn4H5q2UGP9F2Cc/AD4oXaAL/moVSLqVKmaUCJehyqzZ97Zfz9Xdwe6ST FvYw== X-Gm-Message-State: ALoCoQmMKYypjrZMf2CkXntS4UnKjw/ATn3x6yLajU0SLiSc+C4MqL8sQOxSxjRqxizlNO9sovcm MIME-Version: 1.0 X-Received: by 10.68.254.105 with SMTP id ah9mr3468186pbd.87.1383747658847; Wed, 06 Nov 2013 06:20:58 -0800 (PST) Sender: mark@coactus.com Received: by 10.70.25.67 with HTTP; Wed, 6 Nov 2013 06:20:58 -0800 (PST) X-Originating-IP: [192.0.216.13] In-Reply-To: <52793A16.8060301@berkeley.edu> References: <5276878A.6000802@berkeley.edu> <5278AF21.90605@it.aoyama.ac.jp> <52793A16.8060301@berkeley.edu> Date: Wed, 6 Nov 2013 09:20:58 -0500 X-Google-Sender-Auth: aUyfSNkUEA80y840xKXFHDSo7eg Message-ID: From: Mark Baker To: Erik Wilde Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] proposal: adding profile support to JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 14:21:04 -0000 Hi Erik, On Tue, Nov 5, 2013 at 1:33 PM, Erik Wilde wrote: > hello mark. > > > On 2013-11-05, 08:59 , Mark Baker wrote: >> >> On Tue, Nov 5, 2013 at 10:57 AM, Tim Bray wrote: >>> >>> Well, for example, http://www.tbray.org/tmp/draft-bray-i-json-01.html >> >> I'm with Martin. What that spec is trying to do with profiles is to >> supplant the typical role of a media type. If it's representative of >> what Erik has in mind for the use of a profile parameter with Atom (or >> anywhere), then I think that needs to be reconsidered too. > > > i understand your concerns, but profiles do not attempt to "replace media > types", even though they could be (mis-)used to try to do just that. [1] > tries to explain the goal: they are for specializing and/or constraining > existing media types; representing both the nature of the underlying type > ("this is an atom feed and can be processed as a generic feed") as well as > the specialized/constrained profile ("this feed carries podcast data, and > can be processed as a podcast feed"). I've read your RFC, and both referenced blog posts, but still find myself asking the same question; what problem does it solve? Yes, media types have their issues, but in my many years in Web development and standardization, I've yet to encounter a problem that didn't have a workable solution through the correct use of link relations and media types. This includes my time advising on the development of a compound document editor at Justsystem, and representing them on the W3C Compound Document Formats WG. We agree that a document containing some OPDS extensions is still an Atom document that can be delivered as application/atom+xml, I believe. You appear to suggest that there's value in exposing the existence of those OPDS extensions using an additional external metadata protocol element. I believe that this is at best an optimization, since the consumer can easily detect the existence of the extension by inspecting the content (and understanding the extensibility model of the host format). But at worst, it's a recipe for interop problems; does the meaning of the document change if the profile is declared vs not? What if the v2 profile URI is declared and the document contains a v1 extension? etc.. This really smells to me like a solution in search of a problem. > james snell blogged about the bigger problem [2] that media types as they > are today are not a terribly well-designed concept. I strongly disagree with that post (blog commenting seems broken, but I won't respond in detail here except to say "rel=icon" :). I believe media types are far better designed than is commonly appreciated; a single label for a compatible evolution of a document format is a simple yet extremely powerful protocol that promotes compatibility in extensions and penalizes incompatible deviations... but still permits them when required. And FWIW, this is coming from the guy who, AFAIK, started the whole profile parameter ball rolling in RFC 3236. That went in there only as a compromise with the WAPforum, but was never/rarely used in practice. From julian.reschke@gmx.de Wed Nov 6 07:11:46 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1622A21F9E39 for ; Wed, 6 Nov 2013 07:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.826 X-Spam-Level: X-Spam-Status: No, score=-103.826 tagged_above=-999 required=5 tests=[AWL=-2.427, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_63=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfxK9N+7kmHf for ; Wed, 6 Nov 2013 07:11:40 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD5021E8121 for ; Wed, 6 Nov 2013 07:11:33 -0800 (PST) Received: from [31.133.151.131] ([31.133.151.131]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LnPSg-1W7Kmb0BEE-00hhDL for ; Wed, 06 Nov 2013 16:11:32 +0100 Message-ID: <527A5C23.8050201@gmx.de> Date: Wed, 06 Nov 2013 16:11:31 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: James M Snell References: <5279952E.5040402@gmx.de> <527997D3.4010108@gmx.de> <527999EA.9050401@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:BAMU6pJOz/dlbI63yT8W3LqZDXoi8nHavKsdIZbkGDqpblFKYEO OIlW5c1k/N2ND1VreOZ0xg3qwzfdcRoPiIZegTdar6/MGGAKlD2Hr6uKoNKNdurcYtcu+dG yXONTpCUfXCu0P8LREnuu5H1Z3pHLV3NT1y6kJ9PEtZclYA9+3LdggX6FagvZfuEXmMW8pm iyV//dqC+tuDmiKhKYuXQ== Cc: Mark Nottingham , "ietf-http-wg@w3.org" , IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 15:11:46 -0000 On 2013-11-06 03:52, James M Snell wrote: > Sorry, my answer was a bit abbreviated as I was heading out to help > coach the kids soccer practice... Mark's answer touched on the more > complete answer. > > The way this is defined, LINK (and UNLINK) are idempotent requests. If > I send the following request twice, the link > (/my/resource,"foo",/other/resource) still only exists once. > > LINK /my/resource HTTP/1.1 > Host: example.org > Link: ; rel="foo" Yes. > I could send a separate LINK request connecting the same two resources > using a different link relation.. creating a separate link... > > LINK /my/resource HTTP/1.1 > Host: example.org > Link: ; rel="bar" > > No matter how many times I send that request, there is only one link > established. Yes. > Whether or not additional target attributes and extension parameters > are considered is entirely up to how the server chooses to utilize the > link relationship. If, after I send the second request above, I send > another: > > LINK /my/resource HTTP/1.1 > Host: example.org > Link: ; rel="bar"; title="this is the bar link" > > I would expect that -- if the server treats the target attributes as > something worth paying attention to -- the existing bar link (if one > exists) would be modified using the new attributes. I agree that this makes sense for "title", but I'm not convinced that the same is true for every possible parameter. > Per your specific question, yes, we could take all of the target > attributes and extension parameters into consideration when > determining uniqueness of the link, but doing so would introduce > significantly more complexity, especially when one comes back later > and attempts to do an UNLINK -- the client would be required to > duplicate *all* of the target attributes/extension parameters used to > establish the original link. For instance, suppose I did: > > LINK /my/resource HTTP/1.1 > Host: example.org > Link: ; rel="foo"; hreflang="en"; ext=foo > Link: ; rel="foo"; hreflang="fr"; ext=bar > > And suppose that later on I want to UNLINK the second of the two, I > would have to send: > > UNLINK /my/resource HTTP/1.1 > Host: example.org > Link: ; rel="foo"; hreflang="fr"; ext=bar Yes. It would need to match all parameters. Why is matching all parameters more complex than matching one? > Which implies that my UNLINK'ing client has full knowledge of the > complete set of attributes used to establish the link in the first > place ... which it may not (remember, we currently have no > standardized way of enumerating all of the links that have been > established). Wait. What's the point in LINK if the link that you create does not show up in a GET response? Maybe we need to clarify *that* first. > So, by defining the uniqueness constraint as (context,link > rel,target), we greatly simplify the model... and yes, that > simplification comes at the cost of some functionality -- but given > that I have not yet seen a viable, non-theoretical use case, I view > that loss as acceptable. I'm definitely open to be convinced otherwise > (for instance, I could quite easily be convinced that the hreflang and > type attributes ought to be considered part of the uniqueness > constraint) What's the material difference from matching all parameters then? > Is that a better answer? Yes. Best regards, Julian From jasnell@gmail.com Wed Nov 6 07:27:44 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2371A21E8107 for ; Wed, 6 Nov 2013 07:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_63=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7NlxYYgNY6h for ; Wed, 6 Nov 2013 07:27:43 -0800 (PST) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C279B11E810F for ; Wed, 6 Nov 2013 07:27:35 -0800 (PST) Received: by mail-oa0-f45.google.com with SMTP id i4so10414438oah.18 for ; Wed, 06 Nov 2013 07:27:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3qEA9hBrRTihXP1SYSj7ncTAeg6jEqetf3jTNFUdOQw=; b=CM/1myB669G0UIx95ZHMCIvF4a7qhXEy0KfAuQCZTP3mFRZUWzlmj37B3WJwK9hVrJ /q6iVhE68qRzfiN8HXcDGJUNcQjDcKu8WXxVJ6wgW6EoNttsNASWpmOnYnAHtiEv0F+1 tBKrpR/Ke7T6FyBUY/64x2yDO5mlTJceC5/LCdndAbcrhpfebs8FwDQUie54N0+sLVWp y4BISb8QnOtLr3/2+2KnMnGKMxtzYTC9BgGYkO0QMaog1gc968AZab7+rop43JaEW6Zt X4J4QU8cRQ1lHkjZVuIg0jT0gXqIjY8e6k5adnnFL/p/g/zgHSNay0on+D+HOop7ZSlA Suxw== MIME-Version: 1.0 X-Received: by 10.182.142.229 with SMTP id rz5mr3119886obb.12.1383751655086; Wed, 06 Nov 2013 07:27:35 -0800 (PST) Received: by 10.60.124.137 with HTTP; Wed, 6 Nov 2013 07:27:35 -0800 (PST) Received: by 10.60.124.137 with HTTP; Wed, 6 Nov 2013 07:27:35 -0800 (PST) In-Reply-To: <527A5C23.8050201@gmx.de> References: <5279952E.5040402@gmx.de> <527997D3.4010108@gmx.de> <527999EA.9050401@gmx.de> <527A5C23.8050201@gmx.de> Date: Wed, 6 Nov 2013 07:27:35 -0800 Message-ID: From: James M Snell To: Julian Reschke Content-Type: multipart/alternative; boundary=001a11c362e6dbe44b04ea83c9bc Cc: Mark Nottingham , "ietf-http-wg@w3.org" , IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 15:27:44 -0000 --001a11c362e6dbe44b04ea83c9bc Content-Type: text/plain; charset=UTF-8 Whether and how a server surfaces links is undefined by this spec. There are cases where exposing the link would be wholly unnecessary. There are also cases where the server could significantly alter or augment the established link with additional detail. My goal with this spec is only to define the method characteristics. Regarding the main question about whether or not to include target attributes in the uniqueness constraint, the question becomes: which target attributes should be considered? On Nov 6, 2013 7:11 AM, "Julian Reschke" wrote: > On 2013-11-06 03:52, James M Snell wrote: > >> Sorry, my answer was a bit abbreviated as I was heading out to help >> coach the kids soccer practice... Mark's answer touched on the more >> complete answer. >> >> The way this is defined, LINK (and UNLINK) are idempotent requests. If >> I send the following request twice, the link >> (/my/resource,"foo",/other/resource) still only exists once. >> >> LINK /my/resource HTTP/1.1 >> Host: example.org >> Link: ; rel="foo" >> > > Yes. > > I could send a separate LINK request connecting the same two resources >> using a different link relation.. creating a separate link... >> >> LINK /my/resource HTTP/1.1 >> Host: example.org >> Link: ; rel="bar" >> >> No matter how many times I send that request, there is only one link >> established. >> > > Yes. > > Whether or not additional target attributes and extension parameters >> are considered is entirely up to how the server chooses to utilize the >> link relationship. If, after I send the second request above, I send >> another: >> >> LINK /my/resource HTTP/1.1 >> Host: example.org >> Link: ; rel="bar"; title="this is the bar link" >> >> I would expect that -- if the server treats the target attributes as >> something worth paying attention to -- the existing bar link (if one >> exists) would be modified using the new attributes. >> > > I agree that this makes sense for "title", but I'm not convinced that the > same is true for every possible parameter. > > Per your specific question, yes, we could take all of the target >> attributes and extension parameters into consideration when >> determining uniqueness of the link, but doing so would introduce >> significantly more complexity, especially when one comes back later >> and attempts to do an UNLINK -- the client would be required to >> duplicate *all* of the target attributes/extension parameters used to >> establish the original link. For instance, suppose I did: >> >> LINK /my/resource HTTP/1.1 >> Host: example.org >> Link: ; rel="foo"; hreflang="en"; ext=foo >> Link: ; rel="foo"; hreflang="fr"; ext=bar >> >> And suppose that later on I want to UNLINK the second of the two, I >> would have to send: >> >> UNLINK /my/resource HTTP/1.1 >> Host: example.org >> Link: ; rel="foo"; hreflang="fr"; ext=bar >> > > Yes. It would need to match all parameters. Why is matching all parameters > more complex than matching one? > > Which implies that my UNLINK'ing client has full knowledge of the >> complete set of attributes used to establish the link in the first >> place ... which it may not (remember, we currently have no >> standardized way of enumerating all of the links that have been >> established). >> > > Wait. What's the point in LINK if the link that you create does not show > up in a GET response? Maybe we need to clarify *that* first. > > So, by defining the uniqueness constraint as (context,link >> rel,target), we greatly simplify the model... and yes, that >> simplification comes at the cost of some functionality -- but given >> that I have not yet seen a viable, non-theoretical use case, I view >> that loss as acceptable. I'm definitely open to be convinced otherwise >> (for instance, I could quite easily be convinced that the hreflang and >> type attributes ought to be considered part of the uniqueness >> constraint) >> > > What's the material difference from matching all parameters then? > > Is that a better answer? >> > > Yes. > > Best regards, Julian > > --001a11c362e6dbe44b04ea83c9bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Whether and how a server surfaces links is undefined by this= spec. There are cases where exposing the link would be wholly unnecessary.= There are also cases where the server could significantly alter or augment= the established link with additional detail. My goal with this spec is onl= y to define the method characteristics.

Regarding the main question about whether or not to include = target attributes in the uniqueness constraint, the question becomes: which= target attributes should be considered?

On Nov 6, 2013 7:11 AM, "Julian Reschke&quo= t; <julian.reschke@gmx.de&g= t; wrote:
On 2013-11-06 03:52, James M Snell wrote:
Sorry, my answer was a bit abbreviated as I was heading out to help
coach the kids soccer practice... Mark's answer touched on the more
complete answer.

The way this is defined, LINK (and UNLINK) are idempotent requests. If
I send the following request twice, the link
(/my/resource,"foo",/other/resource) still only exists onc= e.

=C2=A0 =C2=A0LINK /my/resource HTTP/1.1
=C2=A0 =C2=A0Host: example= .org
=C2=A0 =C2=A0Link: </other/resource>; rel=3D"foo"

Yes.

I could send a separate LINK request connecting the same two resources
using a different link relation.. creating a separate link...

=C2=A0 =C2=A0LINK /my/resource HTTP/1.1
=C2=A0 =C2=A0Host: example= .org
=C2=A0 =C2=A0Link: </other/resource>; rel=3D"bar"

No matter how many times I send that request, there is only one link
established.

Yes.

Whether or not additional target attributes and extension parameters
are considered is entirely up to how the server chooses to utilize the
link relationship. If, after I send the second request above, I send
another:

=C2=A0 =C2=A0LINK /my/resource HTTP/1.1
=C2=A0 =C2=A0Host: example= .org
=C2=A0 =C2=A0Link: </other/resource>; rel=3D"bar"; title=3D= "this is the bar link"

I would expect that -- if the server treats the target attributes as
something worth paying attention to -- the existing bar link (if one
exists) would be modified using the new attributes.

I agree that this makes sense for "title", but I'm not convin= ced that the same is true for every possible parameter.

Per your specific question, yes, we could take all of the target
attributes and extension parameters into consideration when
determining uniqueness of the link, but doing so would introduce
significantly more complexity, especially when one comes back later
and attempts to do an UNLINK -- the client would be required to
duplicate *all* of the target attributes/extension parameters used to
establish the original link. =C2=A0For instance, suppose I did:

=C2=A0 =C2=A0LINK /my/resource HTTP/1.1
=C2=A0 =C2=A0Host: example= .org
=C2=A0 =C2=A0Link: </other/resource/1>; rel=3D"foo"; hrefla= ng=3D"en"; ext=3Dfoo
=C2=A0 =C2=A0Link: </other/resource/1>; rel=3D"foo"; hrefla= ng=3D"fr"; ext=3Dbar

And suppose that later on I want to UNLINK the second of the two, I
would have to send:

=C2=A0 =C2=A0UNLINK /my/resource HTTP/1.1
=C2=A0 =C2=A0Host: example= .org
=C2=A0 =C2=A0Link: </other/resource/1>; rel=3D"foo"; hrefla= ng=3D"fr"; ext=3Dbar

Yes. It would need to match all parameters. Why is matching all parameters = more complex than matching one?

Which implies that my UNLINK'ing client has full knowledge of the
complete set of attributes used to establish the link in the first
place ... which it may not (remember, we currently have no
standardized way of enumerating all of the links that have been
established).

Wait. What's the point in LINK if the link that you create does not sho= w up in a GET response? Maybe we need to clarify *that* first.

So, by defining the uniqueness constraint as (context,link
rel,target), we greatly simplify the model... and yes, that
simplification comes at the cost of some functionality -- but given
that I have not yet seen a viable, non-theoretical use case, I view
that loss as acceptable. I'm definitely open to be convinced otherwise<= br> (for instance, I could quite easily be convinced that the hreflang and
type attributes ought to be considered part of the uniqueness
constraint)

What's the material difference from matching all parameters then?

Is that a better answer?

Yes.

Best regards, Julian

--001a11c362e6dbe44b04ea83c9bc-- From julian.reschke@gmx.de Wed Nov 6 07:36:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8970911E81CF for ; Wed, 6 Nov 2013 07:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.375 X-Spam-Level: X-Spam-Status: No, score=-104.375 tagged_above=-999 required=5 tests=[AWL=-1.776, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9Bh1Ed0RHuz for ; Wed, 6 Nov 2013 07:36:15 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 71C8411E8150 for ; Wed, 6 Nov 2013 07:36:15 -0800 (PST) Received: from [31.133.151.131] ([31.133.151.131]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MbfnB-1VNnBc09o5-00J2Tj for ; Wed, 06 Nov 2013 16:36:10 +0100 Message-ID: <527A61E8.2050309@gmx.de> Date: Wed, 06 Nov 2013 16:36:08 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: James M Snell References: <5279952E.5040402@gmx.de> <527997D3.4010108@gmx.de> <527999EA.9050401@gmx.de> <527A5C23.8050201@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:L2rEcCF0xqQvzAjgg19pQiMw3iSBNDhOoM1ZK13BuD5zMM8of6h BXK14t979mLDghajf1pVy3y0QygqGRoXJxJkpe1VyAhfi0rOIUPf0Ug4Ykcuz03XxPMI7fA iA0rOLJtO6sutDrj6//GI1HiQ2PEzsY/TqUXJOe5hb0xWw6QNa54bjTe9tPwcEkGgmZnK9y zlc1ggQsssv06evc/oQCQ== Cc: Mark Nottingham , "ietf-http-wg@w3.org" , IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 15:36:21 -0000 On 2013-11-06 16:27, James M Snell wrote: > Whether and how a server surfaces links is undefined by this spec. There > are cases where exposing the link would be wholly unnecessary. There are > also cases where the server could significantly alter or augment the > established link with additional detail. My goal with this spec is only > to define the method characteristics. I have no problem with that, but in the end something needs to come out that is usable. I agree that the server may want to alter/augment the links. Maybe the response body then should reflect what was set? > Regarding the main question about whether or not to include target > attributes in the uniqueness constraint, the question becomes: which > target attributes should be considered? All of them? Best regards, Julian From markus.lanthaler@gmx.net Wed Nov 6 07:41:13 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC5B11E81D4 for ; Wed, 6 Nov 2013 07:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugWVDmDBBrd8 for ; Wed, 6 Nov 2013 07:41:07 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4E811E81CF for ; Wed, 6 Nov 2013 07:41:07 -0800 (PST) Received: from Vostro3500 ([178.115.129.229]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MdaiW-1VGwjl0Ijk-00PMne for ; Wed, 06 Nov 2013 16:41:06 +0100 From: "Markus Lanthaler" To: "'Mark Baker'" , "'Erik Wilde'" References: <5276878A.6000802@berkeley.edu> <5278AF21.90605@it.aoyama.ac.jp> <52793A16.8060301@berkeley.edu> In-Reply-To: Date: Wed, 6 Nov 2013 16:41:02 +0100 Message-ID: <028d01cedb06$9a063d70$ce12b850$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7a+2/woU6c0blBSeKSJnKpzRFO3QAColqQ Content-Language: de X-Provags-ID: V03:K0:+OfQNt/YH58XKACzCD8sdZYLzNL1If1bZ6Sy3GjeLAnSUeviHPC 2i3U1WemLWiacIOV26Y/dybSBVGrSRBKN+E+ZdkP2efE5u5qkqB0+inWOa0ty+4LTzmJPez 8T1oIFG226ggokdNCzyA5/W2Cy/B48cmi64zh4mHQkHGomL3vgmOcPTGbjU7YOfqIHmyFrr ZJ4pYH+v/mLP78Uc8Ftsg== Cc: apps-discuss@ietf.org, 'JSON WG' Subject: Re: [apps-discuss] proposal: adding profile support to JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 15:41:13 -0000 On Wednesday, November 06, 2013 3:21 PM, Mark Baker wrote: > We agree that a document containing some OPDS extensions is still an > Atom document that can be delivered as application/atom+xml, I > believe. You appear to suggest that there's value in exposing the > existence of those OPDS extensions using an additional external > metadata protocol element. I believe that this is at best an > optimization, since the consumer can easily detect the existence of > the extension by inspecting the content (and understanding the > extensibility model of the host format). But at worst, it's a recipe > for interop problems; does the meaning of the document change if the > profile is declared vs not? What if the v2 profile URI is declared and > the document contains a v1 extension? etc.. As you say, in XML you can leverage namespacing to create fully self-descriptive messages without requiring another media type. In this thread, however, we are talking about JSON which doesn't support namespacing. So, how would you (or any of the numerous JSON APIs out there) signal the semantics of such "extensions" in a JSON document without minting a new media type? -- Markus Lanthaler @markuslanthaler From mca@amundsen.com Wed Nov 6 08:18:34 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D7121E8145 for ; Wed, 6 Nov 2013 08:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JV+-j+2JrhwZ for ; Wed, 6 Nov 2013 08:18:30 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id 093D121E8142 for ; Wed, 6 Nov 2013 08:18:29 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id ex4so4011848wid.3 for ; Wed, 06 Nov 2013 08:18:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=OXFbxNqvuwB9l6uDdofynLj++V8cEeGWnofj7w1zoh0=; b=ACXu2GA2vwc6B4woommGS8ZoTafUnpZubxAXliSSc5ehG6IjdiojE4+FO5t1lCcU1L wlui3RYMK/cf45fFohkCGkEPuBTwDvb2q+F62eG9m5h4XrbNERxm8+OkNDVzmkICaeRe 6yiosohez1fDETdyzRu2ZJxa/uIRIvER57sXZ20FwlLaUw91HlF6Kcn5l9XvbTaWZmZY E4iriEmXmlQRkaFFyARPSV2A6r3xpmKG1eBQZIc55sfinMHIoma5AIAxEcBGlp/JcHCZ t7GoQAB1e73fpjKDfBhEfr6xwvsRd7GGPuJ8nTTO2/M3vZWuVhmBzVA6f4wL+72IQ60f 7sFw== X-Gm-Message-State: ALoCoQliXbKpk0GcmGieUBV10WZiVFgDNgosfY122nzQ4Rk+pZC6eq7gL0abV3qGhUwfgI1X7+/t X-Received: by 10.180.99.99 with SMTP id ep3mr3124175wib.11.1383754705264; Wed, 06 Nov 2013 08:18:25 -0800 (PST) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.55.195 with HTTP; Wed, 6 Nov 2013 08:18:05 -0800 (PST) In-Reply-To: References: <5276878A.6000802@berkeley.edu> <5278AF21.90605@it.aoyama.ac.jp> <52793A16.8060301@berkeley.edu> From: mike amundsen Date: Wed, 6 Nov 2013 11:18:05 -0500 X-Google-Sender-Auth: GWsvKWLbzdZC-StsQFPUCr1u_fU Message-ID: To: Mark Baker Content-Type: multipart/alternative; boundary=f46d044283c0b4af3d04ea847fb2 Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] proposal: adding profile support to JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 16:18:34 -0000 --f46d044283c0b4af3d04ea847fb2 Content-Type: text/plain; charset=ISO-8859-1 I've read your RFC, and both referenced blog posts, but still find myself asking the same question; what problem does it solve? Mark: I use profiles to _add_ domain-specific information to an existing hypermedia format (like HTML or Collection+JSON). Separation of Concerns This makes it possible to separate protocol details (HTTP) from domain details (accounting, microblogging) which make re-use of existing media types possible even when you encounter a new problem domain. Decoupling & Reuse Using profiles also creates a "closed world" model of a domain (e.g. microblogging) and that makes it possible to code a client all that recognizes that domain *independent* of the media type. This speeds/eases the effort to create an M2M domain client since you are working in "layers" you can take an existing hypermedia type (e.g. HTML) parser and _add_ the domain-specific coding. IMO, this is solving a problem that existing now and will continue to exist. It offers the ability for developers to "level-up" and stop coding protocol and focus on domain specifics *without* losing fidelity to a protocol. mamund +1.859.757.1449 skype: mca.amundsen http://amundsen.com/blog/ http://twitter.com/mamund https://github.com/mamund http://www.linkedin.com/in/mamund On Wed, Nov 6, 2013 at 9:20 AM, Mark Baker wrote: > Hi Erik, > > On Tue, Nov 5, 2013 at 1:33 PM, Erik Wilde wrote: > > hello mark. > > > > > > On 2013-11-05, 08:59 , Mark Baker wrote: > >> > >> On Tue, Nov 5, 2013 at 10:57 AM, Tim Bray wrote: > >>> > >>> Well, for example, http://www.tbray.org/tmp/draft-bray-i-json-01.html > >> > >> I'm with Martin. What that spec is trying to do with profiles is to > >> supplant the typical role of a media type. If it's representative of > >> what Erik has in mind for the use of a profile parameter with Atom (or > >> anywhere), then I think that needs to be reconsidered too. > > > > > > i understand your concerns, but profiles do not attempt to "replace media > > types", even though they could be (mis-)used to try to do just that. [1] > > tries to explain the goal: they are for specializing and/or constraining > > existing media types; representing both the nature of the underlying type > > ("this is an atom feed and can be processed as a generic feed") as well > as > > the specialized/constrained profile ("this feed carries podcast data, and > > can be processed as a podcast feed"). > > I've read your RFC, and both referenced blog posts, but still find > myself asking the same question; what problem does it solve? Yes, > media types have their issues, but in my many years in Web development > and standardization, I've yet to encounter a problem that didn't have > a workable solution through the correct use of link relations and > media types. This includes my time advising on the development of a > compound document editor at Justsystem, and representing them on the > W3C Compound Document Formats WG. > > We agree that a document containing some OPDS extensions is still an > Atom document that can be delivered as application/atom+xml, I > believe. You appear to suggest that there's value in exposing the > existence of those OPDS extensions using an additional external > metadata protocol element. I believe that this is at best an > optimization, since the consumer can easily detect the existence of > the extension by inspecting the content (and understanding the > extensibility model of the host format). But at worst, it's a recipe > for interop problems; does the meaning of the document change if the > profile is declared vs not? What if the v2 profile URI is declared and > the document contains a v1 extension? etc.. > > This really smells to me like a solution in search of a problem. > > > james snell blogged about the bigger problem [2] that media types as they > > are today are not a terribly well-designed concept. > > I strongly disagree with that post (blog commenting seems broken, but > I won't respond in detail here except to say "rel=icon" :). I believe > media types are far better designed than is commonly appreciated; a > single label for a compatible evolution of a document format is a > simple yet extremely powerful protocol that promotes compatibility in > extensions and penalizes incompatible deviations... but still permits > them when required. > > And FWIW, this is coming from the guy who, AFAIK, started the whole > profile parameter ball rolling in RFC 3236. That went in there only as > a compromise with the WAPforum, but was never/rarely used in practice. > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --f46d044283c0b4af3d04ea847fb2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
<snip>I've read your RFC, and both referenced blog posts, but s= till find
<= span style=3D"font-family:arial,sans-serif;font-size:13px">myself asking th= e same question; what problem does it solve?</snip>

Mark:
=
I use profiles to _add_ domain-specific information to an existing hyper= media format (like HTML or Collection+JSON).

Separation of Concerns
This makes it possible to = separate protocol details (HTTP) from domain details (accounting, microblog= ging) which make re-use of existing media types possible even when you enco= unter a new problem domain.

Decoupling & Reuse
Using profiles also creates a "closed world" mode= l of a domain (e.g. microblogging) and that makes it possible to code a cli= ent all that recognizes that domain *independent* of the media type. =A0Thi= s speeds/eases the effort to create an M2M domain client since you are work= ing in "layers" you can take an existing hypermedia type (e.g. HT= ML) parser and _add_ the domain-specific coding.=A0

IMO, this is solving a problem that existing now and will= continue to exist. It offers the ability for developers to "level-up&= quot; and stop coding protocol and focus on domain specifics *without* losi= ng fidelity to a protocol.

=A0

=



On Wed, Nov 6, 2013 at 9:20 AM, Mark Bak= er <distobj@acm.org> wrote:
Hi Erik,

On Tue, Nov 5, 2013 at 1:33 PM, Erik Wilde <dret@berkeley.edu> wrote:
> hello mark.
>
>
> On 2013-11-05, 08:59 , Mark Baker wrote:
>>
>> On Tue, Nov 5, 2013 at 10:57 AM, Tim Bray <tbray@textuality.com> wrote:
>>>
>>> Well, for example, http://www.tbray.org/tmp/draft-bray-i= -json-01.html
>>
>> I'm with Martin. What that spec is trying to do with profiles = is to
>> supplant the typical role of a media type. If it's representat= ive of
>> what Erik has in mind for the use of a profile parameter with Atom= (or
>> anywhere), then I think that needs to be reconsidered too.
>
>
> i understand your concerns, but profiles do not attempt to "repla= ce media
> types", even though they could be (mis-)used to try to do just th= at. [1]
> tries to explain the goal: they are for specializing and/or constraini= ng
> existing media types; representing both the nature of the underlying t= ype
> ("this is an atom feed and can be processed as a generic feed&quo= t;) as well as
> the specialized/constrained profile ("this feed carries podcast d= ata, and
> can be processed as a podcast feed").

I've read your RFC, and both referenced blog posts, but still fin= d
myself asking the same question; what problem does it solve? Yes,
media types have their issues, but in my many years in Web development
and standardization, I've yet to encounter a problem that didn't ha= ve
a workable solution through the correct use of link relations and
media types. This includes my time advising on the development of a
compound document editor at Justsystem, and representing them on the
W3C Compound Document Formats WG.

We agree that a document containing some OPDS extensions is still an
Atom document that can be delivered as application/atom+xml, I
believe. You appear to suggest that there's value in exposing the
existence of those OPDS extensions using an additional external
metadata protocol element. I believe that this is at best an
optimization, since the consumer can easily detect the existence of
the extension by inspecting the content (and understanding the
extensibility model of the host format). But at worst, it's a recipe for interop problems; does the meaning of the document change if the
profile is declared vs not? What if the v2 profile URI is declared and
the document contains a v1 extension? etc..

This really smells to me like a solution in search of a problem.

> james snell blogged about the bigger problem [2] that media types as t= hey
> are today are not a terribly well-designed concept.

I strongly disagree with that post (blog commenting seems broken, but=
I won't respond in detail here except to say "rel=3Dicon" :).= I believe
media types are far better designed than is commonly appreciated; a
single label for a compatible evolution of a document format is a
simple yet extremely powerful protocol that promotes compatibility in
extensions and penalizes incompatible deviations... but still permits
them when required.

And FWIW, this is coming from the guy who, AFAIK, started the whole
profile parameter ball rolling in RFC 3236. That went in there only as
a compromise with the WAPforum, but was never/rarely used in practice.
___________________________________= ____________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--f46d044283c0b4af3d04ea847fb2-- From jasnell@gmail.com Wed Nov 6 08:19:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0312121E8145 for ; Wed, 6 Nov 2013 08:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjGLflxbG8hu for ; Wed, 6 Nov 2013 08:19:20 -0800 (PST) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3A521E8142 for ; Wed, 6 Nov 2013 08:19:20 -0800 (PST) Received: by mail-ob0-f175.google.com with SMTP id va2so2468612obc.6 for ; Wed, 06 Nov 2013 08:19:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gJDnCU/+56FoFogsByCmuGOIWrsjn6oRe4Ty1MnZzRs=; b=0glTNLJ9mj2NjnGNuZbXB3ePxrefXwl3zaxp/CaGhsWYC/DSEPurEpzJ2ycT7pLMAN VrfmQYVb22f1LLQoYjgLkxVlhEcsbKzpZCfE/5Q6eib3basyJAX3Ac9giOKNdEJrn30P QmsGGHjj4rqglnG0zfPW49hvHCKP08v4UTRd9LcDpsKaYjTdD572zsMfqggKcWQkqzJF 9GPDGUt5kqTyzC+6xwi8ZaJzTBYTNETv7a4Q89wg8T/mEPWTO9jvG3qw4AVUTpAGuHpu JtHo0CYKvfXmYXcjO6H2oFHv/L023fUp2lWAGs13GnF2jgIMYHkf0lPNf4O3AqyR1HIs OsMw== X-Received: by 10.182.117.195 with SMTP id kg3mr3260508obb.17.1383754759832; Wed, 06 Nov 2013 08:19:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.124.137 with HTTP; Wed, 6 Nov 2013 08:18:59 -0800 (PST) In-Reply-To: <527A61E8.2050309@gmx.de> References: <5279952E.5040402@gmx.de> <527997D3.4010108@gmx.de> <527999EA.9050401@gmx.de> <527A5C23.8050201@gmx.de> <527A61E8.2050309@gmx.de> From: James M Snell Date: Wed, 6 Nov 2013 08:18:59 -0800 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Cc: Mark Nottingham , "ietf-http-wg@w3.org" , IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 16:19:21 -0000 On Wed, Nov 6, 2013 at 7:36 AM, Julian Reschke wrote: > On 2013-11-06 16:27, James M Snell wrote: >> >> Whether and how a server surfaces links is undefined by this spec. There >> are cases where exposing the link would be wholly unnecessary. There are >> also cases where the server could significantly alter or augment the >> established link with additional detail. My goal with this spec is only >> to define the method characteristics. > > > I have no problem with that, but in the end something needs to come out that > is usable. > > I agree that the server may want to alter/augment the links. Maybe the > response body then should reflect what was set? > Thus far I haven't had any practical need for this... so, again, I would go back to the question about viable, non-theoretical use cases. > >> Regarding the main question about whether or not to include target >> attributes in the uniqueness constraint, the question becomes: which >> target attributes should be considered? > > > All of them? > "All of them" becomes impractical for the reasons I've already given, particularly without clearly defined, viable, non-theoretical use cases. That said, here's a compromise: Let's expand the uniqueness constraint to include anchor, hreflang and type. Doing so ought to cover the vast overwhelming majority of the possibly viable use cases. I can also say that the server MUST consider the remaining target attributes to be significant in that, *if* the server chooses to surface those links in some representable manner, the most recently received values for those MUST be included. Is that better? (btw, getting back to your earlier question about the anchor attribute, I had honestly completely forgotten about the anchor target attribute! I've never actually seen it used in any practical sense so it had completely slipped my mind... to answer that particular question, yes, the server MUST consider the anchor attribute as being significant. I'll add a few more examples) - James > Best regards, Julian > From jasnell@gmail.com Wed Nov 6 08:29:19 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C9C21E8142 for ; Wed, 6 Nov 2013 08:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJ6PB1nOdMLa for ; Wed, 6 Nov 2013 08:29:19 -0800 (PST) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFEE21F9CAD for ; Wed, 6 Nov 2013 08:29:19 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id wn1so10386412obc.13 for ; Wed, 06 Nov 2013 08:29:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=z/rggxvSqAk0u1BLVpwupTWQSwpf49XpJl5aXjaG3dc=; b=taA6cJ60zPHd2KnWA0584rSHwTcINyFCxO+ouK/zgf6rPKyljmZO/OcybE+loYcD1/ mqzS7XLvfFBbtrpjWLsmtbO1Id8xRDHbYLIlAfa7uPsLYB/jhClL2MdhfjB9sN81dL1x ty2YX4Mj83G5/7XkUWVjYJAdXoUGDGktr7syOmMKEnHiZRVFhfkDtHfH/PkKP0FrgWiG DUAb/Hpx7mjbN4AWHG7z6/q4Yy9opPfut/FFt91eWyLflGrRchA6pX8WZiSvtHmbnlyO Hdz/sW3ISy2gU8/q6Zq3AtZXu96/W6JXhXRHQLeLHQ8yEoKnHOylnvqSeq8vQ6YsUTRL OwHg== X-Received: by 10.60.52.1 with SMTP id p1mr3273422oeo.41.1383755358658; Wed, 06 Nov 2013 08:29:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.124.137 with HTTP; Wed, 6 Nov 2013 08:28:58 -0800 (PST) In-Reply-To: References: <5276878A.6000802@berkeley.edu> <5278AF21.90605@it.aoyama.ac.jp> <52793A16.8060301@berkeley.edu> From: James M Snell Date: Wed, 6 Nov 2013 08:28:58 -0800 Message-ID: To: Mark Baker Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] proposal: adding profile support to JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 16:29:19 -0000 Please consider the examples I gave in that post to just be a strawman. The more significant point is that the media type syntax, as currently defined, does not scale very well for the types of uses developers are currently attempting to use them for, and the process around which new media types is defined and standardized leaves much to be desired. I won't go in detail here except to reference the ugly hack that is RFC 6839 ;-) - James On Wed, Nov 6, 2013 at 6:20 AM, Mark Baker wrote: [snip[ > >> james snell blogged about the bigger problem [2] that media types as they >> are today are not a terribly well-designed concept. > > I strongly disagree with that post (blog commenting seems broken, but > I won't respond in detail here except to say "rel=icon" :). I believe > media types are far better designed than is commonly appreciated; a > single label for a compatible evolution of a document format is a > simple yet extremely powerful protocol that promotes compatibility in > extensions and penalizes incompatible deviations... but still permits > them when required. >[snip] From sm@resistor.net Wed Nov 6 08:54:51 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3E621E8150 for ; Wed, 6 Nov 2013 08:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cfulx+JTuzD for ; Wed, 6 Nov 2013 08:54:51 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 515E121E8082 for ; Wed, 6 Nov 2013 08:54:51 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rA6GsiNM017581; Wed, 6 Nov 2013 08:54:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1383756890; bh=0m2/Y49XO7TRxNhO0n9ASPdca1pwp/jJFcvWuTmobbk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=4+W17GApFPL7v/O780uppzP4hn7WU/Aby/kLXtEll91yu4bx4Q7rwCffzjEKjDBO/ QejYP6kV8/3xxBq/fBM+FdLDxJMP2bSZbz1cCu2fguPHQde4LF2kM9HTEmfmfYZBzY JwRXIVm7mbGK2Gw03fxrazx3XjGxbw3k/2IQhK2s= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1383756890; i=@resistor.net; bh=0m2/Y49XO7TRxNhO0n9ASPdca1pwp/jJFcvWuTmobbk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=gU63HAC6xY0r6nq04Y+Xo9U4cp/lr1mEQKlUIsXkEkisNJGJrGVzmkUacrOh9eeM4 /NLvhiNg8Gob15vdk0/kWu1Mfo2ZbGy8X0I/oT/BznL9vjPjQjaNsYPjiCQZiIRlMt tnzMZWUSA+5uyAo14+dDbkad1wOFnH6pBMpsKrx0= Message-Id: <6.2.5.6.2.20131106083041.0c572800@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 06 Nov 2013 08:39:53 -0800 To: Hosnieh Rafiee From: SM In-Reply-To: <003701cedae4$e7494360$b5dbca20$@rozanak.com> References: <002101ceda82$f49bd4e0$ddd37ea0$@rozanak.com> <6.2.5.6.2.20131105210233.0d495e28@resistor.net> <003701cedae4$e7494360$b5dbca20$@rozanak.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Erik Nordmark , apps-discuss@ietf.org Subject: Re: [apps-discuss] privacy in applications - anybody working in this area or interested? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 16:54:52 -0000 Hi Hosnieh, At 03:39 06-11-2013, Hosnieh Rafiee wrote: >This is like an intermediate framework between network layer and application >layer. There is two possibilities. Firstly, the framework checks the current >available processes in the list of tasks and if any processes wants to use >internet it assigns a IID. Secondly, the application can trigger a function >to ask for an IID and it is transparent for it how this happen. But this is >actually implementation issue. I implemented the first option for Windows to >check the performance. The second option is easier since the application >calls the function and this application layer lifetime does not need to care >about the processes in the node. Thanks, the above addresses my question. There is a message about identifiers at http://www.ietf.org/mail-archive/web/ietf/current/msg83662.html I like the suggestion to "start from first principles before thinking about solutions" and "what needs to be identified, and what characteristics does it have". Regards, -sm From Peter.Rushforth@NRCan-RNCan.gc.ca Wed Nov 6 08:56:44 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C547B21F9F08 for ; Wed, 6 Nov 2013 08:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilcks5Irp4lO for ; Wed, 6 Nov 2013 08:56:39 -0800 (PST) Received: from nrcan.gc.ca (s-bsc-edge1.nrcan.gc.ca [132.156.238.13]) by ietfa.amsl.com (Postfix) with ESMTP id 822D421F8415 for ; Wed, 6 Nov 2013 08:56:28 -0800 (PST) Received: from S-BSC-CAS1.nrn.nrcan.gc.ca (132.156.238.11) by S-BSC-EDGE1.nrcan.gc.ca (132.156.238.13) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 6 Nov 2013 11:56:25 -0500 Received: from S-BSC-MBX1.nrn.nrcan.gc.ca ([169.254.1.186]) by S-BSC-CAS1.nrn.nrcan.gc.ca ([fe80::a1cd:5722:74ed:d1fd%21]) with mapi id 14.02.0342.003; Wed, 6 Nov 2013 11:56:25 -0500 From: "Rushforth, Peter" To: Mark Baker , Erik Wilde Thread-Topic: [apps-discuss] proposal: adding profile support to JSON Thread-Index: AQHO2LoGs7m3K3yZ+k2Edv+Q9dGPQpoWp+WAgAB6A4CAABEggIAAGoMAgAFLpQD//9JM8A== Date: Wed, 6 Nov 2013 16:56:24 +0000 Message-ID: <1CD55F04538DEA4F85F3ADF7745464AF24A8A389@S-BSC-MBX1.nrn.nrcan.gc.ca> References: <5276878A.6000802@berkeley.edu> <5278AF21.90605@it.aoyama.ac.jp> <52793A16.8060301@berkeley.edu> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.156.238.22] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] proposal: adding profile support to JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 16:56:44 -0000 Hey Mark, > -----Original Message----- > From: apps-discuss-bounces@ietf.org=20 > [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Mark Baker > Sent: November 6, 2013 09:21 > To: Erik Wilde > Cc: apps-discuss@ietf.org application-layer protocols > Subject: Re: [apps-discuss] proposal: adding profile support to JSON >=20 > Hi Erik, >=20 > On Tue, Nov 5, 2013 at 1:33 PM, Erik Wilde wrote: > > hello mark. > > > > > > On 2013-11-05, 08:59 , Mark Baker wrote: > >> > >> On Tue, Nov 5, 2013 at 10:57 AM, Tim Bray=20 > wrote: > >>> > >>> Well, for example,=20 > >>> http://www.tbray.org/tmp/draft-bray-i-json-01.html > >> > >> I'm with Martin. What that spec is trying to do with=20 > profiles is to=20 > >> supplant the typical role of a media type. If it's=20 > representative of=20 > >> what Erik has in mind for the use of a profile parameter with Atom=20 > >> (or anywhere), then I think that needs to be reconsidered too. > > > > > > i understand your concerns, but profiles do not attempt to "replace=20 > > media types", even though they could be (mis-)used to try=20 > to do just=20 > > that. [1] tries to explain the goal: they are for=20 > specializing and/or=20 > > constraining existing media types; representing both the=20 > nature of the=20 > > underlying type ("this is an atom feed and can be processed as a=20 > > generic feed") as well as the specialized/constrained=20 > profile ("this=20 > > feed carries podcast data, and can be processed as a podcast feed"). >=20 > I've read your RFC, and both referenced blog posts, but still=20 > find myself asking the same question; what problem does it=20 > solve? Yes, media types have their issues, but in my many=20 > years in Web development and standardization, I've yet to=20 > encounter a problem that didn't have a workable solution=20 > through the correct use of link relations and media types.=20 > This includes my time advising on the development of a=20 > compound document editor at Justsystem, and representing them=20 > on the W3C Compound Document Formats WG. >=20 > We agree that a document containing some OPDS extensions is=20 > still an Atom document that can be delivered as=20 > application/atom+xml, I believe. You appear to suggest that=20 > there's value in exposing the existence of those OPDS=20 > extensions using an additional external metadata protocol=20 > element. I believe that this is at best an optimization,=20 > since the consumer can easily detect the existence of the=20 > extension by inspecting the content=20 How can the consumer *request* the extended semantics, if not through the m= edia type? Lots of stuff gets transmitted under guise of text/html, application/xml, a= pplication/json that should be encouraged to register. > But at worst, it's a=20 > recipe for interop problems; does the meaning of the document=20 > change if the profile is declared vs not?=20 According to RFC 2045, it falls back to the base media type/subtype without= =20 that parameter. " Parameters are modifiers of the media subtype, and as such do not fundamentally affect the nature of the content.=20 ... MIME implementations must ignore any parameters whose names they do not recognize." > What if the v2=20 > profile URI is declared and the document contains a v1=20 > extension? . That would be an error, unless v1 is wholly included in v2. Furthermore, media type parameters are meant to help the client interpret the meaning of the message. An optional parameter should = not be not a 'slot', it should be a recommendation to future registrations to d= efine values of it. I think the recommended use of a URI perhaps leads one to think it can be assigned ad hoc. I think values=20 should be registered, like what Tim is doing. > > james snell blogged about the bigger problem [2] that media=20 > types as=20 > > they are today are not a terribly well-designed concept. >=20 > I strongly disagree with that post (blog commenting seems=20 > broken, but I won't respond in detail here except to say=20 > "rel=3Dicon" :). I believe media types are far better designed=20 > than is commonly appreciated; a single label for a compatible=20 > evolution of a document format is a simple yet extremely=20 > powerful protocol that promotes compatibility in extensions=20 > and penalizes incompatible deviations... but still permits=20 > them when required. +1 >=20 > And FWIW, this is coming from the guy who, AFAIK, started the=20 > whole profile parameter ball rolling in RFC 3236. That went=20 > in there only as a compromise with the WAPforum, but was=20 > never/rarely used in practice. Interesting, thanks for pointing that out. Regards, Peter Rushforth From julian.reschke@gmx.de Wed Nov 6 08:56:50 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2ED021E8109 for ; Wed, 6 Nov 2013 08:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.399 X-Spam-Level: X-Spam-Status: No, score=-104.399 tagged_above=-999 required=5 tests=[AWL=-1.800, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OM-qCtH8XJ8 for ; Wed, 6 Nov 2013 08:56:45 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 08AE521F9ED4 for ; Wed, 6 Nov 2013 08:56:38 -0800 (PST) Received: from [31.133.162.78] ([31.133.162.78]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LmJsk-1WCtC20Sji-00ZuwJ for ; Wed, 06 Nov 2013 17:56:36 +0100 Message-ID: <527A74C3.3010506@gmx.de> Date: Wed, 06 Nov 2013 17:56:35 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: James M Snell References: <5279952E.5040402@gmx.de> <527997D3.4010108@gmx.de> <527999EA.9050401@gmx.de> <527A5C23.8050201@gmx.de> <527A61E8.2050309@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:oGDdUxSPx6OXeriG5THTB72Jd+ZZkmfJF9ydfiJU/n9LnwcuSm0 zTQ8k8/LruiYEVB5iC5I25urDRoSfFEJyVg+K6TQMGi0mm7MgUtIIE5NCo2IAV3IRDadYGL tJui5PkmxrsoFBV7TEPZ6F4uF2iJCZiDujjmEj2ccpe8eo5x0I7OX65TKBBkW/OTmjdj1Cb 8nhVJKZugkiGPWyGdNV9A== Cc: Mark Nottingham , "ietf-http-wg@w3.org" , IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 16:56:51 -0000 On 2013-11-06 17:18, James M Snell wrote: > ... >>> Regarding the main question about whether or not to include target >>> attributes in the uniqueness constraint, the question becomes: which >>> target attributes should be considered? >> >> >> All of them? >> > > "All of them" becomes impractical for the reasons I've already given, > particularly without clearly defined, viable, non-theoretical use > cases. I don't understand how "all of them" can be impractical when "two of them" works. Furthermore, how does the (current) lack of a use case affect the practicability? > That said, here's a compromise: Let's expand the uniqueness constraint > to include anchor, hreflang and type. Doing so ought to cover the vast > overwhelming majority of the possibly viable use cases. I can also say > that the server MUST consider the remaining target attributes to be > significant in that, *if* the server chooses to surface those links in > some representable manner, the most recently received values for those > MUST be included. Is that better? I don't think it resolves the issue... > ... Best regards, Julian From scott.brim@gmail.com Wed Nov 6 09:08:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 712BC11E8222 for ; Wed, 6 Nov 2013 09:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0o5g6-fbH9Hl for ; Wed, 6 Nov 2013 09:08:28 -0800 (PST) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A7FC111E820E for ; Wed, 6 Nov 2013 09:08:28 -0800 (PST) Received: by mail-oa0-f43.google.com with SMTP id m1so10643721oag.30 for ; Wed, 06 Nov 2013 09:08:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r7TMTDQ3hdPsdpfdkl9ZYXIx0bgFfnsma7AsTyvXqDU=; b=BtIql/4HWgGPCYdm80m/w2cVLd1gVQQhqJao8lqMQAPdgL/4ig9gehiIpPQQh8XT3N 5+9xN3cny+6g/82k1+xdNm6HzFyAybt16fUFp+ZdDVzBymsXeZCzMVenKgrgGUIUkJcD fhnQyuvf4Sz0Wyl3k/diFTinBlUGSPs0weS34naWkLIh4Q6aA58lZim6bt1AKN9Sqeai guvkQ3QhwyfnBPek86n+DJccesx3TQDU8wUYpXFjf/YmA0z809wm0MvPsWnaIl+y2DYd jpzcjuQp3LSdqpH/wITqPzA6lYAAoVKORsAjqFWXYdQJwL0/uB6g6eWi3s5hykfc2VY4 ISyA== MIME-Version: 1.0 X-Received: by 10.182.81.41 with SMTP id w9mr3497137obx.18.1383757707953; Wed, 06 Nov 2013 09:08:27 -0800 (PST) Received: by 10.182.2.134 with HTTP; Wed, 6 Nov 2013 09:08:27 -0800 (PST) In-Reply-To: <5279A0BC.6030506@sonic.net> References: <002101ceda82$f49bd4e0$ddd37ea0$@rozanak.com> <5279A0BC.6030506@sonic.net> Date: Wed, 6 Nov 2013 09:08:27 -0800 Message-ID: From: Scott Brim To: Erik Nordmark Content-Type: multipart/alternative; boundary=047d7b2e4d7ca5018204ea853208 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] privacy in applications - anybody working in this area or interested? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 17:08:29 -0000 --047d7b2e4d7ca5018204ea853208 Content-Type: text/plain; charset=ISO-8859-1 On Tuesday, November 5, 2013, Erik Nordmark wrote: > On 11/5/13 5:03 PM, Scott Brim wrote: > > You've opened up a multi-layer issue here. If each application gets a >> separate IID, that could make privacy more difficult, in that it could >> be easier to track and correlate the behavior of applications even with >> low layer encryption. Your proposal could be okay if each application >> (or session, actually) could request a new IID at an arbitrary time, and >> if there were a general way for sessions to let each other know this was >> happening, like multihomed transport. Fun yet? >> > > Scott, > > I'm not sure I understand. > > An example of what Hosnieh and I have been talking about is an application > (like a web browser) having some privacy-enhancing feature (such as > incognito browsing sessions/tabs). In such a case it would seem to make > sure to pick a different IPv6 IID for traffic originated due to the > separate session. > > But the user presumably would want to make it hard to link that traffic > with other traffic from the box, hence a multihomed transport (which links > multiple sessions together) would seem to be the opposite of what they'd > expect. > > Regards, > Erik > Hi Erik. A new IID used for a specific activity would stick out. A scanner would definitely notice it - you wouldn't just slip it past - and would say "there's something unusual here, I might benefit by paying closer attention". If it's in a /64 with other more normal use, the scanner would look even closer for correlations. I don't think this gives more privacy, I think it attracts attention. On the other hand if I could encrypt my content and use multiple IIDs within a single session, that would make correlating a bit more difficult. This kind of agility requires a handshake between endpoints, along the lines of SCTP CMT or MPTCP. IMHO ... Scott --047d7b2e4d7ca5018204ea853208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tuesday, November 5, 2013, Erik Nordmark wrote:
On 11/5/13 5:03 PM, Scott Brim wrote:

You've opened up a multi-layer issue here. If each application gets a separate IID, that could make privacy more difficult, in that it could
be easier to track and correlate the behavior of applications even with
low layer encryption. Your proposal could be okay if each application
(or session, actually) could request a new IID at an arbitrary time, and if there were a general way for sessions to let each other know this was happening, like multihomed transport. =A0Fun yet?

Scott,

I'm not sure I understand.

An example of what Hosnieh and I have been talking about is an application = (like a web browser) having some privacy-enhancing feature (such as incogni= to browsing sessions/tabs). In such a case it would seem to make sure to pi= ck a different IPv6 IID for traffic originated due to the separate session.=

But the user presumably would want to make it hard to link that traffic wit= h other traffic from the box, hence a multihomed transport (which links mul= tiple sessions together) would seem to be the opposite of what they'd e= xpect.

Regards,
=A0 =A0Erik

Hi Erik.

A new IID used for a specific activity would stick out. =A0A scanner= would definitely notice it - you wouldn't just slip it past - and woul= d say "there's something unusual here, I might benefit by paying c= loser attention". =A0 If it's in a /64 with other more normal use,= the scanner would look even closer for correlations. =A0I don't think = this gives more privacy, I think it attracts attention. =A0

On the other hand if I could encrypt my content and use= multiple IIDs within a single session, that would make correlating a bit m= ore difficult. =A0This kind of agility requires a handshake between endpoin= ts, along the lines of SCTP CMT or MPTCP. =A0

IMHO ... Scott

--047d7b2e4d7ca5018204ea853208-- From jasnell@gmail.com Wed Nov 6 09:13:55 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4E521E811B for ; Wed, 6 Nov 2013 09:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJXec8tKhQOs for ; Wed, 6 Nov 2013 09:13:55 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2703C21E8115 for ; Wed, 6 Nov 2013 09:13:55 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id va2so2595217obc.37 for ; Wed, 06 Nov 2013 09:13:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UNmSDw+6hTmYqG6M+At4JoavDDNU+RMPvXnhYZX0qYY=; b=i7X0VpJXegddVIDp3J2JYYW4hgNnSMcLeAd5H2V01YtxwVgbp2Gixg8rhDMsE8gZrs nkfEnlbnw2pWU/4oMt8ID0HICKCVKIlkYavNVy9B9vMCfRXeV/Lgb0I9SY5rCbOOqNAt vcbHYcwKZ9cWGPCrJRxx3ErwBjohNsssouZycS5d9ayTTSqX5d8JTaY0bG1LQ6enc09p ZgGZNFbbgzjxBra195jZbPn+AQkLqisjmL/v6fihMstKKeSMk4626ZvdwApumkS1RVyF UVRqAjrjyXOqPwJpa6Cr0QGsV4mgM0qfFwhekBjusHdtuzMSrt8q75E3s68DyV7mRj2z AB0Q== X-Received: by 10.182.215.202 with SMTP id ok10mr1517151obc.62.1383758034620; Wed, 06 Nov 2013 09:13:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.124.137 with HTTP; Wed, 6 Nov 2013 09:13:34 -0800 (PST) In-Reply-To: <527A74C3.3010506@gmx.de> References: <5279952E.5040402@gmx.de> <527997D3.4010108@gmx.de> <527999EA.9050401@gmx.de> <527A5C23.8050201@gmx.de> <527A61E8.2050309@gmx.de> <527A74C3.3010506@gmx.de> From: James M Snell Date: Wed, 6 Nov 2013 09:13:34 -0800 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Cc: Mark Nottingham , "ietf-http-wg@w3.org" , IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 17:13:55 -0000 On Wed, Nov 6, 2013 at 8:56 AM, Julian Reschke wrote: > On 2013-11-06 17:18, James M Snell wrote: [snip] >> >> "All of them" becomes impractical for the reasons I've already given, >> particularly without clearly defined, viable, non-theoretical use >> cases. > > > I don't understand how "all of them" can be impractical when "two of them" > works. > > Furthermore, how does the (current) lack of a use case affect the > practicability? > Not intending to be rude, but I've already answered this... it has to do with the amount of a priori knowledge a client needs to unlink or update a single link relationship. > >> That said, here's a compromise: Let's expand the uniqueness constraint >> to include anchor, hreflang and type. Doing so ought to cover the vast >> overwhelming majority of the possibly viable use cases. I can also say >> that the server MUST consider the remaining target attributes to be >> significant in that, *if* the server chooses to surface those links in >> some representable manner, the most recently received values for those >> MUST be included. Is that better? > > > I don't think it resolves the issue... > Is it at least a step in the right direction? - James >> ... > > > Best regards, Julian From ietf@rozanak.com Wed Nov 6 09:50:28 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D646521E816A for ; Wed, 6 Nov 2013 09:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZL40nz1JyghE for ; Wed, 6 Nov 2013 09:50:16 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9B821E8172 for ; Wed, 6 Nov 2013 09:50:13 -0800 (PST) Received: from kopoli (dhcp-a798.meeting.ietf.org [31.133.167.152]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0Ma26R-1VLDyx2K0F-00LfHu; Wed, 06 Nov 2013 12:50:12 -0500 From: "Hosnieh Rafiee" To: "'Scott Brim'" References: <002101ceda82$f49bd4e0$ddd37ea0$@rozanak.com> <5279A0BC.6030506@sonic.net> In-Reply-To: Date: Wed, 6 Nov 2013 18:50:06 +0100 Message-ID: <001601cedb18$a389d3e0$ea9d7ba0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKkV7ZzhCzbQYGFezj5ycrrtI8nuQJ/0BilAhzR8PIAz6GnWphCGxAA Content-Language: en-us X-Provags-ID: V02:K0:X3eNgOSWFxEzuozIJIhHvG+i4n/j8yxqkQmzXwHykdl TwMtHTF/Nis+oE48zXmUMt1BUt0eJ76Eb5aeL+5EiKNnJxYW82 KR/gUUzFoiCMoSwqgCItFIDyiDxKy2LD0CxET7Dqu1SO9rVOPL G5n0K6u8YwlI8gle912meJxe/KcSlbE9+xhZdG10ojDc0jxypG PVLzovjkzlcNBCxeTMtxIcmuiH119uWLvzky6Zm0dZvUtWqW+N L5V4wwhhZMSIlOWuqwOO0cdwZAXuJdZlEFnS3qHEqhQdheJzpH 6dyj2JCKblzGYvogdGAp8oh7AHoNLaKXRhOyBE1HgsQLdaqv7x iSXV6h6k73GD7zWkFb2c= Cc: 'Erik Nordmark' , apps-discuss@ietf.org Subject: Re: [apps-discuss] privacy in applications - anybody working in this area or interested? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 17:50:29 -0000 Hi Scott, >A new IID used for a specific activity would stick out. =A0A scanner = would definitely notice it - you wouldn't just slip it past - and would say "there's something unusual here, I might benefit by paying closer attention". =A0 If >it's in a /64 with other more normal use, the = scanner would look even closer for correlations. =A0I don't think this gives = more privacy, I think it attracts attention. =A0 Let me give you an example. Consider a scenario where there are = different nodes in a network that use the same prefix. We want to focus on one of these nodes. It is a fixed node in this network. Since IPv6 addresses = are public addresses, dissimilar to IPv4, the IPv6 address of this node is = the unique identity of this node. Actually this is the feature of IPv6 to = allow easy end-to-end communications. It's not popular in IPv6 to use NAT yet. This is because the main purpose of NAT is to address the lack of = available IP addresses. This problem existed in IPv4 but we do not have this = problem in IPv6. However, later they also used NAT as a way of hiding the real = IP addresses of the node inside the network but as I explained, NAT is = still not popular in IPv6 because it is against its actual feature.=20 So, this means our target nodes use one unique IP address which is its = real identity to access different resources on the internet. If one of this websites is a bad guy's website, the node is now vulnerable to possible privacy and security attacks. As you know the initial step to attack a = node in a network is recon the node. This gives the attacker an easy way of = recon this node.=20 But now if the IID of this node changes, then the attacker will not have this opportunity to attack this node. The attacker does not know how = many nodes available in the same subnet prefix.=20 Now let me explain about the level of privacy that we provide for our = nodes if they apply our approach. It is actually about medium to high privacy. = If you want to have high privacy, that is true that you might want to use encryption as well. But our purpose is to decrease the chance of node's recon. I guess it would be useful if you can attend in our presentation (remote = or in person). >On the other hand if I could encrypt my content and use multiple IIDs within a single session, that would make correlating a bit more = difficult. =A0This kind of agility requires a handshake between endpoints, along = the ?>lines of SCTP CMT or MPTCP. =A0 -----------smile---------- Hosnieh =85 success is a journey, not a destination=85. You cannot change your destination overnight, but you can change your direction ... Focus on the journey From julian.reschke@gmx.de Wed Nov 6 10:05:40 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B5D11E80F9 for ; Wed, 6 Nov 2013 10:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.335 X-Spam-Level: X-Spam-Status: No, score=-104.335 tagged_above=-999 required=5 tests=[AWL=-1.736, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42TOXvpkYgA8 for ; Wed, 6 Nov 2013 10:05:35 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id BA24511E8132 for ; Wed, 6 Nov 2013 10:05:34 -0800 (PST) Received: from [31.133.162.78] ([31.133.162.78]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0ML6XF-1VeOb60ooT-000InU for ; Wed, 06 Nov 2013 19:05:33 +0100 Message-ID: <527A84ED.3080208@gmx.de> Date: Wed, 06 Nov 2013 19:05:33 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: James M Snell References: <5279952E.5040402@gmx.de> <527997D3.4010108@gmx.de> <527999EA.9050401@gmx.de> <527A5C23.8050201@gmx.de> <527A61E8.2050309@gmx.de> <527A74C3.3010506@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:1XJ47iE4YrCr2iVe35EZzTf5CeogPUxPIjWxIMCudZV84JB/EJQ a2YaltBcCmNzMBCpLtmk0YZS2KmfEwoJaM0vuQ0nOqCJA8NDjgEkHh5aOl+TH8Z6x6wlCAQ P4dcTDmHKPj+nErqnnefXPwD2qNGDPPnshwWaNIko7Unoc0aie+4CZBsv2cgfgTsTil+f/j jHVok01eGQpgWU+JK2lyQ== Cc: Mark Nottingham , "ietf-http-wg@w3.org" , IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 18:05:40 -0000 On 2013-11-06 18:13, James M Snell wrote: > On Wed, Nov 6, 2013 at 8:56 AM, Julian Reschke wrote: >> On 2013-11-06 17:18, James M Snell wrote: > [snip] >>> >>> "All of them" becomes impractical for the reasons I've already given, >>> particularly without clearly defined, viable, non-theoretical use >>> cases. >> >> >> I don't understand how "all of them" can be impractical when "two of them" >> works. >> >> Furthermore, how does the (current) lack of a use case affect the >> practicability? >> > > Not intending to be rude, but I've already answered this... it has to > do with the amount of a priori knowledge a client needs to unlink or > update a single link relationship. I don't see the material difference. If the client has no reliable way to find out what links are there it'll be essentially restricted to edit those that it created itself. It seems that this is the issue that needs to be addressed. >>> That said, here's a compromise: Let's expand the uniqueness constraint >>> to include anchor, hreflang and type. Doing so ought to cover the vast >>> overwhelming majority of the possibly viable use cases. I can also say >>> that the server MUST consider the remaining target attributes to be >>> significant in that, *if* the server chooses to surface those links in >>> some representable manner, the most recently received values for those >>> MUST be included. Is that better? >> >> >> I don't think it resolves the issue... >> > > Is it at least a step in the right direction? Well yes, it includes more parameters, but what I'm mainly concerned with parameters that we don't know yet. Best regards, Julian From jasnell@gmail.com Wed Nov 6 10:21:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A8D11E8244 for ; Wed, 6 Nov 2013 10:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlXmj-EBt8bC for ; Wed, 6 Nov 2013 10:21:32 -0800 (PST) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3304E11E8243 for ; Wed, 6 Nov 2013 10:21:32 -0800 (PST) Received: by mail-ob0-f174.google.com with SMTP id vb8so10440450obc.19 for ; Wed, 06 Nov 2013 10:21:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vSCwWFqJLpmJUw8TblHMu+yoUkOwNzPaEho6txRF9Y8=; b=z5KufzjEN7tb+Ukl9cZ8NfrDdS40eEejlhvu9TacqEWiXHyFdjFSizI9rnODPZ1kpP JSO5oxa2ZF8kpaT0d89avAP3/BTAvq2MW+GW7XWg5scJKCUIi7HIuCGwt6JUOo+Exv29 K06Xka28w08DxV7eQmmshnabXU0M0gG4MXBuh3ZWbLlVWqbs2f+Gzbk4zl44cuJ4DwyG V7tYdBptludTMDhFcbNtIjyd3QZRXBAJuFEVK1Th31/85ZRAvINeeLjKY2hEBJxFZs3w Z2aR0tmplhT8k+5T05v8mj7HLmhMu8LZELYxmIU3d95N5ydopmTMxMWspSVZWCngl/9b 06BA== X-Received: by 10.182.81.99 with SMTP id z3mr1632716obx.64.1383762091618; Wed, 06 Nov 2013 10:21:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.124.137 with HTTP; Wed, 6 Nov 2013 10:21:11 -0800 (PST) In-Reply-To: <527A84ED.3080208@gmx.de> References: <5279952E.5040402@gmx.de> <527997D3.4010108@gmx.de> <527999EA.9050401@gmx.de> <527A5C23.8050201@gmx.de> <527A61E8.2050309@gmx.de> <527A74C3.3010506@gmx.de> <527A84ED.3080208@gmx.de> From: James M Snell Date: Wed, 6 Nov 2013 10:21:11 -0800 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Cc: Mark Nottingham , "ietf-http-wg@w3.org" , IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 18:21:32 -0000 On Wed, Nov 6, 2013 at 10:05 AM, Julian Reschke wrote: [snip] > > I don't see the material difference. > > If the client has no reliable way to find out what links are there it'll be > essentially restricted to edit those that it created itself. > > It seems that this is the issue that needs to be addressed. > > This is not a problem I intend to solve... largely because I have no need to solve it. For one set of use cases I have, there is no need to discover established links, and for the remaining set, the data formats used already have ways of exposing whatever links the server wishes to expose. That said, have a concrete suggestion? - James >>>> That said, here's a compromise: Let's expand the uniqueness constraint >>>> to include anchor, hreflang and type. Doing so ought to cover the vast >>>> overwhelming majority of the possibly viable use cases. I can also say >>>> that the server MUST consider the remaining target attributes to be >>>> significant in that, *if* the server chooses to surface those links in >>>> some representable manner, the most recently received values for those >>>> MUST be included. Is that better? >>> >>> >>> >>> I don't think it resolves the issue... >>> >> >> Is it at least a step in the right direction? > > > Well yes, it includes more parameters, but what I'm mainly concerned with > parameters that we don't know yet. > > Best regards, Julian From julian.reschke@gmx.de Wed Nov 6 10:31:30 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D648E11E8115 for ; Wed, 6 Nov 2013 10:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.357 X-Spam-Level: X-Spam-Status: No, score=-104.357 tagged_above=-999 required=5 tests=[AWL=-1.758, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAwp+qEn1F7j for ; Wed, 6 Nov 2013 10:31:24 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id EC55821F8E8E for ; Wed, 6 Nov 2013 10:31:22 -0800 (PST) Received: from [31.133.162.78] ([31.133.162.78]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M3NEK-1VvehY2G6S-00r2Vf for ; Wed, 06 Nov 2013 19:31:18 +0100 Message-ID: <527A8AF3.4000304@gmx.de> Date: Wed, 06 Nov 2013 10:31:15 -0800 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: James M Snell References: <5279952E.5040402@gmx.de> <527997D3.4010108@gmx.de> <527999EA.9050401@gmx.de> <527A5C23.8050201@gmx.de> <527A61E8.2050309@gmx.de> <527A74C3.3010506@gmx.de> <527A84ED.3080208@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:MnWaBXEWhdLSZtDb2ce511/3ak/fwoNRJqG37gqs/lXfNIGgYxc Z6TEcZg1Rf/H1bBLCAT+T8zwLUN1zP+1cyUACVwUoDYD/oFIvcuU/Gbki4Vi/a6+l4DhnM9 DOSQQMTEWZaAx4gavCXNzAeLdPx4aKWi2+AABq3zSdvp/1jnEj88s1BeXL71EdHCtjPlgt/ jQ3KYrS7QJClRCGcr0vvg== Cc: Mark Nottingham , "ietf-http-wg@w3.org" , IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 18:31:30 -0000 On 2013-11-06 10:21, James M Snell wrote: > On Wed, Nov 6, 2013 at 10:05 AM, Julian Reschke wrote: > [snip] >> >> I don't see the material difference. >> >> If the client has no reliable way to find out what links are there it'll be >> essentially restricted to edit those that it created itself. >> >> It seems that this is the issue that needs to be addressed. >> >> > > This is not a problem I intend to solve... largely because I have no > need to solve it. For one set of use cases I have, there is no need to > discover established links, and for the remaining set, the data > formats used already have ways of exposing whatever links the server > wishes to expose. > > That said, have a concrete suggestion? Maybe have a keyword for the "Prefer" header field that instructs the server to return *all* links upon GET? Best regards, Julian From dret@berkeley.edu Wed Nov 6 10:35:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E91011E815A for ; Wed, 6 Nov 2013 10:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.276 X-Spam-Level: X-Spam-Status: No, score=-6.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lq5sP4tYPwiM for ; Wed, 6 Nov 2013 10:35:36 -0800 (PST) Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id EF1C011E80F9 for ; Wed, 6 Nov 2013 10:35:35 -0800 (PST) Received: from dhcp-a20d.meeting.ietf.org ([31.133.162.13]) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1Ve7x0-00071w-5U; Wed, 06 Nov 2013 10:35:35 -0800 Message-ID: <527A8BF6.20604@berkeley.edu> Date: Wed, 06 Nov 2013 10:35:34 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "apps-discuss@ietf.org application-layer protocols" References: <5276878A.6000802@berkeley.edu> <5278AF21.90605@it.aoyama.ac.jp> <52793A16.8060301@berkeley.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] proposal: adding profile support to JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 18:35:42 -0000 hello mark. On 2013-11-06, 06:20 , Mark Baker wrote: > I've read your RFC, and both referenced blog posts, but still find > myself asking the same question; what problem does it solve? Yes, > media types have their issues, but in my many years in Web development > and standardization, I've yet to encounter a problem that didn't have > a workable solution through the correct use of link relations and > media types. as i am sure you know, "profile" is a link relation. so what you're saying that it's not a "correct" use of link relations? i am really just trying to understand your perspective here. a profile media type parameter just exposes that link relation in a special place, because it matters for the media type, and it is more convenient to see it exposed there, instead of first having to parse the representation. > We agree that a document containing some OPDS extensions is still an > Atom document that can be delivered as application/atom+xml, I > believe. yes, absolutely. > You appear to suggest that there's value in exposing the > existence of those OPDS extensions using an additional external > metadata protocol element. yes, because then profiles can, for example, take part in wen-level mechanisms such as conneg, instead of being "hidden" only in the representations. > I believe that this is at best an > optimization, since the consumer can easily detect the existence of > the extension by inspecting the content (and understanding the > extensibility model of the host format). true for reading, not true for writing, where profiles can also indicate what constrained media types a server is willing to accept. > But at worst, it's a recipe > for interop problems; does the meaning of the document change if the > profile is declared vs not? no it doesn't. the RFC (at least tries to) make that clear. if the processing model of the underlying media type cannot be safely applied to a representation using a profile, then you shouldn't use a profile. > What if the v2 profile URI is declared and > the document contains a v1 extension? etc.. this is no different from the media type versioning problem. cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From dret@berkeley.edu Wed Nov 6 10:51:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050C721E8161; Wed, 6 Nov 2013 10:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.341 X-Spam-Level: X-Spam-Status: No, score=-6.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foeUdBsoAjmx; Wed, 6 Nov 2013 10:51:22 -0800 (PST) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF1221E808D; Wed, 6 Nov 2013 10:51:18 -0800 (PST) Received: from dhcp-a20d.meeting.ietf.org ([31.133.162.13]) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1Ve8CC-0004zB-BV; Wed, 06 Nov 2013 10:51:18 -0800 Message-ID: <527A8FA5.9040405@berkeley.edu> Date: Wed, 06 Nov 2013 10:51:17 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Markus Lanthaler , apps-discuss@ietf.org, 'JSON WG' References: <5276878A.6000802@berkeley.edu> <5278AF21.90605@it.aoyama.ac.jp> <52793A16.8060301@berkeley.edu> <527a6316.c214440a.6c31.ffffefe5SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: <527a6316.c214440a.6c31.ffffefe5SMTPIN_ADDED_BROKEN@mx.google.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] proposal: adding profile support to JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 18:51:35 -0000 hello markus. thanks for the feedback. On 2013-11-06, 07:41 , Markus Lanthaler wrote: > As you say, in XML you can leverage namespacing to create fully > self-descriptive messages without requiring another media type. In this > thread, however, we are talking about JSON which doesn't support > namespacing. So, how would you (or any of the numerous JSON APIs out there) > signal the semantics of such "extensions" in a JSON document without minting > a new media type? i think there are several ways in which you can do this. if your JSON format supports generic linking somehow somewhere in the format, then you can simply add a "profile" link. if it doesn't, you might have a specific profile identifier in the format, similar to HTML's head/@profile. but that's of course assuming you already *have* some processing model in place that's used for the representation, so we might have a chicken-and-egg problem here. maybe that points to the fact that in practice, profiles make more sense on more meaningful media types (such as adding profiles to Atom or HTML that signify certain ways of how these formats are constrained), and less so on very generic ones. on the other hand, I-JSON may be a good example for how even something as generic as plain JSON might benefit from profiles being exposable on the media type level. cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From markus.lanthaler@gmx.net Wed Nov 6 11:10:53 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A1F21E817A for ; Wed, 6 Nov 2013 11:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjeS6qi96bdz for ; Wed, 6 Nov 2013 11:10:47 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 7852D21E8175 for ; Wed, 6 Nov 2013 11:10:47 -0800 (PST) Received: from Vostro3500 ([178.115.129.229]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LgdBZ-1W1O1D0CAP-00nveO for ; Wed, 06 Nov 2013 20:10:46 +0100 From: "Markus Lanthaler" To: "'Erik Wilde'" , , "'JSON WG'" References: <5276878A.6000802@berkeley.edu> <5278AF21.90605@it.aoyama.ac.jp> <52793A16.8060301@berkeley.edu> <527a6316.c214440a.6c31.ffffefe5SMTPIN_ADDED_BROKEN@mx.google.com> <527A8FA5.9040405@berkeley.edu> In-Reply-To: <527A8FA5.9040405@berkeley.edu> Date: Wed, 6 Nov 2013 20:10:40 +0100 Message-ID: <031601cedb23$e4c5f540$ae51dfc0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7bIS5y9tuveYctTk27UMPT3z2mGAAAjvWw Content-Language: de X-Provags-ID: V03:K0:ZUepMy84EMuzVm03x6TrJipdQD6L6UTdc93+Mt76JtexVxfZ/x/ h/43h1LeqsBKpJw5XNzp4xIrlJQ+aQ1YCZse5sPV45e1uPD9wEJOWUBYtwItBi5v0ZNVJJw Mqs7bpXwc7cjoojaa6/3XGXHFzvIjzKA6xcPu6Q1bpyqKtOZ74C8phLOwPU4uj/bwTySDJZ YiFuIVU+VgH7zF6Kxlodg== Subject: Re: [apps-discuss] proposal: adding profile support to JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 19:10:54 -0000 On Wednesday, November 06, 2013 7:51 PM, Erik Wilde wrote: > On 2013-11-06, 07:41 , Markus Lanthaler wrote: > > As you say, in XML you can leverage namespacing to create fully > > self-descriptive messages without requiring another media type. In = this > > thread, however, we are talking about JSON which doesn't support > > namespacing. So, how would you (or any of the numerous JSON APIs out = there) > > signal the semantics of such "extensions" in a JSON document without = minting > > a new media type? >=20 > i think there are several ways in which you can do this. if your JSON > format supports generic linking somehow somewhere in the format, then I was specifically talking about application/json. > you can simply add a "profile" link. if it doesn't, you might have a > specific profile identifier in the format, similar to HTML's > head/@profile. but that's of course assuming you already *have* some > processing model in place that's used for the representation, so we > might have a chicken-and-egg problem here. Right, to signal it you could use a HTTP Link header, but that wouldn't = work for conneg. > maybe that points to the fact that in practice, profiles make more = sense > on more meaningful media types (such as adding profiles to Atom or = HTML > that signify certain ways of how these formats are constrained), and > less so on very generic ones. on the other hand, I-JSON may be a good > example for how even something as generic as plain JSON might benefit > from profiles being exposable on the media type level. I think quite the contrary is the case. IMO generic media types such as = JSON or vanilla XML are the ones benefitting most of this. -- Markus Lanthaler @markuslanthaler From jasnell@gmail.com Wed Nov 6 11:56:36 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B689521E8175 for ; Wed, 6 Nov 2013 11:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmoJWu1fMZNc for ; Wed, 6 Nov 2013 11:56:36 -0800 (PST) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 23E3B21E80CF for ; Wed, 6 Nov 2013 11:56:36 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id wp4so10452437obc.26 for ; Wed, 06 Nov 2013 11:56:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3Gj+4yhf10hgaO3JI8d4MIpL8Z2dLOq/iIWWE75POyU=; b=1DcIZR2gBjag9oejmcz1euKJBlKTPBjM8guET4Zcdjna6dpAm7JBP/P5QR5Vb0Y1OQ RU8wXuG9cQ63EURRJeaYdsMfmxRE4lS2IFsDcrR+u3H+b3wLrwKTSkoP3NTI5gann7NN vJA8+FRM98W4KrfHdW9z8hn4luGBB3AwAYigbyq2C/iyB4zwZMHQnrGmGYRmyxSurm/1 BG2xgUq8RAtzvuS7isTEk4vm/zHysunIivo6HpbWteLIDqzIHCwS3ssoWIpEYCEN9Ul/ 4TmqT7Vrx5c/qBnfd27i6NEZFj8wvPrnSwkI9vAmvcdBC6SfQ5WHrse6SIdhPHc1YHuo LxGw== X-Received: by 10.182.246.39 with SMTP id xt7mr4073102obc.16.1383767795761; Wed, 06 Nov 2013 11:56:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.124.137 with HTTP; Wed, 6 Nov 2013 11:56:15 -0800 (PST) In-Reply-To: <527A8AF3.4000304@gmx.de> References: <5279952E.5040402@gmx.de> <527997D3.4010108@gmx.de> <527999EA.9050401@gmx.de> <527A5C23.8050201@gmx.de> <527A61E8.2050309@gmx.de> <527A74C3.3010506@gmx.de> <527A84ED.3080208@gmx.de> <527A8AF3.4000304@gmx.de> From: James M Snell Date: Wed, 6 Nov 2013 11:56:15 -0800 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Cc: Mark Nottingham , "ietf-http-wg@w3.org" , IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 19:56:36 -0000 http://www.ietf.org/id/draft-snell-link-method-07.txt Per Julian's suggestion, accommodates all target attributes, deals with 2xx response codes, handles use of the anchor attribute to override the context IRI. Also, deals with equivalence checking for IRIs. - James On Wed, Nov 6, 2013 at 10:31 AM, Julian Reschke wrote: > On 2013-11-06 10:21, James M Snell wrote: >> >> On Wed, Nov 6, 2013 at 10:05 AM, Julian Reschke >> wrote: >> [snip] >>> >>> >>> I don't see the material difference. >>> >>> If the client has no reliable way to find out what links are there it'll >>> be >>> essentially restricted to edit those that it created itself. >>> >>> It seems that this is the issue that needs to be addressed. >>> >>> >> >> This is not a problem I intend to solve... largely because I have no >> need to solve it. For one set of use cases I have, there is no need to >> discover established links, and for the remaining set, the data >> formats used already have ways of exposing whatever links the server >> wishes to expose. >> >> That said, have a concrete suggestion? > > > Maybe have a keyword for the "Prefer" header field that instructs the server > to return *all* links upon GET? > > Best regards, Julian > > From nordmark@sonic.net Tue Nov 5 17:53:07 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63EAB11E8199 for ; Tue, 5 Nov 2013 17:53:07 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Odj+0xG8fvCx for ; Tue, 5 Nov 2013 17:53:00 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id E526111E81B2 for ; Tue, 5 Nov 2013 17:52:38 -0800 (PST) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id rA61pucD007405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Nov 2013 17:51:56 -0800 Received: from [31.133.180.117] (dhcp-b475.meeting.ietf.org [31.133.180.117]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id rA61pt88028886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Nov 2013 17:51:56 -0800 Message-ID: <5279A0BC.6030506@sonic.net> Date: Tue, 05 Nov 2013 17:51:56 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Scott Brim , Hosnieh Rafiee References: <002101ceda82$f49bd4e0$ddd37ea0$@rozanak.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;xAOHBIZG4xGSO1gAt3+xLg== M;DG+NBIZG4xGSO1gAt3+xLg== X-Mailman-Approved-At: Wed, 06 Nov 2013 13:09:33 -0800 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] privacy in applications - anybody working in this area or interested? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 01:53:08 -0000 On 11/5/13 5:03 PM, Scott Brim wrote: > You've opened up a multi-layer issue here. If each application gets a > separate IID, that could make privacy more difficult, in that it could > be easier to track and correlate the behavior of applications even with > low layer encryption. Your proposal could be okay if each application > (or session, actually) could request a new IID at an arbitrary time, and > if there were a general way for sessions to let each other know this was > happening, like multihomed transport. Fun yet? Scott, I'm not sure I understand. An example of what Hosnieh and I have been talking about is an application (like a web browser) having some privacy-enhancing feature (such as incognito browsing sessions/tabs). In such a case it would seem to make sure to pick a different IPv6 IID for traffic originated due to the separate session. But the user presumably would want to make it hard to link that traffic with other traffic from the box, hence a multihomed transport (which links multiple sessions together) would seem to be the opposite of what they'd expect. Regards, Erik From nordmark@acm.org Wed Nov 6 13:13:24 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB97321E81AB for ; Wed, 6 Nov 2013 13:13:23 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gy8J76cGnARs for ; Wed, 6 Nov 2013 13:13:15 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id 9E05421E81BC for ; Wed, 6 Nov 2013 13:13:10 -0800 (PST) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id rA6LCuRs024249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Nov 2013 13:12:56 -0800 Received: from [31.133.180.117] (dhcp-b475.meeting.ietf.org [31.133.180.117]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id rA6LCtbF010224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Nov 2013 13:12:56 -0800 Message-ID: <527AB0DB.8090401@acm.org> Date: Wed, 06 Nov 2013 13:12:59 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Scott Brim References: <002101ceda82$f49bd4e0$ddd37ea0$@rozanak.com> <5279A0BC.6030506@sonic.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;VLUcNShH4xG+CVgAt3+xLg== M;3OgkNShH4xG+CVgAt3+xLg== Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] privacy in applications - anybody working in this area or interested? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 21:13:24 -0000 > A new IID used for a specific activity would stick out. A scanner would > definitely notice it - you wouldn't just slip it past - and would say > "there's something unusual here, I might benefit by paying closer > attention". If it's in a /64 with other more normal use, the scanner > would look even closer for correlations. I don't think this gives more > privacy, I think it attracts attention. It wouldn't only be for that specific activity. Instead a host would have some number of IIDs (current draft has max 10 active IIDs) and different applications will use different ones. As an IID is safe to remove the host stack can create a new one. (And if we can provide some new APIs to the stack an application can have its different sessions use different IIDs.) All of that by default - without any specific activity. The specific activity (specific session) would just pick a different IID than other activity, making it harder to link with other activities/IIDs. As long as the /64 prefix is shared by a large number of users, then the about should improve the pseudonymity. > On the other hand if I could encrypt my content and use multiple IIDs > within a single session, that would make correlating a bit more > difficult. This kind of agility requires a handshake between endpoints, > along the lines of SCTP CMT or MPTCP. Ah - now I understand the MPTCP reference. Spreading the traffic over multiple paths will potentially make traffic analysis and capturing (to decrypt) content harder. But I don't think it is required. Erik From scott.brim@gmail.com Wed Nov 6 13:21:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55C011E80E2 for ; Wed, 6 Nov 2013 13:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWBeGSgqI8MK for ; Wed, 6 Nov 2013 13:21:35 -0800 (PST) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 084EE11E8121 for ; Wed, 6 Nov 2013 13:21:34 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id wn1so98255obc.13 for ; Wed, 06 Nov 2013 13:21:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=edr9PaN9lXCIkimzEz8j+9OARCpJiirbCh7J043NTPI=; b=Mw/8RC0kX/jdAl5JY2yXx+SDIn0D8OA8W3LI1Vi6hB4z1uuI6u+y2uSaQ2xMeR7Z4W uaKxI8ruUh4YguwvDYTx7JDav0LSfG9Ha/eFs+1+xoxlRrSS3RCEharBTOPGQm4HgF6T eDet/4XecDR5fppo+k3nmR9JO17vGKxeBKvZfH9tQ1b/da8TwHzqkT4TUAPZc1toxCbq TxiZ2lurOEx0fSRZQBy3UEKI0IypYHbiaMyQrEtk4qyuP6LcjKiYZObxVc6J/QofvNRM eTYFsIZ5JcyUHBwOEDmcPhRWvGMkQ2jb/+NhwBZRdW2eT87/PDc/ZLh7EqIQUsjcMQWb 1Nyw== MIME-Version: 1.0 X-Received: by 10.182.246.39 with SMTP id xt7mr4319455obc.16.1383772892411; Wed, 06 Nov 2013 13:21:32 -0800 (PST) Received: by 10.182.2.134 with HTTP; Wed, 6 Nov 2013 13:21:32 -0800 (PST) In-Reply-To: <527AB0DB.8090401@acm.org> References: <002101ceda82$f49bd4e0$ddd37ea0$@rozanak.com> <5279A0BC.6030506@sonic.net> <527AB0DB.8090401@acm.org> Date: Wed, 6 Nov 2013 13:21:32 -0800 Message-ID: From: Scott Brim To: Erik Nordmark Content-Type: multipart/alternative; boundary=001a11c2e224b3bf3404ea88bb10 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] privacy in applications - anybody working in this area or interested? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 21:21:35 -0000 --001a11c2e224b3bf3404ea88bb10 Content-Type: text/plain; charset=ISO-8859-1 On Wednesday, November 6, 2013, Erik Nordmark wrote: > > A new IID used for a specific activity would stick out. A scanner would >> definitely notice it - you wouldn't just slip it past - and would say >> "there's something unusual here, I might benefit by paying closer >> attention". If it's in a /64 with other more normal use, the scanner >> would look even closer for correlations. I don't think this gives more >> privacy, I think it attracts attention. >> > > It wouldn't only be for that specific activity. Instead a host would have > some number of IIDs (current draft has max 10 active IIDs) and different > applications will use different ones. Just to be clear: use the same IID for all instances of a particular application? I hope not :-) > As long as the /64 prefix is shared by a large number of users, then the > about should improve the pseudonymity. > I guess I was expecting the /64 to be shared by very few. If the expected situation is a large number of users, then I withdraw my concern. > > On the other hand if I could encrypt my content and use multiple IIDs >> within a single session, that would make correlating a bit more >> difficult. This kind of agility requires a handshake between endpoints, >> along the lines of SCTP CMT or MPTCP. >> > > Ah - now I understand the MPTCP reference. > > Spreading the traffic over multiple paths will potentially make traffic > analysis and capturing (to decrypt) content harder. But I don't think it is > required. > Well, I wasn't thinking of multiple paths - I was thinking of being able to use multiple "addresses" even on a single path, as an obfuscation technique. Thanks ... Scott --001a11c2e224b3bf3404ea88bb10 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wednesday, November 6, 2013, Erik Nordmark wrote:

A new IID used for a specific activity would stick out. =A0A scanner would<= br> definitely notice it - you wouldn't just slip it past - and would say "there's something unusual here, I might benefit by paying closer<= br> attention". =A0 If it's in a /64 with other more normal use, the s= canner
would look even closer for correlations. =A0I don't think this gives mo= re
privacy, I think it attracts attention.

It wouldn't only be for that specific activity. Instead a host would ha= ve some number of IIDs (current draft has max 10 active IIDs) and different= applications will use different ones.

Just to be clear: use the same IID for all instances of a particular applic= ation? I hope not :-)
=A0
As long as the /64 prefix is shared by a large number of users, then the ab= out should improve the pseudonymity.

I = guess I was expecting the /64 to be shared by very few. =A0If the expected = situation is a large number of users, then I withdraw my concern.
=A0

On the other hand if I could encrypt my content and use multiple IIDs
within a single session, that would make correlating a bit more
difficult. =A0This kind of agility requires a handshake between endpoints,<= br> along the lines of SCTP CMT or MPTCP.

Ah - now I understand the MPTCP reference.

Spreading the traffic over multiple paths will potentially make traffic ana= lysis and capturing (to decrypt) content harder. But I don't think it i= s required.

Well, I wasn't thinking= of multiple paths - I was thinking of being able to use multiple "add= resses" even on a single path, as an obfuscation technique.

Thanks ... Scott

--001a11c2e224b3bf3404ea88bb10-- From internet-drafts@ietf.org Wed Nov 6 13:40:30 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16EF821E81B9; Wed, 6 Nov 2013 13:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGdHQdHeWSvR; Wed, 6 Nov 2013 13:40:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A73E921E81A7; Wed, 6 Nov 2013 13:39:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131106213938.20980.30376.idtracker@ietfa.amsl.com> Date: Wed, 06 Nov 2013 13:39:38 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 21:40:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : The "Require Recipient Valid Since" SMTP Service Extensi= on Author(s) : William J. Mills Murray S. Kucherawy Filename : draft-ietf-appsawg-rrvs-header-field-02.txt Pages : 9 Date : 2013-11-06 Abstract: This document defines an extension for the Simple Mail Transfer Protocol, called RRVS (for "Require Recipient Valid Since"), to provide a method for senders to indicate to receivers the time when the sender last confirmed the ownership of the target mailbox. This can be used to detect changes of mailbox ownership, and thus prevent mail from being delivered to the wrong party. The intended use of this facility is on automatically generated messages that might contain sensitive information, though it may also be useful in other applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-rrvs-header-field There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-rrvs-header-field-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-rrvs-header-field-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From superuser@gmail.com Wed Nov 6 13:45:23 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B815921E81A2 for ; Wed, 6 Nov 2013 13:45:23 -0800 (PST) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajoOG-au3dgG for ; Wed, 6 Nov 2013 13:45:23 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id D9C7F21E81CA for ; Wed, 6 Nov 2013 13:43:38 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id hm4so124740wib.0 for ; Wed, 06 Nov 2013 13:43:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=KjQrL7KtSEttajSuy5jXK5uaJl46KihGSzmnl48IR3o=; b=Uo5F9utILivfqyrom+X92W0IamGPyLZYASHoErubFYLgDo52nOOwAsJ4GnP3Qn7pZL SGSShNgB/hwUNt7IkvNIRXtEa1m287y/sQqoZV7qdvmFcFXFzmc6BswY/++hNcUIkPDQ VG0+6GnQ/HtOOSWjvHtPxRl5KcimahEQEd50CdX0OKLEMIt1JPgdZExV1D+viyqVlx0R 86wme7p5tRzJ+E5Dli/lFrZ85+56M+j2pQkWNZyCp4HlRqbo+tfKA7se7clsr+VIJ5gu KrCsULvM0I37mJlP8wvhzv6ahmuBdnbv16eyhA1dLnrx65D3gOTFT3bF9Hkld1CP3+lm nxDg== MIME-Version: 1.0 X-Received: by 10.180.79.230 with SMTP id m6mr4196647wix.19.1383774206785; Wed, 06 Nov 2013 13:43:26 -0800 (PST) Received: by 10.180.18.202 with HTTP; Wed, 6 Nov 2013 13:43:26 -0800 (PST) In-Reply-To: <20131106213938.20980.30376.idtracker@ietfa.amsl.com> References: <20131106213938.20980.30376.idtracker@ietfa.amsl.com> Date: Wed, 6 Nov 2013 13:43:26 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d044403780b81e804ea890a3f Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 21:45:23 -0000 --f46d044403780b81e804ea890a3f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 6, 2013 at 1:39 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Applications Area Working Group Working > Group of the IETF. > > Title : The "Require Recipient Valid Since" SMTP Service > Extension > Author(s) : William J. Mills > Murray S. Kucherawy > Filename : draft-ietf-appsawg-rrvs-header-field-02.txt > Pages : 9 > Date : 2013-11-06 > > Abstract: > This document defines an extension for the Simple Mail Transfer > Protocol, called RRVS (for "Require Recipient Valid Since"), to > provide a method for senders to indicate to receivers the time when > the sender last confirmed the ownership of the target mailbox. This > can be used to detect changes of mailbox ownership, and thus prevent > mail from being delivered to the wrong party. > > The intended use of this facility is on automatically generated > messages that might contain sensitive information, though it may also > be useful in other applications. > This version removes the header field altogether, leaving the SMTP extension only. The timestamp syntax has been changed to RFC3339 format, and there's been some minor wordsmithing. Ned's made an implementation based on this, and I'll be taking a run at it after I get home from this trip, though I'll also need to convince a receiver to play along. :-) Other than waiting for implementation results, are there any other changes we need to make or at least consider? -MSK --f46d044403780b81e804ea890a3f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 6, 2013 at 1:39 PM, <internet-drafts@= ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Applications Area Working Group Working= Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : The "Require Recipient Val= id Since" SMTP Service Extension
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : William J. Mills
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Murray S. Kucherawy
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-rrvs-header-fi= eld-02.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 9
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-11-06

Abstract:
=A0 =A0This document defines an extension for the Simple Mail Transfer
=A0 =A0Protocol, called RRVS (for "Require Recipient Valid Since"= ), to
=A0 =A0provide a method for senders to indicate to receivers the time when<= br> =A0 =A0the sender last confirmed the ownership of the target mailbox. =A0Th= is
=A0 =A0can be used to detect changes of mailbox ownership, and thus prevent=
=A0 =A0mail from being delivered to the wrong party.

=A0 =A0The intended use of this facility is on automatically generated
=A0 =A0messages that might contain sensitive information, though it may als= o
=A0 =A0be useful in other applications.

This version removes the header field altogether, leaving the SMTP extensi= on only.=A0 The timestamp syntax has been changed to RFC3339 format, and th= ere's been some minor wordsmithing.

Ned's made an implementation based on this, and I'll= be taking a run at it after I get home from this trip, though I'll als= o need to convince a receiver to play along.=A0 :-)

Other= than waiting for implementation results, are there any other changes we ne= ed to make or at least consider?

-MSK

--f46d044403780b81e804ea890a3f-- From superuser@gmail.com Wed Nov 6 16:48:59 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238F111E8170; Wed, 6 Nov 2013 16:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnuelMJ5JChm; Wed, 6 Nov 2013 16:48:57 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 326FC11E816D; Wed, 6 Nov 2013 16:48:57 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id ex4so4654026wid.9 for ; Wed, 06 Nov 2013 16:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LhoXC6rh4G2EAQOENjujQQie8BaMRtRK89lx2CzPRJw=; b=vBAval7/vJg4qXzC6f2BvagkvlIcMgHYVNssX9d0KICruFA7JG2EEqf39BzeN/LkGS 0Yl5Eh8SgGbewPmI2JlUBTTaATQ5WvCstj/aUHrKeLDVrlPa+cWTUCBOzesZH2y6ZO3o F6LCcOxg58noMHn1YMiJdj0shUtC7IBVS7RM52iNV702KR5iC8VOnwDu6vSiAkD6qybu URUun3uH2sSFtvE/XktaxqsJK2I4BQK8zkBPeWBlaWhPnQDxHuyrFc5ho0sPLbb1w5im idcrqlqH/9mfg7a/mRdLuiJR7AryRymBb7FKEROmn33QI+j0Nd0jok3iIAd7X36rnv0+ 6++g== MIME-Version: 1.0 X-Received: by 10.194.205.37 with SMTP id ld5mr812981wjc.67.1383785336344; Wed, 06 Nov 2013 16:48:56 -0800 (PST) Received: by 10.180.18.202 with HTTP; Wed, 6 Nov 2013 16:48:55 -0800 (PST) In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026AAEBA81@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712026AAEBA81@MX15A.corp.emc.com> Date: Wed, 6 Nov 2013 16:48:55 -0800 Message-ID: From: "Murray S. Kucherawy" To: "Black, David" Content-Type: multipart/alternative; boundary=047d7bb70c586b148c04ea8ba161 Cc: "ned.freed@mrochek.com" , "ietf@ietf.org" , "apps-discuss@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , "gshapiro@proofpoint.com" , "Barry Leiba \(barryleiba@computer.org\)" Subject: Re: [apps-discuss] Gen-ART review of draft-ietf-appsawg-malformed-mail-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 00:48:59 -0000 --047d7bb70c586b148c04ea8ba161 Content-Type: text/plain; charset=ISO-8859-1 I think I'm going to request creation of my own private Directorate. David seems to get all my Gen-ART reviews, and we could possibly do some optimizing here. :-) On Fri, Nov 1, 2013 at 6:32 PM, Black, David wrote: > > Nits/editorial comments: > > The word "naked" is used a few times to refer to something that occurs in > isolation, without enclosure in another construct, e.g., a naked CR. This > idiomatic use of "naked" should be explained before it is used. > Fixed; just used "isolated" again. > > In Section 1.1, I have always heard Postel's law as: > - Be conservative in what you send, and > - Be liberal in what you accept. > The change from "do" in this draft to "send" (above) seems useful, as > it should help focus the discussion in the second paragraph of Section > 1.1 - Postel's law, as I have understood it, has never blessed anything > remotely resembling there being "no limits to the liberties that a > sender might take." > There are a bunch of versions. See: http://en.wikipedia.org/wiki/Jon_Postel#Postel.27s_Law Some of them say "do", some say "send". Perhaps the most authoritative one is here, in Section 1.1.2: http://tools.ietf.org/html/rfc1122 It says "send". I'll make that a reference and adjust. I concur that the Law doesn't bless the extremes, but I believe the email community has (deliberately or through ignorance) gone there, which is largely the point of this work. > > Section 5's section title "Mail Submission Agents" doesn't seem to be > connected to its MHS and MTA content. It would be useful to add a > sentence to remind readers, including this one ;-), of what Mail > Submission Agents are. > The final sentence of that paragraph specifies what it does, but I see your point about the disconnect in terminology. Will adjust to tie it all together. > > Sections 7.1.* offers degrees of advice qualified by "safely", "usually", > "reasonably" and "should". There appear to be only two concepts: > - "safely": Do this all the time. > - "usually", "reasonably", "should": This is the recommended course > of action, but there may be exceptions. > While RFC 2119 is not intended for Informational documents, this is an > example of the sort of sloppiness that RFC 2119 is intended to clean up. > At the very least, the use of three words for essentially the same concept > is poor form, and RFC 2119 can be used in an Informational document when > appropriate caveats are provided in the terminology section that references > it. > Earlier versions of this draft looked roughly like an applicability statement, and thus had RFC2119 language throughout. We decided that, as you point out, it's mostly advice, and not a way of establishing a capability within Internet Mail, which would be more like what an applicability statement is for. I'm thus inclined not to backtrack, but merely satisfy your "At the very least" clause. > In Section 7.1.4, "Likewise" is not a good way to associate the second > example with the first, because it handles the missing parenthesis in a > rather different fashion (adds quotes instead of inserting the missing > parenthesis character). > Removed. > > In Section 7.7, the first use of "8bit" occurs in "8bit material" but some > of > the subsequent occurrences omit the word "material" - that word should be > used with all occurrences. > Fixed. > > idnits 2.13.00 generated a couple of warnings about obsolete references: > > -- Obsolete informational reference (is this intentional?): RFC 1113 > (ref. > 'PEM') (Obsoleted by RFC 1421) > > -- Obsolete informational reference (is this intentional?): RFC 733 > (Obsoleted by RFC 822) > > In both cases, the reference appears to be intentional, and the warning > should be ignored. > Correct; I'll make sure the AD sees this. Thanks! -MSK --047d7bb70c586b148c04ea8ba161 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think I'm going to request creation of my own privat= e Directorate.=A0 David seems to get all my Gen-ART reviews, and we could p= ossibly do some optimizing here.=A0 :-)

<= div class=3D"gmail_quote"> On Fri, Nov 1, 2013 at 6:32 PM, Black, David <david.black@emc.com&g= t; wrote:

Nits/editorial comments:

The word "naked" is used a few times to refer to something that o= ccurs in
isolation, without enclosure in another construct, e.g., a naked CR. =A0Thi= s
idiomatic use of "naked" should be explained before it is used.

Fixed; just used "isolated" ag= ain.
=A0

In Section 1.1, I have always heard Postel's law as:
=A0 =A0 =A0 =A0 - Be conservative in what you send, and
=A0 =A0 =A0 =A0 - Be liberal in what you accept.
The change from "do" in this draft to "send" (above) se= ems useful, as
it should help focus the discussion in the second paragraph of Section
1.1 - Postel's law, as I have understood it, has never blessed anything=
remotely resembling there being "no limits to the liberties that a
sender might take."

There are a bu= nch of versions.=A0 See:

http://en.wikipedia.org/wiki/Jon_Postel#Postel.27s_= Law

Some of them say "do", some say "send".= =A0 Perhaps the most authoritative one is here, in Section 1.1.2:

http://tools.ietf.org/html/rfc= 1122

It says "send".=A0 I'll make that a reference = and adjust.

I concur that the Law doesn't bless the e= xtremes, but I believe the email community has (deliberately or through ign= orance) gone there, which is largely the point of this work.
=A0

Section 5's section title "Mail Submission Agents" doesn'= t seem to be
connected to its MHS and MTA content. =A0It would be useful to add a
sentence to remind readers, including this one ;-), of what Mail
Submission Agents are.

The final senten= ce of that paragraph specifies what it does, but I see your point about the= disconnect in terminology.=A0 Will adjust to tie it all together.
=A0

Sections 7.1.* offers degrees of advice qualified by "safely", &q= uot;usually",
"reasonably" and "should". =A0There appear to be only t= wo concepts:
=A0 =A0 =A0 =A0 - "safely": Do this all the time.
=A0 =A0 =A0 =A0 - "usually", "reasonably", "should= ": This is the recommended course
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 of action, but there may be exceptions.
While RFC 2119 is not intended for Informational documents, this is an
example of the sort of sloppiness that RFC 2119 is intended to clean up. At the very least, the use of three words for essentially the same concept<= br> is poor form, and RFC 2119 can be used in an Informational document when appropriate caveats are provided in the terminology section that references=
it.

Earlier versions of this draft look= ed roughly like an applicability statement, and thus had RFC2119 language t= hroughout. =A0 We decided that, as you point out, it's mostly advice, a= nd not a way of establishing a capability within Internet Mail, which would= be more like what an applicability statement is for.

I'm thus inclined not to backtrack, but merely satisfy y= our "At the very least" clause.


In Section 7.1.4, "Likewise" is not a good way to associate the s= econd
example with the first, because it handles the missing parenthesis in a
rather different fashion (adds quotes instead of inserting the missing
parenthesis character).

Removed.
=A0=

In Section 7.7, the first use of "8bit" occurs in "8bit mate= rial" but some of
the subsequent occurrences omit the word "material" - that word s= hould be
used with all occurrences.

Fixed.
= =A0

idnits 2.13.00 generated a couple of warnings about obsolete references:
=A0 -- Obsolete informational reference (is this intentional?): RFC 1113 (r= ef.
=A0 =A0 =A0'PEM') (Obsoleted by RFC 1421)

=A0 -- Obsolete informational reference (is this intentional?): RFC =A0733<= br> =A0 =A0 =A0(Obsoleted by RFC 822)

In both cases, the reference appears to be intentional, and the warning
should be ignored.

Correct; I'll ma= ke sure the AD sees this.

Thanks!

-MSK =

--047d7bb70c586b148c04ea8ba161-- From julian.reschke@gmx.de Wed Nov 6 16:50:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212B211E8160 for ; Wed, 6 Nov 2013 16:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.249 X-Spam-Level: X-Spam-Status: No, score=-104.249 tagged_above=-999 required=5 tests=[AWL=-1.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4i5Sg+G5NJl for ; Wed, 6 Nov 2013 16:50:51 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBE111E8169 for ; Wed, 6 Nov 2013 16:50:51 -0800 (PST) Received: from [31.133.162.78] ([31.133.162.78]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lz3rc-1ViOgS2u8m-0148Lv for ; Thu, 07 Nov 2013 01:50:50 +0100 Message-ID: <527AE3E8.3000207@gmx.de> Date: Wed, 06 Nov 2013 16:50:48 -0800 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: S Moonesamy , apps-discuss@ietf.org, draft-ietf-httpbis-p5-range.all@tools.ietf.org References: <6.2.5.6.2.20131028101123.0e37a698@elandnews.com> In-Reply-To: <6.2.5.6.2.20131028101123.0e37a698@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:3B3V1Ke0z3ZTSTPsi+9fQ/rYHapfl4UipLbuICxPBcdQWIwTcRk q0QczfhAMi5S6BzJdUs4nBVVn6lyMikh278foASgY1kfbtvmlrp3ZP6uSGrn5UdL+kFV+wh mHAEZ2bewyGjcdK1HJS/0xlCsuFUau7n21AMkJ0PhG0QgKZxgyucy9FTBwdMgx+tDPbgOWO TtDVGUApLVzArYRe6badg== Cc: iesg@ietf.org, ietf-http-wg@w3.org, ietf@ietf.org Subject: [apps-discuss] #507 integer value parsing, Re: APPSDIR review of draft-ietf-httpbis-p5-range-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 00:50:56 -0000 On 2013-10-29 01:13, S Moonesamy wrote: > ... I have been selected as the Applications Area Directorate reviewer for > this draft (for background on APPSDIR, please see > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). > > > 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. > > In Section 2.1: > > "In the byte range syntax, first-byte-pos, last-byte-pos, and suffix- > length are expressed as decimal number of octets. Since there is no > predefined limit to the length of a payload, recipients ought to > anticipate potentially large decimal numerals and prevent parsing > errors due to integer conversion overflows." > > There is a RFC 2119 "should" in Section 3.3.2 of > draft-ietf-httpbis-p1-messaging-24 about integer conversion and a > reference to Section 9.3 of that draft. I may have missed integer > conversation issues in the reviews. I suggest doing a verification to > verify that there is adequate text where it is applicable. > ... We discussed this during this weeks WG meeting, and the consensus was that we want to make both instances a "MUST". The proposed change is here: Best regards, Julian From barryleiba@gmail.com Wed Nov 6 16:59:24 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B0321E81AE; Wed, 6 Nov 2013 16:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.955 X-Spam-Level: X-Spam-Status: No, score=-101.955 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWQ90I8HMIeZ; Wed, 6 Nov 2013 16:59:24 -0800 (PST) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 104DD21E8191; Wed, 6 Nov 2013 16:59:23 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id c9so300171qcz.3 for ; Wed, 06 Nov 2013 16:59:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+l61v8fQZ35q5WIVKSVv/5vGz7NuKwjU7n5MmW7WUHA=; b=asGl0wWyaWyPgblstsS9g/77E0Ej0PsknjAztnFDN1nf/rIdUjgW+nEMvIz7TcTnOk A4R80Bg33+rwfRsOMFTrsIwsWQGn4DpSg90r1BI3EPzFfdjaXgJZD3MAqkVFeABjw+0x NI2QR7UTMbuQDBriBwXXoyohcP6IhS4ePAKi7pOSfCUiXayxeStCTH5wnUnGkpe1q2qx FGMInSCdfuySRBz0sAsSnd1fQtpyKVzdM5QG9CVh/a8WUryqDTwiLDbFfmMJGoMeEGir i6Typ9LDz5oFdkmkY11w/Ju6k16ZqaRft7fRS981xnAb5w1W8DHan2scBF6vNKZrtZCa TM2w== MIME-Version: 1.0 X-Received: by 10.224.161.146 with SMTP id r18mr9764615qax.57.1383785963509; Wed, 06 Nov 2013 16:59:23 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.224.67.130 with HTTP; Wed, 6 Nov 2013 16:59:23 -0800 (PST) In-Reply-To: References: <8D3D17ACE214DC429325B2B98F3AE712026AAEBA81@MX15A.corp.emc.com> Date: Wed, 6 Nov 2013 19:59:23 -0500 X-Google-Sender-Auth: qecHh3Q5fyvyHOZIsmx_7UsQgXI Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=089e0149beeecce06104ea8bc6ec Cc: "ned.freed@mrochek.com" , "ietf@ietf.org" , "apps-discuss@ietf.org" , "Black, David" , "gshapiro@proofpoint.com" , "General Area Review Team \(gen-art@ietf.org\)" Subject: Re: [apps-discuss] Gen-ART review of draft-ietf-appsawg-malformed-mail-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 00:59:25 -0000 --089e0149beeecce06104ea8bc6ec Content-Type: text/plain; charset=ISO-8859-1 > > Sections 7.1.* offers degrees of advice qualified by "safely", "usually", > "reasonably" and "should". There appear to be only two concepts: > - "safely": Do this all the time. > - "usually", "reasonably", "should": This is the recommended course > of action, but there may be exceptions. > While RFC 2119 is not intended for Informational documents, this is an > example of the sort of sloppiness that RFC 2119 is intended to clean up. > At the very least, the use of three words for essentially the same concept > is poor form, and RFC 2119 can be used in an Informational document when > appropriate caveats are provided in the terminology section that references > it. > > Earlier versions of this draft looked roughly like an applicability statement, and thus > had RFC2119 language throughout. We decided that, as you point out, it's mostly > advice, and not a way of establishing a capability within Internet Mail, which would > be more like what an applicability statement is for. > > I'm thus inclined not to backtrack, but merely satisfy your "At the very least" clause. I'm more inclined to leave it alone: This is not conformance language at all, and isn't meant to be. It's mild advice about how one might handle bad situations. We could be consistent, and pick one word. Or we can leave the document less stilted and have it read better. We specifically don't *want* to be precise, here, about the strength or *exact* meaning of the advising words. Barry --089e0149beeecce06104ea8bc6ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sections 7.1.* offers degrees of advice qualified by "safely", &= quot;usually",
"reasonably" and "should". =A0There appear to be only t= wo concepts:
=A0 =A0 =A0 =A0 - "safely": Do this all the time.=
=A0 =A0 =A0 =A0 - "usually", "reasonably", "sh= ould": This is the recommended course
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 of action, but there may be exceptions.
= While RFC 2119 is not intended for Informational documents, this is an
e= xample of the sort of sloppiness that RFC 2119 is intended to clean up.
= At the very least, the use of three words for essentially the same concept<= br> is poor form, and RFC 2119 can be used in an Informational document whenappropriate caveats are provided in the terminology section that reference= s
it.

>=A0Earlier versions of this draft looked roughly like an appli= cability statement, and thus
>=A0had RFC2119 language throughout= . =A0 We decided that, as you point=A0 out, it's mostly
> advice= , and not a way of establishing a capability within Internet Mail, which wo= uld
>=A0be more like what an applicability statement is for.
>
>=A0I'm thus inclined not to backtrack, but merely sati= sfy your "At the very least" clause.

I'm more inclined to leave it alone:
This is not c= onformance language at all, and isn't meant to be. =A0It's mild adv= ice about how one might handle bad situations. =A0We could be consistent, a= nd pick one word. =A0Or we can leave the document less stilted and have it = read better. =A0We specifically don't *want* to be precise, here, about= the strength or *exact* meaning of the advising words.

Barry

--089e0149beeecce06104ea8bc6ec-- From gonzalo.camarillo@ericsson.com Wed Nov 6 17:07:24 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE3211E816D; Wed, 6 Nov 2013 17:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.597 X-Spam-Level: X-Spam-Status: No, score=-105.597 tagged_above=-999 required=5 tests=[AWL=0.652, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMdmFF8GgpHj; Wed, 6 Nov 2013 17:06:50 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A5F8D11E81CB; Wed, 6 Nov 2013 17:06:42 -0800 (PST) X-AuditID: c1b4fb30-b7eff8e000006d14-73-527ae79651a9 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 7C.24.27924.697EA725; Thu, 7 Nov 2013 02:06:31 +0100 (CET) Received: from [131.160.126.80] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.2.328.9; Thu, 7 Nov 2013 02:06:30 +0100 Message-ID: <527AE794.1060506@ericsson.com> Date: Wed, 6 Nov 2013 17:06:28 -0800 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Vijay K. Gurbani" References: <52432012.9070104@bell-labs.com> <52792ECE.80006@ericsson.com> <5279987E.6080803@bell-labs.com> In-Reply-To: <5279987E.6080803@bell-labs.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUyM+Jvje7051VBBh9OMFusfrmCzeLgpGCL GX8mMlvsWFNo0bBGzoHVo++yi8eU3xtZPZYs+cnk8eXyZ7YAligum5TUnMyy1CJ9uwSujP+T 5jAV3GapmLt1BVMD4ynmLkYODgkBE4mJn5W6GDmBTDGJC/fWs3UxcnEICRxilHjyciILhLOa UeLw5sfMIFW8AtoSszccYgOxWQRUJHYcXsYOYrMJWEhsuXWfBcQWFYiS2LD9AgtEvaDEyZlP wGwRAS2JiU1XmECGMgtMZZSY/f06I0hCWCBE4tON/1DbZjNKTP34F2wDp4CuxNp5jYwQ90lK bHnRDraNWUBPYsrVFkYIW15i+9s5YNcJAV23/FkLywRGoVlIls9C0jILScsCRuZVjOy5iZk5 6eXmmxiBgX1wy2+DHYyb7osdYpTmYFES5/3w1jlISCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dU A6PGLvsnH663N2j928rfWLFvBdOMdtf4E46TzfYtmv3jdl61o//2J107/7r9mZb4vzqn7oOT cNWXZL9X+TxVayZcM6nWmCPJ8ez7YSWbA1pvNY4HmDeL8SjulLZpnNNiNpf9Cwuf8lW/i/MU eopmb5Cw2bFetSmN+eRfrxvZhqfenBQ6v8/mhK4SS3FGoqEWc1FxIgC9I3y5OgIAAA== Cc: draft-ietf-insipid-session-id-reqts.all@tools.ietf.org, 'James Polk' , 'IESG IESG' , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-insipid-session-id-reqts-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 01:07:25 -0000 Hi Vijay, thanks for taking the time and having a look at the new revision. Cheers, Gonzalo On 05/11/2013 5:16 PM, Vijay K. Gurbani wrote: > On 11/05/2013 11:45 AM, Gonzalo Camarillo wrote: >> Hi Vijay, >> >> Paul has just revised the draft to address your comments (see his >> separate email about the discussions that took place within the WG). >> Could you please let us know if you are happy with the new revision? > > Gonzalo: I saw Paul's email on the insipid list. > > I am fine with the outcome. I have no further comments on the draft. > > Cheers, > > - vijay From James.H.Manger@team.telstra.com Wed Nov 6 17:15:34 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623B511E81DB for ; Wed, 6 Nov 2013 17:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.316 X-Spam-Level: X-Spam-Status: No, score=-0.316 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_55=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjGp0hlclp9O for ; Wed, 6 Nov 2013 17:15:29 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id C83E711E8213 for ; Wed, 6 Nov 2013 17:15:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,647,1378821600"; d="scan'208";a="172003847" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 07 Nov 2013 12:15:26 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7251"; a="229664647" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcavi.tcif.telstra.com.au with ESMTP; 07 Nov 2013 12:15:12 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Thu, 7 Nov 2013 12:15:11 +1100 From: "Manger, James H" To: James M Snell , Julian Reschke Date: Thu, 7 Nov 2013 12:15:11 +1100 Thread-Topic: [apps-discuss] FYI: LINK and UNLINK Thread-Index: Ac7bKlBx9RRWY9S2RqOM2yVcRq3e3wAJQbcA Message-ID: <255B9BB34FB7D647A506DC292726F6E1153607F874@WSMSG3153V.srv.dir.telstra.com> References: <5279952E.5040402@gmx.de> <527997D3.4010108@gmx.de> <527999EA.9050401@gmx.de> <527A5C23.8050201@gmx.de> <527A61E8.2050309@gmx.de> <527A74C3.3010506@gmx.de> <527A84ED.3080208@gmx.de> <527A8AF3.4000304@gmx.de> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ietf-http-wg@w3.org" , IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 01:15:34 -0000 PiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXNuZWxsLWxpbmstbWV0aG9kLTA3LnR4dA0K PiANCj4gUGVyIEp1bGlhbidzIHN1Z2dlc3Rpb24sIGFjY29tbW9kYXRlcyBhbGwgdGFyZ2V0IGF0 dHJpYnV0ZXMsIGRlYWxzDQo+IHdpdGggMnh4IHJlc3BvbnNlIGNvZGVzLCBoYW5kbGVzIHVzZSBv ZiB0aGUgYW5jaG9yIGF0dHJpYnV0ZSB0bw0KPiBvdmVycmlkZSB0aGUgY29udGV4dCBJUkkuIEFs c28sIGRlYWxzIHdpdGggZXF1aXZhbGVuY2UgY2hlY2tpbmcgZm9yDQo+IElSSXMuDQoNCg0KVGhl IHJvb3QgY2F1c2Ugb2YgdGhlIGFyZ3VtZW50cyBhYm91dCB3aGljaCBsaW5rIGF0dHJpYnV0ZXMg YXJlICJzaWduaWZpY2FudCIgaXMgdGhhdCAxIGxpbmsgc3ludGF4IGlzIGJlaW5nIHVzZWQgZm9y IDIgZGlzdGluY3QgcHVycG9zZXMuDQoNCjEuIFdpdGggdGhlIExJTksgbWV0aG9kLCBhIExpbmsg aGVhZGVyIHByb3ZpZGVzIGEgY29tcGxldGUgbGluayB0byBhZGQuDQoNCjIuIFdpdGggdGhlIFVO TElOSyBtZXRob2QsIGEgTGluayBoZWFkZXIgcHJvdmlkZXMgY3JpdGVyaWEgZm9yIG1hdGNoaW5n IGV4aXN0aW5nIGxpbmtzIHRvIHJlbW92ZS4NCiANClRoZSBMaW5rIGhlYWRlciBpcyBkZXNpZ25l ZCB0byBwcm92aWRlIGEgY29tcGxldGUgbGluay4gSXQgaXMgbm90IGRlc2lnbmVkIHRvIGNvbnZl eSBjcml0ZXJpYSBmb3IgbWF0Y2hpbmcgbGlua3MuIEl0IGNhbiBhcHByb3hpbWF0ZWx5IHNlcnZl IHRoZSBsYXR0ZXIgcHVycG9zZSBpZiB5b3UgYWRkIGEgcnVsZS4gUG9zc2libGUgcnVsZXMgYXJl Og0KQSkgImEgbGluayBtYXRjaGVzIG9ubHkgaWYgZXZlcnkgYXR0cmlidXRlIGlzIGV4YWN0bHkg dGhlIHNhbWUiOyBvcg0KQikgImEgbGluayBtYXRjaGVzIGlmIHRoZSBhdHRyaWJ1dGVzIHByb3Zp ZGVkIG1hdGNoLCByZWdhcmRsZXNzIG9mIGFueSBvdGhlciBhdHRyaWJ1dGUgaXMgaGFzIjsgb3IN CkMpICJhIGxpbmsgbWF0Y2hlcyBpZiB0aGUgdmFsdWVzIGFuZCBwcmVzZW5jZSBvZiA2IHNwZWNp ZmljIGF0dHJpYnV0ZXMgbWF0Y2ggKHJlbCwgaHJlZmxhbmcsIC4uLikiLg0KDQpBIGJldHRlciBk ZXNpZ24gd291bGQgYmUgdG8gYWNrbm93bGVkZ2UgdGhhdCBzcGVjaWZ5aW5nIGEgbGluayBhbmQg c3BlY2lmeWluZyBjcml0ZXJpYSBmb3IgbWF0Y2hpbmcgbGlua3MgYXJlIGRpZmZlcmVudCB0aGlu Z3MuIFRoYXQgY291bGQgYmUgcmVmbGVjdGVkIGJ5IGRlZmluaW5nIGFuIFVubGluayBoZWFkZXIg dG8gaG9sZCBtYXRjaGluZyBjcml0ZXJpYS4gV2UgY291bGQgZHJvcCB0aGUgVU5MSU5LIG1ldGhv ZCBhbmQganVzdCBpbmNsdWRlIExpbmsgYW5kIFVubGluayBoZWFkZXJzIHdoZW4gdXNpbmcgdGhl IExJTksgbWV0aG9kLg0KDQpUaGUgVW5saW5rIGhlYWRlciBjb3VsZCB1c2UgYSBzeW50YXggbGlr ZSBMaW5rOyBwcm9iYWJseSB3aXRoIHJ1bGUgQiAoYWxsIGF0dHJpYnV0ZSBpbiB0aGUgVW5saW5r IHZhbHVlIG11c3QgbWF0Y2gsIGJ1dCBhIGxpbmsgc3RpbGwgbWF0Y2hlcyBpZiBpdCBoYXMgYWRk aXRpb25hbCBhdHRyaWJ1dGVzKTsgcGVyaGFwcyB3aXRoIGFuIG9wdGlvbmFsIGV4dHJhPWZhbHNl IGF0dHJpYnV0ZSBtZWFuaW5nIGxpbmtzIHdpdGggYWRkaXRpb25hbCBhdHRyaWJ1dGVzIGRvIG5v dCBtYXRjaC4NCg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From internet-drafts@ietf.org Wed Nov 6 17:27:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D4A11E8202; Wed, 6 Nov 2013 17:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFgqbqI-KjBv; Wed, 6 Nov 2013 17:27:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B575911E820C; Wed, 6 Nov 2013 17:27:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131107012746.20998.82839.idtracker@ietfa.amsl.com> Date: Wed, 06 Nov 2013 17:27:46 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail-10.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 01:27:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Advice for Safe Handling of Malformed Messages Author(s) : Murray S. Kucherawy Gregory N. Shapiro N. Freed Filename : draft-ietf-appsawg-malformed-mail-10.txt Pages : 22 Date : 2013-11-06 Abstract: Although Internet mail formats have been precisely defined since the 1970s, authoring and handling software often show only mild conformance to the specifications. The malformed messages that result are non-standard. Nonetheless, decades of experience has shown that handling with some tolerance the malformations that result is often an acceptable approach, and is better than rejecting the messages outright as nonconformant. This document includes a collection of the best advice available regarding a variety of common malformed mail situations, to be used as implementation guidance. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-malformed-mail There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-malformed-mail-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-malformed-mail-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From superuser@gmail.com Wed Nov 6 17:29:10 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD42A21E8197 for ; Wed, 6 Nov 2013 17:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY9aBeoxUQ64 for ; Wed, 6 Nov 2013 17:29:10 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id D754B21E811A for ; Wed, 6 Nov 2013 17:29:09 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id c11so294736wgh.9 for ; Wed, 06 Nov 2013 17:29:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=uzlk2ZhrZ9RYoqCiLAoKHNTzY4I4akM7py1yEXhg6TQ=; b=wbU63l5JmPFcay5FThYZCjSR9CL5mWTINyVu3Q4hZIsYE9MNckhVwSj7aVwtA0VVbz 2PsIqIGCFuAHlOmxeEXdif0qRtZ8w3Pe82kV9fpS/u6t8yov+vkv3+A8BV9p3GNl+ICG KDnI2a7DG/yb9f78Q4WX3PVK87Vozb+A8fCPgzAhpmwbR7oxQ+Rk8F+OQikbsnmJHA+t YMMpQkbIgtlrtf3DoBNPHXUw+b2BtNLW7hN+h4Hcwd9SsXOSzeZAy9RDMXkBxsRHMFn/ 72PGKrN+KifyYRosQa5JnOAVA+omCT5vfBOevMQGWnRpQZjmHpoCDbU4a/IvAou+RDU4 gqiA== MIME-Version: 1.0 X-Received: by 10.180.92.100 with SMTP id cl4mr705242wib.1.1383787748943; Wed, 06 Nov 2013 17:29:08 -0800 (PST) Received: by 10.180.18.202 with HTTP; Wed, 6 Nov 2013 17:29:08 -0800 (PST) In-Reply-To: <20131107012746.20998.82839.idtracker@ietfa.amsl.com> References: <20131107012746.20998.82839.idtracker@ietfa.amsl.com> Date: Wed, 6 Nov 2013 17:29:08 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d04388e53386e5a04ea8c31c2 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail-10.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 01:29:10 -0000 --f46d04388e53386e5a04ea8c31c2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 6, 2013 at 5:27 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Applications Area Working Group Working > Group of the IETF. > > Title : Advice for Safe Handling of Malformed Messages > Author(s) : Murray S. Kucherawy > Gregory N. Shapiro > N. Freed > Filename : draft-ietf-appsawg-malformed-mail-10.txt > Pages : 22 > Date : 2013-11-06 > > Abstract: > Although Internet mail formats have been precisely defined since the > 1970s, authoring and handling software often show only mild > conformance to the specifications. The malformed messages that > result are non-standard. Nonetheless, decades of experience has > shown that handling with some tolerance the malformations that result > is often an acceptable approach, and is better than rejecting the > messages outright as nonconformant. This document includes a > collection of the best advice available regarding a variety of common > malformed mail situations, to be used as implementation guidance. > > > Response to the ops-dir and gen-art reviews after IETF Last Call. Nothing major. -MSK --f46d04388e53386e5a04ea8c31c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 6, 2013 at 5:27 PM, <internet-drafts@= ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Applications Area Working Group Working= Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Advice for Safe Handling of Mal= formed Messages
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Murray S. Kucherawy
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gregory N. Shapiro
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 N. Freed
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-malformed-mail= -10.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 22
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-11-06

Abstract:
=A0 =A0Although Internet mail formats have been precisely defined since the=
=A0 =A01970s, authoring and handling software often show only mild
=A0 =A0conformance to the specifications. =A0The malformed messages that =A0 =A0result are non-standard. =A0Nonetheless, decades of experience has =A0 =A0shown that handling with some tolerance the malformations that resul= t
=A0 =A0is often an acceptable approach, and is better than rejecting the =A0 =A0messages outright as nonconformant. =A0This document includes a
=A0 =A0collection of the best advice available regarding a variety of commo= n
=A0 =A0malformed mail situations, to be used as implementation guidance.


Response to the ops-dir and gen-ar= t reviews after IETF Last Call.=A0 Nothing major.

-MSK

--f46d04388e53386e5a04ea8c31c2-- From alexey.melnikov@isode.com Wed Nov 6 19:23:44 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D8B11E8232 for ; Wed, 6 Nov 2013 19:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.051 X-Spam-Level: X-Spam-Status: No, score=-102.051 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsU2jIZyf6qi for ; Wed, 6 Nov 2013 19:23:39 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id B27F911E813F for ; Wed, 6 Nov 2013 19:23:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1383794617; d=isode.com; s=selector; i=@isode.com; bh=HFHnl3t771xrB9dxzHXwkds1DE/sOKmpjQVvEbMYR48=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Zuij2NzmkYhV5IBkKyaJZsvLjUWpf0cqxY35RDIuef37NXbpkzP74X/WHFYQWoiR/WpZ5j llBq657ciBqsZVL/2m0IxVg9O4+JpvvP4Ln1lwtcqPEZZuUzAL6be2k3GnrSBzdFKVAsHL vwqvLPlh2ATIVEhNQKcfxZLh7SVyitY=; Received: from [31.133.165.173] (dhcp-a5ad.meeting.ietf.org [31.133.165.173]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 7 Nov 2013 03:23:37 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <527B07B8.1070103@isode.com> Date: Wed, 06 Nov 2013 19:23:36 -0800 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: apps-discuss@ietf.org References: <20131106213938.20980.30376.idtracker@ietfa.amsl.com> In-Reply-To: <20131106213938.20980.30376.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 03:23:44 -0000 On 06/11/2013 13:39, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Applications Area Working Group Working Group of the IETF. > > Title : The "Require Recipient Valid Since" SMTP Service Extension > Author(s) : William J. Mills > Murray S. Kucherawy > Filename : draft-ietf-appsawg-rrvs-header-field-02.txt > Pages : 9 > Date : 2013-11-06 Some quick comments on the latest version: 4.2. SMTP Extension Not Offered For a message being sent that includes content meant to be protected by this extension, the client MUST NOT continue to deliver a message to a server That might be nitpicking, but if a message has multiple recipients on the same server, some with the RRVS parameter and some without, I think you only want non deliver for recipients with the RRVS parameter present. The above doesn't say that. where the server does not advertise the RRVS SMTP extension. What is the error code to return? 6. Use with Mailing Lists Mailing list services can store the timestamp at which a subscriber was added to a mailing list. This specification can be used in conjunction with that information in order to restrict traffic to the original subscriber, rather than a different person now in possession of an address under which the original subscriber registered. Upon receiving a rejection caused by this specification, the list service can remove that address from further distribution. I am a bit confused about this section. You are not talking about using RRVS parameter on a mailing list address, right? Which also reminds me: should the document talk about mailing list expansions, i.e. whether the RRVS parameter should be copied for each recipient on expansion. 11.2. Enhanced Status Code Registration IANA is requested to register the following in the SMTP Enhanced Status Codes registry: Code: X.7.15 Sample Text: Mailbox owner has changed Associated basic status code: 5 Description: This status code is returned when a message is received with a Require-Recipient-Valid-Since This is still referencing the header field that you removed in -02. field and the receiving system is able to determine that the intended recipient mailbox has not been under continuous ownership since the specified date. From alexey.melnikov@isode.com Wed Nov 6 19:32:01 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BAB11E823B for ; Wed, 6 Nov 2013 19:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.187 X-Spam-Level: X-Spam-Status: No, score=-102.187 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-9MH6ymuHtZ for ; Wed, 6 Nov 2013 19:31:52 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 602D811E823C for ; Wed, 6 Nov 2013 19:31:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1383795109; d=isode.com; s=selector; i=@isode.com; bh=N2jDEXdYYrO3Q5G8pCg6bBWPuCw41ICCUVNNaNSXkCE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Tb5X1OJIUfha7H+OXRyoh/1FFe5cyLcsX/VGSTi6uyL73yGLG0VRD8TQXaWTzdOSrMcaEB +CKxihcdjsd7nk/SfmufZp7tXkPOYSLgNY/8iUT/y1D94msFVgUNIYJc7t506k4zoBQNp0 0tBTjS82OWvpNTy361LVzIXrC6cecZk=; Received: from [31.133.165.173] (dhcp-a5ad.meeting.ietf.org [31.133.165.173]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 7 Nov 2013 03:31:49 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <527B09A3.2060200@isode.com> Date: Wed, 06 Nov 2013 19:31:47 -0800 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: apps-discuss@ietf.org References: <20131106213938.20980.30376.idtracker@ietfa.amsl.com> <527B07B8.1070103@isode.com> In-Reply-To: <527B07B8.1070103@isode.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------090102000608060306090109" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 03:32:01 -0000 This is a multi-part message in MIME format. --------------090102000608060306090109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 10.1. Probing Attacks [...] Given that MSPs have chosen to allow transfers of mailbox ownership without the prior owner's involvement, the information leakage from the header field specified here creates far fewer risks than the Again, this is talking about the removed header field. potential for delivering mail to the wrong party. --------------090102000608060306090109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 10.1. Probing Attacks 
   [...]
   Given that MSPs have chosen to allow transfers of mailbox ownership
   without the prior owner's involvement, the information leakage from
   the header field specified here creates far fewer risks than the

Again, this is talking about the removed header field.

   potential for delivering mail to the wrong party.

--------------090102000608060306090109-- From duerst@it.aoyama.ac.jp Wed Nov 6 19:53:53 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9D321E80D5 for ; Wed, 6 Nov 2013 19:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.84 X-Spam-Level: X-Spam-Status: No, score=-103.84 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-13W+QqRdf5 for ; Wed, 6 Nov 2013 19:53:37 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2C81111E81B8 for ; Wed, 6 Nov 2013 19:53:33 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rA73rQS6018149; Thu, 7 Nov 2013 12:53:27 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 493e_3cdc_27eed97e_4760_11e3_b4b7_001e6722eec2; Thu, 07 Nov 2013 12:53:25 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id D7582BF545; Thu, 7 Nov 2013 12:53:25 +0900 (JST) Message-ID: <527B0EA0.40907@it.aoyama.ac.jp> Date: Thu, 07 Nov 2013 12:53:04 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Tim Bray References: <5276878A.6000802@berkeley.edu> <5278AF21.90605@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] proposal: adding profile support to JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 03:53:53 -0000 Hello Tim, On 2013/11/06 0:57, Tim Bray wrote: > Well, for example, http://www.tbray.org/tmp/draft-bray-i-json-01.html Well, I may be repeating what others have said, but: - I think this draft provides value in that somebody can point to it and=20 say "I'm accepting JSON, but only if it conforms to this" (meaning no=20 single surrogates, no duplicate object keys,...). - I think the profile parameter and the "self-identification" are total=20 overkill. They would be needed if we imagine a receiver that accepts=20 both restricted (i-json) and general (JSON) stuff, but I can't see the=20 point of doing that (except for the constructed example of a service=20 that checks which of the two it is). - If I restrict myself to accepting i-json, I have to check for problems=20 anyway, even if it comes with a profile parameter and a=20 "self-identification". So these two items don't really help. Because I don't know you as somebody who makes protocols and formats=20 needlessly complex, I'm really wondering what you think these two=20 features are good for. I hope you can explain. Regards, Martin. > On Tue, Nov 5, 2013 at 12:41 AM, "Martin J. D=C3=BCrst" > wrote: > >> Hello Erik, >> >> >> On 2013/11/04 2:27, Erik Wilde wrote: >> >>> hello. >>> >>> seeing that http://tools.ietf.org/html/draft-ietf-json-rfc4627bis is >>> making good progress, i wanted to raise the question of maybe adding >>> profile support to the JSON media type. >>> >>> http://tools.ietf.org/html/draft-wilde-atom-profile is a proposal for >>> adding profile support to the atom media type, and the "profile" >>> optional media type parameter >>> (http://tools.ietf.org/html/draft-wilde-atom-profile-02#section-4.1.1= ) >>> is what could be added to JSON as well. >>> >>> the advantage would be that different JSON-based formats could be >>> distinguished by their (mediatype+profile). this would allow JSON-bas= ed >>> formats to become more visible on the web level, instead of always ju= st >>> saying "i am JSON", without any ability to differentiate. >>> >> >> I don't understand this. JSON-based formats can be distinguished by >> registering a mime type. E.g., application/foo+json can be distinguish= ed >> from application/bar+json. If that's not what you mean, can you give s= ome >> examples of what you mean? >> >> In general, adding a parameter doesn't work very well, because the >> infrastructure (e.g. setting mechanisms on the server side,...) isn't >> developped. >> >> With respect to your atom profile proposal, it contains ideas for actu= al >> usage, but they all use "would". I think you should wait to pursue tha= t >> draft until you have an *actual* use case, i.e. an actual profile para= meter >> value. Just defining protocol slots without values isn't something tha= t's >> done in the IETF, and isn't something that makes sense to spend IETF >> resources on. >> >> Regards, Martin. >> >> thanks and cheers, >>> >>> dret. >>> >>> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > From duerst@it.aoyama.ac.jp Wed Nov 6 19:57:55 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8456621E8177 for ; Wed, 6 Nov 2013 19:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.839 X-Spam-Level: X-Spam-Status: No, score=-103.839 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QP1NQ7tSUSbM for ; Wed, 6 Nov 2013 19:57:40 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 16D1C21E8108 for ; Wed, 6 Nov 2013 19:57:39 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rA73vZNc021522; Thu, 7 Nov 2013 12:57:35 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 493a_f547_bc5c7ddc_4760_11e3_969a_001e6722eec2; Thu, 07 Nov 2013 12:57:34 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id DC76FBF545; Thu, 7 Nov 2013 12:57:34 +0900 (JST) Message-ID: <527B0F99.2000101@it.aoyama.ac.jp> Date: Thu, 07 Nov 2013 12:57:13 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Erik Wilde References: <5276878A.6000802@berkeley.edu> <5278AF21.90605@it.aoyama.ac.jp> <52793480.6010006@berkeley.edu> In-Reply-To: <52793480.6010006@berkeley.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] proposal: adding profile support to JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 03:57:55 -0000 On 2013/11/06 3:10, Erik Wilde wrote: > another existing example is > http://lists.geojson.org/pipermail/geojson-geojson.org/2013-November/th= read.html That thread seems to say that it's too difficult or tedious to register=20 a Mime media type. That's actually not the case, in particular if you=20 don't insist on a registration in the standard tree. Regards, Martin. >> On Tue, Nov 5, 2013 at 12:41 AM, "Martin J. D=C3=BCrst" >> > wrote: >> On 2013/11/04 2:27, Erik Wilde wrote: >> the advantage would be that different JSON-based formats could be >> distinguished by their (mediatype+profile). this would allow >> JSON-based >> formats to become more visible on the web level, instead of >> always just >> saying "i am JSON", without any ability to differentiate. >> >> >> I don't understand this. JSON-based formats can be distinguished by >> registering a mime type. E.g., application/foo+json can be >> distinguished from application/bar+json. If that's not what you >> mean, can you give some examples of what you mean? From duerst@it.aoyama.ac.jp Wed Nov 6 22:10:44 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C4011E8247 for ; Wed, 6 Nov 2013 22:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.837 X-Spam-Level: X-Spam-Status: No, score=-101.837 tagged_above=-999 required=5 tests=[AWL=-2.047, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eyIz9It2d1N for ; Wed, 6 Nov 2013 22:10:39 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id CF0A821E80AC for ; Wed, 6 Nov 2013 22:10:33 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id rA76AQPG008904; Thu, 7 Nov 2013 15:10:26 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 493e_ae7e_4ba76b20_4773_11e3_b4b7_001e6722eec2; Thu, 07 Nov 2013 15:10:26 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 26D16BF545; Thu, 7 Nov 2013 15:10:26 +0900 (JST) Message-ID: <527B2EB2.9080400@it.aoyama.ac.jp> Date: Thu, 07 Nov 2013 15:09:54 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Erik Wilde References: <5276878A.6000802@berkeley.edu> <5278AF21.90605@it.aoyama.ac.jp> <52793A16.8060301@berkeley.edu> In-Reply-To: <52793A16.8060301@berkeley.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] proposal: adding profile support to JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 06:10:44 -0000 On 2013/11/06 3:33, Erik Wilde wrote: > hello mark. > > On 2013-11-05, 08:59 , Mark Baker wrote: >> On Tue, Nov 5, 2013 at 10:57 AM, Tim Bray wrote: >>> Well, for example, http://www.tbray.org/tmp/draft-bray-i-json-01.html >> I'm with Martin. What that spec is trying to do with profiles is to >> supplant the typical role of a media type. If it's representative of >> what Erik has in mind for the use of a profile parameter with Atom (or >> anywhere), then I think that needs to be reconsidered too. > > i understand your concerns, but profiles do not attempt to "replace > media types", even though they could be (mis-)used to try to do just > that. Well, James just said: >>> +1. Adding support for "profile" is harmless. It can safely be ignored by anyone who feels it is unnecessary and introducing new profiles is far less complicated than getting a new media sub-type accepted. >>> which at least comes close. > [1] tries to explain the goal: they are for specializing and/or > constraining existing media types; representing both the nature of the > underlying type ("this is an atom feed and can be processed as a generic > feed") as well as the specialized/constrained profile ("this feed > carries podcast data, and can be processed as a podcast feed"). Looking at that, I see: >>>> it should be possible to have meaningful applications using the services without knowing/using the profile. specifically, for this reason it would not be a proper use of profiles to say that podcasts or OPDS are profiles of RDF or XML, because you cannot meaningfully consume podcasts or OPDS just based on on parsing RDF or XML. >>>> I don't know of meaningful JSON *applications* that would work without using a profile (or knowing what's supposed to be sent in the first place, or using a more specialized mime type). > james snell blogged about the bigger problem [2] that media types as > they are today are not a terribly well-designed concept. i think that's > correct, and profiles are just a minor "patch" in that space. what james > suggests would be much more comprehensive and much more involved, but > would affect so may parts of internet/web architecture that maybe using > profiles as a stepping stone is a useful first step. This kind of discussion comes up from time to time. Of course media types aren't perfect. But they aren't really broken, either. Regards, Martin. > cheers, > > dret. > > [1] http://dret.typepad.com/dretblog/2013/03/on-profiles.html > [2] > http://www.chmod777self.com/2012/04/more-on-future-of-mime-media-types.html > From GK@ninebynine.org Thu Nov 7 01:41:08 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF8E21E80F8 for ; Thu, 7 Nov 2013 01:41:07 -0800 (PST) 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.343, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6HPWP+5EH-Y for ; Thu, 7 Nov 2013 01:41:01 -0800 (PST) Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) by ietfa.amsl.com (Postfix) with ESMTP id 8505521E80DC for ; Thu, 7 Nov 2013 01:41:01 -0800 (PST) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1VeM5A-0004c7-cV; Thu, 07 Nov 2013 09:40:56 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1VeM5A-00006m-3u; Thu, 07 Nov 2013 09:40:56 +0000 Message-ID: <527B5C6C.6070302@ninebynine.org> Date: Thu, 07 Nov 2013 09:25:00 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: James M Snell References: <5279952E.5040402@gmx.de> <527997D3.4010108@gmx.de> <527999EA.9050401@gmx.de> <527A5C23.8050201@gmx.de> <527A61E8.2050309@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: Julian Reschke , Mark Nottingham , "ietf-http-wg@w3.org" , IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 09:41:08 -0000 On 06/11/2013 16:18, James M Snell wrote: > (btw, getting back to your earlier question about the anchor > attribute, I had honestly completely forgotten about the anchor target > attribute! I've never actually seen it used in any practical sense so > it had completely slipped my mind... to answer that particular > question, yes, the server MUST consider the anchor attribute as being > significant. I'll add a few more examples) FWIW, a recent W3C note (not standard) suggests use of anchor, intended to allow some refinement of the intended referent of a provenance link, but I don't yet know of any implementations: http://www.w3.org/TR/prov-aq/ http://www.w3.org/TR/prov-aq/#resource-accessed-by-http #g -- From GK@ninebynine.org Thu Nov 7 01:41:17 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0075C21E8164 for ; Thu, 7 Nov 2013 01:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.013 X-Spam-Level: X-Spam-Status: No, score=-6.013 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cT2iajTgKi8n for ; Thu, 7 Nov 2013 01:41:11 -0800 (PST) Received: from relay12.mail.ox.ac.uk (relay12.mail.ox.ac.uk [129.67.1.163]) by ietfa.amsl.com (Postfix) with ESMTP id 79C2021E80F8 for ; Thu, 7 Nov 2013 01:41:10 -0800 (PST) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay12.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1VeM5C-0003hd-eq; Thu, 07 Nov 2013 09:40:58 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1VeM5C-00006x-49; Thu, 07 Nov 2013 09:40:58 +0000 Message-ID: <527B5F7D.8050206@ninebynine.org> Date: Thu, 07 Nov 2013 09:38:05 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Manger, James H" , James M Snell References: <5279952E.5040402@gmx.de> <527997D3.4010108@gmx.de> <527999EA.9050401@gmx.de> <527A5C23.8050201@gmx.de> <527A61E8.2050309@gmx.de> <527A74C3.3010506@gmx.de> <527A84ED.3080208@gmx.de> <527A8AF3.4000304@gmx.de> <255B9BB34FB7D647A506DC292726F6E1153607F874@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1153607F874@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: Julian Reschke , "ietf-http-wg@w3.org" , IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 09:41:17 -0000 On 07/11/2013 01:15, Manger, James H wrote: >> http://www.ietf.org/id/draft-snell-link-method-07.txt >> >> Per Julian's suggestion, accommodates all target attributes, deals >> with 2xx response codes, handles use of the anchor attribute to >> override the context IRI. Also, deals with equivalence checking for >> IRIs. > > > The root cause of the arguments about which link attributes are "significant" is that 1 link syntax is being used for 2 distinct purposes. > > 1. With the LINK method, a Link header provides a complete link to add. > > 2. With the UNLINK method, a Link header provides criteria for matching existing links to remove. > > The Link header is designed to provide a complete link. It is not designed to convey criteria for matching links. It can approximately serve the latter purpose if you add a rule. Possible rules are: > A) "a link matches only if every attribute is exactly the same"; or > B) "a link matches if the attributes provided match, regardless of any other attribute is has"; or > C) "a link matches if the values and presence of 6 specific attributes match (rel, hreflang, ...)". > > A better design would be to acknowledge that specifying a link and specifying criteria for matching links are different things. That could be reflected by defining an Unlink header to hold matching criteria. We could drop the UNLINK method and just include Link and Unlink headers when using the LINK method. > > The Unlink header could use a syntax like Link; probably with rule B (all attribute in the Unlink value must match, but a link still matches if it has additional attributes); perhaps with an optional extra=false attribute meaning links with additional attributes do not match. I had a similar problem when reading the updated draft: it's not clear what an UNLINK actually removes. I'm uncertain about whether this is the right response, but it seems like a plausible approach to me. I kinda like the idea that it would allow links to be changed (remove+add) atomically. #g -- From julian.reschke@gmx.de Thu Nov 7 07:30:36 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812BF21E821C for ; Thu, 7 Nov 2013 07:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.241 X-Spam-Level: X-Spam-Status: No, score=-104.241 tagged_above=-999 required=5 tests=[AWL=-1.642, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mR+oFFLlsA5D for ; Thu, 7 Nov 2013 07:30:20 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 40A9421E821A for ; Thu, 7 Nov 2013 07:30:12 -0800 (PST) Received: from [31.133.151.131] ([31.133.151.131]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MMjgF-1VY75C3Tqh-008ZxE for ; Thu, 07 Nov 2013 16:30:11 +0100 Message-ID: <527BB202.4080103@gmx.de> Date: Thu, 07 Nov 2013 07:30:10 -0800 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: S Moonesamy , apps-discuss@ietf.org, draft-ietf-httpbis-p5-range.all@tools.ietf.org References: <6.2.5.6.2.20131028101123.0e37a698@elandnews.com> <527AE3E8.3000207@gmx.de> In-Reply-To: <527AE3E8.3000207@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:fFTkFpPx+uDXsfw4N1DcwPiLF0k1vHEqq917BVELAdfCVfyynlM ce+nhK8jRJ/IK/QzegZ5G+0sNPUmAP+nRYOJRFhRWyk1DJJVDl+75erWgld9i2X0XxP/bTb 8oc+Yzan60JRE8aAVr/Cbfy8tU7oDZYhaZnPBdE/nPEgGrHcojE0As7bPTItLjXYXLTL43D bv9C+4NB3+Vl5F/fafHBQ== Cc: iesg@ietf.org, ietf-http-wg@w3.org, ietf@ietf.org Subject: Re: [apps-discuss] #507 integer value parsing, Re: APPSDIR review of draft-ietf-httpbis-p5-range-24 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 15:30:36 -0000 On 2013-11-06 16:50, Julian Reschke wrote: > On 2013-10-29 01:13, S Moonesamy wrote: >> ... > > I have been selected as the Applications Area Directorate reviewer for >> this draft (for background on APPSDIR, please see >> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate >> ). >> >> >> 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. >> >> In Section 2.1: >> >> "In the byte range syntax, first-byte-pos, last-byte-pos, and suffix- >> length are expressed as decimal number of octets. Since there is no >> predefined limit to the length of a payload, recipients ought to >> anticipate potentially large decimal numerals and prevent parsing >> errors due to integer conversion overflows." >> >> There is a RFC 2119 "should" in Section 3.3.2 of >> draft-ietf-httpbis-p1-messaging-24 about integer conversion and a >> reference to Section 9.3 of that draft. I may have missed integer >> conversation issues in the reviews. I suggest doing a verification to >> verify that there is adequate text where it is applicable. >> ... > > We discussed this during this weeks WG meeting, and the consensus was > that we want to make both instances a "MUST". > > The proposed change is here: > > > Best regards, Julian ...and applied in . Best regards, Julian From mark@coactus.com Thu Nov 7 08:01:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB5921E80E8 for ; Thu, 7 Nov 2013 08:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClKz+cG-6mYu for ; Thu, 7 Nov 2013 08:01:13 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB9C11E8168 for ; Thu, 7 Nov 2013 08:01:13 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id fb1so803629pad.17 for ; Thu, 07 Nov 2013 08:01:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=V0AsXBy5NiM3gCvSSaM/cQju6qk2IUHU9GruRnCZo44=; b=ZBnRNOEUYmGBjD6E9doxaGmYLQHnouKdBdz9MM2cxvBN0KE9eoU4ipL1LmXgdV7Ock zhZe6M5jwH2wBam+rnaFlu34pLfWFQBhji6RVHhdCSBT8yHJKq92QX1Przm/iXXZ53hA 9Z41g6dUVy1fMChgbkjrROBu9NCDoXXjYu9pUjn68rih0bvcsu0OvmE8ocbqblgaMitR NDaaXlbqEX9QORr5FpYRkYfCzsyy50WR27w6lEyCNDhI7dhPw4sDiyUTu42RoGG8+dYD +UayqET5zaC9/N/exYdKqgBHu2UNyEqUya8x8swKxJ1qgRal9iB71Wg/OOLr7qG5VRY+ hSuA== X-Gm-Message-State: ALoCoQmeZCraMCmG2K0GgQlGozO2PdYralYMum//DFtoEn/5p5GYOct2UglJCi1eW4hjFRCTrbsb MIME-Version: 1.0 X-Received: by 10.68.254.105 with SMTP id ah9mr9757503pbd.87.1383840072855; Thu, 07 Nov 2013 08:01:12 -0800 (PST) Sender: mark@coactus.com Received: by 10.70.25.67 with HTTP; Thu, 7 Nov 2013 08:01:12 -0800 (PST) X-Originating-IP: [174.115.246.125] In-Reply-To: <527A8BF6.20604@berkeley.edu> References: <5276878A.6000802@berkeley.edu> <5278AF21.90605@it.aoyama.ac.jp> <52793A16.8060301@berkeley.edu> <527A8BF6.20604@berkeley.edu> Date: Thu, 7 Nov 2013 11:01:12 -0500 X-Google-Sender-Auth: rpT_NnFHtZ4q7_ejSgjzstcuWFw Message-ID: From: Mark Baker To: Erik Wilde Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] proposal: adding profile support to JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 16:01:18 -0000 Hi Erik, On Wed, Nov 6, 2013 at 1:35 PM, Erik Wilde wrote: > hello mark. > > > On 2013-11-06, 06:20 , Mark Baker wrote: >> >> I've read your RFC, and both referenced blog posts, but still find >> myself asking the same question; what problem does it solve? Yes, >> media types have their issues, but in my many years in Web development >> and standardization, I've yet to encounter a problem that didn't have >> a workable solution through the correct use of link relations and >> media types. > > > as i am sure you know, "profile" is a link relation. so what you're saying > that it's not a "correct" use of link relations? i am really just trying to > understand your perspective here. a profile media type parameter just > exposes that link relation in a special place, because it matters for the > media type, and it is more convenient to see it exposed there, instead of > first having to parse the representation. Yes, I wasn't trying to single out "profile" at all, just speak to the general utility of type/rel. >> You appear to suggest that there's value in exposing the >> existence of those OPDS extensions using an additional external >> metadata protocol element. > > > yes, because then profiles can, for example, take part in wen-level > mechanisms such as conneg, instead of being "hidden" only in the > representations. ... >> I believe that this is at best an >> optimization, since the consumer can easily detect the existence of >> the extension by inspecting the content (and understanding the >> extensibility model of the host format). > > > true for reading, not true for writing, where profiles can also indicate > what constrained media types a server is willing to accept. Ok. But AFAICT, the I-JSON draft isn't using profile=i-json as an optimization. IMO, if it needs for the "urn:ietf:i-json" key to have special meaning, media types are the only way we currently have to communicate that fact to JSON recipients (over HTTP at least). But I have to admit to not understanding the context for I-JSON's existence, not being involved in those discussions, so perhaps I'm missing something. Regardless of the specifics of that example, my general concern is that what you admit is an optimization for these types of scenarios, may be misunderstood as being something more than that (as James' suggests when he talks about it eventually replacing media types). If your claim is that the true value for profiles is elsewhere, I'd like to see a concrete proposal before we begin to standardize on protocol elements for their use. I'm personally skeptical (I'm sure you're shocked to hear this :) as I've put considerable effort into exploring this space over the years (including lots of test case code). See http://www.markbaker.ca/Talks/2004-media-types-and-compdocs/slide1-0.html which Markus might also be interested in, to explain why XML namespaces don't do what he claims. W3C members might also be interested in the strawman proposal motivated by that presentation; https://lists.w3.org/Archives/Member/member-cdf/2006Apr/0000.html From tbray@textuality.com Thu Nov 7 08:20:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E57721E8107 for ; Thu, 7 Nov 2013 08:20:21 -0800 (PST) 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.434, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjNc8ZlkK9XW for ; Thu, 7 Nov 2013 08:20:15 -0800 (PST) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id 26B1611E80DC for ; Thu, 7 Nov 2013 08:20:15 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id hv10so521767vcb.15 for ; Thu, 07 Nov 2013 08:20:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dWI8RRaHM98rAgi95me+uugivzm5Gwu1gXDXZKcsRpg=; b=HcI1hZT62wRz6znd6xE+Aqedvjq9+7AYw5gpWvEXFbj7FsGOuicZpxsSY9SX1rw9Cf EDtsSv9Ud4VP6e+mqDLrw7nD9U0vJos+RMaRCUlUb3g1/l/ZtoW8RhCnlfmhTqOgR3sV N220jfagzruTMUxEPS0xqFRwD+VWVaD90WTJY58e/VVVyEcSNxFpTgBnAEcecasKXPM8 ST0VwMl1FXtbH272xzR5HDxKSIla1EwPptQPzwA5OtLiEakobEYf4RpPANI9z+VnIHKK OU8TR/M4tipZ3cfgGWiLgpDoQRWSgv8fQP5Qw1KreQz/7EYc+eIgTIoizy3ZBqIBvO2w QkZA== X-Gm-Message-State: ALoCoQmn0mLLKiXtdCKTaqEexqTjqKIRek07QZgNk2BF3MNjBUj3G+mQM4AOkUu3ujLdfc1p17pr MIME-Version: 1.0 X-Received: by 10.52.26.69 with SMTP id j5mr6162815vdg.21.1383841214565; Thu, 07 Nov 2013 08:20:14 -0800 (PST) Received: by 10.220.110.134 with HTTP; Thu, 7 Nov 2013 08:20:14 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <527B0EA0.40907@it.aoyama.ac.jp> References: <5276878A.6000802@berkeley.edu> <5278AF21.90605@it.aoyama.ac.jp> <527B0EA0.40907@it.aoyama.ac.jp> Date: Thu, 7 Nov 2013 08:20:14 -0800 Message-ID: From: Tim Bray To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=20cf307f3246052b8a04ea98a433 Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] proposal: adding profile support to JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 16:20:21 -0000 --20cf307f3246052b8a04ea98a433 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Well, my thinking was like this. Suppose people start requiring I-JSON for some protocol or other. What we would like is to convince the authors of the existing JSON libraries to implement I-JSON mode, where they signal an error when they hit a dupe key or whatever. I suppose in most cases this would be done with a new JSONParserFactory#setIJSONMode() method, or something like that. But, speaking as the author of quite a bit of markup parsing software, the notion of putting a force-I-JSON-mode in the instance struck me as potentially useful for: - a bug-catcher - Postel=E2=80=99s-law-following receivers who want to check how careful th= ey have to be about name/value mapping, broken Unicode, etc - as it stands, you really can=E2=80=99t safely use UTF-8 conformant String#length on JSON stri= ngs in the general case. I guess I=E2=80=99m also influenced by the generally good experience with t= he XML declaration. But this is not something I=E2=80=99m passionate about, just something that= =E2=80=99s worth thinking about. -T On Wed, Nov 6, 2013 at 7:53 PM, "Martin J. D=C3=BCrst" wrote: > - I think this draft provides value in that somebody can point to it and > say "I'm accepting JSON, but only if it conforms to this" (meaning no > single surrogates, no duplicate object keys,...). > > - I think the profile parameter and the "self-identification" are total > overkill. They would be needed if we imagine a receiver that accepts both > restricted (i-json) and general (JSON) stuff, but I can't see the point o= f > doing that (except for the constructed example of a service that checks > which of the two it is). > > - If I restrict myself to accepting i-json, I have to check for problems > anyway, even if it comes with a profile parameter and a > "self-identification". So these two items don't really help. > > Because I don't know you as somebody who makes protocols and formats > needlessly complex, I'm really wondering what you think these two feature= s > are good for. I hope you can explain. > --20cf307f3246052b8a04ea98a433 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well, my thinking was like this. Suppose people start= requiring I-JSON for some protocol or other. =C2=A0What we would like is t= o convince the authors of the existing JSON libraries to implement I-JSON m= ode, where they signal an error when they hit a dupe key or whatever. =C2= =A0I suppose in most cases this would be done with a new JSONParserFactory#= setIJSONMode() method, or something like that. =C2=A0

But, speaking as the author of quite a bit of markup pa= rsing software, the notion of putting a force-I-JSON-mode in the instance s= truck me as potentially useful for:
- a bug-catcher
- Postel=E2=80=99s-law-following receivers who want to check how careful th= ey have to be about name/value mapping, broken Unicode, etc - as it stands,= you really can=E2=80=99t safely use UTF-8 conformant String#length on JSON= strings in the general case.

I guess I=E2=80=99m also influenced by the generally go= od experience with the XML declaration.=C2=A0

But = this is not something I=E2=80=99m passionate about, just something that=E2= =80=99s worth thinking about. -T


On Wed, Nov 6, 2013 at 7:53 PM, "Martin = J. D=C3=BCrst" <duerst@it.aoyama.ac.jp> wrote:
=
- I think this dr= aft provides value in that somebody can point to it and say "I'm a= ccepting JSON, but only if it conforms to this" (meaning no single sur= rogates, no duplicate object keys,...).

- I think the profile parameter and the "self-identification" are= total overkill. They would be needed if we imagine a receiver that accepts= both restricted (i-json) and general (JSON) stuff, but I can't see the= point of doing that (except for the constructed example of a service that = checks which of the two it is).

- If I restrict myself to accepting i-json, I have to check for problems an= yway, even if it comes with a profile parameter and a "self-identifica= tion". So these two items don't really help.

Because I don't know you as somebody who makes protocols and formats ne= edlessly complex, I'm really wondering what you think these two feature= s are good for. I hope you can explain.
--20cf307f3246052b8a04ea98a433-- From jasnell@gmail.com Thu Nov 7 08:29:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24DA21E8116 for ; Thu, 7 Nov 2013 08:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CLv3KE-8roX for ; Thu, 7 Nov 2013 08:29:18 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3284F11E81E6 for ; Thu, 7 Nov 2013 08:29:17 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id gq1so279069obb.2 for ; Thu, 07 Nov 2013 08:29:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=4r5EaBNuC5JPWYrL77LF0T0KZsEShejQJe9yjGhaLDo=; b=YL+sxFI1MEUmXeWHIn8MtrSN9gnQFWA71H37dd94hnv96fvZMEmCs0UF4zalkhc3WA M/iBVz855TJ53+z6Wxh+io1przJZt9rtAkCHy8AapPyekusCh6HgCWEzavAFK8IPYD0j eUOlqlz9DSYCI2oOJO+d2AcNdPAqsEhl1sGh/S6rApspvSKd8UogiHeZDd16pzn6pzhW ZzQEOqlo6U3/ZEl2ZtQ5z0iz3Ed/GtPvYYXoVpM1K/fCGqY7P2u4knbRaH32u4g3lrbu +tu+vIJNO78sqL886wioaH3Pxczek0d5iFccc6zIhrNxN6biJAEXMCtGpoCCKDGrqNxo aRKA== X-Received: by 10.182.243.138 with SMTP id wy10mr483070obc.83.1383841757462; Thu, 07 Nov 2013 08:29:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.124.137 with HTTP; Thu, 7 Nov 2013 08:28:57 -0800 (PST) In-Reply-To: References: <5276878A.6000802@berkeley.edu> <5278AF21.90605@it.aoyama.ac.jp> <527B0EA0.40907@it.aoyama.ac.jp> From: James M Snell Date: Thu, 7 Nov 2013 08:28:57 -0800 Message-ID: To: Tim Bray Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] proposal: adding profile support to JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 16:29:18 -0000 On Thu, Nov 7, 2013 at 8:20 AM, Tim Bray wrote: > [snip] > But, speaking as the author of quite a bit of markup parsing software, th= e > notion of putting a force-I-JSON-mode in the instance struck me as > potentially useful for: > - a bug-catcher > - Postel=E2=80=99s-law-following receivers who want to check how careful = they have > to be about name/value mapping, broken Unicode, etc - as it stands, you > really can=E2=80=99t safely use UTF-8 conformant String#length on JSON st= rings in > the general case. > > I guess I=E2=80=99m also influenced by the generally good experience with= the XML > declaration. > Just as an aside, using HTTP Prefer's handling=3Dstrict vs. handling=3Dlenient would also be a great way of toggling whether or not to optionally apply an I-JSON parsing mode. - James > But this is not something I=E2=80=99m passionate about, just something th= at=E2=80=99s worth > thinking about. -T > > > On Wed, Nov 6, 2013 at 7:53 PM, "Martin J. D=C3=BCrst" > wrote: >> >> - I think this draft provides value in that somebody can point to it and >> say "I'm accepting JSON, but only if it conforms to this" (meaning no si= ngle >> surrogates, no duplicate object keys,...). >> >> - I think the profile parameter and the "self-identification" are total >> overkill. They would be needed if we imagine a receiver that accepts bot= h >> restricted (i-json) and general (JSON) stuff, but I can't see the point = of >> doing that (except for the constructed example of a service that checks >> which of the two it is). >> >> - If I restrict myself to accepting i-json, I have to check for problems >> anyway, even if it comes with a profile parameter and a >> "self-identification". So these two items don't really help. >> >> Because I don't know you as somebody who makes protocols and formats >> needlessly complex, I'm really wondering what you think these two featur= es >> are good for. I hope you can explain. > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From david.black@emc.com Wed Nov 6 17:01:46 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A2121E8198; Wed, 6 Nov 2013 17:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.229 X-Spam-Level: X-Spam-Status: No, score=-102.229 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztA9+bJr5FOf; Wed, 6 Nov 2013 17:01:41 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id B62BA21E80EC; Wed, 6 Nov 2013 17:01:38 -0800 (PST) Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rA711T70006223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Nov 2013 20:01:30 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com rA711T70006223 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1383786090; bh=WHL2MzeR9v4Tv18YRS5rBy/J180=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=uX8xAJGiaJmjZX524Ox7r4PTO/u9BGkkf2lbwIaB9vUy1s3wrcoXmibrvTd3VCbtV g8NbMhDpgysLDbFVxNNvzf8CA2BSA00pTv5tirepPU9FG2SIcBUKjgRKBYUwMFLbuI 1OlG/eLSXQZ+uLTlqBE0FuFcGqYDc9giF0AHk+Yo= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com rA711T70006223 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd56.lss.emc.com (RSA Interceptor); Wed, 6 Nov 2013 20:01:18 -0500 Received: from mxhub23.corp.emc.com (mxhub23.corp.emc.com [128.222.70.135]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rA711H4i009904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Nov 2013 20:01:18 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub23.corp.emc.com ([128.222.70.135]) with mapi; Wed, 6 Nov 2013 20:01:17 -0500 From: "Black, David" To: "Murray S. Kucherawy" Date: Wed, 6 Nov 2013 20:01:16 -0500 Thread-Topic: Gen-ART review of draft-ietf-appsawg-malformed-mail-09 Thread-Index: Ac7bUydFVQjFko0GRkSYwd3I4YhRegAACcGQ Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026AAEC093@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE712026AAEBA81@MX15A.corp.emc.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: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE712026AAEC093MX15Acorpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: public X-Mailman-Approved-At: Thu, 07 Nov 2013 08:43:55 -0800 Cc: "ned.freed@mrochek.com" , "ietf@ietf.org" , "apps-discuss@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , "gshapiro@proofpoint.com" , "Barry Leiba \(barryleiba@computer.org\)" , "Black, David" Subject: Re: [apps-discuss] Gen-ART review of draft-ietf-appsawg-malformed-mail-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 01:01:46 -0000 --_000_8D3D17ACE214DC429325B2B98F3AE712026AAEC093MX15Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > I think I'm going to request creation of my own private Directorate. Dav= id seems to get all my Gen-ART reviews, > and we could possibly do some optimizing here. :-) Luck of the draw :). All of your suggestions are fine, and in Section 7.1.*, picking a single wo= rd for "usually", "reasonably" and "should" will definitely suffice - I mig= ht suggest scanning the rest of section 7 for consistent use of terminology= to express levels of recommendations. Thanks, --David From: Murray S. Kucherawy [mailto:superuser@gmail.com] Sent: Wednesday, November 06, 2013 7:49 PM To: Black, David Cc: gshapiro@proofpoint.com; ned.freed@mrochek.com; General Area Review Tea= m (gen-art@ietf.org); Barry Leiba (barryleiba@computer.org); apps-discuss@i= etf.org; ietf@ietf.org Subject: Re: Gen-ART review of draft-ietf-appsawg-malformed-mail-09 I think I'm going to request creation of my own private Directorate. David= seems to get all my Gen-ART reviews, and we could possibly do some optimiz= ing here. :-) On Fri, Nov 1, 2013 at 6:32 PM, Black, David > wrote: Nits/editorial comments: The word "naked" is used a few times to refer to something that occurs in isolation, without enclosure in another construct, e.g., a naked CR. This idiomatic use of "naked" should be explained before it is used. Fixed; just used "isolated" again. In Section 1.1, I have always heard Postel's law as: - Be conservative in what you send, and - Be liberal in what you accept. The change from "do" in this draft to "send" (above) seems useful, as it should help focus the discussion in the second paragraph of Section 1.1 - Postel's law, as I have understood it, has never blessed anything remotely resembling there being "no limits to the liberties that a sender might take." There are a bunch of versions. See: http://en.wikipedia.org/wiki/Jon_Postel#Postel.27s_Law Some of them say "do", some say "send". Perhaps the most authoritative one= is here, in Section 1.1.2: http://tools.ietf.org/html/rfc1122 It says "send". I'll make that a reference and adjust. I concur that the Law doesn't bless the extremes, but I believe the email c= ommunity has (deliberately or through ignorance) gone there, which is large= ly the point of this work. Section 5's section title "Mail Submission Agents" doesn't seem to be connected to its MHS and MTA content. It would be useful to add a sentence to remind readers, including this one ;-), of what Mail Submission Agents are. The final sentence of that paragraph specifies what it does, but I see your= point about the disconnect in terminology. Will adjust to tie it all toge= ther. Sections 7.1.* offers degrees of advice qualified by "safely", "usually", "reasonably" and "should". There appear to be only two concepts: - "safely": Do this all the time. - "usually", "reasonably", "should": This is the recommended course of action, but there may be exceptions. While RFC 2119 is not intended for Informational documents, this is an example of the sort of sloppiness that RFC 2119 is intended to clean up. At the very least, the use of three words for essentially the same concept is poor form, and RFC 2119 can be used in an Informational document when appropriate caveats are provided in the terminology section that references it. Earlier versions of this draft looked roughly like an applicability stateme= nt, and thus had RFC2119 language throughout. We decided that, as you poi= nt out, it's mostly advice, and not a way of establishing a capability with= in Internet Mail, which would be more like what an applicability statement = is for. I'm thus inclined not to backtrack, but merely satisfy your "At the very le= ast" clause. In Section 7.1.4, "Likewise" is not a good way to associate the second example with the first, because it handles the missing parenthesis in a rather different fashion (adds quotes instead of inserting the missing parenthesis character). Removed. In Section 7.7, the first use of "8bit" occurs in "8bit material" but some = of the subsequent occurrences omit the word "material" - that word should be used with all occurrences. Fixed. idnits 2.13.00 generated a couple of warnings about obsolete references: -- Obsolete informational reference (is this intentional?): RFC 1113 (ref= . 'PEM') (Obsoleted by RFC 1421) -- Obsolete informational reference (is this intentional?): RFC 733 (Obsoleted by RFC 822) In both cases, the reference appears to be intentional, and the warning should be ignored. Correct; I'll make sure the AD sees this. Thanks! -MSK --_000_8D3D17ACE214DC429325B2B98F3AE712026AAEC093MX15Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> I think = I'm going to request creation of my own private Directorate.  David se= ems to get all my Gen-ART reviews,

> = and we could possibly do some optimizing here.  :-)

 

Luck of the draw J= .

 

All of your suggestions are fine, and in Section 7.1.*, picking a= single word for “usually”, “reasonably” and “= ;should” will definitely suffice – I might suggest scanning the= rest of section 7 for consistent use of terminology to express levels of r= ecommendations.

 

Thanks,
--David

 

From: Murray S. Kucherawy [mailto:superuser@gmail.com]
= Sent: Wednesday, November 06, 2013 7:49 PM
To: Black, DavidCc: gshapiro@proofpoint.com; ned.freed@mrochek.com; General Area R= eview Team (gen-art@ietf.org); Barry Leiba (barryleiba@computer.org); apps-= discuss@ietf.org; ietf@ietf.org
Subject: Re: Gen-ART review of dr= aft-ietf-appsawg-malformed-mail-09

 

I think I'm go= ing to request creation of my own private Directorate.  David seems to= get all my Gen-ART reviews, and we could possibly do some optimizing here.=   :-)

 

On Fri, Nov 1, 2013 at 6:32 PM, Black, David <david.black@emc.com> wrote:


Nits/editorial comment= s:

The word "naked" is used a few times to refer to someth= ing that occurs in
isolation, without enclosure in another construct, e.= g., a naked CR.  This
idiomatic use of "naked" should be = explained before it is used.


In Section 1.1, I have alw= ays heard Postel's law as:
        - Be conservative= in what you send, and
        - Be liberal in what = you accept.
The change from "do" in this draft to "send&q= uot; (above) seems useful, as
it should help focus the discussion in the= second paragraph of Section
1.1 - Postel's law, as I have understood it= , has never blessed anything
remotely resembling there being "no li= mits to the liberties that a
sender might take."

Some= of them say "do", some say "send".  Perhaps the m= ost authoritative one is here, in Section 1.1.2:

http://tools.ietf.org/html/rfc1122

It say= s "send".  I'll make that a reference and adjust.=

I concur that the Law doesn't bless the= extremes, but I believe the email community has (deliberately or through i= gnorance) gone there, which is largely the point of this work.

 


Section 5's = section title "Mail Submission Agents" doesn't seem to be
conn= ected to its MHS and MTA content.  It would be useful to add a
sent= ence to remind readers, including this one ;-), of what Mail
Submission = Agents are.

 = ;

The final sentence of that parag= raph specifies what it does, but I see your point about the disconnect in t= erminology.  Will adjust to tie it all together.
 <= /p>


Sections 7.1.* offers degrees of advice qualified by "safel= y", "usually",
"reasonably" and "should&qu= ot;.  There appear to be only two concepts:
      &n= bsp; - "safely": Do this all the time.
      &n= bsp; - "usually", "reasonably", "should": Thi= s is the recommended course
            &n= bsp;   of action, but there may be exceptions.
While RFC 2119 is no= t intended for Informational documents, this is an
example of the sort o= f sloppiness that RFC 2119 is intended to clean up.
At the very least, t= he use of three words for essentially the same concept
is poor form, and= RFC 2119 can be used in an Informational document when
appropriate cave= ats are provided in the terminology section that references
it.

 

Earlier versions of t= his draft looked roughly like an applicability statement, and thus had RFC2= 119 language throughout.   We decided that, as you point out, it's mos= tly advice, and not a way of establishing a capability within Internet Mail= , which would be more like what an applicability statement is for.

I'm th= us inclined not to backtrack, but merely satisfy your "At the very lea= st" clause.


In Section 7.1.4, "Likewise&quo= t; is not a good way to associate the second
example with the first, bec= ause it handles the missing parenthesis in a
rather different fashion (a= dds quotes instead of inserting the missing
parenthesis character).=

 

Removed.
 


In Sect= ion 7.7, the first use of "8bit" occurs in "8bit material&qu= ot; but some of
the subsequent occurrences omit the word "material&= quot; - that word should be
used with all occurrences.

 

Fixed.
 


idnits 2.13.00 generat= ed a couple of warnings about obsolete references:

  -- Obsolet= e informational reference (is this intentional?): RFC 1113 (ref.
  =    'PEM') (Obsoleted by RFC 1421)

  -- Obsolete infor= mational reference (is this intentional?): RFC  733
    &= nbsp;(Obsoleted by RFC 822)

In both cases, the reference appears to = be intentional, and the warning
should be ignored.

 

Correct; I'll make sure the AD see= s this.

Thanks!

-MSK <= /o:p>

 

=
= --_000_8D3D17ACE214DC429325B2B98F3AE712026AAEC093MX15Acorpemcc_-- From blueroofmusic@gmail.com Thu Nov 7 08:44:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B90D21E81C3 for ; Thu, 7 Nov 2013 08:44:46 -0800 (PST) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4kpTVygKVee for ; Thu, 7 Nov 2013 08:44:44 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0638F11E825F for ; Thu, 7 Nov 2013 08:43:38 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id u16so1253197iet.35 for ; Thu, 07 Nov 2013 08:43:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=ZyXRe900iTYGXdbqIgM57mvvO+uvPAG1ME0vHxgO4w8=; b=EfeCGEtRiMf1d6gXmxuMAomNiiAkmDUn8giDGWEcIpIHKPqu361Ekevlo3OEmVN3LI nJsB3FX/vYo4CKMCCwDJo4drVi3FJXkI2+yLmZRUSl0YsVGSxvWJ/LW5EH8JG8oEOcfw 2KTh/tghosHv5mtvkSPg7nJmPNXybRpa0XtCzIgM7r0kkQMA+BVPS+adW5DKpW6z17+O /SrbCapgV7Rbm/yYl50Dw/LVPlOcTZ1DUpAQS2J2uq/Et9faqqE9kUVMmgsYLhGPq9C+ f9F0kRJ6JwdTqb2xLZU+wrMt+IJJYddLXNIF62+5gKjw2Lwu/uSRascF4YqstiJlL72c 3S9A== X-Received: by 10.50.55.65 with SMTP id q1mr2720767igp.4.1383842611328; Thu, 07 Nov 2013 08:43:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.96.135 with HTTP; Thu, 7 Nov 2013 08:43:11 -0800 (PST) From: Ira McDonald Date: Thu, 7 Nov 2013 11:43:11 -0500 Message-ID: To: "apps-discuss@ietf.org" , Ira McDonald Content-Type: multipart/alternative; boundary=047d7b10c8074649ba04ea98f77a Subject: [apps-discuss] Fwd: New version of draft-mcdonald-ipps-uri-scheme-09.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 16:44:47 -0000 --047d7b10c8074649ba04ea98f77a Content-Type: text/plain; charset=ISO-8859-1 Hi, Sections rearranged and various technical edits (mainly to expand Security Considerations) - please see change history for details. Thanks especially to Tom Petch for some good comments. Cheers, - Ira (PWG Secretary, PWG IPP WG co-chair) Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 ---------- Forwarded message ---------- From: Date: Tue, Nov 5, 2013 at 4:40 PM Subject: New Version Notification for draft-mcdonald-ipps-uri-scheme-09.txt To: Michael Sweet , Ira McDonald A new version of I-D, draft-mcdonald-ipps-uri-scheme-09.txt has been successfully submitted by Ira McDonald and posted to the IETF repository. Filename: draft-mcdonald-ipps-uri-scheme Revision: 09 Title: IPP over HTTPS Transport Binding and 'ipps' URI Scheme Creation date: 2013-11-05 Group: Individual Submission Number of pages: 27 URL: http://www.ietf.org/internet-drafts/draft-mcdonald-ipps-uri-scheme-09.txt Status: http://datatracker.ietf.org/doc/draft-mcdonald-ipps-uri-scheme Htmlized: http://tools.ietf.org/html/draft-mcdonald-ipps-uri-scheme-09 Diff: http://www.ietf.org/rfcdiff?url2=draft-mcdonald-ipps-uri-scheme-09 Abstract: This memo defines the Internet Printing Protocol (IPP) over HTTPS transport binding and the corresponding 'ipps' URI scheme, that is used to designate the access to the network location of a secure IPP print service or a network resource (for example, a print job) managed by such a service. This memo is an individual submission to the IETF by the Internet Printing Protocol Working Group of the IEEE-ISTO Printer Working Group, as part of their PWG IPP Everywhere (PWG 5100.14) project for secure mobile printing with vendor-neutral Client software. This memo defines an alternate IPP transport binding to that defined in the original IPP URL Scheme (RFC 3510), but this memo does not update or obsolete (RFC 3510). This memo updates RFC 2910 and RFC 2911. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --047d7b10c8074649ba04ea98f77a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Sections re= arranged and various technical edits (mainly
to expand Security C= onsiderations) - please see change
history for details.

Thanks especially to Tom Petch for some good comments.

Cheers,=
- Ira (PWG Secretary, PWG IPP WG co-chair)

<= div>
Ira McDonald (Musician / Softwa= re Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer = Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted = Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF D= esignated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites= .google.com/site/blueroofmusic
http://si= tes.google.com/site/highnorthinc
mailto:blueroo= fmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 = 734-944-0094
Summer=A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2= 434



---------- Forwarded message ----------<= br>From: <internet-drafts@ietf.org>
Date: Tue, Nov 5, 2013 at 4:40 PM
Subject: New Version Notification for = draft-mcdonald-ipps-uri-scheme-09.txt
To: Michael Sweet <msweet@apple.com>, Ira McDonald <blueroofmusic@gmail.com>



A new version of I-D, draft-mcdonald-ipps-uri-scheme-09.txt
has been successfully submitted by Ira McDonald and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-mcdonald-ipps-uri-scheme
Revision: =A0 =A0 =A0 =A009
Title: =A0 =A0 =A0 =A0 =A0 IPP over HTTPS Transport Binding and 'ipps&#= 39; URI Scheme
Creation date: =A0 2013-11-05
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 27
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.o= rg/internet-drafts/draft-mcdonald-ipps-uri-scheme-09.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/do= c/draft-mcdonald-ipps-uri-scheme
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-m= cdonald-ipps-uri-scheme-09
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rf= cdiff?url2=3Ddraft-mcdonald-ipps-uri-scheme-09

Abstract:
=A0 =A0This memo defines the Internet Printing Protocol (IPP) over HTTPS =A0 =A0transport binding and the corresponding 'ipps' URI scheme, t= hat is
=A0 =A0used to designate the access to the network location of a secure IPP=
=A0 =A0print service or a network resource (for example, a print job)
=A0 =A0managed by such a service.

=A0 =A0This memo is an individual submission to the IETF by the Internet =A0 =A0Printing Protocol Working Group of the IEEE-ISTO Printer Working
=A0 =A0Group, as part of their PWG IPP Everywhere (PWG 5100.14) project for=
=A0 =A0secure mobile printing with vendor-neutral Client software.

=A0 =A0This memo defines an alternate IPP transport binding to that defined=
=A0 =A0in the original IPP URL Scheme (RFC 3510), but this memo does not =A0 =A0update or obsolete (RFC 3510).

=A0 =A0This memo updates RFC 2910 and RFC 2911.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--047d7b10c8074649ba04ea98f77a-- From jasnell@gmail.com Thu Nov 7 08:54:09 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEB711E80DC for ; Thu, 7 Nov 2013 08:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paK5IgVZrj43 for ; Thu, 7 Nov 2013 08:54:08 -0800 (PST) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4C79321E81C2 for ; Thu, 7 Nov 2013 08:52:33 -0800 (PST) Received: by mail-oa0-f43.google.com with SMTP id m1so1199888oag.16 for ; Thu, 07 Nov 2013 08:52:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=qKGenc4Thg5f6vIv0mRH2tWubEeZbTlsCKL1FVgggbY=; b=yzAZJh4TgFLxuea10hzP0qdbK0RZDT4Z+S6ZeMRuyu8H4ukuS/r5LBpg5WAD4LMOoU GnJaRQXhEg4DA9E8jnvYpcjk7Y5WTC3Ft5TJP52AGLbukgHY/79aJ8ejicM8PdDu7mQN K8mWSMNBiIL/w3C311bX+rG7mF6msiuItzXv25BbGtEG7sIMP6fSqxnJYJf54hUqCnKx 3pnn6+LU7QWBolNmrkxKXtdw+6H+S2TzxOx6xC6fdcNUCIcTJYPOXEut144ZfoI+t2MZ T6aR5VEAOa3sJr06cZaNmiaSrLmZTbgN56e0f7oIWosh9Hc774vPjkVK28H+Tl9oHkGU zPjw== X-Received: by 10.60.33.74 with SMTP id p10mr7375144oei.18.1383843152765; Thu, 07 Nov 2013 08:52:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.124.137 with HTTP; Thu, 7 Nov 2013 08:52:12 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1153607F874@WSMSG3153V.srv.dir.telstra.com> References: <5279952E.5040402@gmx.de> <527997D3.4010108@gmx.de> <527999EA.9050401@gmx.de> <527A5C23.8050201@gmx.de> <527A61E8.2050309@gmx.de> <527A74C3.3010506@gmx.de> <527A84ED.3080208@gmx.de> <527A8AF3.4000304@gmx.de> <255B9BB34FB7D647A506DC292726F6E1153607F874@WSMSG3153V.srv.dir.telstra.com> From: James M Snell Date: Thu, 7 Nov 2013 08:52:12 -0800 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Julian Reschke , "ietf-http-wg@w3.org" , IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 16:54:09 -0000 Definitely appreciate the feedback but I'm definitely -1 on the idea of inventing a new "Unlink" request header. It's just not necessary. I also don't believe matching rules are required. The UNLINK will match if all the attributes provided match all the attributes of an established link. It doesn't need to be more complicated than that. On Wed, Nov 6, 2013 at 5:15 PM, Manger, James H wrote: >> http://www.ietf.org/id/draft-snell-link-method-07.txt >> >> Per Julian's suggestion, accommodates all target attributes, deals >> with 2xx response codes, handles use of the anchor attribute to >> override the context IRI. Also, deals with equivalence checking for >> IRIs. > > > The root cause of the arguments about which link attributes are "signific= ant" is that 1 link syntax is being used for 2 distinct purposes. > > 1. With the LINK method, a Link header provides a complete link to add. > > 2. With the UNLINK method, a Link header provides criteria for matching e= xisting links to remove. > > The Link header is designed to provide a complete link. It is not designe= d to convey criteria for matching links. It can approximately serve the lat= ter purpose if you add a rule. Possible rules are: > A) "a link matches only if every attribute is exactly the same"; or > B) "a link matches if the attributes provided match, regardless of any ot= her attribute is has"; or > C) "a link matches if the values and presence of 6 specific attributes ma= tch (rel, hreflang, ...)". > > A better design would be to acknowledge that specifying a link and specif= ying criteria for matching links are different things. That could be reflec= ted by defining an Unlink header to hold matching criteria. We could drop t= he UNLINK method and just include Link and Unlink headers when using the LI= NK method. > > The Unlink header could use a syntax like Link; probably with rule B (all= attribute in the Unlink value must match, but a link still matches if it h= as additional attributes); perhaps with an optional extra=3Dfalse attribute= meaning links with additional attributes do not match. > > > -- > James Manger From david.black@emc.com Wed Nov 6 19:04:43 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DAC11E8163; Wed, 6 Nov 2013 19:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaAY7GFz8FOG; Wed, 6 Nov 2013 19:04:39 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3870111E813F; Wed, 6 Nov 2013 19:04:38 -0800 (PST) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rA734Yn5010121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Nov 2013 22:04:34 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com rA734Yn5010121 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1383793475; bh=98QhQO0HAPlaPt0E7pnNg1RXMuk=; h=From:To:CC:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=lnx2pW94Xr1zZNqTpDdpuWZMHsOMiWI0nuHOUrHJki2mlQUIt3Wd12ghrMjiJ1PxB jNO0KrDmgA+VQwgHwuNjYjQdKFVEWrxeSo0bXeOMdlW/pLWAc352vjqilvFFbhHWE6 A+yj2YcGD++DVM1HQ2eLp7+h+QNZArZ6jz2dgohM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com rA734Yn5010121 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd04.lss.emc.com (RSA Interceptor); Wed, 6 Nov 2013 19:04:25 -0800 Received: from mxhub04.corp.emc.com (mxhub04.corp.emc.com [10.254.141.106]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rA734OpP008413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Nov 2013 22:04:24 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub04.corp.emc.com ([10.254.141.106]) with mapi; Wed, 6 Nov 2013 22:04:23 -0500 From: "Black, David" To: "Murray S. Kucherawy (superuser@gmail.com)" , "gshapiro@proofpoint.com" , "ned.freed@mrochek.com" , "General Area Review Team (gen-art@ietf.org)" Date: Wed, 6 Nov 2013 22:04:21 -0500 Thread-Topic: Gen-ART review of draft-ietf-appsawg-malformed-mail-10 Thread-Index: Ac7bZg6Td4Q7e59VSPaRLIgP5ahDXg== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026AAEC0AC@MX15A.corp.emc.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public, Resumes X-Mailman-Approved-At: Thu, 07 Nov 2013 08:58:02 -0800 Cc: "Black, David" , "Barry Leiba \(barryleiba@computer.org\)" , "ietf@ietf.org" , "apps-discuss@ietf.org" Subject: [apps-discuss] Gen-ART review of draft-ietf-appsawg-malformed-mail-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 03:04:43 -0000 The -10 version of this draft responds to all of the nits/editorial comment= s noted in the Gen-ART review of the -09 version. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Friday, November 01, 2013 9:32 PM > To: Murray S. Kucherawy (superuser@gmail.com); gshapiro@proofpoint.com; > ned.freed@mrochek.com; General Area Review Team (gen-art@ietf.org) > Cc: Black, David; Barry Leiba (barryleiba@computer.org); apps- > discuss@ietf.org; ietf@ietf.org > Subject: Gen-ART review of draft-ietf-appsawg-malformed-mail-09 >=20 >=20 > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at >=20 > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-ietf-appsawg-malformed-mail-09 > Reviewer: David L. Black > Review Date: November 1, 2013 > IETF LC End Date: October 29, 2013 > IESG Telechat date: November 21, 2013 >=20 > Summary: This draft is basically ready for publication, but has nits that > should be fixed before publication. >=20 > This draft discusses common errors in mail message syntax and provides > useful guidance on handling them. The draft is well written and likely > to be of significant value to implementers. >=20 > Most of my comments relate to clarity, but none of them seem important > enough to be characterized as issues that really have to be fixed, > although the sloppy terminology usage in Sections 7.1.* comes close. >=20 > I apologize for this review appearing slightly after the end of IETF > Last Call - there is too much going on in the weeks immediately before > this IETF meeting. >=20 > Nits/editorial comments: >=20 > The word "naked" is used a few times to refer to something that occurs in > isolation, without enclosure in another construct, e.g., a naked CR. Thi= s > idiomatic use of "naked" should be explained before it is used. >=20 > In Section 1.1, I have always heard Postel's law as: > - Be conservative in what you send, and > - Be liberal in what you accept. > The change from "do" in this draft to "send" (above) seems useful, as > it should help focus the discussion in the second paragraph of Section > 1.1 - Postel's law, as I have understood it, has never blessed anything > remotely resembling there being "no limits to the liberties that a > sender might take." >=20 > Section 5's section title "Mail Submission Agents" doesn't seem to be > connected to its MHS and MTA content. It would be useful to add a > sentence to remind readers, including this one ;-), of what Mail > Submission Agents are. >=20 > Sections 7.1.* offers degrees of advice qualified by "safely", "usually", > "reasonably" and "should". There appear to be only two concepts: > - "safely": Do this all the time. > - "usually", "reasonably", "should": This is the recommended course > of action, but there may be exceptions. > While RFC 2119 is not intended for Informational documents, this is an > example of the sort of sloppiness that RFC 2119 is intended to clean up. > At the very least, the use of three words for essentially the same concep= t > is poor form, and RFC 2119 can be used in an Informational document when > appropriate caveats are provided in the terminology section that referenc= es > it. >=20 > In Section 7.1.4, "Likewise" is not a good way to associate the second > example with the first, because it handles the missing parenthesis in a > rather different fashion (adds quotes instead of inserting the missing > parenthesis character). >=20 > In Section 7.7, the first use of "8bit" occurs in "8bit material" but som= e of > the subsequent occurrences omit the word "material" - that word should be > used with all occurrences. >=20 > idnits 2.13.00 generated a couple of warnings about obsolete references: >=20 > -- Obsolete informational reference (is this intentional?): RFC 1113 (r= ef. > 'PEM') (Obsoleted by RFC 1421) >=20 > -- Obsolete informational reference (is this intentional?): RFC 733 > (Obsoleted by RFC 822) >=20 > In both cases, the reference appears to be intentional, and the warning > should be ignored. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 From superuser@gmail.com Thu Nov 7 13:44:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B726521E80B6 for ; Thu, 7 Nov 2013 13:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 605iyPBgpV+R for ; Thu, 7 Nov 2013 13:44:14 -0800 (PST) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C9BEE21E809F for ; Thu, 7 Nov 2013 13:44:04 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id t61so1131662wes.6 for ; Thu, 07 Nov 2013 13:44:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n4ws8OriwqP3LglefIjyFpBi6f7wEW+Wg/0NNQcnpW8=; b=bZv5MDsbqodtF2nFXzEOw2HpmejowIUNfLL1QRA4KMkofmA2wIyFQd7d8atJm3YRtw PSJWb2dN7tKU25jKot0/QEUb6camlioLhqivt7U/I0CYbNEN73H/h9LCnkXh/ZyNB/xn t/yoxguTpPmLn3VTA4BMebtXN6au1cBfEn6/1odgEm6HBVWSYwE498M/GrMvZiBF/QCX zahfyil1fG+gIZPBJ/fKuS48FFgI8rGQ4nND/bwcyJSjPQ1zEZAaPbXRAw0SwdBpnFyF jSPmAVAQoKRNWptzyATkXGKRmJktOVboP3OqVdz4Iua24sUyKootBtq3HyHaR7bS+bWi W8tA== MIME-Version: 1.0 X-Received: by 10.180.212.51 with SMTP id nh19mr4441355wic.52.1383860643816; Thu, 07 Nov 2013 13:44:03 -0800 (PST) Received: by 10.180.18.202 with HTTP; Thu, 7 Nov 2013 13:44:03 -0800 (PST) In-Reply-To: <024801cecb55$e478be20$4001a8c0@gateway.2wire.net> References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> <5238B9E9.7010204@gmx.de> <525CF2A8.2090904@berkeley.edu> <6vcq5950d7mclheqfcjna5hdue19arqfm8@hive.bjoern.hoehrmann.de> <525D386B.3070705@gmx.de> <525D3D24.3030702@gmx.de> <525D7877.6080905@gmx.de> <024801cecb55$e478be20$4001a8c0@gateway.2wire.net> Date: Thu, 7 Nov 2013 13:44:03 -0800 Message-ID: From: "Murray S. Kucherawy" To: "t.petch" , Erik Wilde , Dave Cridland Content-Type: multipart/alternative; boundary=001a11c3576017ee7704ea9d2a58 Cc: Julian Reschke , Bjoern Hoehrmann , IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call:draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 21:44:22 -0000 --001a11c3576017ee7704ea9d2a58 Content-Type: text/plain; charset=ISO-8859-1 Colleagues, but specifically Tom, Erik, Dave, Julian and Bjoern: Can you have a look at the latest version of this draft (or the diffs, available via the tracker) and let us know if you think it's ready to go in its latest form? Thanks, -MSK, APPSAWG co-chair On Thu, Oct 17, 2013 at 9:23 AM, t.petch wrote: > ----- Original Message ----- > From: "Julian Reschke" > To: "Henry S. Thompson" > Cc: "Bjoern Hoehrmann" ; > Sent: Tuesday, October 15, 2013 6:16 PM > > On 2013-10-15 19:08, Henry S. Thompson wrote: > > > Julian Reschke writes: > > > > > >> The point I was trying to make is that we now have a registry. The > > >> registry is authoritative; if we move the definition of "+xml", > it's > > >> sufficient to simply update the registry. > > > > > > I don't agree. If we don't include 'Updates: 6839', then 6839 will > > > not get an 'Updated by [3023bis]', and anyone reading 6839 will be > > > free to conclude that it defines +xml, which would be false. > > > > Anyone reading it that way would be reading it incorrectly :-) > > > > But anyway, that's something the IESG can worry about. > > Having just read about the difficulty in finding potential members of > the IESG, I think we should do what we can as a WG to make the task of > the IESG simpler, in this case by putting forward a rough consensus from > the WG. > > I am with Henry on this one. It is true that if your world revolves > around web pages, then the IANA web page will take you to the current > definition whereever that is. But if you start with RFC, for example > with the rfc-index, and that does not mention an update to an RFC, then > you will go astray. > > Comparing the two definitions, in RFC6839 and this I-D, they seem to me > like chalk and cheese, as for example in who has change control and who > the contact is, so that the RFC6839 one will be wiped from the face of > the earth; specifying 'Updates' seems the least we can do. > > Tom Petch > > > Best regards, Julian > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --001a11c3576017ee7704ea9d2a58 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues, but specifically Tom, Erik, Dave, Ju= lian and Bjoern:

Can you have a look at the latest version of this d= raft (or the diffs, available via the tracker) and let us know if you think= it's ready to go in its latest form?

Thanks,
-MSK, APPSAWG co-chair



On Thu, Oct 17, 2013 at= 9:23 AM, t.petch <ietfc@btconnect.com> wrote:
----- Original Message ---= --
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Henry S. Thompson" <ht= @inf.ed.ac.uk>
Cc: "Bjoern Hoehrmann" <d= erhoermi@gmx.net>; <apps= -discuss@ietf.org>
Sent: Tuesday, October 15, 2013 6:16 PM
> On 2013-10-15 19:08, Henry S. Thompson wrote:
> > Julian Reschke writes:
> >
> >> The point I was trying to make is that we now have a registry= . The
> >> registry is authoritative; if we move the definition of "= ;+xml",
it's
> >> sufficient to simply update the registry.
> >
> > I don't agree. =A0If we don't include 'Updates: 6839&= #39;, then 6839 will
> > not get an 'Updated by [3023bis]', and anyone reading 683= 9 will be
> > free to conclude that it defines +xml, which would be false.
>
> Anyone reading it that way would be reading it incorrectly :-)
>
> But anyway, that's something the IESG can worry about.

Having just read about the difficulty in finding potential members of=
the IESG, I think we should do what we can as a WG to make the task of
the IESG simpler, in this case by putting forward a rough consensus from the WG.

I am with Henry on this one. =A0It is true that if your world revolves
around web pages, then the IANA web page will take you to the current
definition whereever that is. =A0But if you start with RFC, for example
with the rfc-index, and that does not mention an update to an RFC, then
you will go astray.

Comparing the two definitions, in RFC6839 and this I-D, they seem to me
like chalk and cheese, as for example in who has change control and who
the contact is, so that the RFC6839 one will be wiped from the face of
the earth; specifying 'Updates' seems the least we can do.

Tom Petch

> Best regards, Julian
>


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

--001a11c3576017ee7704ea9d2a58-- From derhoermi@gmx.net Thu Nov 7 14:29:15 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A63321E8144 for ; Thu, 7 Nov 2013 14:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.936 X-Spam-Level: X-Spam-Status: No, score=-2.936 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJEgcaURNlsu for ; Thu, 7 Nov 2013 14:29:01 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id AD49C21E817B for ; Thu, 7 Nov 2013 14:28:55 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.56.251]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0M7CRe-1VrNxb47Fu-00x3rr for ; Thu, 07 Nov 2013 23:28:54 +0100 From: Bjoern Hoehrmann To: "Murray S. Kucherawy" Date: Thu, 07 Nov 2013 23:28:55 +0100 Message-ID: <303o795cbqscut34qbeeuevdmf3ig4769k@hive.bjoern.hoehrmann.de> References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> <5238B9E9.7010204@gmx.de> <525CF2A8.2090904@berkeley.edu> <6vcq5950d7mclheqfcjna5hdue19arqfm8@hive.bjoern.hoehrmann.de> <525D386B.3070705@gmx.de> <525D3D24.3030702@gmx.de> <525D7877.6080905@gmx.de> <024801cecb55$e478be20$4001a8c0@gateway.2wire.net> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:vp9+XFUGA3/RreUE81PDWEx1xdbLA94EC1Xab/3Dke7giomJqQ8 vVHrlj+CIh+lYrwTh7PSxGv+NxMHXvGupbG0ekJucIjJZULZyYk8X3Kqodyia7qg0TRQFJp 5RM6+JVietrdoc46Emgqt6XRFfRjX/gTZCRoqXkxgNxUIuxQc7+zXHwFh3qoPdRlWtpTxCi rjTgRDFwF6aBlRPaH5SnA== Cc: IETF Apps Discuss , Julian Reschke Subject: Re: [apps-discuss] Working Group Last Call:draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 22:29:15 -0000 * Murray S. Kucherawy wrote: >Colleagues, but specifically Tom, Erik, Dave, Julian and Bjoern: > >Can you have a look at the latest version of this draft (or the diffs, >available via the tracker) and let us know if you think it's ready to go in >its latest form? It seems that in the current draft Unicode signatures take precedence over media type `charset` parameters. This is a very recent change that renders all implementations that conform to RFC 3023 non-compliant and it makes the XML types inconsistent with other types like text/plain. It would not be possible to apply the same change to text/plain without making it practically impossible to encode text/plain using ISO-8859-1. Pretty much all text formats that allow you to put non-ASCII bytes at the beginning of a document have this problem if their media types uses the `charset` parameter mechanism. The XML types have the same problem as the draft currently proposes it; a resource like data:application/xml;charset=utf-32,%FF%FE%00%00... will probably be interpreted as malformed UTF-16 encoded document even though it clearly declares UTF-32 and is well-formed when interpreted as such. Similar for `data:application/xml;charset=utf-16le,%FF%FE...`. I think this is a serious and problematic change that needs wide review prior to a two-week Last Call period. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From ht@inf.ed.ac.uk Thu Nov 7 14:40:52 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7998921F9FB5 for ; Thu, 7 Nov 2013 14:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.141 X-Spam-Level: X-Spam-Status: No, score=-7.141 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAbkJ8-hBKu5 for ; Thu, 7 Nov 2013 14:40:47 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE0C21F9FC6 for ; Thu, 7 Nov 2013 14:40:46 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rA7Mea9r015943; Thu, 7 Nov 2013 22:40:36 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rA7MeZee007976; Thu, 7 Nov 2013 22:40:36 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rA7MeZpJ021143; Thu, 7 Nov 2013 22:40:35 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rA7MeYxp021138; Thu, 7 Nov 2013 22:40:34 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Bjoern Hoehrmann References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> <5238B9E9.7010204@gmx.de> <525CF2A8.2090904@berkeley.edu> <6vcq5950d7mclheqfcjna5hdue19arqfm8@hive.bjoern.hoehrmann.de> <525D386B.3070705@gmx.de> <525D3D24.3030702@gmx.de> <525D7877.6080905@gmx.de> <024801cecb55$e478be20$4001a8c0@gateway.2wire.net> <303o795cbqscut34qbeeuevdmf3ig4769k@hive.bjoern.hoehrmann.de> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 07 Nov 2013 22:40:34 +0000 In-Reply-To: <303o795cbqscut34qbeeuevdmf3ig4769k@hive.bjoern.hoehrmann.de> (Bjoern Hoehrmann's message of "Thu\, 07 Nov 2013 23\:28\:55 +0100") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: IETF Apps Discuss , Julian Reschke Subject: Re: [apps-discuss] Working Group Last Call:draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 22:40:52 -0000 Bjoern Hoehrmann writes: > It seems that in the current draft Unicode signatures take precedence > over media type `charset` parameters. This is a very recent change that > renders all implementations that conform to RFC 3023 non-compliant and > it makes the XML types inconsistent with other types like text/plain. 3023 did not specify behaviour at all in this case, leaving implementors free to choose. Implementors have all chosen to take the BOM as definitive. The proposed text merely ratifies this. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From derhoermi@gmx.net Thu Nov 7 15:16:52 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E42511E8197 for ; Thu, 7 Nov 2013 15:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.929 X-Spam-Level: X-Spam-Status: No, score=-2.929 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3g8RfhHBE6G for ; Thu, 7 Nov 2013 15:16:46 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id AB2B011E8278 for ; Thu, 7 Nov 2013 15:16:45 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.56.251]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0MJBn4-1Vctqz48Ko-002mO3 for ; Fri, 08 Nov 2013 00:16:44 +0100 From: Bjoern Hoehrmann To: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 08 Nov 2013 00:16:44 +0100 Message-ID: <256o79p8kcls640qtmtkianfmu1sp1vi2b@hive.bjoern.hoehrmann.de> References: <6vcq5950d7mclheqfcjna5hdue19arqfm8@hive.bjoern.hoehrmann.de> <525D386B.3070705@gmx.de> <525D3D24.3030702@gmx.de> <525D7877.6080905@gmx.de> <024801cecb55$e478be20$4001a8c0@gateway.2wire.net> <303o795cbqscut34qbeeuevdmf3ig4769k@hive.bjoern.hoehrmann.de> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:9oh+KqPcjrtPp0bjkz1Z13E/OnH+IWp4sZnMsnY+Sf28aT0/KSd jtQCmAzSAtL3r0EEjV902dMFk2n9AkQPOHQxsb0At9uz0zxKKCXLrDhtVezP9c3xLdMnsGq 07XQQPY7P0M3nODeQkGFTPH5qyV70P2YpmoaVefpFf6m2kQibVoZOCA9oCLuT2bZEbx5gJD 9e2jnPvM0ZBhBuO4Q/gcw== Cc: IETF Apps Discuss , Julian Reschke Subject: Re: [apps-discuss] Working Group Last Call:draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Nov 2013 23:16:53 -0000 * Henry S. Thompson wrote: >Bjoern Hoehrmann writes: > >> It seems that in the current draft Unicode signatures take precedence >> over media type `charset` parameters. This is a very recent change that >> renders all implementations that conform to RFC 3023 non-compliant and >> it makes the XML types inconsistent with other types like text/plain. > >3023 did not specify behaviour at all in this case, leaving >implementors free to choose. Implementors have all chosen to take the >BOM as definitive. The proposed text merely ratifies this. That internal byte sequences take precedence over external labels is not a reasonable interpretation of RFC 3023 and the XML 1.0 specification. Treating data:application/xml;charset=utf-32,%FF%FE%00%00... as UTF-16 encoded document for instance directly contradicts section F.1 of the XML 1.0 Recommendation. And no, giving precendence to the signature is a recent trend among some browser developers. It is not what I implemented e.g. for W3C's Markup Validator. If the XML community wishes to make a change such as this, that is fine by me, but I have seen little to no evidence that people are aware of this proposal, fully understand it, and agree with it, and claims such as yours above do not help to change that. More helpful would be test results from a diverse set of implemen- tations; that should be easy if implementers all have chosen as you are suggesting. My http://search.cpan.org/dist/HTML-Encoding/ is a "fail". -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From julian.reschke@gmx.de Thu Nov 7 16:10:50 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DA511E829A for ; Thu, 7 Nov 2013 16:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.262 X-Spam-Level: X-Spam-Status: No, score=-104.262 tagged_above=-999 required=5 tests=[AWL=-1.663, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkS9ezyrEYzf for ; Thu, 7 Nov 2013 16:10:22 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 1922921E808A for ; Thu, 7 Nov 2013 16:10:22 -0800 (PST) Received: from [31.133.151.131] ([31.133.151.131]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M5cMq-1Vpmrr1Klk-00xZlv for ; Fri, 08 Nov 2013 01:10:03 +0100 Message-ID: <527C2BD9.1060401@gmx.de> Date: Thu, 07 Nov 2013 16:10:01 -0800 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , "t.petch" , Erik Wilde , Dave Cridland References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> <5238B9E9.7010204@gmx.de> <525CF2A8.2090904@berkeley.edu> <6vcq5950d7mclheqfcjna5hdue19arqfm8@hive.bjoern.hoehrmann.de> <525D386B.3070705@gmx.de> <525D3D24.3030702@gmx.de> <525D7877.6080905@gmx.de> <024801cecb55$e478be20$4001a8c0@gateway.2wire.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:jNwZjSQIduCNhfYNcZqHbTyvuFKWXkXYSTR6P7u/ecsofSpO5dd EFkELPoyrmb4H4tXvw1kaItgYjgnHOPNLQt4NGk6s+Mk6xkA2n5yyN/VVH5SJKbuZd/j65S 55xcHE+LSxz6R7qlysFmc+1pHJz/yJZM2PwlokaU3Bcnf7SYi05An3Z2YSqtuejYwyEE6Ps BjZFdx3AAN19Pri5u4fkw== Cc: Bjoern Hoehrmann , IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call:draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Nov 2013 00:10:51 -0000 On 2013-11-07 13:44, Murray S. Kucherawy wrote: > Colleagues, but specifically Tom, Erik, Dave, Julian and Bjoern: > > Can you have a look at the latest version of this draft (or the diffs, > available via the tracker) and let us know if you think it's ready to go > in its latest form? > > Thanks, > -MSK, APPSAWG co-chair Actually, I looked at the diffs wrt to my comments, and they seem to be addressed. I want to do another pass at the document; at least the 2616/HTTPbis references need to be cleaned up (see the mail I sent in October). Best regards, Julian From dret@berkeley.edu Thu Nov 7 17:07:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BBD11E81BB for ; Thu, 7 Nov 2013 17:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cC+Mt0utbgjL for ; Thu, 7 Nov 2013 17:07:06 -0800 (PST) Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id 71AF711E8156 for ; Thu, 7 Nov 2013 17:07:05 -0800 (PST) Received: from dhcp-a20d.meeting.ietf.org ([31.133.162.13]) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1VeaXM-0002gQ-3E; Thu, 07 Nov 2013 17:07:00 -0800 Message-ID: <527C3933.6060000@berkeley.edu> Date: Thu, 07 Nov 2013 17:06:59 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> <5238B9E9.7010204@gmx.de> <525CF2A8.2090904@berkeley.edu> <6vcq5950d7mclheqfcjna5hdue19arqfm8@hive.bjoern.hoehrmann.de> <525D386B.3070705@gmx.de> <525D3D24.3030702@gmx.de> <525D7877.6080905@gmx.de> <024801cecb55$e478be20$4001a8c0@gateway.2wire.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss , Julian Reschke , Bjoern Hoehrmann Subject: Re: [apps-discuss] Working Group Last Call:draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Nov 2013 01:07:12 -0000 On 2013-11-07, 13:44 , Murray S. Kucherawy wrote: > Colleagues, but specifically Tom, Erik, Dave, Julian and Bjoern: > Can you have a look at the latest version of this draft (or the diffs, > available via the tracker) and let us know if you think it's ready to go > in its latest form? i looked at http://tools.ietf.org/rfcdiff?url2=draft-ietf-appsawg-xml-mediatypes-04.txt&url1=draft-ietf-appsawg-xml-mediatypes-02.txt and i am happy with how my comments have been addressed in the latest draft. thanks and cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From dev+ietf@seantek.com Thu Nov 7 19:24:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504E411E814B; Thu, 7 Nov 2013 19:24:42 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsbkkfxZ0bKE; Thu, 7 Nov 2013 19:24:37 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 85AA411E822C; Thu, 7 Nov 2013 19:24:13 -0800 (PST) Received: from [142.131.19.16] (unknown [64.114.24.114]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0AC6F22E259; Thu, 7 Nov 2013 22:24:06 -0500 (EST) From: Sean Leonard Content-Type: multipart/signed; boundary="Apple-Mail=_44F48962-CDBB-4588-8170-43FEFF435A19"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <92685DEB-1713-4018-8E27-C8D78829EEB7@seantek.com> Date: Thu, 7 Nov 2013 19:24:06 -0800 To: "urn-nid@ietf.org" , "saag@ietf.org" , "apps-discuss@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [apps-discuss] New version of certspec (02) incorporating Dale's feedback X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Nov 2013 03:24:42 -0000 --Apple-Mail=_44F48962-CDBB-4588-8170-43FEFF435A19 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello URN/Apps folks, and SAAG folks: A new version of the Internet-Draft draft-seantek-certspec (02) has been = posted to the IETF repository. I would like to notify this list for = further commentary. Dale Worley provided excellent feedback on the urn-nid mailing list, all = of which I considered and most of which I incorporated. Some of the = changes are significant; the most significant changes are tightening up = the acceptable characters for various certspec productions, and = referring and conforming to URNBIS = (http://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-06) as much = as possible, instead of RFC 2141. I also changed a lot of nomenclature = to be consistent--for example, I refer to certificates encoded in their = entirety as "content-based certspecs" rather than "value-based = certspecs" (in contrast to certificate identifiers by reference), since = "certspec-value" is the counterpart to "certspec-type". I will respond = to Dale's feedback on the urn-nid list. Kind regards, Sean ************** Subject: New Version Notification for draft-seantek-certspec-02.txt A new version of I-D, draft-seantek-certspec-02.txt has been successfully submitted by Sean Leonard and posted to the IETF repository. Filename: draft-seantek-certspec Revision: 02 Title: A Uniform Resource Name (URN) Namespace for = Certificates Creation date: 2013-11-08 Group: Individual Submission Number of pages: 19 URL: = http://www.ietf.org/internet-drafts/draft-seantek-certspec-02.txt Status: http://datatracker.ietf.org/doc/draft-seantek-certspec Htmlized: http://tools.ietf.org/html/draft-seantek-certspec-02 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-seantek-certspec-02 Abstract: Digital certificates are used in many systems and protocols to identify and authenticate parties. This document describes a Uniform Resource Name (URN) namespace that identifies certificates. These URNs can be used when certificates need to be identified by value or reference. --Apple-Mail=_44F48962-CDBB-4588-8170-43FEFF435A19 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO2TCCBIow ggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wNTA2MDcwODA5MTBa Fw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNh bHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0 dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmF pPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJk xIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2q L+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAs vIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMe oYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3 +sQmVO8DveAky1QaMB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMC AQYwDwYDVR0TAQH/BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2Nh LmNvbS9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8u bmV0L0FkZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyis pgCi54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHdWTBK 322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftzMizpm4Qk LdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsyXEFs/vVdoOr/ 0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi5iIyeqpx3jANBgkq hkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwn VmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49c NfrlVICv2HEKHTcKAlBTbJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+Os vxQ7sCVxaD30D9YXWEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWON GoulzEKbm30iY9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAU iYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1Ud DwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUHMAKGMWh0 dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQwJQYIKwYBBQUH MAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAIXWvnhXVW0z f0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjfy/tCPKElPgp11tA9OYZm 0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T4ENyG+2P/WA5IEf7i686ZUg8 mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8H+2b/5tJM75CKTmD7jNpLoKd RU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ 1eBDQEIwvuql55TSsP7zdfl/bucwggUpMIIEEaADAgECAhBnqxWWtMRiPAtoE+jFTARpMA0GCSqG SIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09N T0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMTEyOTAw MDAwMFoXDTEzMTEyOTIzNTk1OVowJTEjMCEGCSqGSIb3DQEJARYUZGV2K2lldGZAc2VhbnRlay5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPifbSoA7NS0LWg3PnOBOfLQlEETWY lmzNXazoS6tqEo++S7sT662cuFxo1qEBavahmB4Ir26ESqKNoLiotkeca3/6WduxC2OYwmtwULOE NmMM4l1jOa5LZxS9mpjtjDMIbqNJ+ziDA2H7b0xLp9pjq5ydxud872sEHTG7kYh0jcHOw81icAI2 UFhTvDhfgYDT8zA0Bps2EODFTZPDV+XnDVW37rFFNcGTpX3cvJVk33AEg6mvYy6GgIksdmsuKu/+ ZtATlqjimQktH+zJiFLUqjgxKImZHe6Ao+TESjoNmS4mt9yTfqEua0yjfK7OLuGReYPM8qR0uU2P 5d6TUZa3AgMBAAGjggHkMIIB4DAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNV HQ4EFgQUGmbl3vLw8FPo2qchVt80ryFuk8YwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAw IAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNV HSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21v ZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01P RE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8 MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhl bnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNv bW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0BAQUF AAOCAQEABjcZ+BfSkuzPqoQ44bX3USBhdIKkpbvTBIWBJ77sB6dlPzx3+bzDRi184VUPv73h01Qs Ocfg/qwPvSF1rLv+R7i5h+BRHHKB6Yo3bopXdPvAHDxZtlJOZgmmHNKipQrkhKxA3Atop/jJOakB 70hHUCNlc/egBm+xG+lkO2JpQtD4d8VPKksOyesDuxO2hW2Ksl0iYYFMexW1n4YRCWG64nobVwif M3EhvGCct2fikUXzYU/rRKxnFpbZVGoMrsJsclfgtQf6gnqSn2rEXkj9EgCFEd3eUx5earq9k9uc xQ2EnJQLpNtiKl7XX5UMU8aIdkT/7LpExK5Gd6knMTg8sDGCA6swggOnAgEBMIGoMIGTMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBnqxWWtMRiPAtoE+jFTARpMAkGBSsOAwIaBQCg ggHXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTEwODAzMjQw N1owIwYJKoZIhvcNAQkEMRYEFFrx5zma/BaXozAJY5F2qLhfIq4PMIG5BgkrBgEEAYI3EAQxgasw gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEGerFZa0xGI8C2gT6MVMBGkw gbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBN YW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhBnqxWWtMRiPAtoE+jFTARpMA0GCSqGSIb3DQEBAQUABIIBALO2eKdG5WonVzeX37fKgh8Ni67d z/IeB13rt5z7LzOqoLg1c65C0MuwD9shqTqlamc0VgmDFcwRhnmb0Nwjj7n09nZ7tmCksS9SAm59 oBnzv42TWRIEbDcczeySTerjaeGsFRuSsTfX5DUMclDGdJHStY/pnLTU9/ZvuZzhFlw5wIlnv3V0 VNXvsYk1lKRq16kgJ3mM84DYtCemHCuQ2PgavJQkjX1r2PKH/G9VvITtEcal2H8feDfGjDKYo6xP C2OzB2cb865XOHnizMCn2C1+yaRtUgaJK+NG5CQXRMD9bIJdbDWLktN3Ucgv99rmWRfUYJBvvmDS vNsaeMaLgmMAAAAAAAA= --Apple-Mail=_44F48962-CDBB-4588-8170-43FEFF435A19-- From James.H.Manger@team.telstra.com Thu Nov 7 19:55:06 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A20621E81A9 for ; Thu, 7 Nov 2013 19:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.308 X-Spam-Level: X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_39=0.6, J_CHICKENPOX_55=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10sGv73FFtF2 for ; Thu, 7 Nov 2013 19:55:01 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 6099421E8198 for ; Thu, 7 Nov 2013 19:54:59 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,657,1378821600"; d="scan'208";a="172361750" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipobvi.tcif.telstra.com.au with ESMTP; 08 Nov 2013 14:54:45 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7252"; a="173154574" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipccvi.tcif.telstra.com.au with ESMTP; 08 Nov 2013 14:54:45 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Fri, 8 Nov 2013 14:54:45 +1100 From: "Manger, James H" To: James M Snell Date: Fri, 8 Nov 2013 14:54:43 +1100 Thread-Topic: [apps-discuss] FYI: LINK and UNLINK Thread-Index: Ac7b2cSFjoYqVI6wTPqhFUC7fRwKDwAVgHIw Message-ID: <255B9BB34FB7D647A506DC292726F6E11536159351@WSMSG3153V.srv.dir.telstra.com> References: <5279952E.5040402@gmx.de> <527997D3.4010108@gmx.de> <527999EA.9050401@gmx.de> <527A5C23.8050201@gmx.de> <527A61E8.2050309@gmx.de> <527A74C3.3010506@gmx.de> <527A84ED.3080208@gmx.de> <527A8AF3.4000304@gmx.de> <255B9BB34FB7D647A506DC292726F6E1153607F874@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Julian Reschke , "ietf-http-wg@w3.org" , IETF Apps Discuss Subject: Re: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Nov 2013 03:55:06 -0000 PiBEZWZpbml0ZWx5IGFwcHJlY2lhdGUgdGhlIGZlZWRiYWNrIGJ1dCBJJ20gZGVmaW5pdGVseSAt MSBvbiB0aGUgaWRlYQ0KPiBvZiBpbnZlbnRpbmcgYSBuZXcgIlVubGluayIgcmVxdWVzdCBoZWFk ZXIuIEl0J3MganVzdCBub3QgbmVjZXNzYXJ5LiBJDQo+IGFsc28gZG9uJ3QgYmVsaWV2ZSBtYXRj aGluZyBydWxlcyBhcmUgcmVxdWlyZWQuIFRoZSBVTkxJTksgd2lsbCBtYXRjaA0KPiBpZiBhbGwg dGhlIGF0dHJpYnV0ZXMgcHJvdmlkZWQgbWF0Y2ggYWxsIHRoZSBhdHRyaWJ1dGVzIG9mIGFuDQo+ IGVzdGFibGlzaGVkIGxpbmsuIEl0IGRvZXNuJ3QgbmVlZCB0byBiZSBtb3JlIGNvbXBsaWNhdGVk IHRoYW4gdGhhdC4NCg0KDQpTbyB0byBjaGFuZ2UgdGhlIHRpdGxlIGFzc29jaWF0ZWQgd2l0aCBh biBleGlzdGluZyBsaW5rIEkgbmVlZCB0byBkbyBhbiBVTkxJTksgcmVxdWVzdCB0byByZW1vdmUg dGhlIGV4aXN0aW5nIG9uZSwgdGhlbiBhIHNlcGFyYXRlIExJTksgcmVxdWVzdCB0byBhZGQgdGhl IG5ldyBvbmUuIEkgcHJvYmFibHkgbmVlZCBhIDNyZCByZXF1ZXN0OiBhbiBpbml0aWFsIEdFVCAo b3IgSEVBRCkgdG8gZ2V0IGFsbCB0aGUgYXR0cmlidXRlcyBvZiB0aGUgb2xkIGxpbmsgc28gSSBj YW4gcmVtb3ZlIGl0Lg0KDQpTaW5jZSBJIG5lZWQgc2VwYXJhdGUgVU5MSU5LIGFuZCBMSU5LIHJl cXVlc3RzLCBtb2RpZnlpbmcgdGhlIHRpdGxlIGNhbm5vdCBiZSBhdG9taWMuIE91Y2guDQoNCklm IEkgd2FudCB0byByZW1vdmUgYWxsIHJlbD1hbHRlcm5hdGUgbGlua3MgSSBjYW7igJl0IHNlbmQg MSByZXF1ZXN0IHdpdGggIlVubGluazogcmVsPWFsdGVybmF0ZSIsIGJ1dCBJIG5lZWQgdG8gcmVh ZCBhbGwgZXhpc3RpbmcgbGlua3MsIHNlbGVjdCB0aG9zZSB3aXRoIHRoZSByZWwgb2YgaW50ZXJl c3QsIHRoZW4gcmVwbGF5IGFsbCB0aG9zZSBsaW5rcyBpbiBhbiBVTkxJTksgcmVxdWVzdCAod2l0 aCBhbiBJZi1NYXRjaCBoZWFkZXIgaW4gY2FzZSB0aGVyZSB3ZXJlIG90aGVyIGNvbmN1cnJlbnQg Y2hhbmdlcykuDQoNCklmIGEgbGluayBoYXMgMiByZWwgdmFsdWVzIEkgYXNzdW1lIEkgbmVlZCB0 byBpbmNsdWRlIGJvdGggdG8gcmVtb3ZlIHRoZSBsaW5rLiBEbyB0aGV5IGhhdmUgdG8gYmUgaW4g dGhlIHNhbWUgb3JkZXIgb3IgZG9lcyByZWw9ImFsdGVybmF0ZSBzdHlsZXNoZWV0IiBtYXRjaCBy ZWw9InN0eWxlc2hlZXQgYWx0ZXJuYXRlIi4gSSB3b25kZXIgd2hhdCBhbiBleHRyYW5lb3VzIHNw YWNlIGluIGEgcmVsIHZhbHVlIHdvdWxkIGRvPyBUaGUgbGluayBpcyBsaWtlbHkgdG8gd29yaywg YnV0IGFuIFVOTElOSyByZXF1ZXN0IHdpbGwgcHJvYmFibHkgZmFpbC4NCg0KSWYgSSBHRVQgYW4g SFRNTCBkb2MgdGhhdCBoYXMgPGxpbms+cywgSSBob3BlIGl0IGluY2x1ZGVzIGFsbCB0aGUgYXR0 cmlidXRlcyBvZiB0aG9zZSBsaW5rcyBvdGhlcndpc2UgbXkgYXR0ZW1wdCB0byByZW1vdmUgYSBs aW5rIHdpbGwgZmFpbC4gSSBob3BlIEkgY2FuIHRyYW5zbGF0ZSBIVE1MIGF0dHJpYnV0ZSB2YWx1 ZXMgaW50byBIVFRQIGhlYWRlciBwYXJhbWV0ZXIgdmFsdWVzIChkb2luZyB0aGF0IFJGQzIyMzEg cGFyYW1uYW1lKj0lLWVzY2FwZWQgc3R1ZmYpIG90aGVyd2lzZSBJIGNhbm5vdCByZW1vdmUgbGlu a3MuDQoNCklmIGFuIFhNTCA8bGluaz4gZWxlbWVudCBoYXMgYW4geG1sbnMgYXR0cmlidXRlIEkg YXNzdW1lIEkgZG9u4oCZdCB0cmFuc2xhdGUgaXQgdG8gYW4gSFRUUCBMaW5rIGhlYWRlciBwYXJh bWV0ZXIgd2hlbiBkb2luZyBhbiBVTkxJTksgcmVxdWVzdC4gSXMgaXQgb2J2aW91cyB3aGljaCBY TUwgYXR0cmlidXRlcyB0byBpbmNsdWRlIGFuZCBleGNsdWRlPw0KDQoNCkkgdGhpbmsgc3BsaXR0 aW5nIExpbmsgY2hhbmdlcyBpbnRvIHNlcGFyYXRlIExJTksgYW5kIFVOTElOSyByZXF1ZXN0cyBp cyBhIHNpZ25pZmljYW50IGZsYXcuIFRvIGZpeCB0aGF0IHlvdSBuZWVkIGEgc2VwYXJhdGUgd2F5 IHRvIGV4cHJlc3MgbGluayByZW1vdmFsIChlZyBhbiBVbmxpbmsgSFRUUCBoZWFkZXIgaXMgb25l IG9wdGlvbiksIGFuZCB0aGF0IHdheSB3b3VsZCBiZSBtb3JlIHVzZWZ1bCB3aXRoIGEgbW9yZSBs ZW5pZW50IG1hdGNoaW5nIHJ1bGUuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0KDQoNCg0KDQo+IE9u IFdlZCwgTm92IDYsIDIwMTMgYXQgNToxNSBQTSwgTWFuZ2VyLCBKYW1lcyBIDQo+IDxKYW1lcy5I Lk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPiB3cm90ZToNCj4gPj4gaHR0cDovL3d3dy5pZXRmLm9y Zy9pZC9kcmFmdC1zbmVsbC1saW5rLW1ldGhvZC0wNy50eHQNCj4gPj4NCj4gPj4gUGVyIEp1bGlh bidzIHN1Z2dlc3Rpb24sIGFjY29tbW9kYXRlcyBhbGwgdGFyZ2V0IGF0dHJpYnV0ZXMsIGRlYWxz DQo+ID4+IHdpdGggMnh4IHJlc3BvbnNlIGNvZGVzLCBoYW5kbGVzIHVzZSBvZiB0aGUgYW5jaG9y IGF0dHJpYnV0ZSB0bw0KPiA+PiBvdmVycmlkZSB0aGUgY29udGV4dCBJUkkuIEFsc28sIGRlYWxz IHdpdGggZXF1aXZhbGVuY2UgY2hlY2tpbmcgZm9yDQo+ID4+IElSSXMuDQo+ID4NCj4gPg0KPiA+ IFRoZSByb290IGNhdXNlIG9mIHRoZSBhcmd1bWVudHMgYWJvdXQgd2hpY2ggbGluayBhdHRyaWJ1 dGVzIGFyZQ0KPiAic2lnbmlmaWNhbnQiIGlzIHRoYXQgMSBsaW5rIHN5bnRheCBpcyBiZWluZyB1 c2VkIGZvciAyIGRpc3RpbmN0DQo+IHB1cnBvc2VzLg0KPiA+DQo+ID4gMS4gV2l0aCB0aGUgTElO SyBtZXRob2QsIGEgTGluayBoZWFkZXIgcHJvdmlkZXMgYSBjb21wbGV0ZSBsaW5rIHRvDQo+IGFk ZC4NCj4gPg0KPiA+IDIuIFdpdGggdGhlIFVOTElOSyBtZXRob2QsIGEgTGluayBoZWFkZXIgcHJv dmlkZXMgY3JpdGVyaWEgZm9yDQo+IG1hdGNoaW5nIGV4aXN0aW5nIGxpbmtzIHRvIHJlbW92ZS4N Cj4gPg0KPiA+IFRoZSBMaW5rIGhlYWRlciBpcyBkZXNpZ25lZCB0byBwcm92aWRlIGEgY29tcGxl dGUgbGluay4gSXQgaXMgbm90DQo+IGRlc2lnbmVkIHRvIGNvbnZleSBjcml0ZXJpYSBmb3IgbWF0 Y2hpbmcgbGlua3MuIEl0IGNhbiBhcHByb3hpbWF0ZWx5DQo+IHNlcnZlIHRoZSBsYXR0ZXIgcHVy cG9zZSBpZiB5b3UgYWRkIGEgcnVsZS4gUG9zc2libGUgcnVsZXMgYXJlOg0KPiA+IEEpICJhIGxp bmsgbWF0Y2hlcyBvbmx5IGlmIGV2ZXJ5IGF0dHJpYnV0ZSBpcyBleGFjdGx5IHRoZSBzYW1lIjsg b3INCj4gPiBCKSAiYSBsaW5rIG1hdGNoZXMgaWYgdGhlIGF0dHJpYnV0ZXMgcHJvdmlkZWQgbWF0 Y2gsIHJlZ2FyZGxlc3Mgb2YNCj4gYW55IG90aGVyIGF0dHJpYnV0ZSBpcyBoYXMiOyBvcg0KPiA+ IEMpICJhIGxpbmsgbWF0Y2hlcyBpZiB0aGUgdmFsdWVzIGFuZCBwcmVzZW5jZSBvZiA2IHNwZWNp ZmljDQo+IGF0dHJpYnV0ZXMgbWF0Y2ggKHJlbCwgaHJlZmxhbmcsIC4uLikiLg0KPiA+DQo+ID4g QSBiZXR0ZXIgZGVzaWduIHdvdWxkIGJlIHRvIGFja25vd2xlZGdlIHRoYXQgc3BlY2lmeWluZyBh IGxpbmsgYW5kDQo+IHNwZWNpZnlpbmcgY3JpdGVyaWEgZm9yIG1hdGNoaW5nIGxpbmtzIGFyZSBk aWZmZXJlbnQgdGhpbmdzLiBUaGF0IGNvdWxkDQo+IGJlIHJlZmxlY3RlZCBieSBkZWZpbmluZyBh biBVbmxpbmsgaGVhZGVyIHRvIGhvbGQgbWF0Y2hpbmcgY3JpdGVyaWEuIFdlDQo+IGNvdWxkIGRy b3AgdGhlIFVOTElOSyBtZXRob2QgYW5kIGp1c3QgaW5jbHVkZSBMaW5rIGFuZCBVbmxpbmsgaGVh ZGVycw0KPiB3aGVuIHVzaW5nIHRoZSBMSU5LIG1ldGhvZC4NCj4gPg0KPiA+IFRoZSBVbmxpbmsg aGVhZGVyIGNvdWxkIHVzZSBhIHN5bnRheCBsaWtlIExpbms7IHByb2JhYmx5IHdpdGggcnVsZSBC DQo+IChhbGwgYXR0cmlidXRlIGluIHRoZSBVbmxpbmsgdmFsdWUgbXVzdCBtYXRjaCwgYnV0IGEg bGluayBzdGlsbCBtYXRjaGVzDQo+IGlmIGl0IGhhcyBhZGRpdGlvbmFsIGF0dHJpYnV0ZXMpOyBw ZXJoYXBzIHdpdGggYW4gb3B0aW9uYWwgZXh0cmE9ZmFsc2UNCj4gYXR0cmlidXRlIG1lYW5pbmcg bGlua3Mgd2l0aCBhZGRpdGlvbmFsIGF0dHJpYnV0ZXMgZG8gbm90IG1hdGNoLg0KPiA+DQo+ID4N Cj4gPiAtLQ0KPiA+IEphbWVzIE1hbmdlcg0K From duerst@it.aoyama.ac.jp Fri Nov 8 02:01:24 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC7921E8094 for ; Fri, 8 Nov 2013 02:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.392 X-Spam-Level: X-Spam-Status: No, score=-103.392 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_66=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsxnxXTw94Be for ; Fri, 8 Nov 2013 02:01:18 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id E33A011E81C9 for ; Fri, 8 Nov 2013 02:01:16 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rA8A1AWX021274; Fri, 8 Nov 2013 19:01:10 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 493a_6a16_b158afda_485c_11e3_969a_001e6722eec2; Fri, 08 Nov 2013 19:01:09 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 53FD4BF54D; Fri, 8 Nov 2013 19:01:09 +0900 (JST) Message-ID: <527CB65B.7030301@it.aoyama.ac.jp> Date: Fri, 08 Nov 2013 19:00:59 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Tim Bray References: <5276878A.6000802@berkeley.edu> <5278AF21.90605@it.aoyama.ac.jp> <527B0EA0.40907@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] proposal: adding profile support to JSON X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Nov 2013 10:01:24 -0000 On 2013/11/08 1:20, Tim Bray wrote: > Well, my thinking was like this. Suppose people start requiring I-JSON = for > some protocol or other. What we would like is to convince the authors = of > the existing JSON libraries to implement I-JSON mode, where they signal= an > error when they hit a dupe key or whatever. I suppose in most cases th= is > would be done with a new JSONParserFactory#setIJSONMode() method, or > something like that. Yes. I'm very much with you up to here. I'd personally use a parameter=20 to the factory constructor, but that's a minor detail. > But, speaking as the author of quite a bit of markup parsing software, = the > notion of putting a force-I-JSON-mode But it's NOT a 'force-I-JSON-mode'. There are lots of old JSON parsers=20 out there that don't know anything about i-json. > in the instance struck me as > potentially useful for: > - a bug-catcher Yes, if you have lots of JSON (I- or not) lying around somewhere, and=20 you want to check how much of what's supposed to be of the I- variant,=20 then it may be useful. But that's what I call a meta-usecase, which by=20 my book shouldn't drive design. > - Postel=E2=80=99s-law-following receivers who want to check how carefu= l they have > to be about name/value mapping, broken Unicode, etc - as it stands, you > really can=E2=80=99t safely use UTF-8 conformant String#length on JSON = strings in > the general case. It's difficult for me to imagine a receiver that checks some of the JSON=20 it receives more carefully. If I have an application, let's say with a=20 database behind it, and I don't want to have any unpaired surrogate=20 stuff and the like in that database, I'll check all incoming data, and=20 won't care about whether it comes with the necessary flags or not. > I guess I=E2=80=99m also influenced by the generally good experience wi= th the XML > declaration. The XML declaration was there from the start (of XML). There isn't any=20 such thing for JSON up to now. The XML declaration, if it is there (it's not mandatory) is always at=20 the very start of an XML document (no spaces allowed). There have been=20 strong doubts about whether the i-json indication inside the document=20 can be made to appear early on in an object. > But this is not something I=E2=80=99m passionate about, just something = that=E2=80=99s worth > thinking about. Yes. My thinking hasn't turned up much in favor, but maybe somebody=20 else's thinking will? Regards, Martin. -T > > > On Wed, Nov 6, 2013 at 7:53 PM, "Martin J. D=C3=BCrst"wrote: > >> - I think this draft provides value in that somebody can point to it a= nd >> say "I'm accepting JSON, but only if it conforms to this" (meaning no >> single surrogates, no duplicate object keys,...). >> >> - I think the profile parameter and the "self-identification" are tota= l >> overkill. They would be needed if we imagine a receiver that accepts b= oth >> restricted (i-json) and general (JSON) stuff, but I can't see the poin= t of >> doing that (except for the constructed example of a service that check= s >> which of the two it is). >> >> - If I restrict myself to accepting i-json, I have to check for proble= ms >> anyway, even if it comes with a profile parameter and a >> "self-identification". So these two items don't really help. >> >> Because I don't know you as somebody who makes protocols and formats >> needlessly complex, I'm really wondering what you think these two feat= ures >> are good for. I hope you can explain. >> > From ht@inf.ed.ac.uk Fri Nov 8 07:18:16 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC67B21E8164 for ; Fri, 8 Nov 2013 07:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.111 X-Spam-Level: X-Spam-Status: No, score=-7.111 tagged_above=-999 required=5 tests=[AWL=-0.512, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeZ0UA707GOs for ; Fri, 8 Nov 2013 07:18:11 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7527021E8140 for ; Fri, 8 Nov 2013 07:18:10 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rA8FHsT3027459; Fri, 8 Nov 2013 15:17:54 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rA8FHrQW022726; Fri, 8 Nov 2013 15:17:53 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rA8FHrTN007960; Fri, 8 Nov 2013 15:17:53 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rA8FHpo1007956; Fri, 8 Nov 2013 15:17:51 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Bjoern Hoehrmann References: <6vcq5950d7mclheqfcjna5hdue19arqfm8@hive.bjoern.hoehrmann.de> <525D386B.3070705@gmx.de> <525D3D24.3030702@gmx.de> <525D7877.6080905@gmx.de> <024801cecb55$e478be20$4001a8c0@gateway.2wire.net> <303o795cbqscut34qbeeuevdmf3ig4769k@hive.bjoern.hoehrmann.de> <256o79p8kcls640qtmtkianfmu1sp1vi2b@hive.bjoern.hoehrmann.de> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 08 Nov 2013 15:17:51 +0000 In-Reply-To: <256o79p8kcls640qtmtkianfmu1sp1vi2b@hive.bjoern.hoehrmann.de> (Bjoern Hoehrmann's message of "Fri\, 08 Nov 2013 00\:16\:44 +0100") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: IETF Apps Discuss , Julian Reschke Subject: Re: [apps-discuss] Working Group Last Call:draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Nov 2013 15:18:17 -0000 Bjoern Hoehrmann writes: > That internal byte sequences take precedence over external labels is not > a reasonable interpretation of RFC 3023 This draft replaces 3023. > and the XML 1.0 specification. Treating > data:application/xml;charset=utf-32,%FF%FE%00%00... as UTF-16 > encoded document for instance directly contradicts section F.1 of > the XML 1.0 Recommendation. Appendix F is non-normative, but in any case your statement is incorrect. F.1 applies only in the _absence_ of a charset parameter. F.2 applies when there is one, and it says: When multiple sources of information are available, their relative priority and the preferred method of handling conflict should be specified as part of the higher-level protocol used to deliver XML. So it's entirely in-scope for 3023bis to specify that a BOM is definitive in the presence of a charset parameter. Furthermore, your example is broken in another way -- XML _requires_ any document not in UTF-8 or UTF-16 to begin with an XML encoding declaration. The above data:... document does not do so. So it's not an XML document at all, and so not a legitimate use of the application/xml media type. > And no, giving precendence to the signature is a recent trend among > some browser developers. I don't know about 'recent', but it's widespread. IE9, Chrome 32.0.1700.4, Opera 12.16, Safari 5.1.7 and Firefox 25 all treat a BOM as definitive despite the presence of a conflicting charset parameter value, as do expat and rxp. libxml2 is the only counter-example I'm aware of. > More helpful would be test results from a diverse set of > implementations; that should be easy if implementers all have chosen > as you are suggesting. See the above list, which includes about as diverse a set of browsers as you can get. . . ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From ietf-secretariat-reply@ietf.org Fri Nov 8 12:11:17 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809C521F99BD for ; Fri, 8 Nov 2013 12:11:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgqGUQ5nuoju; Fri, 8 Nov 2013 12:11:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F36BA21F9C7B; Fri, 8 Nov 2013 12:11:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-malformed-mail@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131108201022.20564.84057.idtracker@ietfa.amsl.com> Date: Fri, 08 Nov 2013 12:10:22 -0800 From: IETF Secretariat Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 20:11:17 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-malforme= d-mail/ From derhoermi@gmx.net Fri Nov 8 12:23:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D594411E8240 for ; Fri, 8 Nov 2013 12:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.923 X-Spam-Level: X-Spam-Status: No, score=-2.923 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gW1fMiE1ZNSx for ; Fri, 8 Nov 2013 12:23:17 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC0D11E8221 for ; Fri, 8 Nov 2013 12:23:03 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.34.147]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0LaJWs-1W2hKt09Ec-00m1xr for ; Fri, 08 Nov 2013 21:23:01 +0100 From: Bjoern Hoehrmann To: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 08 Nov 2013 21:23:03 +0100 Message-ID: <349q79t09elodhhqf1rhib87j2plnc4slv@hive.bjoern.hoehrmann.de> References: <525D3D24.3030702@gmx.de> <525D7877.6080905@gmx.de> <024801cecb55$e478be20$4001a8c0@gateway.2wire.net> <303o795cbqscut34qbeeuevdmf3ig4769k@hive.bjoern.hoehrmann.de> <256o79p8kcls640qtmtkianfmu1sp1vi2b@hive.bjoern.hoehrmann.de> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:7PgQsDOfNULEJQXDc9yZL+k+rJ3AGgnG+vfqduxgjUAnhAgnP7o WD27wOoVW5MMoW/7P3+wL9aDfEiC3AGGTmRq7X3OBOcQ9/My1THNj++6KDfcR3s8+mQJEJH TuKIWsjvkfxl9/xzWmWbEkaoB7hxz6nUHBGPq0o8QNMILV+Yl7ysRniVnc+9neELSJTRQFp vywY76WdknzYX0qoqcRJA== Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call:draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Nov 2013 20:23:22 -0000 * Henry S. Thompson wrote: >Furthermore, your example is broken in another way -- XML _requires_ >any document not in UTF-8 or UTF-16 to begin with an XML encoding >declaration. The above data:... document does not do so. So it's not >an XML document at all, and so not a legitimate use of the >application/xml media type. >I don't know about 'recent', but it's widespread. IE9, Chrome >32.0.1700.4, Opera 12.16, Safari 5.1.7 and Firefox 25 all treat a BOM >as definitive despite the presence of a conflicting charset parameter >value, as do expat and rxp. libxml2 is the only counter-example I'm >aware of. I think I have made clear why I think this change needs much broader review, but I guess it does not hurt to offer the test case a third time, `data:application/xml;charset=utf-32,%FF%FE%00%00...`. I've put it up at http://www.websitedev.de/temp/application-xml-utf32-le.xml so people can easily check that IE9 treats that as UTF-32 even though it starts with a UTF-16 Unicode Signature. I also mentioned the W3C Markup Validator as an implementation that gives precedence to the `charset` parameter in the `Content-Type` header and I just checked, it, too, treats it as a UTF-32 document. http://www.websitedev.de/temp/application-xml-utf32-le-decl.xml is the same document with an encoding declaration. Whether an encoding is required can easily determined by grepping the XML specification for "In the absence". Accordingly the W3C Markup Validator finds no error with either document. For external entities for example In the absence of external character encoding information (such as MIME headers), parsed entities which are stored in an encoding other than UTF-8 or UTF-16 MUST begin with a text declaration (see 4.3.1 The Text Declaration) containing an encoding declaration You also list Expat. I was under the impression that Expat does not actually support reading HTTP responses. I downloaded the sources for expat-2.1.0 and the string `charset` only appears under `xmlwf/` which would be an expat-based utility, but even there the code seems dead. Similar for "Host", "Content-Type", "HTTP/", "winsock", "socket". So, I think Expat also does not do as you describe. And rxp-1.5.0 does seem to have some HTTP support, but a grep for the string `Content-Type` returns unsuccessfully. That usually means the Content-Type header is ignored entirely. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From cabo@tzi.org Fri Nov 8 12:48:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4009111E80EC for ; Fri, 8 Nov 2013 12:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.302 X-Spam-Level: X-Spam-Status: No, score=-106.302 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRdOKz+rkeg7 for ; Fri, 8 Nov 2013 12:48:41 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5095F11E80E9 for ; Fri, 8 Nov 2013 12:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id rA8KmTsc001989 for ; Fri, 8 Nov 2013 21:48:29 +0100 (CET) Received: from dhcp-9cfc.meeting.ietf.org (dhcp-9cfc.meeting.ietf.org [31.133.156.252]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 52FE4DA1; Fri, 8 Nov 2013 21:48:27 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Carsten Bormann Date: Fri, 8 Nov 2013 12:48:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "apps-discuss@ietf.org Discuss" X-Mailer: Apple Mail (2.1822) Subject: [apps-discuss] Meeting summary CoRE IETF88 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Nov 2013 20:48:48 -0000 FYI, here is the summary about this week=92s CoRE meetings that I sent = to=20 the CoRE mailing list. >> CoRE met for its first slot on Monday, 2013-11-04. >> Work is proceeding on the standards-track draft-ietf-core-observe and >> draft-ietf-core-block, as well as the informational >> draft-ietf-core-groupcomm and draft-ietf-core-http-mapping, with >> specific points raised to be handlded by the editors. We expect to >> submit -observe to the IESG this month, with -block on its heels. >> Work on draft-ietf-core-resource-directory is resuming, with some >> charter updating required. The new proposal >> draft-tcs-coap-no-response-option-04 received favorable reception and >> further work required before adoption was identified, in particular >> with respect to exploring the duality with -observe. >=20 > The second meeting of CoRE on Thursday, 2013-11-07, mostly focused on > the subject of authorization. Based on reports given from a number of > ad-hoc meetings that started on Sunday, as well as some impromptu > input, a set of five areas of desirable deliverables was identified. > CoRE is currently chartered at most for one of those, so charter > updates will be required (these can be combined with the outstanding > update for resource-directory); details need to be worked out after > the meeting, and work on understanding the technical approaches needs > to continue. One area that may not fit into the CoRE WG is the > authenticated multi-party transfer of authorization information; a > home for this (most likely in the security area) may need to be found > once it is better understood. We quickly looked at OMA (LWM2M) and > ETSI plugtest activities based on CoAP, and continued the discussion > on the format of the URIs to be used for alternative transports. We > ran out of time before coming to sleepy nodes and the transfer of > management information. Gr=FC=DFe, Carsten From tony@att.com Sat Nov 9 21:10:27 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09CA321E80CC for ; Sat, 9 Nov 2013 21:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.104 X-Spam-Level: X-Spam-Status: No, score=-103.104 tagged_above=-999 required=5 tests=[AWL=-0.506, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShxjVXo1S7E3 for ; Sat, 9 Nov 2013 21:10:19 -0800 (PST) Received: from tlpi046.enaf.dadc.sbc.com (egssmtp01.att.com [144.160.112.12]) by ietfa.amsl.com (Postfix) with ESMTP id 65FD121E80E6 for ; Sat, 9 Nov 2013 21:10:16 -0800 (PST) Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp01.att.com (8.14.4/8.14.4) with ESMTP id rAA59vlg003328 for ; Sat, 9 Nov 2013 23:10:01 -0600 Received: from [135.70.252.205] (vpn-135-70-252-205.vpn.east.att.com[135.70.252.205]) by maillennium.att.com (mailgw1) with ESMTP id <20131110050954gw100q0giqe> (Authid: tony); Sun, 10 Nov 2013 05:09:56 +0000 X-Originating-IP: [135.70.252.205] Message-ID: <527F1521.1050602@att.com> Date: Sun, 10 Nov 2013 00:09:53 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: General discussion of application-layer protocols X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------030108080007090405090201" Subject: [apps-discuss] A review of draft-ietf-appsawg-xml-mediatypes-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Nov 2013 05:10:27 -0000 This is a multi-part message in MIME format. --------------030108080007090405090201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This is a review of draft-ietf-appsawg-xml-mediatypes-04. I consider this draft to be "almost ready for publication". I saw one MAJOR- and one MEDIUM-level items that need to be taken care of, and a variety of NIT-level items that should be taken care of at some point. Tony Hansen ================ Section 3.1 Application/xml Registration and Section 9.1 UTF-8 Charset MEDIUM In both of these sections, the text reads "(e.g. 8BITMIME [RFC6152], ESMTP or NNTP)" and later "(e.g. HTTP)". This arrangement of text, particularly the comma after "8BITMIME", causes several implications to arise: 1) that 8BITMIME as defined in RFC6152 is something separate from ESMTP, 2) that ESMTP supports 8-bit text by itself 3) that ESMTP does not support binary Instead, ESMTP supports 8-bit text (only) when the 8BITMIME extension is used from RFC6152, AND ESMTP supports binary files (only) when the BINARY extension from RFC3030 is used. I would like to see two changes made to these two parenthetical clauses: (e.g. 8BITMIME ESMTP [RFC6152] or NNTP) (e.g. BINARY ESMTP [RFC3030] or HTTP) This clarifies the relationship between 8BITMIME and ESMTP. It also recognizes that ESMTP can be used with binary files and provides a nice counterpoint to HTTP, making the later comment "or even possible" more salient. ================ Section 3.6 Charset considerations NIT Add a period to the end of the sentence ending with "or its successor". ================ Section 4 The Byte Order Mark (BOM) and Charset Conversions When used in this fashion, "endianness" is usually the term used instead of "endian". ================ Section 5 Fragment Identifiers NIT 1st paragraph: Add a space before "Specifying". ================ Section 8.2 +xml Structured Syntax Suffix Registration NIT Within Fragment identifier considerations, add a space before "A fragment identifier of the form". MAJOR Under Change controller, it has a comment about "the XML specification" being a work product of the WWW MXL WorkingCore Group. While "the XML specification" is certainly related to +xml and this is nice historical information about XML, the statement says nothing about who the +xml change controller is. I'll make no comment about who the change controller *should* be; other people can discuss that if they so choose. But assuming that the authors wish to CHANGE the change controller from what was specified in RFC 6839, *) I think there should be explicit mention of this in the comments in section 8. *) The statement in section 8.2 needs to say *who* the change controller is. ================ Section 9.1 UTF-8 Charset See comments above for section 3.1. ================ Appendix A NIT You might consider adding a reference to RFC 6838. ================ Appendix B NIT The word "spec" should not have a period after it; it is not an abbreviation. --------------030108080007090405090201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This is a review of draft-ietf-appsawg-xml-mediatypes-04.

I consider this draft to be "almost ready for publication". I saw one MAJOR- and one MEDIUM-level items that need to be taken care of, and a variety of NIT-level items that should be taken care of at some point.

    Tony Hansen

================
Section 3.1 Application/xml Registration and Section 9.1 UTF-8 Charset

MEDIUM

In both of these sections, the text reads "(e.g. 8BITMIME [RFC6152], ESMTP or NNTP)" and later "(e.g. HTTP)". This arrangement of text, particularly the comma after "8BITMIME", causes several implications to arise:

    1) that 8BITMIME as defined in RFC6152 is something separate from ESMTP,
    2) that ESMTP supports 8-bit text by itself
    3) that ESMTP does not support binary

Instead, ESMTP supports 8-bit text (only) when the 8BITMIME extension is used from RFC6152, AND ESMTP supports binary files (only) when the BINARY extension from RFC3030 is used.


I would like to see two changes made to these two parenthetical clauses:

  (e.g. 8BITMIME ESMTP [RFC6152] or NNTP)
  (e.g. BINARY ESMTP [RFC3030] or HTTP)

This clarifies the relationship between 8BITMIME and ESMTP. It also recognizes that ESMTP can be used with binary files and provides a nice counterpoint to HTTP, making the later comment "or even possible" more salient.


================
Section 3.6 Charset considerations

NIT

Add a period to the end of the sentence ending with "or its successor".



================
Section 4 The Byte Order Mark (BOM) and Charset Conversions

When used in this fashion, "endianness" is usually the term used instead of "endian".



================
Section 5 Fragment Identifiers

NIT

1st paragraph:

Add a space before "Specifying".



================
Section 8.2 +xml Structured Syntax Suffix Registration

NIT

Within Fragment identifier considerations, add a space before "A fragment identifier of the form".


MAJOR

Under Change controller, it has a comment about "the XML specification" being a  work product of the WWW MXL WorkingCore Group. While "the XML specification" is certainly related to +xml and this is nice historical information about XML, the statement says nothing about who the +xml change controller is.

I'll make no comment about who the change controller *should* be; other people can discuss that if they so choose. But assuming that the authors wish to CHANGE the change controller from what was specified in RFC 6839,

    *) I think there should be explicit mention of this in the comments in section 8.
    *) The statement in section 8.2 needs to say *who* the change controller is.


================
Section 9.1 UTF-8 Charset

See comments above for section 3.1.


================
Appendix A

NIT

You might consider adding a reference to RFC 6838.



================
Appendix B

NIT

The word "spec" should not have a period after it; it is not an abbreviation.
--------------030108080007090405090201-- From tony@att.com Sat Nov 9 21:16:26 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A364121F9AE7 for ; Sat, 9 Nov 2013 21:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.054 X-Spam-Level: X-Spam-Status: No, score=-103.054 tagged_above=-999 required=5 tests=[AWL=-0.455, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dH5H8QrkbSA for ; Sat, 9 Nov 2013 21:16:20 -0800 (PST) Received: from tlpi046.enaf.dadc.sbc.com (egssmtp01.att.com [144.160.112.12]) by ietfa.amsl.com (Postfix) with ESMTP id EA83F21E80CC for ; Sat, 9 Nov 2013 21:16:19 -0800 (PST) Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp01.att.com (8.14.4/8.14.4) with ESMTP id rAA5GISS009248 for ; Sat, 9 Nov 2013 23:16:19 -0600 Received: from [135.70.252.205] (vpn-135-70-252-205.vpn.east.att.com[135.70.252.205]) by maillennium.att.com (mailgw1) with ESMTP id <20131110051618gw100q0gire> (Authid: tony); Sun, 10 Nov 2013 05:16:18 +0000 X-Originating-IP: [135.70.252.205] Message-ID: <527F16A2.6060805@att.com> Date: Sun, 10 Nov 2013 00:16:18 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> <5238B9E9.7010204@gmx.de> <525CF2A8.2090904@berkeley.edu> In-Reply-To: <525CF2A8.2090904@berkeley.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Nov 2013 05:16:26 -0000 On 10/15/2013 3:45 AM, Erik Wilde wrote: > On 2013-09-17 10:22 , Julian Reschke wrote: > >> Network Working Group C. Lilley >> Internet-Draft W3C >> Obsoletes: 3023 (if approved) M. Murata >> Updates: 4289, 6839 (if approved) International University of Japan > > i guess i have the same question here as julian: why would it update > RFC 6839, instead of just referencing it? if this is just the > technicality of RFC 6839 referencing this draft, then that would > probably answer my question. There's a very specific reason that I feel that this draft needs to update 6839 and not just reference it: it's changing the Change controller for +xml from the IETF/IESG to another entity. I don't think that is something that can/should be done just through a registry change. Tony From mnot@mnot.net Mon Nov 11 01:33:34 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD7221F9D9A for ; Mon, 11 Nov 2013 01:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqglrmOoQdfj for ; Mon, 11 Nov 2013 01:33:29 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9C99521F9E9D for ; Mon, 11 Nov 2013 01:31:41 -0800 (PST) Received: from [IPv6:::1] (unknown [50.56.234.188]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7CF7722E1F3; Mon, 11 Nov 2013 04:31:35 -0500 (EST) Content-Type: text/plain; charset=iso-8859-7 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Mark Nottingham In-Reply-To: Date: Mon, 11 Nov 2013 17:31:30 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5581799F-875E-4998-BC41-5BF5C5C5594A@mnot.net> References: <527825DB.6010105@gmx.de> <93E08AC0-9D97-4296-B139-DE439D3DE8B2@mnot.net> To: "Henry S. Thompson" X-Mailer: Apple Mail (2.1816) Cc: "Julian F. Reschke" , "apps-discuss@ietf.org Discuss" , "www-tag@w3.org WG" Subject: Re: [apps-discuss] Request that the WG reconsider section 3.4: Content Negotiation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Nov 2013 09:33:34 -0000 Hi Henry, Thanks for taking the time to make a suggestion. Based on the = discussions in Vancouver, I don=A2t see consensus to make a change like = this. Regards, On 6 Nov 2013, at 7:06 pm, Henry S. Thompson wrote: > Mark Nottingham writes: >=20 >> On 5 Nov 2013, at 4:18 am, Henry S. Thompson wrote: >>=20 >>>> Reactive conneg isn't just about 300s and 406s. Another example = would >>>> be a representation returned with a 200 response that contains = links >>>> to alternate versions of the content. That's what the >>>=20 >>> How is this in scope for discussion _in the HTTP spec._? People = (not >>> user agents, note) use 200 responses for a huge range of = interesting, >>> powerful, innovative things. We don't look in the HTTP spec. to = find >>> a discussion of them. >>=20 >> You seem to be thinking of HTTP as a separate layer from the >> application; as section 3.4 of p2 says, it=A2s defining a pattern of >> use, and that is certainly in scope for this specification, given >> that it was also in scope for RF2616. >=20 > I guess it's statements such as "HTTP provides mechanisms for content > negotiation" (1st para of 3.4) and "patterns . . . visible within the > protocol" (2nd para) which suggest that we're talking about the HTTP > layer, not a more general functionality. >=20 >> We talked about this issue at the WG meeting yesterday. Based upon >> that discussion, we decided to close this issue. Looking at >> = , >> I can=A2t see any immediate clarifications that would help; if you = can >> suggest some, please do bring them to our attention. >=20 > Thanks for your time. Here's a quick redraft of 3.4 (the first para > is nearly unchanged) -- this is the direction I think would be a > helpful change. >=20 > -------- > 3.4 MSc Content Negotiation >=20 > When responses convey payload information, whether indicating a > success or an error, the origin server often has different ways of > representing that information; for example, in different formats, > languages, or encodings. Likewise, different users or user agents > might have differing capabilities, characteristics, or preferences > that could influence which representation, among those available, > would be best to deliver. For this reason, HTTP provides mechanisms > supporting content negotiation, that is, means for clients and servers > to select, or involve users and user agents in selecting, among > alternative representations. >=20 > Note that, in all cases, HTTP is not aware of resource semantics. The > consistency with which an origin server responds to requests, over > time and over the varying dimensions of content negotiation, and thus > the "sameness" of a resource's observed representations over time, is > determined entirely by whatever entity or algorithm selects or > generates those responses. HTTP pays no attention to the man behind > the curtain. >=20 > In particular, this specification defines headers and response codes > for use in exchanges where multiple representations are, or may be, > involved. Accept headers in requests (Section 5.3) allow clients to > signal preferred alternatives. Such explicit preferences may derive > from user agent capabilities (for example with respect to image format > support), user preferences (for example with respect to natural > language) or local context (for example with respect to media type). > Servers may also infer implicit preferences from other properties of > requests such as the network address or User-Agent header. > Response codes (Sections 6.4.1 and 6.5.6) and response headers > (Sections 7.1.4 and 7.1.2) allow servers (and proxies) to signal the > success or failure in any attempt to satisfy client preferences > (implicit or explicit) as well as the availability of alternatives. >=20 > Although the most common use of these mechanisms is for clients to > include Accept headers in requests, and servers (or proxies) to select > among available alternatives based on those headers, a wide range of > other patterns of use exist, including ones where the initiative is > all on the server side, where for example a 300 response may accompany > a payload offering what amounts to spelling correction, as an > alternative to a 404. Many of these patterns depend on particular > media types and/or user agents. > ------------------ > and leave it at that. Some corresponding changes to the referenced > sections would likely be necessary to pick up a few of the details > from the now-deleted 3.4.1 and 3.4.2. >=20 > ht >=20 > "Whereof one cannot speak, thereof one must be silent" > --=20 > Henry S. Thompson, School of Informatics, University of = Edinburgh > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 = 650-4440 > Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ > [mail from me _always_ has a .sig like this -- mail without it is = forged spam] -- Mark Nottingham http://www.mnot.net/ From ht@inf.ed.ac.uk Tue Nov 12 05:08:45 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A71F11E8133 for ; Tue, 12 Nov 2013 05:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.084 X-Spam-Level: X-Spam-Status: No, score=-7.084 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owbTlojiNn0o for ; Tue, 12 Nov 2013 05:08:27 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 672B111E80F8 for ; Tue, 12 Nov 2013 05:08:27 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rACD7cFE017228; Tue, 12 Nov 2013 13:07:38 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rACD7cZb027472; Tue, 12 Nov 2013 13:07:38 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rACD7cvk011107; Tue, 12 Nov 2013 13:07:38 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rACD7cnW011103; Tue, 12 Nov 2013 13:07:38 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Tony Hansen References: <527F1521.1050602@att.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 12 Nov 2013 13:07:38 +0000 In-Reply-To: <527F1521.1050602@att.com> (Tony Hansen's message of "Sun\, 10 Nov 2013 00\:09\:53 -0500") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] A review of draft-ietf-appsawg-xml-mediatypes-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 13:08:45 -0000 Tony Hansen writes: > This is a review of draft-ietf-appsawg-xml-mediatypes-04. > > I consider this draft to be "almost ready for publication". I saw one > MAJOR- and one MEDIUM-level items that need to be taken care of, and a > variety of NIT-level items that should be taken care of at some point. Thanks very much for this -- please see below for responses, except for the MAJOR one, which I'll reply to separately. > Section 3.1 Application/xml Registration and Section 9.1 UTF-8 Charset > > MEDIUM > > In both of these sections, the text reads "(e.g. 8BITMIME [RFC6152], > ESMTP or NNTP)" and later "(e.g. HTTP)". This arrangement of text, > particularly the comma after "8BITMIME", causes several implications to > arise: > > 1) that 8BITMIME as defined in RFC6152 is something separate from ESMTP, > 2) that ESMTP supports 8-bit text by itself > 3) that ESMTP does not support binary > > Instead, ESMTP supports 8-bit text (only) when the 8BITMIME extension is > used from RFC6152, AND ESMTP supports binary files (only) when the > BINARY extension from RFC3030 is used. > > > I would like to see two changes made to these two parenthetical clauses: > > (e.g. 8BITMIME ESMTP [RFC6152] or NNTP) > (e.g. BINARY ESMTP [RFC3030] or HTTP) > > This clarifies the relationship between 8BITMIME and ESMTP. It also > recognizes that ESMTP can be used with binary files and provides a nice > counterpoint to HTTP, making the later comment "or even possible" more > salient. This section dates back before my time as editor, and indeed appears in 3023 (without the comma!), but what you say makes sense, and I've changed the text accordingly. > ================ > Section 3.6 Charset considerations > > NIT > > Add a period to the end of the sentence ending with "or its successor". It's not a sentence in the original -- I've added an ellipsis. > ================ > Section 4 The Byte Order Mark (BOM) and Charset Conversions > > When used in this fashion, "endianness" is usually the term used instead > of "endian". This and all other nits corrected as you suggest. > ================ > Section 9.1 UTF-8 Charset > > See comments above for section 3.1. Changed in a parallel way. Thanks again, these changes will all appear in the next version, ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From ht@inf.ed.ac.uk Tue Nov 12 05:21:48 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FE511E815B for ; Tue, 12 Nov 2013 05:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.76 X-Spam-Level: X-Spam-Status: No, score=-6.76 tagged_above=-999 required=5 tests=[AWL=-0.761, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSntSX4Cc5WF for ; Tue, 12 Nov 2013 05:21:43 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 84E1F11E813D for ; Tue, 12 Nov 2013 05:21:43 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rACDKvfE024803; Tue, 12 Nov 2013 13:20:57 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rACDKuiO028073; Tue, 12 Nov 2013 13:20:56 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rACDKvDk011486; Tue, 12 Nov 2013 13:20:57 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rACDKvrB011482; Tue, 12 Nov 2013 13:20:57 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Tony Hansen References: <527F1521.1050602@att.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 12 Nov 2013 13:20:57 +0000 In-Reply-To: <527F1521.1050602@att.com> (Tony Hansen's message of "Sun\, 10 Nov 2013 00\:09\:53 -0500") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Cc: apps-discuss@ietf.org Subject: [apps-discuss] Change controller for +xml (was Re: A review of draft-ietf-appsawg-xml-mediatypes-04) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 13:21:48 -0000 Tony Hansen writes: > Section 8.2 +xml Structured Syntax Suffix Registration > > MAJOR > > Under Change controller, it has a comment about "the XML > specification" being a work product of the WWW MXL WorkingCore > Group. While "the XML specification" is certainly related to +xml > and this is nice historical information about XML, the statement > says nothing about who the +xml change controller is. > > I'll make no comment about who the change controller *should* be; > other people can discuss that if they so choose. But assuming that > the authors wish to CHANGE the change controller from what was > specified in RFC 6839, > > *) I think there should be explicit mention of this in the > comments in section 8. Where in section 8, exactly? > *) The statement in section 8.2 needs to say *who* the change > controller is. I would welcome some further guidance on this point. The change controller field for the /xml media types themselves, in sections 3.1, 3.3 and 3.5, uses exactly the same (after typo corrected) wording. I also note that other media type registrations from the W3C (e.g. xslt+xml [1], exi [2]) use the same wording, plus a further sentence: "The W3C has change control over this specification". So, two questions: 1) Is there any reason not to use the same wording in all of 3.1, 3.3 and 3.5? 2) If so, should that wording be The XML specification is a work product of the World Wide Web Consortium's XML Core Working Group. The W3C has change control over this specification. ? If not, then what? Thanks, ht [1] http://www.w3.org/TR/2007/REC-xslt20-20070123/#media-type-registration [2] http://www.w3.org/TR/2009/CR-exi-20091208/#mediaTypeRegistration -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From julian.reschke@gmx.de Tue Nov 12 05:22:50 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E0111E815C for ; Tue, 12 Nov 2013 05:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.178 X-Spam-Level: X-Spam-Status: No, score=-104.178 tagged_above=-999 required=5 tests=[AWL=-1.579, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ik4UCMe6v-BK for ; Tue, 12 Nov 2013 05:22:44 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 90D0811E813D for ; Tue, 12 Nov 2013 05:22:42 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MI5Ve-1Viy1H0yL8-003smG for ; Tue, 12 Nov 2013 14:22:41 +0100 Message-ID: <52822B9A.3050700@gmx.de> Date: Tue, 12 Nov 2013 14:22:34 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , "t.petch" , Erik Wilde , Dave Cridland References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> <5238B9E9.7010204@gmx.de> <525CF2A8.2090904@berkeley.edu> <6vcq5950d7mclheqfcjna5hdue19arqfm8@hive.bjoern.hoehrmann.de> <525D386B.3070705@gmx.de> <525D3D24.3030702@gmx.de> <525D7877.6080905@gmx.de> <024801cecb55$e478be20$4001a8c0@gateway.2wire.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:C6FMzcqjN4DrPDYeL5id4WPQ8mTLRzJZJleKG7axwqYZtMPPomD /64rZhXaYnG4PhFVayfVZVNiPoK+k6S7G0QbPRyldtM038bvBsznxNPeFRU06LcpzOSwflS klpIpVFItmccoRhwZ9AEOTsc+IQYST39l5z2AR56TIRTlzJtWplTQlpQUGok4wtNENiny/B jPyl+bkAdZZvP9iwLICRw== Cc: Bjoern Hoehrmann , IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call:draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 13:22:50 -0000 On 2013-11-07 22:44, Murray S. Kucherawy wrote: > Colleagues, but specifically Tom, Erik, Dave, Julian and Bjoern: > > Can you have a look at the latest version of this draft (or the diffs, > available via the tracker) and let us know if you think it's ready to go > in its latest form? > > Thanks, > -MSK, APPSAWG co-chair > ... I'm generally happy with the changes, and defer charset/BOM discussions to Björn. With respect to HTTP references, I'd like the spec to: - normatively reference httpbis - only informatively reference RFC2616 (if needed at all) In particular: > NOTE: Section 5.3.2HTTPbis [HTTPbis] does not support Accept > headers of the form "Accept: */*+xml" and so this header MUST NOT > be used in this way. s/Section 5.3.2HTTPbis [HTTPbis]/Section 5.3.2 of [RFCxxxx]/ > [HTTPbis] Fielding, R., "Hypertext Transfer Protocol (HTTP/1.1) > [revised]", ietf-httpbis-p2-semantics (work in progress), > September 2013. Substitute with: [RFCxxxx] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", draft-ietf-httpbis-p2-semantics-24 (work in progress), September 2013. also: > encoded in base64. For binary clean transports (e.g. HTTP > [RFC2616]), no content-transfer-encoding is necessary (or even > possible, in the case of HTTP) for 7bit, 8bit or binary data. s/HTTP [RFC2616]/HTTP [RFCxxxx]/ > As described in [RFC2781], the UTF-16 family must not be used with > media types under the top-level type "text" except over HTTP or HTTPS > (see section 19.4.2 of [RFC2616] for details). Hence this example is s/see section 19.4.2 of [RFC2616]/see Appendix A.2 of [RFCxxxx]/ > default character sets for the text/xml... types has been resolved by > [HTTPbis] changing [RFC2616] by removing the ISO-8859-1 default and > not defining any default at all, as well as [RFC6657] updating s/[HTTPbis]/[RFCxxxx]/ Best regards, Julian From ht@inf.ed.ac.uk Tue Nov 12 06:18:49 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7965111E814C for ; Tue, 12 Nov 2013 06:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.023 X-Spam-Level: X-Spam-Status: No, score=-7.023 tagged_above=-999 required=5 tests=[AWL=-0.424, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyEp79NgQGUd for ; Tue, 12 Nov 2013 06:18:43 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 18D4F11E815A for ; Tue, 12 Nov 2013 06:18:32 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rACEIJs8000043; Tue, 12 Nov 2013 14:18:19 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rACEIItN030256; Tue, 12 Nov 2013 14:18:18 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rACEII1B012822; Tue, 12 Nov 2013 14:18:18 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rACEIHse012818; Tue, 12 Nov 2013 14:18:17 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Julian Reschke References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> <5238B9E9.7010204@gmx.de> <525CF2A8.2090904@berkeley.edu> <6vcq5950d7mclheqfcjna5hdue19arqfm8@hive.bjoern.hoehrmann.de> <525D386B.3070705@gmx.de> <525D3D24.3030702@gmx.de> <525D7877.6080905@gmx.de> <024801cecb55$e478be20$4001a8c0@gateway.2wire.net> <52822B9A.3050700@gmx.de> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 12 Nov 2013 14:18:17 +0000 In-Reply-To: <52822B9A.3050700@gmx.de> (Julian Reschke's message of "Tue\, 12 Nov 2013 14\:22\:34 +0100") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Cc: IETF Apps Discuss , Bjoern Hoehrmann Subject: Re: [apps-discuss] Working Group Last Call:draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 14:18:50 -0000 Julian Reschke writes: > I'm generally happy with the changes, and defer charset/BOM > discussions to Bj=F6rn. > > With respect to HTTP references, I'd like the spec to: > > - normatively reference httpbis > - only informatively reference RFC2616 (if needed at all) I'm happy to do this, but would like confirmation from Murray that this is acceptable IETF practice, given that HTTPbis is still in Last Call. ht --=20 Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged s= pam] From julian.reschke@gmx.de Tue Nov 12 06:25:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD57021E8063 for ; Tue, 12 Nov 2013 06:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.118 X-Spam-Level: X-Spam-Status: No, score=-104.118 tagged_above=-999 required=5 tests=[AWL=-1.519, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3j4LVKsrc4l5 for ; Tue, 12 Nov 2013 06:25:06 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id BDFAB11E80FA for ; Tue, 12 Nov 2013 06:25:05 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MEFlg-1VvZvM1cuO-00FQ5m for ; Tue, 12 Nov 2013 15:25:04 +0100 Message-ID: <52823A3E.6040609@gmx.de> Date: Tue, 12 Nov 2013 15:25:02 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Henry S. Thompson" References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> <5238B9E9.7010204@gmx.de> <525CF2A8.2090904@berkeley.edu> <6vcq5950d7mclheqfcjna5hdue19arqfm8@hive.bjoern.hoehrmann.de> <525D386B.3070705@gmx.de> <525D3D24.3030702@gmx.de> <525D7877.6080905@gmx.de> <024801cecb55$e478be20$4001a8c0@gateway.2wire.net> <52822B9A.3050700@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:sJNyw/HsBhYDqE3GA/fgxkPjE3SuMMPpNzCeWXKraOA5cL6CDSM nEHHrI1wZzM9QbCmWC2zBpfEwpi4I+/G8FpsUgSyeRXCcC2dj80w4Cn9LWS5nQFUBsCNl7A nc93vjf9BtMIOTfnIeO7Z77OxdQLz6jW2HDwQNn+85IwX/Va2RvvEdrzVe3sCkMCmQ1fU/L 3cm0pgaGpWsvDEvezly5g== Cc: IETF Apps Discuss , Bjoern Hoehrmann Subject: Re: [apps-discuss] Working Group Last Call:draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 14:25:12 -0000 On 2013-11-12 15:18, Henry S. Thompson wrote: > Julian Reschke writes: > >> I'm generally happy with the changes, and defer charset/BOM >> discussions to Björn. >> >> With respect to HTTP references, I'd like the spec to: >> >> - normatively reference httpbis >> - only informatively reference RFC2616 (if needed at all) > > I'm happy to do this, but would like confirmation from Murray that > this is acceptable IETF practice, given that HTTPbis is still in Last > Call. HTTPbis is past IETF LC, so in theory it should be ahead of this document. Best regards, Julian From superuser@gmail.com Tue Nov 12 16:11:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D47121E80BF for ; Tue, 12 Nov 2013 16:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSfHqUd-37gf for ; Tue, 12 Nov 2013 16:11:03 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6336321E8098 for ; Tue, 12 Nov 2013 16:11:03 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id ey11so4534699wid.12 for ; Tue, 12 Nov 2013 16:11:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BTepBw/4CTd0CEGiaVew43kFiStJGEjZzeAb1JXj7DI=; b=Sv7hR0nNzevLX945vuq68173gybOAWX2XpOMXLAYHD+J2u/MJphf+Z5D7GhcXeSuFb wF83lOloRF1pTHbD+6o8A+RT8J+38g1yaZhaBCd3VVwZPcUhvmDVpP/JHSADW3r64rbO H18So6dlEmMDK8oR/gRqbhCI3uhmId4bBsumZeRi08rI6I6VWysmAAZOnZ2c9+3BPkD0 FdXcbIrFfV270x9LawDtkG5R6Ggt//PVAMGiA+iSeRAq4tB8+lqWV/ZyRSIDp8uQuP9Q yLmvpfhDM8Dou4DwVAUNuahLVyGMWhC+NTFAqbnPZhfQYRb9jvHZkGgntrT3tpDOp+AH A4RQ== MIME-Version: 1.0 X-Received: by 10.194.89.233 with SMTP id br9mr28842631wjb.15.1384301462510; Tue, 12 Nov 2013 16:11:02 -0800 (PST) Received: by 10.181.13.230 with HTTP; Tue, 12 Nov 2013 16:11:02 -0800 (PST) In-Reply-To: References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> <5238B9E9.7010204@gmx.de> <525CF2A8.2090904@berkeley.edu> <6vcq5950d7mclheqfcjna5hdue19arqfm8@hive.bjoern.hoehrmann.de> <525D386B.3070705@gmx.de> <525D3D24.3030702@gmx.de> <525D7877.6080905@gmx.de> <024801cecb55$e478be20$4001a8c0@gateway.2wire.net> <52822B9A.3050700@gmx.de> Date: Tue, 12 Nov 2013 16:11:02 -0800 Message-ID: From: "Murray S. Kucherawy" To: "Henry S. Thompson" Content-Type: multipart/alternative; boundary=089e0102fb5cef629104eb03cc66 Cc: Bjoern Hoehrmann , IETF Apps Discuss , Julian Reschke Subject: Re: [apps-discuss] Working Group Last Call:draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Nov 2013 00:11:04 -0000 --089e0102fb5cef629104eb03cc66 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Nov 12, 2013 at 6:18 AM, Henry S. Thompson wrote: > > I'm generally happy with the changes, and defer charset/BOM > > discussions to Bj=F6rn. > > > > With respect to HTTP references, I'd like the spec to: > > > > - normatively reference httpbis > > - only informatively reference RFC2616 (if needed at all) > > I'm happy to do this, but would like confirmation from Murray that > this is acceptable IETF practice, given that HTTPbis is still in Last > Call. > > I think you can just refer to HTTPbis as a work-in-progress, and the RFC Editor will hold this document until that one is ready. It doesn't have to delay our part of the process. -MSK --089e0102fb5cef629104eb03cc66 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 12, 2013 at 6:18 AM, Henry S. Thompson <ht@inf.= ed.ac.uk> wrote:
> I'm generally hap= py with the changes, and defer charset/BOM
> discussions to Bj=F6rn.
>
> With respect to HTTP references, I'd like the spec to:
>
> - normatively reference httpbis
> - only informatively reference RFC2616 (if needed at all)

I'm happy to do this, but would like confirmation from Murray tha= t
this is acceptable IETF practice, given that HTTPbis is still in Last
Call.

<= br>
I think you can just refer to HTTPbis as a work-in-progress, and t= he RFC Editor will hold this document until that one is ready.=A0 It doesn&= #39;t have to delay our part of the process.

-MSK
--089e0102fb5cef629104eb03cc66-- From superuser@gmail.com Tue Nov 12 16:13:48 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF10D21F9F51 for ; Tue, 12 Nov 2013 16:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNhCcAdjkxtS for ; Tue, 12 Nov 2013 16:13:48 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id E1B8B21F9F1B for ; Tue, 12 Nov 2013 16:13:47 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id cb5so4496347wib.2 for ; Tue, 12 Nov 2013 16:13:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bE6yFa/Q4oZku8y/R7qRNkJQYmKSUAIGXVM6NcV7pyE=; b=wacrxkB0pB/0G8OOu0kkGuhdoPYq1Q3Hd5eHX+dMSfWr4zciRC6/ah1rrOsZFMFzCP DErBj2sZtRt0k4slKv6MB8cxmYp6rwhhyi1cwSaOdPXvesYDfdcNNmIztDfWwUpv61tg LOEY8BrVQJS07ykSrLTkgQ8kpMcGBP7jhRpvwGHJkhEIhz9wt9DBLH7TNg/s6MC1HT/d gD4n4THs0qYxi+MGr7KM3J9xwwr3kubqzymwr2gFk7n+06zEPO17OORP6HGsoPd4sK5N OZ3n0Velz5mK0IqTsr3rg3cD539uSGk0c0DwcRJ+xSWy3ej/Bb4iEn+TnmGeSSY4j8vK sg0w== MIME-Version: 1.0 X-Received: by 10.194.89.233 with SMTP id br9mr28849819wjb.15.1384301626988; Tue, 12 Nov 2013 16:13:46 -0800 (PST) Received: by 10.181.13.230 with HTTP; Tue, 12 Nov 2013 16:13:46 -0800 (PST) In-Reply-To: <20131029190235.20826.qmail@joyce.lan> References: <01P05GVOY8RU00004R@mauve.mrochek.com> <20131029190235.20826.qmail@joyce.lan> Date: Tue, 12 Nov 2013 16:13:46 -0800 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=089e0102fb5cbd1e6804eb03d64a Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] SMTP extension Re: I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Nov 2013 00:13:48 -0000 --089e0102fb5cbd1e6804eb03d64a Content-Type: text/plain; charset=ISO-8859-1 So to you two guys in particular, does the new draft, which dropped the header field, satisfy your concerns? I saw John's editorial nits, so let's assume those are resolved... anything else we need to do here? -MSK On Tue, Oct 29, 2013 at 12:02 PM, John Levine wrote: > >I have to say I'm not wild about the notion of downgrading the RRVS > extension > >to the header mechanism on the fly, because it grots up code that > otherwise is > >able to do things like BDAT in a single, simple operation. But it is > >implementable. > > I don't think anyone is, but considering the number of relay servers > that exist, we need to say something. > > I'm pretty much with Murray, note it and don't try to solve the > problem. > > If a relay is able to remember the RRVS envelope info, it can pass it > along in the next SMTP session. Or it could stick it in the message > as an RRVS header, although since RRVS isn't a trace header that runs the > risk of breaking signatures and other confusion. > > R's, > John > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --089e0102fb5cbd1e6804eb03d64a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
So to you two guys in particular, does the new draft,= which dropped the header field, satisfy your concerns?=A0 I saw John's= editorial nits, so let's assume those are resolved... anything else we= need to do here?

-MSK


On Tue, Oct 29, 2013 at 12:02 PM, John Levine = <johnl@taugh.com> wrote:
>I have to say I'm = not wild about the notion of downgrading the RRVS extension
>to the header mechanism on the fly, because it grots up code that other= wise is
>able to do things like BDAT in a single, simple operation. But it is >implementable.

I don't think anyone is, but considering the number of relay serv= ers
that exist, we need to say something.

I'm pretty much with Murray, note it and don't try to solve the
problem.

If a relay is able to remember the RRVS envelope info, it can pass it
along in the next SMTP session. =A0Or it could stick it in the message
as an RRVS header, although since RRVS isn't a trace header that runs t= he
risk of breaking signatures and other confusion.

R's,
John
___________________________________= ____________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--089e0102fb5cbd1e6804eb03d64a-- From prvs=002259c8a6=johnl@taugh.com Tue Nov 12 17:41:15 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CAF11E8163 for ; Tue, 12 Nov 2013 17:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNkDaEV-a9KA for ; Tue, 12 Nov 2013 17:41:11 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id EEE5A11E816D for ; Tue, 12 Nov 2013 17:41:10 -0800 (PST) Received: (qmail 18202 invoked from network); 13 Nov 2013 01:41:10 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Nov 2013 01:41:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type:user-agent:cleverness; s=5282d8b6.xn--btvx9d.k1310; i=sendmail-bs@submit.iecc.com; bh=2ruWpyQtYg3RmYvOxh1zGUUf4E4MMNw+VMmZ9zXcEVw=; b=ToF9GiEh3N7C160rr+obNhFQjAZ+VICQg+K3rOKfID/l/oxqZxlJwKTomaadHbKiHsbiaHWrceTqy1Tjv0MfayDYUf+lDtMlgo4dokIvOAhjKMbmybrfJ4hFZBXmr4Vj8deOcSvYRz+A6XIB2lH7sbUCah6gCWP1agmLIdYUkoSm8LEQoatwYNEavPAmXRsyuejXL6tJXaGvZPxOLqT2KhQqNQN500AXUxHnS7q74yFeqI29yB6wMBjGCd8CGfZt DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type:user-agent:cleverness; s=5282d8b6.xn--btvx9d.k1310; olt=sendmail-bs@submit.iecc.com; bh=2ruWpyQtYg3RmYvOxh1zGUUf4E4MMNw+VMmZ9zXcEVw=; b=IfgSQ+QKQRgh0/o+OSRfGsSV1PCz3gOADHlgL7SSXNYf+WEkiL4JtozfpkRUDiZFxsY3T5eekylQcYYjQoaypji0g6np0xE0jMpdoiZKaM+N79CQ/xUDe5T1wbnpu+vpbBzza6LrubL0MYjYTskvUt95UjpaJQ4dZ9rzZGJSVx7etuANMzv8MjHO0lyvC0rGe/i/ZQhwjT2j66s+DcOKwITZ5qYEwCdOhmnYbQsnSOwfCbYaruqUYyJ880ai76AA Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 13 Nov 2013 01:41:09 -0000 Date: Tue, 12 Nov 2013 20:41:09 -0500 (EST) From: John R Levine To: "Murray S. Kucherawy" In-Reply-To: Message-ID: References: <01P05GVOY8RU00004R@mauve.mrochek.com> <20131029190235.20826.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] SMTP extension Re: I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Nov 2013 01:41:15 -0000 > So to you two guys in particular, does the new draft, which dropped the > header field, satisfy your concerns? I saw John's editorial nits, so let's > assume those are resolved... anything else we need to do here? Technically it's OK, although if there's no RRVS header I'd want to add an Authentication-Results: clause, e.g.: rrvs=2013-12-31T23:59:59 smtp.mailfrom=someone@example.com ; Have you asked your co-author whether Yahoo is planning to implement this as an SMTP extension? If not and there aren't any other large mail systems planning to do so, my advice would be to abandon the draft and spend your limited time on something that's likely to get some traction. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From wmills@yahoo-inc.com Tue Nov 12 17:48:15 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D2F21F9CA8 for ; Tue, 12 Nov 2013 17:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.798 X-Spam-Level: X-Spam-Status: No, score=-16.798 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWH71KIZDL8z for ; Tue, 12 Nov 2013 17:48:10 -0800 (PST) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7055F21E8140 for ; Tue, 12 Nov 2013 17:48:08 -0800 (PST) Received: from GQ1-EX10-CAHT17.y.corp.yahoo.com (gq1-ex10-caht17.corp.gq1.yahoo.com [10.73.119.198]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id rAD1lmcm052593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 12 Nov 2013 17:47:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1384307269; bh=PEBVL/RTuRFYX+zczxap2PPXtT0PGuSwAB3qv6LrFdg=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=xOBfYa0ymLyR6RxhcOYygFd+OUA1mDUOZ2DSEfTSmAR7h+F45I+p7QPWeMFz5GzXK ZYaKjTRuvjipy5MqN1+pwOlnkbh2C+QBvznmPR8SyfELb1+lUycGsgqB4nZuwsttMG oq308ZrUXVKbTitebrV4sjhVw4iVB25ySD1CHrVo= Received: from omp1085.mail.ne1.yahoo.com (98.138.101.174) by GQ1-EX10-CAHT17.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 17:47:47 -0800 Received: (qmail 40472 invoked by uid 1000); 13 Nov 2013 01:47:47 -0000 Received: (qmail 55170 invoked by uid 60001); 13 Nov 2013 01:47:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1384307266; bh=yc698Z+atU+U7owZVuWdBRCeC2s3fhlPoSEvrO//2vY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=C87UQhmnMrvhEBVxH+VAm6+vghT19o96YDVZD4emOEsMUwDr8vVUiWQZKs31IMr1j2xn9HKs13eGbFWLqCktWf0B2szdzUguAZ0qzIzbk77rtjSZ2g5m8500ephN9z3HDUH/irkp6I9/ZNEE6Du/vYZg1TJlxxE2SwKYoHTf1Ac= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=BWnxVU0i0X3Fs8d+WMscfWhCrDFJXcaInaJYjG+dU9/UUv7vMM7WDKCibAaFxVXzjkKZoaKuvqbNeiC3fia9eeCYe3CVO2SJw6szPCufPEGhIqjXSsUbWRXDY/e8iEkl0kjRsHxGm0/7IkvGopNya76iJdzapzrRJ9vNN6k8oTo=; X-YMail-OSG: 8SPBKhMVM1lOw8SYC.y7gbRV3enfaLBnh2k4cMKIQUoC6t4 sIZKnE0vZg52387bYxsIO4o0Dkuh7_m6oQ9xxfodykRWFhdH5sZfZdKv.Yud 8deSbY5S_8lu3IhSMjOo7IUEgl5QouPbZGG3gkTMkuiOkkFoAsApGUu0HN_K eKVcCxkkTcpHRFkK9Bi.qgLsJYRT_a5dc1i.C3KaI2GFOUA.lJVukciI0.qC kGNuGkAigWdZMYThQgjO52g0ku6L75WTjusuJj0m3TEyxdlNsAOiTiIPTjAm Xok98r5RYS3bqHItBwJV36zNr Received: from [209.131.62.113] by web125603.mail.ne1.yahoo.com via HTTP; Tue, 12 Nov 2013 17:47:46 PST X-Rocket-MIMEInfo: 002.001, U28sIGFiYW5kb24gdGhlIFNNVFAgZXh0ZW5zaW9uIGFuZCB0aGUgcnVubmluZyBjb2RlIHdpdGggbWFqb3IgaW50ZXJvcCBib3RoP8KgIFRoYXQgZG9lc24ndCBzb3VuZCBsaWtlIGEgd2luLgoKSSBkb24ndCBrbm93IGhvdyBxdWlja2x5IHdlJ2QgaW1wbGVtZW50IGFuIFNNVFAgZXh0ZW5zaW9uLgoKCsKgCi1iaWxsCgoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCldpbGxpYW0gSi4gTWlsbHMKIlBhcmFub2lkIiBZYWhvbyEKCgoKCgpPbiBUdWVzZGF5LCBOb3ZlbWJlciAxMiwgMjAxMyA1OjQBMAEBAQE- X-Mailer: YahooMailWebService/0.8.163.597 References: <01P05GVOY8RU00004R@mauve.mrochek.com> <20131029190235.20826.qmail@joyce.lan> Message-ID: <1384307266.54777.YahooMailNeo@web125603.mail.ne1.yahoo.com> Date: Tue, 12 Nov 2013 17:47:46 -0800 From: Bill Mills To: John R Levine , "Murray S. Kucherawy" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="933233344-565727097-1384307266=:54777" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 307269000 Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] SMTP extension Re: I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 01:48:15 -0000 --933233344-565727097-1384307266=:54777 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So, abandon the SMTP extension and the running code with major interop both= ?=A0 That doesn't sound like a win.=0A=0AI don't know how quickly we'd impl= ement an SMTP extension.=0A=0A=0A=A0=0A-bill=0A=0A=0A=0A-------------------= -------------=0AWilliam J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A=0A=0A=0AOn Tu= esday, November 12, 2013 5:41 PM, John R Levine wrote:=0A= =0A> So to you two guys in particular, does the new draft, which dropped t= he=0A> header field, satisfy your concerns?=A0 I saw John's editorial nits,= so let's=0A> assume those are resolved... anything else we need to do here= ?=0A=0ATechnically it's OK, although if there's no RRVS header I'd want to = add an =0AAuthentication-Results: clause, e.g.:=0A=0A=A0 rrvs=3D2013-12-31T= 23:59:59 smtp.mailfrom=3Dsomeone@example.com ;=0A=0AHave you asked your co-= author whether Yahoo is planning to implement this =0Aas an SMTP extension?= =A0 If not and there aren't any other large mail =0Asystems planning to do = so, my advice would be to abandon the draft and =0Aspend your limited time = on something that's likely to get some traction.=0A=0ARegards,=0AJohn Levin= e, johnl@taugh.com, Taughannock Networks, Trumansburg NY=0APlease consider = the environment before reading this e-mail.=0A=0A__________________________= _____________________=0Aapps-discuss mailing list=0Aapps-discuss@ietf.org= =0Ahttps://www.ietf.org/mailman/listinfo/apps-discuss --933233344-565727097-1384307266=:54777 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
So, aband= on the SMTP extension and the running code with major interop both?  T= hat doesn't sound like a win.

I don't know how quickly we'd implemen= t an SMTP extension.
 
-bill=


--------------------------------
William J. Mills
"Paran= oid" Yahoo!



On= Tuesday, November 12, 2013 5:41 PM, John R Levine <johnl@taugh.com> wrote:
> So to you two guys in= particular, does the new draft, which dropped the
> h= eader field, satisfy your concerns?  I saw John's editorial nits, so l= et's
> assume those are resolved... anything else we n= eed to do here?

Technically it's OK, a= lthough if there's no RRVS header I'd want to add an
Aut= hentication-Results: clause, e.g.:

&nb= sp; rrvs=3D2013-12-31T23:59:59 smtp.mailfrom=3Dsomeone@ex= ample.com ;

Have you asked your co= -author whether Yahoo is planning to implement this
as a= n SMTP extension?  If not and there aren't any other large mail
systems planning to do so, my advice would be to abandon the draft and
spend your limited time on something that's likely to get some tr= action.

Regards,
Joh= n Levine, johnl@taugh.com, Taughannock Networks, Trumansburg = NY
Please consider the environment before reading this e-= mail.

____= ___________________________________________
apps-discuss = mailing list
apps-discuss@ietf.org<= /a>
https://www.ietf.org/mailman/lis= tinfo/apps-discuss


--933233344-565727097-1384307266=:54777-- From prvs=002259c8a6=johnl@taugh.com Tue Nov 12 18:17:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86EF11E80DE for ; Tue, 12 Nov 2013 18:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpGp6RMWoouS for ; Tue, 12 Nov 2013 18:16:59 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B5A4721E80A1 for ; Tue, 12 Nov 2013 18:16:57 -0800 (PST) Received: (qmail 23664 invoked from network); 13 Nov 2013 02:16:51 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Nov 2013 02:16:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type:user-agent:cleverness; s=5282e113.xn--hew.k1310; i=sendmail-bs@submit.iecc.com; bh=RyNd6p/kMViGXAc0vXEJ0rLnnZVMRv73m8wvjQ8Ayi0=; b=EOXQNkEHm402EXMnN+jvE5hL36vcswz+GlUAzY75apwDBPq4iWTdBNxZlJWRDEYi0Xvp2DSrybqK7Lqcbslmx5E7loUPDpfG1MImP+xSxxEkn5olyoIjIJ8Pi1kCo4H6TGsPwBfmqAPXoGWDreuSb1U9uALePOZdaWnahyTho+B2LgxpGBXFOYDrcyzvwPgu2ANv9TB0WK9lAiwVHWC8UXpfe8IajWtSpLZU5iNsTANEMkJavZeikNIMIFVz1fwx DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type:user-agent:cleverness; s=5282e113.xn--hew.k1310; olt=sendmail-bs@submit.iecc.com; bh=RyNd6p/kMViGXAc0vXEJ0rLnnZVMRv73m8wvjQ8Ayi0=; b=kxs5nFBza1Iddj+1r8n+cONKww2y+pqqfBKen33M8aBHPQLUt9s551QL5lPU7ZnypnPboUzxiTVRBEf/adF5S9NYqZPS8f41kqMAiu6nrERx9NHhMNb9UWI9qlYfn7vEsrL3azmbZRDvhDsGj8rZhW1QmMUIHOT2m6Gg+r5grFo/WmzPeqFEZv9IR9bGaoNBMykmc6XEd7t5yLESIXdzdVUTQG0a50jQwFrrIy4aIw9BAZapjIr0bn0t5JqGKlnP Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 13 Nov 2013 02:16:50 -0000 Date: Tue, 12 Nov 2013 21:16:50 -0500 (EST) From: John R Levine To: Bill Mills In-Reply-To: <1384307266.54777.YahooMailNeo@web125603.mail.ne1.yahoo.com> Message-ID: References: <01P05GVOY8RU00004R@mauve.mrochek.com> <20131029190235.20826.qmail@joyce.lan> <1384307266.54777.YahooMailNeo@web125603.mail.ne1.yahoo.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="3825401791-145643061-1384309010=:72415" Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] SMTP extension Re: I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Nov 2013 02:17:11 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-145643061-1384309010=:72415 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT > So, abandon the SMTP extension and the running code with major interop > both?  That doesn't sound like a win. > > I don't know how quickly we'd implement an SMTP extension. The current draft just describes the SMTP extension. If Yahoo isn't planning to implement it, I'm not aware of anyone else who is, so I don't see any point in spending effort on shepherd write up, last call, and so forth for an RFC that nobody will use. On the other hand, if you've implemented the RRVS header and particularly if you know of other people who've done so and they interoperate, we should document that even if it is inferior in principle to the SMTP version. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. --3825401791-145643061-1384309010=:72415-- From wmills@yahoo-inc.com Tue Nov 12 18:20:45 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C66E21E80A1 for ; Tue, 12 Nov 2013 18:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.198 X-Spam-Level: X-Spam-Status: No, score=-17.198 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MybaPiRz4JOX for ; Tue, 12 Nov 2013 18:20:35 -0800 (PST) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by ietfa.amsl.com (Postfix) with ESMTP id C94BA21F9EF2 for ; Tue, 12 Nov 2013 18:20:34 -0800 (PST) Received: from GQ1-EX10-CAHT11.y.corp.yahoo.com (gq1-ex10-caht11.corp.gq1.yahoo.com [10.87.93.110]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id rAD2KBgF081163 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 12 Nov 2013 18:20:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1384309213; bh=qIZ2bTMNgoaO8Qr4wzlfqNrauvaPwTkMbxoBp0mdKno=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=MvMAfnrO9DUkLtRHExfp8jJcQcdPHDfoM/zOR1EajcJTomuawPaQMC+nF6g4PIMuV yTGhvm9uwckI+Ai459PoROmzdjKYZUDvRcTNrWazvuD/sRr8kuaNmcsqJL7RdRQXF4 coYTtTvMlFM3kagiObJo4JMGwioNRUs6Z+0GUy8s= Received: from omp1053.mail.ne1.yahoo.com (98.138.89.195) by GQ1-EX10-CAHT11.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 18:20:10 -0800 Received: (qmail 21424 invoked by uid 1000); 13 Nov 2013 02:20:10 -0000 Received: (qmail 26633 invoked by uid 60001); 13 Nov 2013 02:20:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1384309209; bh=dbeLWWbl1cIGXoAh4gVjKVZU1JbRPyAkavNMMLU5r+c=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VZgkKudO0PgbP06pkyOF/BQgg/zrRcNgU35Si+aeNE5hy0LxlZdb2hkZjjOl9DK9urKO/yk/ylWfvh/mMSj2TIckxjHxcyJT2k8nxHcBwjG9aFogCXuRDGFHxqZ4n+gRBKFiXCqy4+roI867hcLjW5Ja1WoHqhi14rTQAu7ePyk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=BQ2NS19qIzn/QwUrBlX8ujaNSU6V5uDFKGagmaR4sA9+QlXEIzTqz6qzQR/FTU7JbvUsW2aLx31TROSH5UBcyp0QPd3bx7TKbdliDon7KwjN+ocFhsCAbGf5iFaRSD5onvETTleVQs6lO1AoPB2rdPje7g3XNfIiHJZxA38gnN8=; X-YMail-OSG: lrI48XIVM1kubNC1VQfPa9yfBtGbo81l5El2TgFpYslj7c0 58Sh3KHdesXObEdRDrDIT_eEfdxMHmCpu8cfriMuF0jQkysmYOEE6s1LrXsq YDCZa22MiR_onJ8wEGNNhiO9r8aEYupqEO17xQZ5zyP7.GNOrqhkOYKSQ8BO 2cXfXGyf1yFWukAjLnKap7iSBpw_w4RI9rdtd8aLnuCgGTt8fgfXTny7D3Jo dF1iJ59EkE3NVp7jgBiK.mYOI1vvCxFUrknNTYPPINabxRBqPHGFbRoR.1EL E6t6b4Fszb_OqGkyMbGAECr8n Received: from [209.131.62.113] by web125605.mail.ne1.yahoo.com via HTTP; Tue, 12 Nov 2013 18:20:09 PST X-Rocket-MIMEInfo: 002.001, VGhlIHByZXZpb3VzIGRyYWZ0cyBkb2N1bWVudGVkIHRoZSBoZWFkZXIgdXNhZ2UgdGhhdCBZYWhvbyBhbmQgRmFjZWJvb2sgYXJlIGFscmVhZHkgdXNpbmcuwqAgSSBiZWxpZXZlIEdvb2dsZSBpcyBpbXBsZW1lbnRpbmcgY3VycmVudGx5LCBJIGRvbid0IGtub3cgb2ZmaGFuZCB3aGF0IG90aGVyIHNvdXJjZXMgYXJlIHNlbmRpbmcgaXQuCgoKwqAKLWJpbGwKCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KV2lsbGlhbSBKLiBNaWxscwoiUGFyYW5vaWQiIFlhaG9vIQoKCgoKCk9uIFR1ZXNkYXkBMAEBAQE- X-Mailer: YahooMailWebService/0.8.163.597 References: <01P05GVOY8RU00004R@mauve.mrochek.com> <20131029190235.20826.qmail@joyce.lan> <1384307266.54777.YahooMailNeo@web125603.mail.ne1.yahoo.com> Message-ID: <1384309209.26140.YahooMailNeo@web125605.mail.ne1.yahoo.com> Date: Tue, 12 Nov 2013 18:20:09 -0800 From: Bill Mills To: John R Levine In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1124617404-2040732324-1384309209=:26140" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 309212004 Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] SMTP extension Re: I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 02:20:45 -0000 ---1124617404-2040732324-1384309209=:26140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The previous drafts documented the header usage that Yahoo and Facebook are= already using.=A0 I believe Google is implementing currently, I don't know= offhand what other sources are sending it.=0A=0A=0A=A0=0A-bill=0A=0A=0A=0A= --------------------------------=0AWilliam J. Mills=0A"Paranoid" Yahoo!=0A= =0A=0A=0A=0A=0AOn Tuesday, November 12, 2013 6:17 PM, John R Levine wrote:=0A =0A> So, abandon the SMTP extension and the running co= de with major interop =0A> both?=A0 That doesn't sound like a win.=0A>=0A> = I don't know how quickly we'd implement an SMTP extension.=0A=0AThe current= draft just describes the SMTP extension.=A0 If Yahoo isn't =0Aplanning to = implement it, I'm not aware of anyone else who is, so I don't =0Asee any po= int in spending effort on shepherd write up, last call, and so =0Aforth for= an RFC that nobody will use.=0A=0AOn the other hand, if you've implemented= the RRVS header and particularly =0Aif you know of other people who've don= e so and they interoperate, we =0Ashould document that even if it is inferi= or in principle to the SMTP =0Aversion.=0A=0A=0ARegards,=0AJohn Levine, joh= nl@taugh.com, Taughannock Networks, Trumansburg NY=0APlease consider the en= vironment before reading this e-mail. ---1124617404-2040732324-1384309209=:26140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The previ= ous drafts documented the header usage that Yahoo and Facebook are already = using.  I believe Google is implementing currently, I don't know offha= nd what other sources are sending it.

&= nbsp;
-bill


--------------------------------
Willi= am J. Mills
"Paranoid" Yahoo!



On Tuesday, November 12, 2013 6:17 PM, John R Levine <johnl= @taugh.com> wrote:
&g= t; So, abandon the SMTP extension and the running code with major interop <= br clear=3D"none">> both?  That doesn't sound like a win.
>
> I don't know how quickly we'd impleme= nt an SMTP extension.

The current draf= t just describes the SMTP extension.  If Yahoo isn't
planning to implement it, I'm not aware of anyone else who is, so I don't=
see any point in spending effort on shepherd write up, = last call, and so
forth for an RFC that nobody will use.=

On the other hand, if you've implemen= ted the RRVS header and particularly
if you know of othe= r people who've done so and they interoperate, we
should= document that even if it is inferior in principle to the SMTP
version.


Regards,
John Levine, johnl@taugh.com, T= aughannock Networks, Trumansburg NY
Please consider the e= nvironment before reading this e-mail.


=
---1124617404-2040732324-1384309209=:26140-- From prvs=002215dcaf=johnl@iecc.com Tue Nov 12 18:26:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E56E21E809C for ; Tue, 12 Nov 2013 18:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yamn+8BkmTeK for ; Tue, 12 Nov 2013 18:25:58 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E28A321E8096 for ; Tue, 12 Nov 2013 18:25:57 -0800 (PST) Received: (qmail 25347 invoked from network); 13 Nov 2013 02:25:56 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Nov 2013 02:25:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type:user-agent:cleverness; s=5282e334.xn--btvx9d.k1310; i=sendmail-bs@submit.iecc.com; bh=8lMk4cK+IcPGUsEE12bf0QUYSx95MHRstnAvykkgVrI=; b=naOInBA2wf1ZSqo+N5Iz6v+A/NdUwL/pcZE+6C8xrs9g0hUss6Xd/KJeBtTadfNXSVXYHBK2FoQ0T57s683VmCCPJMu7UVEEk8AimvyTRuHH1YSlBBx1wQ6Hvk4posJNdOuIvAbYb5uETZijXue0wNc0Dox8ZiYnF6gS+v0dXcD5LiekdJRr+55dgcKdqNq/5gtlIsfeitcoD+ngARJMmWhUFw6C/C/dTUzRERwoIX+My0f0CZFIRuEIUe9Vwp/H Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 13 Nov 2013 02:25:56 -0000 Date: Tue, 12 Nov 2013 21:25:56 -0500 (EST) From: "John R. Levine" To: Bill Mills In-Reply-To: <1384309209.26140.YahooMailNeo@web125605.mail.ne1.yahoo.com> Message-ID: References: <01P05GVOY8RU00004R@mauve.mrochek.com> <20131029190235.20826.qmail@joyce.lan> <1384307266.54777.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1384309209.26140.YahooMailNeo@web125605.mail.ne1.yahoo.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="3825401791-792238529-1384309556=:72415" Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] SMTP extension Re: I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Nov 2013 02:26:11 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-792238529-1384309556=:72415 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT > The previous drafts documented the header usage that Yahoo and Facebook > are already using.  I believe Google is implementing currently, I don't > know offhand what other sources are sending it. Then despite Ned's reservations, we should go back and document that. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly --3825401791-792238529-1384309556=:72415-- From ned.freed@mrochek.com Wed Nov 13 09:07:15 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C83811E8125 for ; Wed, 13 Nov 2013 09:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tj02LZDa5n9h for ; Wed, 13 Nov 2013 09:07:10 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5E61B11E8119 for ; Wed, 13 Nov 2013 09:07:10 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P0QDUDKPBK000JTJ@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 13 Nov 2013 09:02:02 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=UTF-8; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P0DS85DTO000004G@mauve.mrochek.com>; Wed, 13 Nov 2013 09:01:56 -0800 (PST) Message-id: <01P0QDUA6LDQ00004G@mauve.mrochek.com> Date: Wed, 13 Nov 2013 08:49:59 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 12 Nov 2013 21:25:56 -0500 (EST)" References: <01P05GVOY8RU00004R@mauve.mrochek.com> <20131029190235.20826.qmail@joyce.lan> <1384307266.54777.YahooMailNeo@web125603.mail.ne1.yahoo.com> <1384309209.26140.YahooMailNeo@web125605.mail.ne1.yahoo.com> To: "John R. Levine" Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] SMTP extension Re: I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Nov 2013 17:07:15 -0000 > > The previous drafts documented the header usage that Yahoo and Facebook > > are already using.  I believe Google is implementing currently, I don't > > know offhand what other sources are sending it. > Then despite Ned's reservations, we should go back and document that. First of all, I never said the header should be abandoned. In fact I was quite careful not to say that. What I did say is that the header mechanism was a lot more difficult to implement than I anticipated. As such, if this moves forward it needs to include the much simpler SMTP extension, and if something is to be dropped it should be the header mechanism. And if the header mechanism has already deployed, that's certainly an argument for keeping it, despite the issues it clearly has. A header mechanism was defined for MT-PRIORITY, so there is precedent for doing this. Now, as to who is going to implement this. I already have, and assuming it makes it to an RFC, our plan is to make it part of our implementation in due course. And not to put too fine a point on it, but quite a few large MSPs and ISPs use our stuff. Of course this doesn't mean they will choose to use this facility. I've only spoken to a couple so far, and their response was that they don't care about it since they don't recycle addresses. (They had a lot more to say about this particular practice, but I'll spare everyone the repitition of that.) But assuming there are some that do want to recycle, I see no reason why they wouldn't deploy this. Ned From hsantos@isdg.net Wed Nov 13 13:18:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E28921E80CC for ; Wed, 13 Nov 2013 13:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.289 X-Spam-Level: X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twa4TvxAZckO for ; Wed, 13 Nov 2013 13:18:39 -0800 (PST) Received: from groups.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6574021E80B4 for ; Wed, 13 Nov 2013 13:18:38 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4353; t=1384377506; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=znUb6HXQvXqJWvZT3oxTlqER3LU=; b=sYSF1ALs/ITTMrrTxtfX SNZIS7A4/rKhiBMR30KqtZwrXc4xEQ1qMg8trFifLvKiOoArvOnQRpLWwM9gaq2a hohfzSHsde9HChRGsWb5k8fXjcr+TxoresOs/YcJhlNzAbD+04ulrMKfvMKCwJY7 nP9by3aHCLturE0kLftLV8E= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Wed, 13 Nov 2013 16:18:26 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2250003782.2741.432; Wed, 13 Nov 2013 16:18:25 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4353; t=1384377048; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=/64OuQF /vA74ZG0ouB9kVmGfdIQOvAeUEM7y3epebjU=; b=MW93eqCQVzIDh0G9BYOjrCq dKw4kKIYRrs1p+6dDgfxPq4E0gsB6aepfiJlLRcdWkA2o4VI71NS6YK8Br53jwdG FwwKGHZ0mW8a9EAzuo4p7RX+R7ObVy2JwEPnO0QoIayE91TUP4MVcjqwl4kez1Un /LXmlW625SfiYMGbyUlc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Wed, 13 Nov 2013 16:10:48 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1696361957.9.4072; Wed, 13 Nov 2013 16:10:47 -0500 Message-ID: <5283ECA9.5080502@isdg.net> Date: Wed, 13 Nov 2013 16:18:33 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <01P05GVOY8RU00004R@mauve.mrochek.com> <20131029190235.20826.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] SMTP extension Re: I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Nov 2013 21:18:47 -0000 On 11/12/2013 7:13 PM, Murray S. Kucherawy wrote: > So to you two guys in particular, does the new draft, which dropped the > header field, satisfy your concerns? I saw John's editorial nits, so let's > assume those are resolved... anything else we need to do here? > I was surprised you pulled the header. I think this is a dual solution for the widest coverage. The alternative is to discuss the passage of meta information in relays. We had to do the same thing with adding support for Return-Path when we moved from old 822/2822 "From " UUCP methods of getting bounce path information. In fact, our MDA will pull the Return-Path once its logic and need has been satisfied for final MUA pick up. Again, different software parts. Overall, I could add support for this, but I have having trouble with the safe automated logistics. I think you need more use case examples and also discuss or at least understand all boundary conditions. Consider what is being asked of the server (receiver) system in dealing with accounts, in particular those that have "expired" either for lack of usage and/or some subscription model is in play. - Deleted Accounts ---> Yields 55x responses - Demoted Accounts (No network mail) --> Yields 55x responses. That is today. Ultimately, this proposal is about asking a hosting server when it should issue a 55x for what is otherwise a 250 action for active accounts: - Active Accounts normally yields 250 responses: - Non-RRVS compliant --> 250 - RRVS compliant (Time Pass) --> 250 - RRVS compliant (Time Failed) --> 550 5.7.15 What TIME fields are we comparing among those only known to the server? Is this proposal asking Servers to add a new "RRVS" field to user records with opaque meaning? When does it get set? By the first instance of the RRVS client? Anyway, I guess the only real change in the final results is reaching a 550 response for normally 250 active accounts. Would this be a near understanding of this proposal? I understand the long time problem. All of our BBS operators since the 80s had the problem of expired accounts but the odds of name collisions were low. Today, the potential for name collisions are very high especially at popular centralize service sites where multiple people with the same names can gather. But I wonder if this the right solution in order to reclaim old "expired/demoted" account names for new users? What happens when an account with RRVS information is demoted? Should a client get the 550 when the RRVS TIME is still valid? For example, a yahoo account is used to create a facebook account. Facebook sends automated messages and it uses the RRVS with the TIME reflecting I suppose, some "creation" or "last confirmation" time. How does the server know what time is this? So I suppose YAHOO will save the RRVS value that was passed by the first time RRVS client and then use this value as a "Key" in theory for validity in future transactions. I guess, facebook will get some benefit (sure feels like its playing with fire here), but what about Yahoo? What if the user goes away, gets sick, for a long time and comes back 1+ year later, and Yahoo either deletes or demote the account? 550 happens now or does it? Because its quite possible that the Facebook user may be active there but never at yahoo.com. There has to be other integration considerations. Yahoo.com may be able to use these RRVS transactions as a way to re-activate or better "Keep Alive" accounts at the host system. This will prevent it from expiring for example. I think if this is left only for 550 responses, then there is less potential harm. Anyway, I think the proposal needs more generic examples of how this can used and integrated, what times are compared and whether or not ultimately, this about adding a new RRVS field to user accounts, something that is not currently there. The time fields we have our Wildcat! user record are: // history and accounting FILETIME CreateTime; FILETIME LastCall; FILETIME LastNewFiles; FILETIME ExpireDate; FILETIME FirstCall; FILETIME BirthDate; FILETIME LastUpdate; FILETIME PasswordChangeDate; What this proposal seems to be asking that we add: FILETIME RRVS; But how/when it is set or cleared? By whom? -- HLS From stephen.farrell@cs.tcd.ie Wed Nov 13 14:05:34 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8512821E811A; Wed, 13 Nov 2013 14:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.926 X-Spam-Level: X-Spam-Status: No, score=-102.926 tagged_above=-999 required=5 tests=[AWL=-0.679, BAYES_00=-2.599, SARE_SUB_11CONS_WORD=0.352, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Awvabs-ic2w7; Wed, 13 Nov 2013 14:05:28 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A2B3B21E8104; Wed, 13 Nov 2013 14:05:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F171BBE80; Wed, 13 Nov 2013 22:05:26 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFovoWoxQeEh; Wed, 13 Nov 2013 22:05:25 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.41.61.15]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 14096BE7D; Wed, 13 Nov 2013 22:05:25 +0000 (GMT) Message-ID: <5283F7A2.5040106@cs.tcd.ie> Date: Wed, 13 Nov 2013 22:05:22 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "\"saag@ietf.org\" per" , perpass , "cfrg@irtf.org" , "secdir@ietf.org" References: <20131113215822.13869.69647.idtracker@ietfa.amsl.com> In-Reply-To: <20131113215822.13869.69647.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <20131113215822.13869.69647.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: [apps-discuss] Fwd: New Non-WG Mailing List: dsfjdssdfsd X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Nov 2013 22:05:34 -0000 Hi, There was some discussion in Vancouver at the secdir lunch and the perpass BoF about better randomness recommendations and we agreed to set up a new list. Details for that are below. Many thanks to Dan Harkins and Paul Hoffman for agreeing to moderate this. I think Don Eastlake is also working on an update to RFC 4086 so this could be a useful place to talk about that. I'm hoping that one of them will kick off the discussion in a few days, once folks have had a chance to sign up. Regards, Stephen. -------- Original Message -------- Subject: New Non-WG Mailing List: dsfjdssdfsd Date: Wed, 13 Nov 2013 13:58:22 -0800 From: IETF Secretariat Reply-To: ietf@ietf.org To: IETF Announcement List CC: dsfjdssdfsd@ietf.org, dharkins@lounge.org, paul.hoffman@vpnc.org A new IETF non-working group email list has been created. List address: dsfjdssdfsd@ietf.org Archive: http://www.ietf.org/mail-archive/web/dsfjdssdfsd/current/maillist.html To subscribe: https://www.ietf.org/mailman/listinfo/dsfjdssdfsd Purpose: The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086. For additional information, please contact the list administrators. From dave@cridland.net Wed Nov 13 14:34:36 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D505521E80CF for ; Wed, 13 Nov 2013 14:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+-kIk9JUFF2 for ; Wed, 13 Nov 2013 14:34:35 -0800 (PST) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id AD36221E8094 for ; Wed, 13 Nov 2013 14:34:35 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id wm4so1246601obc.17 for ; Wed, 13 Nov 2013 14:34:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DF+j6n5p/ILtjkrIP83oW9Ac5bJst+RrFMyYBs5G9lw=; b=YTtLx9VqKTSggu5k5Ps5cgf7KXycdI4GSu8wbI4LWFbV7vSIuTrmvgIcYXChxEAKHU /3hql/iwo09NzXWQl0/CrpOZGcLzAYA0tid1nfcM3mXhGA4BGyv+ogignDQfic0hjv2K gSSiKF8FaTwkDlg9VFNRQ8uJJiOcCL6N4FfxU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DF+j6n5p/ILtjkrIP83oW9Ac5bJst+RrFMyYBs5G9lw=; b=EEMG/ju/HG+/VusfiCNkpCTePmBSQy9WTRKzetr8zGtrZ/RNk77dhaEUfS1figtRvC LY2uGpagJ+Qmt52ncppGany5mrGmsJRLazfOA0T7gdHGQhbAZtdIS8LAlKOZT9UPHbZA kNl95AL3TkrTmXhqoBMhDBbB1Rbk94uFoANFQYCV6580B42Z5FZZ+z8cvL1h4VrkFPtw GQcxAnn0z8OSUkS/iZGqiIwTKJz9lePB98939q8bAEQiXEDApw6Uo7KxD5Eos76u4Yor gYx9mxBXsMNkORaAyPmBLtVnOMOhj/2JiGWj4zKJ+TJcRH4AejS8/zm+Kj60uI7IdSAr UX5Q== X-Gm-Message-State: ALoCoQnlvXsrfctFYKZ7/TXfxpAwRMfrqDRjLvJMKoHce6C7THjaoUHf54/Q/+TwGfw5K/dZV7o9 MIME-Version: 1.0 X-Received: by 10.182.71.50 with SMTP id r18mr165221obu.102.1384382073364; Wed, 13 Nov 2013 14:34:33 -0800 (PST) Received: by 10.60.121.97 with HTTP; Wed, 13 Nov 2013 14:34:33 -0800 (PST) In-Reply-To: <5283ECA9.5080502@isdg.net> References: <01P05GVOY8RU00004R@mauve.mrochek.com> <20131029190235.20826.qmail@joyce.lan> <5283ECA9.5080502@isdg.net> Date: Wed, 13 Nov 2013 22:34:33 +0000 Message-ID: From: Dave Cridland To: Hector Santos Content-Type: multipart/alternative; boundary=e89a8fb1fa74b79f9304eb169171 Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] SMTP extension Re: I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Nov 2013 22:34:36 -0000 --e89a8fb1fa74b79f9304eb169171 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 13, 2013 at 9:18 PM, Hector Santos wrote: > I was surprised you pulled the header. > FWIW, me too. I understood the logic behind having a header as fallback, just wanted it as a fallback to an extension that would be used in preference. Dave. --e89a8fb1fa74b79f9304eb169171 Content-Type: text/html; charset=ISO-8859-1
On Wed, Nov 13, 2013 at 9:18 PM, Hector Santos <hsantos@isdg.net> wrote:
I was surprised you pulled the header.


FWIW, me too. I understood the logic behind having a header as fallback, just wanted it as a fallback to an extension that would be used in preference.

Dave.
--e89a8fb1fa74b79f9304eb169171-- From superuser@gmail.com Wed Nov 13 16:05:07 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6787C21E811C for ; Wed, 13 Nov 2013 16:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoyglzHGQzqo for ; Wed, 13 Nov 2013 16:05:06 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC3021E80ED for ; Wed, 13 Nov 2013 16:05:06 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id q58so1175432wes.28 for ; Wed, 13 Nov 2013 16:05:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fI1Q2KGNPuSQmKSaGKZv4I+N8lZ9ftbgfIG9kfPpIrQ=; b=raztI2u2j5S1G2Dx6NncRJ182dI8uUNJOkjnuY3Li1euufoX51slqD7C4J2/xXpAqe mEQiMnT6IXpiut4FM2PqMD/Za0A2HG8XJ/wNigv0ClTDzSYmSlgO9zh5h1yYtB7RUw8/ spVGlMbNdQrEHA+4JWE94csbnerektUVv3YbyKtFdvq12A5CQrIDQzUdsruIkdku6/5f bkLIOwVCK4u51hd52sr6V2ooFQjvY2IjCj8sioXCNbknO7i2hcBLlBJ6OFrEnaR4D1nD WzquKDH+ymsChP9GTqjVPTx2NRTlkphC5KOpuPUt7XVpvN2d7EDDnbXzBBJUUKtbBAbp weIA== MIME-Version: 1.0 X-Received: by 10.180.212.51 with SMTP id nh19mr256412wic.52.1384387505569; Wed, 13 Nov 2013 16:05:05 -0800 (PST) Received: by 10.181.13.230 with HTTP; Wed, 13 Nov 2013 16:05:05 -0800 (PST) In-Reply-To: References: <01P05GVOY8RU00004R@mauve.mrochek.com> <20131029190235.20826.qmail@joyce.lan> <5283ECA9.5080502@isdg.net> Date: Wed, 13 Nov 2013 16:05:05 -0800 Message-ID: From: "Murray S. Kucherawy" To: Dave Cridland Content-Type: multipart/alternative; boundary=001a11c3576080471404eb17d5a6 Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] SMTP extension Re: I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 00:05:07 -0000 --001a11c3576080471404eb17d5a6 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 13, 2013 at 2:34 PM, Dave Cridland wrote: > On Wed, Nov 13, 2013 at 9:18 PM, Hector Santos wrote: > >> I was surprised you pulled the header. >> > > FWIW, me too. I understood the logic behind having a header as fallback, > just wanted it as a fallback to an extension that would be used in > preference. > > Dave. > I guess I misunderstood the sentiment then. Sorry about that. I'll go back a version and then apply the nits that have otherwise been posted, and do an update. Ned, if you go back one version to the draft that had both, was there any specific text you would suggest we add based on your experience with implementation? -MSK --001a11c3576080471404eb17d5a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 13, 2013 at 2:34 PM, Dave Cridland <dave@cr= idland.net> wrote:
On Wed, N= ov 13, 2013 at 9:18 PM, Hector Santos <hsantos@isdg.net> wrot= e:
I w= as surprised you pulled the header.

FWIW, me too. I understood the logic behind having a header as f= allback, just wanted it as a fallback to an extension that would be used in= preference.

<= /div>
Dave.

I guess I misunders= tood the sentiment then.=A0 Sorry about that.=A0 I'll go back a version= and then apply the nits that have otherwise been posted, and do an update.=

Ned, if you go back one version to the= draft that had both, was there any specific text you would suggest we add = based on your experience with implementation?

-MSK
--001a11c3576080471404eb17d5a6-- From superuser@gmail.com Wed Nov 13 16:33:22 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E2321E80CB for ; Wed, 13 Nov 2013 16:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65bzryO728HS for ; Wed, 13 Nov 2013 16:33:21 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6D26521E8090 for ; Wed, 13 Nov 2013 16:33:21 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id k14so22584wgh.3 for ; Wed, 13 Nov 2013 16:33:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cXmjtlek26CzAh8ap9fUAIdVjP44lFgm28TDPArGR6M=; b=UG9DTaPNKIJOG72TjD1baUqICJzCzC0R+sFnXtz0ei76pi7YNUnPk3eMdeNsVRDHeJ HoFVs4EGQR1uiAp6sovpYLXUBgk+ikQ3l/0P0PcghTRTkqJvmhoK01bT0X5OLfylwwZp yaMD7ZKnNJGE0+SCuJZN75RHeqOEF49wsFmafPbbNmywhgRjIb5k696HU7AZ1s9Tzoqw L8UM6Af09hGJsaexNqGEI/25v/OT+R7kwzc4DUGZ3iBZAEvanLMg5/vjPPcfg4r7hboV bcYcwVJa/Eic6/CudBmPIMwgpcSrUReiQEHITxPEEvFWHZa+kvryrGo7RIuRJHvP+I4C JK8w== MIME-Version: 1.0 X-Received: by 10.180.212.51 with SMTP id nh19mr317346wic.52.1384389200111; Wed, 13 Nov 2013 16:33:20 -0800 (PST) Received: by 10.181.13.230 with HTTP; Wed, 13 Nov 2013 16:33:19 -0800 (PST) In-Reply-To: <527B07B8.1070103@isode.com> References: <20131106213938.20980.30376.idtracker@ietfa.amsl.com> <527B07B8.1070103@isode.com> Date: Wed, 13 Nov 2013 16:33:19 -0800 Message-ID: From: "Murray S. Kucherawy" To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a11c3576080ecc904eb183ac8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 00:33:22 -0000 --001a11c3576080ecc904eb183ac8 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 6, 2013 at 7:23 PM, Alexey Melnikov wrote: > > 4.2. SMTP Extension Not Offered > > For a message being sent that includes content meant to be protected > by this extension, the client MUST NOT continue to deliver a message > to a server > > That might be nitpicking, but if a message has multiple recipients on the > same server, some with the RRVS parameter and some without, I think you > only want non deliver for recipients with the RRVS parameter present. The > above doesn't say that. > where the server does not advertise the RRVS SMTP > extension. > > What is the error code to return? > We're going back a version, so this will disappear. > > 6. Use with Mailing Lists > > Mailing list services can store the timestamp at which a subscriber > was added to a mailing list. This specification can be used in > conjunction with that information in order to restrict traffic to the > original subscriber, rather than a different person now in possession > of an address under which the original subscriber registered. Upon > receiving a rejection caused by this specification, the list service > can remove that address from further distribution. > > I am a bit confused about this section. You are not talking about using > RRVS parameter on a mailing list address, right? > Either. > > Which also reminds me: should the document talk about mailing list > expansions, i.e. whether the RRVS parameter should be copied for each > recipient on expansion. > > 11.2. Enhanced Status Code Registration > > IANA is requested to register the following in the SMTP Enhanced > Status Codes registry: > > Code: X.7.15 > Sample Text: Mailbox owner has changed > Associated basic status code: 5 > Description: This status code is returned when a message is > received with a Require-Recipient-Valid-Since > > This is still referencing the header field that you removed in -02. > We're adding it back. -MSK --001a11c3576080ecc904eb183ac8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 6, 2013 at 7:23 PM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:

4.2. =A0SMTP Extension Not Offered

=A0 =A0For a message being sent that includes content meant to be protected=
=A0 =A0by this extension, the client MUST NOT continue to deliver a message=
=A0 =A0to a server

That might be nitpicking, but if a message has multiple recipients on the s= ame server, some with the RRVS parameter and some without, I think you only= want non deliver for recipients with the RRVS parameter present. The above= doesn't say that.
=A0=A0 where the server does not advertise the RRVS SMTP
=A0 =A0extension.

What is the error code to return?

We= 9;re going back a version, so this will disappear.
=A0

6. =A0Use with Mailing Lists

=A0 =A0Mailing list services can store the timestamp at which a subscriber<= br> =A0 =A0was added to a mailing list. =A0This specification can be used in =A0 =A0conjunction with that information in order to restrict traffic to th= e
=A0 =A0original subscriber, rather than a different person now in possessio= n
=A0 =A0of an address under which the original subscriber registered. Upon =A0 =A0receiving a rejection caused by this specification, the list service=
=A0 =A0can remove that address from further distribution.

I am a bit confused about this section. You are not talking about using RRV= S parameter on a mailing list address, right?

Either.
=A0

Which also reminds me: should the document talk about mailing list expansio= ns, i.e. whether the RRVS parameter should be copied for each recipient on = expansion.

11.2. =A0Enhanced Status Code Registration

=A0 =A0IANA is requested to register the following in the SMTP Enhanced
=A0 =A0Status Codes registry:

=A0 =A0 =A0 Code: =A0 =A0 =A0 =A0 =A0 =A0 =A0 X.7.15
=A0 =A0 =A0 Sample Text: =A0 =A0 =A0 =A0Mailbox owner has changed
=A0 =A0 =A0 Associated basic status code: =A05
=A0 =A0 =A0 Description: =A0 =A0 =A0 =A0This status code is returned when a= message is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 received with a Require= -Recipient-Valid-Since

This is still referencing the header field that you removed in -02.

We're adding it back.

-M= SK
--001a11c3576080ecc904eb183ac8-- From superuser@gmail.com Wed Nov 13 16:43:58 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A6121F9FBC for ; Wed, 13 Nov 2013 16:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlCw-olazKD2 for ; Wed, 13 Nov 2013 16:43:56 -0800 (PST) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id EB63121F9C55 for ; Wed, 13 Nov 2013 16:43:55 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id t60so1162440wes.6 for ; Wed, 13 Nov 2013 16:43:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jroY2CGlBBVukSQZsY2uD03DuccL1yPzZbQ0gdInJP4=; b=ubPAKtREvbjjUngQzRi3gs1nNowLHU2LJFZcARroh7/WWEnUsb+m7hyL8pmL14Pg/T vEO6j+ZAKm7OxAB3ALLoSjTBF1gTgtmEhoMRdC55koS/aYo2DtCrSRmFtzdnDyjVsJ95 HD9pmhRnd5N8srKhGYGIB7Jb+OZCpcVMvkv5CUbuC01c5hxpSruXJhvOXMWAXRSYsqQ8 ZhRwh5DHJCJS6yj2nPLsg9isWkJ/5waiQW7XL+knEKcmljsaCT8nlhb96dPD2rqopLRL 6PYAsqOFsnuSemxhVZE1BfTZTpWSCMIqAeMGFX3/3KCm8JHP1dZQRvmt6fZgDhD4LzTh pf+A== MIME-Version: 1.0 X-Received: by 10.194.240.197 with SMTP id wc5mr34670117wjc.23.1384389834002; Wed, 13 Nov 2013 16:43:54 -0800 (PST) Received: by 10.181.13.230 with HTTP; Wed, 13 Nov 2013 16:43:53 -0800 (PST) In-Reply-To: <01P00BXM2CJU00004R@mauve.mrochek.com> References: <20131022182337.4789.qmail@joyce.lan> <01P00BXM2CJU00004R@mauve.mrochek.com> Date: Wed, 13 Nov 2013 16:43:53 -0800 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=089e013d19cc49558404eb186065 Cc: John Levine , IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 00:43:58 -0000 --089e013d19cc49558404eb186065 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 25, 2013 at 4:03 PM, Ned Freed wrote: > Anyway, once I had the extension I started in on the header stuff. I > expected > this to be harder due to the need to handle the header-envelope matcheup as > well as the possibility of partial failures, but I was gobsmacked at the > difficultly. This has taken me literally days to get right. > > The multiple recipient issue is a big part of it, but not all. Just as > one example of how tricky the multiple recipient issue is, suppose you > have two recipients A and B that forward to the same address C: > > A -> C > B -> C > The author only has a timestamp at which it thought A and B had confirmed owners of interest. The author has no idea that A and B are forwarded to C, or to anywhere at all. > So what recreation date do you attach to that one address? If either one > doesn't have a recreation date the answe is "you don't attach one". But > they > both do the correct thing is to attach and check both. That means making > some > data structure changes, which to be honest I didn't bother to do. I think > this > is enough of a corner case that I can ignore it. But I could be wrong, in > which > case this will be even more work. > The author would store the A and B confirmation dates. > But this is nasty even if there's only a single recipient and header. The > basic > problem is you've introduced a new failure case after the content of the > message has been received, and it turns out to have somewhat different > semantics from other failure cases at this point, in my implementation at > least. > The failure would be a bounce from the receiver, right? If you're talking about a failure from the MSA, I'm not sure why that would be a problem specific to this extension. > > It's not like throwing out the message because, say, it was a big pile of > binary nonsense. Or because it violated overall site policy in some way. In > such cases there's justification for returning an error and dropping the > trash > in the trashcan. But RRVS differs in that it's almost certainly a bad idea > to > ignore legal intercept or other archiving requirements for what is, after > all a > valid message. (And before you say otherwise, think what happens when Silk > Road > supports this on the sending side.) > You're talking about a receiver implementing those features, I presume. Is that something that we need to talk about in this draft? Seems like a sentence or two would suffice if so, but I haven't seen that mentioned in other extensions. > > This led me to conclude that RRVS is much more like a sieve ereject - which > already had support in place for multiple recipients - and that's more or > less > how I ended up implementing it. But the interactions with actual sieves are > different, the handling in the event of sieve errors are different, and > ereject > doesn't allow specification of a specific enhanced status code so support > for > that had to be added. > Wouldn't an implementing receiver just do an SMTP rejection for the RCPT TO commands for which the test failed, and continue otherwise? Again, is this a new problem specific to RRVS? -MSK --089e013d19cc49558404eb186065 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 25, 2013 at 4:03 PM= , Ned Freed <ned.freed@mrochek.com> wrote:
Anyway, once I had the extension I started i= n on the header stuff. I expected
this to be harder due to the need to handle the header-envelope matcheup as=
well as the possibility of partial failures, but I was gobsmacked at the difficultly. This has taken me literally days to get right.

The multiple recipient issue is a big part of it, but not all. Just as
one example of how tricky the multiple recipient issue is, suppose you
have two recipients A and B that forward to the same address C:

=A0 A -> C
=A0 B -> C

The author only has a tim= estamp at which it thought A and B had confirmed owners of interest.=A0 The= author has no idea that A and B are forwarded to C, or to anywhere at all.=
=A0
So what recreation date do you attach to that one address? If either one doesn't have a recreation date the answe is "you don't attach = one". But they
both do the correct thing is to attach and check both. That means making so= me
data structure changes, which to be honest I didn't bother to do. I thi= nk this
is enough of a corner case that I can ignore it. But I could be wrong, in w= hich
case this will be even more work.

The a= uthor would store the A and B confirmation dates.
=A0
But this is nasty even if there's only a single recipient and header. T= he basic
problem is you've introduced a new failure case after the content of th= e
message has been received, and it turns out to have somewhat different
semantics from other failure cases at this point, in my implementation at least.

The failure would be a bounce fr= om the receiver, right?=A0 If you're talking about a failure from the M= SA, I'm not sure why that would be a problem specific to this extension= .
=A0

It's not like throwing out the message because, say, it was a big pile = of
binary nonsense. Or because it violated overall site policy in some way. In=
such cases there's justification for returning an error and dropping th= e trash
in the trashcan. But RRVS differs in that it's almost certainly a bad i= dea to
ignore legal intercept or other archiving requirements for what is, after a= ll a
valid message. (And before you say otherwise, think what happens when Silk = Road
supports this on the sending side.)

You= 're talking about a receiver implementing those features, I presume.=A0= Is that something that we need to talk about in this draft?=A0 Seems like = a sentence or two would suffice if so, but I haven't seen that mentione= d in other extensions.
=A0

This led me to conclude that RRVS is much more like a sieve ereject - which=
already had support in place for multiple recipients - and that's more = or less
how I ended up implementing it. But the interactions with actual sieves are=
different, the handling in the event of sieve errors are different, and ere= ject
doesn't allow specification of a specific enhanced status code so suppo= rt for
that had to be added.

Wouldn't an i= mplementing receiver just do an SMTP rejection for the RCPT TO commands for= which the test failed, and continue otherwise?=A0 Again, is this a new pro= blem specific to RRVS?

-MSK
--089e013d19cc49558404eb186065-- From internet-drafts@ietf.org Thu Nov 14 00:03:36 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A7911E8183; Thu, 14 Nov 2013 00:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gGyfw4bpjuF; Thu, 14 Nov 2013 00:03:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D97421F8B04; Thu, 14 Nov 2013 00:03:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131114080334.4258.93195.idtracker@ietfa.amsl.com> Date: Thu, 14 Nov 2013 00:03:34 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 08:03:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : The Require-Recipient-Valid-Since Header Field and SMTP = Service Extension Author(s) : William J. Mills Murray S. Kucherawy Filename : draft-ietf-appsawg-rrvs-header-field-03.txt Pages : 14 Date : 2013-11-14 Abstract: This document defines an extension for the Simple Mail Transfer Protocol called RRVS, and a header field called Require-Recipient- Valid-Since, to provide a method for senders to indicate to receivers the time when the sender last confirmed the ownership of the target mailbox. This can be used to detect changes of mailbox ownership, and thus prevent mail from being delivered to the wrong party. The intended use of these facilities is on automatically generated messages that might contain sensitive information, though it may also be useful in other applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-rrvs-header-field There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-rrvs-header-field-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-rrvs-header-field-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From superuser@gmail.com Thu Nov 14 00:06:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6DE21E808F for ; Thu, 14 Nov 2013 00:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlJo8Bd4q8e3 for ; Thu, 14 Nov 2013 00:06:40 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id C4CB121E8087 for ; Thu, 14 Nov 2013 00:06:38 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id x13so1523168wgg.16 for ; Thu, 14 Nov 2013 00:06:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=I2QAOT5bdpT0N+RSzEAZiHUtQh00n6EEFniv1/fpLRo=; b=KO+pGNt3q9awGchUb7MV0uaNr2Vf4nDSk6Wj26lwp1RZEx7HsRTj9l4DrnSGTiaTyM XA+cvWrJRkLiQ+8gi4cULGqwg7OTylB9I+yMMnMjVns41hDdib7GM3SsSOcCJGWWVj0c DRV+dk/zCK9Ug+nnpe9XFpWq8JEDaxMNvM3PR1GQQBHaRxMLdbxqCQK4N/ZX1uQYMxQ0 R3JMcGfQCzN2JTV+uhDqE2WTMNEW+7iwGTsaOeOgN4WS5tUyqzSO1X5NFWUpE6SylWXh 7SAPKVbAQjbvBITkFBmcN5XezGBU3lphKIWSuVI98NzRV1u4aRZpGzjHWB4fMKjBdSAv HeLQ== MIME-Version: 1.0 X-Received: by 10.194.3.78 with SMTP id a14mr43781wja.77.1384416397846; Thu, 14 Nov 2013 00:06:37 -0800 (PST) Received: by 10.181.13.230 with HTTP; Thu, 14 Nov 2013 00:06:37 -0800 (PST) In-Reply-To: <20131114080334.4258.93195.idtracker@ietfa.amsl.com> References: <20131114080334.4258.93195.idtracker@ietfa.amsl.com> Date: Thu, 14 Nov 2013 00:06:37 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=047d7b343d6a9d6e6304eb1e8fed Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 08:06:42 -0000 --047d7b343d6a9d6e6304eb1e8fed Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 14, 2013 at 12:03 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Applications Area Working Group Working > Group of the IETF. > > Title : The Require-Recipient-Valid-Since Header Field > and SMTP Service Extension > Author(s) : William J. Mills > Murray S. Kucherawy > Filename : draft-ietf-appsawg-rrvs-header-field-03.txt > Pages : 14 > Date : 2013-11-14 > > Abstract: > This document defines an extension for the Simple Mail Transfer > Protocol called RRVS, and a header field called Require-Recipient- > Valid-Since, to provide a method for senders to indicate to receivers > the time when the sender last confirmed the ownership of the target > mailbox. This can be used to detect changes of mailbox ownership, > and thus prevent mail from being delivered to the wrong party. > > The intended use of these facilities is on automatically generated > messages that might contain sensitive information, though it may also > be useful in other applications. > Reverts removal of the header field definition, adds a second enhanced status code to indicate domain ownership changes, makes use of enhanced status codes a SHOULD, and differentiates between relays and re-senders in terms of whether the ESMTP material should be relayed when a message passed to a downstream MTA. Please (Bill, John and Ned especially) let me know if I've missed anything here. -MSK --047d7b343d6a9d6e6304eb1e8fed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Nov 14, 2013 at 12:03 AM, <<= a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blank">internet-draft= s@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Applications Area Working Group Working= Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : The Require-Recipient-Valid-Sin= ce Header Field and SMTP Service Extension
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : William J. Mills
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Murray S. Kucherawy
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-rrvs-header-fi= eld-03.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 14
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-11-14

Abstract:
=A0 =A0This document defines an extension for the Simple Mail Transfer
=A0 =A0Protocol called RRVS, and a header field called Require-Recipient- =A0 =A0Valid-Since, to provide a method for senders to indicate to receiver= s
=A0 =A0the time when the sender last confirmed the ownership of the target<= br> =A0 =A0mailbox. =A0This can be used to detect changes of mailbox ownership,=
=A0 =A0and thus prevent mail from being delivered to the wrong party.

=A0 =A0The intended use of these facilities is on automatically generated =A0 =A0messages that might contain sensitive information, though it may als= o
=A0 =A0be useful in other applications.

Reverts removal of the header field definition, adds a second enhanced sta= tus code to indicate domain ownership changes, makes use of enhanced status= codes a SHOULD, and differentiates between relays and re-senders in terms = of whether the ESMTP material should be relayed when a message passed to a = downstream MTA.

Please (Bill, John and Ned especially) let me know if I'= ve missed anything here.

-MSK
--047d7b343d6a9d6e6304eb1e8fed-- From hsantos@isdg.net Thu Nov 14 05:40:48 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3685811E80E2 for ; Thu, 14 Nov 2013 05:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.31 X-Spam-Level: X-Spam-Status: No, score=-102.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3U9K1su8ukEM for ; Thu, 14 Nov 2013 05:40:42 -0800 (PST) Received: from mail.winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBAA11E80F5 for ; Thu, 14 Nov 2013 05:40:41 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2723; t=1384436438; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=9k0PiQbsieIoF/wcYcf4cEDoP7Y=; b=sv8rRgBKxA2caeiKIroE REKkta43Y0gdezM1SwNuBTeECiM14IOnoNbD6zDRV01Jz3D8+gAD9uODRQ4hKwDp yDnQoUznYZ/N8gEeTxmXlKje/3sbpgKloeiljEYAlxINs49CEfoeKW16gPZAnkc+ rbq78AlF1ByZsTJYpb1MY2c= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Thu, 14 Nov 2013 08:40:38 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2308934673.3485.1304; Thu, 14 Nov 2013 08:40:36 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2723; t=1384435978; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=utY525T aWUaRfOzDzrgT3XoearaaJPZSPkk6R3x2Kws=; b=Z/sPDfrJvR3Rt3xJ0Ljhy8m 1QrLeKkthTixQFOFKm5b/P4YfqXcITg3weBBR4Q7QEpdeN5clGo6Nd1LJB2IiShx i1HBcZvcDOlJFsUNtGp8WnmCxPuxVYY3jauHgGUBU+Ojq+YhNWawZzDaUpj5hFBj 5sgLGD6ExXWKj2b1/+Qo= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Thu, 14 Nov 2013 08:32:58 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1755290723.9.1508; Thu, 14 Nov 2013 08:32:56 -0500 Message-ID: <5284D2DC.9050804@isdg.net> Date: Thu, 14 Nov 2013 08:40:44 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20131114080334.4258.93195.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 13:40:48 -0000 On 11/14/2013 3:06 AM, Murray S. Kucherawy wrote: > On Thu, Nov 14, 2013 at 12:03 AM, wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Applications Area Working Group Working >> Group of the IETF. >> >> Title : The Require-Recipient-Valid-Since Header Field >> and SMTP Service Extension >> Author(s) : William J. Mills >> Murray S. Kucherawy >> Filename : draft-ietf-appsawg-rrvs-header-field-03.txt >> Pages : 14 >> Date : 2013-11-14 >> >> Abstract: >> This document defines an extension for the Simple Mail Transfer >> Protocol called RRVS, and a header field called Require-Recipient- >> Valid-Since, to provide a method for senders to indicate to receivers >> the time when the sender last confirmed the ownership of the target >> mailbox. This can be used to detect changes of mailbox ownership, >> and thus prevent mail from being delivered to the wrong party. >> >> The intended use of these facilities is on automatically generated >> messages that might contain sensitive information, though it may also >> be useful in other applications. >> > > Reverts removal of the header field definition, adds a second enhanced > status code to indicate domain ownership changes, makes use of enhanced > status codes a SHOULD, and differentiates between relays and re-senders in > terms of whether the ESMTP material should be relayed when a message passed > to a downstream MTA. > > Please (Bill, John and Ned especially) let me know if I've missed anything > here. > I'm not Bill, John nor Ned, but I hope you can shine some light here. Suppose I create an account at winserver.com to sign up at facebook.com. What RRVS value is going to be passed to winserver.com and what do I compare it with? Is Winserver.com expected to save this value for the user? It sounds to me that we will need to save RRVS values PER client domain because each can have its own understanding of the RRVS value or not at all. Is this correct? I still don't have the complete "Ah Ha" on how this is going to work to safely deal with expired accounts which I expect this proposal is expecting the accounts will never be deleted but perhaps marked inactive in order to be able to have a history of RRVS values. Overall: Deleted Accounts yield 550 Demoted Accounts yield 550 Active Accounts with non-RRVS yield 250 Active Accounts with pass RRVS yield 250 Active Accounts with failed RRVS yield 550 Before I am even try to implement this, I'm trying to see what RRVS value is compared too in order to change an active account 250 to 550. -- HLS From superuser@gmail.com Thu Nov 14 06:47:51 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2571921E80F9 for ; Thu, 14 Nov 2013 06:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZ4saQfJ4Qcy for ; Thu, 14 Nov 2013 06:47:50 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id B347D21E80F3 for ; Thu, 14 Nov 2013 06:47:49 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id w61so2094293wes.12 for ; Thu, 14 Nov 2013 06:47:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wRhpJq8YK/qaEYDRq8RWWsdFKshkJ9JUnjZLD5khO4c=; b=rfujc46gNtGC5fnPfbfgzbOMgJ72Acr6o/2dIZYPKkhuYbPF9suAyekrFZ41qlsJ1u C7hTtlliFBTQcM31XGvhP/qct1/7Nb9A2r2rgjRdRGZVoAI/hMPwewO1SYSAZFWiGFnj Re2MCMPJd+nUpqIt6J7qvvTeSltw+nPaiKUWi4evZXmforZPEIpQB3VJ6hCvW3xiB09T MB0WhzKX/xw03gnYOiqPYyc0EiGal/QEmqsdCczkZaw6tab61hQjnHuz3A4YtWB67BY9 SBgk6WukAr0jSrmeEB0ybXAVn0jiJeTLz0XLjGyP3UMXjhMFPkdyh4DmcCnN0A7K+bql J7gA== MIME-Version: 1.0 X-Received: by 10.194.121.133 with SMTP id lk5mr1605694wjb.77.1384440468838; Thu, 14 Nov 2013 06:47:48 -0800 (PST) Received: by 10.181.13.230 with HTTP; Thu, 14 Nov 2013 06:47:48 -0800 (PST) In-Reply-To: <5284D2DC.9050804@isdg.net> References: <20131114080334.4258.93195.idtracker@ietfa.amsl.com> <5284D2DC.9050804@isdg.net> Date: Thu, 14 Nov 2013 06:47:48 -0800 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=089e01184e565ba67e04eb242aee Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 14:47:51 -0000 --089e01184e565ba67e04eb242aee Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 14, 2013 at 5:40 AM, Hector Santos wrote: > I'm not Bill, John nor Ned, but I hope you can shine some light here. > > Suppose I create an account at winserver.com to sign up at facebook.com. > > What RRVS value is going to be passed to winserver.com and what do I > compare it with? You would in theory go through a "confirm you own this email address" step, and Facebook (or whoever) would save the timestamp when you did so. After that, email to your winserver.com address would include RRVS=that-timestamp on RCPT TO lines, and your MTA would determine whether that email address has changed owners since that-timestamp before deciding to accept or reject. > > Is Winserver.com expected to save this value for the user? > If it advertises the RRVS extension or understands the header field, it is expected to save the local account's creation date for comparison to incoming timestamps from clients that also use this extension or header field. Otherwise, obviously, it can't participate. > > It sounds to me that we will need to save RRVS values PER client domain > because each can have its own understanding of the RRVS value or not at > all. Is this correct? > If you're participating in this, you need to save account creation dates for all mailboxes for which you do local delivery, or otherwise derive them. > > I still don't have the complete "Ah Ha" on how this is going to work to > safely deal with expired accounts which I expect this proposal is expecting > the accounts will never be deleted but perhaps marked inactive in order to > be able to have a history of RRVS values. > If the account is deleted, I presume you return 550. If you then reassign that account to someone else, you would remember the timestamp when you did so, and then start rejecting messages that fail the RRVS check on a reassigned mailbox, and deliver the rest. -MSK --089e01184e565ba67e04eb242aee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Nov 14, 2013 at 5:40 AM, Hector Santos <hsantos@= isdg.net> wrote:
I'm not Bill, John nor Ned, but I hope y= ou can shine some light here.

Suppose I create an account at winserver.com to sign up at facebook.com.

What RRVS value is going to be passed to winserver.com and what do I compare it with?=A0

You would in theory go through a "confirm yo= u own this email address" step, and Facebook (or whoever) would save t= he timestamp when you did so.=A0 After that, email to your winserver.com address would include RRVS=3Dthat-timest= amp on RCPT TO lines, and your MTA would determine whether that email addre= ss has changed owners since that-timestamp before deciding to accept or rej= ect.
=A0

Is Winserver.com expected to save this value for the user?
=

If it advertises the RRVS extension or understands the = header field, it is expected to save the local account's creation date = for comparison to incoming timestamps from clients that also use this exten= sion or header field.=A0 Otherwise, obviously, it can't participate. =A0

It sounds to me that we will need to save RRVS values PER client domain bec= ause each can have its own understanding of the RRVS value or not at all. I= s this correct?

If you're participa= ting in this, you need to save account creation dates for all mailboxes for= which you do local delivery, or otherwise derive them.
=A0

I still don't have the complete "Ah Ha" on how this is going = to work to safely deal with expired accounts which I expect this proposal i= s expecting the accounts will never be deleted but perhaps marked inactive = in order to be able to have a history of RRVS values.

If the account is deleted, I presume you r= eturn 550.=A0 If you then reassign that account to someone else, you would = remember the timestamp when you did so, and then start rejecting messages t= hat fail the RRVS check on a reassigned mailbox, and deliver the rest.

-MSK

--089e01184e565ba67e04eb242aee-- From prvs=0229835c1=kandersen@linkedin.com Wed Nov 13 10:50:00 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4451811E8136 for ; Wed, 13 Nov 2013 10:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.916 X-Spam-Level: X-Spam-Status: No, score=-5.916 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiCOG0rslwLD for ; Wed, 13 Nov 2013 10:49:49 -0800 (PST) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id AA49C11E8126 for ; Wed, 13 Nov 2013 10:49:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1384368589; x=1415904589; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=AU4qg8blMb8XPkRWEstxYawL9Vp60CEPfiUZ6ZV1t+k=; b=AqcvLjMSKQFqu7d/I0TPsGhy7kcPI8vdFhHbdfVLh3J9JItu1EuAEE/M /XdSTDq9a4DBYUMdFu0NaEpGHyhICaL8WM2yZ5/l5k6y1BkOKSkA4wnQp BWWF5Trmt1QlCWX7SCyIQe8Nsa0GaXCfxWSRYh0mfcM0eJrMkR/72/l8M o=; X-IronPort-AV: E=Sophos;i="4.93,693,1378882800"; d="scan'208,217";a="70327574" Received: from esv4-exctest.linkedin.biz (172.18.46.60) by esv4-cas01.linkedin.biz (172.18.46.140) with Microsoft SMTP Server (TLS) id 14.2.328.11; Wed, 13 Nov 2013 10:49:46 -0800 Received: from ESV4-EXC01.linkedin.biz ([fe80::d7c:dc04:aea1:97d7]) by esv4-exctest.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Wed, 13 Nov 2013 10:49:46 -0800 From: Kurt Andersen To: Bill Mills , John R Levine Thread-Topic: [apps-discuss] SMTP extension Re: I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt Thread-Index: AQHO4KEfaGw38BvegEioS3gXnTUvZw== Date: Wed, 13 Nov 2013 18:49:45 +0000 Message-ID: <3560C13B3A3EC9408B4BFEDB3B7283956018C6A8@esv4-exc01.linkedin.biz> In-Reply-To: <1384309209.26140.YahooMailNeo@web125605.mail.ne1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.253] Content-Type: multipart/alternative; boundary="_000_3560C13B3A3EC9408B4BFEDB3B7283956018C6A8esv4exc01linked_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 14 Nov 2013 08:58:30 -0800 Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] SMTP extension Re: I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Nov 2013 18:50:00 -0000 --_000_3560C13B3A3EC9408B4BFEDB3B7283956018C6A8esv4exc01linked_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We would find it difficult to implement an extension any time soon as well.= We are quite happy sending with the header. --Kurt Andersen LinkedIn On 2013-11-12 18:20 , "Bill Mills" > wrote: The previous drafts documented the header usage that Yahoo and Facebook are= already using. I believe Google is implementing currently, I don't know o= ffhand what other sources are sending it. -bill -------------------------------- William J. Mills "Paranoid" Yahoo! On Tuesday, November 12, 2013 6:17 PM, John R Levine > wrote: > So, abandon the SMTP extension and the running code with major interop > both? That doesn't sound like a win. > > I don't know how quickly we'd implement an SMTP extension. The current draft just describes the SMTP extension. If Yahoo isn't planning to implement it, I'm not aware of anyone else who is, so I don't see any point in spending effort on shepherd write up, last call, and so forth for an RFC that nobody will use. On the other hand, if you've implemented the RRVS header and particularly if you know of other people who've done so and they interoperate, we should document that even if it is inferior in principle to the SMTP version. Regards, John Levine, johnl@taugh.com, Taughannock Networks,= Trumansburg NY Please consider the environment before reading this e-mail. --_000_3560C13B3A3EC9408B4BFEDB3B7283956018C6A8esv4exc01linked_ Content-Type: text/html; charset="us-ascii" Content-ID: <2B66128821907B438DAA66E975A28629@linkedin.com> Content-Transfer-Encoding: quoted-printable
We would find it difficult to implement an extension any time soon as = well. We are quite happy sending with the header.

--Kurt Andersen
  LinkedIn

On 2013-11-12 18:20 , "Bill Mills" <wmills@yahoo-inc.com> wrote:

The previous drafts documented the header usage that Yahoo and Facebook are= already using.  I believe Google is implementing currently, I don't k= now offhand what other sources are sending it.

 
-bill


--------------------------------
William J. Mills
"Paranoid" Yahoo!



On Tuesday, November 12, 2= 013 6:17 PM, John R Levine <johnl@tau= gh.com> wrote:
> So, abandon the SMTP extension and the = running code with major interop
> both?  That doesn't sound like a win.
>
> I don't know how quickly we'd implement an SMTP extension.

The current draft just describes the SMTP extension.  If Yahoo isn't <= br clear=3D"none"> planning to implement it, I'm not aware of anyone else who is, so I don't <= br clear=3D"none"> see any point in spending effort on shepherd write up, last call, and so forth for an RFC that nobody will use.

On the other hand, if you've implemented the RRVS header and particularly <= br clear=3D"none"> if you know of other people who've done so and they interoperate, we
should document that even if it is inferior in principle to the SMTP
version.


Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.


 --_000_3560C13B3A3EC9408B4BFEDB3B7283956018C6A8esv4exc01linked_-- From paul@paulgrosso.name Thu Nov 14 07:10:00 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0252C21E80F5 for ; Thu, 14 Nov 2013 07:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMLx9iqdazLO for ; Thu, 14 Nov 2013 07:09:54 -0800 (PST) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [70.85.6.5]) by ietfa.amsl.com (Postfix) with ESMTP id A31EF11E8132 for ; Thu, 14 Nov 2013 07:09:54 -0800 (PST) Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id 9504D9F4CFAC8; Thu, 14 Nov 2013 09:09:53 -0600 (CST) Received: from colorado.websitewelcome.com (colorado.websitewelcome.com [192.185.82.155]) by gateway12.websitewelcome.com (Postfix) with ESMTP id 230819F4CF941 for ; Thu, 14 Nov 2013 09:09:53 -0600 (CST) Received: from [70.113.58.209] (port=64761 helo=[192.168.200.38]) by colorado.websitewelcome.com with esmtpa (Exim 4.80) (envelope-from ) id 1VgyYK-0003nC-Mp; Thu, 14 Nov 2013 09:09:52 -0600 Message-ID: <5284E7BA.9030705@paulgrosso.name> Date: Thu, 14 Nov 2013 09:09:46 -0600 From: Paul Grosso User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: superuser@gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - colorado.websitewelcome.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - paulgrosso.name X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.200.38]) [70.113.58.209]:64761 X-Source-Auth: paul+paulgrosso.name X-Email-Count: 3 X-Source-Cap: cGF1bGdyb3M7Y2xlYXJsaWc7Y29sb3JhZG8ud2Vic2l0ZXdlbGNvbWUuY29t X-Mailman-Approved-At: Thu, 14 Nov 2013 08:58:30 -0800 Cc: core , apps-discuss@ietf.org Subject: [apps-discuss] Comment in support of appsawg-xml-mediatypes-04 aka 3023-bis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 15:24:50 -0000 Dear IETF, The W3C XML Core Working Group is pleased to see the recent progress made toward a replacement for RFC 3023. We have reviewed the 2013 November 4 draft at http://www.ietf.org/id/draft-ietf-appsawg-xml-mediatypes-04.txt and would like to support its transition to RFC. Our Working Group members have made several comments on earlier drafts as well as reviewed the comments and dispositions of others as evidenced by http://www.w3.org/XML/2012/10/3023bis/02-comments.html and various emails archived in our groups mailing list at http://lists.w3.org/Archives/Public/public-xml-core-wg/2013Sep/0010 and http://lists.w3.org/Archives/Public/public-xml-core-wg/2013Sep/0019 and various other threads. We look forward to having an updated replacement to RFC 3023. Paul Grosso, co-chair for the W3C XML Core Working Group From prvs=002379d062=johnl@iecc.com Thu Nov 14 09:54:45 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF4621F9343 for ; Thu, 14 Nov 2013 09:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2lAcVfX63ww for ; Thu, 14 Nov 2013 09:54:41 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 89DED21F9C6A for ; Thu, 14 Nov 2013 09:54:41 -0800 (PST) Received: (qmail 52602 invoked from network); 14 Nov 2013 17:54:39 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 14 Nov 2013 17:54:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52850e5f.xn--hew.k1310; i=johnl@user.iecc.com; bh=GMlIQH/KEWD7+0mQPW3kA6XDkQm3hM9J80BJoqBvh8Q=; b=wXnj7TB/9etv1sYle4nb6qIAtKM91289bLxo6VYTh6OGXqM46YJOaW0MmQVZEG6tSuzEmqZPsqI8GxnSXJbvjrmhUmwnLvRSEafcwKhRM/fRZVoXybYPWhU46YuKeXnCb6j/bshzTLxa7ALR27zYvRDjiaeOvOMFoQSoceUD6+kKChu69GfGSAcKTqnP8CQuscapxxRzbfR1dhg3HOGqqrhgQBGEj5PL7sdIMLuyT4srpOh5jvPRlIiTOIidXcWy DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52850e5f.xn--hew.k1310; olt=johnl@user.iecc.com; bh=GMlIQH/KEWD7+0mQPW3kA6XDkQm3hM9J80BJoqBvh8Q=; b=A4UVNhIGNbIxsQFz8EDqWsombnIom+T+ddoYBLlQcUBZRNh0Y2lrmswJfm0V7LbbICu5lk+EhZD9DIvTTVeCjiVOPr44tgOdNJrldaqgzEnRg3c69iThwpP8WJWg7vrgyn7Zv59DDUeH7oivThmPnu88vO/BMyPAjc2MdkNWiuw1byKICkruZ+ANRDBWZ/B9/PhOr+GwkNZ2aHepBrNOzG50tmPGu2vw4gmYzH1Mwyxg+nx0I6fDHLMaGg27MLDl Date: 14 Nov 2013 17:54:17 -0000 Message-ID: <20131114175417.97596.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 17:54:46 -0000 >Please (Bill, John and Ned especially) let me know if I've missed anything >here. Near the bottom of page 5, in 4.1.1 it says RRVS RRVS. When you fix that, you might say something like: If the relaying system knows the time when the alias was established, it MAY add an RRVS parameter for the new target address that includes that time. (Based on recent mail, Ned was confused by this, and if it confuses him, it could confuse anyone.) On page 7, near the top, the paragraph about multiple recipients seems wrong. It says "and if any one of them fails the test, the delivery fails to all of them". The options are to interpret the header at the end of data and reject, which will fail for all the recipients, or to accept at the end of data, deliver to some and send DSNs for the others. Last pp of section 8 at the top of page 9, there are lots of reasons for the recipient not to be on the To: line beyond morally questionable address munging. Obvious examples are mailing lists where the To: is the list address, and ordinary correspondence where the recipient is on the Cc: or Bcc: lines. Just note that SMTP has never required that envelope and header addresses correspond, so the RRVS header contains the envelope address to which the timestamp applies. I'd still like the A-R phrase to log the RRVS envelope info. If I implement it, that's what I'll use. From ietfc@btconnect.com Thu Nov 14 10:35:51 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1395D11E8132 for ; Thu, 14 Nov 2013 10:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfEVYAFriBvr for ; Thu, 14 Nov 2013 10:35:34 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 6236F11E80F7 for ; Thu, 14 Nov 2013 10:35:34 -0800 (PST) Received: from mail91-co1-R.bigfish.com (10.243.78.248) by CO1EHSOBE005.bigfish.com (10.243.66.68) with Microsoft SMTP Server id 14.1.225.22; Thu, 14 Nov 2013 18:35:32 +0000 Received: from mail91-co1 (localhost [127.0.0.1]) by mail91-co1-R.bigfish.com (Postfix) with ESMTP id C4BFD4C0443; Thu, 14 Nov 2013 18:35:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: PS-19(zz98dI9371I936eI146fI542I1432I1418I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h20f7h1d1ah1d2ah1fc6hzd9hz8275ch1de098h1033IL8275bh8275dh1de097hz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h2218h2216h304l1d11m1155h) Received: from mail91-co1 (localhost.localdomain [127.0.0.1]) by mail91-co1 (MessageSwitch) id 1384454130976766_13549; Thu, 14 Nov 2013 18:35:30 +0000 (UTC) Received: from CO1EHSMHS013.bigfish.com (unknown [10.243.78.248]) by mail91-co1.bigfish.com (Postfix) with ESMTP id EA90550004C; Thu, 14 Nov 2013 18:35:30 +0000 (UTC) Received: from AMSPRD0710HT002.eurprd07.prod.outlook.com (157.56.249.85) by CO1EHSMHS013.bigfish.com (10.243.66.23) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 14 Nov 2013 18:35:30 +0000 Received: from AMXPRD0111HT001.eurprd01.prod.exchangelabs.com (157.56.250.117) by pod51017.outlook.com (10.255.160.165) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 14 Nov 2013 18:35:12 +0000 Message-ID: <03c601cee167$e4cf6040$4001a8c0@gateway.2wire.net> From: t.petch To: "Murray S. Kucherawy" , Erik Wilde , Dave Cridland References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com><5238B9E9.7010204@gmx.de><525CF2A8.2090904@berkeley.edu><6vcq5950d7mclheqfcjna5hdue19arqfm8@hive.bjoern.hoehrmann.de><525D386B.3070705@gmx.de><525D3D24.3030702@gmx.de><525D7877.6080905@gmx.de><024801cecb55$e478be20$4001a8c0@gateway.2wire.net> Date: Thu, 14 Nov 2013 18:32:31 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.250.117] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Julian Reschke , Bjoern Hoehrmann , IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call:draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 18:35:51 -0000 Sigh The point I raised has been addressed, which is good. But, doing the homework I should have done earlier, how does this I-D interact with RFC6657 which says "registrations for "text/*" media types that can transport charset information inside the corresponding payloads (such as "text/html" and "text/xml") SHOULD NOT specify the use of a "charset" parameter, nor any default value, in order to avoid conflicting interpretations should the "charset" parameter value and the value specified in the payload disagree" Seems to me that this RFC text is being updated and that that should appear both in rfc-index (and on the IANA website). And, what about all the application/*+xml registrations in existence, along with a few message/*+xml and model/*+xml? How will anyone looking up these have any idea that this I-D provides guidance for them (which is what this I-D is claiming)? I think that you are giving IANA too big a challenge and that more specific guidance is needed in section 10. Tom Petch ----- Original Message ----- From: "Murray S. Kucherawy" To: "t.petch" ; "Erik Wilde" ; "Dave Cridland" Cc: "Julian Reschke" ; "Henry S. Thompson" ; "Bjoern Hoehrmann" ; "IETF Apps Discuss" Sent: Thursday, November 07, 2013 9:44 PM > Colleagues, but specifically Tom, Erik, Dave, Julian and Bjoern: > > Can you have a look at the latest version of this draft (or the diffs, > available via the tracker) and let us know if you think it's ready to go in > its latest form? > > Thanks, > -MSK, APPSAWG co-chair > > On Thu, Oct 17, 2013 at 9:23 AM, t.petch wrote: > > > ----- Original Message ----- > > From: "Julian Reschke" > > To: "Henry S. Thompson" > > Cc: "Bjoern Hoehrmann" ; > > Sent: Tuesday, October 15, 2013 6:16 PM > > > On 2013-10-15 19:08, Henry S. Thompson wrote: > > > > Julian Reschke writes: > > > > > > > >> The point I was trying to make is that we now have a registry. The > > > >> registry is authoritative; if we move the definition of "+xml", > > it's > > > >> sufficient to simply update the registry. > > > > > > > > I don't agree. If we don't include 'Updates: 6839', then 6839 will > > > > not get an 'Updated by [3023bis]', and anyone reading 6839 will be > > > > free to conclude that it defines +xml, which would be false. > > > > > > Anyone reading it that way would be reading it incorrectly :-) > > > > > > But anyway, that's something the IESG can worry about. > > > > Having just read about the difficulty in finding potential members of > > the IESG, I think we should do what we can as a WG to make the task of > > the IESG simpler, in this case by putting forward a rough consensus from > > the WG. > > > > I am with Henry on this one. It is true that if your world revolves > > around web pages, then the IANA web page will take you to the current > > definition whereever that is. But if you start with RFC, for example > > with the rfc-index, and that does not mention an update to an RFC, then > > you will go astray. > > > > Comparing the two definitions, in RFC6839 and this I-D, they seem to me > > like chalk and cheese, as for example in who has change control and who > > the contact is, so that the RFC6839 one will be wiped from the face of > > the earth; specifying 'Updates' seems the least we can do. > > > > Tom Petch > > > > > Best regards, Julian > > > From julian.reschke@gmx.de Thu Nov 14 10:51:10 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD9421E80B6 for ; Thu, 14 Nov 2013 10:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.341 X-Spam-Level: X-Spam-Status: No, score=-103.341 tagged_above=-999 required=5 tests=[AWL=-1.342, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqOsnuerxX5s for ; Thu, 14 Nov 2013 10:51:04 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id B7E8D21E80AE for ; Thu, 14 Nov 2013 10:50:59 -0800 (PST) Received: from [192.168.2.117] ([93.217.110.173]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LzXTy-1VdP1e10b4-014gOF for ; Thu, 14 Nov 2013 19:50:56 +0100 Message-ID: <52851B8C.3090601@gmx.de> Date: Thu, 14 Nov 2013 19:50:52 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "t.petch" , "Murray S. Kucherawy" , Erik Wilde , Dave Cridland References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com><5238B9E9.7010204@gmx.de><525CF2A8.2090904@berkeley.edu><6vcq5950d7mclheqfcjna5hdue19arqfm8@hive.bjoern.hoehrmann.de><525D386B.3070705@gmx.de><525D3D24.3030702@gmx.de><525D7877.6080905@gmx.de><024801cecb55$e478be20$4001a8c0@gateway.2wire.net> <03c601cee167$e4cf6040$4001a8c0@gateway.2wire.net> In-Reply-To: <03c601cee167$e4cf6040$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:fHrQo1vTdT5jDOFNZ37AL/Ae3XXSmLvgoVW7XZDWSjhkYxxf2P4 //CevHEbIg2Lo0quSjCGn5FuM6KIjRRjVUERLUt3rXgYl+jBAO0ANQi03PcolSAwLxfzR5o IBzgLcN1ZYXosVSyDHZbKfEv75hSgt62QqXecbEtwdGuEDP/3s1gH6ck7idEXJaYyF529tD WTcFOuJI5bUBKHunjZ8DA== Cc: Bjoern Hoehrmann , IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call:draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 18:51:10 -0000 On 2013-11-14 19:32, t.petch wrote: > Sigh > > The point I raised has been addressed, which is good. > > But, doing the homework I should have done earlier, how does this I-D > interact with RFC6657 which says > "registrations for "text/*" media > types that can transport charset information inside the corresponding > payloads (such as "text/html" and "text/xml") SHOULD NOT specify the > use of a "charset" parameter, nor any default value, in order to > avoid conflicting interpretations should the "charset" parameter > value and the value specified in the payload disagree" > > Seems to me that this RFC text is being updated and that that should > appear both in rfc-index (and on the IANA website). Um, no. That RFC is not updated- The intent of the sentence you quote was of course to apply to *new* registrations. It was not a goal to force a change on existing ones. > And, what about all the application/*+xml registrations in existence, > along with a few message/*+xml and model/*+xml? How will anyone looking > up these have any idea that this I-D provides guidance for them (which > is what this I-D is claiming)? Is it? What specifically? (Or is this again about new registrations?) > I think that you are giving IANA too big a challenge and that more > specific guidance is needed in section 10. > > Tom Petch Best regards, Julian From tony@att.com Thu Nov 14 17:19:07 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F45121E80A8 for ; Thu, 14 Nov 2013 17:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.096 X-Spam-Level: X-Spam-Status: No, score=-103.096 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBUOcomh2Hjo for ; Thu, 14 Nov 2013 17:19:00 -0800 (PST) Received: from flpi406.enaf.ffdc.sbc.com (egssmtp03.att.com [144.160.128.152]) by ietfa.amsl.com (Postfix) with ESMTP id 8C04A21F9B4B for ; Thu, 14 Nov 2013 17:19:00 -0800 (PST) Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp03.att.com (8.14.4/8.14.4) with ESMTP id rAF1Ixnu029061 for ; Thu, 14 Nov 2013 17:19:00 -0800 Received: from [135.70.25.43] (vpn-135-70-25-43.vpn.west.att.com[135.70.25.43]) by maillennium.att.com (mailgw1) with ESMTP id <20131115011853gw100j0c1ae> (Authid: tony); Fri, 15 Nov 2013 01:18:58 +0000 X-Originating-IP: [135.70.25.43] Message-ID: <5285767C.1090905@att.com> Date: Thu, 14 Nov 2013 20:18:52 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Henry S. Thompson" References: <527F1521.1050602@att.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Change controller for +xml (was Re: A review of draft-ietf-appsawg-xml-mediatypes-04) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 01:19:07 -0000 On 11/12/2013 8:20 AM, Henry S. Thompson wrote: > Tony Hansen writes: > >> Section 8.2 +xml Structured Syntax Suffix Registration >> >> MAJOR >> >> Under Change controller, it has a comment about "the XML >> specification" being a work product of the WWW MXL WorkingCore >> Group. While "the XML specification" is certainly related to +xml >> and this is nice historical information about XML, the statement >> says nothing about who the +xml change controller is. >> >> I'll make no comment about who the change controller *should* be; >> other people can discuss that if they so choose. But assuming that >> the authors wish to CHANGE the change controller from what was >> specified in RFC 6839, >> >> *) I think there should be explicit mention of this in the >> comments in section 8. > Where in section 8, exactly? Section 8 is where you introduce the other changes from 6839 to this draft. I suggest you add a short statement at the end of it. Something like the following would be okay: In addition to the changes described above, the change controller has been changed to the W3C. >> *) The statement in section 8.2 needs to say *who* the change >> controller is. > I would welcome some further guidance on this point. The change > controller field for the /xml media types themselves, in sections > 3.1, 3.3 and 3.5, uses exactly the same (after typo corrected) wording. > > I also note that other media type registrations from the W3C > (e.g. xslt+xml [1], exi [2]) use the same wording, plus a further > sentence: "The W3C has change control over this specification". > > So, two questions: > > 1) Is there any reason not to use the same wording in all of 3.1, 3.3 > and 3.5? > 2) If so, should that wording be > > The XML specification is a work product of the World Wide Web > Consortium's XML Core Working Group. The W3C has change control > over this specification. > > ? If not, then what? The statement "The W3C has change control over this specification" is exactly what is needed and completely sufficient. The rest of the current content in that the current Change controller is superfluous, but should be okay to leave there if you prefer. Tony Hansen > Thanks, > > ht > > [1] http://www.w3.org/TR/2007/REC-xslt20-20070123/#media-type-registration > [2] http://www.w3.org/TR/2009/CR-exi-20091208/#mediaTypeRegistration From ned.freed@mrochek.com Thu Nov 14 19:20:43 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A50B11E8179 for ; Thu, 14 Nov 2013 19:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aT9D83xWsroQ for ; Thu, 14 Nov 2013 19:20:38 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED3A11E810C for ; Thu, 14 Nov 2013 19:20:38 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P0SB4SRXU8000P1W@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 14 Nov 2013 18:05:42 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P0DS85DTO000004G@mauve.mrochek.com>; Thu, 14 Nov 2013 18:05:40 -0800 (PST) Message-id: <01P0SB4RIKPA00004G@mauve.mrochek.com> Date: Thu, 14 Nov 2013 15:24:54 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 13 Nov 2013 16:33:19 -0800" References: <20131106213938.20980.30376.idtracker@ietfa.amsl.com> <527B07B8.1070103@isode.com> To: "Murray S. Kucherawy" Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 03:20:43 -0000 > On Wed, Nov 6, 2013 at 7:23 PM, Alexey Melnikov > wrote: > > > > 4.2. SMTP Extension Not Offered > > > > For a message being sent that includes content meant to be protected > > by this extension, the client MUST NOT continue to deliver a message > > to a server > > > > That might be nitpicking, but if a message has multiple recipients on the > > same server, some with the RRVS parameter and some without, I think you > > only want non deliver for recipients with the RRVS parameter present. The > > above doesn't say that. > > > where the server does not advertise the RRVS SMTP > > extension. > > > > What is the error code to return? > > > We're going back a version, so this will disappear. The text may have disappeared, but the issue of how to handle forwarding a message using the extension to a system that doesn't support it still exists. There are basically three options: (1) Do what the SMTP-extension-only draft said, and assign an error code for that case. (2) Silently drop the RRVS parameter. (3) Downgrade the RRVS parameter into a Require-Recipient-Valid-Since header field. I'm currently doing (2), but Chris has convinced me that this is a security issue and (1) is the right choice for a relay client, so I'm going to switch. (I believe this is only the second time we've ever specified an SMTP extension that calls for bouncing certain messages if the extension isn't there. The first was EAI.) A submission client is another matter. This client actually "owns" the data being exposed, as such, it is in a position to elect to use (3) if it wants to. Ned From ned.freed@mrochek.com Thu Nov 14 23:20:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22E021F9C32 for ; Thu, 14 Nov 2013 23:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hsZMgEGYB17 for ; Thu, 14 Nov 2013 23:20:06 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id DAAA221F9B10 for ; Thu, 14 Nov 2013 23:19:57 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P0S5H6JNRK000PKZ@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 14 Nov 2013 15:23:54 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P0DS85DTO000004G@mauve.mrochek.com>; Thu, 14 Nov 2013 15:23:50 -0800 (PST) Message-id: <01P0S5H4KKS600004G@mauve.mrochek.com> Date: Thu, 14 Nov 2013 14:52:30 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 13 Nov 2013 16:43:53 -0800" References: <20131022182337.4789.qmail@joyce.lan> <01P00BXM2CJU00004R@mauve.mrochek.com> To: "Murray S. Kucherawy" Cc: John Levine , Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 07:20:12 -0000 > On Fri, Oct 25, 2013 at 4:03 PM, Ned Freed wrote: > > Anyway, once I had the extension I started in on the header stuff. I > > expected > > this to be harder due to the need to handle the header-envelope matcheup as > > well as the possibility of partial failures, but I was gobsmacked at the > > difficultly. This has taken me literally days to get right. > > > > The multiple recipient issue is a big part of it, but not all. Just as > > one example of how tricky the multiple recipient issue is, suppose you > > have two recipients A and B that forward to the same address C: > > > > A -> C > > B -> C > > > The author only has a timestamp at which it thought A and B had confirmed > owners of interest. The author has no idea that A and B are forwarded to > C, or to anywhere at all. Assuming by "author" you mean sender, I'm not talking about what the author knows, which is obviously one date per recipient address. I'm talking about how the mail system handles the case where two accounts with their own creation dates have both forwarded mail to a common destination. This is the problem with having to wait to handle things until the message is transferred - you've already accepted and expanded the recipients, and life is no longer as simple as just issuing a 5YZ code to the RCPT TO. In order to do this "correctly" what you have to do is store a list of every initial address that mapped to a final address and the associated RRVS timestamp. Of course this all depends on the data structures you've used. And as I said, I think this is enough of a corner case given the focus of this extension that I'll deal with this issue only if it becomes a problem. > > So what recreation date do you attach to that one address? If either one > > doesn't have a recreation date the answe is "you don't attach one". But > > they > > both do the correct thing is to attach and check both. That means making > > some > > data structure changes, which to be honest I didn't bother to do. I think > > this > > is enough of a corner case that I can ignore it. But I could be wrong, in > > which > > case this will be even more work. > > > The author would store the A and B confirmation dates. Of course, but the issue is that both apply to C and you have to keep track of that fact. > > But this is nasty even if there's only a single recipient and header. The > > basic > > problem is you've introduced a new failure case after the content of the > > message has been received, and it turns out to have somewhat different > > semantics from other failure cases at this point, in my implementation at > > least. > > > The failure would be a bounce from the receiver, right? If you're talking > about a failure from the MSA, I'm not sure why that would be a problem > specific to this extension. But that's exactly the problem: This is a failure case with somewhat different semantics. > > > > It's not like throwing out the message because, say, it was a big pile of > > binary nonsense. Or because it violated overall site policy in some way. In > > such cases there's justification for returning an error and dropping the > > trash > > in the trashcan. But RRVS differs in that it's almost certainly a bad idea > > to > > ignore legal intercept or other archiving requirements for what is, after > > all a > > valid message. (And before you say otherwise, think what happens when Silk > > Road > > supports this on the sending side.) > > > You're talking about a receiver implementing those features, I presume. Is > that something that we need to talk about in this draft? Seems like a > sentence or two would suffice if so, but I haven't seen that mentioned in > other extensions. I can't really recommend adding anything about any of this. The IETF seems to have developed a rather peculiar attitude about implementation advice of late; it seems it gets taken as directives as to how things have to be and judged on that basis. > > > > This led me to conclude that RRVS is much more like a sieve ereject - which > > already had support in place for multiple recipients - and that's more or > > less > > how I ended up implementing it. But the interactions with actual sieves are > > different, the handling in the event of sieve errors are different, and > > ereject > > doesn't allow specification of a specific enhanced status code so support > > for > > that had to be added. > > > Wouldn't an implementing receiver just do an SMTP rejection for the RCPT TO > commands for which the test failed, and continue otherwise? Again, is this > a new problem specific to RRVS? In the case of the SMTP extension, sure. I'm not talking about that; I'm talking about the header approach. This is all part and parcel of why the SMTP extension is easier to handle than the header. Ned From ht@inf.ed.ac.uk Fri Nov 15 02:29:40 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5BE11E819F for ; Fri, 15 Nov 2013 02:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mwimoi9SfGdl for ; Fri, 15 Nov 2013 02:29:33 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5006F11E8172 for ; Fri, 15 Nov 2013 02:29:33 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rAFATNl4008272; Fri, 15 Nov 2013 10:29:24 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAFATM4M023090; Fri, 15 Nov 2013 10:29:22 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAFATNMf029405; Fri, 15 Nov 2013 10:29:23 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rAFATMrb029401; Fri, 15 Nov 2013 10:29:22 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Tony Hansen References: <527F1521.1050602@att.com> <5285767C.1090905@att.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 15 Nov 2013 10:29:22 +0000 In-Reply-To: <5285767C.1090905@att.com> (Tony Hansen's message of "Thu\, 14 Nov 2013 20\:18\:52 -0500") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Change controller for +xml X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 10:29:40 -0000 Tony Hansen writes: > Section 8 is where you introduce the other changes from 6839 to this > draft. I suggest you add a short statement at the end of it. Something > like the following would be okay: > > In addition to the changes described above, the change controller > has been changed to the W3C. Done. > . . . > The statement "The W3C has change control over this specification" is > exactly what is needed and completely sufficient. The rest of the > current content in that the current Change controller is superfluous, > but should be okay to leave there if you prefer. Done, so all 4 places are now identical. Thanks, ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From ht@inf.ed.ac.uk Fri Nov 15 03:05:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C239211E817B for ; Fri, 15 Nov 2013 03:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cz+Xk7qtEHTs for ; Fri, 15 Nov 2013 03:05:06 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5A611E814C for ; Fri, 15 Nov 2013 03:05:06 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rAFB4uZO004303; Fri, 15 Nov 2013 11:04:56 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAFB4utZ024965; Fri, 15 Nov 2013 11:04:56 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAFB4vq5030454; Fri, 15 Nov 2013 11:04:57 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rAFB4uxe030450; Fri, 15 Nov 2013 11:04:56 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: "t.petch" References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> <5238B9E9.7010204@gmx.de> <525CF2A8.2090904@berkeley.edu> <6vcq5950d7mclheqfcjna5hdue19arqfm8@hive.bjoern.hoehrmann.de> <525D386B.3070705@gmx.de> <525D3D24.3030702@gmx.de> <525D7877.6080905@gmx.de> <024801cecb55$e478be20$4001a8c0@gateway.2wire.net> <03c601cee167$e4cf6040$4001a8c0@gateway.2wire.net> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 15 Nov 2013 11:04:56 +0000 In-Reply-To: <03c601cee167$e4cf6040$4001a8c0@gateway.2wire.net> (t. petch's message of "Thu\, 14 Nov 2013 18\:32\:31 +0000") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: IETF Apps Discuss , Julian Reschke , Bjoern Hoehrmann Subject: Re: [apps-discuss] Working Group Last Call:draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 11:05:11 -0000 t.petch writes: > But, doing the homework I should have done earlier, how does this I-D > interact with RFC6657 which says > "registrations for "text/*" media > types that can transport charset information inside the corresponding > payloads (such as "text/html" and "text/xml") SHOULD NOT specify the > use of a "charset" parameter, nor any default value, in order to > avoid conflicting interpretations should the "charset" parameter > value and the value specified in the payload disagree" > > Seems to me that this RFC text is being updated and that that should > appear both in rfc-index (and on the IANA website). I don't think the spec updates that RFC. It is consistent with it. It only recommends (with a 'SHOULD') the use of a charset param. when there is _known_ to be _no_ encoding decl. in the payload. > And, what about all the application/*+xml registrations in existence, > along with a few message/*+xml and model/*+xml? How will anyone looking > up these have any idea that this I-D provides guidance for them (which > is what this I-D is claiming)? Such registrations should have referred to 3023 or 6839. Anyone following such references will find that those specs have been replaced/updated by the new spec. Note that this is precisely what 6839 did, and that's why it is listed as updated 3023. > I think that you are giving IANA too big a challenge and that more > specific guidance is needed in section 10. I don't think any challenge at all arises. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From ietfc@btconnect.com Fri Nov 15 07:45:25 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7229011E81B3 for ; Fri, 15 Nov 2013 07:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.987 X-Spam-Level: X-Spam-Status: No, score=-0.987 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FAKE_REPLY_C=2.012, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1-QLbFz+90t for ; Fri, 15 Nov 2013 07:45:12 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id E69B811E8210 for ; Fri, 15 Nov 2013 07:43:46 -0800 (PST) Received: from mail187-ch1-R.bigfish.com (10.43.68.227) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.22; Fri, 15 Nov 2013 15:43:43 +0000 Received: from mail187-ch1 (localhost [127.0.0.1]) by mail187-ch1-R.bigfish.com (Postfix) with ESMTP id 890103E0230; Fri, 15 Nov 2013 15:43:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.197; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: PS-19(zz98dI9371I936eI146fI542I1432I1418I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h20f7h1d1ah1d2ah1fc6hz8dhz8275ch1de098h1033IL17326ah8275bh8275dh1de097h186068hz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1e23h2218h2216h304l1d11m1155h) Received: from mail187-ch1 (localhost.localdomain [127.0.0.1]) by mail187-ch1 (MessageSwitch) id 1384530221806468_29057; Fri, 15 Nov 2013 15:43:41 +0000 (UTC) Received: from CH1EHSMHS034.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.249]) by mail187-ch1.bigfish.com (Postfix) with ESMTP id B768B180064; Fri, 15 Nov 2013 15:43:41 +0000 (UTC) Received: from DBXPRD0710HT001.eurprd07.prod.outlook.com (157.56.253.197) by CH1EHSMHS034.bigfish.com (10.43.70.34) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 15 Nov 2013 15:43:41 +0000 Received: from DBXPRD0611HT001.eurprd06.prod.outlook.com (157.56.254.85) by pod51017.outlook.com (10.255.79.164) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 15 Nov 2013 15:43:31 +0000 Message-ID: <009101cee219$12eced60$4001a8c0@gateway.2wire.net> From: t.petch To: "Murray S. Kucherawy" Date: Fri, 15 Nov 2013 15:40:46 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.254.85] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Julian Reschke , IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call:draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 15:45:25 -0000 On 2013-11-14 19:32, t.petch wrote: >Sigh > >The point I raised has been addressed, which is good. > >But, doing the homework I should have done earlier, how does this I-D >interact with RFC6657 which says >"registrations for "text/*" media > types that can transport charset information inside the corresponding > payloads (such as "text/html" and "text/xml") SHOULD NOT specify the > use of a "charset" parameter, nor any default value, in order to > avoid conflicting interpretations should the "charset" parameter > value and the value specified in the payload disagree" > >Seems to me that this RFC text is being updated and that that should >appear both in rfc-index (and on the IANA website). > Um, no. That RFC is not updated- The intent of the sentence you quote was of course to apply to *new* registrations. It was not a goal to force a change on existing ones. >And, what about all the application/*+xml registrations in existence, >along with a few message/*+xml and model/*+xml? How will anyone looking >up these have any idea that this I-D provides guidance for them (which >is what this I-D is claiming)? Is it? What specifically? (Or is this again about new registrations?) Julian What is the purpose of this I-D? s.8 says "When a new media type is introduced for an XML-based format," so I think that this I-D is talking about new registrations, as RFC6657 does. And it goes on to say " Media types following the naming convention '+xml' SHOULD introduce the charset parameter for consistency" When I go to http://www.iana.org/assignments/media-types/text I see "See [RFC6657] for information about 'charset' parameter handling for text media types." and RFC6657 says "registrations for "text/*" media types that can transport charset information inside the corresponding payloads (such as "text/html" and "text/xml") SHOULD NOT specify the use of a "charset" parameter, nor any default value, in order to avoid conflicting interpretations should the "charset" parameter value and the value specified in the payload disagree" So from this I-D - SHOULD. >From the IANA website - SHOULD NOT. Which all seems very clear and logical With the advent of this I-D, perhaps that statement on the IANA website needs to be updated, which I cannot see the I-D in its current form making happen. Tom Petch I think that you are giving IANA too big a challenge and that more specific guidance is needed in section 10. Tom Petch Best regards, Julian Tom Petch ----- Original Message ----- From: "t.petch" To: "Murray S. Kucherawy" ; "Erik Wilde" ; "Dave Cridland" Cc: "Julian Reschke" ; "Henry S. Thompson" ; "Bjoern Hoehrmann" ; "IETF Apps Discuss" Sent: Thursday, November 14, 2013 6:32 PM Subject: Re: [apps-discuss] Working Group Last Call:draft-ietf-appsawg-xml-mediatypes > Sigh > > The point I raised has been addressed, which is good. > > But, doing the homework I should have done earlier, how does this I-D > interact with RFC6657 which says > "registrations for "text/*" media > types that can transport charset information inside the corresponding > payloads (such as "text/html" and "text/xml") SHOULD NOT specify the > use of a "charset" parameter, nor any default value, in order to > avoid conflicting interpretations should the "charset" parameter > value and the value specified in the payload disagree" > > Seems to me that this RFC text is being updated and that that should > appear both in rfc-index (and on the IANA website). > > And, what about all the application/*+xml registrations in existence, > along with a few message/*+xml and model/*+xml? How will anyone looking > up these have any idea that this I-D provides guidance for them (which > is what this I-D is claiming)? > > I think that you are giving IANA too big a challenge and that more > specific guidance is needed in section 10. > > Tom Petch > > ----- Original Message ----- > From: "Murray S. Kucherawy" > To: "t.petch" ; "Erik Wilde" ; > "Dave Cridland" > Cc: "Julian Reschke" ; "Henry S. Thompson" > ; "Bjoern Hoehrmann" ; "IETF Apps > Discuss" > Sent: Thursday, November 07, 2013 9:44 PM > > Colleagues, but specifically Tom, Erik, Dave, Julian and Bjoern: > > > > Can you have a look at the latest version of this draft (or the diffs, > > available via the tracker) and let us know if you think it's ready to > go in > > its latest form? > > > > Thanks, > > -MSK, APPSAWG co-chair > > > > On Thu, Oct 17, 2013 at 9:23 AM, t.petch wrote: > > > > > ----- Original Message ----- > > > From: "Julian Reschke" > > > To: "Henry S. Thompson" > > > Cc: "Bjoern Hoehrmann" ; > > > Sent: Tuesday, October 15, 2013 6:16 PM > > > > On 2013-10-15 19:08, Henry S. Thompson wrote: > > > > > Julian Reschke writes: > > > > > > > > > >> The point I was trying to make is that we now have a registry. > The > > > > >> registry is authoritative; if we move the definition of "+xml", > > > it's > > > > >> sufficient to simply update the registry. > > > > > > > > > > I don't agree. If we don't include 'Updates: 6839', then 6839 > will > > > > > not get an 'Updated by [3023bis]', and anyone reading 6839 will > be > > > > > free to conclude that it defines +xml, which would be false. > > > > > > > > Anyone reading it that way would be reading it incorrectly :-) > > > > > > > > But anyway, that's something the IESG can worry about. > > > > > > Having just read about the difficulty in finding potential members > of > > > the IESG, I think we should do what we can as a WG to make the task > of > > > the IESG simpler, in this case by putting forward a rough consensus > from > > > the WG. > > > > > > I am with Henry on this one. It is true that if your world revolves > > > around web pages, then the IANA web page will take you to the > current > > > definition whereever that is. But if you start with RFC, for > example > > > with the rfc-index, and that does not mention an update to an RFC, > then > > > you will go astray. > > > > > > Comparing the two definitions, in RFC6839 and this I-D, they seem to > me > > > like chalk and cheese, as for example in who has change control and > who > > > the contact is, so that the RFC6839 one will be wiped from the face > of > > > the earth; specifying 'Updates' seems the least we can do. > > > > > > Tom Petch > > > > > > > Best regards, Julian > > > > > From julian.reschke@gmx.de Fri Nov 15 08:00:39 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736E111E81C5 for ; Fri, 15 Nov 2013 08:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-4.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEfO4SKAmIjG for ; Fri, 15 Nov 2013 08:00:29 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id B06FF11E81B3 for ; Fri, 15 Nov 2013 07:58:17 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MEccf-1Vx5NG21DV-00FmhL for ; Fri, 15 Nov 2013 16:58:15 +0100 Message-ID: <52864493.9010204@gmx.de> Date: Fri, 15 Nov 2013 16:58:11 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "t.petch" , "Murray S. Kucherawy" References: <009101cee219$12eced60$4001a8c0@gateway.2wire.net> In-Reply-To: <009101cee219$12eced60$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:HRF536LKEoNh0dh1rwpZv/StS2kyh8rep8qQkRHtVe1wPaXpi2K 4PBr0NwM3xb6NjwaPBqchLR+0744hu1udDdLqIWWN4vvkMhixyYl/khbAPL0X67KGLKBVOu zwJNwt63V6d9GpCy0lWu9ef1IZUMCnvdOedRFkNVq9VaWa7qDyLwJwBQj6vjb/QKxFW6773 ShV2mB1pzxNHGpt3VOjaQ== Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call:draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 16:00:39 -0000 On 2013-11-15 16:40, t.petch wrote: > On 2013-11-14 19:32, t.petch wrote: > ... Tom, could you please be specific about what part of the I-D you think is in conflict with RFC6657? Best regards, Julian From derhoermi@gmx.net Fri Nov 15 08:57:39 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3153A11E8117 for ; Fri, 15 Nov 2013 08:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3b6RPJekX0P for ; Fri, 15 Nov 2013 08:57:33 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 79A4F11E8128 for ; Fri, 15 Nov 2013 08:56:55 -0800 (PST) Received: from netb ([47.67.181.38]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0Mchyv-1VzAfM15LV-00HvSl for ; Fri, 15 Nov 2013 17:56:53 +0100 From: Bjoern Hoehrmann To: Julian Reschke Date: Fri, 15 Nov 2013 17:56:50 +0100 Message-ID: <6fjc895sk13el2jfn2nu975nl2p7lveg4i@hive.bjoern.hoehrmann.de> References: <009101cee219$12eced60$4001a8c0@gateway.2wire.net> <52864493.9010204@gmx.de> In-Reply-To: <52864493.9010204@gmx.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:tYxoWAOhays9eIuPdVvmHaeUC88w72i4j2U+TNS606gaYlW8oFI YTPuJShgXeALSTCDw11jherDgNyv+TguBul7NK7Tb3lylwDIO8/mjy8X3xQ29OBbJfOVLaR CSXb/Gug4EzELXLrgW9FYkgkFTAjWPXV0f80epK3WH71R5IZkh9XJl1enbvVxDBxs1nX/6X 66udedrwi8e3yyey7oYjA== Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call:draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 16:57:39 -0000 * Julian Reschke wrote: >On 2013-11-15 16:40, t.petch wrote: >> On 2013-11-14 19:32, t.petch wrote: >> ... > >Tom, > >could you please be specific about what part of the I-D you think is in >conflict with RFC6657? The draft recommends specifying a charset parameter for new text/*+xml types. RFC 6657 recommends against that. There is no conflict between the two, the whole idea behind the `+xml` convention is that software does not need to be updated every time a new `+xml` type is registered, so existing software will look at the charset parameter of unrecognised types, which practically means all `+xml` types define the parameter, and the RFC 6657 recommendation cannot apply retroactively. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From franck@peachymango.org Fri Nov 15 09:00:58 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF86A21F9B8A for ; Fri, 15 Nov 2013 09:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGfGDCjLa1Ki for ; Fri, 15 Nov 2013 09:00:54 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 7E56011E81FA for ; Fri, 15 Nov 2013 09:00:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 53E793F4389 for ; Fri, 15 Nov 2013 11:00:51 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAlMi_CfHhIB for ; Fri, 15 Nov 2013 11:00:51 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 358773F438C for ; Fri, 15 Nov 2013 11:00:51 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 292363F438A for ; Fri, 15 Nov 2013 11:00:51 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id U4AS7-FWGLbA for ; Fri, 15 Nov 2013 11:00:51 -0600 (CST) Received: from [10.0.0.12] (c-24-5-172-97.hsd1.ca.comcast.net [24.5.172.97]) by smtp-out-1.01.com (Postfix) with ESMTPSA id AE4693F4389 for ; Fri, 15 Nov 2013 11:00:50 -0600 (CST) From: Franck Martin Content-Type: multipart/alternative; boundary="Apple-Mail=_94B74F54-1C83-4AFD-B329-97B38FD843D8" Message-Id: Date: Fri, 15 Nov 2013 09:01:47 -0800 To: IETF Apps Discuss Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) Subject: [apps-discuss] SMTP+IPV6 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 17:00:59 -0000 --Apple-Mail=_94B74F54-1C83-4AFD-B329-97B38FD843D8 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii You may be interested by the following documents: A new version of I-D, draft-martin-smtp-target-host-selection-ipv4-ipv6-00.txt has been successfully submitted by Franck Martin and posted to the IETF repository. Filename: draft-martin-smtp-target-host-selection-ipv4-ipv6 Revision: 00 Title: SMTP target host selection in Mixed IPv4/IPv6 environments Creation date: 2013-11-14 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-martin-smtp-target-host-selection-i pv4-ipv6-00.txt Status: http://datatracker.ietf.org/doc/draft-martin-smtp-target-host-selection-ipv4- ipv6 Htmlized: http://tools.ietf.org/html/draft-martin-smtp-target-host-selection-ipv4-ipv6- 00 Abstract: The Simple Mail Transfer Protocol (SMTP) is defined in [RFC5321]. Section 5 of that document describes the process of host selection. While locating the target host in IPv4 is well defined, this process is unclear for sytems in IPv4 and IPv6 environemts. This specification extends [RFC5321] to provide a standard way of selecting the target host in mixed environments. -------- A new version of I-D, draft-martin-smtp-ipv6-to-ipv4-fallback-00.txt has been successfully submitted by Franck Martin and posted to the IETF repository. Filename: draft-martin-smtp-ipv6-to-ipv4-fallback Revision: 00 Title: SMTP IPv6 to IPv4 Fallback: An Applicability Statement Creation date: 2013-11-14 Group: Individual Submission Number of pages: 12 URL: http://www.ietf.org/internet-drafts/draft-martin-smtp-ipv6-to-ipv4-fallback-0 0.txt Status: http://datatracker.ietf.org/doc/draft-martin-smtp-ipv6-to-ipv4-fallback Htmlized: http://tools.ietf.org/html/draft-martin-smtp-ipv6-to-ipv4-fallback-00 Abstract: This Applicability Statement describes how Mail Transfer Agents (MTAs) can be encouraged to fall back to IPv4 when a message is refused over IPv6. --Apple-Mail=_94B74F54-1C83-4AFD-B329-97B38FD843D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii You = may be interested by the following documents:

A new version of = I-D,
draft-martin-smtp-target-host-selection-ipv4-ipv6-00.txt
has = been successfully submitted by Franck Martin and posted to the
IETF = repository.

Filename: =  draft-martin-smtp-target-host-selection-ipv4-ipv6
Revision= : =  00
Title:  SMTP target host selection = in Mixed IPv4/IPv6 environments
Creation date: =  2013-11-14
Group:  Individual = Submission
Number of pages: 6
URL:
http://www.ietf.org/internet-drafts/draft-martin-smtp-target-= host-selection-i
pv4-ipv6-00.txt
Status:
http://datatracker.ietf.org/doc/draft-martin-smtp-target-host= -selection-ipv4-
ipv6
Htmlized:
http://tools.ietf.org/html/draft-martin-smtp-target-host-sele= ction-ipv4-ipv6-
00


Abstract:
 The Simple Mail = Transfer Protocol (SMTP) is defined in [RFC5321].
 Section 5 of = that document describes the process of host selection.
 While = locating the target host in IPv4 is well defined, this = process
 is unclear for sytems in IPv4 and IPv6 environemts. =  This
 specification extends [RFC5321] to provide a = standard way of
 selecting the target host in mixed = environments.

--------

A new version of I-D, = draft-martin-smtp-ipv6-to-ipv4-fallback-00.txt
has been successfully = submitted by Franck Martin and posted to the
IETF = repository.

Filename: =  draft-martin-smtp-ipv6-to-ipv4-fallback
Revision: =  00
Title:  SMTP IPv6 to IPv4 Fallback: = An Applicability Statement
Creation date:  2013-11-14
Group: =  Individual Submission
Number of pages: 12
URL:
http://www.ietf.org/internet-drafts/draft-martin-smtp-ipv6-to= -ipv4-fallback-0
0.txt
Status:
http://datatracker.ietf.org/doc/draft-martin-smtp-ipv6-to-ipv4-fall= back
Htmlized:
http://tools.ietf.org/html/draft-martin-smtp-ipv6-to-ipv4-fallback-00=


Abstract:
 This Applicability Statement = describes how Mail Transfer Agents
 (MTAs) can be encouraged to = fall back to IPv4 when a message is
 refused over = IPv6.= --Apple-Mail=_94B74F54-1C83-4AFD-B329-97B38FD843D8-- From dwing@cisco.com Fri Nov 15 11:59:19 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7737E11E8233 for ; Fri, 15 Nov 2013 11:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBMjtCR6xupb for ; Fri, 15 Nov 2013 11:59:10 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id EFE8411E8225 for ; Fri, 15 Nov 2013 11:57:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3367; q=dns/txt; s=iport; t=1384545420; x=1385755020; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=7IhY/F/I3/yERRNBf+Qmw+R636nO7hARQ5W/vqzNA0M=; b=VQoulm8Vga2KHxo92Rz+ddnltKd5DYiT4d4DuFPLzbVA6qXEn32sGk/c zXpnPtnCv7MmSPQzRU9VgnxnyM1yZyyCUTrAG8rzBFa++Kl6wcqtixdIW AH9WzFtYgycrqZgW+fYCdtvGYYVM9xDJAsSYx4xbfkhR+e0SRe1NhngFG I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAN57hlKrRDoH/2dsb2JhbABZgwc4v36BKhZ0gmY/G4k2DsEdjicBgQ4zgyeBEQOJQo5OgS+QXoNJG4EsAR8 X-IronPort-AV: E=Sophos;i="4.93,709,1378857600"; d="scan'208";a="94451269" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 15 Nov 2013 19:56:58 +0000 Received: from sjc-vpn3-279.cisco.com (sjc-vpn3-279.cisco.com [10.21.65.23]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAFJuuBn018620; Fri, 15 Nov 2013 19:56:56 GMT From: Dan Wing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Nov 2013 11:56:56 -0800 Message-Id: <1E854922-D7F6-42ED-A1EF-690F463B2E9F@cisco.com> To: apps-discuss@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: Re: [apps-discuss] SMTP+IPV6 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 19:59:19 -0000 Thanks for forwarding a pointer to your new I-D, = http://tools.ietf.org/html/draft-martin-smtp-target-host-selection-ipv4-ip= v6-00. A few comments: The sender-SMTP server first tries all the IP addresses (IPv4 and IPv6) with higher preference (lower number) before the IP addresses with lower preference (higher number). The sender-SMTP server tries all the addresses up to a limit before deciding if the message is deliverable or not. The sender-SMTP server tries at least two addresses in each IP familly it is enabled (2 IPv4 addresses if IPv4 capable and 2 IPv6 addresses if IPv6 capable). Could that paragraph be edited for greater clarity? I don't understand = the interaction between the sender's limited number of addresses it = tries and trying at least two addresses in each IP address family. I = believe the intent is that, prior to exhausting the limit of addresses = it tries, it tries at least two addresses belonging to the 'other' = address family. For the same MX RR preference, when there is more than one IP address (IPv4/IPv6) to be tried, the sender-SMTP SHOULD maintain an internal sub preference list based on the rate of successful delivery of messages and based on the speed of such delivery. I'm not too keen on measuring delivery speed. How is delivery speed = measured? It can be throw off by a sender-SMTP sending a large message = with a =46rom address the receiver considers to have a poor reputation = (which triggers more thorough spam checking on the receiver-SMTP and may = well delay its response to the final dot), whereas that same sender-SMTP = might send a short message with a =46rom address the receiver considers = to have a good reputation. Is this delivery speed prioritization = necessary for proper operation of IPv4/IPv6 selection? I have not been = deeply involved in SMTP in years, so perhaps this sort of delivery speed = is used by high-end sender-SMTPs already and is state-of-the-art, but it = seems an optimization that is unnecessary for v4/v6 selection. If such internal sub preference list is not established or cannot be established then the sender-SMTP tries randomly any address within the same preference. This implies the sender-SMTP is prohibited (or discouraged?) from = following the OS's configured IP preference table (RFC6724 / RFC3484). = I don't think that is desirable or the intent. In some ways, this strategy is similar to the Happy Eveballs [RFC6555] strategy where web browsers initiate parralel connections to web servers using IPv4 and IPv6 and select the connection with better response.=20 The Happy Eyeballs RFC doesn't set up parallel connections. You might = be confusing Apple's implementation with the Happy Eyeballs RFC. = Apple's implementation does perform parallel connections when it has not = yet established a history for its network (or if the history has = decayed). After Apple's implementation has established some information = on v6 and v4 performance for that network, it reduces its aggressiveness = and no longer does parallel connections. It does periodically re-check = its assumptions because IPv6 or IPv4 performance can improve or degrade = over time, much like path MTU can improve or degrade over time. -d From franck@peachymango.org Fri Nov 15 14:29:14 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6EFD21F9D94 for ; Fri, 15 Nov 2013 14:29:14 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ME-TOk-hxKh for ; Fri, 15 Nov 2013 14:29:10 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8E921F9B9F for ; Fri, 15 Nov 2013 14:29:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 9067A3F4358; Fri, 15 Nov 2013 16:29:06 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7pCh6tdoxfS; Fri, 15 Nov 2013 16:29:06 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 714073F438B; Fri, 15 Nov 2013 16:29:06 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 630ED3F4391; Fri, 15 Nov 2013 16:29:06 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2mjV1wDk-7Bp; Fri, 15 Nov 2013 16:29:06 -0600 (CST) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id 3EFCB3F438B; Fri, 15 Nov 2013 16:29:06 -0600 (CST) Date: Fri, 15 Nov 2013 16:29:05 -0600 (CST) From: Franck Martin To: Dan Wing Message-ID: <272848605.101032.1384554545269.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <1E854922-D7F6-42ED-A1EF-690F463B2E9F@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF25 (Mac)/8.0.5_GA_5839) Thread-Topic: SMTP+IPV6 Thread-Index: RxZvLviOs5Mayg4WrGkoJyACpIPtqg== Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] SMTP+IPV6 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 22:29:15 -0000 ----- Original Message ----- > From: "Dan Wing" > To: apps-discuss@ietf.org > Cc: "Franck Martin" > Sent: Friday, November 15, 2013 11:56:56 AM > Subject: Re: SMTP+IPV6 > > Thanks for forwarding a pointer to your new I-D, > http://tools.ietf.org/html/draft-martin-smtp-target-host-selection-ipv4-ipv6-00. > A few comments: > > > The sender-SMTP server first tries all the IP addresses (IPv4 and > IPv6) with higher preference (lower number) before the IP addresses > with lower preference (higher number). The sender-SMTP server tries > all the addresses up to a limit before deciding if the message is > deliverable or not. The sender-SMTP server tries at least two > addresses in each IP familly it is enabled (2 IPv4 addresses if IPv4 > capable and 2 IPv6 addresses if IPv6 capable). > > Could that paragraph be edited for greater clarity? I don't understand the > interaction between the sender's limited number of addresses it tries and > trying at least two addresses in each IP address family. I believe the > intent is that, prior to exhausting the limit of addresses it tries, it > tries at least two addresses belonging to the 'other' address family. yes, do you have text to propose? > > > For the same MX RR preference, when there is more than one IP address > (IPv4/IPv6) to be tried, the sender-SMTP SHOULD maintain an internal > sub preference list based on the rate of successful delivery of > messages and based on the speed of such delivery. > > I'm not too keen on measuring delivery speed. How is delivery speed > measured? It can be throw off by a sender-SMTP sending a large message with > a From address the receiver considers to have a poor reputation (which > triggers more thorough spam checking on the receiver-SMTP and may well delay > its response to the final dot), whereas that same sender-SMTP might send a > short message with a From address the receiver considers to have a good > reputation. Is this delivery speed prioritization necessary for proper > operation of IPv4/IPv6 selection? I have not been deeply involved in SMTP > in years, so perhaps this sort of delivery speed is used by high-end > sender-SMTPs already and is state-of-the-art, but it seems an optimization > that is unnecessary for v4/v6 selection. > > I don't want to suggest any method, just saying that building a sub preference list based on some criteria (such as) is useful. I'll make it clearer. The MTA needs to remember which MX it tried for each message, some MX never works for some domains, so keeping this info cached, improve delivery. > If such internal > sub preference list is not established or cannot be established then > the sender-SMTP tries randomly any address within the same > preference. > > This implies the sender-SMTP is prohibited (or discouraged?) from following > the OS's configured IP preference table (RFC6724 / RFC3484). I don't think > that is desirable or the intent. > Well this could be another criteria to build the sub preference list. It depends how much statefullness you want to code... It seems to me we are moving from the OS IP preference to the application IP preference, as the application knows better what works for it than the OS. > > In some ways, this strategy is similar to the Happy > Eveballs [RFC6555] strategy where web browsers initiate parralel > connections to web servers using IPv4 and IPv6 and select the > connection with better response. > > The Happy Eyeballs RFC doesn't set up parallel connections. You might be > confusing Apple's implementation with the Happy Eyeballs RFC. Apple's > implementation does perform parallel connections when it has not yet > established a history for its network (or if the history has decayed). > After Apple's implementation has established some information on v6 and v4 > performance for that network, it reduces its aggressiveness and no longer > does parallel connections. It does periodically re-check its assumptions > because IPv6 or IPv4 performance can improve or degrade over time, much like > path MTU can improve or degrade over time. > Yes, mixed up a bit eyeballs with Safari strategy, but the idea remains the same for both, find which one works best and remember it. From dwing@cisco.com Fri Nov 15 15:48:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCAE21F93BA for ; Fri, 15 Nov 2013 15:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.321 X-Spam-Level: X-Spam-Status: No, score=-110.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9T338VTqZnM for ; Fri, 15 Nov 2013 15:48:20 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1E24711E815B for ; Fri, 15 Nov 2013 15:47:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8608; q=dns/txt; s=iport; t=1384559260; x=1385768860; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=gux71JzKuuapzDBKd4a5d7p9uJIf60Nt2BCjFehuBxo=; b=BFNb0z224TKePdEP4Z5KlYeCseXZl61lcXDnR7L63VKG+NzLMp8oRTOr zDl2xReicLbbDQRNy9ea2Yj+bJoBWeDoTVH8/7Nl8wEsrlzCYK1VNLeaZ 9oG4A21+HuW1XPJHIzZLMX+XM4axTUNlEMPJuu9qQo4qcbKWheTNDI7aw g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAAGyhlKrRDoI/2dsb2JhbABZgwc4v3+BKxZ0giUBAQEDATo/BQcECxEEAQEvTwgGE4d7BQ7BFY4nAQYBAYEGMwcGgxqBEQOJQopsg2KBL5Beg0kbgSwBCBc X-IronPort-AV: E=Sophos;i="4.93,710,1378857600"; d="scan'208";a="95179660" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 15 Nov 2013 23:47:39 +0000 Received: from sjc-vpn5-723.cisco.com (sjc-vpn5-723.cisco.com [10.21.90.211]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAFNlbDQ022212; Fri, 15 Nov 2013 23:47:37 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: <272848605.101032.1384554545269.JavaMail.zimbra@peachymango.org> Date: Fri, 15 Nov 2013 15:47:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <86BB0760-EA4F-4BD5-9A72-CECA949FC0E2@cisco.com> References: <1E854922-D7F6-42ED-A1EF-690F463B2E9F@cisco.com> <272848605.101032.1384554545269.JavaMail.zimbra@peachymango.org> To: Franck Martin X-Mailer: Apple Mail (2.1510) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] SMTP+IPV6 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Nov 2013 23:48:36 -0000 On Nov 15, 2013, at 2:29 PM, Franck Martin = wrote: >=20 > ----- Original Message ----- >> From: "Dan Wing" >> To: apps-discuss@ietf.org >> Cc: "Franck Martin" >> Sent: Friday, November 15, 2013 11:56:56 AM >> Subject: Re: SMTP+IPV6 >>=20 >> Thanks for forwarding a pointer to your new I-D, >> = http://tools.ietf.org/html/draft-martin-smtp-target-host-selection-ipv4-ip= v6-00. >> A few comments: >>=20 >>=20 >> The sender-SMTP server first tries all the IP addresses (IPv4 and >> IPv6) with higher preference (lower number) before the IP addresses >> with lower preference (higher number). The sender-SMTP server = tries >> all the addresses up to a limit before deciding if the message is >> deliverable or not. The sender-SMTP server tries at least two >> addresses in each IP familly it is enabled (2 IPv4 addresses if = IPv4 >> capable and 2 IPv6 addresses if IPv6 capable). >>=20 >> Could that paragraph be edited for greater clarity? I don't = understand the >> interaction between the sender's limited number of addresses it tries = and >> trying at least two addresses in each IP address family. I believe = the >> intent is that, prior to exhausting the limit of addresses it tries, = it >> tries at least two addresses belonging to the 'other' address family. >=20 > yes, do you have text to propose? "The sender-SMTP obtains that list of MX records and sorts them in MX = preference order (highest preference has lowest MX value), as described = in Section 5.1 of [RFC5321]. After sorting, each of these hostnames is = resolved for its IPv6 and IPv4 addresses, and the IPv6 or IPv4 addresses = for that host are sorted following the application configuration, = recognition of an easily reached address, or the operating system's = address selection [RFC6724]. Most sender-SMTP limit the number of IP = addresses that will be tried for each MX record. For each MX record, = the sender-SMTP SHOULD ensure that at least two IP addresses of the = other address family are tried before that limit. For example if a DNS zone might be configured as follows: IN MX 10 mail1 IN MX 20 mail2 mail1 IN A 192.0.2.1 mail1 IN A 192.0.2.2 mail1 IN A 192.0.2.3 mail1 IN A 192.0.2.4 mail1 IN A 192.0.2.5 mail1 IN A 192.0.2.6 mail1 IN AAAA 2001:db8::1 mail1 IN AAAA 2001:db8::2 mail1 IN AAAA 2001:db8::3 mail1 IN AAAA 2001:db8::4 mail1 IN AAAA 2001:db8::5 mail1 IN AAAA 2001:db8::6 mail2 IN A 192.0.2.100 mail2 IN AAAA 2001:db8::100 the sender-SMTP would prefer mail1 (preference 10) and then mail2 = (preference 20). An SMTP-server implementation that does not implementation this = specification and has a 6 address limit per MX record and [RFC6724] default address = preference,=20 would attempt to connect to the 6 IPv6 addresses belonging to mail1. If = the IPv6 path is broken, these connection attempts would all fail (after a timeout), = as would the=20 connection attempt to mail2's IPv6 address. Finally, after those = connection timeouts, the IPv4 address for mail2 would succeed. In contrast, an SMTP-server which is following the normative procedure = above would succeed in connecting to mail1 if the IPv4 path is working but the IPv6 = path is broken. This SMTP-server implementation would attempt to connect to the four = IPv6 addresses=20 belonging to mail1 and then to the IPv4 addresses belonging to mail2 -- = resulting in mail delivery to mail1 (which is preferable for the receiving domain) and faster mail delivery. Following the procedure above with a 6 address limit per MX record and [RFC6724] default address preference, the connections attempted would be: 2001:db8::1 ; mail1, connection attempt 1 2001:db8::2 ; mail1, connection attempt 2 2001:db8::3 ; mail1, connection attempt 3 2001:db8::4 ; mail1, connection attempt 4 192.0.2.1 ; mail1, connection attempt 5 (IPv4) 192.0.2.2 ; mail1, connection attempt 6 (IPv4) ; the other addresses for mail1 are not used by this particular ; sender-SMTP because of its 6 address limit per MX record. 2001:db8::100 ; mail2, connection attempt 1 (IPv6) 192.0.2.100 ; mail2, connection attempt 2 (IPv4) The following paragraph from [RFC5321] remains important for = implementations: If there are multiple destinations with the same preference and there is no clear reason to favor one (e.g., by recognition of an easily reached address), then the sender-SMTP MUST randomize them to spread the load across multiple mail exchangers for a specific organization." >=20 >>=20 >>=20 >> For the same MX RR preference, when there is more than one IP = address >> (IPv4/IPv6) to be tried, the sender-SMTP SHOULD maintain an = internal >> sub preference list based on the rate of successful delivery of >> messages and based on the speed of such delivery. >>=20 >> I'm not too keen on measuring delivery speed. How is delivery speed >> measured? It can be throw off by a sender-SMTP sending a large = message with >> a =46rom address the receiver considers to have a poor reputation = (which >> triggers more thorough spam checking on the receiver-SMTP and may = well delay >> its response to the final dot), whereas that same sender-SMTP might = send a >> short message with a =46rom address the receiver considers to have a = good >> reputation. Is this delivery speed prioritization necessary for = proper >> operation of IPv4/IPv6 selection? I have not been deeply involved in = SMTP >> in years, so perhaps this sort of delivery speed is used by high-end >> sender-SMTPs already and is state-of-the-art, but it seems an = optimization >> that is unnecessary for v4/v6 selection. >>=20 >>=20 > I don't want to suggest any method, just saying that building a sub = preference list based on some criteria (such as) is useful. I'll make it = clearer. Suggest: "(e.g., by recognition of a well-performing address)" > The MTA needs to remember which MX it tried for each message, some MX = never works for some domains, so keeping this info cached, improve = delivery.=20 >=20 >=20 >> If such internal >> sub preference list is not established or cannot be established = then >> the sender-SMTP tries randomly any address within the same >> preference. >>=20 >> This implies the sender-SMTP is prohibited (or discouraged?) from = following >> the OS's configured IP preference table (RFC6724 / RFC3484). I don't = think >> that is desirable or the intent. >>=20 >=20 > Well this could be another criteria to build the sub preference list. = It depends how much statefullness you want to code... >=20 > It seems to me we are moving from the OS IP preference to the = application IP preference, as the application knows better what works = for it than the OS. Decay is important, though. Without decay, an hour-long IPv6 hiccup on = Tuesday will have effects for weeks afterwards. Suggest: "Network paths and servers are constantly breaking and being repaired. = Thus, implementations MUST occasionally age out their IPv6 or IPv4 = preferences. It is RECOMMENDED that this information be aged out every = 4 hours." >=20 >>=20 >> In some ways, this strategy is similar to the Happy >> Eveballs [RFC6555] strategy where web browsers initiate parralel >> connections to web servers using IPv4 and IPv6 and select the >> connection with better response. >>=20 >> The Happy Eyeballs RFC doesn't set up parallel connections. You = might be >> confusing Apple's implementation with the Happy Eyeballs RFC. = Apple's >> implementation does perform parallel connections when it has not yet >> established a history for its network (or if the history has = decayed). >> After Apple's implementation has established some information on v6 = and v4 >> performance for that network, it reduces its aggressiveness and no = longer >> does parallel connections. It does periodically re-check its = assumptions >> because IPv6 or IPv4 performance can improve or degrade over time, = much like >> path MTU can improve or degrade over time. >>=20 >=20 > Yes, mixed up a bit eyeballs with Safari strategy, but the idea = remains the same for both, find which one works best and remember it. Okay. -d From superuser@gmail.com Fri Nov 15 16:59:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4055411E812B for ; Fri, 15 Nov 2013 16:59:56 -0800 (PST) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTTMvQ7avFnc for ; Fri, 15 Nov 2013 16:59:55 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2DE11E8128 for ; Fri, 15 Nov 2013 16:59:55 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id hi5so3156078wib.4 for ; Fri, 15 Nov 2013 16:59:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=GaiDR3xzhHRbuoszF4aXXDIOnB6WQINJBLybW8A5sus=; b=dTwTeFL1b0AnxEIGwyqZ3hu3Ck0VSZaAISdlQD8o/NWyZDI4KX5ajndYn33xqKEN4b yvzxyoj6lOuwHCsv0EsNdNu2OI+qKTMskvPwHKwdkb8dEZk+mZvj8za4uME7spyHi10D 0hupvwmvI1LfDJqnpUxSrksgjUfT9AmKiwpgjbYWSXmKHoo/kyoQGRXtmUyIrjIwypBt kf5JE9q68pAHTYhx1O1M/qsKz+znbviBMBKQBEi/s1I9TIVwx5YR4NiaLaudOL2cCRLn lZHON4LlTOOUTejhKBaMzaFjEt2F1j9E1t9bnU6M+NEcaQliwba1EesvVC0kas/5aLq4 YZ6g== MIME-Version: 1.0 X-Received: by 10.194.121.133 with SMTP id lk5mr1758567wjb.77.1384563594470; Fri, 15 Nov 2013 16:59:54 -0800 (PST) Received: by 10.181.13.230 with HTTP; Fri, 15 Nov 2013 16:59:54 -0800 (PST) In-Reply-To: References: Date: Fri, 15 Nov 2013 16:59:54 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=089e01184e5637a9e704eb40d521 Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-json-merge-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 00:59:56 -0000 --089e01184e5637a9e704eb40d521 Content-Type: text/plain; charset=ISO-8859-1 Colleagues, This WGLC ended more than a month ago with only a single reviewer. There has been no activity since. Could we please get some volunteers to review and comment on it? We really need to get it over to the IESG before we can accept new work; too many WG documents open at once has gotten us into trouble in the past. The other option is to park it indefinitely, but we'd really rather not have to resort to that. Thanks, -MSK On Fri, Oct 4, 2013 at 12:19 PM, Murray S. Kucherawy wrote: > A quick reminder that this Working Group Last Call ends today. So far > there's been one review on this thread, which is hardly enough to be able > to send it to the IESG. Could we please get some more eyes on this and > some substantive review comments? > > -MSK > > > On Tue, Sep 17, 2013 at 12:16 PM, Murray S. Kucherawy > wrote: > >> This note begins Working Group Last Call for >> draft-ietf-appsawg-json-merge-patch, ending October 4, 2013. >> >> Please review the document and post review comments to this list. Please >> indicate in your reply whether you support publication in its current form, >> with your constructive comments accommodated, or if it needs more >> development. A simple "+1" is not especially useful. The more detailed >> your review comments are, the more useful they are. >> >> We also need to see enough of these to be able to say unsarcastically >> that the document has consensus support of the working group. >> >> Thanks, >> >> -MSK, APPSAWG co-chair >> >> > --089e01184e5637a9e704eb40d521 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

This WGLC ended more tha= n a month ago with only a single reviewer.=A0 There has been no activity si= nce.

Could we please get some volunteers to review and comment= on it?=A0 We really need to get it over to the IESG before we can accept n= ew work; too many WG documents open at once has gotten us into trouble in t= he past.=A0 The other option is to park it indefinitely, but we'd reall= y rather not have to resort to that.

Thanks,
-MSK


On Fri, Oct 4, 2013 at 12:19 PM, Murray S. = Kucherawy <superuser@gmail.com> wrote:
A quick reminder that = this Working Group Last Call ends today.=A0 So far there's been one rev= iew on this thread, which is hardly enough to be able to send it to the IES= G.=A0 Could we please get some more eyes on this and some substantive revie= w comments?

-MSK=


On Tue, Sep 17, 2013 at= 12:16 PM, Murray S. Kucherawy <superuser@gmail.com> wrote= :
This no= te begins Working Group Last Call for draft-ietf-appsawg-json-merge-patch, = ending October 4, 2013.

Please review the document and post review comments to this list.= =A0 Please indicate in your reply whether you support publication in its cu= rrent form, with your constructive comments accommodated, or if it needs mo= re development.=A0 A simple "+1" is not especially useful.=A0 The= more detailed your review comments are, the more useful they are.

We also need to see enough of these to be able to say unsarcastic= ally that the document has consensus support of the working group.

<= /div>Thanks,

-MSK, APPSAWG co-chair



--089e01184e5637a9e704eb40d521-- From derhoermi@gmx.net Sat Nov 16 06:56:07 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3E811E8168 for ; Sat, 16 Nov 2013 06:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.832 X-Spam-Level: X-Spam-Status: No, score=-3.832 tagged_above=-999 required=5 tests=[AWL=-1.233, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5XN0nRKvij7 for ; Sat, 16 Nov 2013 06:55:58 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id DF2F611E8118 for ; Sat, 16 Nov 2013 06:55:48 -0800 (PST) Received: from netb ([47.67.181.38]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0MFi1J-1VtZF01f6b-00EgdR for ; Sat, 16 Nov 2013 15:55:47 +0100 From: Bjoern Hoehrmann To: "Murray S. Kucherawy" Date: Sat, 16 Nov 2013 15:55:51 +0100 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:R876MM+7T84VTWTUuVsGkyIERJzjHulVfzqRGhpI33GIm5GsmKY BZwQC0w+pMWmkR9OnNcKfYg4Pes6b7onI/ePcBHLGrf9R1BwoDamvpAEbgKKlrVt6dTay0N 8lfGcK4J3dYozNKLjGUgd/c9m1yS1zo11AaXa71CmYmRUAjwUO3Tjd0i91gK7RswkAGRbOO 0c/Ndmy2OWNEBtdwDYURQ== Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-json-merge-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 14:56:07 -0000 * Murray S. Kucherawy wrote: >This note begins Working Group Last Call for >draft-ietf-appsawg-json-merge-patch, ending October 4, 2013. > >Please review the document and post review comments to this list. In http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-01 the title seems misleading, it just mentions the media type but according to the introduction the document also defines the format. I think emphasis should be given to the format, not some identifier string. In section 1 I found The Merge Patch format generally supports two types of changes: removing and setting JSON object members. JSON arrays are essentially treated the same as JSON primitives: the existing value is replaced, but not partially modified. confusingly worded. Overall I think the introduction does not do a good job explaining how a "Merge Patch" format is different from an ordinary "patch" format. I think RFC 2119 boilerplate does not belong in an Introduction section, it should go into a "Terminology", "Document conventions", "Conformance" or similarily named section. In section 2, the first example has rather inconsistent white space use; white space should be normalised to avoid distracting readers thinking the example might be about white space. I find the references to HTTP PATCH unhelpful, for instance, "When used within an HTTP PATCH request, it is the responsibility of the server receiving and processing the request to inspect the payload entity and determine the specific set of operations that are to be performed to modify the target resource." seems entirely redundant with the semantics of the PATCH method and does not seem to belong in the document. But I don't terribly mind that. Also in section 2, Upon receiving the request, the server is responsible for inspecting the payload and determining, based on it's own understanding of the target resource media type and the underlying data model of the target resource, what specific operations will be applied to modify the resource. This makes it sound like the document does not actually define how the result after applying a "Merge Patch" to a document will look like. I'm not sure that is the intended interpretation. Later in the document I get the impression that the server can only decide whether to accept the request at all. I do not really understand why `null` is handled the way it is, it seems for instance with wholesale replacements where `null` cannot be "delete" it could be fine to use the value e.g. to handle cases where you need to have explicit `null`s. I think having no method to have explicit `null`s is likely hazardous. Including a `charset` parameter for the media type strikes me as very bad idea. In section 3 the field "Applications that use this media type" should identify the class of application that would support the type, not give a list of products ("revision control systems" versus "GNU Patch"), so "None" is never a proper value. I have not looked at the appendices. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From tbray@textuality.com Sat Nov 16 07:57:37 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E9811E8176 for ; Sat, 16 Nov 2013 07:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lP7QeCtFB+fP for ; Sat, 16 Nov 2013 07:57:31 -0800 (PST) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8637D11E8147 for ; Sat, 16 Nov 2013 07:57:25 -0800 (PST) Received: by mail-ve0-f173.google.com with SMTP id c14so3902782vea.32 for ; Sat, 16 Nov 2013 07:57:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gAHeZQxyKpbYV7EEKBKkkZJW/2GXFY8IGTfbCcgyfhA=; b=FhQbO/0lpmkrH0OzFM/PAyNPZLyn4dUV1DeZTgIES5i67Ub6FiAvnOnVAHZDNNGijn nOloCBdoyeryjjocJ+0+9wrj4zUFpXMKLgUx9BXimUxzkl0eK0x4HWCiTo8J8Fkwl8ye yFQXhF+/Sa7QBjL9ootObw8ZzfswTvAZv2+fp22rMnBDqGMsw+jtsuwdSpTDdaluPYBY uaVu0+D+TM+kERznz+46ColI2D4QAsuAKLCteVPPDrlYj0jgnGB4gRVh2Z9tqELuEUn2 e6XfVu2RsfwovJe8lXJAUZXn++5o0GP6twGSoe4sKlHSCeUHqsDcKlNN1KmiHY8kN5n2 9WCg== X-Gm-Message-State: ALoCoQlmVKLtXUbQWXHeEfbKmmnfJoI7jfKmn0oXbYvwLmLKj/uhiKmuJasQSa6al+otAGsgwSSq MIME-Version: 1.0 X-Received: by 10.52.230.102 with SMTP id sx6mr6530361vdc.15.1384617444949; Sat, 16 Nov 2013 07:57:24 -0800 (PST) Received: by 10.220.198.199 with HTTP; Sat, 16 Nov 2013 07:57:24 -0800 (PST) X-Originating-IP: [24.84.235.32] Received: by 10.220.198.199 with HTTP; Sat, 16 Nov 2013 07:57:24 -0800 (PST) In-Reply-To: References: Date: Sat, 16 Nov 2013 07:57:24 -0800 Message-ID: From: Tim Bray To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=089e0111ae34f4df1b04eb4d5e5f Cc: Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-json-merge-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 15:57:37 -0000 --089e0111ae34f4df1b04eb4d5e5f Content-Type: text/plain; charset=UTF-8 I'd worry a little bit that the lack of reaction is a symptom of a general lack of interest. I'm not sure the document should be advanced if nobody cares about it. On Nov 15, 2013 5:00 PM, "Murray S. Kucherawy" wrote: > Colleagues, > > This WGLC ended more than a month ago with only a single reviewer. There > has been no activity since. > > Could we please get some volunteers to review and comment on it? We > really need to get it over to the IESG before we can accept new work; too > many WG documents open at once has gotten us into trouble in the past. The > other option is to park it indefinitely, but we'd really rather not have to > resort to that. > > Thanks, > -MSK > > > > On Fri, Oct 4, 2013 at 12:19 PM, Murray S. Kucherawy wrote: > >> A quick reminder that this Working Group Last Call ends today. So far >> there's been one review on this thread, which is hardly enough to be able >> to send it to the IESG. Could we please get some more eyes on this and >> some substantive review comments? >> >> -MSK >> >> >> On Tue, Sep 17, 2013 at 12:16 PM, Murray S. Kucherawy < >> superuser@gmail.com> wrote: >> >>> This note begins Working Group Last Call for >>> draft-ietf-appsawg-json-merge-patch, ending October 4, 2013. >>> >>> Please review the document and post review comments to this list. >>> Please indicate in your reply whether you support publication in its >>> current form, with your constructive comments accommodated, or if it needs >>> more development. A simple "+1" is not especially useful. The more >>> detailed your review comments are, the more useful they are. >>> >>> We also need to see enough of these to be able to say unsarcastically >>> that the document has consensus support of the working group. >>> >>> Thanks, >>> >>> -MSK, APPSAWG co-chair >>> >>> >> > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --089e0111ae34f4df1b04eb4d5e5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'd worry a little bit that the lack of reaction is a sy= mptom of a general lack of interest. I'm not sure the document should b= e advanced if nobody cares about it.

On Nov 15, 2013 5:00 PM, "Murray S. Kuchera= wy" <superuser@gmail.com= > wrote:
Colleagues,

This WGLC ended more tha= n a month ago with only a single reviewer.=C2=A0 There has been no activity= since.

Could we please get some volunteers to review and comm= ent on it?=C2=A0 We really need to get it over to the IESG before we can ac= cept new work; too many WG documents open at once has gotten us into troubl= e in the past.=C2=A0 The other option is to park it indefinitely, but we= 9;d really rather not have to resort to that.

Thanks,
-MSK


On Fri, Oct 4, 2013 at 12:19 PM, Murray S. = Kucherawy <superuser@gmail.com> wrote:
A quick reminder that = this Working Group Last Call ends today.=C2=A0 So far there's been one = review on this thread, which is hardly enough to be able to send it to the = IESG.=C2=A0 Could we please get some more eyes on this and some substantive= review comments?

-MSK


On Tue, Sep 17, 2013 at 12:16 PM, Murray S. Kucherawy <superuser@gma= il.com> wrote:
This no= te begins Working Group Last Call for draft-ietf-appsawg-json-merge-patch, = ending October 4, 2013.

Please review the document and post review comments to this list.= =C2=A0 Please indicate in your reply whether you support publication in its= current form, with your constructive comments accommodated, or if it needs= more development.=C2=A0 A simple "+1" is not especially useful.= =C2=A0 The more detailed your review comments are, the more useful they are= .

We also need to see enough of these to be able to say unsarcastic= ally that the document has consensus support of the working group.

<= /div>Thanks,

-MSK, APPSAWG co-chair




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

--089e0111ae34f4df1b04eb4d5e5f-- From paul.hoffman@vpnc.org Sat Nov 16 08:24:39 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC5211E81AF for ; Sat, 16 Nov 2013 08:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDI9oHrFhkCz for ; Sat, 16 Nov 2013 08:24:38 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 923AC11E80E7 for ; Sat, 16 Nov 2013 08:24:38 -0800 (PST) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rAGGOafT026282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 16 Nov 2013 09:24:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul Hoffman In-Reply-To: Date: Sat, 16 Nov 2013 08:24:36 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2572F50B-C68E-4745-B2C8-A88BAA03428F@vpnc.org> References: To: IETF Apps Discuss X-Mailer: Apple Mail (2.1822) Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-json-merge-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 16:24:39 -0000 Apologies for the late review. I know I put this on my calendar for a = while ago, but it was lost. This document seems mostly fine. I don't knowingly use HTTP PATCH, so I = cannot say whether or not it works well within that context. =46rom a = strictly JSON point of view, the rules seem sensible other than the = following: Because null values carry specific meaning within a merge patch document, JSON Arrays contained within the merge patch document SHOULD NOT contain null members. Likewise, object members within the array SHOULD NOT contain any members with null values. If null members are contained anywhere within the Array, those MUST be ignored and handled as if the null member were not specified at all. The null values MUST NOT appear within the modified result. For instance, within the merge patch document, the array value ["a", null, "b"] is equivalent to ["a", "b"] and the array value ["a", {"z":1, "y":null},"b"] is equivalent to ["a",{"z":1},"b"]. Those SHOULD NOTs are horrible and will lead to lack of interop for no = good reason. It would be much simpler to say: Because null values carry specific meaning within a merge patch document, JSON Arrays contained within the merge patch document SHOULD NOT contain null members, even within array or object members within the array. This matches the prohibition earlier in the document. Yes, it further = limits what you can patch to, but it certainly also makes it more = reliable. If this change is made to the document, at least one of the = examples needs to be changed as well. --Paul Hoffman= From ned.freed@mrochek.com Sat Nov 16 13:27:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6257611E82FE for ; Sat, 16 Nov 2013 13:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfoODPBKU4Dh for ; Sat, 16 Nov 2013 13:27:17 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 42F1411E82FD for ; Sat, 16 Nov 2013 13:27:17 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P0UTT0E5ZK000QCD@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 16 Nov 2013 13:22:13 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P0USA6030W00004G@mauve.mrochek.com>; Sat, 16 Nov 2013 13:22:07 -0800 (PST) Message-id: <01P0UTSX2FXE00004G@mauve.mrochek.com> Date: Sat, 16 Nov 2013 13:21:28 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sat, 16 Nov 2013 15:55:51 +0100" References: To: Bjoern Hoehrmann Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-json-merge-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 21:27:21 -0000 > * Murray S. Kucherawy wrote: > >This note begins Working Group Last Call for > >draft-ietf-appsawg-json-merge-patch, ending October 4, 2013. > > > >Please review the document and post review comments to this list. > In http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-01 the > title seems misleading, it just mentions the media type but according to > the introduction the document also defines the format. I think emphasis > should be given to the format, not some identifier string. I agree. In this case the media type registration is incidental to the format specification. Ned From ned.freed@mrochek.com Sat Nov 16 19:31:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C219D11E80F9 for ; Sat, 16 Nov 2013 19:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgkBhSxxTk89 for ; Sat, 16 Nov 2013 19:30:59 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7E811E83CB for ; Sat, 16 Nov 2013 19:30:27 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P0V6I7INLC000TL5@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 16 Nov 2013 19:25:21 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P0USA6030W00004G@mauve.mrochek.com>; Sat, 16 Nov 2013 19:25:15 -0800 (PST) Message-id: <01P0V6I4M6IO00004G@mauve.mrochek.com> Date: Sat, 16 Nov 2013 19:09:55 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Fri, 15 Nov 2013 11:56:56 -0800" <1E854922-D7F6-42ED-A1EF-690F463B2E9F@cisco.com> References: <1E854922-D7F6-42ED-A1EF-690F463B2E9F@cisco.com> To: Dan Wing Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] SMTP+IPV6 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 03:31:03 -0000 > Thanks for forwarding a pointer to your new I-D, > http://tools.ietf.org/html/draft-martin- smtp-target-host-selection-ipv4-ipv6-00. A few comments: > The sender-SMTP server first tries all the IP addresses (IPv4 and > IPv6) with higher preference (lower number) before the IP addresses > with lower preference (higher number). The sender-SMTP server tries > all the addresses up to a limit before deciding if the message is > deliverable or not. The sender-SMTP server tries at least two > addresses in each IP familly it is enabled (2 IPv4 addresses if IPv4 > capable and 2 IPv6 addresses if IPv6 capable). > Could that paragraph be edited for greater clarity? I don't understand the > interaction between the sender's limited number of addresses it tries and > trying at least two addresses in each IP address family. I believe the intent > is that, prior to exhausting the limit of addresses it tries, it tries at least > two addresses belonging to the 'other' address family. It should also be stated explicitly that clever tricks like trying multiple addresses at once may not be such a swell idea in the case of SMTP. This sort of thing increases the liklihood of running afoul of server-side restrictions. > For the same MX RR preference, when there is more than one IP address > (IPv4/IPv6) to be tried, the sender-SMTP SHOULD maintain an internal > sub preference list based on the rate of successful delivery of > messages and based on the speed of such delivery. > I'm not too keen on measuring delivery speed. How is delivery speed > measured? It can be throw off by a sender-SMTP sending a large message with a > From address the receiver considers to have a poor reputation (which triggers > more thorough spam checking on the receiver-SMTP and may well delay its > response to the final dot), whereas that same sender-SMTP might send a short > message with a From address the receiver considers to have a good reputation. > Is this delivery speed prioritization necessary for proper operation of > IPv4/IPv6 selection? I have not been deeply involved in SMTP in years, so > perhaps this sort of delivery speed is used by high-end sender-SMTPs already > and is state-of-the-art, but it seems an optimization that is unnecessary for > v4/v6 selection. I most emphatically agree. This is basically asking people to implement things in ways that sooner or later will have a bad interaction with something out there, leading to problems that are very difficult to track down. Keeping track of which addresses work and which don't is fine and should be encouraged, tracking speed is not. > If such internal > sub preference list is not established or cannot be established then > the sender-SMTP tries randomly any address within the same > preference. > This implies the sender-SMTP is prohibited (or discouraged?) from following > the OS's configured IP preference table (RFC6724 / RFC3484). I don't think > that is desirable or the intent. I don't think that was the intent, but then again, I'm a little unclear on how RFC 6724 is supposed to interact with application selection of what address to use. Ned From Walter.H@mathemainzel.info Sun Nov 17 10:58:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3047A11E90AF for ; Sun, 17 Nov 2013 10:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcsG2Dtn1-as for ; Sun, 17 Nov 2013 10:58:03 -0800 (PST) Received: from mx26lb.world4you.com (mx26lb.world4you.com [IPv6:2a00:1a68:1:101::1b1b:26]) by ietfa.amsl.com (Postfix) with ESMTP id E1EEA11E90BA for ; Sun, 17 Nov 2013 10:58:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mathemainzel.info; s=dkim11; h=Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=U6kSKEKT3aoUQDQbXWYcVjXVnVs/pxoE41EXo/E3zJI=; b=WVfkfJKPqv2FtRSOGZcObvspAsz8gpZgz+8QXIDP1C6JbPSOwT1S3Idg/sh37c+OOyCyhJT+0OfuL6De23dEPgYJrJyplMoLgLKr6+eL85t5ne0wNwaJ5+Sjzqum7n4HT1Igs/o8ZOp+6kjuy5YhiRfIB2CVAsrFlPy13RcLdOI=; Received: from [86.56.130.134] (helo=cm56-130-134.liwest.at) by mx26lb.world4you.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Vi7Wv-00086M-5C for apps-discuss@ietf.org; Sun, 17 Nov 2013 19:57:09 +0100 Received: from [mailsrvr] by outgoing.mail (mail delivery) Received: from [mailclnt] by [mailsrvr] Message-ID: <52891184.6080707@mathemainzel.info> Date: Sun, 17 Nov 2013 19:57:08 +0100 From: "Walter H." Organization: Home X-Mailer: Mozilla/5.0 (UNIX; U; Cray X-MP/48; en-US; rv:2.70) Gecko/20110929 Communicator/7.20 MIME-Version: 1.0 To: IETF Apps Discuss Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060200060800020806020301" X-SA-Do-Not-Run: Yes X-AV-Do-Run: Yes X-SA-Exim-Connect-IP: 86.56.130.134 X-SA-Exim-Mail-From: Walter.H@mathemainzel.info X-SA-Exim-Scanned: No (on mx26lb.world4you.com); SAEximRunCond expanded to false Subject: [apps-discuss] Add-on for HTTPS websites X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 18:58:04 -0000 This is a cryptographically signed message in MIME format. --------------ms060200060800020806020301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable You may be interested by the following documents: A new version of I-D, draft-hoehlhubmer-https-addon-03.txt has been successfully submitted by Walter Hoehlhubmer and posted to the IETF repository. Filename: draft-hoehlhubmer-https-addon Revision: 03 Title: Informational Add-on for HTTP over the Secure Sockets Layer (SSL) = Protocol and/or the Transport Layer Security (TLS) Protocol Creation date: 2013-11-17 Group: Individual Submission Number of pages: 24 URL:=20 http://www.ietf.org/internet-drafts/draft-hoehlhubmer-https-addon-03.txt Status: http://datatracker.ietf.org/doc/draft-hoehlhubmer-https-addon Htmlized: http://tools.ietf.org/html/draft-hoehlhubmer-https-addon-03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-hoehlhubmer-https-addon-03= Abstract: This document describes an Add-on for websites providing encrypted connectivity (HTTP over TLS). The Add-on has two parts, one for the Domain Name System (DNS) - storing the X.509 certificate hashes - and one for the webserver itself - an additional webpage providing specific informations. --=20 Best regards, Walter H=F6hlhubmer --------------ms060200060800020806020301 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIS7jCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGVzCCBT+gAwIBAgIDB7IRMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTMwOTI4MTMyODMy WhcNMTQwOTI5MTAwMjI5WjBrMRkwFwYDVQQNExBWbVJDM2RlMnhkY2xkV2UzMSMwIQYDVQQD DBp3YWx0ZXIuaEBtYXRoZW1haW56ZWwuaW5mbzEpMCcGCSqGSIb3DQEJARYad2FsdGVyLmhA bWF0aGVtYWluemVsLmluZm8wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsecjS QVmgix4Jxz2iGhLz6MGEX2UmmwNmIx36iqhbQ5fu+kWjaUnZY8WIyIA0D1eYMUcFeLFyR06J 5LL7r47QdWWjDkcmrT4JzSMflRGOhgheEE8wBIXi6D7bGo9ySCLG7iRbFoxZHzj9yO3kGq38 Afos9rtncxM3rq9jVf5e7bzJ6rIZl/GLCBexQRuZoUZKBtG7rqfLutRIyd/VljnhRPGg31P/ 3FmuDoMiUtTjYw7HdV+bWDUDV5ZYs9gCZzTlqIfaFojIA8zugFOK24izwFHpz/Q7jAQ06gqB EpEUp2Oyr7ohvMBNoVlTqZp8Rrtbxb84xtnqPtxT0p6/RuNtAgMBAAGjggLgMIIC3DAJBgNV HRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYD VR0OBBYEFF3MzuxEgHE/Le6u4xhuQmO8VdTxMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1 TvLUuFGCMCUGA1UdEQQeMByBGndhbHRlci5oQG1hdGhlbWFpbnplbC5pbmZvMIIBTAYDVR0g BIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1 ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRl ZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlv bnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNy bC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0 c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5z dGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqG GGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAIzkTeK+tB22s UiCTtoV48QrIcROVvRygTVQMHRihhuNJbnQuAh7bnUB+hyG2mM9PZY+9YxxAdSkqclJ9TJLm k+C8cuIEC8GUi6UFaAkkjlKiaqfkpAD96FTCuUetMLzViDSkpuDQzR9DkX/UamM3qX6fT8jG gDs9XiGXT1E82sbB+4gtnqH1cp1Ci3sMurw3H5q5MUXg1gdyt59JoNuHDsvLZFAHRFuTpcz8 gXkT9J8N9cUvkzd1XgEbmzldQgQZrrrngKG8SGGfUQozwfUIk83LFhIOr9kyzcnKAQTelFqZ zDLbJrn/arofs5ziNVv2oKbdpbrWXgNA5ZiP5uAMZzCCBlcwggU/oAMCAQICAweyETANBgkq hkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEzMDky ODEzMjgzMloXDTE0MDkyOTEwMDIyOVowazEZMBcGA1UEDRMQVm1SQzNkZTJ4ZGNsZFdlMzEj MCEGA1UEAwwad2FsdGVyLmhAbWF0aGVtYWluemVsLmluZm8xKTAnBgkqhkiG9w0BCQEWGndh bHRlci5oQG1hdGhlbWFpbnplbC5pbmZvMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEArHnI0kFZoIseCcc9ohoS8+jBhF9lJpsDZiMd+oqoW0OX7vpFo2lJ2WPFiMiANA9XmDFH BXixckdOieSy+6+O0HVlow5HJq0+Cc0jH5URjoYIXhBPMASF4ug+2xqPckgixu4kWxaMWR84 /cjt5Bqt/AH6LPa7Z3MTN66vY1X+Xu28yeqyGZfxiwgXsUEbmaFGSgbRu66ny7rUSMnf1ZY5 4UTxoN9T/9xZrg6DIlLU42MOx3Vfm1g1A1eWWLPYAmc05aiH2haIyAPM7oBTituIs8BR6c/0 O4wENOoKgRKRFKdjsq+6IbzATaFZU6mafEa7W8W/OMbZ6j7cU9Kev0bjbQIDAQABo4IC4DCC AtwwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMB0GA1UdDgQWBBRdzM7sRIBxPy3uruMYbkJjvFXU8TAfBgNVHSMEGDAWgBRTcu2SnODa ywFcfH6WNU7y1LhRgjAlBgNVHREEHjAcgRp3YWx0ZXIuaEBtYXRoZW1haW56ZWwuaW5mbzCC AUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFy dENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3 YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVt ZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUg aW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9i bGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBACM5 E3ivrQdtrFIgk7aFePEKyHETlb0coE1UDB0YoYbjSW50LgIe251AfochtpjPT2WPvWMcQHUp KnJSfUyS5pPgvHLiBAvBlIulBWgJJI5Somqn5KQA/ehUwrlHrTC81Yg0pKbg0M0fQ5F/1Gpj N6l+n0/IxoA7PV4hl09RPNrGwfuILZ6h9XKdQot7DLq8Nx+auTFF4NYHcrefSaDbhw7Ly2RQ B0Rbk6XM/IF5E/SfDfXFL5M3dV4BG5s5XUIEGa6654ChvEhhn1EKM8H1CJPNyxYSDq/ZMs3J ygEE3pRamcwy2ya5/2q6H7Oc4jVb9qCm3aW61l4DQOWYj+bgDGcxggPQMIIDzAIBATCBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMHshEwCQYFKw4DAhoFAKCCAhAw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMTE3MTg1NzA4 WjAjBgkqhkiG9w0BCQQxFgQUaMZ20E/rqGxI78tq7SYAK721VnAwXwYJKoZIhvcNAQkPMVIw UDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDB7IRMIGnBgsqhkiG9w0BCRACCzGBl6CB lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMHshEwDQYJKoZIhvcNAQEB BQAEggEALGbnAzuVUh03+IkU+5eRquKyY7nJ48zjqjtfoMOy+tlREnB8M10+Zj4TwOpID7gc VI3plZMAkOQjorQgEWeG8OwPprHreStK8KVzE6QKnxzI1bRp007UaCKbxSMPHGud4LC7Ho1x AmZEnkJLakqFk1iuUzvGRW5Fqud3TxKW2OMJd6/Hn/hNgR4z+jXVFmlIrSYnRbRN7OVCgtBA jEXSrVmSPrQp88+UEI659H7GNjMuxt6s3ov7/MndgbL3/DYM6uOtYUIpGL39EhBnKm1QcUNY oRHOKxOtYVP8ERrelVKLg3kUdsdXb+fapI63oPmAPpbxY2P/4htTJwGZ+eMofAAAAAAAAA== --------------ms060200060800020806020301-- From walter.h@mathemainzel.info Sun Nov 17 22:02:05 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC2411E82DE for ; Sun, 17 Nov 2013 22:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[AWL=-1.348, BAYES_00=-2.599, FORGED_MUA_MOZILLA=2.696, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2GCufkMClPw for ; Sun, 17 Nov 2013 22:02:04 -0800 (PST) Received: from mx28lb.world4you.com (mx28lb.world4you.com [IPv6:2a00:1a68:1:101::1b1b:28]) by ietfa.amsl.com (Postfix) with ESMTP id 76C3111E80EC for ; Sun, 17 Nov 2013 22:02:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mathemainzel.info; s=dkim11; h=Content-Transfer-Encoding:Content-Type:MIME-Version:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=NpfSsk69kJerec+IuCbo5qmREsQJbP3pjStz8YbdbvQ=; b=IKK4ziIBSZEc76AAx/8h8aA/Gi/E9eO0nhbDGj4jvyLG8u5gpcolpAH34ltoNBuYP6SdhDfVMm5xNt+IGAUIPQ6f7Y3X70xaP9VdZ+CuwwHZUWUVoov2kWsGQK2Cx0LNFqSbKGeu2rFLMJi1zU39b1XP5McT0Xh6KAFNxyRR/YU=; Received: from [86.56.130.134] (helo=cm56-130-134.liwest.at) by mx28lb.world4you.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1ViHuL-0002Gy-Dq for apps-discuss@ietf.org; Mon, 18 Nov 2013 07:02:01 +0100 Received: from [mailsrvr] by outgoing.mail (mail delivery) Received: from [mailclnt] by [mailsrvr] Message-ID: <37f8fec05d4d1acc999ab77a925c88e0.1384754521@squirrel.mail> In-Reply-To: <52891184.6080707@mathemainzel.info> References: <52891184.6080707@mathemainzel.info> Date: Mon, 18 Nov 2013 07:02:01 +0100 From: "Walter H." To: "IETF Apps Discuss" X-Mailer: Mozilla/5.0 (UNIX; U; Cray X-MP/48; en-US; rv:2.70) Gecko/20110929 Communicator/7.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-SA-Do-Not-Run: Yes X-AV-Do-Run: Yes X-SA-Exim-Connect-IP: 86.56.130.134 X-SA-Exim-Mail-From: walter.h@mathemainzel.info X-SA-Exim-Scanned: No (on mx28lb.world4you.com); SAEximRunCond expanded to false Subject: Re: [apps-discuss] Add-on for HTTPS websites X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 06:02:05 -0000 Bug corrected, the example certificates were wrong. Filename: draft-hoehlhubmer-https-addon Revision: 04 Title: Informational Add-on for HTTP over the Secure Sockets Layer (SSL) Protocol and/or the Transport Layer Security (TLS) Protocol Creation date: 2013-11-17 Group: Individual Submission Number of pages: 24 URL: http://www.ietf.org/internet-drafts/draft-hoehlhubmer-https-addon-04.txt Status: http://datatracker.ietf.org/doc/draft-hoehlhubmer-https-addon Htmlized: http://tools.ietf.org/html/draft-hoehlhubmer-https-addon-04 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-hoehlhubmer-https-addon-04 On Sun, November 17, 2013 19:57, Walter H. wrote: > You may be interested by the following documents: > > A new version of I-D, draft-hoehlhubmer-https-addon-03.txt > has been successfully submitted by Walter Hoehlhubmer and posted to the > IETF repository. > > Filename: draft-hoehlhubmer-https-addon > Revision: 03 > Title: Informational Add-on for HTTP over the Secure Sockets Layer (SSL= ) > Protocol and/or the Transport Layer Security (TLS) Protocol > Creation date: 2013-11-17 > Group: Individual Submission > Number of pages: 24 > URL: > http://www.ietf.org/internet-drafts/draft-hoehlhubmer-https-addon-03.tx= t > Status: http://datatracker.ietf.org/doc/draft-hoehlhubmer-https-addon > Htmlized: http://tools.ietf.org/html/draft-hoehlhubmer-https-addon-03 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-hoehlhubmer-https-addon-= 03 > > Abstract: > This document describes an Add-on for websites providing encrypted > connectivity (HTTP over TLS). > > The Add-on has two parts, one for the Domain Name System (DNS) - > storing the X.509 certificate hashes - and one for the webserver > itself - an additional webpage providing specific informations. > > -- > Best regards, > Walter H=F6hlhubmer > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From superuser@gmail.com Sun Nov 17 22:29:06 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FE011E814F for ; Sun, 17 Nov 2013 22:29:06 -0800 (PST) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbOyOX-CUpuv for ; Sun, 17 Nov 2013 22:29:06 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id EE36811E80EC for ; Sun, 17 Nov 2013 22:29:05 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id f4so3339367wiw.2 for ; Sun, 17 Nov 2013 22:29:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r36kvIjpZzIvV2Hsi3EA9kEATOfsDD03hFITDzYNUXU=; b=xix1Jq/FOZ/yLTes2jvKr9W4g77nrtXqpbPo5lYzj77lrkpnnBlH3ed8+cyxOaRQme 9NFH2IzzoigVwndmIBdFv4YlvCcIT4vTGGU/kKIz+0T6MIlsNcOHMDPPvOZkVPo3ZJXD ikISBvWxKIhP6RtTdLHfER4w7JTplirFw2QxLBRI5O71wbdGAwqP0L0HWr6P37V4LlMU 1bqf3wxWK9PJAVqO3a/4z6xilQea2jxq2Dyv/yelBOfTsh528BDu6vbQkJTgeoO0peJ0 TBxdwuJgRZ9f7tjCq7KdRwIzZHcKHgz7TxPfu3V1BbMnraEiEFRyX7PpfEPbJf4b0ILq IRnQ== MIME-Version: 1.0 X-Received: by 10.180.79.230 with SMTP id m6mr15675637wix.19.1384756145062; Sun, 17 Nov 2013 22:29:05 -0800 (PST) Received: by 10.181.13.230 with HTTP; Sun, 17 Nov 2013 22:29:05 -0800 (PST) In-Reply-To: References: Date: Sun, 17 Nov 2013 22:29:05 -0800 Message-ID: From: "Murray S. Kucherawy" To: Tim Bray Content-Type: multipart/alternative; boundary=f46d0444037820877604eb6daa64 Cc: Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-json-merge-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 06:29:06 -0000 --f46d0444037820877604eb6daa64 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Nov 16, 2013 at 7:57 AM, Tim Bray wrote: > I'd worry a little bit that the lack of reaction is a symptom of a general > lack of interest. I'm not sure the document should be advanced if nobody > cares about it. > Right, if it stays parked for a protracted period, we would probably just mark it "Dead" (from a WG perspective). -MSK --f46d0444037820877604eb6daa64 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Nov 16, 2013 at 7:57 AM, Tim Bray <tbray@textu= ality.com> wrote:

I'd worry a little bit th= at the lack of reaction is a symptom of a general lack of interest. I'm= not sure the document should be advanced if nobody cares about it.


Right, if it stays parked for a protracted= period, we would probably just mark it "Dead" (from a WG perspec= tive).

-MSK
--f46d0444037820877604eb6daa64-- From jasnell@gmail.com Sun Nov 17 22:41:31 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94EE11E839D for ; Sun, 17 Nov 2013 22:41:30 -0800 (PST) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1j1ndRQ14eca for ; Sun, 17 Nov 2013 22:41:28 -0800 (PST) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5CF11E84A3 for ; Sun, 17 Nov 2013 22:41:23 -0800 (PST) Received: by mail-ob0-f174.google.com with SMTP id wn1so156368obc.5 for ; Sun, 17 Nov 2013 22:41:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bXVIqZa+bet68aTkHDMktiqWFScmazFseWEHogFtyNg=; b=ffy4Np1up+uJOWu4tewk0PkeEqfq8EL16XEmlULR2CPN8ue8f1bL1GcO/mbJ4sGL3P e1xc74rFv6AoA4RuQtpvKo7FYDEuONNQbtgEjcvgVV4hikxXla+U1W63uTKL1fnNkG5b 0QNRvA6g1E9IhhEB4uq0JvCjSj1DxO/6NmoZbZQzSmHjhauAvgRpT0nQ5Tz76U7lBtcG DqqZSNM34koOGi71ddj+xtqWkV/pnubFvkTm/vnI4ss8FXPumi60+OFki59TeDCuOEWr kl6xUqUUG6xZDFPiC8Q11O2xmpmyNdDNvyQK0jhlh0uFruOXO3Jzo2sMTl88MXpEKWAy oyYA== MIME-Version: 1.0 X-Received: by 10.60.146.210 with SMTP id te18mr18682576oeb.20.1384756882985; Sun, 17 Nov 2013 22:41:22 -0800 (PST) Received: by 10.60.124.137 with HTTP; Sun, 17 Nov 2013 22:41:22 -0800 (PST) Received: by 10.60.124.137 with HTTP; Sun, 17 Nov 2013 22:41:22 -0800 (PST) In-Reply-To: References: Date: Sun, 17 Nov 2013 22:41:22 -0800 Message-ID: From: James M Snell To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=047d7b5d42f81c58b704eb6dd600 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-json-merge-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 06:41:31 -0000 --047d7b5d42f81c58b704eb6dd600 Content-Type: text/plain; charset=UTF-8 There are existing implementers of the current spec. If the wg doesn't move it forward, I'll resubmit as an independent submission. On Nov 17, 2013 10:29 PM, "Murray S. Kucherawy" wrote: > On Sat, Nov 16, 2013 at 7:57 AM, Tim Bray wrote: > >> I'd worry a little bit that the lack of reaction is a symptom of a >> general lack of interest. I'm not sure the document should be advanced if >> nobody cares about it. >> > > Right, if it stays parked for a protracted period, we would probably just > mark it "Dead" (from a WG perspective). > > -MSK > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --047d7b5d42f81c58b704eb6dd600 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

There are existing implementers of the current spec.=C2=A0 I= f the wg doesn't move it forward,=C2=A0 I'll resubmit as an indepen= dent submission.=C2=A0

On Nov 17, 2013 10:29 PM, "Murray S. Kucher= awy" <superuser@gmail.com> wrote:
On Sat, Nov 16, 2013 at 7:57 AM, Tim Bray <tbray@textu= ality.com> wrote:

I'd worry a little bit th= at the lack of reaction is a symptom of a general lack of interest. I'm= not sure the document should be advanced if nobody cares about it.


Right, if it stays parked for a protracted= period, we would probably just mark it "Dead" (from a WG perspec= tive).

-MSK

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

--047d7b5d42f81c58b704eb6dd600-- From walter.h@mathemainzel.info Mon Nov 18 00:41:13 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9181B11E81FB for ; Mon, 18 Nov 2013 00:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.576 X-Spam-Level: X-Spam-Status: No, score=-0.576 tagged_above=-999 required=5 tests=[AWL=-0.674, BAYES_00=-2.599, FORGED_MUA_MOZILLA=2.696, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOaJBAZnkDhE for ; Mon, 18 Nov 2013 00:41:13 -0800 (PST) Received: from mx26lb.world4you.com (mx26lb.world4you.com [IPv6:2a00:1a68:1:101::1b1b:26]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0AE11E820E for ; Mon, 18 Nov 2013 00:41:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mathemainzel.info; s=dkim11; h=Content-Transfer-Encoding:Content-Type:MIME-Version:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=0dSbGn1SoFKChGPEsaL3o78niybNwjxhs1SgovwHLkw=; b=pc6CxhiVYwluXN3Bpe6U7RIMsSdSUt2FrTlnDr07B1TM03YXbgFcnxJZDrg4YxvZX+L2WMCJ3hze+Tkcp22dDp2Fmmt7P5nYv5tCtpnRjxvZNjNUoonShveETD2CX6ndHlVVnPUv1/F25jZofQ2jpcNDLNzvINn1J+FMxFyuWwo=; Received: from [86.56.130.134] (helo=cm56-130-134.liwest.at) by mx26lb.world4you.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1ViKOD-0003Ks-8x for apps-discuss@ietf.org; Mon, 18 Nov 2013 09:41:01 +0100 Received: from [mailsrvr] by outgoing.mail (mail delivery) Received: from [mailclnt] by [mailsrvr] Message-ID: <3fccadbb93d588da1c37e11e5734c95b.1384764060@squirrel.mail> In-Reply-To: <37f8fec05d4d1acc999ab77a925c88e0.1384754521@squirrel.mail> References: <52891184.6080707@mathemainzel.info> <37f8fec05d4d1acc999ab77a925c88e0.1384754521@squirrel.mail> Date: Mon, 18 Nov 2013 09:41:00 +0100 From: "Walter H." To: "IETF Apps Discuss" X-Mailer: Mozilla/5.0 (UNIX; U; Cray X-MP/48; en-US; rv:2.70) Gecko/20110929 Communicator/7.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-SA-Do-Not-Run: Yes X-AV-Do-Run: Yes X-SA-Exim-Connect-IP: 86.56.130.134 X-SA-Exim-Mail-From: walter.h@mathemainzel.info X-SA-Exim-Scanned: No (on mx26lb.world4you.com); SAEximRunCond expanded to false Subject: Re: [apps-discuss] Add-on for HTTPS websites X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 08:41:13 -0000 Minor formatting done, Byte Mixup corrected. Filename: draft-hoehlhubmer-https-addon Revision: 05 Title: Informational Add-on for HTTP over the Secure Sockets Layer (SSL) Protocol and/or the Transport Layer Security (TLS) Protocol Creation date: 2013-11-17 Group: Individual Submission Number of pages: 24 URL: http://www.ietf.org/internet-drafts/draft-hoehlhubmer-https-addon-05.txt Status: http://datatracker.ietf.org/doc/draft-hoehlhubmer-https-addon Htmlized: http://tools.ietf.org/html/draft-hoehlhubmer-https-addon-05 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-hoehlhubmer-https-addon-05 On Mon, November 18, 2013 07:02, Walter H. wrote: > > Bug corrected, the example certificates were wrong. > > Filename: draft-hoehlhubmer-https-addon > Revision: 04 > Title: Informational Add-on for HTTP over the Secure > Sockets Layer (SSL) Protocol > and/or the Transport Layer Security (TLS) Protocol > Creation date: 2013-11-17 > Group: Individual Submission > Number of pages: 24 > URL: > http://www.ietf.org/internet-drafts/draft-hoehlhubmer-https-addon-04.tx= t > Status: http://datatracker.ietf.org/doc/draft-hoehlhubmer-https-addon > Htmlized: http://tools.ietf.org/html/draft-hoehlhubmer-https-addon-04 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-hoehlhubmer-https-addon-= 04 > > > On Sun, November 17, 2013 19:57, Walter H. wrote: >> You may be interested by the following documents: >> >> A new version of I-D, draft-hoehlhubmer-https-addon-03.txt >> has been successfully submitted by Walter Hoehlhubmer and posted to th= e >> IETF repository. >> >> Filename: draft-hoehlhubmer-https-addon >> Revision: 03 >> Title: Informational Add-on for HTTP over the Secure Sockets Layer (SS= L) >> Protocol and/or the Transport Layer Security (TLS) Protocol >> Creation date: 2013-11-17 >> Group: Individual Submission >> Number of pages: 24 >> URL: >> http://www.ietf.org/internet-drafts/draft-hoehlhubmer-https-addon-03.t= xt >> Status: http://datatracker.ietf.org/doc/draft-hoehlhubmer-https-addon >> Htmlized: http://tools.ietf.org/html/draft-hoehlhubmer-https-addon-03 >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-hoehlhubmer-https-addon= -03 >> >> Abstract: >> This document describes an Add-on for websites providing encrypted >> connectivity (HTTP over TLS). >> >> The Add-on has two parts, one for the Domain Name System (DNS) - >> storing the X.509 certificate hashes - and one for the webserver >> itself - an additional webpage providing specific informations. >> >> -- >> Best regards, >> Walter H=F6hlhubmer From dave@cridland.net Mon Nov 18 00:43:00 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD1411E8162 for ; Mon, 18 Nov 2013 00:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nB2-kid4zjRU for ; Mon, 18 Nov 2013 00:43:00 -0800 (PST) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 265A411E80FA for ; Mon, 18 Nov 2013 00:43:00 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id vb8so6575173obc.39 for ; Mon, 18 Nov 2013 00:42:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Fc1vKjx8ji8mDJTuxUu+w2N6Ams9NkOoBNIpG6qvgXw=; b=f5lGuU6wVZMH/3hdrIzKkCzhD/siZ9twF3fHqik9mBf52e3G7yHZi4joE2liHC8eMC xtS3mYPFhOZf+CNmc81FUIzbsPNrZBCxWKGZBAmRNKG0jnyXjuunMgnaxhVzET1zlPnB oCtbVG0JURLqhQzjt4JV8AsyNw2hHTkKrL210= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Fc1vKjx8ji8mDJTuxUu+w2N6Ams9NkOoBNIpG6qvgXw=; b=Iv6s6Gt84c3CRL9rRrLygmmut3Zuo8zMCn8FNUAsnRVQvzoClZnVRdS45+Pas+2q4h d2zptdabyvf401uoYwPdlrdU4Po4AZj5wzRKP0THcoMpR2omAHv8UVshakuF6RmDscLB z97mwINVTyQJ+Du2+4uSXQMB3tIOGAk+teXDsM/2WokOohnhFiOZx/VPzNPtIQZD0Kbf 4/s7A0t3wtrwvSbvgn4zdo4qmuYxOsk2yVxhZNt5L5Kq3OI8s/1QXAOcwZVawu1G+ENB KHFHRITXPsQblTtyqTPsbv1tM0xJ34LfSycuaBS4w2/HdcMIKN/Ig7628N14zWVTRyXQ PeDQ== X-Gm-Message-State: ALoCoQnYNldcxte9heYwrKMSMfLPjhCZ9wmb2KD6yQdlJPPpyjuWe5S+BZrz7vkfM6szntEs1XWA MIME-Version: 1.0 X-Received: by 10.60.62.172 with SMTP id z12mr19097926oer.4.1384764179562; Mon, 18 Nov 2013 00:42:59 -0800 (PST) Received: by 10.60.121.97 with HTTP; Mon, 18 Nov 2013 00:42:59 -0800 (PST) In-Reply-To: <37f8fec05d4d1acc999ab77a925c88e0.1384754521@squirrel.mail> References: <52891184.6080707@mathemainzel.info> <37f8fec05d4d1acc999ab77a925c88e0.1384754521@squirrel.mail> Date: Mon, 18 Nov 2013 08:42:59 +0000 Message-ID: From: Dave Cridland To: "Walter H." Content-Type: multipart/alternative; boundary=001a11c2097605543a04eb6f893e Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Add-on for HTTPS websites X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 08:43:01 -0000 --001a11c2097605543a04eb6f893e Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 18, 2013 at 6:02 AM, Walter H. wrote: > > Bug corrected, the example certificates were wrong. > > Filename: draft-hoehlhubmer-https-addon > Revision: 04 > > I've skimmed this quickly, and what I think you've done here is reinvent DANE, which is specified in RFC 6698. I don't *think* you're adding anything new, here, but I do think it's always interesting when someone independently arrives at roughly the same concept. I'd encourage you to read through RFC 6698, and see if there's any differences between your approaches that should be addressed. I'd suggest you probably don't want to invest too much more time in your own approach, though. Dave. --001a11c2097605543a04eb6f893e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Nov 18, 2013 at 6:02 AM, Walter H. <walter.h@math= emainzel.info> wrote:

Bug corrected, the example certificates were wrong.

Filename: draft-hoehlhubmer-https-addon
Revision: 04


I've skimm= ed this quickly, and what I think you've done here is reinvent DANE, wh= ich is specified in RFC 6698.

I don't *think* = you're adding anything new, here, but I do think it's always intere= sting when someone independently arrives at roughly the same concept. I'= ;d encourage you to read through RFC 6698, and see if there's any diffe= rences between your approaches that should be addressed.

I'd suggest you probably don't want to invest t= oo much more time in your own approach, though.

Da= ve.
--001a11c2097605543a04eb6f893e-- From julian.reschke@gmx.de Mon Nov 18 00:45:28 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD9A11E8146 for ; Mon, 18 Nov 2013 00:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.516 X-Spam-Level: X-Spam-Status: No, score=-106.516 tagged_above=-999 required=5 tests=[AWL=-3.917, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCWDNkt2zGrD for ; Mon, 18 Nov 2013 00:45:22 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 596F511E80FA for ; Mon, 18 Nov 2013 00:45:22 -0800 (PST) Received: from [192.168.2.117] ([84.187.34.72]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M5tU1-1VSRGB3lc1-00xtWt for ; Mon, 18 Nov 2013 09:45:20 +0100 Message-ID: <5289D398.7020504@gmx.de> Date: Mon, 18 Nov 2013 09:45:12 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: James M Snell , "Murray S. Kucherawy" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:AfNcjH60zXuEXU6bli1zXgRrA+HUzgfzu3/9n3O92DEJjTCJsPW BQ9TmOfqbJcbUB4cCFsu9Mgfkv78EGW5FQMY+oqR98XEEbRDax3Ual3tAbR+Xac3TOQ00th jsnAJWfCH1oRYS3Hrz+J5JilXAs01Y2/q0iSRy2nssD8DmngeD0t+Z3DooS+btbgeeswyjL 5bXJZOziGtdMo70c27CFg== Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-json-merge-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 08:45:28 -0000 On 2013-11-18 07:41, James M Snell wrote: > There are existing implementers of the current spec. If the wg doesn't > move it forward, I'll resubmit as an independent submission. This spec is needed. I don't care particularly whether it'll be a WG draft or an independent submission. Best regards, Julian From walter.h@mathemainzel.info Mon Nov 18 01:09:09 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A6911E81B8 for ; Mon, 18 Nov 2013 01:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.351 X-Spam-Level: X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5 tests=[AWL=-0.449, BAYES_00=-2.599, FORGED_MUA_MOZILLA=2.696, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3s7gL4M5y2q for ; Mon, 18 Nov 2013 01:09:08 -0800 (PST) Received: from mx25lb.world4you.com (mx25lb.world4you.com [IPv6:2a00:1a68:1:101::1b1b:25]) by ietfa.amsl.com (Postfix) with ESMTP id 20A8D11E819D for ; Mon, 18 Nov 2013 01:09:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mathemainzel.info; s=dkim11; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=Nh4aiSu7HQdnkzUk+e44gz8LeC8iSn/NHpu6bvaPfg8=; b=iQ0PVIXd2bZzZ6fxYam4X80teu0dfKL0hFplAnYXdvCo29Wi4WRGnGDHzNsLOCKqeSNcDjeoT60ZrsyWzgAUawTH2plCb+UZ0RaLE8zOR1npY62xz5IxexZ5pax+252RmEAqe+wCtn+t3bf8Vel/KfPBvWJhZSfwK/hpB0KgumA=; Received: from [86.56.130.134] (helo=cm56-130-134.liwest.at) by mx25lb.world4you.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1ViKpO-0003rf-Rk; Mon, 18 Nov 2013 10:09:06 +0100 Received: from [mailsrvr] by outgoing.mail (mail delivery) Received: from [mailclnt] by [mailsrvr] Message-ID: <482b790b64b4eab31aa26a1b10493605.1384765746@squirrel.mail> In-Reply-To: References: <52891184.6080707@mathemainzel.info> <37f8fec05d4d1acc999ab77a925c88e0.1384754521@squirrel.mail> Date: Mon, 18 Nov 2013 10:09:06 +0100 From: "Walter H." To: "Dave Cridland" X-Mailer: Mozilla/5.0 (UNIX; U; Cray X-MP/48; en-US; rv:2.70) Gecko/20110929 Communicator/7.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-SA-Do-Not-Run: Yes X-AV-Do-Run: Yes X-SA-Exim-Connect-IP: 86.56.130.134 X-SA-Exim-Mail-From: walter.h@mathemainzel.info X-SA-Exim-Scanned: No (on mx25lb.world4you.com); SAEximRunCond expanded to false Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Add-on for HTTPS websites X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 09:09:09 -0000 On Mon, November 18, 2013 09:42, Dave Cridland wrote: > On Mon, Nov 18, 2013 at 6:02 AM, Walter H. > wrote: > >> >> Bug corrected, the example certificates were wrong. >> >> Filename: draft-hoehlhubmer-https-addon >> Revision: 04 >> >> > I've skimmed this quickly, and what I think you've done here is reinven= t > DANE, which is specified in RFC 6698. I didn't notice this RFC; > I don't *think* you're adding anything new, here, seen, the additional HTTP webpage in 2.2? > but I do think it's > always interesting when someone independently arrives at roughly the sa= me > concept. I'd encourage you to read through RFC 6698, and see if there's > any > differences between your approaches that should be addressed. there is a difference: my variant uses TXT records and these are availabl= e on every DNS software; > I'd suggest you probably don't want to invest too much more time in you= r > own approach, though. Walter From dave@cridland.net Mon Nov 18 01:48:20 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDED11E8132 for ; Mon, 18 Nov 2013 01:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsyGoN500rq6 for ; Mon, 18 Nov 2013 01:48:19 -0800 (PST) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9D411E8106 for ; Mon, 18 Nov 2013 01:48:19 -0800 (PST) Received: by mail-ob0-f174.google.com with SMTP id wn1so324403obc.19 for ; Mon, 18 Nov 2013 01:48:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+1d9+CkHXzJFoufXOazbEdQKCCAy9lJ3Y71RrI6N4O0=; b=iheJSWbD/LC/YdJzKNx/tQKsYtv7BixweYtiJrcm/nEQbLOFnVL9goRnTQTYJcnd2P jslRDkMYG/PGAgEU9ZRXPbiq2PJwHfoX+JmWo9AW51nB2qq1I+xfMVW1xW539n6SMBj9 IrRqoWVtWpOYPemKlg9w8A9m2vnugE+GeQg18= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+1d9+CkHXzJFoufXOazbEdQKCCAy9lJ3Y71RrI6N4O0=; b=l/8PyZ5Zm9RdH0lVMPVATDjZPQ/rbmR9Em3PZdhyS/GDETi5e83Zoy4Q1CnBoryw1T 9Jc1wB0hgcfUAF7ID6/N5B7ZlK2pSXm9qpwlS2ZaXHgvP3IVYe1z+w939mX+lvSYe0oG TTOt+ACiINmeD7oDwzLwCSW+2R8tXSlM5cGYuM30J2IuuOzjtrdPBjXeHdDVfydRTf/7 ve+7iem93Ldta/XBEcOCim7EZ2VjPriUm+WcxDh3BI/hogPuEarMu9FRNvEoLgCG9i34 Lmnf92OpUPTx13uCqznTBlLEsYyK/60qhL9dcILIbEDT/3vIOq65tXnVNTgdVRf5v7fT 52HA== X-Gm-Message-State: ALoCoQkYXK9n8GjcPMCB3C0kQ0ePWSBGkUo9Pi6Y+gu3uHsG/iBzi20/gOZWAdEkh5NWKv4RKLOX MIME-Version: 1.0 X-Received: by 10.182.221.230 with SMTP id qh6mr19571154obc.7.1384768098575; Mon, 18 Nov 2013 01:48:18 -0800 (PST) Received: by 10.60.121.97 with HTTP; Mon, 18 Nov 2013 01:48:18 -0800 (PST) In-Reply-To: <482b790b64b4eab31aa26a1b10493605.1384765746@squirrel.mail> References: <52891184.6080707@mathemainzel.info> <37f8fec05d4d1acc999ab77a925c88e0.1384754521@squirrel.mail> <482b790b64b4eab31aa26a1b10493605.1384765746@squirrel.mail> Date: Mon, 18 Nov 2013 09:48:18 +0000 Message-ID: From: Dave Cridland To: "Walter H." Content-Type: multipart/alternative; boundary=001a11c2fcb89ccbbc04eb7072d2 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Add-on for HTTPS websites X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 09:48:20 -0000 --001a11c2fcb89ccbbc04eb7072d2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Nov 18, 2013 at 9:09 AM, Walter H. wrot= e: > On Mon, November 18, 2013 09:42, Dave Cridland wrote: > > On Mon, Nov 18, 2013 at 6:02 AM, Walter H. > > wrote: > > > >> > >> Bug corrected, the example certificates were wrong. > >> > >> Filename: draft-hoehlhubmer-https-addon > >> Revision: 04 > >> > >> > > I've skimmed this quickly, and what I think you've done here is reinven= t > > DANE, which is specified in RFC 6698. > > I didn't notice this RFC; > > > I don't *think* you're adding anything new, here, > > seen, the additional HTTP webpage in 2.2? > > Ah. I hadn't, but the problem with this is it's only a marginal increase in security, and given there's no formatting, it wouldn't even be possible to test automatically. So basically, you'd want this to be a .well-known thing in JSON or XML - but if this were typically deployed, then any attacker who'd already subverted everything else could easily subvert that too at little extra cost. I don't think that it'd be worthwhile, to be honest. > > but I do think it's > > always interesting when someone independently arrives at roughly the sa= me > > concept. I'd encourage you to read through RFC 6698, and see if there's > > any > > differences between your approaches that should be addressed. > > there is a difference: my variant uses TXT records and these are availabl= e > on every DNS software; > > Yes, I did wonder if there would be faster uptake of DANE if it were purely in TXT records, however I suspect that the marginal difficult of adding TLSA support in this specific case would be pretty low compared to adding DNSSEC anyway. Besides, DANE does TLSA; I don't think there's any evidence that TLSA support is holding anything back right now. > > I'd suggest you probably don't want to invest too much more time in you= r > > own approach, though. > I should expand on this, really. What you have done is independently come up with largely the same concept as DANE. This is pretty awesome, and it puts you with a unique insight into DANE. I don't want to imply that your effort so far is a complete waste of your time. Your fundamental idea - that certificate information can be put in DNS to increase security - is a good one, so good that it's been done already. However, there's no point in trying to persuade all those involved in DANE that they should scrap their approach and go with yours - even if there was some merit in that, you'd need a really compelling reason to do that, and I don't think you have one. What you should instead do is figure out how to get your higher-level ideas to work within DANE's framework, and see whether they make sense. One interesting point your draft makes is that you have DNSSEC as a "SHOULD", rather than a "MUST" - I need to think considerably more about whether running DANE without DNSSEC make sense in some cases - my gut feeling is that it might be interesting in Certificate Usage 0 and 1 cases (See RFC 6698 =A7 2.1.1) - that is, where the TLSA records indicate constraints on PKIX. Dave. --001a11c2fcb89ccbbc04eb7072d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 18, 2013 at 9:09 AM, Walter H. <walt= er.h@mathemainzel.info> wrote:
=
On Mon, November 18, 2013 = 09:42, Dave Cridland wrote:
> On Mon, Nov 18, 2013 at 6:02 AM, Walter H.
> <walter.h@mathemainze= l.info>wrote:
>
>>
>> Bug corrected, the example certificates were wrong.
>>
>> Filename: draft-hoehlhubmer-https-addon
>> Revision: 04
>>
>>
> I've skimmed this quickly, and what I think you've done here i= s reinvent
> DANE, which is specified in RFC 6698.

I didn't notice this RFC;

> I don't *think* you're adding anything new, here,

seen, the additional HTTP webpage in 2.2?


Ah. I hadn'= ;t, but the problem with this is it's only a marginal increase in secur= ity, and given there's no formatting, it wouldn't even be possible = to test automatically.

So basically, you'd want this to be a .well-known t= hing in JSON or XML - but if this were typically deployed, then any attacke= r who'd already subverted everything else could easily subvert that too= at little extra cost.

I don't think that it'd be worthwhile, to be ho= nest.
=A0
> but I do think it's
> always interesting when someone independently arrives at roughly the s= ame
> concept. I'd encourage you to read through RFC 6698, and see if th= ere's
> any
> differences between your approaches that should be addressed.

there is a difference: my variant uses TXT records and these are avai= lable
on every DNS software;

<= br>
Yes, I did wonder if there would be faster uptake of DANE if = it were purely in TXT records, however I suspect that the marginal difficul= t of adding TLSA support in this specific case would be pretty low compared= to adding DNSSEC anyway.

Besides, DANE does TLSA; I don't think there&= #39;s any evidence that TLSA support is holding anything back right now.
=A0
> I'd suggest you probably don't want to invest too much more ti= me in your
> own approach, though.

= I should expand on this, really.

What you have don= e is independently come up with largely the same concept as DANE. This is p= retty awesome, and it puts you with a unique insight into DANE. I don't= want to imply that your effort so far is a complete waste of your time. Yo= ur fundamental idea - that certificate information can be put in DNS to inc= rease security - is a good one, so good that it's been done already.

However, there's no point in trying to persuade all= those involved in DANE that they should scrap their approach and go with y= ours - even if there was some merit in that, you'd need a really compel= ling reason to do that, and I don't think you have one. What you should= instead do is figure out how to get your higher-level ideas to work within= DANE's framework, and see whether they make sense.

One interesting point your draft makes is that you have= DNSSEC as a "SHOULD", rather than a "MUST" - I need to= think considerably more about whether running DANE without DNSSEC make sen= se in some cases - my gut feeling is that it might be interesting in Certif= icate Usage 0 and 1 cases (See RFC 6698 =A7 2.1.1) - that is, where the TLS= A records indicate constraints on PKIX.

Dave.
--001a11c2fcb89ccbbc04eb7072d2-- From superuser@gmail.com Mon Nov 18 02:13:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63DDB11E8152 for ; Mon, 18 Nov 2013 02:13:29 -0800 (PST) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lInin2PaTeAA for ; Mon, 18 Nov 2013 02:13:28 -0800 (PST) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id AB67E11E80F6 for ; Mon, 18 Nov 2013 02:13:21 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x12so5938217wgg.25 for ; Mon, 18 Nov 2013 02:13:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aAsnzOKVq0M4sesqy2+sa3bG2iKiNv9jkaBiNgu1VaQ=; b=PqyMIydN+Ld7ZnQzgDpbGjLFnyoVtJJzqtO/0RmeXzqj8P9lSHEWqux8APdw8lHrV4 RQMDCXwMxVqWB638d5nGFLTc9ymrpV3n3pa7iLZuaY+g6GxfO99SA8xokgaWvnI46WkS qIWX05hM+g9olzIpgbtsX9mEjGqVu6WMJNfUoDWwNDrRaERJVQqVWv8HlHJPfA7uzrdP 3DqKMT4ElGapABM8dEoSOLRX9vzwTpE9xAs3Dawa8VnVNnit8KCkSItKivkHGd4/b1Bd A+n64hrpf4rfQ+pHioCPPl/xM8W5S74oM6z7sTFFVjP/4b+j3DK5j7GbZ4d0qZHkMdx8 1L7A== MIME-Version: 1.0 X-Received: by 10.180.74.52 with SMTP id q20mr16558633wiv.60.1384769600853; Mon, 18 Nov 2013 02:13:20 -0800 (PST) Received: by 10.181.13.230 with HTTP; Mon, 18 Nov 2013 02:13:20 -0800 (PST) In-Reply-To: References: Date: Mon, 18 Nov 2013 02:13:20 -0800 Message-ID: From: "Murray S. Kucherawy" To: James M Snell Content-Type: multipart/alternative; boundary=f46d0438907927a17504eb70ccb5 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-json-merge-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 10:13:29 -0000 --f46d0438907927a17504eb70ccb5 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Nov 17, 2013 at 10:41 PM, James M Snell wrote: > There are existing implementers of the current spec. If the wg doesn't > move it forward, I'll resubmit as an independent submission. > ...which is fine, of course, unless this needs Proposed Standard status, which is what you're currently requesting. The independent stream cannot produce standards track documents. So unless you'd be satisfied with Informational status, it needs to go through a WG (though not necessarily this one) or be sponsored by an Area Director; either way, there needs to be consensus recorded to proceed. If there are only a couple of people willing to review it, demonstrating that will be an uphill battle. I think getting some people to (finally!) post comments in here is probably the simplest path forward. I'm not familiar enough with this space to be able to suggest whom you might ask specifically, however. -MSK --f46d0438907927a17504eb70ccb5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Nov 17, 2013 at 10:41 PM, James M Snell <jasnell= @gmail.com> wrote:

There are existing implemente= rs of the current spec.=A0 If the wg doesn't move it forward,=A0 I'= ll resubmit as an independent submission.=A0


...which is fine, of course, unless this n= eeds Proposed Standard status, which is what you're currently requestin= g.=A0 The independent stream cannot produce standards track documents.=A0 S= o unless you'd be satisfied with Informational status, it needs to go t= hrough a WG (though not necessarily this one) or be sponsored by an Area Di= rector; either way, there needs to be consensus recorded to proceed.=A0 If = there are only a couple of people willing to review it, demonstrating that = will be an uphill battle.

I think getting some peopl= e to (finally!) post comments in here is probably the simplest path forward= .=A0 I'm not familiar enough with this space to be able to suggest whom= you might ask specifically, however.

-MSK
--f46d0438907927a17504eb70ccb5-- From walter.h@mathemainzel.info Mon Nov 18 03:25:09 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A6F11E8107 for ; Mon, 18 Nov 2013 03:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.239 X-Spam-Level: X-Spam-Status: No, score=-0.239 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_00=-2.599, FORGED_MUA_MOZILLA=2.696, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Stn3lNpMfhID for ; Mon, 18 Nov 2013 03:25:08 -0800 (PST) Received: from mx08lb.world4you.com (mx08lb.world4you.com [IPv6:2a00:1a68:1:101::1b1b:8]) by ietfa.amsl.com (Postfix) with ESMTP id F0FEF11E80FB for ; Mon, 18 Nov 2013 03:25:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mathemainzel.info; s=dkim11; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=pw/sG/vV78nJ1FB/5+cEuOWPj6rkxJfmKYzWGVY+IPg=; b=YALKOb/OPyVnTZ8QFCu4gVntR8EGFy2hAnlsMGcoR7dn27A6C+3QPdmJ6lHssl5opy75a5AtdxjVi9WPvrbcWfk+oEhBlSmIeZOndeS9Hgx0nIqYj9UwM2tzYqf4BvgXIAzLY0D0ouYpaBSlH39SOVU4QT21fH8Wu30U+amiO1g=; Received: from [86.56.130.134] (helo=cm56-130-134.liwest.at) by mx08lb.world4you.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1ViMwx-00058b-G2; Mon, 18 Nov 2013 12:25:03 +0100 Received: from [mailsrvr] by outgoing.mail (mail delivery) Received: from [mailclnt] by [mailsrvr] Message-ID: <8bb47c6739f9356bd6d2bdcbb91a498d.1384773903@squirrel.mail> In-Reply-To: References: <52891184.6080707@mathemainzel.info> <37f8fec05d4d1acc999ab77a925c88e0.1384754521@squirrel.mail> <482b790b64b4eab31aa26a1b10493605.1384765746@squirrel.mail> Date: Mon, 18 Nov 2013 12:25:03 +0100 From: "Walter H." To: "Dave Cridland" X-Mailer: Mozilla/5.0 (UNIX; U; Cray X-MP/48; en-US; rv:2.70) Gecko/20110929 Communicator/7.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-SA-Do-Not-Run: Yes X-AV-Do-Run: Yes X-SA-Exim-Connect-IP: 86.56.130.134 X-SA-Exim-Mail-From: walter.h@mathemainzel.info X-SA-Exim-Scanned: No (on mx08lb.world4you.com); SAEximRunCond expanded to false Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Add-on for HTTPS websites X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 11:25:09 -0000 On Mon, November 18, 2013 10:48, Dave Cridland wrote: > On Mon, Nov 18, 2013 at 9:09 AM, Walter H. > wrote: > > Ah. I hadn't, but the problem with this is it's only a marginal increas= e > in > security, and given there's no formatting, it wouldn't even be possible= to > test automatically. this webpage is more for the user in front of the monitor, not any softwa= re; especially the picked ciphersuite; there shall be an instruction for the programmers of browsers to make this information available to the user, too. the intention for this is not an increase of security; > So basically, you'd want this to be a .well-known thing in JSON or XML = - JSON, XML? > Yes, I did wonder if there would be faster uptake of DANE if it were > purely > in TXT records, however I suspect that the marginal difficult of adding > TLSA support in this specific case would be pretty low compared to addi= ng > DNSSEC anyway. would this work, when only one of the involved DNS servers doesn't suppor= t TLSA? I think of the fact, that DNSSEC was specified a while ago, and this is n= ew; > Besides, DANE does TLSA; I don't think there's any evidence that TLSA > support is holding anything back right now. the concept in this RFC is good, and compared to my variante very complex= . > I should expand on this, really. > > What you have done is independently come up with largely the same conce= pt > as DANE. but in comparison very simple and ready to implement; > Your fundamental idea - that certificate information can be put > in DNS to increase security - is a good one, so good that it's been don= e > already. theoretically, any real implementation within the next few months is impossible: because DANE is not just adding something to the ZONE files; > ..., you'd need a really compelling reason to do that, and I > don't think you have one. What you should instead do is figure out how = to > get your higher-level ideas to work within DANE's framework, and see > whether they make sense. the concept of DANE's framework is not the primary intention of my I-D, just the webpage for users; because of missing informations on browser-side; the other aspect of storing verifyable data in the DNS was an idea from a workmate, that I formed in a practiable ready-to-implement instruction; my thoughts were a complete new non existing system, why read my last statement of this ... > One interesting point your draft makes is that you have DNSSEC as a > "SHOULD", rather than a "MUST" the reason for this is just one: when the browser supports this checking mechanisms, the user MUST be able to use the website without DNSSEC and without these DNS entries; and if the DNS server of the provider supports DNSSEC, there MUST not be any force for the user to use this. but one other idea in this connection, that both variants - DANE and mine will fail: when the DNS is maintained by the same folks as the webserver; and this is in fact most times. Walter From alexey.melnikov@isode.com Mon Nov 18 07:40:07 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E18111E8125 for ; Mon, 18 Nov 2013 07:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTwMpuBrhvyY for ; Mon, 18 Nov 2013 07:40:02 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id F31DC11E814B for ; Mon, 18 Nov 2013 07:37:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1384789041; d=isode.com; s=selector; i=@isode.com; bh=CyezJ3F4h48HUt14BmT3E3ov1QxUqvENa19045AP87k=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=w/K+C0HQ2Voa/osaoEgVhJXlqDSiosSlcM9mvWwOcQ79qcECq6HgwlheLkoj+skkWZmuou ljfSporgIL3lQYjLwVgk2AskJazAgOwP6iY+uWkPwZhd8E+LUe31sG2eQSXTO8TOFPAAmu 2WNKeUdB0m31Jiy3ME4xBcHC6mpIZOg=; Received: from [172.16.1.224] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 18 Nov 2013 15:37:21 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <528A3430.6080900@isode.com> Date: Mon, 18 Nov 2013 15:37:20 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Ira McDonald References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pat Fleming , "apps-discuss@ietf.org" Subject: [apps-discuss] AppsDir review of draft-mcdonald-ldap-printer-schema-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 15:40:07 -0000 On 19/09/2013 17:34, Ira McDonald wrote: > Hello, > > The IEEE-ISTO PWG Internet Printing Protocol WG would like to request > IETF Apps Area review of our updated LDAP Printer Schema (updates > RFC 3712). > > http://www.ietf.org/internet-drafts/draft-mcdonald-ldap-printer-schema-05.txt > > Cheers, > - Ira (co-chair of IEEE-ISTO PWG IPP WG and co-editor of this document) My apologies for belated review. I hope you find them useful. ----------------------------------------- I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). 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-mcdonald-ldap-printer-schema-05.txt Title: Lightweight Directory Access Protocol (LDAP): Schema for Printer Services Reviewer: Alexey Melnikov Review Date: November 18, 2013 IETF Last Call Date: N/A Summary: This draft is nearly reading for publication. This document defines a schema, object classes and attributes, for Printers and Print Services, for use with directories that support Lightweight Directory Access Protocol (RFC 4510). This document is based on the Printer attributes listed in Appendix E of Internet Printing Protocol/1.1 (IPP) (RFC 2911). Additional Printer attributes are based on definitions in the Printer MIB v2 (RFC 3805), IEEE-ISTO PWG Command Set for IEEE 1284 Device ID (PWG 5107.2), IEEE-ISTO PWG IPP Job and Printer Extensions - Set 3 (PWG 5100.13), and IEEE-ISTO PWG IPP Everywhere (PWG 5100.14). This document is published by the IETF on behalf of the Internet Printing Protocol Working Group of the IEEE-ISTO Printer Working Group. Most of the issues I found are minor. In general the document is quite readable. General comments: I noticed that you redifined various syntaxes to have upper limits on Directory strings. URI and Language Tags have no upper limits. I suspect that limits that you added are going to be sufficient in most cases, but it would be better for your document to call these out explicitly in text. In Section 1: This document updates RFC 3712. But the draft header says that it Obsoletes it. I think Obsolete is correct, so the statement in Section 1 should be updated to match. In Section 3.3: > Note: When extending other structural classes with auxiliary > classes, printerService SHOULD not be used. You should also capitalize "not" according to RFC 2119. There are multiple occurrences of the same problem in multiple places in the document. > 3.4. printerServiceAuxClass > > ( 1.3.18.0.2.6.257 > NAME 'printerServiceAuxClass' > DESC 'Printer information.' > > Fleming, McDonald Expires 19 March 2014 [Page 11] > > Internet-Draft LDAP Schema for Printer Services 19 September 2013 > > AUXILIARY > SUP printerAbstract > MAY ( printer-uri $ > printer-xri-supported ) > ) > > This auxiliary class defines Printer information. It is derived from > class printerAbstract and thus inherits common Printer attributes. > This class SHOULD be used with a structural class. Each directory entry requires a structural object class, so I think this SHOULD is misleading. Also, why is this not a MUST? I suggest you just delete this sentence or reword it to make it non normative (and point to the document which makes the authoritative statement on this matter.) Similar text in 3.5 and 3.6. > 4. Definition of Attribute Types > > The following attribute types reference matching rule names (instead > of OIDs) for clarity (see Section 6 below). For optional attributes, > if the Printer information is not known, the attribute value SHOULD > not be set. In the following definitions, referenced matching rules > are defined in Section 4 of [RFC4517] (see Section 6 'Definition of > Matching Rules' below). I think you still meant section 4. > Note: For interoperability and consistent text display, values of > attributes defined in this document: (a) SHOULD be normalized as > recommended in Unicode Format for Network Interchange [RFC5198]; (b) > SHOULD not contain DEL or any C0 or C1 control characters except for "SHOULD not" --> "SHOULD NOT" > HT, CR, and LF; (c) SHOULD only contain CR and LF characters together > (not as singletons); and SHOULD NOT contain HT, CR, or LF characters > in names, e.g., printer-name and printer-aliases. In 4.1: > Note: LDAP application clients SHOULD not attempt to use malformed > URI values read from this attribute. LDAP administrative clients > SHOULD not write malformed URI values into this attribute. "SHOULD not" --> "SHOULD NOT" (twice) In 4.4: > Values of language tags SHOULD conform to Tags for Identifying > Languages [BCP47]. Why is this a SHOULD and not a MUST? I.e. what are possible reason to put anything not specified in BCP47 here? > 4.12. printer-charset-supported > > ( 1.3.18.0.2.4.1131 > NAME 'printer-charset-supported' > DESC 'One of the charsets supported for the attribute values of > syntax DirectoryString for this directory entry.' I don't understand this description. DirectoryString is always in UTF-8. How is this LDAP attribute being used? > EQUALITY caseIgnoreMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} > ) > 4.13. printer-generated-natural-language-supported > > ( 1.3.18.0.2.4.1137 > NAME 'printer-generated-natural-language-supported' > DESC 'One of the natural languages supported for this directory > entry.' Again, I am not entirely sure how this is used. Can you clarify? > 4.20. printer-number-up-supported > > ( 1.3.18.0.2.4.1124 > NAME 'printer-number-up-supported' > DESC 'Maximum number of print-stream pages that can be imposed upon a > single side of an instance of selected medium by this Printer.' > EQUALITY integerMatch > ORDERING integerOrderingMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 > ) This is not defined as single-valued. What is the meaning of multiple values? > 4.35. printer-device-id > > ( 1.3.18.0.2.24.46.1.101 > NAME 'printer-device-id' > DESC 'The IEEE 1284 Device ID for this Printer.' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} > ) > > Values of this attribute SHOULD conform to IEEE-ISTO PWG Command Set > Format for IEEE 1284 Device ID [PWG5107.2]. > > Note: For interoperatibility, values of this attribute SHOULD > include key/value pairs in the following order: (a) all required > key/value pairs (i.e., MANUFACTURER/MFG, MODEL/MDL, and COMMAND > SET/CMD); (b) all optional key/value pairs; and (c) all vendor > key/value pairs. How does the advice on ordering interacts with multiple values of the attribute? LDAP multivalued attributes have no ordering of values. printer-device-id 1.3.18.0.2.24.46.1.101 printer-device-service-count 1.3.18.0.2.24.46.1.102 printer-uuid 1.3.18.0.2.24.46.1.104 printer-charge-info 1.3.18.0.2.24.46.1.105 printer-charge-info-uri 1.3.18.0.2.24.46.1.106 printer-geo-location 1.3.18.0.2.24.46.1.107 printer-ipp-features-supported 1.3.18.0.2.24.46.1.108 This is not necessarily a problem, but I couldn't find a registration for the 1.3.18.0.2.24 OID. The parent OID is owned by IBM. 13. Appendix X - Change History [ [RFC Editor: This section to be deleted before RFC publication] ] -bis document are required to include "Changes since RFC XXXX" section. So you should replace this Appendix with another one that details changes since RFC 3712. Best Regards, Alexey From ht@inf.ed.ac.uk Mon Nov 18 07:51:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10D711E8190 for ; Mon, 18 Nov 2013 07:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4ImyvcVTvMM for ; Mon, 18 Nov 2013 07:51:52 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 51D0411E81DE for ; Mon, 18 Nov 2013 07:49:36 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rAIFn7p1018955; Mon, 18 Nov 2013 15:49:12 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAIFn6F8017984; Mon, 18 Nov 2013 15:49:06 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAIFn7va016477; Mon, 18 Nov 2013 15:49:07 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rAIFn7P0016473; Mon, 18 Nov 2013 15:49:07 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Bjoern Hoehrmann References: <525D3D24.3030702@gmx.de> <525D7877.6080905@gmx.de> <024801cecb55$e478be20$4001a8c0@gateway.2wire.net> <303o795cbqscut34qbeeuevdmf3ig4769k@hive.bjoern.hoehrmann.de> <256o79p8kcls640qtmtkianfmu1sp1vi2b@hive.bjoern.hoehrmann.de> <349q79t09elodhhqf1rhib87j2plnc4slv@hive.bjoern.hoehrmann.de> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Mon, 18 Nov 2013 15:49:07 +0000 In-Reply-To: <349q79t09elodhhqf1rhib87j2plnc4slv@hive.bjoern.hoehrmann.de> (Bjoern Hoehrmann's message of "Fri\, 08 Nov 2013 21\:23\:03 +0100") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call:draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Nov 2013 15:51:57 -0000 Bjoern Hoehrmann writes: > I think I have made clear why I think this change needs much broader > review, but I guess it does not hurt to offer the test case a third > time, `data:application/xml;charset=utf-32,%FF%FE%00%00...`. I've put > it up at http://www.websitedev.de/temp/application-xml-utf32-le.xml > so people can easily check that IE9 treats that as UTF-32 even though > it starts with a UTF-16 Unicode Signature. It starts with a UTF-32 signature, per both the UNICODE 6.2 documentation (see e.g. Table 16-6 in Chapter 16 [1]) and the XML specification (see the first table in Appendix F.1 [2]), so the question of precedence isn't actually addressed by this one. > I also mentioned the W3C Markup Validator as an implementation that > gives precedence to the `charset` parameter in the `Content-Type` > header and I just checked, it, too, treats it as a UTF-32 document. > . . . > You also list Expat. I was under the impression that Expat does not > actually support reading HTTP responses. I downloaded the sources for > expat-2.1.0 and the string `charset` only appears under `xmlwf/` which > would be an expat-based utility, but even there the code seems dead. > Similar for "Host", "Content-Type", "HTTP/", "winsock", "socket". So, > I think Expat also does not do as you describe. You're right -- I should have been clearer -- Python's xml.parser.expat embedding was what I tested, which doesn't access the HTTP response directly (as is also the case with lxml, even though it uses libxml2). > And rxp-1.5.0 does seem to have some HTTP support, but a grep for the > string `Content-Type` returns unsuccessfully. That usually means the > Content-Type header is ignored entirely. Correct. So for the two main Python embeddings, and rxp, a BOM does, in practice, take precedence over the charset param, because they ignore the response header altogether. The 'requests' Python package, on the other hand, does give precedence to a charset param if one is present. Let me try to summarise, with the help of a test page I've put together [3], drawing on your examples and some of mine. That page contains tests of 4 related byte-sequences, each provided as a separate resource and as a data: URI. Their text content is identical (

CU+2019U+00E9st domage

), but they differ in encoding (UTF-16LE vs. UTF-32LE) and in the presence or absence of an appropriate BOM. There are 6 tests, 3 for each encoding (read 'xx' below as 16 or 32), as follows: label filename description --------------------------- b bxxle with BOM, served with correct charset param bX bxxleX with BOM, served with conflicting charset param nbX nbxxleX without BOM, served with conflicting charset param In each test the byte-sequence is made available in three forms: a data: URI as the src of an iframe; an HTTP resource via the src of an iframe; an HTTP resource via the href of an a. Here's a tabulation of the results for eight contemporary browsers which I've tested C Chrome 33.0.1707, Windows 7 (same results from Chrome 30.0, Debian) FF Firefox 25.0, Windows 7, (same results from Firefox 25, Ubuntu) IE Internet Explorer 9.0.22, Windows 7 O Opera 12.6, Windows 7 (in auto-detect mode) S Safari 5.1.7, Windows 7 (same results from Safari, MacOs 10) Y means renders correctly (as HTML, that is, w/o the

), YT means renders correctly (as plain text, that is, with the

), YX means renders correctly (as 'tree view' XML, including

), E means gives an error, N means a blank The result codes appear twice, the first time for the data: URI (in its iframe), labelled 'd:', the second for the HTTP resource in its iframe, labelled 'h:'. encoding 16LE 32LE d: h: d: h: label C: Y Y | Y Y b FF: YX YX | E E IE: E Y | E Y O: YX YX | E YT S: Y Y | Y Y --------------------------------------- C: Y Y | Y Y bX FF: YX YX | E E IE: E N | E Y O: YX YX | E YT S: Y Y | Y Y --------------------------------------- C: E E | E E nbX FF: E E | E E IE: E N | E N O: YX YT | E YT S: E E | E E ------------------------------------------ There's a lot of data there, but we can simplify the analysis by reducing it along some dimensions. First of all, the third condition, nbX, is the uncontroversially broken case: there is no BOM in the byte-sequence and the charset parameter conflicts with the actually encoding used. And five out of the six browsers tested in fact detect the error and (except for IE in the resource cases) signal it. The exception is Opera, which apparently operates some kind of recovery strategy. This condition was included in the test set so that we know that the browsers _can_ detect the conflict, and it appears that they can. Second of all, the 32-bit encoding column. Clearly the Firefoxs, IE and Opera simply don't support 32-bit data: URI decoding, and the Firefoxes don't handle 32-bit at all. And, more to the point, the b32 and b32X conditions show identical results, so they give us no insight into the question of fundamental interest, that is, the relative priority of BOM and charset parameter. So we can focus our attention on the b16 and b16X conditions. Here we can see that a) Chrome*2 and Safari show identical results (no surprise here), but also FF*2 and Opera show identical results. Furthermore, once we notice the IE _never_ accepts data: URIs, then collapse the result codes into two broader categories: decoding success vs. failure (S vs. F), the difference between the three result columns goes away: encoding 16LE label C*2/S: S b FF*2/O: S E: S ----------------- C*2/S: S bX FF*2/O: S E: F So, seven out of eight of the browsers that we tested treat a UTF-16 BOM as authoritative when a conflicting charset param is present. Moving over to APIs and libraries, it's harder to know what's a more-or-less comprehensive survey. Here's what I know: Two out of four C/C++ libraries (rxp, xerces-c) treat a BOM as authoritative, and this is _not_ because they don't have access to the charset parameter, but rather because their designers have specifically chosen not to consider it. xmllint however makes the opposite choice, and treats a charset, if present, as authoritative. Expat is a surprising case -- it provides a parameter which can be used to pass in a character encoding name, but it will ignore this if it detects a different encoding in its input byte-stream (tested via both the Perl and Python embeddings, and confirmed by examining the source). So in fact expat does explicitly to treat a BOM as authoritative. Similarly xerces-j treats a BOM as authoritative, again based on a specific choice, even documented in the source code, to ignore the charset parameter. Summary: For five 'native' XML processors: 1 Ignores the charset param altogether: rxp 3 Explicitly uses in-band information (BOM or simply sniffing) to override a charset or other external information (expat, xerces-c, xerces-j) 1 Treats the charset as authoritative if present (libxml2) So we have 7 out of 8 web browsers (or 4 out of browser 5 code-bases) which treat a UTF-16LE BOM as authoritative, and 4 out of 5 native XML APIs which do the same. (I'm not ignoring your reminder that you have built an add-on to perl's HTML::Parser module which treats the charset as authoritative, but since that module does not qualify as a conformant XML parser in any case, it's not really relevant to 3023bis). (The php built-in XMLReader extension, which is documented as relying on 'libxml', behaves similarly to rxp, not libxml2, as far as I can see). So, net-net: I think the above tabulation counts as rough consensus. Certainly it's not a reason _not_ to adopt the approach specified in section 3.6 of the most recent 3023bis draft [4]. ht [1] http://www.unicode.org/versions/Unicode6.2.0/ch16.pdf [2] http://www.w3.org/TR/REC-xml/#sec-guessing-no-ext-info [3] http://www.ltg.ed.ac.uk/~ht/ov-test/wrapper.html -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From internet-drafts@ietf.org Mon Nov 18 10:37:20 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C82781A1F48; Mon, 18 Nov 2013 10:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIlNZmge2vxJ; Mon, 18 Nov 2013 10:37:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0ECE1A1F4D; Mon, 18 Nov 2013 10:37:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131118183718.14705.29469.idtracker@ietfa.amsl.com> Date: Mon, 18 Nov 2013 10:37:18 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-merge-patch-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 18:37:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : JSON Merge Patch Author(s) : James M Snell Filename : draft-ietf-appsawg-json-merge-patch-02.txt Pages : 10 Date : 2013-11-18 Abstract: This specification defines the JSON merge patch format and processing rules. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-merge-patch-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jasnell@gmail.com Mon Nov 18 10:39:09 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8F51A1F4F for ; Mon, 18 Nov 2013 10:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9Vu87rRkGas for ; Mon, 18 Nov 2013 10:39:08 -0800 (PST) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0856F1A1F48 for ; Mon, 18 Nov 2013 10:39:04 -0800 (PST) Received: by mail-oa0-f41.google.com with SMTP id g12so7680719oah.0 for ; Mon, 18 Nov 2013 10:38:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=G2GAEJ27j3JgDWuPbUC64SbhtpKJKr95zHudW+L/HBg=; b=ZPuQlvr40rSyXZjpn3p1OVfexxP4cmI0cI05k1uTJcX0BdCkTiZzS9sgKXn89sXudW MNftQILzq87VDrx3iP5vI1opedO/kfJdhb0QahdcLDF3EMKghDA6Oh9YRAfd9UxTuWAi Rp/BIfzrN3NgZUG4hN4DR/9wERIqABulhb2ZbVD9GIKv/yI/cnWlepq71TSNtFtzB4Jb hiCLv2vCYt7pUVYYbaC+Heu8AJBpaCA9OTFSOzsTRg1Ilm5tqj0vh372fHjGjImwn1/k somQsQEjl1E8BffnmOBDEZ6hNl9ta+dduj/zCbXkTXR96U7MHj+iesanlBEcpdcysnqG Zkyg== X-Received: by 10.182.92.231 with SMTP id cp7mr627739obb.82.1384799939150; Mon, 18 Nov 2013 10:38:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.124.137 with HTTP; Mon, 18 Nov 2013 10:38:39 -0800 (PST) In-Reply-To: <20131118183719.14705.16188.idtracker@ietfa.amsl.com> References: <20131118183719.14705.16188.idtracker@ietfa.amsl.com> From: James M Snell Date: Mon, 18 Nov 2013 10:38:39 -0800 Message-ID: To: IETF Apps Discuss Content-Type: text/plain; charset=UTF-8 Subject: [apps-discuss] Fwd: New Version Notification for draft-ietf-appsawg-json-merge-patch-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 18:39:09 -0000 Based on feedback. Fairly significant editorial update and one key technical change. This updates the media type registration to follow the +json naming policy on the media type (that is, application/json-merge-patch becomes application/merge-patch+json). - James ---------- Forwarded message ---------- From: Date: Mon, Nov 18, 2013 at 10:37 AM Subject: New Version Notification for draft-ietf-appsawg-json-merge-patch-02.txt To: "James M. Snell" A new version of I-D, draft-ietf-appsawg-json-merge-patch-02.txt has been successfully submitted by James M Snell and posted to the IETF repository. Filename: draft-ietf-appsawg-json-merge-patch Revision: 02 Title: JSON Merge Patch Creation date: 2013-11-18 Group: appsawg Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-json-merge-patch-02.txt Status: http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch Htmlized: http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-json-merge-patch-02 Abstract: This specification defines the JSON merge patch format and processing rules. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From ietf@rozanak.com Mon Nov 18 16:13:09 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9571D1AE693 for ; Mon, 18 Nov 2013 16:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHj6f3UIa33A for ; Mon, 18 Nov 2013 16:13:07 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8A51AE6C8 for ; Mon, 18 Nov 2013 16:13:07 -0800 (PST) Received: from kopoli (g226059105.adsl.alicedsl.de [92.226.59.105]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0Lpu1v-1VESyv0JcN-00f3NL; Mon, 18 Nov 2013 19:12:56 -0500 From: "Hosnieh Rafiee" To: Date: Tue, 19 Nov 2013 01:12:51 +0100 Message-ID: <00d001cee4bc$195860d0$4c092270$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7kvBXwheJi5ln1Sn21puHNkZpmtg== Content-Language: en-us X-Provags-ID: V02:K0:oPNg2PZDj7TcSHBsiaDf9I+3XvWUQCs2ahGFrj3eKHk nNAHyK1DJIQN6QkX93CUxGurysZrA9QweDYv4Y1dj+ahjD1Clz UkU96Q58vK4xMuKPnI9C/qWGIfHC8MkKzPdXfYZeDt/gjSkmGA Op4LsHYHlMJ5zkt4feYUkq1HHE3CI8P8m3NkTl+ceKWlSYlNht 5DYtqbCtar9fxP7OE5Zc5/TxN0MFK2TFkkBM+dQMuW5ZyrJsoq lI9ePsGw3glxBucjCjqfA7LBC8YA19D/O/2yZa1FgMlGBAJXoH Na2x8UmUqMNyMEyRWMxdaaxFUadH2n53G5et72PHEj6+YuScgW KI0xY1AO4a3wJOZK/TuM= Cc: Erik Nordmark Subject: [apps-discuss] Using SSAS for secure authentication in application layer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 00:13:09 -0000 Hello, Sorry if my message might not be so related to this group. I wasn't really thinking about integrating a network layer security with application layer security except about DNS. But after I reviewed a paper that tried to use the network layer as a means of authentication for application layer, I thought it might be also useful to discuss it in this group. Now let me explain the approach. I have a draft, http://tools.ietf.org/html/draft-rafiee-6man-ssas that some of you might already know it, which provides the proof of IP address ownership simpler and faster than the current standard available approach in network layer. The paper that I read tried to integrated this work with SIP for authentication purposes especially for proxy SIPs. This is the reason that I thought it can be a start of new use cases for this draft for not only providing local security but a means of authentication for application layers. What do you think? Thanks, -----------smile---------- Hosnieh . success is a journey, not a destination.. You cannot change your destination overnight, but you can change your direction ... Focus on the journey From James.H.Manger@team.telstra.com Mon Nov 18 18:15:10 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB931AEA64 for ; Mon, 18 Nov 2013 18:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIusey0LEc1Y for ; Mon, 18 Nov 2013 18:15:08 -0800 (PST) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id DDED91AEA66 for ; Mon, 18 Nov 2013 18:15:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,727,1378821600"; d="scan'208";a="158999391" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 19 Nov 2013 13:14:59 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7263"; a="178337011" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcbni.tcif.telstra.com.au with ESMTP; 19 Nov 2013 13:14:59 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Tue, 19 Nov 2013 13:14:59 +1100 From: "Manger, James H" To: James M Snell , IETF Apps Discuss Date: Tue, 19 Nov 2013 13:14:58 +1100 Thread-Topic: [apps-discuss] Fwd: New Version Notification for draft-ietf-appsawg-json-merge-patch-02.txt Thread-Index: Ac7kkQGJvD80R2X0QX6jsVJL7OclgwAMX5qA Message-ID: <255B9BB34FB7D647A506DC292726F6E11536736422@WSMSG3153V.srv.dir.telstra.com> References: <20131118183719.14705.16188.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-ietf-appsawg-json-merge-patch-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 02:15:11 -0000 Pj4gVGl0bGU6ICAgICAgICAgICBKU09OIE1lcmdlIFBhdGNoDQo+PiBIdG1saXplZDoNCj4+IGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXBwc2F3Zy1qc29uLW1lcmdlLXBh dGNoLTAyDQo+PiBBYnN0cmFjdDoNCj4+ICAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIHRo ZSBKU09OIG1lcmdlIHBhdGNoIGZvcm1hdCBhbmQNCj4+IHByb2Nlc3NpbmcNCj4+ICAgIHJ1bGVz Lg0KDQo+IEJhc2VkIG9uIGZlZWRiYWNrLiBGYWlybHkgc2lnbmlmaWNhbnQgZWRpdG9yaWFsIHVw ZGF0ZSBhbmQgb25lIGtleQ0KPiB0ZWNobmljYWwgY2hhbmdlLiBUaGlzIHVwZGF0ZXMgdGhlIG1l ZGlhIHR5cGUgcmVnaXN0cmF0aW9uIHRvIGZvbGxvdw0KPiB0aGUgK2pzb24gbmFtaW5nIHBvbGlj eSBvbiB0aGUgbWVkaWEgdHlwZSAodGhhdCBpcywNCj4gYXBwbGljYXRpb24vanNvbi1tZXJnZS1w YXRjaCBiZWNvbWVzIGFwcGxpY2F0aW9uL21lcmdlLXBhdGNoK2pzb24pLg0KDQpNb3N0IG9mIHRo ZXNlIGNoYW5nZXMgYXJlIGdyZWF0OiB0aXRsZSwgbWVkaWEgdHlwZSwgb3JnYW5pemF0aW9uLg0K DQpJIGZlZWwgdGhlcmUgYXJlIHN0aWxsIGlzc3VlcyAoaW4gYWRkaXRpb24gdG8gdGhlIG91dHN0 YW5kaW5nIGlzc3VpbmcgaW4gbXkgbGFzdCBjYWxsIGNvbW1lbnRzKToNCg0KMS4NClNlY3Rpb24g Miwgc3RlcCAxIHNheXM6DQoNCiAgICAgICBBbnkgbnVsbCBtZW1iZXIgY29udGFpbmVkIGluDQog ICAgICAgdGhlIG1lcmdlIHBhdGNoIE1VU1QgYmUgaWdub3JlZCBhbmQgdHJlYXRlZCBhcyBpZiB0 aG9zZSBtZW1iZXJzDQogICAgICAgYXJlIHVuZGVmaW5lZC4NCg0KIm51bGwgbWVtYmVyIiBpcyB1 bmNsZWFyLiBSRkMgNDYyNyAiSlNPTiIgdXNlcyAibWVtYmVyIiB0byBtZWFuIGEgbmFtZS92YWx1 ZSBwYWlyIGluIGFuIG9iamVjdCAoYW5kIHdlIHNob3VsZCBzdGljayB0byB0aGlzIG1lYW5pbmcp LiBJcyBhICJudWxsIG1lbWJlciIgYSBuYW1lL3ZhbHVlIHBhaXIgd2l0aCBhIG51bGwgdmFsdWUs IG9yIGRvZXMgaXQgYWxzbyBpbmNsdWRlIGEgbnVsbCB2YWx1ZSBpbiBhbiBhcnJheT8gSSBob3Bl IGl0IGlzIHRoZSBmb3JtZXIsIGJ1dCBkb24ndCB0aGluayB0aGlzIGlzIHdoYXQgdGhlIGF1dGhv ciBpbnRlbmRzLg0KDQpJIHRoaW5rIGl0IGlzIGNyYXp5IHRvIHJlbW92ZSBudWxsIHZhbHVlcyBm cm9tIGFycmF5cyAobWVyZ2UtcGF0Y2ggc2hvdWxkIHRyZWF0IGFycmF5cyBhcyBvcGFxdWUgcHJp bWl0aXZlIHZhbHVlcyksIGJ1dCBpZiB0aGlzIGlzIHRoZSByZWdyZXR0YWJsZSBjb25zZW5zdXMg dGhlIHRleHQgbmVlZHMgdG8gYmUgY2xlYXJlci4gU2F5aW5nIGEgbnVsbCB2YWx1ZSAiTVVTVCBi ZSBpZ25vcmVkIiBhbmQgdHJlYXRlZCBhcyBpZiBpdCBpcyAidW5kZWZpbmVkIiBkb2VzIG5vdCBz dWdnZXN0IGEgcGF0Y2ggWzEsbnVsbCwzXSBpcyBzdXBwb3NlZCB0byBiZSBjb252ZXJ0ZWQgdG8g WzEsM10uIFRoaXMgY29udmVyc2lvbiBkb2VzIG5vdCBpZ25vcmUgdGhlIG51bGwgKGl0IGV4cGxp Y2l0bHkgcmVtb3ZlcyBpdCkgYW5kIGRvZXMgbm90IHRyZWF0IGl0IGFzICJ1bmRlZmluZWQiIChh dCBsZWFzdCBpbiBKYXZhU2NyaXB0IGFuIGFycmF5IHBvc2l0aW9uIGNhbiBiZSB1bmRlZmluZWQg YW5kIGl0IGRvZXMgbm90IHNoaWZ0IHN1YnNlcXVlbnQgdmFsdWVzIGluIHRoZSBhcnJheSB0byBl YXJsaWVyIHBvc2l0aW9ucykuDQoNCiJudWxsIG1lbWJlciAuLiBpZ25vcmUgLi4gdW5kZWZpbmVk IiB0ZXh0IGFwcGVhcnMgMyB0aW1lcyAoc3RlcCAxLCBzdGVwIDIgM3JkIHBvaW50LCBzdGVwIDIg NHRoIHBvaW50KSBlYWNoIHdvcmRlZCBzbGlnaHRseSBkaWZmZXJlbnRseS4NCg0KDQoyLg0KU2Vj dGlvbiAyIG9mZmVycyB0d28gcnVsZXM6DQojMSBpZiBlaXRoZXIgcGF0Y2ggb3IgdGFyZ2V0IGlz IGFuIGFycmF5Ow0KIzIgaWYgcGF0Y2ggb3IgdGFyZ2V0IGlzIGFuIG9iamVjdC4NCg0KSWYgbWVy Z2luZyBpcyByZWFsbHkgb25seSBkZWZpbmVkIHdoZW4gcGF0Y2ggYW5kIHRhcmdldCBhcmUgYXJy YXlzIG9yIG9iamVjdHMsIHRoZW4gdGhpcyBzaG91bGQgYmUgZXhwbGljaXRseSBzdGF0ZWQuIFJ1 bGUgIzIgYWx3YXlzIGFwcGxpZXMgd2hlbiBydWxlICMxIGRvZXMgbm90IHNvIGRyb3AgdGhlICJp ZiIgY29uZGl0aW9uLg0KDQogICAgMS4gSWYgdGhlIHJvb3RzIG9mIGVpdGhlciB0aGUgbWVyZ2Ug cGF0Y2ggb3IgdGFyZ2V0IHJlc291cmNlDQogICAgICAgZG9jdW1lbnRzIGFyZSBKU09OIEFycmF5 cyAuLi4NCiANCiAgICAyLiBPdGhlcndpc2UgdGhlIHJvb3RzIG9mIHRoZSBtZXJnZSBwYXRjaCBh bmQgdGFyZ2V0IHJlc291cmNlDQogICAgICAgZG9jdW1lbnRzIGFyZSBib3RoIEpTT04gT2JqZWN0 cy4gSXRlcmF0ZSB0aHJvdWdoIC4uLg0KDQpJdCB3b3VsZCBiZSBtdWNoIGJldHRlciB0byBkZWZp bmUgcHJvY2Vzc2luZyBydWxlcyBmb3IgcGF0Y2ggYW5kIHRhcmdldCBiZWluZyBhbnkgSlNPTiB2 YWx1ZSAoaW5jbHVkaW5nIHByaW1pdGl2ZSB2YWx1ZXMpLCBub3QganVzdCBhcnJheXMgYW5kIG9i amVjdHMuIFBhcnRpY3VsYXJseSBhcyB0aGUgZXhhbXBsZSBKYXZhU2NyaXB0IGltcGxlbWVudGF0 aW9uIChhcHBlbmRpeCBCKSBleHBsaWNpdGx5IHN1cHBvcnRzIHBhdGNoIGFuZCB0YXJnZXQgYmVp bmcgcHJpbWl0aXZlIHZhbHVlcyBzbyBzb21lIGJlaGF2aW91ciBpcyBpbXBsaWVkIGJ5IHRoZSBj b2RlLCBqdXN0IG5vdCBzdGF0ZWQgaW4gdGhlIHRleHQuDQoNCkV2ZW4gaWYgd2Ugc29tZSB3YW50 IHRvIHJlc3RyaWN0IGFwcGxpY2F0aW9uL21lcmdlLXBhdGNoK2pzb24gY29udGVudCAoZWcgYSBQ QVRDSCBib2R5KSB0byBiZWluZyBhbiBhcnJheSBvciBvYmplY3QgKG9yIGV2ZW4ganVzdCBhbiBv YmplY3QpLCBpdCB3b3VsZCBzdGlsbCBiZSB3b3J0aCBkZXNjcmliaW5nIHRoZSBtZXJnZSBwcm9j ZXNzaW5nIGZvciBhcmJpdHJhcnkgSlNPTiB2YWx1ZXMgdG8gaGVscCBpbXBsZW1lbnRlcnMgd3Jp dGluZyBjb2RlLg0KDQoNCjMuDQpBcHBlbmRpeCBCICJFeGFtcGxlIEphdmFTY3JpcHQgSW1wbGVt ZW50YXRpb24iIGRlZmluZXMgYW4gYXBwbHkob3JpZywgcGF0Y2gpIGZ1bmN0aW9uIHRoYXQgc2F5 cyBpdCAid2lsbCBtdXRhdGUgdGhlIHBhc3NlZCBpbiBvYmplY3QgaW4gcGxhY2UgYXMgd2VsbCIu IFRoaXMgaXMgcHJvYmFibHkgYSBiYWQgZGVzaWduIGFuZCBpcyBjZXJ0YWlubHkgYSBiYWQgaW1w bGVtZW50YXRpb24gYXMgJ29yaWcnIGlzIG11dGF0ZWQgaW4gc29tZSBjaXJjdW1zdGFuY2VzIGJ1 dCBub3QgaW4gb3RoZXJzOyBzb21ldGltZXMgJ29yaWcnIHdpbGwgZW5kIHVwIG1hdGNoaW5nIHRo ZSByZXR1cm5lZCByZXN1bHQsIGluIG90aGVyIGNpcmN1bXN0YW5jZXMgaXQgaXMgdW5jaGFuZ2Vk LCBhbmQgSSdtIG5vdCBzdXJlIGlmIGl0IGNhbiBlbmQgdXAgc29tZXdoZXJlIGluIGJldHdlZW4u DQoNCkZvciBpbnN0YW5jZSwgJ29yaWcnIHJlbWFpbnMgdW5jaGFuZ2VkIGlmIGl0IGlzIGFuIGFy cmF5IG9yIGlmICdwYXRjaCcgaXMgYW4gYXJyYXkuDQoNCkkgc3VnZ2VzdGVkIHNvbWUgYWx0ZXJu YXRpdmUgY29kZSBpbiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYXBwcy1k aXNjdXNzL2N1cnJlbnQvbXNnMTA1NDguaHRtbA0KDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0K From internet-drafts@ietf.org Tue Nov 19 04:09:22 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317F11ADF55; Tue, 19 Nov 2013 04:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dn7BCT_UWCDS; Tue, 19 Nov 2013 04:09:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA0B1ADF59; Tue, 19 Nov 2013 04:09:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131119120919.12901.59046.idtracker@ietfa.amsl.com> Date: Tue, 19 Nov 2013 04:09:19 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 12:09:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : XML Media Types Author(s) : Henry S. Thompson Chris Lilley Filename : draft-ietf-appsawg-xml-mediatypes-05.txt Pages : 27 Date : 2013-11-19 Abstract: This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types. This specification also standardizes the '+xml' suffix for naming media types outside of these five types when those media types represent XML MIME entities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-xml-mediatypes There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-xml-mediatypes-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ht@inf.ed.ac.uk Tue Nov 19 04:23:41 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717171ADF61; Tue, 19 Nov 2013 04:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlakOt7kOZPc; Tue, 19 Nov 2013 04:23:38 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 558871ADF5E; Tue, 19 Nov 2013 04:23:37 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rAJCNFCC019163; Tue, 19 Nov 2013 12:23:20 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAJCNEUn010470; Tue, 19 Nov 2013 12:23:14 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAJCNFg5007140; Tue, 19 Nov 2013 12:23:15 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rAJCNEKh007136; Tue, 19 Nov 2013 12:23:14 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: i-d-announce@ietf.org, apps-discuss@ietf.org References: <20131119120919.12901.59046.idtracker@ietfa.amsl.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 19 Nov 2013 12:23:14 +0000 In-Reply-To: <20131119120919.12901.59046.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Tue\, 19 Nov 2013 04\:09\:19 -0800") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 12:23:41 -0000 internet-drafts writes: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Applications Area > Working Group Working Group of the IETF. > > Title : XML Media Types > Filename : draft-ietf-appsawg-xml-mediatypes-05.txt As for previous drafts, an editors' diff is available, at http://www.w3.org/XML/2012/10/3023bis/draft-ietf-appsawg-xml-mediatypes-05_diff.html This draft contains only very modest changes, which address all but one outstanding comment. My reasoning for not changing 3.6 in response to Bjoern Hoehrmann's objection to the treatment of a BOM as authoritative even in the presence of a charset parameter [1] is set out in [2]. Martin Duerst (in another thread) summarises my reasoning, as follows: What's most important now is to know what receivers actually accept. We are not in a design phase, we are just updating the definition ... and making sure we fix problems if there are problems, but we have to use the installed base for the main guidance Given the wide review these drafts have received (thanks in particular to Julian Reschke and Erik Wilde), and the recent endorsement by the W3C XML Core WG [3], I hope we can move this back to WG Last Call, get an official review, and take it forward. ht [1] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10810.html [2] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10883.html [3] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10849.html -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From derhoermi@gmx.net Tue Nov 19 07:03:10 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3E61AE005 for ; Tue, 19 Nov 2013 07:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QkM0KLIsPqf for ; Tue, 19 Nov 2013 07:03:07 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 644051AE001 for ; Tue, 19 Nov 2013 07:03:07 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.62.159]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0MU0U9-1W8o1S3Ns9-00Qi0R for ; Tue, 19 Nov 2013 16:03:00 +0100 From: Bjoern Hoehrmann To: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 19 Nov 2013 16:03:00 +0100 Message-ID: References: <20131119120919.12901.59046.idtracker@ietfa.amsl.com> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:hnxvgJS9YfpGiBEdwu1BHs1e22GlPz1GaJufieRTa3xcJddxhAf sWwUWdPqUk/NawGXsiu1FK4SQI5Ze8CymuDMWxRQcvuc+ckG8LBUfR6cBY6D4+B6S63skll IgsfwcaYSBOUXDKn7EZSxyQUYMSO1EB27BxGDOc4aIB+ESdkW3x+zU9i8PKQqUNQ0Jeq176 U3mZiuPqO0EC6tJ7BYP9Q== Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 15:03:10 -0000 * Henry S. Thompson wrote: >My reasoning for not changing 3.6 in response to Bjoern Hoehrmann's >objection to the treatment of a BOM as authoritative even in the >presence of a charset parameter [1] is set out in [2]. I said that I think this is a serious and problematic change that needs wide review prior to a two-week Last Call period and that the change is fine by me provided there is evidence of wide review. It would be easy, for instance, to ask on a set of mailing lists, say * ietf-charsets@iana.org * www-international@w3.org * unicode@unicode.org for endorsements for one part of the proposal which would require XML implementations to treat data:application/xml;charset=utf-32,%FF%FE%00%00... as malformed UTF-16 encoded document, and if the question is not mis- leading and there are endorsements by qualified individuals then I'd be satisfied that this part of the proposal has received adequate review. You could also point me to messages in archive of this list where such individuals have provided rationale for their support of this change. I note that the "Changes from RFC 3023" appendix of the document does not mention the changes in question and you need to have a good grasp of the issues to notice them when carefully reading the document. If the document had carefully explained the changes where appropriate, for instance, for the issue above, which is just one among several, e.g. NOTE: While appendix F.1 of the XML 1.0 Recommendation suggests that an initial byte sequence of FF FE 00 00 is indicative of the UTF-32 character encoding, the rules of this specification require such a sequence to be interpreted as a UTF-16 Byte Order Mark followed by a U+0000 character rendering the document malformed. It is therefore impossible to use UTF-32 in application/xml, ... entities; a charset parameter cannot be used to prevent misinterpretation of documents encoded in UTF-32 when using the media types defined in this memo. then there might be a plausible claim people knew of this change and some of its implications and signed off on it. The document does not have that, so I find it reasonable to believe that people are unaware of these changes, have not considered their implications, and possibly would object to them if they did. I can't even tell myself whether a note such as the one above accurately reflects what you mean to propose. I do not think it would be useful to continue the discussion between only the two of us, and I find your misrepresentation of my position most unhelpful. I do appreciate that you have now started to gather some information on what running code actually does, but let's have a look at your claims: Expat is a surprising case -- it provides a parameter which can be used to pass in a character encoding name, but it will ignore this if it detects a different encoding in its input byte-stream (tested via both the Perl and Python embeddings, and confirmed by examining the source). So in fact expat does explicitly to treat a BOM as authoritative. Well then let us examine the source: /* This is what detects the encoding. ... */ static int initScan(const ENCODING * const *encodingTable, ... case 0xEFBB: /* Maybe a UTF-8 BOM (EF BB BF) */ /* If there's an explicitly specified (external) encoding of ISO-8859-1 or some flavour of UTF-16 and this is an external text entity, don't look for the BOM, because it might be a legal data. */ What does that suggest about expat always looking for a BOM that overrides anything else? Or how about this claim: (I'm not ignoring your reminder that you have built an add-on to perl's HTML::Parser module which treats the charset as authoritative, but since that module does not qualify as a conformant XML parser in any case, it's not really relevant to 3023bis). The W3C Markup Validator uses my HTML::Encoding module to detect the character encoding of HTML and XHTML documents. XHTML documents use whatever rules there are for XML documents to detect the encoding. It is an implementation of "Given a HTTP response, what is the encoding of the XML document in it", which is what most of the draft is about. Inconsistent, ad-hoc, and changing character encoding detection rules have been a long-standing concern of mine and I have tried to reach out e.g. in http://www.unicode.org/mail-arch/unicode-ml/y2010-m10/0003.html to others to improve the situation. It is not too much to ask of the Applications Area Working Group to do the same. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From Peter.Rushforth@NRCan-RNCan.gc.ca Tue Nov 19 07:31:19 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3C61AE056 for ; Tue, 19 Nov 2013 07:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Clmw61c7xZP7 for ; Tue, 19 Nov 2013 07:31:16 -0800 (PST) Received: from nrcan.gc.ca (s-bsc-edge1.nrcan.gc.ca [132.156.238.13]) by ietfa.amsl.com (Postfix) with ESMTP id 651F11AE058 for ; Tue, 19 Nov 2013 07:31:16 -0800 (PST) Received: from S-BSC-CAS2.nrn.nrcan.gc.ca (132.156.238.12) by S-BSC-EDGE1.nrcan.gc.ca (132.156.238.13) with Microsoft SMTP Server (TLS) id 14.2.347.0; Tue, 19 Nov 2013 10:31:09 -0500 Received: from S-BSC-MBX1.nrn.nrcan.gc.ca ([169.254.1.249]) by S-BSC-CAS2.nrn.nrcan.gc.ca ([fe80::48d4:f168:78ba:d4e8%19]) with mapi id 14.02.0347.000; Tue, 19 Nov 2013 10:31:08 -0500 From: "Rushforth, Peter" To: "Henry S. Thompson" Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-05.txt Thread-Index: AQHO5SI0i8sAqD7AXE+GSf67lD/p1posmZfA Date: Tue, 19 Nov 2013 15:31:06 +0000 Message-ID: <1CD55F04538DEA4F85F3ADF7745464AF24AA1EA7@S-BSC-MBX1.nrn.nrcan.gc.ca> References: <20131119120919.12901.59046.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.156.238.22] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 15:31:19 -0000 Henry, I am not very familiar with BOM technology, so please excuse the beginner n= ature of this comment. In section 3.6, your use of the term "in-band" is not correct, I believe. = The band referred to is the communication channel. When that channel is HT= TP, the Content-Type and Accept header values *are* in-band. =20 I think the question is "which metadata is _more_ authoritative". I have r= ead on another (w3c) list the idea that the authoritativeness of metadata i= s inversely proportional to the square of the distance from the payload, wi= th the idea being that the payload is most authoritative. I disagree, to t= he extent that the payload is *not* _metadata_, but data. If a server tran= smits an image/png as image/jpeg, it is an error, in my opinion. So it sho= uld be for an incorrectly charset-characterized XML file. Otherwise, how w= ould a server operator/author ever know if he had a misconfigured server? HTTP stands for "HyperText" Transfer Protocol. In contrast to Martin's ass= ertion on another thread, the IETF HTTP protocol is based on hypertext, in = that it provides *textual* slots for substitution by clients. To the exten= t that a BOM is binary information, it is not a suitable slot for hypertext= substitution. =20 Do browsers provide the opportunity to *create* a BOM when transmitting XML= content? Browsers are less and less important conveyors of XML informatio= n these days. I have read that (for example) Chrome plans to remove the xm= l parser from its codebase. Browsers should therefore not be the implementa= tions chosen to prioritize how XML is registered for use on the web. =20 Sincerely, Peter Rushforth > -----Original Message----- > From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On=20 > Behalf Of Henry S. Thompson > Sent: November 19, 2013 07:23 > To: i-d-announce@ietf.org; apps-discuss@ietf.org > Subject: Re: [apps-discuss] I-D Action:=20 > draft-ietf-appsawg-xml-mediatypes-05.txt >=20 > internet-drafts writes: >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. This draft is a work item of the Applications Area=20 > > Working Group Working Group of the IETF. > > > > Title : XML Media Types > > Filename : draft-ietf-appsawg-xml-mediatypes-05.txt >=20 > As for previous drafts, an editors' diff is available, at >=20 > =20 > http://www.w3.org/XML/2012/10/3023bis/draft-ietf-appsawg-xml-m ediatypes-05_diff.html >=20 > This draft contains only very modest changes, which address=20 > all but one outstanding comment. >=20 > My reasoning for not changing 3.6 in response to Bjoern=20 > Hoehrmann's objection to the treatment of a BOM as=20 > authoritative even in the presence of a charset parameter [1]=20 > is set out in [2]. Martin Duerst (in another thread)=20 > summarises my reasoning, as follows: >=20 > What's most important now is to know what receivers actually > accept. We are not in a design phase, we are just updating the > definition ... and making sure we fix problems if there are > problems, but we have to use the installed base for the main > guidance >=20 > Given the wide review these drafts have received (thanks in=20 > particular to Julian Reschke and Erik Wilde), and the recent=20 > endorsement by the W3C XML Core WG [3], I hope we can move=20 > this back to WG Last Call, get an official review, and take=20 > it forward. >=20 > ht >=20 > [1]=20 > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg1 0810.html > [2]=20 > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg1 0883.html > [3]=20 > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg1 0849.html > --=20 > Henry S. Thompson, School of Informatics, University=20 > of Edinburgh > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44)=20 > 131 650-4440 > Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ =20 > [mail from me _always_ has a .sig like this -- mail without=20 > it is forged spam] _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > = From ht@inf.ed.ac.uk Tue Nov 19 09:42:50 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC981AE0EC for ; Tue, 19 Nov 2013 09:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pScIGC6RPbbF for ; Tue, 19 Nov 2013 09:42:46 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 656861AE0D4 for ; Tue, 19 Nov 2013 09:42:45 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rAJHgQGq012252; Tue, 19 Nov 2013 17:42:31 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAJHgO4f024651; Tue, 19 Nov 2013 17:42:24 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAJHgPrM014763; Tue, 19 Nov 2013 17:42:25 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rAJHgOXu014759; Tue, 19 Nov 2013 17:42:24 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Bjoern Hoehrmann References: <20131119120919.12901.59046.idtracker@ietfa.amsl.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 19 Nov 2013 17:42:24 +0000 In-Reply-To: (Bjoern Hoehrmann's message of "Tue\, 19 Nov 2013 16\:03\:00 +0100") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 17:42:50 -0000 Bjoern Hoehrmann writes: > * Henry S. Thompson wrote: >>My reasoning for not changing 3.6 in response to Bjoern Hoehrmann's >>objection to the treatment of a BOM as authoritative even in the >>presence of a charset parameter [1] is set out in [2]. > > I said that I think this is a serious and problematic change that needs > wide review prior to a two-week Last Call period and that the change is > fine by me provided there is evidence of wide review. It would be easy, > for instance, to ask on a set of mailing lists, say > > * ietf-charsets@iana.org > * www-international@w3.org > * unicode@unicode.org Happy to email them, thanks for the suggestion. > for endorsements for one part of the proposal which would require XML > implementations to treat > > data:application/xml;charset=utf-32,%FF%FE%00%00... > as malformed UTF-16 encoded document Not so. Did you see my earlier message [2]? Both XML and UNICODE documentation identify FF FE 00 00 as a UTF-32 BOM. >From F.1 of XML: With a Byte Order Mark: 00 00 FE FF UCS-4, big-endian machine (1234 order) FF FE 00 00 UCS-4, little-endian machine (4321 order) > and if the question is not mis- leading and there are endorsements > by qualified individuals then I'd be satisfied that this part of the > proposal has received adequate review. You could also point me to > messages in archive of this list where such individuals have > provided rationale for their support of this change. > > I note that the "Changes from RFC 3023" appendix of the document does > not mention the changes in question and you need to have a good grasp > of the issues to notice them when carefully reading the document. Thanks, good suggestion. > If the document had carefully explained the changes where > appropriate, for instance, for the issue above, which is just one > among several, e.g. > > NOTE: While appendix F.1 of the XML 1.0 Recommendation suggests that > an initial byte sequence of FF FE 00 00 is indicative of the UTF-32 > character encoding, the rules of this specification require such a > sequence to be interpreted as a UTF-16 Byte Order Mark followed by a > U+0000 character rendering the document malformed. I still don't understand where you're seeing this in the spec. Certainly not my intention. Would it help to add a para. about UCS-4 to section 4, referring to Unicode 6.2 and/or XML appendix F.1 for signature detection? > I do not think it would be useful to continue the discussion between > only the two of us, and I find your misrepresentation of my position > most unhelpful. No intentional misrepresentation, I assure you. See subsequent message for low-level discussion of our disagreement about expat, which those who don't care about such things are welcome to skip. > (I'm not ignoring your reminder that you have built an add-on to > perl's HTML::Parser module which treats the charset as authoritative, > but since that module does not qualify as a conformant XML parser in > any case, it's not really relevant to 3023bis). > > The W3C Markup Validator uses my HTML::Encoding module to detect the > character encoding of HTML and XHTML documents. XHTML documents use > whatever rules there are for XML documents to detect the encoding. It > is an implementation of "Given a HTTP response, what is the encoding > of the XML document in it", which is what most of the draft is about. Ah, I only looked at the documentation associated with HTML::Encoding when I installed it. So, yes, along with xmllint, this would have to change if the spec is published as it now stands. > Inconsistent, ad-hoc, and changing character encoding detection rules > have been a long-standing concern of mine and I have tried to reach out > e.g. in http://www.unicode.org/mail-arch/unicode-ml/y2010-m10/0003.html > to others to improve the situation. It is not too much to ask of the > Applications Area Working Group to do the same. I absolutely agree -- increasing interoperability in this space is obviously of great importance. Given the wide disparity among available implementations, what I've proposed not only endorses the existing majority among implementations so far as I can see but also is simple to understand, explain and implement. I'll draft a proposed message to the above lists tomorrow and send it to you for review. ht [1] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10810.html [2] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10883.html -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From ht@inf.ed.ac.uk Tue Nov 19 09:44:46 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D661AE118 for ; Tue, 19 Nov 2013 09:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPwuUThyEy3h for ; Tue, 19 Nov 2013 09:44:44 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 368E91AE111 for ; Tue, 19 Nov 2013 09:44:44 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rAJHib7S012839; Tue, 19 Nov 2013 17:44:37 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAJHiZ4i024692; Tue, 19 Nov 2013 17:44:35 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAJHiaAe014817; Tue, 19 Nov 2013 17:44:36 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rAJHia9F014813; Tue, 19 Nov 2013 17:44:36 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Bjoern Hoehrmann References: <20131119120919.12901.59046.idtracker@ietfa.amsl.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 19 Nov 2013 17:44:36 +0000 In-Reply-To: (Bjoern Hoehrmann's message of "Tue\, 19 Nov 2013 16\:03\:00 +0100") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: apps-discuss@ietf.org Subject: [apps-discuss] expat and the BOM (was Re: I-D Action: draft-ietf-appsawg-xml-mediatypes-05.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 17:44:46 -0000 Bjoern Hoehrmann writes: > I do appreciate that you have now started to gather some information > on what running code actually does, but let's have a look at your > claims: > > Expat is a surprising case -- it provides a parameter which can be > used to pass in a character encoding name, but it will ignore this if > it detects a different encoding in its input byte-stream (tested via > both the Perl and Python embeddings, and confirmed by examining the > source). So in fact expat does explicitly to treat a BOM as > authoritative. > > Well then let us examine the source: > > /* This is what detects the encoding. ... > */ >=20=20=20 > static int > initScan(const ENCODING * const *encodingTable,=20 > ... > case 0xEFBB: > /* Maybe a UTF-8 BOM (EF BB BF) */ > /* If there's an explicitly specified (external) encoding > of ISO-8859-1 or some flavour of UTF-16 > and this is an external text entity, > don't look for the BOM, > because it might be a legal data. > */ Look further down, and you will see that the actual code which follows is if (state =3D=3D XML_CONTENT_STATE) { int e =3D INIT_ENC_INDEX(enc); if (e =3D=3D ISO_8859_1_ENC || e =3D=3D UTF_16BE_ENC || e =3D=3D UTF_16LE_ENC || e =3D=3D UTF_16_ENC) break; } At the beginning of documents, state !=3D XML_CONTENT_STATE, so the UTF-8 BOM is only ignored for external entities, not for documents as such. It seems to me that treating documents and external entities differently is explicitly contrary to the XML specification, which clearly states: "If the replacement text of an external entity is to begin with the character U+FEFF, and no text declaration is present, then a Byte Order Mark MUST be present, whether the entity is encoded in UTF-8 or UTF-16." Looking further up, we see case 0xFEFF: if (INIT_ENC_INDEX(enc) =3D=3D ISO_8859_1_ENC && state =3D=3D XML_CONTENT_STATE) break; i.e. that UTF-16 BOMs are only ignored if a) you're looking at an external entity and b) [some encoding] is ISO_8859_1_ENC [some encoding] -- I spent an hour trying to figure out what encoding the parser for external entities is passed and how to affect it so as to cause the 'break' above to happen in a way that would cause an error if the external entity has a UTF-8 or UTF-16 BOM, but I couldn't. I invite people to retrieve [3]--[6] and see if you can provoke an error by any form of invocation of expat 2.1.0. I have not been able to -- for example > xmlwf -m -d /tmp -e ISO-8859-1 -x wrap-local-b8.xml perfectly happily produces

C=E2=80=99=C3=A9st domage

=20=20 despite the external entity beginning with a UTF-8 BOM. > What does that suggest about expat always looking for a BOM that > overrides anything else?: As just noted, in practice, it seems that it does -- for reasons I understand for top-level documents, and reasons I don't understand for external entities. Of course expat will never manage to process a UTF-32-encoded document with or without a BOM or correct charset, because expat doesn't implement UTF-32 _at all_, but that's a separate issue, surely. ht [3] http://www.ltg.ed.ac.uk/~ht/ov-test/wrap-local-b16le.xml [4] http://www.ltg.ed.ac.uk/~ht/ov-test/wrap-local-b8.xml [5] http://www.ltg.ed.ac.uk/~ht/ov-test/b16le.xml [6] http://www.ltg.ed.ac.uk/~ht/ov-test/b8.xml --=20 Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged s= pam] From joelja@bogus.com Tue Nov 19 18:20:51 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1D91AE2D7; Tue, 19 Nov 2013 18:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSIyo3p_s2d8; Tue, 19 Nov 2013 18:20:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9441AE2D2; Tue, 19 Nov 2013 18:20:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Joel Jaeggli" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131120022049.13902.55873.idtracker@ietfa.amsl.com> Date: Tue, 19 Nov 2013 18:20:49 -0800 Cc: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-malformed-mail@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org Subject: [apps-discuss] Joel Jaeggli's No Objection on draft-ietf-appsawg-malformed-mail-10: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 02:20:51 -0000 Joel Jaeggli has entered the following ballot position for draft-ietf-appsawg-malformed-mail-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-malformed-mail/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 10 appears to have addressed many of the ops reviewers concerns. Thanks! From internet-drafts@ietf.org Wed Nov 20 00:00:28 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733421AE39B; Wed, 20 Nov 2013 00:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPrmeDjV5RUg; Wed, 20 Nov 2013 00:00:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 450601AE39A; Wed, 20 Nov 2013 00:00:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131120080026.25156.23231.idtracker@ietfa.amsl.com> Date: Wed, 20 Nov 2013 00:00:26 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 08:00:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : The Require-Recipient-Valid-Since Header Field and SMTP = Service Extension Author(s) : William J. Mills Murray S. Kucherawy Filename : draft-ietf-appsawg-rrvs-header-field-04.txt Pages : 20 Date : 2013-11-19 Abstract: This document defines an extension for the Simple Mail Transfer Protocol called RRVS, and a header field called Require-Recipient- Valid-Since, to provide a method for senders to indicate to receivers the time when the sender last confirmed the ownership of the target mailbox. This can be used to detect changes of mailbox ownership, and thus prevent mail from being delivered to the wrong party. The intended use of these facilities is on automatically generated messages that might contain sensitive information, though it may also be useful in other applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-rrvs-header-field There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-rrvs-header-field-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-rrvs-header-field-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From superuser@gmail.com Wed Nov 20 00:03:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCBC1AC7F2 for ; Wed, 20 Nov 2013 00:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esAFTAkZScSv for ; Wed, 20 Nov 2013 00:03:01 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2139A1AC7EE for ; Wed, 20 Nov 2013 00:03:00 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id fb10so6638814wid.12 for ; Wed, 20 Nov 2013 00:02:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=vsi65GRCrKbncb+euVaLZk5ZU46rtVy2KRUwB9sgMbw=; b=GkabpszSJuDROHSX72WHd5nkxhqijwDtEMfE6GXuKkYyQBcA9kzwhW/wIGAuA2dWQF f1YWpJHNnN2FAR2BdgEjRF7QTQumOp3pnIwtnnYqOOJWejHrr2sydDIIGDqvBM1IqW4h G0XKChrHf8hiQuv0wVgpKLEHCCkcGEIeBFPYsCykd9Zk8eA0p4EZ6wy44VN+0+ic1no4 PghbS4HFmhsyJWgT4iYzFv3y75Frma7m1D/Pi3lARsB48axPSQoGKXXhgkuq3WlRuGug U9dk7d1hG/9VK7WHRuBKp4dwJLe/51VijjkrrbQE0ShTk353nRUY+3poP6G6nDCYHJsK jZDQ== MIME-Version: 1.0 X-Received: by 10.180.79.230 with SMTP id m6mr69021wix.19.1384934574412; Wed, 20 Nov 2013 00:02:54 -0800 (PST) Received: by 10.181.13.230 with HTTP; Wed, 20 Nov 2013 00:02:54 -0800 (PST) In-Reply-To: <20131120080026.25156.23231.idtracker@ietfa.amsl.com> References: <20131120080026.25156.23231.idtracker@ietfa.amsl.com> Date: Wed, 20 Nov 2013 00:02:54 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d0444037858598e04eb9735b2 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 08:03:03 -0000 --f46d0444037858598e04eb9735b2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 20, 2013 at 12:00 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Applications Area Working Group Working > Group of the IETF. > > Title : The Require-Recipient-Valid-Since Header Field > and SMTP Service Extension > Author(s) : William J. Mills > Murray S. Kucherawy > Filename : draft-ietf-appsawg-rrvs-header-field-04.txt > Pages : 20 > Date : 2013-11-19 > > Abstract: > This document defines an extension for the Simple Mail Transfer > Protocol called RRVS, and a header field called Require-Recipient- > Valid-Since, to provide a method for senders to indicate to receivers > the time when the sender last confirmed the ownership of the target > mailbox. This can be used to detect changes of mailbox ownership, > and thus prevent mail from being delivered to the wrong party. > > The intended use of these facilities is on automatically generated > messages that might contain sensitive information, though it may also > be useful in other applications. > > Incorporates a lot of suggestions from Ned, Alexey, and John. Diff available from the datatracker. Have at it! -MSK --f46d0444037858598e04eb9735b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 20, 2013 at 12:00 AM, <<= a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blank">internet-draft= s@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Applications Area Working Group Working= Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : The Require-Recipient-Valid-Sin= ce Header Field and SMTP Service Extension
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : William J. Mills
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Murray S. Kucherawy
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-rrvs-header-fi= eld-04.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 20
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-11-19

Abstract:
=A0 =A0This document defines an extension for the Simple Mail Transfer
=A0 =A0Protocol called RRVS, and a header field called Require-Recipient- =A0 =A0Valid-Since, to provide a method for senders to indicate to receiver= s
=A0 =A0the time when the sender last confirmed the ownership of the target<= br> =A0 =A0mailbox. =A0This can be used to detect changes of mailbox ownership,=
=A0 =A0and thus prevent mail from being delivered to the wrong party.

=A0 =A0The intended use of these facilities is on automatically generated =A0 =A0messages that might contain sensitive information, though it may als= o
=A0 =A0be useful in other applications.


Incorporates a lot of suggestions from= Ned, Alexey, and John.=A0 Diff available from the datatracker.=A0 Have at = it!

-MSK

--f46d0444037858598e04eb9735b2-- From duerst@it.aoyama.ac.jp Wed Nov 20 03:08:37 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AA81ADBCB for ; Wed, 20 Nov 2013 03:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.316 X-Spam-Level: X-Spam-Status: No, score=-1.316 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPTrkY1Ueben for ; Wed, 20 Nov 2013 03:08:34 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id C60961ADBC9 for ; Wed, 20 Nov 2013 03:08:32 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rAKB8NwF017902; Wed, 20 Nov 2013 20:08:24 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 28e5_6439_12318db0_51d4_11e3_8778_001e6722eec2; Wed, 20 Nov 2013 20:08:22 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 51B2EBF4CD; Wed, 20 Nov 2013 20:08:22 +0900 (JST) Message-ID: <528C980D.7070106@it.aoyama.ac.jp> Date: Wed, 20 Nov 2013 20:07:57 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Henry S. Thompson" References: <20131119120919.12901.59046.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 11:08:37 -0000 Hello Henry, others, I'm sorry this is very late, but I managed to review most of the -04 draft. I checked -05, so the comments below apply to -05. First, let me say that my comments in the first review (months ago, mostly against closely interleaving spec parts and historical notes) have been addressed very well. This time, the comments are much more on details. Copyright notice: Given the long history of this draft, I'd guess that this document needs the following addition in the copyright: >>>> This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. >>>> (This can easily be produced with a setting on some attribute in the XML source.) Section 3 and Section 8: These sections have more than a page of text before the first subsection. I suggest to add one or more additional subsection titles at the start or very close to the start of the section for better structuring. Section 3 says: >>>> document entities The media types application/xml or text/xml MAY be used. >>>> First, it would be good to have some syntactic delimiter (colon maybe) between "document entities" and the rest. Same for the other items. Second, RFC 2119 defines MAY as follows: "This word, or the adjective "OPTIONAL", mean that an item is truly optional." This is quite a bit misleading in the sentence above. Using application/xml or text/xml for XML document entities is the default case, not just an optional option. I suggest something like "The media types application/xml or text/xml, or a more specific media type, SHOULD be used." (A should without additional qualification is probably too strong.) >>>> external parsed entities The media types application/xml-external- parsed-entity or text/xml-external-parsed-entity SHOULD be used. The media types application/xml and text/xml MUST NOT be used unless the parsed entities are also well-formed "document entities" and are referenced as such. >>>> The last clause ("and are referenced as such") is confusing. Stuff is just served or sent; on the server side, it's unclear how it's being referenced, and so such a condition does not make sense operationally. Note starting with: >>>> Note that [RFC3023] (which this specification obsoletes) recommended the use of text/xml and text/xml-external-parsed- entity for document entities and external parsed entities, >>>> Because of the indenting, it looks as if this note only applies to the immediately preceding item ("external parameter entities"), but content-wise, it seems to apply more generally. The note should be outdented (if that's possible) or should be moved to another place where it's less confusing to the reader as to what it applies to. Para starting with: >>> Compared to [RFC2376] or [RFC3023], this specification alters the charset handling of text/xml and text/xml-external-parsed-entity, >>> This is very long, in particular the first sentence. A very easy first step towards improvement would be to use a period before the "however", and change "however" to "However". Any additional untangling would be appreciated, too. Also, "for the text/xml... types" should be changed to "for types with a top-level media type text". (several instances) Last paragraph before Section 3.1: It was unclear what exactly the spec tried to say here. I suggest to add a sentence at the end, e.g. "Such processing is not specified in this document." Section 3.1, Encoding considerations (and elsewhere): The term "charset encoding" shows up. This is an unfortunate mixture of terminology. MIME has the "charset" parameter, and XML has the "encoding" pseudo-attribute, but this doesn't mean that these two words should be combined just like this. Also, this isn't used uniformly through the spec, e.g. there are things like "ASCII-compatible character sets" (see also http://www.w3.org/MarkUp/html-spec/charset-harmful.html). I suggest, in Section 2, to shortly talk about the fact that MIME has the "charset" parameter, and XML has the "encoding" pseudo-attribute, and then use a single term. I'd personally suggest "character encoding" (see e.g. RFC 3986), but I'd be happy with any term that has been used widely already. Also, we have "7bit or 8bit data, for example data with charset encoding UTF-8 or US-ASCII". In general speach, a chiasmus is something nice, but it's generally only confusing in specs, so I'd change this to "7bit or 8bit data, for example data with charset encoding US-ASCII or UTF-8". Section 3.1, Applications that use this media type: There is a missing "and" but a superfluous comma : "is supported by a wide range of generic XML tools (editors, parsers, Web agents, ...)*,* *and* generic and task-specific applications." Probably, reordering makes this easier to read: "is supported by generic and task-specific applications and a wide range of generic XML tools (editors, parsers, Web agents, ...)." Section 3.2: Text/xml Registration This is defined as an "alias", but the Media Type registry (e.g. in contrast to the charset registry) doesn't know the concept of an alias. So this should be reworded, e.g. saying that the registration information is the same. This also applies to Section 3.4. Section 3.3, Encoding considerations (and other items): There are two "as" prepositions in short succession. What about "Same as application/xml, see Section 3.1." or some such? Section 3.3, Interoperability considerations: >>>> Identifying XML external parsed entities with their own content type should enhance interoperability of both XML documents and XML external parsed entities. >>>> Lowercase "should" SHOULD be avoided! (there are other cases, too) I suggest to change to "will", or just say "enhances". Section 3.6: >>>> XML MIME producers are RECOMMENDED to provide means for XML MIME entity authors to control the supply of charset parameters for their entities, for example by enabling user-level configuration of filename-to-Content-Type-header mappings on a file-by-file or suffix basis. >>>> "control the supply" reads as if these charset parameters were in ample or short supply. I suggest to replace "supply" with "presence" or "presence or absence". Section 3.6: It may be helpful to create (sub)subsections for producers and consumers, because that's what many readers of the spec will look for. Section 3.6, para starting with (and the following citation and para): >>>> When a charset parameter is specified for an XML MIME entity, then >>>> This is way too lengthy and complicated. The first sentence is almost six lines long. This is another case of mixing history and justification with the hard facts, and should be untangled. "Section 4.3.3 of the [XML] specification": Please fix this to "Section 4.3.3 of [XML]" (as in other locations) or "Section 4.3.3 of the XML specification [XML]". "When MIME producers conform to the requirements on them stated above," "on them" is redundant and should be removed. Section 4: I'm not sure why this is a separate section, as the content is tightly related to Section 3.6. At the minimum, I suggest moving the stuff about BOMs from 3.6 to 4. A better solution would be to promote 3.6 to a section, and include the current section 4 in there (with appropriate additional subsections as suggested above). >>>> byte order mark (BOM), which is a hexadecimal octet sequence 0xFE 0xFF (or 0xFF 0xFE, depending on endianness) >>>> A byte order mark is a character, not an octet sequence. Also, better say which endianness is which. This would result in >>>> byte order mark (BOM), which appears as the hexadecimal octet sequence 0xFE 0xFF (big-endian) or 0xFF 0xFE (little-endian) >>>> The change from "is" to "appears as" is also needed for UTF-8. >>>> Applications which convert XML into "utf-8" SHOULD add a BOM after conversion is complete. >>>> There are two problems there: 1) "after conversion is complete", if taken literally, would lead to very efficient implementations (adding three bytes at the start of a long file). This clause should therefore be removed. 2) There is absolutely no need for a SHOULD. SHOULDs are only used when otherwise, there are interoperability problems, but XML in UTF-8 without a BOM 'should' not have any such problems. MAY seems much more appropriate here. Section 5: "IRI" is mentioned without a reference. The reference was dropped between -04 and -05 because it looked as if it wasn't needed, but it should be put back in (with "Dueerst" fixed to "Duerst"). >>>> A registry of XPointer schemes [XPtrReg] is maintained at the W3C. Document authors SHOULD NOT use unregistered schemes. Scheme authors SHOULD register their schemes ([XPtrRegPolicy] describes requirements and procedures for doing so). >>>> I fully agree with the SHOULDs here, but they don't belong in this spec. >>>> When a URI has a fragment identifier, it is encoded by a limited subset of the repertoire of US-ASCII [ASCII] characters, as defined in [RFC3986]. >>>> I'm not sure what this helps here. A pointer to the relevant parts of the XPointer spec(s) would be better, because some issues with respect to XPointer encoding in URIs (and IRIs) can be rather tricky. Section 6: Again very complicated language. I'd shorten the background information drastically, e.g. as follows (replacing the first *two* paragraphs of Section 6): >>>> An XML MIME entity of type application/xml, text/xml, application/xml-external-parsed-entity or text/xml-external-parsed-entity MAY use the xml:base attribute, as described in [XMLBase], to establish a base URI for that entity (see Section 5.1 of [RFC3986]). >>>> Section 8: A Naming Convention... I suggest removing the "a". In RFC 3023, this was in many ways just a trial, and so "a" was appropriate. Today, this doesn't have to be stressed anymore, and there are no other naming conventions for XML-Based Media Types. "pattern '*/*+xml'": This is shell notation applied to something else than file names. It's close to the syntax allowed in an HTTP Accept: header, but (as correctly noted in the draft) not the same. It should be obvious to many readers, but it would be better if it were clearly explained. >>>> When an XML-based media type is restricted to UTF-8, it is not necessary to introduce the charset parameter. "UTF-8 only" is a generic principle and UTF-8 is the default of XML. >>>> I'm not sure what ""UTF-8 only" is a generic principle" is referring to. I guess it refers to the idea that using UTF-8 only for certain use cases on the Internet simplifies things a lot and is therefore a good idea. I fully agree. But a) this should be clearer, and b) it should be separated from "UTF-8 is the default of XML", because the former is a justification for the antecedent of the previous sentence (which I don't think is actually necessary), whereas the later is a justification for the conclusion made in that sentence. So in order of decreasing preference: 1) Remove ""UTF-8 only" is a generic principle and" 2) Split the second sentence into two, explaining the "generic principle" in slightly more detail. "Similarly, media subtypes that do not represent XML MIME...": I don't see any similarity to what comes before. If a connective is really needed, I'd use "Conversely", but the best solution would be to do without connectives altogether. 8.1: "Referencing": Please use a slightly longer subsection title to make it easier for readers to understand what this subsection is talking about. Maybe "Registration Template Details"? "Registrations for new XML-based media types under top-level types" Please remove "under top-level types". It doesn't add any information. 8.2, Reference: Replaces "This specification" with "RFC XXXX". This makes the template more portable. There are more occasions that would benefit from the same change. 8.2, Fragment identifier considerations: The two provisions "they MAY restrict the syntax to a specified subset of schemes" and "They MAY further require support for other registered schemes" look okay, but they leave open the question of what's the default. As far as I understand, barenames and element scheme pointers are the (bare :-) minimum, and so the first provision seems unnecessary. Removing that provision (and removing the "further" in the second provision) should make it clear that the minimum is the default. >>>> For fragment identifiers matching the syntax defined in [XPointerFramework], where the fragment identifier does _not_ resolve per the rules specified there, then process as specified in "xxx/yyy+xml"; >>>> Is this the case of an unregistered XPointer scheme? If yes, it would be good to mention here (not with MUSTard) that this is a bad idea. If not, I don't understand what case this addresses. Section 9: The last para before subsection 9.1 should be moved to the start of this section. >>>> the charset portion, if any, of the value of the MIME Content-type header >>>> I'd prefer to keep the full Content-type header, as in the examples in RFC 3023. Why? I think something like Content-type: application/xml; charset="UTF-8" is easier to read than Content-type charset: charset="UTF-8" Either this can use different types in the different examples, or use application/xml throughout. I'd personally prefer the later. >>>> and the XML MIME entity may contain other data in addition to the XML declaration; >>>> The 'may' here is misleading a) because lower-case 'may' SHOULD be avoided and b) because (except for an XML declaration) there 'may' indeed be no data, but that would be exceedingly rare. So I would change this to something like "and the XML MIME entity will contain other data in addition to the XML declaration (or might be empty);", where the parenthetical in my opinion isn't even necessary. Section 9.1: Why is there no , similar to 9.2? Why are there no cases without any XML declaration (difficult to represent in the current way but very realistic)? >>>> If sent using a 7-bit transport (e.g., SMTP[RFC0821]), the XML MIME entity MUST use a content-transfer-encoding of either quoted- printable or base64. >>>> I may be wrong here, but in my understanding, it would be possible to send pure US-ASCII labeled as UTF-8 through 7-bit transport (i.e. what defines the transport is the actual data and not the potential bit patterns allowed by the charset). Section 9.1 and 9.2: The 7-bit/8-bit/binary considerations repeat what's already said in 3.1, so they should be replaced with a pointer to that section. 9.3: The title includes "and 8-bit MIME entity", but the considerations apply equally well e.g. to encoding="iso-2022-jp", which is 7-bit. 9.5: This is lengthy. Remove "and UTF-8 Entity" from the title, and simply say that this is interpreted as UTF-8 because that's the default for XML. 9.6 "Observe that the BOM does not exist." -> "Observe that the BOM isn't present." or "Observe that there is no BOM." (the BOM exists as well as any other character :-) That's as far as I got. More maybe over the weekend or next week, sorry. Regards, Martin. On 2013/11/19 21:23, Henry S. Thompson wrote: > internet-drafts writes: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Applications Area >> Working Group Working Group of the IETF. >> >> Title : XML Media Types >> Filename : draft-ietf-appsawg-xml-mediatypes-05.txt > > As for previous drafts, an editors' diff is available, at > > http://www.w3.org/XML/2012/10/3023bis/draft-ietf-appsawg-xml-mediatypes-05_diff.html > > This draft contains only very modest changes, which address all but > one outstanding comment. > > My reasoning for not changing 3.6 in response to Bjoern Hoehrmann's > objection to the treatment of a BOM as authoritative even in the > presence of a charset parameter [1] is set out in [2]. Martin Duerst > (in another thread) summarises my reasoning, as follows: > > What's most important now is to know what receivers actually > accept. We are not in a design phase, we are just updating the > definition ... and making sure we fix problems if there are > problems, but we have to use the installed base for the main > guidance > > Given the wide review these drafts have received (thanks in particular > to Julian Reschke and Erik Wilde), and the recent endorsement by the > W3C XML Core WG [3], I hope we can move this back to WG Last Call, get > an official review, and take it forward. > > ht > > [1] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10810.html > [2] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10883.html > [3] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10849.html From presnick@qti.qualcomm.com Wed Nov 20 14:35:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCA41AE148; Wed, 20 Nov 2013 14:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOUQCi5GXtB8; Wed, 20 Nov 2013 14:35:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E635D1AE078; Wed, 20 Nov 2013 14:35:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131120223533.8958.23858.idtracker@ietfa.amsl.com> Date: Wed, 20 Nov 2013 14:35:33 -0800 Cc: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-malformed-mail@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org Subject: [apps-discuss] Pete Resnick's Yes on draft-ietf-appsawg-malformed-mail-10: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 22:35:35 -0000 Pete Resnick has entered the following ballot position for draft-ietf-appsawg-malformed-mail-10: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-malformed-mail/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Nothing that would stop me from endorsing this document going forward, but please do take the following into consideration: 1.1 - The 5th paragraph seems redundant with previous paragraphs in this section. The last paragraph seems redundant with section 1.2. Suggest striking. 4 - It seems worth pointing out somewhere in this section that the prepending of Received fields is the safest thing to do if changes must be made to the message to pass information between modules. 7.1 - "A message using an obsolete header syntax" You might consider adding a direct reference to 5322 section 4 to define what's meant by "obsolete". 7.1.6 - Why is the second example not obviously better? I have a hard time imagining circumstances where an unterminated quoted-string that contains an angle-bracketed thing that looks like an addr-spec is in fact a local part. 7.4 - "acceptance grammar" is a weird construction, not used in 5322. Suggest "obsolete syntax" (with the reference to section 4) instead. 7.5 - Third paragraph: Reference to DKIM would be useful. Fourth paragraph: I find the word "enacted" a bit weird. I suggest changing "can be enacted" to "can be used" or "strategies can be used" What's the difference between 3 & 4? Or maybe I don't know what "compound instance" means in 3. 7.5.3 - What's the harm in more than one Return-Path? Only one of interest is the top-most. --- Finally, a gedankenexperiment, or maybe fodder for a real experiment: What would happen if, upon receiving a malformed message that was determined to not be otherwise malicious, a receiving SMTP system both returned a 5xx to the message *and* processed and delivered the message (i.e., give the receiver what they want, but push back on folks who generate crap)? Would it help? (I am not asking for a discussion of this in the document. Just an interesting thought.) From turners@ieca.com Wed Nov 20 17:40:38 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81ECE1AD94A; Wed, 20 Nov 2013 17:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YkTwgub56rj; Wed, 20 Nov 2013 17:40:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 389231ADBCF; Wed, 20 Nov 2013 17:40:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Sean Turner" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131121014037.8958.98759.idtracker@ietfa.amsl.com> Date: Wed, 20 Nov 2013 17:40:37 -0800 Cc: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-malformed-mail@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org Subject: [apps-discuss] Sean Turner's No Objection on draft-ietf-appsawg-malformed-mail-10: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 01:40:38 -0000 Sean Turner has entered the following ballot position for draft-ietf-appsawg-malformed-mail-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-malformed-mail/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I quickly skimmed this draft and it looks fine to me. I'm balloting no objection, but I'm sure it would have been a YES had I had more time to review it - my fault mind you. From turners@ieca.com Wed Nov 20 17:40:44 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999B01ADEC4; Wed, 20 Nov 2013 17:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuB2tvvQKGW3; Wed, 20 Nov 2013 17:40:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CE81ADEB7; Wed, 20 Nov 2013 17:40:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Sean Turner" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131121014043.9013.22068.idtracker@ietfa.amsl.com> Date: Wed, 20 Nov 2013 17:40:43 -0800 Cc: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-malformed-mail@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org Subject: [apps-discuss] Sean Turner's No Objection on draft-ietf-appsawg-malformed-mail-10: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 01:40:45 -0000 Sean Turner has entered the following ballot position for draft-ietf-appsawg-malformed-mail-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-malformed-mail/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I quickly skimmed this draft and it looks fine to me. I'm balloting no objection, but I'm sure it would have been a YES had I had more time to review it - my fault mind you. From prvs=003088068a=johnl@iecc.com Wed Nov 20 18:29:30 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1CB1ADFC8 for ; Wed, 20 Nov 2013 18:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qPOXh0IlJKS for ; Wed, 20 Nov 2013 18:29:28 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id A7F6D1ADFC5 for ; Wed, 20 Nov 2013 18:29:27 -0800 (PST) Received: (qmail 72075 invoked from network); 21 Nov 2013 02:29:19 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 21 Nov 2013 02:29:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=528d6fff.xn--hew.k1310; i=johnl@user.iecc.com; bh=BG22KoNNli81GcoM/t3HIHxt+wq7hfZ5vQdlYqRFcsk=; b=vWKKv0whz55X8iGZ7R4dxpaoa8WzaeIdPqQgX6H6dKGfuzAR4trK4ccO+Vw2QibcDUHKMRGNfRXEUUC9ZlcwjjJ9MXQ5ECbRatOSJoGeQ/R8KtAn0uEuK5oYWurICmzDKxkIOtHA+IMPSETaf3FRhSHq92CGM09DLyb9LpBAmG+E7pIzdl7mHN1lwa/ISusWYvQjejFA4O4fFdUjeTKnlcOa3ttcNC31oPFdqaJIoqDV1EHcWIkYrOWItG5S6k0/ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=528d6fff.xn--hew.k1310; olt=johnl@user.iecc.com; bh=BG22KoNNli81GcoM/t3HIHxt+wq7hfZ5vQdlYqRFcsk=; b=s7n520wo+TdLavrESK6OCuruPynjjx75prn/U7UH+2UPiwbiVIzDHrrUIBaxyPeYdk9V92gtRRJfoiMykc/hNbuhdcVJJCnk+0tWViAvP0Abiz3o6B0uyBXJByuVZoMOM4KHwzXaZhqwSooSHeRNF0z6vLpjbKEEE6poFn22TW/RJ3MB59SAkjrvZge+2x2B8fS4c9Aa6dui2gZRwLNdWWPOl3cWfqm6UKW3w9KQ2Rg6R2czsYKjGZMwejnf95S8 Date: 21 Nov 2013 02:28:57 -0000 Message-ID: <20131121022857.30004.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <20131120223533.8958.23858.idtracker@ietfa.amsl.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: presnick@qti.qualcomm.com Subject: Re: [apps-discuss] reject and process, was Pete Resnick's Yes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 02:29:30 -0000 >What would happen if, upon receiving a malformed message that was >determined to not be otherwise malicious, a receiving SMTP system both >returned a 5xx to the message *and* processed and delivered the message >(i.e., give the receiver what they want, but push back on folks who >generate crap)? Would it help? I've been doing reject and process on my spamtraps for years. It doesn't seem to have broken anything, but it also doesn't seem that anyone's taken the hint. R's, John From stephen.farrell@cs.tcd.ie Thu Nov 21 04:17:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998F21AE0D8; Thu, 21 Nov 2013 04:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5GEbhDd-UwY; Thu, 21 Nov 2013 04:17:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCF11ADBD4; Thu, 21 Nov 2013 04:17:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131121121728.12108.46847.idtracker@ietfa.amsl.com> Date: Thu, 21 Nov 2013 04:17:28 -0800 Cc: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-malformed-mail@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org Subject: [apps-discuss] Stephen Farrell's Yes on draft-ietf-appsawg-malformed-mail-10: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 12:17:29 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-appsawg-malformed-mail-10: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-appsawg-malformed-mail/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for a useful document. I would have loved to have seen text about S/MIME and PGP issues, but I guess that might require another equally long document all by itself. It might well be worth looking though to see if there's a reference to which you could point that has relevant guidance about those. = Separately, it might also be worth pointing out that some of the handling guidance you give if applied to some S/MIME or PGP messages is likely to break signatures or make decryption impossible. But those are just suggestions to take or leave, this is already useful enough as-is. From jari.arkko@piuha.net Thu Nov 21 05:33:09 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202551AE153; Thu, 21 Nov 2013 05:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ke0e2tqE7rjg; Thu, 21 Nov 2013 05:33:07 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0CA1ADF64; Thu, 21 Nov 2013 05:33:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4649C2CC6C; Thu, 21 Nov 2013 15:33:00 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xXghOTXxpT3; Thu, 21 Nov 2013 15:32:58 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 00C2A2CC48; Thu, 21 Nov 2013 15:32:51 +0200 (EET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jari Arkko In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026AAEC0AC@MX15A.corp.emc.com> Date: Thu, 21 Nov 2013 10:32:49 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8D3D17ACE214DC429325B2B98F3AE712026AAEC0AC@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1510) Cc: "ned.freed@mrochek.com" , "ietf@ietf.org" , "apps-discuss@ietf.org" , "General Area Review Team \(gen-art@ietf.org\)" , "gshapiro@proofpoint.com" , "Barry Leiba \(barryleiba@computer.org\)" Subject: Re: [apps-discuss] [Gen-art] Gen-ART review of draft-ietf-appsawg-malformed-mail-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 13:33:09 -0000 On Nov 7, 2013, at 12:04 AM, "Black, David" wrote: > The -10 version of this draft responds to all of the nits/editorial = comments > noted in the Gen-ART review of the -09 version. Thank you for the review & the fixes! Jari From superuser@gmail.com Thu Nov 21 06:17:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17AED1AE17D; Thu, 21 Nov 2013 06:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rleegq-07u79; Thu, 21 Nov 2013 06:17:01 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5F01AE16F; Thu, 21 Nov 2013 06:17:01 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id x12so797966wgg.28 for ; Thu, 21 Nov 2013 06:16:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lS7OC0dDQrl/GkTF++biafOUeBZ6EMkn3aAtd6IEehI=; b=sG/VZ8UwZ/VIigj4S6vUE2w/RuEQ6IsF2XUahBwEYF3pqFnx1X5YcjpwEmwOe8xI3P YmzHQgQYJeDd5pxOu6OKwfVctKlx0Q/Cc4Cxkb8bFtnvIoaiEuU+rNgQ0xppP8q2mEcE 5AD/3gxOja0wxKBxf5FQmpWBG8ZtBeXpgN5sSOybFQcmVr0WWxjMN5OiWsLp8xP3lfNF khhH9XKIjitRINo0eaG7losuz8BJCwo5ag9cRyuD8Jjrf07PZPCcvm2qM2zBbWqMx6Tb Ba4WzSNtOqO16BxyjITPJ8sukzjpvsEDcf/o3ldEbl0+e0rxHH34BEsb8HQKl1iBQNcj bIqA== MIME-Version: 1.0 X-Received: by 10.180.39.238 with SMTP id s14mr6157453wik.60.1385043413971; Thu, 21 Nov 2013 06:16:53 -0800 (PST) Received: by 10.181.13.230 with HTTP; Thu, 21 Nov 2013 06:16:53 -0800 (PST) In-Reply-To: <20131121121728.12108.46847.idtracker@ietfa.amsl.com> References: <20131121121728.12108.46847.idtracker@ietfa.amsl.com> Date: Thu, 21 Nov 2013 06:16:53 -0800 Message-ID: From: "Murray S. Kucherawy" To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c24faab03a2704ebb08c31 Cc: "appsawg-chairs@tools.ietf.org" , "draft-ietf-appsawg-malformed-mail@tools.ietf.org" , The IESG , IETF Apps Discuss , SM Subject: Re: [apps-discuss] Stephen Farrell's Yes on draft-ietf-appsawg-malformed-mail-10: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 14:17:03 -0000 --001a11c24faab03a2704ebb08c31 Content-Type: text/plain; charset=ISO-8859-1 Hi Stephen, On Thu, Nov 21, 2013 at 4:17 AM, Stephen Farrell wrote: > > Thanks for a useful document. I would have loved to have > seen text about S/MIME and PGP issues, but I guess that > might require another equally long document all by > itself. It might well be worth looking though to see if > there's a reference to which you could point that has > relevant guidance about those. > I don't think I've ever seen an ambiguity in an email message that included S/MIME or PGP, so I don't have much to offer here. My co-authors might, so I'll let them chime in if so. I'll do a quick look around to see what I can find. > > Separately, it might also be worth pointing out that > some of the handling guidance you give if applied to > some S/MIME or PGP messages is likely to break > signatures or make decryption impossible. > > Sure, we can look at that angle as well. Thanks for the suggestion. -MSK --001a11c24faab03a2704ebb08c31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Stephen,

On Thu, Nov 21, 2013 at 4:17 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Thanks for a useful document. I would have loved to have
seen text about S/MIME and PGP issues, but I guess that
might require another equally long document all by
itself. It might well be worth looking though to see if
there's a reference to which you could point that has
relevant guidance about those.

I don= 9;t think I've ever seen an ambiguity in an email message that included= S/MIME or PGP, so I don't have much to offer here.=A0 My co-authors mi= ght, so I'll let them chime in if so.=A0 I'll do a quick look aroun= d to see what I can find.
=A0

Separately, it might also be worth pointing out that
some of the handling guidance you give if applied to
some S/MIME or PGP messages is likely to break
signatures or make decryption impossible.


Sure, we can look at that angle as wel= l.=A0 Thanks for the suggestion.

-MSK
--001a11c24faab03a2704ebb08c31-- From superuser@gmail.com Thu Nov 21 06:18:50 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D662F1ADF65; Thu, 21 Nov 2013 06:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRwjFHHsjMEo; Thu, 21 Nov 2013 06:18:49 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id ED6711ADF72; Thu, 21 Nov 2013 06:18:48 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id t60so5848281wes.28 for ; Thu, 21 Nov 2013 06:18:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1ieLgn9n1t8grh6rDMm34vtMCAtseJl6dPMjwK1x4lM=; b=PvGF+UgMQP6l9zOP3o1ZKQFJRzkXenkAy9lyilBeKaUu3Rv3QWa0YEosieG2Y2HtQx LDDSt31B6ktHw5tQ94zYq7yRJiMSXOUSMXpx48TDk9FROkEDxZOpcbK46HJN5jSlfRE4 BaJqgGyY3AhZzcdzgYyEwGLS7GbtelZOMwKmkhSd5vFFf2FS7B7QZX/9dkXgMAEXbJ9l LeV5yj/JCD9Jd2uF0/YnKeWxeheESxzRkEL1pioVPqBm5RpJ4+s8jGjMZiZaxfg+mkEx qhd9aBNJVxce/EJlJVCeQuJbJqKWAanmBa1BnlhS+R52tulA122657K2coznIXun7QT9 +ATg== MIME-Version: 1.0 X-Received: by 10.180.212.98 with SMTP id nj2mr6048190wic.52.1385043521657; Thu, 21 Nov 2013 06:18:41 -0800 (PST) Received: by 10.181.13.230 with HTTP; Thu, 21 Nov 2013 06:18:41 -0800 (PST) In-Reply-To: <20131120223533.8958.23858.idtracker@ietfa.amsl.com> References: <20131120223533.8958.23858.idtracker@ietfa.amsl.com> Date: Thu, 21 Nov 2013 06:18:41 -0800 Message-ID: From: "Murray S. Kucherawy" To: Pete Resnick Content-Type: multipart/alternative; boundary=001a11c223de1b62fb04ebb09344 Cc: "appsawg-chairs@tools.ietf.org" , "draft-ietf-appsawg-malformed-mail@tools.ietf.org" , The IESG , IETF Apps Discuss , SM Subject: Re: [apps-discuss] Pete Resnick's Yes on draft-ietf-appsawg-malformed-mail-10: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 14:18:51 -0000 --001a11c223de1b62fb04ebb09344 Content-Type: text/plain; charset=ISO-8859-1 Hi Pete, On Wed, Nov 20, 2013 at 2:35 PM, Pete Resnick wrote: > > Nothing that would stop me from endorsing this document going forward, > but please do take the following into consideration: > > [...] Thanks for the suggestions. I'll take a run at these after the telechat today. > > Finally, a gedankenexperiment, or maybe fodder for a real experiment: > What would happen if, upon receiving a malformed message that was > determined to not be otherwise malicious, a receiving SMTP system both > returned a 5xx to the message *and* processed and delivered the message > (i.e., give the receiver what they want, but push back on folks who > generate crap)? Would it help? (I am not asking for a discussion of this > in the document. Just an interesting thought.) > > If there's information available about this that can get WG consensus (and one person has already chimed in on apps-discuss), we can add a sentence or two about it as well. -MSK --001a11c223de1b62fb04ebb09344 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Pete,

On Wed, Nov 20, 2013 at 2:35 PM, Pete Resnick <pr= esnick@qti.qualcomm.com> wrote:

Nothing that would stop me from endorsing this document going forward,
but please do take the following into consideration:


[...]

Thanks for the suggestion= s.=A0 I'll take a run at these after the telechat today.
=A0

Finally, a gedankenexperiment, or maybe fodder for a real experiment:
What would happen if, upon receiving a malformed message that was
determined to not be otherwise malicious, a receiving SMTP system both
returned a 5xx to the message *and* processed and delivered the message
(i.e., give the receiver what they want, but push back on folks who
generate crap)? Would it help? (I am not asking for a discussion of this in the document. Just an interesting thought.)


If there's info= rmation available about this that can get WG consensus (and one person has = already chimed in on apps-discuss), we can add a sentence or two about it a= s well.

-MSK
--001a11c223de1b62fb04ebb09344-- From ietf@rozanak.com Thu Nov 21 06:45:53 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3681ADFD9; Thu, 21 Nov 2013 06:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.847 X-Spam-Level: X-Spam-Status: No, score=0.847 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZhtjLIEeXDN; Thu, 21 Nov 2013 06:45:52 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 010F01ADFAC; Thu, 21 Nov 2013 06:45:51 -0800 (PST) Received: from oxuslxltgw09.lxa.perfora.net (oxuslxltgw09.lxa.perfora.net [172.19.206.11]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LaGRy-1VFQ621Wwg-00lyyY; Thu, 21 Nov 2013 09:45:44 -0500 Date: Thu, 21 Nov 2013 09:45:44 -0500 (EST) From: Hosnieh To: "Apps Discuss, IETF" , sacm@ietf.org Message-ID: <492903078.119554.1385045144290.open-xchange@email.1and1.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_119553_1946904892.1385045144246" X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.4.0-Rev20 X-Provags-ID: V02:K0:3Z3qN93g2zqkOeqHX9wz7r9IELWWSeiu9I1kAfP/9qD vOOntbwqYjry/LPqTjCtMm37HK0Gr8S2h6q7voOmQZYmoR5n09 0LXEihH85NjqNPvhnk3vGfsSz/DhHtC1ghoImEkwc8zkbb9sAb XcCVTPgSglSYknViMbpEDHu3YuL/0cedENxlU4GzUJ2QsBWvXG kWGL8RWgdY4+wZNJ0Tj4GLgFNvK2SrbA5I3ZcGayX6JqkLhx9n FLi+qn95E1LYu9xSOKEcbTG5H/DOJDZfODwmXBh6sJRBi07CKP wQ2PcoD9T6GbsNw54Q/5Kr3osLwrOgNqJ4MeL5nqzfxDwfDZYp DMfl6gUw9A/knQ30uiuoaiEvF8J+TRJbjIjiJcJh8HPIXSvngu iQORG37CPoOs9CoLp5aXFBltwOTpZ1i6wpqrvy3cdXDRlK+14y 8NQp2 Cc: "Nordmark, Erik" Subject: [apps-discuss] Is latency is important for you? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Hosnieh List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 14:45:53 -0000 ------=_Part_119553_1946904892.1385045144246 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello, I do not know in which WG I saw a message and a discussion of IID generation and latency problems. If it was not in this mailinglist but I guess it is a good place to start since it really relates to this WG. I have a very important question. Please rate your experience about the latency you encountered in any network that was because of IP configuration of your node. Thanks, --- Smile, Hosnieh Sorry for tpyos from my chubby fingers typing on my phone ------=_Part_119553_1946904892.1385045144246 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
Hello,
 
I do not know in which WG I saw a message and a discussion of IID generation and latency problems. If it was not in this mailinglist but I guess it is a good place to start since it really relates to this WG.
I have a very important question. Please rate  your experience about the latency you encountered in any network that was because of IP configuration of your node.
 
 
Thanks,
 
 
---
Smile,
Hosnieh
Sorry for tpyos from my chubby fingers typing on my phone
------=_Part_119553_1946904892.1385045144246-- From prvs=003088068a=johnl@iecc.com Thu Nov 21 09:13:23 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3281AE089 for ; Thu, 21 Nov 2013 09:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T68p0f44ugin for ; Thu, 21 Nov 2013 09:13:22 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B4B881AE058 for ; Thu, 21 Nov 2013 09:13:21 -0800 (PST) Received: (qmail 24498 invoked from network); 21 Nov 2013 17:13:14 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 21 Nov 2013 17:13:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=528e3f2a.xn--btvx9d.k1310; i=johnl@user.iecc.com; bh=TmUMmmlbOZ6ujiBTThPs9d7V0ex3ZWaovh8Ma42smQs=; b=PAO4A4TpHa0STip5D8ZQbVsHflDVoNRqjODG7iryDKKFEknnAqTG/Yta4X8nA90OoWNnE6eb71mPJS31X3d8sw/+detaK6C8ogsVTjmxjGMEmjbkZu+oKOLWjDhStA39gTrJHpMQrMApc9rF7wAB/UsglnvpNDjj7e/QMgKxOgw6BSBG7jvgUk8+afzTj5/a9NRGmzHRExg8UUpUSfyk1LyI4mDCFHtf3oCr4Iou1LlXxas41e1FfTrmdsiTC4ZM DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=528e3f2a.xn--btvx9d.k1310; olt=johnl@user.iecc.com; bh=TmUMmmlbOZ6ujiBTThPs9d7V0ex3ZWaovh8Ma42smQs=; b=B2hWiSVzW8jUfIMBv2s0iVhesz/pdESWo8fePFddD5gk6NEkoB19HC7jV0IzS2fUSoMQ1F9t/a1BD0YF5H8Y5un9PMPz1X/OaDHwlBJwkmvfbiPpp4l5Hex5rhAkPBQQXfWOp5GjLbM9fEoVUQ3VCnt9xod2VBEQrg8OWoM865yjgyEDRJ/Fh45FWMin0hH10Gg9L1q0TahCwfwjjmGWs65IjAJH0LaA/rBK18aswXT41iJSDX6NEZ8ZwrPKO8om Date: 21 Nov 2013 17:12:52 -0000 Message-ID: <20131121171252.41040.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] Stephen Farrell's Yes on draft-ietf-appsawg-malformed-mail-10: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 17:13:23 -0000 >I don't think I've ever seen an ambiguity in an email message that included >S/MIME or PGP, so I don't have much to offer here. My co-authors might, so >I'll let them chime in if so. I'll do a quick look around to see what I >can find. I'm not a co-author, but other than messages signed with expired keys it's hard to think of anything. In general, if you don't have the key, you can't verify the signature or decode the message, so there's nothing to fix. From stephen.farrell@cs.tcd.ie Thu Nov 21 09:52:58 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B9B1AE00B for ; Thu, 21 Nov 2013 09:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGMOi8R--DPm for ; Thu, 21 Nov 2013 09:52:55 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C8CB61AD79D for ; Thu, 21 Nov 2013 09:52:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1B9D7BE5C; Thu, 21 Nov 2013 17:52:47 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzaantznyBQM; Thu, 21 Nov 2013 17:52:43 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.42.24.123]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5F835BE6F; Thu, 21 Nov 2013 17:52:43 +0000 (GMT) Message-ID: <528E486B.10809@cs.tcd.ie> Date: Thu, 21 Nov 2013 17:52:43 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: John Levine , apps-discuss@ietf.org References: <20131121171252.41040.qmail@joyce.lan> In-Reply-To: <20131121171252.41040.qmail@joyce.lan> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Stephen Farrell's Yes on draft-ietf-appsawg-malformed-mail-10: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 17:52:58 -0000 On 11/21/2013 05:12 PM, John Levine wrote: >> I don't think I've ever seen an ambiguity in an email message that included >> S/MIME or PGP, so I don't have much to offer here. My co-authors might, so >> I'll let them chime in if so. I'll do a quick look around to see what I >> can find. > > I'm not a co-author, but other than messages signed with expired keys > it's hard to think of anything. In general, if you don't have the > key, you can't verify the signature or decode the message, so there's > nothing to fix. Well there were cases of folks messing up when they forwarded signed mails and so on, but maybe those were all sorted in the end. Paul H. might even have written something up back in his IMC days. But again, I'm not asking that stuff like that be added unless the authors want to do it. S > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > From ietf-secretariat-reply@ietf.org Thu Nov 21 11:10:23 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE3D51AE266 for ; Thu, 21 Nov 2013 11:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_URI_ONLY=0.25] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sya6gbarWQ2T; Thu, 21 Nov 2013 11:10:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 904751AE1BC; Thu, 21 Nov 2013 11:10:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-malformed-mail@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131121191022.12090.85819.idtracker@ietfa.amsl.com> Date: Thu, 21 Nov 2013 11:10:22 -0800 From: IETF Secretariat Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 19:10:24 -0000 State changed to Approved-announcement to be sent::Point Raised - writeup n= eeded from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-malforme= d-mail/ From ned.freed@mrochek.com Thu Nov 21 18:55:39 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F0A1AE21F for ; Thu, 21 Nov 2013 18:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQEqPVLsc9xk for ; Thu, 21 Nov 2013 18:55:38 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1F38B1AC7F3 for ; Thu, 21 Nov 2013 18:55:38 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P124UM9CGG000ZW9@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 21 Nov 2013 18:53:37 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P0USA6030W00004G@mauve.mrochek.com>; Thu, 21 Nov 2013 18:53:34 -0800 (PST) Message-id: <01P124UKRRKU00004G@mauve.mrochek.com> Date: Thu, 21 Nov 2013 18:52:48 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 21 Nov 2013 02:28:57 +0000" <20131121022857.30004.qmail@joyce.lan> References: <20131120223533.8958.23858.idtracker@ietfa.amsl.com> <20131121022857.30004.qmail@joyce.lan> To: John Levine Cc: presnick@qti.qualcomm.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] reject and process, was Pete Resnick's Yes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 02:55:39 -0000 > >What would happen if, upon receiving a malformed message that was > >determined to not be otherwise malicious, a receiving SMTP system both > >returned a 5xx to the message *and* processed and delivered the message > >(i.e., give the receiver what they want, but push back on folks who > >generate crap)? Would it help? > I've been doing reject and process on my spamtraps for years. It > doesn't seem to have broken anything, but it also doesn't seem that > anyone's taken the hint. I'm not sure we want to open this particular door in a standardized way. The potential for user astonishment here is very large... Ned From prvs=0031c7bd48=johnl@taugh.com Thu Nov 21 19:10:06 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8091AE2D3 for ; Thu, 21 Nov 2013 19:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-Stg6HxgeYi for ; Thu, 21 Nov 2013 19:10:05 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id AC5591AE2BD for ; Thu, 21 Nov 2013 19:10:04 -0800 (PST) Received: (qmail 17872 invoked from network); 22 Nov 2013 03:09:57 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Nov 2013 03:09:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type:user-agent:cleverness; s=528ecb05.xn--i8sz2z.k1310; i=sendmail-bs@submit.iecc.com; bh=doyDYowY7lNLlhTezjNtXV69PG9XtOyxUHGAbeksSoA=; b=bM8WZErwpT8P+/+T2D5nvAv0pg5+bm7xPHd8hX4Mv8nrf6zm+BxOnbtH8jrtmPv6XY7Jx8Ow7Yp3+ZaFN/k8gsDVZNARVa9mVK1lmcI+SfTBzOA3rY5JhwtDZzwHWzFTk7uFFoMCFZ2OSgqT5OKKDblBTQS0qSkDo1LHuFbCtT3vmVmHvlAzOnBgRFYsQhKnfiCJAIhFqovV9PrvolAsc/QhdtUQR3jtsC0PbvVrslg/9kMBMizeMd538ei+9i+S DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type:user-agent:cleverness; s=528ecb05.xn--i8sz2z.k1310; olt=sendmail-bs@submit.iecc.com; bh=doyDYowY7lNLlhTezjNtXV69PG9XtOyxUHGAbeksSoA=; b=ZucctiD24N+iR0QVsXEc6Xb5MeihXsgVd7iiZF+Ypl4gxykDtxyNKiQT2EEF2lJtW8Z5WknCUeZvX7Yt5LzHNkx827sIJzM3SA+4AQXT1f1DL5N80WzRYMtODOmGwM2IigKy7VPq1x84L444p8CmkBR8zxaCGgi9BOT8LabMVXH/w/6pyo0iwAhNQF2m+qATnhw0Mg/w+B7uyNvn9uN4sP9uktVIeg3JCuZYupSu8Ie30RKDd8087bzjxTXMaTfI Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 22 Nov 2013 03:09:56 -0000 Date: Thu, 21 Nov 2013 22:09:56 -0500 (EST) From: John R Levine To: Ned Freed In-Reply-To: <01P124UKRRKU00004G@mauve.mrochek.com> Message-ID: References: <20131120223533.8958.23858.idtracker@ietfa.amsl.com> <20131121022857.30004.qmail@joyce.lan> <01P124UKRRKU00004G@mauve.mrochek.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-623598023-1385089796=:44198" Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] reject and process, was Pete Resnick's Yes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 03:10:06 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-623598023-1385089796=:44198 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> I've been doing reject and process on my spamtraps for years. It >> doesn't seem to have broken anything, but it also doesn't seem that >> anyone's taken the hint. > > I'm not sure we want to open this particular door in a standardized > way. The potential for user astonishment here is very large... The particular reason I do it on the spamtraps is to deter the "nobody ever complained so you must have opted in" crowd. I agree that it's probably not a great idea for anything that might be considered real mail. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. --3825401791-623598023-1385089796=:44198 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMTIyMDMwOTU2WjAjBgkqhkiG 9w0BCQQxFgQUkFHZwNVUaS6yEeiuBURwpLKhnLIweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAanMthRSdAGhZ xOTlvmWB76tJWDtp7LEb03ipRblqA6eBRmcg+MSb5yk6btrMCtwcoWLxtOqC byrK5A7xUWg1dI+CPKiqX4sjUrnd12FgAZlrrSsz+VVN+OgTxOS+fQ+QJIfW 7sr2QEEach7tyVt80poLLA6j/69B4/DtFNbx6GClMQz+JCvNzn/DKlHi9jzF K9ps9HTKUTNRP+iqUq2OnG3eUMjVoHws3C3LuluS+9CG5mLveuMGUYdMR7cX Dl8fy6zx9jdZdq0gDz0Vvao3q5BJUrnEWUootnxrsFVKxCNHKooxZ64UDcFw NUqyK7ZivRtTQ3dV20t5ad4a3z+pEA== --3825401791-623598023-1385089796=:44198-- From ned.freed@mrochek.com Fri Nov 22 07:20:54 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849831ADFD0 for ; Fri, 22 Nov 2013 07:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F53BjqsyzY9b for ; Fri, 22 Nov 2013 07:20:53 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC081ADF8F for ; Fri, 22 Nov 2013 07:20:53 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P12URODIA80019L2@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 22 Nov 2013 07:15:43 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P0USA6030W00004G@mauve.mrochek.com>; Fri, 22 Nov 2013 07:15:39 -0800 (PST) Message-id: <01P12URM36ZC00004G@mauve.mrochek.com> Date: Fri, 22 Nov 2013 07:13:51 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 21 Nov 2013 22:09:56 -0500 (EST)" References: <20131120223533.8958.23858.idtracker@ietfa.amsl.com> <20131121022857.30004.qmail@joyce.lan> <01P124UKRRKU00004G@mauve.mrochek.com> To: John R Levine Cc: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] reject and process, was Pete Resnick's Yes {dkim-fail} X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 15:20:54 -0000 > >> I've been doing reject and process on my spamtraps for years. It > >> doesn't seem to have broken anything, but it also doesn't seem that > >> anyone's taken the hint. > > > > I'm not sure we want to open this particular door in a standardized > > way. The potential for user astonishment here is very large... > The particular reason I do it on the spamtraps is to deter the "nobody > ever complained so you must have opted in" crowd. Makes sense. Another case where this comes up is certain types of compliance archiving. > I agree that it's > probably not a great idea for anything that might be considered real mail. Ned From dhc@dcrocker.net Fri Nov 22 07:28:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606D21ADF8F for ; Fri, 22 Nov 2013 07:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNaWSJV3fCho for ; Fri, 22 Nov 2013 07:28:17 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id F03C11ADF77 for ; Fri, 22 Nov 2013 07:28:16 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id rAMFS6H2016130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Nov 2013 07:28:09 -0800 Message-ID: <528F77DC.2070908@dcrocker.net> Date: Fri, 22 Nov 2013 07:27:24 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ned Freed , John R Levine References: <20131120223533.8958.23858.idtracker@ietfa.amsl.com> <20131121022857.30004.qmail@joyce.lan> <01P124UKRRKU00004G@mauve.mrochek.com> <01P12URM36ZC00004G@mauve.mrochek.com> In-Reply-To: <01P12URM36ZC00004G@mauve.mrochek.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.66]); Fri, 22 Nov 2013 07:28:09 -0800 (PST) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] reject and process, was Pete Resnick's Yes {dkim-fail} X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 22 Nov 2013 15:28:21 -0000 On 11/22/2013 7:13 AM, Ned Freed wrote: >> >> I've been doing reject and process on my spamtraps for years. It >> >> doesn't seem to have broken anything, but it also doesn't seem that >> >> anyone's taken the hint. >> > >> > I'm not sure we want to open this particular door in a standardized >> > way. The potential for user astonishment here is very large... > >> The particular reason I do it on the spamtraps is to deter the "nobody >> ever complained so you must have opted in" crowd. > > Makes sense. > > Another case where this comes up is certain types of compliance archiving. > >> I agree that it's >> probably not a great idea for anything that might be considered real >> mail. Would there be any benefit in a short BCP about this, including when to use it and when not to? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From Claudio.Allocchio@garr.it Fri Nov 22 07:38:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE671AE160; Fri, 22 Nov 2013 07:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.646 X-Spam-Level: X-Spam-Status: No, score=-0.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDVGojr4BUnv; Fri, 22 Nov 2013 07:37:59 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 272E71AE133; Fri, 22 Nov 2013 07:37:56 -0800 (PST) Received: internal info suppressed Date: Fri, 22 Nov 2013 16:37:23 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@synx02.dir.garr.it To: apps-discuss@ietf.org, draft-ietf-qresync-rfc5162bis.all@tools.ietf.org Message-ID: User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-233511237-1384855853=:12603" Content-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1385134656; bh=DbDo3rze64ADdrjzxnEDqqiDR0s79gm9v1dI2Az7i/M=; h=Date:From:To:cc:Subject; b=eAi1vr8O4BLR9hGQccH71i3f7p1cpHDMLYObuETAjMhBZnWkS0kLrzK7G9cB7qwba WZbhKbQMJbayXkMHKoPmNQXG75hReeRsvCke+uhV0RQ3P0wG+KtssCDhgF+nJqbLsQ Jq/xL+1nWmFTqvy69uVmlaDcq+MRHEirqgnd/DwU= Cc: iesg@ietf.org Subject: [apps-discuss] APPSDIR Early review of draft-ietf-qresync-rfc5162bis-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 15:38:03 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-233511237-1384855853=:12603 Content-Type: TEXT/PLAIN; CHARSET=UTF-8; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: This is an Early Review, no IETF LC issued yet. I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see ​http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). 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-qresync-rfc5162bis-03.txt Title: IMAP Extensions for Conditional STORE Operation or Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC) Reviewer: Claudio Allocchio Review Date: Nov 19th 2013 IETF Last Call Date: N/A IESG Telechat Date: N/A Summary: This draft is almost ready for publication as an Informational RFC. It describes in details (maybe even in too much detail in the Introduction and Overview, but I do not see this as a problem) the extensions and possible scenarios. Just some minor issues to check. Major issues: none. Minor issues: Abstract: - When you state "They must be able to guarantee that only one client can change message state (e.g., message flags) at any time." IMHO there is chance that one implementer might undestand that only one client at a time shall be granted permission to change message state/flags al ALL messages in the mailbox, while we just mean "message flags/state of the specific message you are looking at". Maybe a text like: "They must be able to guarantee that only one client can change message state (e.g., message flags of the specific message being looked up) at any time." 1. Introduction and overview - In general, this is more a "condensed summary" of the specification than an introduction or overview. Maybe a different title... I shall say that it is quite unusual to have such a precise summary of the specification (with references to following section) at the beginning of a specification. Nothing wrong, but again it make me thing the title of this section is wrong. - When you talk about QRESYNC, saying that on a mobile client it can "reduce the expense" maybe is not appropriate for a technical specification (and many people run on flat-rate data plans...) - "Since CONDSTORE is a relatively new extension, it is thought likely that clients that support it will also support QRESYNC." why not turn this into a reccomendation? Or add a reccomendation that both should be supported? 3.1.1 I suggest "One of these two response codes MUST be returned" 3.1.2 Note after Example 8. " Note: A client trying to make an atomic change to the state of a particular metadata item (or a set of metadata items) should be prepared to deal with the case when the server returns the MODIFIED" ... it's inside a "note:" ... however I have some doubts that "should" needs to be an uppercase normative SHOULD. Same (minor!) issue also later after Example 10 for the "may": "The following example is based on the example from the Section 4.2.3 of [RFC2180] and demonstrates that the MODIFIED response code may be also returned in the tagged NO response." ... again, after Example 11: "the server must not fail the operation for message 7 as part of processing "3:9" if it succeeded when message 7 was processed the first time." (MUST NOT?) 3.1.4 again as above: " The last means that the server should use the biggest value among "priv" and "shared" mod-sequences" (SHOULD?) 3.1.10 " Server implementations should follow the following rule," (SHOULD?) 6. again: " An advanced disconnected mail client should use the QRESYNC" (SHOULD?) NOTE: All the above refers to client/serve actions, that's why I've the feeling we shall use normative uppercase. Nits: none. ------------------------------------------------------------------------------ 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 --0-233511237-1384855853=:12603-- From ned.freed@mrochek.com Fri Nov 22 07:50:54 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E665F1AE358; Fri, 22 Nov 2013 07:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtpytKlIhemi; Fri, 22 Nov 2013 07:50:54 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id D9C3C1AE19B; Fri, 22 Nov 2013 07:50:52 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P12VSUPJO00010VI@mauve.mrochek.com>; Fri, 22 Nov 2013 07:45:43 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P0USA6030W00004G@mauve.mrochek.com>; Fri, 22 Nov 2013 07:45:37 -0800 (PST) Message-id: <01P12VSSBO5Y00004G@mauve.mrochek.com> Date: Fri, 22 Nov 2013 07:41:43 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 21 Nov 2013 08:58:38 -0800" <20131121165838.GC78520@C02KN7GSDTY3.corp.proofpoint.com> References: <20131121121728.12108.46847.idtracker@ietfa.amsl.com> <20131121165838.GC78520@C02KN7GSDTY3.corp.proofpoint.com> To: Gregory Shapiro Cc: "draft-ietf-appsawg-malformed-mail@tools.ietf.org" , IETF Apps Discuss , SM , "appsawg-chairs@tools.ietf.org" , The IESG Subject: Re: [apps-discuss] Stephen Farrell's Yes on draft-ietf-appsawg-malformed-mail-10: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 15:50:55 -0000 > > I don't think I've ever seen an ambiguity in an email message that > > included S/MIME or PGP, so I don't have much to offer here. My > > co-authors might, so I'll let them chime in if so. I'll do a quick > > look around to see what I can find. > Like Murray, I haven't observed any S/MIME or PGP mangling (which doesn't > mean it doesn't happen, just that it hasn't been caught). We mostly deal with S/MIME, and I can't recall a case where an S/MIME message (either signed or encrypted) got mangled. Certificate problems sure, but that's a different sort of thing. Signed PGP messages get "mangled" all the time, but that's because a lot of PGP still uses the text/plain approach rather than multipart/signed. I regard this as a case of PGP acting stupidly and getting exactly what it deserves. Ned From prvs=0031c7bd48=johnl@taugh.com Fri Nov 22 08:13:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBEA1ADFFA for ; Fri, 22 Nov 2013 08:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOI1DCviVpv2 for ; Fri, 22 Nov 2013 08:12:59 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 910F41ADFCB for ; Fri, 22 Nov 2013 08:12:59 -0800 (PST) Received: (qmail 41642 invoked from network); 22 Nov 2013 16:12:51 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Nov 2013 16:12:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type:user-agent:cleverness; s=528f8283.xn--yuvv84g.k1310; i=sendmail-bs@submit.iecc.com; bh=15a4g/py1Ue0sTSupEWoCAKtVtvfQgad1RZE2yiSoO0=; b=VsJh/AvXimz4lBFVr4Rm/Jh5sfWjt5T/JQWcWz+5K4N1//pb771xXAkkFGt5ZMcEglUCKgSYbBnZs+/3/h4GJ/eDUhrCfBiwvEI6tY/moYRKfKJmiia2OlHe5t9j8AGZm8QCNjYl4fpVGBPJIOriYVNfrTzylwJoEYJwTl6A8+NG+wTw9eMfrbu9mVrF4tbaeDzydafYRiQv72nKHge1ktGxo9bneZRSLyW8q6Exp+vOZMVUEZqHx0S0hdQUtZIK DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type:user-agent:cleverness; s=528f8283.xn--yuvv84g.k1310; olt=sendmail-bs@submit.iecc.com; bh=15a4g/py1Ue0sTSupEWoCAKtVtvfQgad1RZE2yiSoO0=; b=c3slGMa8CFXTsixB4fl5s+ght66ljPae3T2wpe3XKljyNrkIyogLZ5VNI5lq+/fwRON7O/BpJeYrmQA4gOOh8k9cUzBz3mwWQmHr2o3z9w4rlAOfEbFhEColrd3ypuxz6TuBOcKDdHVwvUFr7aMxQIHhDldCoeqCLassf0AMC70hytB2qF+AwcKl2NdVZJlxvbeumeSo2Hmb83aUQOsybfcqU3oF6/ivK+Y41nTlF8NgLaSZecRao/+vQ0X6rF4J Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 22 Nov 2013 16:12:51 -0000 Date: Fri, 22 Nov 2013 11:12:51 -0500 (EST) From: John R Levine To: dcrocker@bbiw.net In-Reply-To: <528F77DC.2070908@dcrocker.net> Message-ID: References: <20131120223533.8958.23858.idtracker@ietfa.amsl.com> <20131121022857.30004.qmail@joyce.lan> <01P124UKRRKU00004G@mauve.mrochek.com> <01P12URM36ZC00004G@mauve.mrochek.com> <528F77DC.2070908@dcrocker.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] reject and process, was Pete Resnick's Yes {dkim-fail} X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 16:13:05 -0000 > Would there be any benefit in a short BCP about this, including when to use > it and when not to? What I'm doing is pretty exotic. If we can't find some other people doing reject and process, the best I can offer is an HSG* rather than BCP. R's, John * - Highly Speculative Guess From blueroofmusic@gmail.com Fri Nov 22 10:15:17 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866461ADFCE for ; Fri, 22 Nov 2013 10:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGlAiXktoDuw for ; Fri, 22 Nov 2013 10:15:13 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 93D211AD959 for ; Fri, 22 Nov 2013 10:15:13 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id at1so2632251iec.21 for ; Fri, 22 Nov 2013 10:15:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xHfQTeIBQns1RIsZjPyl4Ivo6w7V5nDVrQEEeLqY5g0=; b=H0L3yZCs0MdxwXXoBRLii3tgNs0OfDhTDsS1KXCffAnKxIb+nxH5uI461juglWdnQy czr6VMRurekm60szhOhxLB6zjDktcvyS5NDjWkPT9QvWxlQpoKwbNtEW9jodblgbKb5u J5BOkKuGOELoApp+zouQJA1C96noEm7ohI8esQ/t7FfUsY1d0qeGtHi1iUZPZgTNHaBQ JDcJMOGxBmnaz3qrjIU9yNq6xfAHLCjsnzZB32e68nk5CsUwuiz6xQoAk9yBGOeZnFMr xuNPbCD8zjQMEXqmjV/hxntQXsiTeNSxeFL9HZJ1L8j0PQUfH8tFQ2uIDCEUirnJsqkG jjwQ== X-Received: by 10.42.142.129 with SMTP id s1mr9018540icu.30.1385144106178; Fri, 22 Nov 2013 10:15:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.96.135 with HTTP; Fri, 22 Nov 2013 10:14:46 -0800 (PST) In-Reply-To: <528A3430.6080900@isode.com> References: <528A3430.6080900@isode.com> From: Ira McDonald Date: Fri, 22 Nov 2013 13:14:46 -0500 Message-ID: To: Alexey Melnikov , Ira McDonald Content-Type: multipart/alternative; boundary=90e6ba6e8ce2695fff04ebc7fed5 Cc: Pat Fleming , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] AppsDir review of draft-mcdonald-ldap-printer-schema-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 18:15:17 -0000 --90e6ba6e8ce2695fff04ebc7fed5 Content-Type: text/plain; charset=ISO-8859-1 Hi Alexey, Thanks for you excellent comments! My apologies for not acknowledging them sooner. I need to think about resolutions and discuss w/ the IEEE-ISTO PWG Internet Printing Protocol WG, so I'll be a week or so responding yet (our next meeting is 2 December). Cheers, - Ira (co-editor of LDAP Printer Schema, co-chair of PWG IPP WG) Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Mon, Nov 18, 2013 at 10:37 AM, Alexey Melnikov wrote: > On 19/09/2013 17:34, Ira McDonald wrote: > >> Hello, >> >> The IEEE-ISTO PWG Internet Printing Protocol WG would like to request >> IETF Apps Area review of our updated LDAP Printer Schema (updates >> RFC 3712). >> >> http://www.ietf.org/internet-drafts/draft-mcdonald-ldap- >> printer-schema-05.txt >> >> Cheers, >> - Ira (co-chair of IEEE-ISTO PWG IPP WG and co-editor of this document) >> > > My apologies for belated review. I hope you find them useful. > > ----------------------------------------- > > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on APPSDIR, please see > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). > > 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-mcdonald-ldap-printer-schema-05.txt > Title: Lightweight Directory Access Protocol (LDAP): Schema for Printer > Services > Reviewer: Alexey Melnikov > Review Date: November 18, 2013 > IETF Last Call Date: N/A > > Summary: This draft is nearly reading for publication. > > This document defines a schema, object classes and attributes, for > Printers and Print Services, for use with directories that support > Lightweight Directory Access Protocol (RFC 4510). This document is > based on the Printer attributes listed in Appendix E of Internet > Printing Protocol/1.1 (IPP) (RFC 2911). Additional Printer > attributes are based on definitions in the Printer MIB v2 (RFC 3805), > IEEE-ISTO PWG Command Set for IEEE 1284 Device ID (PWG 5107.2), > IEEE-ISTO PWG IPP Job and Printer Extensions - Set 3 (PWG 5100.13), > and IEEE-ISTO PWG IPP Everywhere (PWG 5100.14). > > This document is published by the IETF on behalf of the Internet > Printing Protocol Working Group of the IEEE-ISTO Printer Working > Group. > > > Most of the issues I found are minor. In general the document is quite > readable. > > General comments: > > I noticed that you redifined various syntaxes to have upper limits on > Directory strings. URI and Language Tags have no upper limits. I suspect > that limits that you added are going to be sufficient in most cases, but it > would be better for your document to call these out explicitly in text. > > > In Section 1: > > This document updates RFC 3712. > > But the draft header says that it Obsoletes it. I think Obsolete is > correct, so the statement in Section 1 should be updated to match. > > > In Section 3.3: > > Note: When extending other structural classes with auxiliary >> classes, printerService SHOULD not be used. >> > You should also capitalize "not" according to RFC 2119. There are multiple > occurrences of the same problem in multiple places in the document. > > > 3.4. printerServiceAuxClass >> ( 1.3.18.0.2.6.257 >> NAME 'printerServiceAuxClass' >> DESC 'Printer information.' >> >> Fleming, McDonald Expires 19 March 2014 [Page 11] >> >> Internet-Draft LDAP Schema for Printer Services 19 September 2013 >> >> AUXILIARY >> SUP printerAbstract >> MAY ( printer-uri $ >> printer-xri-supported ) >> ) >> This auxiliary class defines Printer information. It is derived >> from >> class printerAbstract and thus inherits common Printer attributes. >> This class SHOULD be used with a structural class. >> > Each directory entry requires a structural object class, so I think this > SHOULD is misleading. Also, why is this not a MUST? > I suggest you just delete this sentence or reword it to make it non > normative (and point to the document which makes the authoritative > statement on this matter.) > > > Similar text in 3.5 and 3.6. > > 4. Definition of Attribute Types >> >> The following attribute types reference matching rule names (instead >> of OIDs) for clarity (see Section 6 below). For optional attributes, >> if the Printer information is not known, the attribute value SHOULD >> not be set. In the following definitions, referenced matching rules >> are defined in Section 4 of [RFC4517] (see Section 6 'Definition of >> Matching Rules' below). >> > > I think you still meant section 4. > > Note: For interoperability and consistent text display, values of >> attributes defined in this document: (a) SHOULD be normalized as >> recommended in Unicode Format for Network Interchange [RFC5198]; (b) >> SHOULD not contain DEL or any C0 or C1 control characters except for >> > "SHOULD not" --> "SHOULD NOT" > >> HT, CR, and LF; (c) SHOULD only contain CR and LF characters together >> (not as singletons); and SHOULD NOT contain HT, CR, or LF characters >> in names, e.g., printer-name and printer-aliases. >> > > In 4.1: > > Note: LDAP application clients SHOULD not attempt to use malformed >> URI values read from this attribute. LDAP administrative clients >> SHOULD not write malformed URI values into this attribute. >> > "SHOULD not" --> "SHOULD NOT" (twice) > > > In 4.4: > > Values of language tags SHOULD conform to Tags for Identifying >> Languages [BCP47]. >> > Why is this a SHOULD and not a MUST? I.e. what are possible reason to put > anything not specified in BCP47 here? > > > 4.12. printer-charset-supported >> ( 1.3.18.0.2.4.1131 >> NAME 'printer-charset-supported' >> DESC 'One of the charsets supported for the attribute values of >> syntax DirectoryString for this directory entry.' >> > I don't understand this description. DirectoryString is always in UTF-8. > > How is this LDAP attribute being used? > >> EQUALITY caseIgnoreMatch >> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} >> ) >> > > 4.13. printer-generated-natural-language-supported >> ( 1.3.18.0.2.4.1137 >> NAME 'printer-generated-natural-language-supported' >> DESC 'One of the natural languages supported for this directory >> entry.' >> > Again, I am not entirely sure how this is used. Can you clarify? > > 4.20. printer-number-up-supported >> ( 1.3.18.0.2.4.1124 >> NAME 'printer-number-up-supported' >> DESC 'Maximum number of print-stream pages that can be imposed upon a >> single side of an instance of selected medium by this Printer.' >> EQUALITY integerMatch >> ORDERING integerOrderingMatch >> SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 >> ) >> > This is not defined as single-valued. What is the meaning of multiple > values? > > 4.35. printer-device-id >> ( 1.3.18.0.2.24.46.1.101 >> NAME 'printer-device-id' >> DESC 'The IEEE 1284 Device ID for this Printer.' >> EQUALITY caseIgnoreMatch >> SUBSTR caseIgnoreSubstringsMatch >> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} >> ) >> Values of this attribute SHOULD conform to IEEE-ISTO PWG Command >> Set >> Format for IEEE 1284 Device ID [PWG5107.2]. >> Note: For interoperatibility, values of this attribute SHOULD >> include key/value pairs in the following order: (a) all required >> key/value pairs (i.e., MANUFACTURER/MFG, MODEL/MDL, and COMMAND >> SET/CMD); (b) all optional key/value pairs; and (c) all vendor >> key/value pairs. >> > How does the advice on ordering interacts with multiple values of the > attribute? LDAP multivalued attributes have no ordering of values. > > printer-device-id 1.3.18.0.2.24.46.1.101 > printer-device-service-count 1.3.18.0.2.24.46.1.102 > printer-uuid 1.3.18.0.2.24.46.1.104 > printer-charge-info 1.3.18.0.2.24.46.1.105 > printer-charge-info-uri 1.3.18.0.2.24.46.1.106 > printer-geo-location 1.3.18.0.2.24.46.1.107 > printer-ipp-features-supported 1.3.18.0.2.24.46.1.108 > > This is not necessarily a problem, but I couldn't find a registration for > the 1.3.18.0.2.24 OID. The parent OID is owned by IBM. > > > 13. Appendix X - Change History > > [ [RFC Editor: This section to be deleted before RFC publication] ] > > -bis document are required to include "Changes since RFC XXXX" section. So > you should replace this Appendix with another one that details changes > since RFC 3712. > > Best Regards, > Alexey > > --90e6ba6e8ce2695fff04ebc7fed5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Alexey,

Thanks fo= r you excellent comments!=A0 My apologies for not acknowledging them sooner= .

I need to think about resolutions and discuss w/ the IEEE-IS= TO PWG Internet Printing
Protocol WG, so I'll be a week or so responding yet (our next mee= ting is 2 December).

Cheers,
- Ira (co-editor of LDAP= Printer Schema, co-chair of PWG IPP WG)


Ira McDonald (Musician / Software A= rchitect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux = Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group<= br> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated E= xpert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto: blue= roofmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 734-944-0094
Summer= =A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434



On Mon, Nov 18, 2013 at 10:37 AM, Alexey= Melnikov <alexey.melnikov@isode.com> wrote:
On 19/09/2013 17:34, Ira McDonald wrote:
Hello,

The IEEE-ISTO PWG Internet Printing Protocol WG would like to request
IETF Apps Area review of our updated LDAP Printer Schema (updates
RFC 3712).

http://www.ietf.org/internet-drafts= /draft-mcdonald-ldap-printer-schema-05.txt

Cheers,
- Ira (co-chair of IEEE-ISTO PWG IPP WG and co-editor of this document)

My apologies for belated review. I hope you find them useful.

-----------------------------------------

I have been selected as the Applications Area Directorate reviewer for this= draft (for background on APPSDIR, please see = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAre= aDirectorate ).

Please resolve these comments along with any other Last Call comments you m= ay receive. Please wait for direction from your document shepherd or AD bef= ore posting a new version of the draft.

Document: draft-mcdonald-ldap-printer-schema-05.txt
Title: Lightweight Directory Access Protocol (LDAP): Schema for Printer Ser= vices
Reviewer: Alexey Melnikov
Review Date: November 18, 2013
IETF Last Call Date: N/A

Summary: This draft is nearly reading for publication.

This document defines a schema, object classes and attributes, for
Printers and Print Services, for use with directories that support
Lightweight Directory Access Protocol (RFC 4510). =A0This document is
based on the Printer attributes listed in Appendix E of Internet
Printing Protocol/1.1 (IPP) (RFC 2911). =A0Additional Printer
attributes are based on definitions in the Printer MIB v2 (RFC 3805),
IEEE-ISTO PWG Command Set for IEEE 1284 Device ID (PWG 5107.2),
IEEE-ISTO PWG IPP Job and Printer Extensions - Set 3 (PWG 5100.13),
and IEEE-ISTO PWG IPP Everywhere (PWG 5100.14).

This document is published by the IETF on behalf of the Internet
Printing Protocol Working Group of the IEEE-ISTO Printer Working
Group.


Most of the issues I found are minor. In general the document is quite read= able.

General comments:

I noticed that you redifined various syntaxes to have upper limits on Direc= tory strings. URI and Language Tags have no upper limits. =A0I suspect that= limits that you added are going to be sufficient in most cases, but it wou= ld be better for your document to call these out explicitly in text.


In Section 1:

This document updates RFC 3712.

But the draft header says that it Obsoletes it. I think Obsolete is correct= , so the statement in Section 1 should be updated to match.


In Section 3.3:

=A0 =A0Note: =A0When extending other structural classes with auxiliary
=A0 =A0 classes, printerService SHOULD not be used.
You should also capitalize "not" according to RFC 2119. There are= multiple occurrences of the same problem in multiple places in the documen= t.


3.4. =A0printerServiceAuxClass
=A0 =A0 =A0 =A0 ( 1.3.18.0.2.6.257
=A0 =A0 NAME =A0'printerServiceAuxClass'
=A0 =A0 DESC =A0'Printer information.'

Fleming, McDonald =A0 =A0 =A0 =A0 =A0 =A0Expires 19 March 2014 =A0 =A0 =A0 = =A0 =A0 =A0 [Page 11]
=0C
Internet-Draft =A0 =A0LDAP Schema for Printer Services =A0 =A0 19 September= 2013

=A0 =A0 AUXILIARY
=A0 =A0 SUP =A0 printerAbstract
=A0 =A0 MAY =A0 ( printer-uri $
=A0 =A0 =A0 =A0 =A0 =A0 printer-xri-supported )
=A0 =A0 )
=A0 =A0 =A0 =A0 This auxiliary class defines Printer information. =A0It is = derived from
=A0 =A0 class printerAbstract and thus inherits common Printer attributes.<= br> =A0 =A0 This class SHOULD be used with a structural class.
Each directory entry requires a structural object class, so I think this SH= OULD is misleading. Also, why is this not a MUST?
I suggest you just delete this sentence or reword it to make it non normati= ve (and point to the document which makes the authoritative statement on th= is matter.)


Similar text in 3.5 and 3.6.

4. =A0Definition of Attribute Types

=A0 =A0The following attribute types reference matching rule names (instead=
=A0 =A0of OIDs) for clarity (see Section 6 below). =A0For optional attribut= es,
=A0 =A0if the Printer information is not known, the attribute value SHOULD<= br> =A0 =A0not be set. =A0In the following definitions, referenced matching rul= es
=A0 =A0are defined in Section 4 of [RFC4517] (see Section 6 'Definition= of
=A0 =A0Matching Rules' below).

I think you still meant section 4.

=A0 =A0 Note: =A0For interoperability and consistent text display, values o= f
=A0 =A0 attributes defined in this document: =A0(a) SHOULD be normalized as=
=A0 =A0 recommended in Unicode Format for Network Interchange [RFC5198]; (b= )
=A0 =A0 SHOULD not contain DEL or any C0 or C1 control characters except fo= r
"SHOULD not" --> "SHOULD NOT"
=A0 =A0 HT, CR, and LF; (c) SHOULD only contain CR and LF characters togeth= er
=A0 =A0 (not as singletons); and SHOULD NOT contain HT, CR, or LF character= s
=A0 =A0 in names, e.g., printer-name and printer-aliases.

In 4.1:

=A0 =A0 Note: =A0LDAP application clients SHOULD not attempt to use malform= ed
=A0 =A0 URI values read from this attribute. =A0LDAP administrative clients=
=A0 =A0 SHOULD not write malformed URI values into this attribute.
"SHOULD not" --> "SHOULD NOT" (twice)


In 4.4:

=A0 =A0 Values of language tags SHOULD conform to Tags for Identifying
=A0 =A0 Languages [BCP47].
Why is this a SHOULD and not a MUST? I.e. what are possible reason to put a= nything not specified in BCP47 here?


=A0 =A0 4.12. =A0printer-charset-supported
=A0 =A0 =A0 =A0 ( 1.3.18.0.2.4.1131
=A0 =A0 NAME 'printer-charset-supported'
=A0 =A0 DESC 'One of the charsets supported for the attribute values of=
=A0 =A0 =A0 =A0 =A0 syntax DirectoryString for this directory entry.'
I don't understand this description. DirectoryString is always in UTF-8= .

How is this LDAP attribute being used?
=A0 =A0 EQUALITY caseIgnoreMatch
=A0 =A0 SYNTAX =A01.3.6.1.4.1.1466.115.121.1.15{255}
=A0 =A0 )

=A0 =A04.13. =A0printer-generated-natural-language-supported
=A0 =A0 =A0 =A0 ( 1.3.18.0.2.4.1137
=A0 =A0 NAME 'printer-generated-natural-language-supported'<= br> =A0 =A0 DESC 'One of the natural languages supported for this directory=
=A0 =A0 =A0 =A0 =A0 entry.'
Again, I am not entirely sure how this is used. Can you clarify?

=A0 =A04.20. =A0printer-number-up-supported
=A0 =A0 =A0 =A0 ( 1.3.18.0.2.4.1124
=A0 =A0 NAME 'printer-number-up-supported'
=A0 =A0 DESC 'Maximum number of print-stream pages that can be imposed = upon a
=A0 =A0 =A0 =A0 =A0 single side of an instance of selected medium by this P= rinter.'
=A0 =A0 EQUALITY integerMatch
=A0 =A0 ORDERING integerOrderingMatch
=A0 =A0 SYNTAX =A01.3.6.1.4.1.1466.115.121.1.27
=A0 =A0 )
This is not defined as single-valued. What is the meaning of multiple value= s?

=A0 =A0 4.35. =A0printer-device-id
=A0 =A0 =A0 =A0 ( 1.3.18.0.2.24.46.1.101
=A0 =A0 NAME 'printer-device-id'
=A0 =A0 DESC 'The IEEE 1284 Device ID for this Printer.'
=A0 =A0 EQUALITY caseIgnoreMatch
=A0 =A0 SUBSTR caseIgnoreSubstringsMatch
=A0 =A0 SYNTAX =A01.3.6.1.4.1.1466.115.121.1.15{255}
=A0 =A0 )
=A0 =A0 =A0 =A0 Values of this attribute SHOULD conform to IEEE-ISTO PWG Co= mmand Set
=A0 =A0 Format for IEEE 1284 Device ID [PWG5107.2].
=A0 =A0 =A0 =A0 Note: =A0For interoperatibility, values of this attribute S= HOULD
=A0 =A0 include key/value pairs in the following order: =A0(a) all required=
=A0 =A0 key/value pairs (i.e., MANUFACTURER/MFG, MODEL/MDL, and COMMAND
=A0 =A0 SET/CMD); (b) all optional key/value pairs; and (c) all vendor
=A0 =A0 key/value pairs.
How does the advice on ordering interacts with multiple values of the attri= bute? LDAP multivalued attributes have no ordering of values.

=A0 =A0printer-device-id =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 1.3.18.0.2.24.46.1.101
=A0 =A0printer-device-service-count =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01.3.= 18.0.2.24.46.1.102
=A0 =A0printer-uuid =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A01.3.18.0.2.24.46.1.104
=A0 =A0printer-charge-info =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 1.3.18.0.2.24.46.1.105
=A0 =A0printer-charge-info-uri =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = 1.3.18.0.2.24.46.1.106
=A0 =A0printer-geo-location =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A01.3.18.0.2.24.46.1.107
=A0 =A0printer-ipp-features-supported =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01.3.18= .0.2.24.46.1.108

This is not necessarily a problem, but I couldn't find a registration f= or the 1.3.18.0.2.24 OID. The parent OID is owned by IBM.


13. =A0Appendix X - Change History

=A0 =A0[ [RFC Editor: =A0This section to be deleted before RFC publication]= ]

-bis document are required to include "Changes since RFC XXXX" se= ction. So you should replace this Appendix with another one that details ch= anges since RFC 3712.

Best Regards,
Alexey


--90e6ba6e8ce2695fff04ebc7fed5-- From gshapiro@proofpoint.com Thu Nov 21 08:59:16 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B991AE076; Thu, 21 Nov 2013 08:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CznRJJ5Nxkk; Thu, 21 Nov 2013 08:59:14 -0800 (PST) Received: from mx2.proofpoint.com (mx2.proofpoint.com [208.86.202.10]) by ietfa.amsl.com (Postfix) with ESMTP id 0905D1AE20D; Thu, 21 Nov 2013 08:59:11 -0800 (PST) Received: from hq-cas02.corp.proofpoint.com (hq-cas02.corp.proofpoint.com [10.20.7.202]) by admin1010.us.proofpoint.com (8.14.5/8.14.5) with ESMTP id rALGwdod016093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 21 Nov 2013 08:58:39 -0800 Received: from C02KN7GSDTY3.corp.proofpoint.com (208.86.202.10) by hq-cas02.corp.proofpoint.com (10.20.7.200) with Microsoft SMTP Server (TLS) id 14.1.438.0; Thu, 21 Nov 2013 08:58:39 -0800 Date: Thu, 21 Nov 2013 08:58:38 -0800 From: Gregory Shapiro To: "Murray S. Kucherawy" Message-ID: <20131121165838.GC78520@C02KN7GSDTY3.corp.proofpoint.com> References: <20131121121728.12108.46847.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [208.86.202.10] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.14, 0.0.0000 definitions=2013-11-21_04:2013-11-21,2013-11-21,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1311210116 X-Mailman-Approved-At: Fri, 22 Nov 2013 10:42:00 -0800 Cc: "draft-ietf-appsawg-malformed-mail@tools.ietf.org" , IETF Apps Discuss , SM , "appsawg-chairs@tools.ietf.org" , The IESG Subject: Re: [apps-discuss] Stephen Farrell's Yes on draft-ietf-appsawg-malformed-mail-10: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 17:05:44 -0000 > I don't think I've ever seen an ambiguity in an email message that > included S/MIME or PGP, so I don't have much to offer here. My > co-authors might, so I'll let them chime in if so. I'll do a quick > look around to see what I can find. Like Murray, I haven't observed any S/MIME or PGP mangling (which doesn't mean it doesn't happen, just that it hasn't been caught). From superuser@gmail.com Fri Nov 22 11:39:14 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352BF1AE064; Fri, 22 Nov 2013 11:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWP9-FJWszdJ; Fri, 22 Nov 2013 11:39:12 -0800 (PST) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAA41AE1F7; Fri, 22 Nov 2013 11:39:12 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id q58so1599616wes.33 for ; Fri, 22 Nov 2013 11:39:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ns+eS6F30+Ze+D+b5EAq/pe2SnGJ28THB8cdObOxt5o=; b=oqO8QUDPzu8jCUWMBuvmUKzNpPXSpBYrQcy0aT585pfZHfuC205y9IwDMUTVl9fqyg FXiisdpkGdICm2NXMax3nr/1IpkkNEKN5Z6po1niIZDVdm0TO66EKR4UZGw9W1h911gU bbMdsnQYxrr5CuzgVBRjKHRWhrLlkpn6aR4OINoQw+rv17ydLvp6RmNu9DdQEJL2VSEy ftnHnHmxnhr6fiw2DfQ4J4+PMaT4TYX9Rca4cBY6FBa6/DkLxn29+wnqjHpGq+r3cbpo C+b4Do5XQflVNx/fgRdlNvyLvPQ9U5noMPVtBXz7nQLMXpEfkf7CbYYainmP8i8HBjyF FXQw== MIME-Version: 1.0 X-Received: by 10.180.182.136 with SMTP id ee8mr1639662wic.19.1385149144809; Fri, 22 Nov 2013 11:39:04 -0800 (PST) Received: by 10.181.13.230 with HTTP; Fri, 22 Nov 2013 11:39:04 -0800 (PST) In-Reply-To: <20131120223533.8958.23858.idtracker@ietfa.amsl.com> References: <20131120223533.8958.23858.idtracker@ietfa.amsl.com> Date: Fri, 22 Nov 2013 11:39:04 -0800 Message-ID: From: "Murray S. Kucherawy" To: Pete Resnick Content-Type: multipart/alternative; boundary=089e016346b4bcc86904ebc92a24 Cc: "appsawg-chairs@tools.ietf.org" , "draft-ietf-appsawg-malformed-mail@tools.ietf.org" , The IESG , IETF Apps Discuss , SM Subject: Re: [apps-discuss] Pete Resnick's Yes on draft-ietf-appsawg-malformed-mail-10: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 19:39:14 -0000 --089e016346b4bcc86904ebc92a24 Content-Type: text/plain; charset=ISO-8859-1 All of this works for me except: On Wed, Nov 20, 2013 at 2:35 PM, Pete Resnick wrote: > 7.5.3 - What's the harm in more than one Return-Path? Only one of > interest is the top-most. > The issue here is that some components pick the last one, and some pick the first, in general. More often this happen with From, but Return-Path is not special in this regard. -MSK --089e016346b4bcc86904ebc92a24 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All of this works for me except:

On Wed, Nov 2= 0, 2013 at 2:35 PM, Pete Resnick <presnick@qti.qualcomm.com>= ; wrote:
7.5.3 - What's the harm in more than one Return-Path? Only on= e of
interest is the top-most.

The issue her= e is that some components pick the last one, and some pick the first, in ge= neral.=A0 More often this happen with From, but Return-Path is not special = in this regard.

-MSK
--089e016346b4bcc86904ebc92a24-- From ned.freed@mrochek.com Fri Nov 22 17:45:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72AB1AE21E for ; Fri, 22 Nov 2013 17:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vs-5uV5S8YRa for ; Fri, 22 Nov 2013 17:45:02 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 274281AE0E2 for ; Fri, 22 Nov 2013 17:45:02 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P13GKIQG5S00170R@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 22 Nov 2013 17:39:52 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P0USA6030W00004G@mauve.mrochek.com>; Fri, 22 Nov 2013 17:39:49 -0800 (PST) Message-id: <01P13GKHC19Q00004G@mauve.mrochek.com> Date: Fri, 22 Nov 2013 17:37:50 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Fri, 22 Nov 2013 11:12:51 -0500 (EST)" References: <20131120223533.8958.23858.idtracker@ietfa.amsl.com> <20131121022857.30004.qmail@joyce.lan> <01P124UKRRKU00004G@mauve.mrochek.com> <01P12URM36ZC00004G@mauve.mrochek.com> <528F77DC.2070908@dcrocker.net> To: John R Levine Cc: dcrocker@bbiw.net, apps-discuss@ietf.org Subject: Re: [apps-discuss] reject and process, was Pete Resnick's Yes {dkim-fail} X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 23 Nov 2013 01:45:03 -0000 > > Would there be any benefit in a short BCP about this, including when to use > > it and when not to? > What I'm doing is pretty exotic. If we can't find some other people doing > reject and process, the best I can offer is an HSG* rather than BCP. And in regards to compliance archiving, a BCP is probably a good idea, but I'm not the one to write it. You need someone with substantial familiarity with both the legal landscape and actual deployment experience. I also note that now may not be the best time for such a document. Ned From internet-drafts@ietf.org Fri Nov 22 22:59:59 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4164A1AE0CD; Fri, 22 Nov 2013 22:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFELHrYZJxXe; Fri, 22 Nov 2013 22:59:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 654D21AE0E0; Fri, 22 Nov 2013 22:59:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131123065956.19859.21910.idtracker@ietfa.amsl.com> Date: Fri, 22 Nov 2013 22:59:56 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail-11.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 06:59:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Advice for Safe Handling of Malformed Messages Author(s) : Murray S. Kucherawy Gregory N. Shapiro N. Freed Filename : draft-ietf-appsawg-malformed-mail-11.txt Pages : 22 Date : 2013-11-22 Abstract: Although Internet mail formats have been precisely defined since the 1970s, authoring and handling software often show only mild conformance to the specifications. The malformed messages that result are non-standard. Nonetheless, decades of experience has shown that handling with some tolerance the malformations that result is often an acceptable approach, and is better than rejecting the messages outright as nonconformant. This document includes a collection of the best advice available regarding a variety of common malformed mail situations, to be used as implementation guidance. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-malformed-mail There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-malformed-mail-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-malformed-mail-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Nov 22 23:00:00 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E761AE0E4 for ; Fri, 22 Nov 2013 23:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MM3dikLa0Kq2; Fri, 22 Nov 2013 22:59:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E8B1AE0E6; Fri, 22 Nov 2013 22:59:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-malformed-mail@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131123065956.19859.77527.idtracker@ietfa.amsl.com> Date: Fri, 22 Nov 2013 22:59:56 -0800 Subject: [apps-discuss] New Version Notification - draft-ietf-appsawg-malformed-mail-11.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 07:00:00 -0000 A new version (-11) has been submitted for draft-ietf-appsawg-malformed-mai= l: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-malformed-mail-11.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-malformed-mail/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-malformed-mail-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From barryleiba@gmail.com Sat Nov 23 07:11:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3F81AE116 for ; Sat, 23 Nov 2013 07:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V_dexZO55B9w for ; Sat, 23 Nov 2013 07:11:55 -0800 (PST) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 72EAE1ADFAA for ; Sat, 23 Nov 2013 07:11:55 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id ev20so1769779lab.11 for ; Sat, 23 Nov 2013 07:11:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=JWVSjVLQAYbCFCiMPra9GnuwNAKvWXSL1NjFZd4khws=; b=pO7i1XDMpOIv+WfUaZ5twrzCtYkypGBrQo+k+u/gcGZJF8B/pIpW6PyS9fMPm5YFQ4 0mDi0zdt1NQx5UqIysJvGSUaLjqGiK/JS5olVMop1e4nz+1zLVM4uI6wl1A5BvIqz26/ GHrTClojNZMjdvAx74RVCDX6QaQyszbKu33a7XnoKrLrjS/XHh+y2TEyE9d2h/TiZOv/ LHpWpG3O41yrZOBOBGqSiuUMGQ465DLMILGp/IElSYRrDLUrQmc9dQJXPoVgE0pJy/66 HBwPsNrvMlfUxlW38WjQQH1AWxvadnYuKD5EQa4+bXCbOgUOnOQ01Hkpji4shZbp7lZ4 hccg== MIME-Version: 1.0 X-Received: by 10.112.89.42 with SMTP id bl10mr12888333lbb.18.1385219507353; Sat, 23 Nov 2013 07:11:47 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.112.65.69 with HTTP; Sat, 23 Nov 2013 07:11:47 -0800 (PST) In-Reply-To: <20131123065956.19859.77527.idtracker@ietfa.amsl.com> References: <20131123065956.19859.77527.idtracker@ietfa.amsl.com> Date: Sat, 23 Nov 2013 10:11:47 -0500 X-Google-Sender-Auth: Z_mOjXjCdwaDF--HaGeF1GsBuA4 Message-ID: From: Barry Leiba To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Cc: "appsawg-chairs@tools.ietf.org" , draft-ietf-appsawg-malformed-mail@tools.ietf.org, SM , Apps Discuss Subject: Re: [apps-discuss] New Version Notification - draft-ietf-appsawg-malformed-mail-11.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 23 Nov 2013 15:11:57 -0000 Pete, this version looks like it has your comments covered (except for the Return-Path one that Murray disagreed with). You groovy with it? Shall I press "go"? Barry On Sat, Nov 23, 2013 at 1:59 AM, wrote: > > A new version (-11) has been submitted for draft-ietf-appsawg-malformed-mail: > http://www.ietf.org/internet-drafts/draft-ietf-appsawg-malformed-mail-11.txt > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-malformed-mail/ > > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-malformed-mail-11 > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > IETF Secretariat. > From ned.freed@mrochek.com Sat Nov 23 09:10:58 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962CA1ADFDA; Sat, 23 Nov 2013 09:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rN2Oc_tLaTDT; Sat, 23 Nov 2013 09:10:57 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C9F751ADFA4; Sat, 23 Nov 2013 09:10:56 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P14CWGUI4G0019ZQ@mauve.mrochek.com>; Sat, 23 Nov 2013 09:05:47 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P0USA6030W00004G@mauve.mrochek.com>; Sat, 23 Nov 2013 09:05:43 -0800 (PST) Message-id: <01P14CWFCE5A00004G@mauve.mrochek.com> Date: Sat, 23 Nov 2013 09:04:20 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Fri, 22 Nov 2013 11:39:04 -0800" References: <20131120223533.8958.23858.idtracker@ietfa.amsl.com> To: "Murray S. Kucherawy" Cc: "draft-ietf-appsawg-malformed-mail@tools.ietf.org" , IETF Apps Discuss , Pete Resnick , SM , "appsawg-chairs@tools.ietf.org" , The IESG Subject: Re: [apps-discuss] Pete Resnick's Yes on draft-ietf-appsawg-malformed-mail-10: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 23 Nov 2013 17:10:58 -0000 > All of this works for me except: > On Wed, Nov 20, 2013 at 2:35 PM, Pete Resnick wrote: > > 7.5.3 - What's the harm in more than one Return-Path? Only one of > > interest is the top-most. > > > The issue here is that some components pick the last one, and some pick the > first, in general. More often this happen with From, but Return-Path is > not special in this regard. FWIW, one thing an MDA can do is check and see if the top Return-path: agrees with the current MAIL FROM, and if it does don't add a redundant Return-path: field. Ned From mnot@mnot.net Sun Nov 24 19:18:08 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7991A1F1B for ; Sun, 24 Nov 2013 19:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBtNV0onLyXy for ; Sun, 24 Nov 2013 19:18:06 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 59DDF1A1DFA for ; Sun, 24 Nov 2013 19:18:06 -0800 (PST) Received: from [192.168.1.64] (unknown [118.209.140.7]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 87EA522E257 for ; Sun, 24 Nov 2013 22:18:00 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <94DB0488-0DD8-487F-BAA3-AB0F620C1C0E@mnot.net> Date: Mon, 25 Nov 2013 14:20:17 +1100 To: "apps-discuss@ietf.org Discuss" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [apps-discuss] RFC5988bis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 03:18:08 -0000 Just an FYI -=20 I've started collecting issues against RFC5988 (including from the = errata) here: https://github.com/mnot/I-D/issues?labels=3Drfc5988bis&state=3Dopen Feel free to add some. If things go well, I'll come back here with a proposal for a revision = after working on it a bit.=20 Cheers, -- Mark Nottingham http://www.mnot.net/ From anything@michielbdejong.com Mon Nov 25 04:23:41 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE0D1AD8F1 for ; Mon, 25 Nov 2013 04:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYoiuMLTqBp8 for ; Mon, 25 Nov 2013 04:23:38 -0800 (PST) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8AE1AD8F3 for ; Mon, 25 Nov 2013 04:23:38 -0800 (PST) Received: from mfilter7-d.gandi.net (mfilter7-d.gandi.net [217.70.178.136]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id BB22241C054 for ; Mon, 25 Nov 2013 13:23:37 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter7-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter7-d.gandi.net (mfilter7-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id mMRjsMyVHtJD for ; Mon, 25 Nov 2013 13:23:36 +0100 (CET) X-Originating-IP: 178.19.210.162 Received: from [10.1.248.240] (unknown [178.19.210.162]) (Authenticated sender: anything@michielbdejong.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 26A2441C05A for ; Mon, 25 Nov 2013 13:23:35 +0100 (CET) Message-ID: <52934147.90304@michielbdejong.com> Date: Mon, 25 Nov 2013 13:23:35 +0100 From: "Michiel B. de Jong" User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] remote storage: per-user cloud storage for the web X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 12:23:41 -0000 At http://remotestorage.io/ we are nearing completion of version -02 of the 'remotestorage' internet draft: https://github.com/remotestorage/spec/blob/master/draft-dejong-remotestorage-02.txt After input from stakeholders (current storage providers 5apps.com as well as application developers Nick Jennings and Jan-C. Borchardt), we added the following new features, compared to the -01 version: * all servers should now support HEAD requests in addition to GET, PUT, DELETE and OPTIONS. * all servers should now send Content-Length headers back on HEAD and GET requests. * the folder description ("directory listing", when querying a URL that ends in a slash "/") now gives information about Content-Type and Content-Length as well as ETag, and it is now a JSON-LD document. * optional extension #1: putting the bearer token into the URI query parameter instead of in the Authorization header. * optional extension #2: support for Content-Range headers on GET requests. The document also grew from 10 to 20 pages, mainly because we added wire transcripts, and a computer-science-style discussion of how to do distributed versioning with a remoteStorage server. Comments very very welcome! We are hoping to concentrate more interest in this topic. If you send your comments before 10 December then we can still edit the I-D before we publish it. You can reply to this thread, or open an issue on https://github.com/remotestorage/spec/issues?state=open cheers! Michiel From julian.reschke@gmx.de Mon Nov 25 04:44:26 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79E71AD8EF for ; Mon, 25 Nov 2013 04:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dc-aRTimS1z1 for ; Mon, 25 Nov 2013 04:44:24 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 888001AD687 for ; Mon, 25 Nov 2013 04:44:24 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LhSfM-1VGJnT11FI-00mYSZ for ; Mon, 25 Nov 2013 13:44:23 +0100 Message-ID: <52934626.8060503@gmx.de> Date: Mon, 25 Nov 2013 13:44:22 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Michiel B. de Jong" , apps-discuss@ietf.org References: <52934147.90304@michielbdejong.com> In-Reply-To: <52934147.90304@michielbdejong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:EFDzZY+iwMPX0eyyDf0MOt8ZUmWbc8+Z6KtIdmvm1s1XPmtvnJ1 LKd6rgpRHpVmNusVKr/qJv4nJBy3D6Ivw1ChodZjH4KH37ILep5uRwACguUFk3OV29wCzT+ jsEJQTnMhSVOLUMtKJa23tl4D6/cLvl9Er79nK8fEyD4e7n6H4bV9YYhu2rUBR0LkmLZ5b3 U3ETyIe2P9RNhA1jvaUZA== Subject: Re: [apps-discuss] remote storage: per-user cloud storage for the web X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 12:44:27 -0000 On 2013-11-25 13:23, Michiel B. de Jong wrote: > At http://remotestorage.io/ we are nearing completion of version -02 of > the 'remotestorage' internet draft: > > https://github.com/remotestorage/spec/blob/master/draft-dejong-remotestorage-02.txt > > > After input from stakeholders (current storage providers 5apps.com as > well as application developers Nick Jennings and Jan-C. Borchardt), we > added the following new features, compared to the -01 version: > > * all servers should now support HEAD requests in addition to GET, PUT, > DELETE and OPTIONS. HEAD support is already required by HTTP. > * all servers should now send Content-Length headers back on HEAD and > GET requests. So you don't need support for content that is streamed (length unknown in advance?). > * the folder description ("directory listing", when querying a URL that > ends in a slash "/") now gives information about Content-Type and > Content-Length as well as ETag, and it is now a JSON-LD document. > > * optional extension #1: putting the bearer token into the URI query > parameter instead of in the Authorization header. > > * optional extension #2: support for Content-Range headers on GET requests. > > The document also grew from 10 to 20 pages, mainly because we added wire > transcripts, and a computer-science-style discussion of how to do > distributed versioning with a remoteStorage server. > > Comments very very welcome! We are hoping to concentrate more interest > in this topic. > ... This seems to overlap with WebDAV and AtomPub. Did you consider using one of those? Best regards, Julian From derhoermi@gmx.net Mon Nov 25 05:20:02 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C46D1AD8F1 for ; Mon, 25 Nov 2013 05:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wb3HJphfsiFC for ; Mon, 25 Nov 2013 05:20:00 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id DD88D1ACCE3 for ; Mon, 25 Nov 2013 05:19:59 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.22.235]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0MSdRI-1WCOXy385c-00RXJZ for ; Mon, 25 Nov 2013 14:19:59 +0100 From: Bjoern Hoehrmann To: Mark Nottingham Date: Mon, 25 Nov 2013 14:19:59 +0100 Message-ID: References: <94DB0488-0DD8-487F-BAA3-AB0F620C1C0E@mnot.net> In-Reply-To: <94DB0488-0DD8-487F-BAA3-AB0F620C1C0E@mnot.net> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:4Jc6GhBX3yCCA9Fv/fwQow6lYft2rvMMz8HDG2ADlWFWNGMCpnp O/R95/wxvbFuwa3CdIxa3W/cTHBAQWEZ3wzYmfnueT9qi/P9i1ugVVWR4Q5PQlIbALaZFjf 6b2MaO89ar450V9bRHcru133IO+xoIWxYE65vteHzUnE8/GTSSQQ8NTvprxMviOsKpc6bZc 2wUqAsJCfH2jIoZVFW4QQ== Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] RFC5988bis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 13:20:02 -0000 * Mark Nottingham wrote: >I've started collecting issues against RFC5988 (including from the errata) here: > https://github.com/mnot/I-D/issues?labels=rfc5988bis&state=open > >Feel free to add some. Given that Within at most 14 days of the request, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. ... does not happen in practise, revising the registration process should be a primary concern. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From anything@michielbdejong.com Mon Nov 25 06:19:20 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77031AD8F1 for ; Mon, 25 Nov 2013 06:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzDxAzjLiHAW for ; Mon, 25 Nov 2013 06:19:18 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) by ietfa.amsl.com (Postfix) with ESMTP id AACD71AD72A for ; Mon, 25 Nov 2013 06:19:18 -0800 (PST) Received: from mfilter28-d.gandi.net (mfilter28-d.gandi.net [217.70.178.159]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 27454A80D5; Mon, 25 Nov 2013 15:19:18 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter28-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter28-d.gandi.net (mfilter28-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id NRsU7NjAhO0B; Mon, 25 Nov 2013 15:19:16 +0100 (CET) X-Originating-IP: 178.19.210.162 Received: from [10.1.248.240] (unknown [178.19.210.162]) (Authenticated sender: anything@michielbdejong.com) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 3DCECA80E9; Mon, 25 Nov 2013 15:19:15 +0100 (CET) Message-ID: <52935C62.1010301@michielbdejong.com> Date: Mon, 25 Nov 2013 15:19:14 +0100 From: "Michiel B. de Jong" User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Julian Reschke , apps-discuss@ietf.org References: <52934147.90304@michielbdejong.com> <52934626.8060503@gmx.de> In-Reply-To: <52934626.8060503@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] remote storage: per-user cloud storage for the web X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 14:19:20 -0000 hi Julian, thanks for your comments! On 25-Nov-13 13:44, Julian Reschke wrote: > HEAD support is already required by HTTP. true, but we never said servers should implement all of HTTP. For instance, chunked transfer-coding is also required by HTTP/1.1 and we also don't require servers to support that. is that not clear from the text? maybe we should mention that explicitly, then. >> * all servers should now send Content-Length headers back on HEAD and >> GET requests. > > So you don't need support for content that is streamed (length unknown > in advance?). correct. it's just a simple file-system-like storage, no streaming. > This seems to overlap with WebDAV and AtomPub. Did you consider using > one of those? yes, we actually started with full WebDAV, and then looked at what we could remove. we consider the actual REST interface to the simplest part actually, it's just pretty standard read-write web. very similar to the API that GoogleDrive and Dropbox expose. there are a few choices in the format, but that's pretty trivial to abstract from. the innovation, we believe, is in the combination with: * CORS headers, * client-side OAuth (not by default leaking credentials to any server), * WebFinger for per-user service discovery, making it usable as a per-user data storage. See http://nobackend.org/2013/11/cross-origin-backend.html for discussion. Cheers, Michiel From julian.reschke@gmx.de Mon Nov 25 06:23:01 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643D01AD9AC for ; Mon, 25 Nov 2013 06:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9DaGNGYoTgx for ; Mon, 25 Nov 2013 06:23:00 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0597E1AD72A for ; Mon, 25 Nov 2013 06:23:00 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MZlEg-1W5Djx1mda-00LSWr for ; Mon, 25 Nov 2013 15:22:59 +0100 Message-ID: <52935D42.4040506@gmx.de> Date: Mon, 25 Nov 2013 15:22:58 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Michiel B. de Jong" , apps-discuss@ietf.org References: <52934147.90304@michielbdejong.com> <52934626.8060503@gmx.de> <52935C62.1010301@michielbdejong.com> In-Reply-To: <52935C62.1010301@michielbdejong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:nfy62zXTR5z0MMZ5AjdLXrJpp6cTiI+mhu4LZHJwsJ1RmJu5eL3 t3UnHiVdxs3sF2VtaNdWLRAeLetADsM2wSoKOkYE1f8S0i4DDqEN6sFyGfdmARB6o9GIFZP c+GHANEfur5yE35S8al6Az+qh0RlJxHl1rpUZFIFCmGIC2gNn3NSsPBbukDhd6jR9V1aEGj mUuryry5tTmMqR7hsMnhA== Subject: Re: [apps-discuss] remote storage: per-user cloud storage for the web X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 14:23:01 -0000 On 2013-11-25 15:19, Michiel B. de Jong wrote: > hi Julian, > > thanks for your comments! > > On 25-Nov-13 13:44, Julian Reschke wrote: >> HEAD support is already required by HTTP. > > true, but we never said servers should implement all of HTTP. For > instance, chunked transfer-coding is also required by HTTP/1.1 and we > also don't require servers to support that. is that not clear from the > text? maybe we should mention that explicitly, then. So you are sub-setting HTTP? Not a good idea. > ... Best regards, Julian From jan.algermissen@nordsc.com Mon Nov 25 06:25:24 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F421ADD9D for ; Mon, 25 Nov 2013 06:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbb_GoRPjS_B for ; Mon, 25 Nov 2013 06:25:22 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 963ED1ADBCB for ; Mon, 25 Nov 2013 06:25:22 -0800 (PST) Received: from [10.90.135.199] ([87.253.171.196]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0M8mxE-1Vx4ad3LSe-00C7rI; Mon, 25 Nov 2013 15:25:15 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jan Algermissen In-Reply-To: <52935D42.4040506@gmx.de> Date: Mon, 25 Nov 2013 15:25:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52934147.90304@michielbdejong.com> <52934626.8060503@gmx.de> <52935C62.1010301@michielbdejong.com> <52935D42.4040506@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1510) X-Provags-ID: V02:K0:nJcpoMZyEkqb6eerGMd8Qc3p3ie5eeqXcXxJrXmJ+hz hmPFMboeEGmROyjtpEicA+8M+7AlQaZrlau1gpU4/ar3sOzfhW CiamRSahOM0OwsDAdEE+3oIpFmCcH0qet0QyP1DCmWCg+aW2a/ Z+aFXpgQNzXzwA9Yg5HEnvfLtLmGgfXMf2CEQ1xkWeCtuhGn9V pLgowTD6LJ0uz7WYRkBHzBy3upYSphIauSMMt2mvD00YS775Cx zlAFBgBPqyGRY3M+PMUkjLVzDAUyK2HVeQY8i75k9JwyASI9cu bywdRKNI3mZn3OZcc65a0REYIouG/quyGY1xZ+Yyi+Ukur13jH shaX/VT8UPLj1Q6gK0DZOgXfWfNbWwrlONHvqWSC25zMwgDLj6 b/vfK6AHsaBjw== Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] remote storage: per-user cloud storage for the web X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 14:25:24 -0000 On 25.11.2013, at 15:22, Julian Reschke wrote: > On 2013-11-25 15:19, Michiel B. de Jong wrote: >> hi Julian, >>=20 >> thanks for your comments! >>=20 >> On 25-Nov-13 13:44, Julian Reschke wrote: >>> HEAD support is already required by HTTP. >>=20 >> true, but we never said servers should implement all of HTTP. For >> instance, chunked transfer-coding is also required by HTTP/1.1 and we >> also don't require servers to support that. is that not clear from = the >> text? maybe we should mention that explicitly, then. >=20 > So you are sub-setting HTTP? Not a good idea. In addition: Why would you need to subset HTTP? The off-the shelf = connectors implement it already anyhow. Where is the point? Jan >=20 >> ... >=20 > Best regards, Julian > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From dave@cridland.net Mon Nov 25 06:47:16 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC94D1ADE72 for ; Mon, 25 Nov 2013 06:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhx1KgGGDCCx for ; Mon, 25 Nov 2013 06:47:15 -0800 (PST) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 04EA41ADC03 for ; Mon, 25 Nov 2013 06:47:14 -0800 (PST) Received: by mail-oa0-f54.google.com with SMTP id h16so4450476oag.13 for ; Mon, 25 Nov 2013 06:47:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5Ke3lBOmij54y/LwBZXOhS4LOTIWnEciz9JASr5fdtY=; b=VIfSLI6q1f1Xpp2DFAGCx3AJ0NRV5IT2VpLQO6ZBNuT9oqv4E3aHxTNSSCnCag2XQQ wyoIvrhNqNxA465eG67c9gtV5nEdXvKEOu+bAJadWe/HdRfJjVI6I23B5wEt1PMowCoq 6y83EioW3URHcYoziwjhp1eaXbXINqWULhO+Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5Ke3lBOmij54y/LwBZXOhS4LOTIWnEciz9JASr5fdtY=; b=gVouDQ5oZu0pP2WPj2Y0kShY1QeZuXatw//MUtMgDNVWdSs8HaDwqTbT+UjtNNcSRS w7IaWunCKx2Kdy3IFWo5B7EAxEHpOwAgwRkmENJBYsnzs9b5KV0o9h7sdsfa/3VUYWcE L1yssm0RSq3plXvjmqg5t+tTcx+A5sQTSLSeM+tGV3+Caj7p8v4Fh0RxS+3hCFXKUQtc wzb6zFr7nJJ1PA3RjXm3/uvmM3pfr/kJn8pxT37uKXq8d+3n43ypQPWXrIX2oMiiKnYa jDecEX4nl+T/2/uLVq3cgVIEZv5unqC9KgbgxJzxJgOyFYE9pObzPqz6vgTSbLrh3zaX WZhA== X-Gm-Message-State: ALoCoQlJ1wqgPO3xHRHV5xlWWZhZNRcS11O/50kCtyzs0SEybAUB8XsXhcdE6836ZdPVyVsNp3sU MIME-Version: 1.0 X-Received: by 10.182.230.135 with SMTP id sy7mr25034316obc.24.1385390835044; Mon, 25 Nov 2013 06:47:15 -0800 (PST) Received: by 10.60.121.97 with HTTP; Mon, 25 Nov 2013 06:47:14 -0800 (PST) In-Reply-To: <52935C62.1010301@michielbdejong.com> References: <52934147.90304@michielbdejong.com> <52934626.8060503@gmx.de> <52935C62.1010301@michielbdejong.com> Date: Mon, 25 Nov 2013 14:47:14 +0000 Message-ID: From: Dave Cridland To: "Michiel B. de Jong" Content-Type: multipart/alternative; boundary=001a11c336769991d804ec01703a Cc: Julian Reschke , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] remote storage: per-user cloud storage for the web X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 14:47:17 -0000 --001a11c336769991d804ec01703a Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 25, 2013 at 2:19 PM, Michiel B. de Jong < anything@michielbdejong.com> wrote: > hi Julian, > > thanks for your comments! > > > On 25-Nov-13 13:44, Julian Reschke wrote: > >> HEAD support is already required by HTTP. >> > > true, but we never said servers should implement all of HTTP. For > instance, chunked transfer-coding is also required by HTTP/1.1 and we also > don't require servers to support that. is that not clear from the text? > maybe we should mention that explicitly, then. > > Oh, dear lord, that is horrible. Your document actually says it's based on HTTPS, and the only hint that you're intending to subset is that both HTTP and HTTPS are informative references. If you're expecting to chop up HTTP in a sane way without respecifying it, I think you're onto a loser. If I implementing this according to your specification, I would start with an HTTP implementation and move on from there - if your protocol differs from HTTP, then that's a non-starter - at the very least I'll need to ensure I can turn off whichever features is it you're implicitly casting aside. The latter certainly involves being very careful about the library I use. In the case of chunked encoding, I find it actually quite useful for anything but static files. FWIW, I recently worked with a remote-storage style API, and found the lack of chunked encoding support in this particular implementation to be a real pest. For one thing, I was dealing with CTE encoded email parts, and an exact length is hard to determine before decoding (and often impossible without having the data to hand). > * all servers should now send Content-Length headers back on HEAD and >>> GET requests. >>> >> >> So you don't need support for content that is streamed (length unknown in >> advance?). >> > > correct. it's just a simple file-system-like storage, no streaming. > > This is a bad idea. It'd be reasonable if the underlying building blocks didn't support this, but they do already, so you're not restricting your goals, but restricting your use-cases. I also have to carefully ensure my HTTP library doesn't switch to using Chunked, making it a not-HTTP library. I have no idea what else I need to turn off. > > This seems to overlap with WebDAV and AtomPub. Did you consider using one >> of those? >> > > yes, we actually started with full WebDAV, and then looked at what we > could remove. > > Have you had any reviews or opinions from WebDAV experts? I appreciate that WebDAV is a complex protocol, and as the highest point on the stack it's the logistically easiest thing to reinvent, but I'd be interested in whether the likes of Lisa Dusseault have made any comments here. It could be that they'll be able to give you useful directions to explore that'd give you the overall requirements you're seeking to fill without a lot of the excess you're hoping to avoid - and not preclude use of things like WebDAV in the future. Dave. --001a11c336769991d804ec01703a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 25, 2013 at 2:19 PM, Michiel B. de Jong <anything@michielbdejong.com> wrote:
hi Julian,

thanks for your comments!


On 25-Nov-13 13:44, Julian Reschke wrote:
HEAD support is already required by HTTP.

true, but we never said servers should implement all of HTTP. For instance,= chunked transfer-coding is also required by HTTP/1.1 and we also don't= require servers to support that. is that not clear from the text? maybe we= should mention that explicitly, then.


Oh, dear lord, that is horrible.= Your document actually says it's based on HTTPS, and the only hint tha= t you're intending to subset is that both HTTP and HTTPS are informativ= e references.

If you're expecting to chop up HTTP in a sane way w= ithout respecifying it, I think you're onto a loser.

If I implementing this according to your specification, I would star= t with an HTTP implementation and move on from there - if your protocol dif= fers from HTTP, then that's a non-starter - at the very least I'll = need to ensure I can turn off whichever features is it you're implicitl= y casting aside. The latter certainly involves being very careful about the= library I use.

In the case of chunked encoding, I find it actually qui= te useful for anything but static files. FWIW, I recently worked with a rem= ote-storage style API, and found the lack of chunked encoding support in th= is particular implementation to be a real pest. For one thing, I was dealin= g with CTE encoded email parts, and an exact length is hard to determine be= fore decoding (and often impossible without having the data to hand).


* all servers should now send Content-Length headers back on HEAD and
GET requests.

So you don't need support for content that is streamed (length unknown = in advance?).

correct. it's just a simple file-system-like storage, no streaming.

This is a bad idea= .

It'd be reasonable if the underlying buildin= g blocks didn't support this, but they do already, so you're not re= stricting your goals, but restricting your use-cases. I also have to carefu= lly ensure my HTTP library doesn't switch to using Chunked, making it a= not-HTTP library. I have no idea what else I need to turn off.
=A0

This seems to overlap with WebDAV and AtomPub. Did you consider using one o= f those?

yes, we actually started with full WebDAV, and then looked at what we could= remove.


Have you had any reviews or opinions f= rom WebDAV experts? I appreciate that WebDAV is a complex protocol, and as = the highest point on the stack it's the logistically easiest thing to r= einvent, but I'd be interested in whether the likes of Lisa Dusseault h= ave made any comments here.

It could be that they'll be able to give you useful= directions to explore that'd give you the overall requirements you'= ;re seeking to fill without a lot of the excess you're hoping to avoid = - and not preclude use of things like WebDAV in the future.

Dave.
--001a11c336769991d804ec01703a-- From julian.reschke@gmx.de Mon Nov 25 07:20:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754791ADEBB for ; Mon, 25 Nov 2013 07:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlYGKmcp2iXB for ; Mon, 25 Nov 2013 07:20:19 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCED1ADEA7 for ; Mon, 25 Nov 2013 07:20:19 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MELdk-1VrXWU1cJE-00FUlJ for ; Mon, 25 Nov 2013 16:20:18 +0100 Message-ID: <52936AB1.4060505@gmx.de> Date: Mon, 25 Nov 2013 16:20:17 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Mark Nottingham , "apps-discuss@ietf.org Discuss" References: <94DB0488-0DD8-487F-BAA3-AB0F620C1C0E@mnot.net> In-Reply-To: <94DB0488-0DD8-487F-BAA3-AB0F620C1C0E@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:DB9uYcN/eO8Yvtp2R6LEfR6R34irDFXfP6En7bM6aEvFsPGIn0S Tc7cnsctRMgryKQ6gBnEqbgMIDC2hiTzL5AA0ccin5XZ8lNvK5WkKJdWOx3ZmJGhZrw/5q3 3hBMcoU0v7ANQgWIrhymUSeFk5XV2gbh8rxIAnwj/DSFevQ9ZNwMt0JRYZNBKY9oHfTsWt8 hqU3Yu/P/ZAq0cXFAAgkw== Subject: Re: [apps-discuss] RFC5988bis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 15:20:21 -0000 On 2013-11-25 04:20, Mark Nottingham wrote: > Just an FYI - > > I've started collecting issues against RFC5988 (including from the errata) here: > https://github.com/mnot/I-D/issues?labels=rfc5988bis&state=open > > Feel free to add some. > > If things go well, I'll come back here with a proposal for a revision after working on it a bit. > ... I'll likely finish the work on , so it can use an updated reference. Question: RFC 5987 ("Indicating Character Encoding and Language for HTTP Header Field Parameters") was a private, AD-sponsored, standards track document. For a revision, should I move to either httpbis or appsawg? Best regards, Julian From alexey.melnikov@isode.com Mon Nov 25 11:02:40 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20F91ADFFA; Mon, 25 Nov 2013 11:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.471 X-Spam-Level: X-Spam-Status: No, score=-0.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYsYgm85qFR4; Mon, 25 Nov 2013 11:02:39 -0800 (PST) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id AD05C1AE01B; Mon, 25 Nov 2013 11:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1385406158; d=isode.com; s=selector; i=@isode.com; bh=GfpG0Fs9pF2cRVlM9crw6wdDfivZLywx72Q2QewkL6U=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=lkTUGcXyoguaz2VXajh+AKxh8yUA/2pQPnCPnD9krjbo6JZBJfvJoXnqcM4jNFHrGJlTtC xq7g8NoMFa3FY0eKhXcrCcR7iD5H0/KnDAuNMSk3oyJ4hm6ZAxzcRF35ovhnJFz4kOMNW1 DbCthzDPQThAqAq1dRlcMNEpsoji0f4=; Received: from [192.168.0.7] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 25 Nov 2013 19:02:38 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <52939ECD.7010107@isode.com> Date: Mon, 25 Nov 2013 19:02:37 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Claudio Allocchio References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Cc: draft-ietf-qresync-rfc5162bis.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR Early review of draft-ietf-qresync-rfc5162bis-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 19:02:41 -0000 Hi Claudio, Thank you for your review. My replies are below. On 22/11/2013 15:37, Claudio Allocchio wrote: > > This is an Early Review, no IETF LC issued yet. > > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see > =E2=80=8B=20 > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate= =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. > > Document: draft-ietf-qresync-rfc5162bis-03.txt > Title: IMAP Extensions for Conditional STORE Operation or Quick Flag > Changes Resynchronization (CONDSTORE) and Quick Mailbox > Resynchronization (QRESYNC) > Reviewer: Claudio Allocchio > Review Date: Nov 19th 2013 > IETF Last Call Date: N/A > IESG Telechat Date: N/A > > Summary: This draft is almost ready for publication as an Informational > RFC. It describes in details (maybe even in too much detail in the=20 > Introduction and Overview, but I do not see this as a problem) the=20 > extensions and possible scenarios. Just some minor issues to check. > > Major issues: > > none. > > Minor issues: > > Abstract: > > - When you state "They must be able to guarantee that only one client=20 > can change message state (e.g., message flags) at any time." IMHO=20 > there is chance that one implementer might undestand that only one=20 > client at a time shall be granted permission to change message=20 > state/flags al ALL messages in the mailbox, while we just mean=20 > "message flags/state of the specific message you are looking at".=20 > Maybe a text like: > > "They must be able to guarantee that only one client can change=20 > message state (e.g., message flags of the specific message being=20 > looked up) at any time." Ok, changed. > 1. Introduction and overview > > - In general, this is more a "condensed summary" of the specification=20 > than an introduction or overview. Maybe a different title... I shall=20 > say that it is quite unusual to have such a precise summary of the=20 > specification (with references to following section) at the beginning=20 > of a specification. Nothing wrong, but again it make me thing the=20 > title of this section is wrong. Yes, this is somewhat related to Eliot's comments. I don't think this is=20 a problem per se, but some restructuring might be in order. > - When you talk about QRESYNC, saying that on a mobile client it can=20 > "reduce the expense" maybe is not appropriate for a technical=20 > specification (and many people run on flat-rate data plans...) It is still translates to cost of traffic in many environments, but the=20 comment wasn't really adding much to the document, so I deleted it. > - "Since CONDSTORE is a relatively new extension, it is thought likely=20 > that clients that support it will also support QRESYNC." why not turn=20 > this into a reccomendation? Or add a reccomendation that both should=20 > be supported? I think client implementors who look at this document would support both=20 for the reason stated. But clients also need to be able to cope with=20 servers that only support CONDSTORE (which is more widespread). So I can=20 make it a recommendation, but it can't be normative. > 3.1.1 > > I suggest "One of these two response codes MUST be returned" Done. > 3.1.2 > > Note after Example 8. > > " Note: A client trying to make an atomic change to the state of a > particular metadata item (or a set of metadata items) should be > prepared to deal with the case when the server returns the MODIFIED" > > ... it's inside a "note:" ... however I have some doubts that "should"=20 > needs to be an uppercase normative SHOULD. I am not sure that normative language is needed here, but I think MUST=20 is actually more appropriate. > Same (minor!) issue also later after Example 10 for the "may": > > "The following example is based on the example from the Section 4.2.3 > of [RFC2180] and demonstrates that the MODIFIED response code may be > also returned in the tagged NO response." Ok. > ... again, after Example 11: > > "the server must not fail the operation for message 7 as part of > processing "3:9" if it succeeded when message 7 was processed the > first time." (MUST NOT?) As this is an example, I would rather keep it non normative. > 3.1.4 > > again as above: > > " The last means that the server should use > the biggest value among "priv" and "shared" mod-sequences" > > (SHOULD?) I think this is a MUST. > 3.1.10 > > " Server implementations should follow the following rule," (SHOULD?) Actually, the text that follows already uses SHOULD NOT, so adding=20 SHOULD here would not add clarity. > 6. > > again: " An advanced disconnected mail client should use the QRESYNC" > (SHOULD?) Changed. > NOTE: All the above refers to client/serve actions, that's why I've=20 > the feeling we shall use normative uppercase. > > > Nits: > > none. From ietf-secretariat-reply@ietf.org Mon Nov 25 14:54:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3FF1AE093 for ; Mon, 25 Nov 2013 14:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtpMfgVak_51; Mon, 25 Nov 2013 14:54:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E548C1AE092; Mon, 25 Nov 2013 14:54:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-malformed-mail@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131125225426.14059.70994.idtracker@ietfa.amsl.com> Date: Mon, 25 Nov 2013 14:54:26 -0800 From: IETF Secretariat Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 22:54:30 -0000 State changed to Approved-announcement to be sent from Approved-announcemen= t to be sent::Point Raised - writeup needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-malforme= d-mail/ From ietf-secretariat-reply@ietf.org Mon Nov 25 15:24:10 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F65E1AE0A8 for ; Mon, 25 Nov 2013 15:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZMJRvlyXT5Y; Mon, 25 Nov 2013 15:24:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E25641AE0BA; Mon, 25 Nov 2013 15:24:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-malformed-mail@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131125232405.14041.47896.idtracker@ietfa.amsl.com> Date: Mon, 25 Nov 2013 15:24:05 -0800 From: IETF Secretariat Subject: [apps-discuss] ID Tracker State Update Notice: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 23:24:10 -0000 IESG has approved the document and state has been changed to Approved-annou= ncement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-malforme= d-mail/ From Claudio.Allocchio@garr.it Tue Nov 26 02:00:48 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D921AE144; Tue, 26 Nov 2013 02:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.122 X-Spam-Level: X-Spam-Status: No, score=-0.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4ZntYDB44eV; Tue, 26 Nov 2013 02:00:46 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id C32DB1AE133; Tue, 26 Nov 2013 02:00:45 -0800 (PST) Received: internal info suppressed Date: Tue, 26 Nov 2013 11:00:39 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3 To: Alexey Melnikov In-Reply-To: <52939ECD.7010107@isode.com> Message-ID: References: <52939ECD.7010107@isode.com> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1428318578-1385460042=:25707" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1385460041; bh=2biHwIzPqfr9yuLMVzrPjmw0EaLhwvIs5qk4uqyLUgE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=jZ+DjH+MkSo7dqk8F32sZPrnOXTmFZU/yZadXokOU905s6iuTs1co4eHUA3tQlXVT ss4WMV4oLEhRYKm/qiCrYiGk0ZBwGOtQEXgFU+xqgEUZBFd1WOss6ylpE8tGDacaV4 jzD2Re3oPlc53v7s90qDn/NCA8ZhotxxaFYLIMSc= Cc: draft-ietf-qresync-rfc5162bis.all@tools.ietf.org, apps-discuss@ietf.org, iesg@ietf.org Subject: Re: [apps-discuss] APPSDIR Early review of draft-ietf-qresync-rfc5162bis-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 10:00:48 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1428318578-1385460042=:25707 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Thanks Alexey! all fine for me now! On Mon, 25 Nov 2013, Alexey Melnikov wrote: > Hi Claudio, > Thank you for your review. My replies are below. > > On 22/11/2013 15:37, Claudio Allocchio wrote: >> >> This is an Early Review, no IETF LC issued yet. >> >> I have been selected as the Applications Area Directorate reviewer for >> this draft (for background on appsdir, please see >> ​http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate >> ). >> >> 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-qresync-rfc5162bis-03.txt >> Title: IMAP Extensions for Conditional STORE Operation or Quick Flag >> Changes Resynchronization (CONDSTORE) and Quick Mailbox >> Resynchronization (QRESYNC) >> Reviewer: Claudio Allocchio >> Review Date: Nov 19th 2013 >> IETF Last Call Date: N/A >> IESG Telechat Date: N/A >> >> Summary: This draft is almost ready for publication as an Informational >> RFC. It describes in details (maybe even in too much detail in the >> Introduction and Overview, but I do not see this as a problem) the >> extensions and possible scenarios. Just some minor issues to check. >> >> Major issues: >> >> none. >> >> Minor issues: >> >> Abstract: >> >> - When you state "They must be able to guarantee that only one client can >> change message state (e.g., message flags) at any time." IMHO there is >> chance that one implementer might undestand that only one client at a time >> shall be granted permission to change message state/flags al ALL messages >> in the mailbox, while we just mean "message flags/state of the specific >> message you are looking at". Maybe a text like: >> >> "They must be able to guarantee that only one client can change message >> state (e.g., message flags of the specific message being looked up) at any >> time." > Ok, changed. > >> 1. Introduction and overview >> >> - In general, this is more a "condensed summary" of the specification than >> an introduction or overview. Maybe a different title... I shall say that it >> is quite unusual to have such a precise summary of the specification (with >> references to following section) at the beginning of a specification. >> Nothing wrong, but again it make me thing the title of this section is >> wrong. > Yes, this is somewhat related to Eliot's comments. I don't think this is a > problem per se, but some restructuring might be in order. > >> - When you talk about QRESYNC, saying that on a mobile client it can >> "reduce the expense" maybe is not appropriate for a technical specification >> (and many people run on flat-rate data plans...) > > It is still translates to cost of traffic in many environments, but the > comment wasn't really adding much to the document, so I deleted it. > >> - "Since CONDSTORE is a relatively new extension, it is thought likely that >> clients that support it will also support QRESYNC." why not turn this into >> a reccomendation? Or add a reccomendation that both should be supported? > I think client implementors who look at this document would support both for > the reason stated. But clients also need to be able to cope with servers that > only support CONDSTORE (which is more widespread). So I can make it a > recommendation, but it can't be normative. > >> 3.1.1 >> >> I suggest "One of these two response codes MUST be returned" > Done. >> 3.1.2 >> >> Note after Example 8. >> >> " Note: A client trying to make an atomic change to the state of a >> particular metadata item (or a set of metadata items) should be >> prepared to deal with the case when the server returns the MODIFIED" >> >> ... it's inside a "note:" ... however I have some doubts that "should" >> needs to be an uppercase normative SHOULD. > I am not sure that normative language is needed here, but I think MUST is > actually more appropriate. > >> Same (minor!) issue also later after Example 10 for the "may": >> >> "The following example is based on the example from the Section 4.2.3 >> of [RFC2180] and demonstrates that the MODIFIED response code may be >> also returned in the tagged NO response." > Ok. >> ... again, after Example 11: >> >> "the server must not fail the operation for message 7 as part of >> processing "3:9" if it succeeded when message 7 was processed the >> first time." (MUST NOT?) > As this is an example, I would rather keep it non normative. >> 3.1.4 >> >> again as above: >> >> " The last means that the server should use >> the biggest value among "priv" and "shared" mod-sequences" >> >> (SHOULD?) > I think this is a MUST. > >> 3.1.10 >> >> " Server implementations should follow the following rule," (SHOULD?) > Actually, the text that follows already uses SHOULD NOT, so adding SHOULD > here would not add clarity. > >> 6. >> >> again: " An advanced disconnected mail client should use the QRESYNC" >> (SHOULD?) > Changed. >> NOTE: All the above refers to client/serve actions, that's why I've the >> feeling we shall use normative uppercase. >> >> >> Nits: >> >> none. > > ------------------------------------------------------------------------------ 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 --0-1428318578-1385460042=:25707-- From blueroofmusic@gmail.com Tue Nov 26 08:50:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF23E1AD8F0 for ; Tue, 26 Nov 2013 08:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-HSnyfo1vRz for ; Tue, 26 Nov 2013 08:50:53 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id AC3C01A1F55 for ; Tue, 26 Nov 2013 08:50:53 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id at1so9316015iec.7 for ; Tue, 26 Nov 2013 08:50:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=CPTMQ8uBupgWM48MbSGKp/0sqWwzFyWjJIF1HZCRoyg=; b=0PJZOIKbX2zhPf5Xy1cdrZYbVIjEt7+YLscFIogak9XdeY+q026/LhEXBin6SFMbY2 LmcPg0ustzhgh30cUcK4eialOvWWS7t6j872kFmoJ+mcnpmnw9bmc+eOCJzKoFrLkcv2 L2NpUSQO8qbG+wsmVdG7qx72z4hcyVnTNjnWgt22F9T74HyfXW67+NeUtB81LSk9lsFP dyCIOOB73sg/X2RrXki0jOltFlhvtuUz24gUYtedIS3hmnW524ZxkLOVq+3adXhl8BUH 4RXQxIzTsJgZ0V10dZo9huZ4/N0vrCWti8fI38RCS3zUe0fgRz6PTyDxlLh0c0AeqQ5b 0oyA== X-Received: by 10.42.12.80 with SMTP id x16mr2072426icx.56.1385484653444; Tue, 26 Nov 2013 08:50:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.203.38 with HTTP; Tue, 26 Nov 2013 08:50:32 -0800 (PST) From: Ira McDonald Date: Tue, 26 Nov 2013 11:50:32 -0500 Message-ID: To: Alexey Melnikov , Ira McDonald Content-Type: multipart/alternative; boundary=20cf301cc6b89c43e104ec174879 Cc: Pat Fleming , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [IETF procedure question] AppsDir review of draft-mcdonald-ldap-printer-schema-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 16:50:57 -0000 --20cf301cc6b89c43e104ec174879 Content-Type: text/plain; charset=ISO-8859-1 Hi Alexey, I'm confused about current IETF procedures. You requested that I should NOT post a new draft until directed to do so by my document shepherd or AD. But, according to the IETF datatracker there is NO assigned document shepherd or AD for this document: http://datatracker.ietf.org/doc/draft-mcdonald-ldap-printer-schema/ And the same holds true for the closely related IPPS URI Scheme draft: http://datatracker.ietf.org/doc/draft-mcdonald-ipps-uri-scheme/ How do I get a responsible AD or document shepherd assigned to these documents? Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Fri, Nov 22, 2013 at 1:14 PM, Ira McDonald wrote: > Hi Alexey, > > Thanks for you excellent comments! My apologies for not acknowledging > them sooner. > > I need to think about resolutions and discuss w/ the IEEE-ISTO PWG > Internet Printing > Protocol WG, so I'll be a week or so responding yet (our next meeting is 2 > December). > > Cheers, > - Ira (co-editor of LDAP Printer Schema, co-chair of PWG IPP WG) > > > Ira McDonald (Musician / Software Architect) > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music / High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto: blueroofmusic@gmail.com > Winter 579 Park Place Saline, MI 48176 734-944-0094 > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 > > > > On Mon, Nov 18, 2013 at 10:37 AM, Alexey Melnikov < > alexey.melnikov@isode.com> wrote: > >> On 19/09/2013 17:34, Ira McDonald wrote: >> >>> Hello, >>> >>> The IEEE-ISTO PWG Internet Printing Protocol WG would like to request >>> IETF Apps Area review of our updated LDAP Printer Schema (updates >>> RFC 3712). >>> >>> http://www.ietf.org/internet-drafts/draft-mcdonald-ldap- >>> printer-schema-05.txt >>> >>> Cheers, >>> - Ira (co-chair of IEEE-ISTO PWG IPP WG and co-editor of this document) >>> >> >> My apologies for belated review. I hope you find them useful. >> >> ----------------------------------------- >> >> I have been selected as the Applications Area Directorate reviewer for >> this draft (for background on APPSDIR, please see >> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). >> >> 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-mcdonald-ldap-printer-schema-05.txt >> Title: Lightweight Directory Access Protocol (LDAP): Schema for Printer >> Services >> Reviewer: Alexey Melnikov >> Review Date: November 18, 2013 >> IETF Last Call Date: N/A >> >> Summary: This draft is nearly reading for publication. >> >> This document defines a schema, object classes and attributes, for >> Printers and Print Services, for use with directories that support >> Lightweight Directory Access Protocol (RFC 4510). This document is >> based on the Printer attributes listed in Appendix E of Internet >> Printing Protocol/1.1 (IPP) (RFC 2911). Additional Printer >> attributes are based on definitions in the Printer MIB v2 (RFC 3805), >> IEEE-ISTO PWG Command Set for IEEE 1284 Device ID (PWG 5107.2), >> IEEE-ISTO PWG IPP Job and Printer Extensions - Set 3 (PWG 5100.13), >> and IEEE-ISTO PWG IPP Everywhere (PWG 5100.14). >> >> This document is published by the IETF on behalf of the Internet >> Printing Protocol Working Group of the IEEE-ISTO Printer Working >> Group. >> >> >> Most of the issues I found are minor. In general the document is quite >> readable. >> >> General comments: >> >> I noticed that you redifined various syntaxes to have upper limits on >> Directory strings. URI and Language Tags have no upper limits. I suspect >> that limits that you added are going to be sufficient in most cases, but it >> would be better for your document to call these out explicitly in text. >> >> >> In Section 1: >> >> This document updates RFC 3712. >> >> But the draft header says that it Obsoletes it. I think Obsolete is >> correct, so the statement in Section 1 should be updated to match. >> >> >> In Section 3.3: >> >> Note: When extending other structural classes with auxiliary >>> classes, printerService SHOULD not be used. >>> >> You should also capitalize "not" according to RFC 2119. There are >> multiple occurrences of the same problem in multiple places in the document. >> >> >> 3.4. printerServiceAuxClass >>> ( 1.3.18.0.2.6.257 >>> NAME 'printerServiceAuxClass' >>> DESC 'Printer information.' >>> >>> Fleming, McDonald Expires 19 March 2014 [Page 11] >>> >>> Internet-Draft LDAP Schema for Printer Services 19 September 2013 >>> >>> AUXILIARY >>> SUP printerAbstract >>> MAY ( printer-uri $ >>> printer-xri-supported ) >>> ) >>> This auxiliary class defines Printer information. It is derived >>> from >>> class printerAbstract and thus inherits common Printer attributes. >>> This class SHOULD be used with a structural class. >>> >> Each directory entry requires a structural object class, so I think this >> SHOULD is misleading. Also, why is this not a MUST? >> I suggest you just delete this sentence or reword it to make it non >> normative (and point to the document which makes the authoritative >> statement on this matter.) >> >> >> Similar text in 3.5 and 3.6. >> >> 4. Definition of Attribute Types >>> >>> The following attribute types reference matching rule names (instead >>> of OIDs) for clarity (see Section 6 below). For optional attributes, >>> if the Printer information is not known, the attribute value SHOULD >>> not be set. In the following definitions, referenced matching rules >>> are defined in Section 4 of [RFC4517] (see Section 6 'Definition of >>> Matching Rules' below). >>> >> >> I think you still meant section 4. >> >> Note: For interoperability and consistent text display, values of >>> attributes defined in this document: (a) SHOULD be normalized as >>> recommended in Unicode Format for Network Interchange [RFC5198]; (b) >>> SHOULD not contain DEL or any C0 or C1 control characters except for >>> >> "SHOULD not" --> "SHOULD NOT" >> >>> HT, CR, and LF; (c) SHOULD only contain CR and LF characters together >>> (not as singletons); and SHOULD NOT contain HT, CR, or LF characters >>> in names, e.g., printer-name and printer-aliases. >>> >> >> In 4.1: >> >> Note: LDAP application clients SHOULD not attempt to use malformed >>> URI values read from this attribute. LDAP administrative clients >>> SHOULD not write malformed URI values into this attribute. >>> >> "SHOULD not" --> "SHOULD NOT" (twice) >> >> >> In 4.4: >> >> Values of language tags SHOULD conform to Tags for Identifying >>> Languages [BCP47]. >>> >> Why is this a SHOULD and not a MUST? I.e. what are possible reason to put >> anything not specified in BCP47 here? >> >> >> 4.12. printer-charset-supported >>> ( 1.3.18.0.2.4.1131 >>> NAME 'printer-charset-supported' >>> DESC 'One of the charsets supported for the attribute values of >>> syntax DirectoryString for this directory entry.' >>> >> I don't understand this description. DirectoryString is always in UTF-8. >> >> How is this LDAP attribute being used? >> >>> EQUALITY caseIgnoreMatch >>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} >>> ) >>> >> >> 4.13. printer-generated-natural-language-supported >>> ( 1.3.18.0.2.4.1137 >>> NAME 'printer-generated-natural-language-supported' >>> DESC 'One of the natural languages supported for this directory >>> entry.' >>> >> Again, I am not entirely sure how this is used. Can you clarify? >> >> 4.20. printer-number-up-supported >>> ( 1.3.18.0.2.4.1124 >>> NAME 'printer-number-up-supported' >>> DESC 'Maximum number of print-stream pages that can be imposed upon a >>> single side of an instance of selected medium by this Printer.' >>> EQUALITY integerMatch >>> ORDERING integerOrderingMatch >>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 >>> ) >>> >> This is not defined as single-valued. What is the meaning of multiple >> values? >> >> 4.35. printer-device-id >>> ( 1.3.18.0.2.24.46.1.101 >>> NAME 'printer-device-id' >>> DESC 'The IEEE 1284 Device ID for this Printer.' >>> EQUALITY caseIgnoreMatch >>> SUBSTR caseIgnoreSubstringsMatch >>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} >>> ) >>> Values of this attribute SHOULD conform to IEEE-ISTO PWG Command >>> Set >>> Format for IEEE 1284 Device ID [PWG5107.2]. >>> Note: For interoperatibility, values of this attribute SHOULD >>> include key/value pairs in the following order: (a) all required >>> key/value pairs (i.e., MANUFACTURER/MFG, MODEL/MDL, and COMMAND >>> SET/CMD); (b) all optional key/value pairs; and (c) all vendor >>> key/value pairs. >>> >> How does the advice on ordering interacts with multiple values of the >> attribute? LDAP multivalued attributes have no ordering of values. >> >> printer-device-id 1.3.18.0.2.24.46.1.101 >> printer-device-service-count 1.3.18.0.2.24.46.1.102 >> printer-uuid 1.3.18.0.2.24.46.1.104 >> printer-charge-info 1.3.18.0.2.24.46.1.105 >> printer-charge-info-uri 1.3.18.0.2.24.46.1.106 >> printer-geo-location 1.3.18.0.2.24.46.1.107 >> printer-ipp-features-supported 1.3.18.0.2.24.46.1.108 >> >> This is not necessarily a problem, but I couldn't find a registration for >> the 1.3.18.0.2.24 OID. The parent OID is owned by IBM. >> >> >> 13. Appendix X - Change History >> >> [ [RFC Editor: This section to be deleted before RFC publication] ] >> >> -bis document are required to include "Changes since RFC XXXX" section. >> So you should replace this Appendix with another one that details changes >> since RFC 3712. >> >> Best Regards, >> Alexey >> >> > --20cf301cc6b89c43e104ec174879 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Alexey,
I'm confused about current IETF procedures.

You= requested that I should NOT post a new draft until directed to do so
by my document shepherd or AD.

But, according to the IET= F datatracker there is NO assigned document
shepherd or AD for this docu= ment:

=A0 http://datatracker.ietf.org/doc/draft-mcdonald-= ldap-printer-schema/

And the same holds true for the closely related IPPS URI Scheme d= raft:

=A0 http://datatracker.ietf.org/doc/draft-mcdonald-ipps-uri-s= cheme/

How do I get a responsible AD or document shepherd assigned to th= ese documents?

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobi= lity Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary= - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Pri= nting Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High No= rth Inc
http://sites.google.com/site/bluero= ofmusic
http://sites.google.com/site/highnorthincmailto: blue= roofmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 734-944-0094
Summer= =A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434



On Fri, Nov 22, 2013 at 1:14 PM, Ira McD= onald <blueroofmusic@gmail.com> wrote:
Hi Alexey,

Thanks fo= r you excellent comments!=A0 My apologies for not acknowledging them sooner= .

I need to think about resolutions and discuss w/ the IEEE-IS= TO PWG Internet Printing
Protocol WG, so I'll be a week or so responding yet (our next mee= ting is 2 December).

Cheers,
- Ira (co-editor of LDAP= Printer Schema, co-chair of PWG IPP WG)


Ira McDonald (Musician / Software A= rchitect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux = Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group<= br> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated E= xpert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto: blue= roofmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 734-944-0094
Summer=A0= PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434



On Mon, Nov 18, 2013 at 10:37 AM, Alexey= Melnikov <alexey.melnikov@isode.com> wrote:
On 19/09/2013 17:34, Ira McDonald wrote:
Hello,

The IEEE-ISTO PWG Internet Printing Protocol WG would like to request
IETF Apps Area review of our updated LDAP Printer Schema (updates
RFC 3712).

http://www.ietf.org/internet-drafts= /draft-mcdonald-ldap-printer-schema-05.txt

Cheers,
- Ira (co-chair of IEEE-ISTO PWG IPP WG and co-editor of this document)

My apologies for belated review. I hope you find them useful.

-----------------------------------------

I have been selected as the Applications Area Directorate reviewer for this= draft (for background on APPSDIR, please see = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAre= aDirectorate ).

Please resolve these comments along with any other Last Call comments you m= ay receive. Please wait for direction from your document shepherd or AD bef= ore posting a new version of the draft.

Document: draft-mcdonald-ldap-printer-schema-05.txt
Title: Lightweight Directory Access Protocol (LDAP): Schema for Printer Ser= vices
Reviewer: Alexey Melnikov
Review Date: November 18, 2013
IETF Last Call Date: N/A

Summary: This draft is nearly reading for publication.

This document defines a schema, object classes and attributes, for
Printers and Print Services, for use with directories that support
Lightweight Directory Access Protocol (RFC 4510). =A0This document is
based on the Printer attributes listed in Appendix E of Internet
Printing Protocol/1.1 (IPP) (RFC 2911). =A0Additional Printer
attributes are based on definitions in the Printer MIB v2 (RFC 3805),
IEEE-ISTO PWG Command Set for IEEE 1284 Device ID (PWG 5107.2),
IEEE-ISTO PWG IPP Job and Printer Extensions - Set 3 (PWG 5100.13),
and IEEE-ISTO PWG IPP Everywhere (PWG 5100.14).

This document is published by the IETF on behalf of the Internet
Printing Protocol Working Group of the IEEE-ISTO Printer Working
Group.


Most of the issues I found are minor. In general the document is quite read= able.

General comments:

I noticed that you redifined various syntaxes to have upper limits on Direc= tory strings. URI and Language Tags have no upper limits. =A0I suspect that= limits that you added are going to be sufficient in most cases, but it wou= ld be better for your document to call these out explicitly in text.


In Section 1:

This document updates RFC 3712.

But the draft header says that it Obsoletes it. I think Obsolete is correct= , so the statement in Section 1 should be updated to match.


In Section 3.3:

=A0 =A0Note: =A0When extending other structural classes with auxiliary
=A0 =A0 classes, printerService SHOULD not be used.
You should also capitalize "not" according to RFC 2119. There are= multiple occurrences of the same problem in multiple places in the documen= t.


3.4. =A0printerServiceAuxClass
=A0 =A0 =A0 =A0 ( 1.3.18.0.2.6.257
=A0 =A0 NAME =A0'printerServiceAuxClass'
=A0 =A0 DESC =A0'Printer information.'

Fleming, McDonald =A0 =A0 =A0 =A0 =A0 =A0Expires 19 March 2014 =A0 =A0 =A0 = =A0 =A0 =A0 [Page 11]
=0C
Internet-Draft =A0 =A0LDAP Schema for Printer Services =A0 =A0 19 September= 2013

=A0 =A0 AUXILIARY
=A0 =A0 SUP =A0 printerAbstract
=A0 =A0 MAY =A0 ( printer-uri $
=A0 =A0 =A0 =A0 =A0 =A0 printer-xri-supported )
=A0 =A0 )
=A0 =A0 =A0 =A0 This auxiliary class defines Printer information. =A0It is = derived from
=A0 =A0 class printerAbstract and thus inherits common Printer attributes.<= br> =A0 =A0 This class SHOULD be used with a structural class.
Each directory entry requires a structural object class, so I think this SH= OULD is misleading. Also, why is this not a MUST?
I suggest you just delete this sentence or reword it to make it non normati= ve (and point to the document which makes the authoritative statement on th= is matter.)


Similar text in 3.5 and 3.6.

4. =A0Definition of Attribute Types

=A0 =A0The following attribute types reference matching rule names (instead=
=A0 =A0of OIDs) for clarity (see Section 6 below). =A0For optional attribut= es,
=A0 =A0if the Printer information is not known, the attribute value SHOULD<= br> =A0 =A0not be set. =A0In the following definitions, referenced matching rul= es
=A0 =A0are defined in Section 4 of [RFC4517] (see Section 6 'Definition= of
=A0 =A0Matching Rules' below).

I think you still meant section 4.

=A0 =A0 Note: =A0For interoperability and consistent text display, values o= f
=A0 =A0 attributes defined in this document: =A0(a) SHOULD be normalized as=
=A0 =A0 recommended in Unicode Format for Network Interchange [RFC5198]; (b= )
=A0 =A0 SHOULD not contain DEL or any C0 or C1 control characters except fo= r
"SHOULD not" --> "SHOULD NOT"
=A0 =A0 HT, CR, and LF; (c) SHOULD only contain CR and LF characters togeth= er
=A0 =A0 (not as singletons); and SHOULD NOT contain HT, CR, or LF character= s
=A0 =A0 in names, e.g., printer-name and printer-aliases.

In 4.1:

=A0 =A0 Note: =A0LDAP application clients SHOULD not attempt to use malform= ed
=A0 =A0 URI values read from this attribute. =A0LDAP administrative clients=
=A0 =A0 SHOULD not write malformed URI values into this attribute.
"SHOULD not" --> "SHOULD NOT" (twice)


In 4.4:

=A0 =A0 Values of language tags SHOULD conform to Tags for Identifying
=A0 =A0 Languages [BCP47].
Why is this a SHOULD and not a MUST? I.e. what are possible reason to put a= nything not specified in BCP47 here?


=A0 =A0 4.12. =A0printer-charset-supported
=A0 =A0 =A0 =A0 ( 1.3.18.0.2.4.1131
=A0 =A0 NAME 'printer-charset-supported'
=A0 =A0 DESC 'One of the charsets supported for the attribute values of=
=A0 =A0 =A0 =A0 =A0 syntax DirectoryString for this directory entry.'
I don't understand this description. DirectoryString is always in UTF-8= .

How is this LDAP attribute being used?
=A0 =A0 EQUALITY caseIgnoreMatch
=A0 =A0 SYNTAX =A01.3.6.1.4.1.1466.115.121.1.15{255}
=A0 =A0 )

=A0 =A04.13. =A0printer-generated-natural-language-supported
=A0 =A0 =A0 =A0 ( 1.3.18.0.2.4.1137
=A0 =A0 NAME 'printer-generated-natural-language-supported'<= br> =A0 =A0 DESC 'One of the natural languages supported for this directory=
=A0 =A0 =A0 =A0 =A0 entry.'
Again, I am not entirely sure how this is used. Can you clarify?

=A0 =A04.20. =A0printer-number-up-supported
=A0 =A0 =A0 =A0 ( 1.3.18.0.2.4.1124
=A0 =A0 NAME 'printer-number-up-supported'
=A0 =A0 DESC 'Maximum number of print-stream pages that can be imposed = upon a
=A0 =A0 =A0 =A0 =A0 single side of an instance of selected medium by this P= rinter.'
=A0 =A0 EQUALITY integerMatch
=A0 =A0 ORDERING integerOrderingMatch
=A0 =A0 SYNTAX =A01.3.6.1.4.1.1466.115.121.1.27
=A0 =A0 )
This is not defined as single-valued. What is the meaning of multiple value= s?

=A0 =A0 4.35. =A0printer-device-id
=A0 =A0 =A0 =A0 ( 1.3.18.0.2.24.46.1.101
=A0 =A0 NAME 'printer-device-id'
=A0 =A0 DESC 'The IEEE 1284 Device ID for this Printer.'
=A0 =A0 EQUALITY caseIgnoreMatch
=A0 =A0 SUBSTR caseIgnoreSubstringsMatch
=A0 =A0 SYNTAX =A01.3.6.1.4.1.1466.115.121.1.15{255}
=A0 =A0 )
=A0 =A0 =A0 =A0 Values of this attribute SHOULD conform to IEEE-ISTO PWG Co= mmand Set
=A0 =A0 Format for IEEE 1284 Device ID [PWG5107.2].
=A0 =A0 =A0 =A0 Note: =A0For interoperatibility, values of this attribute S= HOULD
=A0 =A0 include key/value pairs in the following order: =A0(a) all required=
=A0 =A0 key/value pairs (i.e., MANUFACTURER/MFG, MODEL/MDL, and COMMAND
=A0 =A0 SET/CMD); (b) all optional key/value pairs; and (c) all vendor
=A0 =A0 key/value pairs.
How does the advice on ordering interacts with multiple values of the attri= bute? LDAP multivalued attributes have no ordering of values.

=A0 =A0printer-device-id =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 1.3.18.0.2.24.46.1.101
=A0 =A0printer-device-service-count =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01.3.= 18.0.2.24.46.1.102
=A0 =A0printer-uuid =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A01.3.18.0.2.24.46.1.104
=A0 =A0printer-charge-info =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 1.3.18.0.2.24.46.1.105
=A0 =A0printer-charge-info-uri =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = 1.3.18.0.2.24.46.1.106
=A0 =A0printer-geo-location =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A01.3.18.0.2.24.46.1.107
=A0 =A0printer-ipp-features-supported =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01.3.18= .0.2.24.46.1.108

This is not necessarily a problem, but I couldn't find a registration f= or the 1.3.18.0.2.24 OID. The parent OID is owned by IBM.


13. =A0Appendix X - Change History

=A0 =A0[ [RFC Editor: =A0This section to be deleted before RFC publication]= ]

-bis document are required to include "Changes since RFC XXXX" se= ction. So you should replace this Appendix with another one that details ch= anges since RFC 3712.

Best Regards,
Alexey



--20cf301cc6b89c43e104ec174879-- From Claudio.Allocchio@garr.it Tue Nov 26 09:05:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C18B1AE219 for ; Tue, 26 Nov 2013 09:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.122 X-Spam-Level: X-Spam-Status: No, score=-0.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzNmBEaW1sUG for ; Tue, 26 Nov 2013 09:05:18 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 82A0D1AE213 for ; Tue, 26 Nov 2013 09:05:18 -0800 (PST) Received: internal info suppressed Date: Tue, 26 Nov 2013 18:05:15 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.local To: Ira McDonald In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1385485516; bh=Pknku7PYzWsvh7u+eOK/L6rTG3qfg6f6PssXFHKgm3M=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=gcbHw0jnxv6MPR8NvHbAosgwgeVegih5Zw1tqLWqL9/jy2+yDMvyrCkr1LHRUB87g VAH3344mEu5X9NhFosDPzsEaASd2yr4FAKm+Z1QYaassvJizi46wdg/evg0KUFrMTJ onSdboxENvcHSZDZg4OHLYxU9WKSv9DTN2eb6xrg= Cc: Pat Fleming , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [IETF procedure question] AppsDir review of draft-mcdonald-ldap-printer-schema-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 17:05:21 -0000 On Tue, 26 Nov 2013, Ira McDonald wrote: > Hi Alexey, > > I'm confused about current IETF procedures. > > You requested that I should NOT post a new draft until directed to do so > by my document shepherd or AD. > > But, according to the IETF datatracker there is NO assigned document > shepherd or AD for this document: > > http://datatracker.ietf.org/doc/draft-mcdonald-ldap-printer-schema/ > > And the same holds true for the closely related IPPS URI Scheme draft: > > http://datatracker.ietf.org/doc/draft-mcdonald-ipps-uri-scheme/ > > How do I get a responsible AD or document shepherd assigned to these > documents? Ira, that's because the whole Datatracker was designed to describe "reviews" being performed when the IETF Last Call is issued by the IESG, and as such "there is a Shepard and AD". but lately we started the "Early Review" experiment, when WG chairs can request reviews even before the LC is out, to make easier and more efficient the process. Alexey (but I made the same slight mistake!) used a template form which is for the traditional "in LC period" reviews... also because we do not have one (yet) for the Early Review ones... ... yes something to fix into the documentation! > > Cheers, > - Ira > > > > Ira McDonald (Musician / Software Architect) > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music / High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto: blueroofmusic@gmail.com > Winter 579 Park Place Saline, MI 48176 734-944-0094 > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 > > > > On Fri, Nov 22, 2013 at 1:14 PM, Ira McDonald wrote: > >> Hi Alexey, >> >> Thanks for you excellent comments! My apologies for not acknowledging >> them sooner. >> >> I need to think about resolutions and discuss w/ the IEEE-ISTO PWG >> Internet Printing >> Protocol WG, so I'll be a week or so responding yet (our next meeting is 2 >> December). >> >> Cheers, >> - Ira (co-editor of LDAP Printer Schema, co-chair of PWG IPP WG) >> >> >> Ira McDonald (Musician / Software Architect) >> Co-Chair - TCG Trusted Mobility Solutions WG >> Chair - Linux Foundation Open Printing WG >> Secretary - IEEE-ISTO Printer Working Group >> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG >> IETF Designated Expert - IPP & Printer MIB >> Blue Roof Music / High North Inc >> http://sites.google.com/site/blueroofmusic >> http://sites.google.com/site/highnorthinc >> mailto: blueroofmusic@gmail.com >> Winter 579 Park Place Saline, MI 48176 734-944-0094 >> Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 >> >> >> >> On Mon, Nov 18, 2013 at 10:37 AM, Alexey Melnikov < >> alexey.melnikov@isode.com> wrote: >> >>> On 19/09/2013 17:34, Ira McDonald wrote: >>> >>>> Hello, >>>> >>>> The IEEE-ISTO PWG Internet Printing Protocol WG would like to request >>>> IETF Apps Area review of our updated LDAP Printer Schema (updates >>>> RFC 3712). >>>> >>>> http://www.ietf.org/internet-drafts/draft-mcdonald-ldap- >>>> printer-schema-05.txt >>>> >>>> Cheers, >>>> - Ira (co-chair of IEEE-ISTO PWG IPP WG and co-editor of this document) >>>> >>> >>> My apologies for belated review. I hope you find them useful. >>> >>> ----------------------------------------- >>> >>> I have been selected as the Applications Area Directorate reviewer for >>> this draft (for background on APPSDIR, please see >>> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). >>> >>> 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-mcdonald-ldap-printer-schema-05.txt >>> Title: Lightweight Directory Access Protocol (LDAP): Schema for Printer >>> Services >>> Reviewer: Alexey Melnikov >>> Review Date: November 18, 2013 >>> IETF Last Call Date: N/A >>> >>> Summary: This draft is nearly reading for publication. >>> >>> This document defines a schema, object classes and attributes, for >>> Printers and Print Services, for use with directories that support >>> Lightweight Directory Access Protocol (RFC 4510). This document is >>> based on the Printer attributes listed in Appendix E of Internet >>> Printing Protocol/1.1 (IPP) (RFC 2911). Additional Printer >>> attributes are based on definitions in the Printer MIB v2 (RFC 3805), >>> IEEE-ISTO PWG Command Set for IEEE 1284 Device ID (PWG 5107.2), >>> IEEE-ISTO PWG IPP Job and Printer Extensions - Set 3 (PWG 5100.13), >>> and IEEE-ISTO PWG IPP Everywhere (PWG 5100.14). >>> >>> This document is published by the IETF on behalf of the Internet >>> Printing Protocol Working Group of the IEEE-ISTO Printer Working >>> Group. >>> >>> >>> Most of the issues I found are minor. In general the document is quite >>> readable. >>> >>> General comments: >>> >>> I noticed that you redifined various syntaxes to have upper limits on >>> Directory strings. URI and Language Tags have no upper limits. I suspect >>> that limits that you added are going to be sufficient in most cases, but it >>> would be better for your document to call these out explicitly in text. >>> >>> >>> In Section 1: >>> >>> This document updates RFC 3712. >>> >>> But the draft header says that it Obsoletes it. I think Obsolete is >>> correct, so the statement in Section 1 should be updated to match. >>> >>> >>> In Section 3.3: >>> >>> Note: When extending other structural classes with auxiliary >>>> classes, printerService SHOULD not be used. >>>> >>> You should also capitalize "not" according to RFC 2119. There are >>> multiple occurrences of the same problem in multiple places in the document. >>> >>> >>> 3.4. printerServiceAuxClass >>>> ( 1.3.18.0.2.6.257 >>>> NAME 'printerServiceAuxClass' >>>> DESC 'Printer information.' >>>> >>>> Fleming, McDonald Expires 19 March 2014 [Page 11] >>>> >>>> Internet-Draft LDAP Schema for Printer Services 19 September 2013 >>>> >>>> AUXILIARY >>>> SUP printerAbstract >>>> MAY ( printer-uri $ >>>> printer-xri-supported ) >>>> ) >>>> This auxiliary class defines Printer information. It is derived >>>> from >>>> class printerAbstract and thus inherits common Printer attributes. >>>> This class SHOULD be used with a structural class. >>>> >>> Each directory entry requires a structural object class, so I think this >>> SHOULD is misleading. Also, why is this not a MUST? >>> I suggest you just delete this sentence or reword it to make it non >>> normative (and point to the document which makes the authoritative >>> statement on this matter.) >>> >>> >>> Similar text in 3.5 and 3.6. >>> >>> 4. Definition of Attribute Types >>>> >>>> The following attribute types reference matching rule names (instead >>>> of OIDs) for clarity (see Section 6 below). For optional attributes, >>>> if the Printer information is not known, the attribute value SHOULD >>>> not be set. In the following definitions, referenced matching rules >>>> are defined in Section 4 of [RFC4517] (see Section 6 'Definition of >>>> Matching Rules' below). >>>> >>> >>> I think you still meant section 4. >>> >>> Note: For interoperability and consistent text display, values of >>>> attributes defined in this document: (a) SHOULD be normalized as >>>> recommended in Unicode Format for Network Interchange [RFC5198]; (b) >>>> SHOULD not contain DEL or any C0 or C1 control characters except for >>>> >>> "SHOULD not" --> "SHOULD NOT" >>> >>>> HT, CR, and LF; (c) SHOULD only contain CR and LF characters together >>>> (not as singletons); and SHOULD NOT contain HT, CR, or LF characters >>>> in names, e.g., printer-name and printer-aliases. >>>> >>> >>> In 4.1: >>> >>> Note: LDAP application clients SHOULD not attempt to use malformed >>>> URI values read from this attribute. LDAP administrative clients >>>> SHOULD not write malformed URI values into this attribute. >>>> >>> "SHOULD not" --> "SHOULD NOT" (twice) >>> >>> >>> In 4.4: >>> >>> Values of language tags SHOULD conform to Tags for Identifying >>>> Languages [BCP47]. >>>> >>> Why is this a SHOULD and not a MUST? I.e. what are possible reason to put >>> anything not specified in BCP47 here? >>> >>> >>> 4.12. printer-charset-supported >>>> ( 1.3.18.0.2.4.1131 >>>> NAME 'printer-charset-supported' >>>> DESC 'One of the charsets supported for the attribute values of >>>> syntax DirectoryString for this directory entry.' >>>> >>> I don't understand this description. DirectoryString is always in UTF-8. >>> >>> How is this LDAP attribute being used? >>> >>>> EQUALITY caseIgnoreMatch >>>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} >>>> ) >>>> >>> >>> 4.13. printer-generated-natural-language-supported >>>> ( 1.3.18.0.2.4.1137 >>>> NAME 'printer-generated-natural-language-supported' >>>> DESC 'One of the natural languages supported for this directory >>>> entry.' >>>> >>> Again, I am not entirely sure how this is used. Can you clarify? >>> >>> 4.20. printer-number-up-supported >>>> ( 1.3.18.0.2.4.1124 >>>> NAME 'printer-number-up-supported' >>>> DESC 'Maximum number of print-stream pages that can be imposed upon a >>>> single side of an instance of selected medium by this Printer.' >>>> EQUALITY integerMatch >>>> ORDERING integerOrderingMatch >>>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 >>>> ) >>>> >>> This is not defined as single-valued. What is the meaning of multiple >>> values? >>> >>> 4.35. printer-device-id >>>> ( 1.3.18.0.2.24.46.1.101 >>>> NAME 'printer-device-id' >>>> DESC 'The IEEE 1284 Device ID for this Printer.' >>>> EQUALITY caseIgnoreMatch >>>> SUBSTR caseIgnoreSubstringsMatch >>>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} >>>> ) >>>> Values of this attribute SHOULD conform to IEEE-ISTO PWG Command >>>> Set >>>> Format for IEEE 1284 Device ID [PWG5107.2]. >>>> Note: For interoperatibility, values of this attribute SHOULD >>>> include key/value pairs in the following order: (a) all required >>>> key/value pairs (i.e., MANUFACTURER/MFG, MODEL/MDL, and COMMAND >>>> SET/CMD); (b) all optional key/value pairs; and (c) all vendor >>>> key/value pairs. >>>> >>> How does the advice on ordering interacts with multiple values of the >>> attribute? LDAP multivalued attributes have no ordering of values. >>> >>> printer-device-id 1.3.18.0.2.24.46.1.101 >>> printer-device-service-count 1.3.18.0.2.24.46.1.102 >>> printer-uuid 1.3.18.0.2.24.46.1.104 >>> printer-charge-info 1.3.18.0.2.24.46.1.105 >>> printer-charge-info-uri 1.3.18.0.2.24.46.1.106 >>> printer-geo-location 1.3.18.0.2.24.46.1.107 >>> printer-ipp-features-supported 1.3.18.0.2.24.46.1.108 >>> >>> This is not necessarily a problem, but I couldn't find a registration for >>> the 1.3.18.0.2.24 OID. The parent OID is owned by IBM. >>> >>> >>> 13. Appendix X - Change History >>> >>> [ [RFC Editor: This section to be deleted before RFC publication] ] >>> >>> -bis document are required to include "Changes since RFC XXXX" section. >>> So you should replace this Appendix with another one that details changes >>> since RFC 3712. >>> >>> Best Regards, >>> Alexey >>> >>> >> > ------------------------------------------------------------------------------ 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 presnick@qti.qualcomm.com Tue Nov 26 09:08:16 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4BC1ADEA7 for ; Tue, 26 Nov 2013 09:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JYNU8LRvEOU for ; Tue, 26 Nov 2013 09:08:15 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id A737D1ADEBB for ; Tue, 26 Nov 2013 09:08:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1385485695; x=1417021695; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=RuM84qsEVCsae/RbZDVZ9AAdfrbPL4T/6SzcfiHZe8k=; b=BNQGMvYpZvpRMhLgoDWHdAbtT5hxjN51XyiugnQJORxxU5shcS3MBkc6 HmCpcaoSNl5NNO9Etft5HRhG3A5TZ+mUrySU/C8y572tqYtrxPcepNjqx 6CBXqw+3iW2zqei1I+Vq8rViUVpJQGlHrXLXen8S+P1rAGZFplzXphHIC E=; X-IronPort-AV: E=McAfee;i="5400,1158,7270"; a="89143584" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 26 Nov 2013 09:08:15 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,7270"; a="553186614" Received: from nasanexhc15.na.qualcomm.com ([129.46.52.215]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 26 Nov 2013 09:08:15 -0800 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc15.na.qualcomm.com (129.46.52.215) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 Nov 2013 09:08:15 -0800 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 Nov 2013 09:08:14 -0800 Message-ID: <5294D57C.8090902@qti.qualcomm.com> Date: Tue, 26 Nov 2013 11:08:12 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: <20131123065956.19859.77527.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: "appsawg-chairs@tools.ietf.org" , draft-ietf-appsawg-malformed-mail@tools.ietf.org, SM , Apps Discuss Subject: Re: [apps-discuss] New Version Notification - draft-ietf-appsawg-malformed-mail-11.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 17:08:17 -0000 On 11/23/13 9:11 AM, Barry Leiba wrote: > Pete, this version looks like it has your comments covered (except for > the Return-Path one that Murray disagreed with). You groovy with it? > Shall I press "go"? > It looks like in my disease and drug-induced state over the weekend and yesterday, I have missed my chance for changes. :-( pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From presnick@qti.qualcomm.com Tue Nov 26 09:44:20 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8A91ADEBE; Tue, 26 Nov 2013 09:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tXI0YnK14RA; Tue, 26 Nov 2013 09:44:18 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 6144F1ADF6C; Tue, 26 Nov 2013 09:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1385487858; x=1417023858; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=lShz2TNIXyHli7TceazpT/APAWLrYhV8whYcDfqADZk=; b=GN5SntTHTt9O8o5YMCDynZWZrHc1mMH2xM482XIIue36AuZaoW4D2ff2 LAPlO9BiUVtGVgQJdw7T0bC/Xuq9vxDXTn+zXx/Pcyz5GP8PJYlCwKgyH rulWuza6D4b4C8kWeA+nsJf3h2JFlsz/apEDjsQyj1LQJCjsmp1Prf4bc Y=; X-IronPort-AV: E=McAfee;i="5400,1158,7271"; a="89149348" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 26 Nov 2013 09:44:18 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,7271"; a="553202260" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 26 Nov 2013 09:44:17 -0800 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc07.na.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 Nov 2013 09:44:17 -0800 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 Nov 2013 09:44:16 -0800 Message-ID: <5294DDEE.4070000@qti.qualcomm.com> Date: Tue, 26 Nov 2013 11:44:14 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Ned Freed References: <20131120223533.8958.23858.idtracker@ietfa.amsl.com> <01P14CWFCE5A00004G@mauve.mrochek.com> In-Reply-To: <01P14CWFCE5A00004G@mauve.mrochek.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: "draft-ietf-appsawg-malformed-mail@tools.ietf.org" , IETF Apps Discuss , SM , "appsawg-chairs@tools.ietf.org" , The IESG Subject: Re: [apps-discuss] Pete Resnick's Yes on draft-ietf-appsawg-malformed-mail-10: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 17:44:20 -0000 I know Barry sent through his approval, but I wanted to send you my comments just in case there is room to change during AUTH48. (I was sick with a cold over the weekend; sorry for the delay.) On 11/23/13 11:04 AM, Ned Freed wrote: > Murray wrote: > >> All of this works for me except: >> >> On Wed, Nov 20, 2013 at 2:35 PM, Pete Resnickwrote: >> >>> 4 - It seems worth pointing out somewhere in this section that the >>> prepending of Received fields is the safest thing to do if changes must >>> be made to the message to pass information between modules. Your new text says: Where a change to content between modules is unavoidable, adding trace data (such as prepending a standard Received field) will at least allow tracing of the handling by modules that actually see different input. I think this is misplaced, and I think you missed the point. Your paragraph seems to say you *want* to insert trace data, and that prepending Received fields is one way to do it. I think the main point of the section is generally correct: You *don't* want to be adding trace data. What I meant for you to add was that, if you do need to add trace data, then the *only* recommended way to do it is to prepend Received fields. I would change the paragraph to: Where a change to content between modules is unavoidable, for example to add trace data, the safest way to do so is to prepend Received fields with the appropriate information. And I'd move it right after paragraph 2. >>> 7.1.6 - Why is the second example not obviously better? I have a hard >>> time imagining circumstances where an unterminated quoted-string that >>> contains an angle-bracketed thing that looks like an addr-spec is in fact >>> a local part. Your change here doesn't address my comment. You still say, "leaves software with no obvious "good" interpretation". I disagree. I think the second *is* an obvious good interpretation. >>> 7.5 - >>> What's the difference between 3& 4? Or maybe I don't know what "compound >>> instance" means in 3. You never did answer that question. >>> 7.5.3 - What's the harm in more than one Return-Path? Only one of >>> interest is the top-most. >> The issue here is that some components pick the last one, and some pick the >> first, in general. More often this happen with From, but Return-Path is >> not special in this regard. >> > FWIW, one thing an MDA can do is check and see if the top Return-path: agrees > with the current MAIL FROM, and if it does don't add a redundant Return-path: > field. > Yep. And I worry about the fact that 7.5.3 pretty directly contradicts [MAIL] on this point without mentioning it. 5322 clearly allows multiple Return-Path fields, so long as they're block prepended with Received fields. Maybe that's now considered a problem, but it seems like you'd want to mention that this is a change. And I'm still not clear on the harm given that Return-Path is supposed to be trace and ignored by end systems (unlike From, which is clearly going to be used). pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From anything@michielbdejong.com Tue Nov 26 10:11:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E571ADFF2 for ; Tue, 26 Nov 2013 10:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeibfgytabI6 for ; Tue, 26 Nov 2013 10:11:26 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) by ietfa.amsl.com (Postfix) with ESMTP id 2004B1ADF89 for ; Tue, 26 Nov 2013 10:11:22 -0800 (PST) Received: from mfilter23-d.gandi.net (mfilter23-d.gandi.net [217.70.178.151]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 81682A80BC; Tue, 26 Nov 2013 19:11:21 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter23-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter23-d.gandi.net (mfilter23-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id onh1LO0-wXrb; Tue, 26 Nov 2013 19:11:19 +0100 (CET) X-Originating-IP: 178.19.209.38 Received: from [192.168.1.209] (unknown [178.19.209.38]) (Authenticated sender: anything@michielbdejong.com) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id AF3A2A80CB; Tue, 26 Nov 2013 19:11:16 +0100 (CET) Message-ID: <5294E443.5050308@michielbdejong.com> Date: Tue, 26 Nov 2013 19:11:15 +0100 From: "Michiel B. de Jong" User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Dave Cridland References: <52934147.90304@michielbdejong.com> <52934626.8060503@gmx.de> <52935C62.1010301@michielbdejong.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040300070902080106000906" Cc: Julian Reschke , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] remote storage: per-user cloud storage for the web X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 18:11:35 -0000 This is a multi-part message in MIME format. --------------040300070902080106000906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit hi! thanks for your comments, we had a bit of discussion about the "sub-setting http" issue with server implementers, and the basic conclusion that you have a valid point. maybe we should say that we are defining an API (a storage protocol, basically) and not a network protocol? in practice, we want to ban "exotic" behavior unless it can be dealt with at the browser-level. So for instance, a server offering SPDY is ok, because the browser executes its XMLHttpRequests in the same way, whether over SPDY or not. On the other hand, we don't want servers responding with any status codes that are not short-listed in section 5 https://github.com/remotestorage/spec/blob/2b2091104696a0105d0176e9547a3be84facb336/draft-dejong-remotestorage-02.txt#L278-L317 ), because an exotic status code in an http response would not be handled transparently by the browser; it would reach the JavaScript code, which would not know what to do with it. in practice, i think the only two points where our I-D subsets http are not mentioning chunked transfer codings, and using only 13 out of the 40+ response codes that http allows. it also doesn't use all the verbs, for instance it leaves POST unused, but the http spec says all verbs apart from GET and HEAD are optional, so we are ok there. what is your opinion about allowing only a short-list of status codes? don't all server APIs do this in practice? Many thanks for your comments so far, Michiel On 25-Nov-13 15:47, Dave Cridland wrote: > On Mon, Nov 25, 2013 at 2:19 PM, Michiel B. de Jong > > wrote: > > hi Julian, > > thanks for your comments! > > > On 25-Nov-13 13:44, Julian Reschke wrote: > > HEAD support is already required by HTTP. > > > true, but we never said servers should implement all of HTTP. For > instance, chunked transfer-coding is also required by HTTP/1.1 and > we also don't require servers to support that. is that not clear > from the text? maybe we should mention that explicitly, then. > > > Oh, dear lord, that is horrible. Your document actually says it's > based on HTTPS, and the only hint that you're intending to subset is > that both HTTP and HTTPS are informative references. > > If you're expecting to chop up HTTP in a sane way without respecifying > it, I think you're onto a loser. > > If I implementing this according to your specification, I would start > with an HTTP implementation and move on from there - if your protocol > differs from HTTP, then that's a non-starter - at the very least I'll > need to ensure I can turn off whichever features is it you're > implicitly casting aside. The latter certainly involves being very > careful about the library I use. > > In the case of chunked encoding, I find it actually quite useful for > anything but static files. FWIW, I recently worked with a > remote-storage style API, and found the lack of chunked encoding > support in this particular implementation to be a real pest. For one > thing, I was dealing with CTE encoded email parts, and an exact length > is hard to determine before decoding (and often impossible without > having the data to hand). > > > * all servers should now send Content-Length headers back > on HEAD and > GET requests. > > > So you don't need support for content that is streamed (length > unknown in advance?). > > > correct. it's just a simple file-system-like storage, no streaming. > > > This is a bad idea. > > It'd be reasonable if the underlying building blocks didn't support > this, but they do already, so you're not restricting your goals, but > restricting your use-cases. I also have to carefully ensure my HTTP > library doesn't switch to using Chunked, making it a not-HTTP library. > I have no idea what else I need to turn off. > > > This seems to overlap with WebDAV and AtomPub. Did you > consider using one of those? > > > yes, we actually started with full WebDAV, and then looked at what > we could remove. > > > Have you had any reviews or opinions from WebDAV experts? I appreciate > that WebDAV is a complex protocol, and as the highest point on the > stack it's the logistically easiest thing to reinvent, but I'd be > interested in whether the likes of Lisa Dusseault have made any > comments here. > > It could be that they'll be able to give you useful directions to > explore that'd give you the overall requirements you're seeking to > fill without a lot of the excess you're hoping to avoid - and not > preclude use of things like WebDAV in the future. > > Dave. --------------040300070902080106000906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit hi!

thanks for your comments, we had a bit of discussion about the "sub-setting http" issue with server implementers, and the basic conclusion that you have a valid point.

maybe we should say that we are defining an API (a storage protocol, basically) and not a network protocol?

in practice, we want to ban "exotic" behavior unless it can be dealt with at the browser-level. So for instance, a server offering SPDY is ok, because the browser executes its XMLHttpRequests in the same way, whether over SPDY or not.

On the other hand, we don't want servers responding with any status codes that are not short-listed in section 5 https://github.com/remotestorage/spec/blob/2b2091104696a0105d0176e9547a3be84facb336/draft-dejong-remotestorage-02.txt#L278-L317 ), because an exotic status code in an http response would not be handled transparently by the browser; it would reach the JavaScript code, which would not know what to do with it.

in practice, i think the only two points where our I-D subsets http are not mentioning chunked transfer codings, and using only 13 out of the 40+ response codes that http allows.

it also doesn't use all the verbs, for instance it leaves POST unused, but the http spec says all verbs apart from GET and HEAD are optional, so we are ok there.

what is your opinion about allowing only a short-list of status codes? don't all server APIs do this in practice?


Many thanks for your comments so far,
Michiel

On 25-Nov-13 15:47, Dave Cridland wrote:
On Mon, Nov 25, 2013 at 2:19 PM, Michiel B. de Jong <anything@michielbdejong.com> wrote:
hi Julian,

thanks for your comments!


On 25-Nov-13 13:44, Julian Reschke wrote:
HEAD support is already required by HTTP.

true, but we never said servers should implement all of HTTP. For instance, chunked transfer-coding is also required by HTTP/1.1 and we also don't require servers to support that. is that not clear from the text? maybe we should mention that explicitly, then.


Oh, dear lord, that is horrible. Your document actually says it's based on HTTPS, and the only hint that you're intending to subset is that both HTTP and HTTPS are informative references.

If you're expecting to chop up HTTP in a sane way without respecifying it, I think you're onto a loser.

If I implementing this according to your specification, I would start with an HTTP implementation and move on from there - if your protocol differs from HTTP, then that's a non-starter - at the very least I'll need to ensure I can turn off whichever features is it you're implicitly casting aside. The latter certainly involves being very careful about the library I use.

In the case of chunked encoding, I find it actually quite useful for anything but static files. FWIW, I recently worked with a remote-storage style API, and found the lack of chunked encoding support in this particular implementation to be a real pest. For one thing, I was dealing with CTE encoded email parts, and an exact length is hard to determine before decoding (and often impossible without having the data to hand).


* all servers should now send Content-Length headers back on HEAD and
GET requests.

So you don't need support for content that is streamed (length unknown in advance?).

correct. it's just a simple file-system-like storage, no streaming.


This is a bad idea.

It'd be reasonable if the underlying building blocks didn't support this, but they do already, so you're not restricting your goals, but restricting your use-cases. I also have to carefully ensure my HTTP library doesn't switch to using Chunked, making it a not-HTTP library. I have no idea what else I need to turn off.
 

This seems to overlap with WebDAV and AtomPub. Did you consider using one of those?

yes, we actually started with full WebDAV, and then looked at what we could remove.


Have you had any reviews or opinions from WebDAV experts? I appreciate that WebDAV is a complex protocol, and as the highest point on the stack it's the logistically easiest thing to reinvent, but I'd be interested in whether the likes of Lisa Dusseault have made any comments here.

It could be that they'll be able to give you useful directions to explore that'd give you the overall requirements you're seeking to fill without a lot of the excess you're hoping to avoid - and not preclude use of things like WebDAV in the future.

Dave.

--------------040300070902080106000906-- From ht@inf.ed.ac.uk Tue Nov 26 10:13:57 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AABBD1AE222 for ; Tue, 26 Nov 2013 10:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.902 X-Spam-Level: X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIlhF1js7t1m for ; Tue, 26 Nov 2013 10:13:55 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id A5CA11ADF76 for ; Tue, 26 Nov 2013 10:13:54 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rAQIDbGR021873; Tue, 26 Nov 2013 18:13:37 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAQIDZZE031721; Tue, 26 Nov 2013 18:13:36 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rAQIDad2029457; Tue, 26 Nov 2013 18:13:36 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rAQIDZ5d029453; Tue, 26 Nov 2013 18:13:35 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= References: <20131119120919.12901.59046.idtracker@ietfa.amsl.com> <528C980D.7070106@it.aoyama.ac.jp> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 26 Nov 2013 18:13:35 +0000 In-Reply-To: <528C980D.7070106@it.aoyama.ac.jp> ("Martin J. =?iso-8859-1?Q?D=FCrst=22's?= message of "Wed\, 20 Nov 2013 20\:07\:57 +0900") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 18:13:57 -0000 Martin J. D=FCrst writes: > . . . > Section 3.1, Encoding considerations (and elsewhere): The term > "charset encoding" shows up. This is an unfortunate mixture of > terminology. MIME has the "charset" parameter, and XML has the > "encoding" pseudo-attribute, but this doesn't mean that these two > words should be combined just like this. Also, this isn't used > uniformly through the spec, e.g. there are things like > "ASCII-compatible character sets" (see also > http://www.w3.org/MarkUp/html-spec/charset-harmful.html). Yes, alas, this area of the spec is . . . inconsistent at best. Some of this was inherited from 3023, some added more recently. The problem begins as far back as *2. Notational Conventions* [1]: As defined in [RFC2781] (informative), the three character sets "utf-16", "utf-16le", and "utf-16be" are used to label UTF-16 text. In this specification, "the UTF-16 family" refers to those three character sets. By contrast, the phrases "utf-16" or UTF-16 in this specification refer specifically to the single charset "utf-16". I'm thinking of changing this to read more along the following lines: XML (in an XML or Text declaration) and MIME (in a charset parameter) use a common vocabulary to identify the coded character set (CCS) and character encoding scheme (CES) of a particular byte stream. The CCS of all XML documents is [UNICODE], so in practice all that is at issue is the CES. A CES determines encoding form and, where relevant, serialization. XML requires support for the UTF-8 and UTF-16 encoding form, and allows others. In this specification, UTF-8, UTF-16 and UTF-32 refer to the encoding forms, independent of serialisation. As documented in [RFC3629], [RFC2781] and [UNICODE] section 3.9, the MIME charset "utf-8" is used to label byte streams which encode UNICODE text using the UTF-8 encoding form, the three MIME charsets "utf-16", "utf-16le", and "utf-16be" are used to label byte streams which encode UNICODE text using the UTF-16 encoding form, and the three MIME charsets "utf-32", "utf-32le" and "utf32-be" likewise for UTF-32. In this specification we will use the phrases "charset parameter" and "encoding declaration" to refer to whatever MIME charset is specified by a MIME charset parameter or XML encoding declaration respectively, reserving the phrase "character encoding" for the encoding form and, where relevant, serialization, actually used in a particular XML MIME entity. and then make further changes throughout along those lines. What do you think? ht [1] http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-05#section= -2 --=20 Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged s= pam] From superuser@gmail.com Tue Nov 26 10:23:46 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A71E1AD8F7; Tue, 26 Nov 2013 10:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKC9tLsR_DDl; Tue, 26 Nov 2013 10:23:44 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 983C11AD72A; Tue, 26 Nov 2013 10:23:43 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id k14so3175964wgh.22 for ; Tue, 26 Nov 2013 10:23:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mjI7x9vaL0z35VIFHIXUN5FDXFL8wDQYR6wSHnfiJgc=; b=0WtGn3N6zQwPTTImWDF/2VOo/LBYvA52p10sIx0UiTqoo3aKUtAYoCUlvYtZwhJlW2 QI5S1wFquOBg3QjMmd3TafHIdzF83JNLktPNEp8pcGLYKkJKBkm+v5nccoe8vqSSXpOM +ts2I0rg95Pc2o57m7YzmyZej2aQEZb4DNFfnuE38DuItkSTmJrK50zAl/XAf/U1yYaP AfnqEcda3k1z6MifOCFDoYrDf3iGmkvJ08Ov+S61JcrQ27lO9cs2B1ZDSSFmhkbnip3t Jwp/g0VBOo9RRqTH5zhwChnyQv2JNfvuTEJtWDljlTrkm6p/e/lws9B3LHdygc6C3pJJ y47g== MIME-Version: 1.0 X-Received: by 10.194.174.36 with SMTP id bp4mr27465520wjc.7.1385490222879; Tue, 26 Nov 2013 10:23:42 -0800 (PST) Received: by 10.181.13.230 with HTTP; Tue, 26 Nov 2013 10:23:42 -0800 (PST) In-Reply-To: <5294DDEE.4070000@qti.qualcomm.com> References: <20131120223533.8958.23858.idtracker@ietfa.amsl.com> <01P14CWFCE5A00004G@mauve.mrochek.com> <5294DDEE.4070000@qti.qualcomm.com> Date: Tue, 26 Nov 2013 10:23:42 -0800 Message-ID: From: "Murray S. Kucherawy" To: Pete Resnick Content-Type: multipart/alternative; boundary=089e0141a0ae931a5504ec189479 Cc: "draft-ietf-appsawg-malformed-mail@tools.ietf.org" , Ned Freed , IETF Apps Discuss , SM , "appsawg-chairs@tools.ietf.org" , The IESG Subject: Re: [apps-discuss] Pete Resnick's Yes on draft-ietf-appsawg-malformed-mail-10: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 18:23:46 -0000 --089e0141a0ae931a5504ec189479 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 26, 2013 at 9:44 AM, Pete Resnick wrote: > I know Barry sent through his approval, but I wanted to send you my > comments just in case there is room to change during AUTH48. (I was sick > with a cold over the weekend; sorry for the delay.) > No objection to working on this during AUTH48. > > On 11/23/13 11:04 AM, Ned Freed wrote: > > Murray wrote: >> >> All of this works for me except: >>> >>> On Wed, Nov 20, 2013 at 2:35 PM, Pete Resnick>> >wrote: >>> >>> 4 - It seems worth pointing out somewhere in this section that the >>>> prepending of Received fields is the safest thing to do if changes must >>>> be made to the message to pass information between modules. >>>> >>> > Your new text says: > > Where a change to content between modules is unavoidable, adding > trace data (such as prepending a standard Received field) will at > least allow tracing of the handling by modules that actually see > different input. > > I think this is misplaced, and I think you missed the point. Your > paragraph seems to say you *want* to insert trace data, and that prepending > Received fields is one way to do it. I think the main point of the section > is generally correct: You *don't* want to be adding trace data. What I > meant for you to add was that, if you do need to add trace data, then the > *only* recommended way to do it is to prepend Received fields. I would > change the paragraph to: > > Where a change to content between modules is unavoidable, for example > to add trace data, the safest way to do so is to prepend Received > fields with the appropriate information. > > And I'd move it right after paragraph 2. OK by me. > > > 7.1.6 - Why is the second example not obviously better? I have a hard >>>> time imagining circumstances where an unterminated quoted-string that >>>> contains an angle-bracketed thing that looks like an addr-spec is in >>>> fact >>>> a local part. >>>> >>> > Your change here doesn't address my comment. You still say, "leaves > software with no obvious "good" interpretation". I disagree. I think the > second *is* an obvious good interpretation. > Will revisit. I think I agreed (it's not in front of me now), but I guess I didn't capture it properly. > > 7.5 - >>>> What's the difference between 3& 4? Or maybe I don't know what >>>> "compound >>>> instance" means in 3. >>>> >>> > You never did answer that question. I thought I clarified that in the latest draft by explaining what was meant by "compound instance". > > > 7.5.3 - What's the harm in more than one Return-Path? Only one of >>>> interest is the top-most. >>>> >>> The issue here is that some components pick the last one, and some pick >>> the >>> first, in general. More often this happen with From, but Return-Path is >>> not special in this regard. >>> >>> >> FWIW, one thing an MDA can do is check and see if the top Return-path: >> agrees >> with the current MAIL FROM, and if it does don't add a redundant >> Return-path: >> field. >> >> > > Yep. And I worry about the fact that 7.5.3 pretty directly contradicts > [MAIL] on this point without mentioning it. 5322 clearly allows multiple > Return-Path fields, so long as they're block prepended with Received > fields. Maybe that's now considered a problem, but it seems like you'd want > to mention that this is a change. And I'm still not clear on the harm given > that Return-Path is supposed to be trace and ignored by end systems (unlike > From, which is clearly going to be used). > > My recollection of Return-Path is that there's always zero or one, and it's typically added at the top only during local delivery; any instance of it in transit is basically wrong and subject to removal. I'll have to revisit this as well if that's wrong. Thanks for persisting on these points. -MSK --089e0141a0ae931a5504ec189479 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 26, 2013 at 9:44 AM, Pete Resnick <pr= esnick@qti.qualcomm.com> wrote:
I know Barry sent through his approval, but = I wanted to send you my comments just in case there is room to change durin= g AUTH48. (I was sick with a cold over the weekend; sorry for the delay.)

No objection to working on this during AUT= H48.
=A0

On 11/23/13 11:04 AM, Ned Freed wrote:

Murray wrote:

All of this works for me except:

On Wed, Nov 20, 2013 at 2:35 PM, Pete Resnick<presnick@qti.qualcomm.com&g= t;wrote:

4 - It seems worth pointing out somewhere in this section that the
prepending of Received fields is the safest thing to do if changes must
be made to the message to pass information between modules.

Your new text says:

=A0 =A0Where a change to content between modules is unavoidable, adding
=A0 =A0trace data (such as prepending a standard Received field) will at =A0 =A0least allow tracing of the handling by modules that actually see
=A0 =A0different input.

I think this is misplaced, and I think you missed the point. Your paragraph= seems to say you *want* to insert trace data, and that prepending Received= fields is one way to do it. I think the main point of the section is gener= ally correct: You *don't* want to be adding trace data. What I meant fo= r you to add was that, if you do need to add trace data, then the *only* re= commended way to do it is to prepend Received fields. I would change the pa= ragraph to:

=A0 =A0Where a change to content between modules is unavoidable, for exampl= e
=A0 =A0to add trace data, the safest way to do so is to prepend Received =A0 =A0fields with the appropriate information.

And I'd move it right after paragraph 2.

OK by me.
=A0


7.1.6 - Why is the second example not obviously better? I have a hard
time imagining circumstances where an unterminated quoted-string that
contains an angle-bracketed thing that looks like an addr-spec is in fact a local part.

Your change here doesn't address my comment. You still say, "leave= s software with no obvious "good" interpretation". I disagre= e. I think the second *is* an obvious good interpretation.

Will revisit.=A0 I think I agreed (it's not in fron= t of me now), but I guess I didn't capture it properly.
=A0

7.5 -
What's the difference between 3& =A04? Or maybe I don't know wh= at "compound
instance" means in 3.

You never did answer that question.

I thoug= ht I clarified that in the latest draft by explaining what was meant by &qu= ot;compound instance".
=A0


7.5.3 - What's the harm in more than one Return-Path? Only one of
interest is the top-most.
The issue here is that some components pick the last one, and some pick the=
first, in general. =A0More often this happen with From, but Return-Path is<= br> not special in this regard.
=A0 =A0 =A0
FWIW, one thing an MDA can do is check and see if the top Return-path: agre= es
with the current MAIL FROM, and if it does don't add a redundant Return= -path:
field.
=A0 =A0

Yep. And I worry about the fact that 7.5.3 pretty directly contradicts [MAI= L] on this point without mentioning it. 5322 clearly allows multiple Return= -Path fields, so long as they're block prepended with Received fields. = Maybe that's now considered a problem, but it seems like you'd want= to mention that this is a change. And I'm still not clear on the harm = given that Return-Path is supposed to be trace and ignored by end systems (= unlike From, which is clearly going to be used).


My recollection of Retur= n-Path is that there's always zero or one, and it's typically added= at the top only during local delivery; any instance of it in transit is ba= sically wrong and subject to removal.=A0 I'll have to revisit this as w= ell if that's wrong.

Thanks for persisting on these points.

-MSK
--089e0141a0ae931a5504ec189479-- From julian.reschke@gmx.de Tue Nov 26 10:25:36 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35681ADEC1 for ; Tue, 26 Nov 2013 10:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_UoEyWTFWvx for ; Tue, 26 Nov 2013 10:25:34 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7701AD72A for ; Tue, 26 Nov 2013 10:25:33 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MXVr0-1W6jR00Vra-00WT70 for ; Tue, 26 Nov 2013 19:25:33 +0100 Message-ID: <5294E795.2010806@gmx.de> Date: Tue, 26 Nov 2013 19:25:25 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Michiel B. de Jong" , Dave Cridland References: <52934147.90304@michielbdejong.com> <52934626.8060503@gmx.de> <52935C62.1010301@michielbdejong.com> <5294E443.5050308@michielbdejong.com> In-Reply-To: <5294E443.5050308@michielbdejong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:dkg4VZxwB9zOW4FijFcacWCEt/xtMurx6SVCuHBqspdjl4hM7/m 0ZU1EIxO2E8CCKwnetDNWKz611MNKu9wrASh3h4VIwXIGA353uF3qwig50buKI1/XfSAODa u3Qd2J5pMflNBOOKOBZngUlPuAgZuymbyxv2JH2a1Nm5Qz8Ye3PLC3+tIBIITswzRJA2NQw Cl9p90nGI1YgDblQkwRnQ== Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] remote storage: per-user cloud storage for the web X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 18:25:36 -0000 On 2013-11-26 19:11, Michiel B. de Jong wrote: > hi! > > thanks for your comments, we had a bit of discussion about the > "sub-setting http" issue with server implementers, and the basic > conclusion that you have a valid point. > > maybe we should say that we are defining an API (a storage protocol, > basically) and not a network protocol? > > in practice, we want to ban "exotic" behavior unless it can be dealt > with at the browser-level. So for instance, a server offering SPDY is > ok, because the browser executes its XMLHttpRequests in the same way, > whether over SPDY or not. > > On the other hand, we don't want servers responding with any status > codes that are not short-listed in section 5 > https://github.com/remotestorage/spec/blob/2b2091104696a0105d0176e9547a3be84facb336/draft-dejong-remotestorage-02.txt#L278-L317 > ), because an exotic status code in an http response would not be > handled transparently by the browser; it would reach the JavaScript > code, which would not know what to do with it. That's exactly the kind of subsetting that is bad. Maybe you could explain what *exactly* the problem with "exotic" status codes is? The HTTP spec is pretty clear about how to process them. BTW: while looking at : > * 400 for all malformed requests (e.g. foreign characters in the > path or unrecognized http verb, etcetera), as well as for > all PUT and DELETE requests to folders, There's already status code 501 for unrecognized verbs. > in practice, i think the only two points where our I-D subsets http are > not mentioning chunked transfer codings, and using only 13 out of the > 40+ response codes that http allows. > > it also doesn't use all the verbs, for instance it leaves POST unused, > but the http spec says all verbs apart from GET and HEAD are optional, > so we are ok there. > > what is your opinion about allowing only a short-list of status codes? > don't all server APIs do this in practice? Not all; for instance WebDAV gives *examples* but always reminds implementers that other status codes can occur too. Best regards, Julian From ned.freed@mrochek.com Tue Nov 26 22:50:43 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183221AE213; Tue, 26 Nov 2013 22:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjPrbS7V7d1C; Tue, 26 Nov 2013 22:50:37 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id A68921AE17A; Tue, 26 Nov 2013 22:50:37 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P19CEW2CE8001KNE@mauve.mrochek.com>; Tue, 26 Nov 2013 22:45:34 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P18HARGJGG00004G@mauve.mrochek.com>; Tue, 26 Nov 2013 22:45:29 -0800 (PST) Message-id: <01P19CETU4PU00004G@mauve.mrochek.com> Date: Tue, 26 Nov 2013 22:04:27 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 26 Nov 2013 10:23:42 -0800" References: <20131120223533.8958.23858.idtracker@ietfa.amsl.com> <01P14CWFCE5A00004G@mauve.mrochek.com> <5294DDEE.4070000@qti.qualcomm.com> To: "Murray S. Kucherawy" Cc: "draft-ietf-appsawg-malformed-mail@tools.ietf.org" , Ned Freed , IETF Apps Discuss , Pete Resnick , SM , "appsawg-chairs@tools.ietf.org" , The IESG Subject: Re: [apps-discuss] Pete Resnick's Yes on draft-ietf-appsawg-malformed-mail-10: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Nov 2013 06:50:43 -0000 > My recollection of Return-Path is that there's always zero or one, and it's > typically added at the top only during local delivery; any instance of it > in transit is basically wrong and subject to removal. I'll have to revisit > this as well if that's wrong. Apologies, I should have caught this sooner. It's zero or one per block of Received/Resent-*/Return-path fields. So yes, you can have more than one of them. And that means section 7.5.3 is incorrect when it asserts that a message with more than one is invalid in the first sentence. Perhaps a change to something like this is in order: While legitimate messages can contain more than one Return-Path header field, such usage is often an error rather that a valid message containing multiple header field blocks as described in sections 3.6 of [RFC 5322]. Accordingly, when a message containing multiple Return-path: header fields is encountered, all but the topmost one is to be disregarded, as it is most likely to have been added nearest to the mailbox that received that message. I think that should cover it. That said, I've always regarded the notion that such blocks can be reliably distinguished as nothing but specious nonsense, and that fact that RFC 5322 doesn't contain language recommending against such usage as a problematic aspect of that specification. The problem is fundamental: Aside from the dependency of Return-path: fields on Received: fields (but not vice versa), all of the fields in one of these blocks are optional. And all the rules only say that fielde must be prepended; they say nothing about which of the various fields in a given block have to be prepended first. It is therefore perfectly valid in a one step MSA/MDA situation to prepend Return-path: first, then Received:, then Resent-*. Or any other order, and that plus the optionality of all the field creates a situation where there is no way to determine the boundaries between blocks with any degree of relability. It follows that if you expect the recipient of your message to be able to consume such information reliably it's a really good idea to remove all instances of these fields other than your own on submission. But all this goes far beyond the scope of the present draft, which is concerned with malformed mail, and as Pete correctly points out, messages containing multiple Return-path: fields may be ill-advised but are not necessarily malformed. Although in practice a lot of them are, because another thing that happens frequently is that when messages are resent all Received: fields are removed (because if you don't your mail tends to get caught by loop checks) but the Return-path: fields are retained. And that's then a malformed message according to the rules. Ned P.S. I claim no special insight into any of this. Marshall Rose patiently explained this issue to me many years ago. From superuser@gmail.com Tue Nov 26 23:22:45 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92DEA1AE243; Tue, 26 Nov 2013 23:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqcEYJilBEeB; Tue, 26 Nov 2013 23:22:30 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id F10EB1AE237; Tue, 26 Nov 2013 23:22:16 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id k14so3826861wgh.20 for ; Tue, 26 Nov 2013 23:22:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9QFNRRE7rzBIVjV0WTeOB/Tq35oNW9AQMkIP4KgS6zM=; b=SK95BBr8vDS9EHMlS+/90s7+jUAYpfBQC6m38Nb9dSiFHPH3YOWxd0uApueYvsY9R4 cpo4KG6SwWVY8+qmjmYtukl+uZKw4CZJi4lTIGKrww8QIupovyROB4fePgnZp/IEgkeS zdETIT9lL97P8FPh0ZSlQDa4VF9AgyfZZWUG9Fzq7nVwhZGHsZtlsNXMYn0iA6IKLaYA S7eeDCKEWalz/hZXmjNiAcYEhEXKPExjHfugCPGfndFZoVWyPw9BJw0lv3rg9G4GKtLx INpu5S8TwnCDYPQaN2cWG00Vss5aa9U+XSkVcBpC/27uV5s6+5GnEi6fO+pNiFB4zhUU +iEg== MIME-Version: 1.0 X-Received: by 10.194.21.104 with SMTP id u8mr254690wje.63.1385536935987; Tue, 26 Nov 2013 23:22:15 -0800 (PST) Received: by 10.181.13.230 with HTTP; Tue, 26 Nov 2013 23:22:15 -0800 (PST) In-Reply-To: References: <20131120223533.8958.23858.idtracker@ietfa.amsl.com> <01P14CWFCE5A00004G@mauve.mrochek.com> <5294DDEE.4070000@qti.qualcomm.com> Date: Tue, 26 Nov 2013 23:22:15 -0800 Message-ID: From: "Murray S. Kucherawy" To: Pete Resnick Content-Type: multipart/alternative; boundary=047d7b5d97cbe4928f04ec2374d6 Cc: "draft-ietf-appsawg-malformed-mail@tools.ietf.org" , Ned Freed , IETF Apps Discuss , SM , "appsawg-chairs@tools.ietf.org" , The IESG Subject: Re: [apps-discuss] Pete Resnick's Yes on draft-ietf-appsawg-malformed-mail-10: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Nov 2013 07:22:47 -0000 --047d7b5d97cbe4928f04ec2374d6 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 26, 2013 at 10:23 AM, Murray S. Kucherawy wrote: > > All of this works for me except: >>>> >>>> On Wed, Nov 20, 2013 at 2:35 PM, Pete Resnick>>> >wrote: >>>> >>>> 4 - It seems worth pointing out somewhere in this section that the >>>>> prepending of Received fields is the safest thing to do if changes must >>>>> be made to the message to pass information between modules. >>>>> >>>> >> Your new text says: >> >> Where a change to content between modules is unavoidable, adding >> trace data (such as prepending a standard Received field) will at >> least allow tracing of the handling by modules that actually see >> different input. >> >> I think this is misplaced, and I think you missed the point. Your >> paragraph seems to say you *want* to insert trace data, and that prepending >> Received fields is one way to do it. I think the main point of the section >> is generally correct: You *don't* want to be adding trace data. What I >> meant for you to add was that, if you do need to add trace data, then the >> *only* recommended way to do it is to prepend Received fields. I would >> change the paragraph to: >> >> Where a change to content between modules is unavoidable, for example >> to add trace data, the safest way to do so is to prepend Received >> fields with the appropriate information. >> >> And I'd move it right after paragraph 2. > > Understood, but I think yours implies that one would change content specifically to add trace data, and not for some other reason. What I'm talking about is the capabilities of the modules to hand data among themselves without having to modify the content itself; if for some reason that's simply not possible, then at least make it look like a hop occurred by adding trace data. So how about: Where a change to content between modules is unavoidable, it is a good idea to add standard trace data to indicate a "visible" handoff between modules has occurred. The only advisable way to do this is to prepend Received fields with the appropriate information, as described in Section 3.6.7 of [MAIL]. Will make Ned's proposed change as well. Here's a diff from -10 (which the IESG approved) to a proposed -12, which incorporates everything to date, including the above: http://www.blackops.org/~msk/draft-ietf-appsawg-malformed-mail-from--10.diff.html -MSK --047d7b5d97cbe4928f04ec2374d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 26, 2013 at 10:23 AM, Murray S. Kucherawy <= superuser@gmail.com> wrote:

All of this works for me except:

On Wed, Nov 20, 2013 at 2:35 PM, Pete Resnick<presnick@qti.qualcomm.com&g= t;wrote:

4 - It seems worth pointing out somewhere in this section that the
prepending of Received fields is the safest thing to do if changes must
be made to the message to pass information between modules.

Your new text says:

=A0 =A0Where a change to content between modules is unavoidable, adding
=A0 =A0trace data (such as prepending a standard Received field) will at =A0 =A0least allow tracing of the handling by modules that actually see
=A0 =A0different input.

I think this is misplaced, and I think you missed the point. Your paragraph= seems to say you *want* to insert trace data, and that prepending Received= fields is one way to do it. I think the main point of the section is gener= ally correct: You *don't* want to be adding trace data. What I meant fo= r you to add was that, if you do need to add trace data, then the *only* re= commended way to do it is to prepend Received fields. I would change the pa= ragraph to:

=A0 =A0Where a change to content between modules is unavoidable, for exampl= e
=A0 =A0to add trace data, the safest way to do so is to prepend Received =A0 =A0fields with the appropriate information.

And I'd move it right after paragraph 2.
=

Understood, but I think yours implie= s that one would change content specifically to add trace data, and not for= some other reason.=A0 What I'm talking about is the capabilities of th= e modules to hand data among themselves without having to modify the conten= t itself; if for some reason that's simply not possible, then at least = make it look like a hop occurred by adding trace data.

So how about:

Where a change to content between modul= es is unavoidable, it is a good idea to add standard trace data to indicate= a "visible" handoff between modules has occurred.=A0 The only ad= visable way to do this is to prepend Received fields with the appropriate i= nformation, as described in Section 3.6.7 of [MAIL].

Will make Ned's proposed change as well.=A0 Here's a diff= from -10 (which the IESG approved) to a proposed -12, which incorporates e= verything to date, including the above:

http://ww= w.blackops.org/~msk/draft-ietf-appsawg-malformed-mail-from--10.diff.html

-MSK
--047d7b5d97cbe4928f04ec2374d6-- From duerst@it.aoyama.ac.jp Wed Nov 27 02:07:52 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908D51AD66E for ; Wed, 27 Nov 2013 02:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.908 X-Spam-Level: X-Spam-Status: No, score=0.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2p3Tw-aBCUj0 for ; Wed, 27 Nov 2013 02:07:50 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8E11AE0E1 for ; Wed, 27 Nov 2013 02:07:33 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id rARA7WOD025671; Wed, 27 Nov 2013 19:07:32 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 0263_8119_badd1390_574b_11e3_bb6f_001e6722eec2; Wed, 27 Nov 2013 19:07:31 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 4A925BF4DD; Wed, 27 Nov 2013 19:07:31 +0900 (JST) Message-ID: <5295C454.6050006@it.aoyama.ac.jp> Date: Wed, 27 Nov 2013 19:07:16 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Henry S. Thompson" References: <20131119120919.12901.59046.idtracker@ietfa.amsl.com> <528C980D.7070106@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Nov 2013 10:07:52 -0000 Hello Henry, On 2013/11/27 3:13, Henry S. Thompson wrote: > Martin J. D=C3=BCrst writes: > >> . . . >> Section 3.1, Encoding considerations (and elsewhere): The term >> "charset encoding" shows up. This is an unfortunate mixture of >> terminology. MIME has the "charset" parameter, and XML has the >> "encoding" pseudo-attribute, but this doesn't mean that these two >> words should be combined just like this. Also, this isn't used >> uniformly through the spec, e.g. there are things like >> "ASCII-compatible character sets" (see also >> http://www.w3.org/MarkUp/html-spec/charset-harmful.html). > > Yes, alas, this area of the spec is . . . inconsistent at best. Some > of this was inherited from 3023, some added more recently. > > The problem begins as far back as *2. Notational Conventions* [1]: > > As defined in [RFC2781] (informative), the three character sets > "utf-16", "utf-16le", and "utf-16be" are used to label UTF-16 > text. In this specification, "the UTF-16 family" refers to those > three character sets. By contrast, the phrases "utf-16" or UTF-16 in > this specification refer specifically to the single charset > "utf-16". > > I'm thinking of changing this to read more along the following lines: This is quite a good start, but has some inaccuracies (and loses the=20 distinction between "the UTF-16 family" and "utf-16" in the text above,=20 which is quite relevant (because of the special treatment that that XML=20 gives "utf-16"). Also, both CCS and CES are used for a single character encoding. XML=20 does not have a single CCS, but a single 'document character set'. So I=20 don't think any text about CCS or CES is needed. So I have tried a re-write, but I'm not totally sure this will work for=20 all of the document. Please check. Both XML (in an XML or Text declaration using the encoding pseudo- attribute) and MIME (in a Content-Type header field using the charset parameter) use a common set of labels [IANA-charsets] to identify the MIME charset (mapping from byte stream to character sequence [RFC2978]). In this specification we will use the phrases "charset parameter" and "encoding declaration" to refer to whatever MIME charset is specified by a MIME charset parameter or XML encoding declaration respectively, reserving the phrase "character encoding" for MIME charset actually used in a particular XML MIME entity. XML requires support for the MIME charsets UTF-8 and UTF-16, and allows others. In this specification, the term "UTF-16" is restricted to the MIME charset of the same name as defined in [RFC2781], whereas the term "the UTF-16 family" refers to "utf-16", "utf-16le", and "utf-16be". [IANA-charsets] http://www.iana.org/assignments/character-sets/character-sets.xhtml That should do it. Regards, Martin. > XML (in an XML or Text declaration) and MIME (in a charset > parameter) use a common vocabulary to identify the coded character > set (CCS) and character encoding scheme (CES) of a particular byte > stream. The CCS of all XML documents is [UNICODE], so in practice > all that is at issue is the CES. A CES determines encoding form > and, where relevant, serialization. XML requires support for the > UTF-8 and UTF-16 encoding form, and allows others. In this > specification, UTF-8, UTF-16 and UTF-32 refer to the encoding forms, > independent of serialisation. > > As documented in [RFC3629], [RFC2781] and [UNICODE] section 3.9, the > MIME charset "utf-8" is used to label byte streams which encode > UNICODE text using the UTF-8 encoding form, the three MIME charsets > "utf-16", "utf-16le", and "utf-16be" are used to label byte streams > which encode UNICODE text using the UTF-16 encoding form, and the > three MIME charsets "utf-32", "utf-32le" and "utf32-be" likewise for > UTF-32. > > In this specification we will use the phrases "charset parameter" > and "encoding declaration" to refer to whatever MIME charset is > specified by a MIME charset parameter or XML encoding declaration > respectively, reserving the phrase "character encoding" for the > encoding form and, where relevant, serialization, actually used in a > particular XML MIME entity. > > and then make further changes throughout along those lines. What do > you think? > > ht > > [1] http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-05#sec= tion-2 From anything@michielbdejong.com Wed Nov 27 04:09:20 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D23D1AE1B1 for ; Wed, 27 Nov 2013 04:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BR5UG0gYarv for ; Wed, 27 Nov 2013 04:09:17 -0800 (PST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5261AE173 for ; Wed, 27 Nov 2013 04:09:16 -0800 (PST) Received: from mfilter17-d.gandi.net (mfilter17-d.gandi.net [217.70.178.145]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id DE43517209C; Wed, 27 Nov 2013 13:09:15 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter17-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter17-d.gandi.net (mfilter17-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id fX7vqt8U9wmw; Wed, 27 Nov 2013 13:08:55 +0100 (CET) X-Originating-IP: 178.19.210.162 Received: from [10.1.248.240] (unknown [178.19.210.162]) (Authenticated sender: anything@michielbdejong.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id E6D5A172093; Wed, 27 Nov 2013 13:08:54 +0100 (CET) Message-ID: <5295E0D6.6020505@michielbdejong.com> Date: Wed, 27 Nov 2013 13:08:54 +0100 From: "Michiel B. de Jong" User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Julian Reschke , Dave Cridland References: <52934147.90304@michielbdejong.com> <52934626.8060503@gmx.de> <52935C62.1010301@michielbdejong.com> <5294E443.5050308@michielbdejong.com> <5294E795.2010806@gmx.de> In-Reply-To: <5294E795.2010806@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] remote storage: per-user cloud storage for the web X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Nov 2013 12:09:20 -0000 hm, it just seemed better to me to keep it simple. we are not defining general-purpose webservers here, quite specifically just storage servers. this is a much smaller problem space than the web as a whole. we don't need all of http's features, and it's more valuable to us that their behavior is predictable. see for instance http://atnan.com/blog/2008/08/08/transfer-encoding-chunked-or-chunky-http/ also, since all data on a remoteStorage server is put there by a remoteStorage client, and we don't support something like http://www.webdav.org/specs/rfc4437.html#METHOD_MKREDIRECTREF to create redirects, it will never occur that a server responds with a redirect header. the list of status codes used to implement remoteStorage is simply shorter than the list of status codes that browsers support in order to display content from the variety of webservers out there. the web is exciting in its variety. remoteStorage servers are boring in their predictability. that's a good thing. :) so to clarify the situation, i added this paragraph: https://github.com/remotestorage/spec/blob/1baccdddfd8606596583f19561d0eed3003d2251/draft-dejong-remotestorage-02.txt#L167-L177 as far as i know we are not deviating from http in any place other than with the chunked encoding and with the shorter list of allowed status codes. i did add chunked encoding as a 'MAY' now, though, and maybe we'll end up making it a 'MUST' (in line with HTTP/1.1) in version -03, after we experiment a bit with it in practice. many thanks for your contributions! Cheers, Michiel On 26-Nov-13 19:25, Julian Reschke wrote: > On 2013-11-26 19:11, Michiel B. de Jong wrote: >> hi! >> >> thanks for your comments, we had a bit of discussion about the >> "sub-setting http" issue with server implementers, and the basic >> conclusion that you have a valid point. >> >> maybe we should say that we are defining an API (a storage protocol, >> basically) and not a network protocol? >> >> in practice, we want to ban "exotic" behavior unless it can be dealt >> with at the browser-level. So for instance, a server offering SPDY is >> ok, because the browser executes its XMLHttpRequests in the same way, >> whether over SPDY or not. >> >> On the other hand, we don't want servers responding with any status >> codes that are not short-listed in section 5 >> https://github.com/remotestorage/spec/blob/2b2091104696a0105d0176e9547a3be84facb336/draft-dejong-remotestorage-02.txt#L278-L317 >> >> ), because an exotic status code in an http response would not be >> handled transparently by the browser; it would reach the JavaScript >> code, which would not know what to do with it. > > That's exactly the kind of subsetting that is bad. > > Maybe you could explain what *exactly* the problem with "exotic" > status codes is? The HTTP spec is pretty clear about how to process them. > > BTW: while looking at > : > >> * 400 for all malformed requests (e.g. foreign characters in the >> path or unrecognized http verb, etcetera), as well as for >> all PUT and DELETE requests to folders, > > There's already status code 501 for unrecognized verbs. > >> in practice, i think the only two points where our I-D subsets http are >> not mentioning chunked transfer codings, and using only 13 out of the >> 40+ response codes that http allows. >> >> it also doesn't use all the verbs, for instance it leaves POST unused, >> but the http spec says all verbs apart from GET and HEAD are optional, >> so we are ok there. >> >> what is your opinion about allowing only a short-list of status codes? >> don't all server APIs do this in practice? > > Not all; for instance WebDAV gives *examples* but always reminds > implementers that other status codes can occur too. > > Best regards, Julian > From julian.reschke@gmx.de Wed Nov 27 04:22:28 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421AE1ADF91 for ; Wed, 27 Nov 2013 04:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYDLgvzAgQj2 for ; Wed, 27 Nov 2013 04:22:26 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id DDF8F1ACCF0 for ; Wed, 27 Nov 2013 04:22:25 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MHso5-1VmU0g0Qm5-003alZ for ; Wed, 27 Nov 2013 13:22:25 +0100 Message-ID: <5295E3FB.4050407@gmx.de> Date: Wed, 27 Nov 2013 13:22:19 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Michiel B. de Jong" , Dave Cridland References: <52934147.90304@michielbdejong.com> <52934626.8060503@gmx.de> <52935C62.1010301@michielbdejong.com> <5294E443.5050308@michielbdejong.com> <5294E795.2010806@gmx.de> <5295E0D6.6020505@michielbdejong.com> In-Reply-To: <5295E0D6.6020505@michielbdejong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:tzNE0CQePWQ4gCLpfrVuNIMvd/m7/zaCRpWBDtATqDH7VxWNeLp Sl6fTqd0uMb3O2iTipUneCW/z2AsvdLScYRst8d1ThalKGUXselQIXc05lPMALEdUlMXN/2 BvuJFSrf7zf0DwGyxlJZF8gYYVfjz13zACSJf8YyMs3bIqqP5DzwmV62by1u2S6ugNQ/c5+ gn8GjMjzCLv5ytVMYl34g== Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] remote storage: per-user cloud storage for the web X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Nov 2013 12:22:28 -0000 On 2013-11-27 13:08, Michiel B. de Jong wrote: > hm, it just seemed better to me to keep it simple. we are not defining > general-purpose webservers here, quite specifically just storage > servers. this is a much smaller problem space than the web as a whole. > we don't need all of http's features, and it's more valuable to us that > their behavior is predictable. see for instance > > http://atnan.com/blog/2008/08/08/transfer-encoding-chunked-or-chunky-http/ > > also, since all data on a remoteStorage server is put there by a > remoteStorage client, and we don't support something like > http://www.webdav.org/specs/rfc4437.html#METHOD_MKREDIRECTREF to create > redirects, it will never occur that a server responds with a redirect > header. the list of status codes used to implement remoteStorage is > simply shorter than the list of status codes that browsers support in > order to display content from the variety of webservers out there. > > the web is exciting in its variety. remoteStorage servers are boring in > their predictability. that's a good thing. :) > > so to clarify the situation, i added this paragraph: > > https://github.com/remotestorage/spec/blob/1baccdddfd8606596583f19561d0eed3003d2251/draft-dejong-remotestorage-02.txt#L167-L177 Quoting: > * Whereas [HTTP, section 10] allows many different status codes, > remoteStorage servers SHOULD send the status codes mentioned > in section 5 of this Internet Draft, and clients MAY treat any > deviation from this as a server malfunction. I still don't understand how that helps. What problem are you solving here? > ... Best regards, Julian From anything@michielbdejong.com Wed Nov 27 05:18:57 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A11D1A1F5D for ; Wed, 27 Nov 2013 05:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ig-psHEwaCu9 for ; Wed, 27 Nov 2013 05:18:55 -0800 (PST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC6D1A1F4C for ; Wed, 27 Nov 2013 05:18:55 -0800 (PST) Received: from mfilter3-d.gandi.net (mfilter3-d.gandi.net [217.70.178.133]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id A9556172093; Wed, 27 Nov 2013 14:18:54 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter3-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter3-d.gandi.net (mfilter3-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id so0tdttiR0Aa; Wed, 27 Nov 2013 14:18:53 +0100 (CET) X-Originating-IP: 178.19.210.162 Received: from [10.1.248.240] (unknown [178.19.210.162]) (Authenticated sender: anything@michielbdejong.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 6FB571720C2; Wed, 27 Nov 2013 14:18:52 +0100 (CET) Message-ID: <5295F13B.4070504@michielbdejong.com> Date: Wed, 27 Nov 2013 14:18:51 +0100 From: "Michiel B. de Jong" User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Julian Reschke , Dave Cridland References: <52934147.90304@michielbdejong.com> <52934626.8060503@gmx.de> <52935C62.1010301@michielbdejong.com> <5294E443.5050308@michielbdejong.com> <5294E795.2010806@gmx.de> <5295E0D6.6020505@michielbdejong.com> <5295E3FB.4050407@gmx.de> In-Reply-To: <5295E3FB.4050407@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] remote storage: per-user cloud storage for the web X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Nov 2013 13:18:57 -0000 On 27-Nov-13 13:22, Julian Reschke wrote: > Quoting: > >> * Whereas [HTTP, section 10] allows many different status codes, >> remoteStorage servers SHOULD send the status codes mentioned >> in section 5 of this Internet Draft, and clients MAY treat any >> deviation from this as a server malfunction. > > I still don't understand how that helps. What problem are you solving > here? > if we allow servers a choice of all response codes then the client implement code to deal with each one of them. most of that code would never be used in practice, and thus be easily end up being buggy and lead to incompatibility. we are solving those three problems (unnecessary work for client implementers, risk of bugs, and risk of incompatibility) by saying exactly which 13 out of 41 (if i counted correctly) status codes we need, to get the job done. the other 28 status codes are useful to some part of the web, but they are useless to our specific problem space, so it's safer to disable them. cheers, Michiel From julian.reschke@gmx.de Wed Nov 27 05:31:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426C31AD8D8 for ; Wed, 27 Nov 2013 05:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4t4TwPZaDSwh for ; Wed, 27 Nov 2013 05:31:01 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEB91AD6BF for ; Wed, 27 Nov 2013 05:31:01 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lx4dh-1Va8s90M6j-016iSd for ; Wed, 27 Nov 2013 14:31:00 +0100 Message-ID: <5295F411.7040002@gmx.de> Date: Wed, 27 Nov 2013 14:30:57 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Michiel B. de Jong" , Dave Cridland References: <52934147.90304@michielbdejong.com> <52934626.8060503@gmx.de> <52935C62.1010301@michielbdejong.com> <5294E443.5050308@michielbdejong.com> <5294E795.2010806@gmx.de> <5295E0D6.6020505@michielbdejong.com> <5295E3FB.4050407@gmx.de> <5295F13B.4070504@michielbdejong.com> In-Reply-To: <5295F13B.4070504@michielbdejong.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:rAmwLjYf6waxIJ0rwF1yolTdmZ7pvSz8KZ/+0Yz2mKLUwbEX9Ue FgpTFFThzzhu3QkCRz1xqkchgQLWQQutbH/47XqdKwNMN2WCi0MkEksU24XeKKP2yO7TEk3 aL/XsoG0lZV/O05A1ruKb1+7WPU8MqeY2HNhpbO4rG84JZHtUPkFKrkYJ/AKitYoLpQpJJY v6fl4HYlatlLpBmNQTtDA== Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] remote storage: per-user cloud storage for the web X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Nov 2013 13:31:03 -0000 On 2013-11-27 14:18, Michiel B. de Jong wrote: > > On 27-Nov-13 13:22, Julian Reschke wrote: >> Quoting: >> >>> * Whereas [HTTP, section 10] allows many different status codes, >>> remoteStorage servers SHOULD send the status codes mentioned >>> in section 5 of this Internet Draft, and clients MAY treat any >>> deviation from this as a server malfunction. >> >> I still don't understand how that helps. What problem are you solving >> here? >> > > if we allow servers a choice of all response codes then the client > implement code to deal with each one of them. most of that code would > never be used in practice, and thus be easily end up being buggy and > lead to incompatibility. The code to implement unknown codes is trivial. Just treat 2xx as 200, 3xx as 300, 4xx as 400, and 5xx as 500. > we are solving those three problems (unnecessary work for client > implementers, risk of bugs, and risk of incompatibility) by saying > exactly which 13 out of 41 (if i counted correctly) status codes we > need, to get the job done. the other 28 status codes are useful to some > part of the web, but they are useless to our specific problem space, so > it's safer to disable them. I disagree. By unnecessarily creating a profile: a) you teach people to handle status codes incorrectly, b) make it impossible to introduce new codes, c) might make it impossible to use existing libraries, d) ignore that intermediaries might change messages, e) make it unnecessarily hard to have a server that supports "your" protocol and somebody else's protocol on the same URI. Best regards, Julian From markus.lanthaler@gmx.net Wed Nov 27 06:02:17 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665FE1ADF91 for ; Wed, 27 Nov 2013 06:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0WVHbhqXe7F for ; Wed, 27 Nov 2013 06:02:16 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED4D1AD69E for ; Wed, 27 Nov 2013 06:02:15 -0800 (PST) Received: from Vostro3500 ([37.116.127.110]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MY75A-1W7Y7q0nZo-00UsC6 for ; Wed, 27 Nov 2013 15:02:14 +0100 From: "Markus Lanthaler" To: References: <52934147.90304@michielbdejong.com> <52934626.8060503@gmx.de> <52935C62.1010301@michielbdejong.com> <5294E443.5050308@michielbdejong.com> <5294E795.2010806@gmx.de> <5295E0D6.6020505@michielbdejong.com> <5295E3FB.4050407@gmx.de> <5295F13B.4070504@michielbdejong.com> In-Reply-To: <5295F13B.4070504@michielbdejong.com> Date: Wed, 27 Nov 2013 15:02:10 +0100 Message-ID: <028701ceeb79$44afb8a0$ce0f29e0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7rc2NLWApLB+/2Sk2zUQJ1bF/5DAABLvqw Content-Language: de X-Provags-ID: V03:K0:Fv0lp4gyhbp//eEFbUIn3ylcqJNm7jum71uxmx5oUCbJUGe59pF IwHV+n+3vYUPJA8s38Jx4M8w4y3EOyA0PxzmeT6Ego+dgbPaloRNZRcH9g3Lv5eOn+2cn5C ywdX3blPO3Pl8EaIyuUtUnxKE+WJKilQBvArYyDWcM1ryr+oXIQwXhoSASuEsCgOg7XBfR+ fVRgAAqcR3qaPkJwkEmNQ== Subject: Re: [apps-discuss] remote storage: per-user cloud storage for the web X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Nov 2013 14:02:19 -0000 Michiel, On Wednesday, November 27, 2013 2:19 PM, Michiel B. de Jong wrote: > On 27-Nov-13 13:22, Julian Reschke wrote: > > Quoting: > > > >> * Whereas [HTTP, section 10] allows many different status codes, > >> remoteStorage servers SHOULD send the status codes mentioned > >> in section 5 of this Internet Draft, and clients MAY treat any > >> deviation from this as a server malfunction. > > > > I still don't understand how that helps. What problem are you solving > > here? > > if we allow servers a choice of all response codes then the client > implement code to deal with each one of them. most of that code would > never be used in practice, and thus be easily end up being buggy and > lead to incompatibility. I think you should try to look at it from a different perspective. draft-dejong-remotestorage-02 does not specify clients, it specifies a protocol (or Web API if you prefer) on top HTTP. As such, it's enough to define the protocol operations you need and leave the rest undefined. You can't prevent server (or intermediaries!) from sending different status codes anyway. Clients *will* have to deal with them. But you don't have to specify how because the HTTP specification already does. > we are solving those three problems (unnecessary work for client > implementers, risk of bugs, and risk of incompatibility) by saying > exactly which 13 out of 41 (if i counted correctly) status codes we > need, to get the job done. the other 28 status codes are useful to some > part of the web, but they are useless to our specific problem space, so > it's safer to disable them. No, it's not. Clients will have to deal with them anyway in practice. The only thing you achieve by doing so IMO is that some off-the-shelf HTTP libraries can't be used to implement conforming remoteStorage servers. Hope this helps, Markus -- Markus Lanthaler @markuslanthaler From anything@michielbdejong.com Wed Nov 27 07:01:13 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE371ADBE8 for ; Wed, 27 Nov 2013 07:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_36=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSyeqCMmSjVM for ; Wed, 27 Nov 2013 07:01:11 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) by ietfa.amsl.com (Postfix) with ESMTP id EE5B11ADBC9 for ; Wed, 27 Nov 2013 07:01:10 -0800 (PST) Received: from mfilter1-d.gandi.net (mfilter1-d.gandi.net [217.70.178.130]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 16C26A8107 for ; Wed, 27 Nov 2013 16:01:10 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter1-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter1-d.gandi.net (mfilter1-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id WQrKM7T+o55C for ; Wed, 27 Nov 2013 16:01:08 +0100 (CET) X-Originating-IP: 178.19.209.38 Received: from [192.168.1.209] (unknown [178.19.209.38]) (Authenticated sender: anything@michielbdejong.com) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 3E595A80F6 for ; Wed, 27 Nov 2013 16:01:05 +0100 (CET) Message-ID: <52960930.8090506@michielbdejong.com> Date: Wed, 27 Nov 2013 16:01:04 +0100 From: "Michiel B. de Jong" User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <52934147.90304@michielbdejong.com> <52934626.8060503@gmx.de> <52935C62.1010301@michielbdejong.com> <5294E443.5050308@michielbdejong.com> <5294E795.2010806@gmx.de> <5295E0D6.6020505@michielbdejong.com> <5295E3FB.4050407@gmx.de> <5295F13B.4070504@michielbdejong.com> <028701ceeb79$44afb8a0$ce0f29e0$@lanthaler@gmx.net> In-Reply-To: <028701ceeb79$44afb8a0$ce0f29e0$@lanthaler@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] remote storage: per-user cloud storage for the web X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Nov 2013 15:01:14 -0000 OK, i changed it so that the checklist of status codes to take into account is only a summary of what follows from section 10 of rfc2616 and section 3.1 of rfc6750: https://github.com/remotestorage/spec/blob/30f8b53430fa5fce765e94bb8ff991468875356e/draft-dejong-remotestorage-02.txt#L284-L286 so we are no longer sub-setting http. :) thanks a lot for this improvement! what do people think in general of the endeavor? is anybody interested in starting a broader discussion about per-user storage? in particular, i think: * the current big industry stakeholders in this space are probably: Dropbox, GoogleDrive, iCloud, and SkyDrive. * apart from these four, many parties probably have an interest in disrupting the per-user storage market, either to neutralize it as a business risk, or to create a level basis for entering. * remoteStorage is a grassroots project, we are about 1 1/2 people. :) it is obvious that we cannot do this without the help from you who are reading this. we hope some of the following parties may be interested in joining this effort: * ISPs and mobile operators who want to offer more than just bandwidth to their users * handset manufacturers who want to disrupt the iOS+iCloud / Android+GoogleDrive / WindowsPhone+SkyDrive power blocks * people who care about open and free technology, also on this new layer. again, comments very welcome! cheers, Michiel From markus.lanthaler@gmx.net Wed Nov 27 07:10:53 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1C11AE090 for ; Wed, 27 Nov 2013 07:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pW9YSxxQZ1tH for ; Wed, 27 Nov 2013 07:10:52 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 040E71AE084 for ; Wed, 27 Nov 2013 07:10:49 -0800 (PST) Received: from Vostro3500 ([37.116.127.110]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Md31i-1W2nuH2hRS-00IHAw for ; Wed, 27 Nov 2013 16:10:47 +0100 From: "Markus Lanthaler" To: References: <52934147.90304@michielbdejong.com> <52934626.8060503@gmx.de> <52935C62.1010301@michielbdejong.com> <5294E443.5050308@michielbdejong.com> <5294E795.2010806@gmx.de> <5295E0D6.6020505@michielbdejong.com> <5295E3FB.4050407@gmx.de> <5295F13B.4070504@michielbdejong.com> <028701ceeb79$44afb8a0$ce0f29e0$@lanthaler@gmx.net> <52960930.8090506@michielbdejong.com> In-Reply-To: <52960930.8090506@michielbdejong.com> Date: Wed, 27 Nov 2013 16:10:43 +0100 Message-ID: <02a101ceeb82$d87d28c0$89777a40$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7rgYcWroF2aIImSg+z5+CV8L1+VQAAP+IA Content-Language: de X-Provags-ID: V03:K0:csIvjovvm5xtWkPSVeUMiARUp4dQzqlqKIVfGOrgKY2KYAQkj51 bK3+wNPN9EJ6TFtY0FHcVmxQEsTypWdxklS+6FUuey6oat7mkb1g1NkNSiDAQcyA+2r4H+M 6pwbskWXkUq1Oosbn3thpiEyOqdPLltAwiAv4vCFyhPLGbLb/GUTl+F30RelkwhbjxDhu3V 0WO75Srg02TKdEViENshw== Subject: Re: [apps-discuss] remote storage: per-user cloud storage for the web X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Nov 2013 15:10:53 -0000 On Wednesday, November 27, 2013 4:01 PM, Michiel B. de Jong wrote: > OK, i changed it so that the checklist of status codes to take into > account is only a summary of what follows from section 10 of rfc2616 > and > section 3.1 of rfc6750: > > https://github.com/remotestorage/spec/blob/30f8b53430fa5fce765e94bb8ff9 > 91468875356e/draft-dejong-remotestorage-02.txt#L284-L286 > > so we are no longer sub-setting http. :) thanks a lot for this > improvement! +1 > what do people think in general of the endeavor? is anybody interested > in starting a broader discussion about per-user storage? It's very interesting work but I think the real problem is not the client but the applications integrating remoteStorage into phones, laptops etc. Dropbox does a fantastic job there.. What we need I think is an open source alternative of their client for all major OS. Just my 2 cents -- Markus Lanthaler @markuslanthaler From presnick@qti.qualcomm.com Wed Nov 27 07:37:12 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768E41ACCEA; Wed, 27 Nov 2013 07:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCfdK0ctVcUF; Wed, 27 Nov 2013 07:36:58 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id EA6301ACC8A; Wed, 27 Nov 2013 07:36:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1385566617; x=1417102617; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Dz/zUpL/bGcXlFmUrFDwJJFXAajzfW7GsXtfW2XD9pA=; b=aS+6BjwXsO/bnETdrLot6keALA9fnqCp7puGlxXoGETXZlpT0u9IxHz7 EfY+u0YF4EnS319OGrvmPZo56+Si1rxuDNeHWCskRuY8rjnaHF25JHGRU DT6l20e4672IejuanzjcVRAyHZR0q1uzaI7lvCpw9qUhtkgnZTtonGRtJ Y=; X-IronPort-AV: E=McAfee;i="5400,1158,7271"; a="55946977" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP; 27 Nov 2013 07:36:57 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,7271"; a="578523528" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 27 Nov 2013 07:36:57 -0800 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 07:36:57 -0800 Message-ID: <52961196.5080700@qti.qualcomm.com> Date: Wed, 27 Nov 2013 09:36:54 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Ned Freed References: <20131120223533.8958.23858.idtracker@ietfa.amsl.com> <01P14CWFCE5A00004G@mauve.mrochek.com> <5294DDEE.4070000@qti.qualcomm.com> <01P19CETU4PU00004G@mauve.mrochek.com> In-Reply-To: <01P19CETU4PU00004G@mauve.mrochek.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: "draft-ietf-appsawg-malformed-mail@tools.ietf.org" , IETF Apps Discuss , SM , "appsawg-chairs@tools.ietf.org" , The IESG Subject: Re: [apps-discuss] Pete Resnick's Yes on draft-ietf-appsawg-malformed-mail-10: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Nov 2013 15:37:12 -0000 On 11/27/13 12:04 AM, Ned Freed wrote: > Perhaps a change to something like this is in order: > > While legitimate messages can contain more than one Return-Path > header field, such usage is often an error rather that a valid > message containing multiple header field blocks as described in > sections 3.6 of [RFC 5322]. Accordingly, when a message containing > multiple Return-path: header fields is encountered, all but the > topmost one is to be disregarded, as it is most likely to have > been added nearest to the mailbox that received that message. > > I think that should cover it. > wfm. > That said, I've always regarded the notion that such blocks can be reliably > distinguished as nothing but specious nonsense, and that fact that RFC 5322 > doesn't contain language recommending against such usage as a problematic > aspect of that specification. > Yeah, well, I was still bright-eyed and bushy-tailed when I wrote that text. Grumpy-old me of today would have said different things. > The problem is fundamental: Aside from the dependency of Return-path: fields on > Received: fields (but not vice versa), all of the fields in one of these blocks > are optional. And all the rules only say that fielde must be prepended; they > say nothing about which of the various fields in a given block have to be > prepended first. It is therefore perfectly valid in a one step MSA/MDA situation > to prepend Return-path: first, then Received:, then Resent-*. Or any other > order, and that plus the optionality of all the field creates a situation where > there is no way to determine the boundaries between blocks with any degree of > relability. > Actually, that's not quite true. The spec is clear that the Return-Path: is always on top of it's associated Received: fields. And though not crystal clear, it certainly implies that the Resent-Fields: get prepended *before* being reintroduced into the transport system, which is what ought to be prepending the Received: and Return-Path: fields. But yes, ambiguity abounds. In any event, I agree with Ned that this is discussion of spilled milk that has gone over the bridge or under the dam or something. The fix he suggests above is perfectly fine for this document. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From presnick@qti.qualcomm.com Wed Nov 27 07:46:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B631AD2EC; Wed, 27 Nov 2013 07:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJ5bqLqpNwVf; Wed, 27 Nov 2013 07:46:24 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 450441ACCDC; Wed, 27 Nov 2013 07:46:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1385567184; x=1417103184; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=k09OZZ2sDX3pk7S/v0fLddQaYM6UBLHDY3lntZvCVLo=; b=VKQODMej0eOTcrU+75vTVAyIKOaF/GQcm+BFVDozhVnkx76wJM726BRz kmzeG7doI+SeHPKMV/e7hGzCJngkPfASWVzI/BkimhcIIf3LHceiWygEk 1ORFdPgbMW9JjH1+sL3eoYkNRxE0SVlcCocDGdB8WUOkrU+mAuYl1pgBL E=; X-IronPort-AV: E=McAfee;i="5400,1158,7271"; a="89383794" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by wolverine02.qualcomm.com with ESMTP; 27 Nov 2013 07:46:23 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,7271"; a="23310400" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 27 Nov 2013 07:46:23 -0800 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 07:46:22 -0800 Message-ID: <529613CD.8060307@qti.qualcomm.com> Date: Wed, 27 Nov 2013 09:46:21 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20131120223533.8958.23858.idtracker@ietfa.amsl.com> <01P14CWFCE5A00004G@mauve.mrochek.com> <5294DDEE.4070000@qti.qualcomm.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090202030504010905030405" X-Originating-IP: [172.30.39.5] Cc: "draft-ietf-appsawg-malformed-mail@tools.ietf.org" , Ned Freed , IETF Apps Discuss , SM , "appsawg-chairs@tools.ietf.org" , The IESG Subject: Re: [apps-discuss] Pete Resnick's Yes on draft-ietf-appsawg-malformed-mail-10: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Nov 2013 15:46:43 -0000 --------------090202030504010905030405 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Everything in the diff you sent looks great. Just one outstanding bit: On 11/26/13 12:23 PM, Murray S. Kucherawy wrote: > > 7.5 - > What's the difference between 3& 4? Or maybe I don't > know what "compound > instance" means in 3. > > > You never did answer that question. > > > I thought I clarified that in the latest draft by explaining what was > meant by "compound instance". Could you give me an example of 3 (a compound instance) which is not a 4? pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------090202030504010905030405 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Everything in the diff you sent looks great. Just one outstanding bit:

On 11/26/13 12:23 PM, Murray S. Kucherawy wrote:
7.5 -
What's the difference between 3&  4? Or maybe I don't know what "compound
instance" means in 3.

You never did answer that question.

I thought I clarified that in the latest draft by explaining what was meant by "compound instance".

Could you give me an example of 3 (a compound instance) which is not a 4?

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------090202030504010905030405-- From stephen.farrell@cs.tcd.ie Wed Nov 27 12:16:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53B21AE2A8 for ; Wed, 27 Nov 2013 12:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbMwmAEPrZmj for ; Wed, 27 Nov 2013 12:16:16 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 783941ADF5F for ; Wed, 27 Nov 2013 12:11:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 88950BE58 for ; Wed, 27 Nov 2013 20:11:17 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wcdLDUC+rF8 for ; Wed, 27 Nov 2013 20:11:15 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.45.61.161]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 22019BE55 for ; Wed, 27 Nov 2013 20:11:15 +0000 (GMT) Message-ID: <529651D8.7090701@cs.tcd.ie> Date: Wed, 27 Nov 2013 20:11:04 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Apps Discuss References: <52964F8F.6000402@cs.tcd.ie> In-Reply-To: <52964F8F.6000402@cs.tcd.ie> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <52964F8F.6000402@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] thread elsewhere relevant to UTA (was:Fwd: Re: [cryptography] [Cryptography] Email is unsecurable) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 27 Nov 2013 20:16:42 -0000 Hiya, This mail was on another list but might be worth thinking about by the putative UTA wg. The idea below about combining DKIM with anon-DH TLS could also do with a sanity check from mail folks in case its just broken. (Which often happens with stuff I imagine might work for mail:-) I'm happy to explain it more, but it can probably wait until the WG is formed, just wanted to get it in an IETF mail archive so its less likely to get forgotten if it is useful. S. -------- Original Message -------- Subject: Re: [cryptography] [Cryptography] Email is unsecurable Date: Wed, 27 Nov 2013 20:01:19 +0000 From: Stephen Farrell To: Nico Williams CC: cryptography@randombit.net Hiya, On 11/27/2013 06:58 PM, Nico Williams wrote: >>> I could imagine something like Received headers to document how each >>> SMTP (and SUBMIT) end-point was authenticated (if they were) along a >>> mail transfer path. This would be of some utility, particularly for >>> *short* paths (MUA->MSA->MTA->mailbox); for longer paths this loses its >>> utility. >> >> Not sure I get the utility there, at least as in scope for >> this proposed WG. Do you mean the receiving MUA would display >> the message differently or something? > > Yes. You get an e-mail from me. Your edge MTA authenticated my MTA and > my MTA claims to have authenticated me. Add in a signature by my MSA > over the relevant headers and body and your MUA can display my e-mail as > more authenticated than one that transited a non-secure link (or where > the transfer path was longer). I'm not sure detecting the path length in terms of ADMDs is so easy, not so useful in terms of MTAs (with all the spam checking that can go on), nor that the above is really explicable to users. We'd need to ask some mail folks. But I like the emerging scheme below a good bit more:-) > Note that there'd be a need for using DANE to authenticate MTAs acting > as *clients*. There'd be no need to prove the use of DANE for > authenticating MTAs acting servers: if the mail gets to its intended > destination, and the transit path is the shortest possible path, then > we're good to go. But it'd still be desirable to use DANE for > authenticating MTAs acting servers: to prevent e-mail falling into the > wrong hands. > > Note too that if a path is longer than the absolute shortest possible > path then it's difficult to verify that there was no MITM in the path. > That is, an MTA along the path could have had its DNS MX RR lookups > spoofed so as to transfer my email to you via an MITM (who then gets to > see it). It's not like a client can prove to a server that the client > used DANE to authenticate the server, so the servers can't protect > against this. The shortest path will generally be: my MUA->my MSA, my > MTA -> your MTA, your MTA -> your mailbox. Internal MTA hops on my > and/or your side are irrelevant and can be noted as such or even not > recorded (assuming our respective internal networks are secure). Policy > could be used to validate longer-than-shortest paths, but in practice > just the shortest-path approach will suffice. > >> There might be an idea there though if some of the hops used >> e.g. anon-DH and someone developed a generic witness protocol >> to help try spot MITM attacks on that, and if the MSA and MTAs >> DKIM-sign messages, then a message header field containing the >> inbound & outbound witness-protocol PDUs that was included in >> the DKIM signature could be good. > > If there's just anon-DH it's not terribly useful except as a way to > bootstrap up to using DANE. If you use DANE then you get the above > property (all hops authenticated == much better than one [or more] hops > not authenticated). Not sure I agree with you there, esp if something could be bound to DKIM at or by the ADMD TLS endpoints. The problem with DANE is the lack of DNSSEC. If we had both I fully agree it'd be better than using anon-DH. But I figure there's a chance mail providers could do a DKIM thing in the very near future and get some benefit. Otherwise I think we're in agreement and I'll send a pointer to this sub-thread to apps-discuss so follow up can happen there. (I think you're on that list right?) Cheers, S. >> That sounds like it'd be a bit out the scope for UTA but if >> that's what you meant (or similar) but I'd say a mail to >> apps-discuss on that would be useful. > > Right. > >> But I don't think we'd want the UTA WG to be the one to >> develop a protocol for how to post-facto spot a MITM on anon-DH >> or other TLS sessions though. (Anyone got suggestions for that >> btw? Probably a different thread though.) > > Agreed. > >> (And yes, the above would depend on DKIM public key records in >> the non-DNSSEC DNS, so a DANE like thing and DNSSEC would be >> stronger, but given that lots of large and small mail services >> already do DKIM and don't change their keys that often, even >> the non-DNSSEC thing might be good enough.) > > I'd prefer the hop-by-hop DANE thing for e-mail. It makes much more > sense. > _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography From alexey.melnikov@isode.com Thu Nov 28 06:37:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DACF1ADBFF for ; Thu, 28 Nov 2013 06:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.47 X-Spam-Level: X-Spam-Status: No, score=-0.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wV8Owk99EQsJ for ; Thu, 28 Nov 2013 06:37:01 -0800 (PST) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 898081AD8D5 for ; Thu, 28 Nov 2013 06:37:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1385649416; d=isode.com; s=selector; i=@isode.com; bh=9in335wjhU54n5JM8AYVA4RmN1H9Y2Lc6mJYpNoIvJU=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=gMvkQHFNTo1eCucx/58Y/baqzQZvawv3tHGszdkyyJDIxd1EYZnMVOF4Sh2fLrYucBGAUr na8hIhJ2ZcIXPrMcxTt85ay2am5yFRXf2kej+aUafvZUbFMEwmx2rfM1LXsQI0md/ZGd6b 7HERICG0Mi6jcCWGKQtupFy3pREH41o=; Received: from [172.16.1.29] (richard.isode.com [62.3.217.249]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 28 Nov 2013 14:36:56 +0000 Message-ID: <52975509.4070401@isode.com> Date: Thu, 28 Nov 2013 14:36:57 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: "Murray S. Kucherawy" References: <20131120080026.25156.23231.idtracker@ietfa.amsl.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------060400040404000809080900" Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 14:37:03 -0000 This is a multi-part message in MIME format. --------------060400040404000809080900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 20/11/2013 08:02, Murray S. Kucherawy wrote: > On Wed, Nov 20, 2013 at 12:00 AM, > wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Applications Area Working Group > Working Group of the IETF. > > Title : The Require-Recipient-Valid-Since Header > Field and SMTP Service Extension > Author(s) : William J. Mills > Murray S. Kucherawy > Filename : draft-ietf-appsawg-rrvs-header-field-04.txt > Pages : 20 > Date : 2013-11-19 > > Abstract: > This document defines an extension for the Simple Mail Transfer > Protocol called RRVS, and a header field called Require-Recipient- > Valid-Since, to provide a method for senders to indicate to > receivers > the time when the sender last confirmed the ownership of the target > mailbox. This can be used to detect changes of mailbox ownership, > and thus prevent mail from being delivered to the wrong party. > > The intended use of these facilities is on automatically generated > messages that might contain sensitive information, though it > may also > be useful in other applications. > > > Incorporates a lot of suggestions from Ned, Alexey, and John. Diff > available from the datatracker. Have at it! This version is much better and it addresses various issues related to mailing list and redirection. I am happy with it. --------------060400040404000809080900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 20/11/2013 08:02, Murray S. Kucherawy wrote:
On Wed, Nov 20, 2013 at 12:00 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

        Title           : The Require-Recipient-Valid-Since Header Field and SMTP Service Extension
        Author(s)       : William J. Mills
                          Murray S. Kucherawy
        Filename        : draft-ietf-appsawg-rrvs-header-field-04.txt
        Pages           : 20
        Date            : 2013-11-19

Abstract:
   This document defines an extension for the Simple Mail Transfer
   Protocol called RRVS, and a header field called Require-Recipient-
   Valid-Since, to provide a method for senders to indicate to receivers
   the time when the sender last confirmed the ownership of the target
   mailbox.  This can be used to detect changes of mailbox ownership,
   and thus prevent mail from being delivered to the wrong party.

   The intended use of these facilities is on automatically generated
   messages that might contain sensitive information, though it may also
   be useful in other applications.


Incorporates a lot of suggestions from Ned, Alexey, and John.  Diff available from the datatracker.  Have at it!
This version is much better and it addresses various issues related to mailing list and redirection. I am happy with it.

--------------060400040404000809080900-- From ht@inf.ed.ac.uk Thu Nov 28 08:30:23 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776191AE1CE for ; Thu, 28 Nov 2013 08:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.902 X-Spam-Level: X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOl07ItQe_zX for ; Thu, 28 Nov 2013 08:30:20 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 3F85E1AE1C4 for ; Thu, 28 Nov 2013 08:30:19 -0800 (PST) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id rASGUCJt017422; Thu, 28 Nov 2013 16:30:12 GMT Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rASGUASX014569; Thu, 28 Nov 2013 16:30:11 GMT Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id rASGUBb5027309; Thu, 28 Nov 2013 16:30:11 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rASGU9Zs027305; Thu, 28 Nov 2013 16:30:09 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= References: <20131119120919.12901.59046.idtracker@ietfa.amsl.com> <528C980D.7070106@it.aoyama.ac.jp> <5295C454.6050006@it.aoyama.ac.jp> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 28 Nov 2013 16:30:09 +0000 In-Reply-To: <5295C454.6050006@it.aoyama.ac.jp> ("Martin J. =?iso-8859-1?Q?D=FCrst=22's?= message of "Wed\, 27 Nov 2013 19\:07\:16 +0900") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 16:30:23 -0000 Martin J. D=FCrst writes: > So I have tried a re-write, but I'm not totally sure this will work > for all of the document. Please check. Thanks! > Both XML (in an XML or Text declaration using the encoding pseudo- > attribute) and MIME (in a Content-Type header field using the > charset parameter) use a common set of labels [IANA-charsets] to > identify the MIME charset (mapping from byte stream to character > sequence [RFC2978]). Perfect. > In this specification we will use the phrases "charset parameter" > and "encoding declaration" to refer to whatever MIME charset is > specified by a MIME charset parameter or XML encoding declaration > respectively, reserving the phrase "character encoding" for MIME > charset actually used in a particular XML MIME entity. OK. > XML requires support for the MIME charsets UTF-8 and UTF-16, and > allows others. In this specification, the term "UTF-16" is restricted > to the MIME charset of the same name as defined in [RFC2781], whereas > the term "the UTF-16 family" refers to "utf-16", "utf-16le", and > "utf-16be". So this is, I think, not how I want to go. Rather, more like UNICODE defines three "encoding forms", which are independent of serialization, namely UTF-8, UTF-16 and UTF-32. This specification follows this precedent. In particular, note that UTF-16-encoded XML documents may be serialised into MIME entities in one of two ways: either big-endian, labelled (optionally) "utf-16" or "utf-16be", or little-endian, labelled (optionally) "utf-16" or "utf-16le". As UTF-8 can only be serialized in one way, the only possible label for UTF-8-encoded documents when serialised into MIME entities is "utf-8". ht --=20 Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged s= pam] From ned.freed@mrochek.com Thu Nov 28 09:14:19 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C981AE17D for ; Thu, 28 Nov 2013 09:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oNGkyYYqDXZ for ; Thu, 28 Nov 2013 09:14:17 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 892ED1AE058 for ; Thu, 28 Nov 2013 09:14:17 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P1BCHFON6O001NPM@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 28 Nov 2013 09:09:13 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P18HARGJGG00004G@mauve.mrochek.com>; Thu, 28 Nov 2013 09:09:07 -0800 (PST) Message-id: <01P1BCHD8JTY00004G@mauve.mrochek.com> Date: Thu, 28 Nov 2013 08:25:52 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 27 Nov 2013 09:36:54 -0600" <52961196.5080700@qti.qualcomm.com> References: <20131120223533.8958.23858.idtracker@ietfa.amsl.com> <01P14CWFCE5A00004G@mauve.mrochek.com> <5294DDEE.4070000@qti.qualcomm.com> <01P19CETU4PU00004G@mauve.mrochek.com> <52961196.5080700@qti.qualcomm.com> To: Pete Resnick Cc: "draft-ietf-appsawg-malformed-mail@tools.ietf.org" , Ned Freed , IETF Apps Discuss , SM , "appsawg-chairs@tools.ietf.org" Subject: Re: [apps-discuss] Pete Resnick's Yes on draft-ietf-appsawg-malformed-mail-10: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 17:14:19 -0000 (IESG dropped from this since they have better things to do than discuss message format arcana.) > Actually, that's not quite true. The spec is clear that the Return-Path: > is always on top of it's associated Received: fields. I'm skeptical of this claim. RFC 5322 section 3.6 states: It is important to note that the header fields are not guaranteed to be in a particular order. They may appear in any order, and they have been known to be reordered occasionally when transported over the Internet. However, for the purposes of this specification, header fields SHOULD NOT be reordered when a message is transported or transformed. More importantly, the trace header fields and resent header fields MUST NOT be reordered, and SHOULD be kept in blocks prepended to the message. See sections 3.6.6 and 3.6.7 for more information. Seems to me this says that trace fields can't be reordered once they are generated, but at the same time this appears to provide carte blanche for a given operation adding trace fields to do it in any order it pleases. And even if you believe that the ABNF showing that return-path comes first within a given block overrides this text, there's also the fact that a header "block" is itsef an ill-defined notion. I can easily envision an implementation that adds return-path and one received field at one step, followed by another process that adds another received field to log some additional processing done to the message. Since the specification never comes out and says that a given create/submit/relay/deliver step MUST only add a single block of trace fields, you've completely lost the ability to call an implementation incompliant when it meets the technical requirements of the ABNF by generating multiple blocks during one of these operations. > And though not crystal clear, it certainly implies that the Resent-Fields: get > prepended *before* being reintroduced into the transport system, which is what > ought to be prepending the Received: and Return-Path: fields. The situation with resent-* is, if anything, worse. It would be one thing if resent-* were associated exclusively with a particular sort of manual message submission operation, which necessarily occurs after final delivery and thus if everything is working perfectly will result in a clear ordering of blocks. But RFC 5322 doesn't restrict resent-* fields to that role. And that means that you cannot count on a delivery event having occurred prior to the "reintroduction" event that's adding the resent-* fields. Just as one example, sieve redirect can easily be seen to meet the criteria of RFC 5322 section 3.6.6 irrespective of whether or not it's done prior to final deliver, and in practice some sieve implementations operating before final delivery do add resent- fields. (We provide it as an option in our implementation.) How this then maps onto a particular set of block additions to the message is anyone's guess. Ned From ned.freed@mrochek.com Fri Nov 29 09:52:08 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572EF1ADDD0; Fri, 29 Nov 2013 09:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daZ9T0u5iQ0J; Fri, 29 Nov 2013 09:52:07 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 170511ACCD8; Fri, 29 Nov 2013 09:52:07 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P1CS3NWTXS001KJJ@mauve.mrochek.com>; Fri, 29 Nov 2013 09:47:02 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P18HARGJGG00004G@mauve.mrochek.com>; Fri, 29 Nov 2013 09:46:57 -0800 (PST) Message-id: <01P1CS3LR0X000004G@mauve.mrochek.com> Date: Fri, 29 Nov 2013 09:39:52 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 27 Nov 2013 09:46:21 -0600" <529613CD.8060307@qti.qualcomm.com> References: <20131120223533.8958.23858.idtracker@ietfa.amsl.com> <01P14CWFCE5A00004G@mauve.mrochek.com> <5294DDEE.4070000@qti.qualcomm.com> <529613CD.8060307@qti.qualcomm.com> To: Pete Resnick Cc: "draft-ietf-appsawg-malformed-mail@tools.ietf.org" , Ned Freed , IETF Apps Discuss , SM , "appsawg-chairs@tools.ietf.org" , The IESG Subject: Re: [apps-discuss] Pete Resnick's Yes on draft-ietf-appsawg-malformed-mail-10: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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 Nov 2013 17:52:08 -0000 > Everything in the diff you sent looks great. Just one outstanding bit: > On 11/26/13 12:23 PM, Murray S. Kucherawy wrote: > > > > 7.5 - > > What's the difference between 3& 4? Or maybe I don't > > know what "compound > > instance" means in 3. > > > > > > You never did answer that question. > > > > > > I thought I clarified that in the latest draft by explaining what was > > meant by "compound instance". > Could you give me an example of 3 (a compound instance) which is not a 4? I don't know of any in RFC 5322, but I've seen content-disposition information scattered across multiple instances of the header. But not often enough to bother coding any kind of support to handle it. That said, "3 but not 4" would appear to be sufficiently obscure that I have no problem with combining them. Ned From superuser@gmail.com Sat Nov 30 20:31:28 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1071AE2D8; Sat, 30 Nov 2013 20:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbl70JAlh3nr; Sat, 30 Nov 2013 20:31:26 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id EFEF61AE08F; Sat, 30 Nov 2013 20:31:25 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id q59so10839410wes.27 for ; Sat, 30 Nov 2013 20:31:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0LJRC3fVwQyL7wzk54RKgzHr0pXTuHtHrfKs5BJJV9Y=; b=paxnhAUbkoAaeT6NLDwcNZzWxVyYVqJTqXVpx7BoeQmtZINkPltN/HCWigxAk9qnFX nBGiQGdPGriciknjIdsMYZuGwCnG3IJY3Ag79qH1jqJSQ/I9sUEuPAP+DAhKnWxgyefM cvsYM4/TOYoH3JmZibPnQV6hhAu/hASRrXXkQYMBcStm4FNwpF81iv4VO5EZLn6Ee4Df z5UZsxpJ1cQcDkCwYa2x2II6Fkt1Fcm6SKpZHc6sbj0lowiGMH5ZBS4w+uMLaXsJIGPJ +0rLPfYceRm97wkbF8IhJypeg7YGx0VYSj1Zay1JlubWmW0zKJB9c6VGMNf7fveueCFn XuCQ== MIME-Version: 1.0 X-Received: by 10.180.182.136 with SMTP id ee8mr12923469wic.19.1385872283681; Sat, 30 Nov 2013 20:31:23 -0800 (PST) Received: by 10.181.13.230 with HTTP; Sat, 30 Nov 2013 20:31:23 -0800 (PST) In-Reply-To: <01P1CS3LR0X000004G@mauve.mrochek.com> References: <20131120223533.8958.23858.idtracker@ietfa.amsl.com> <01P14CWFCE5A00004G@mauve.mrochek.com> <5294DDEE.4070000@qti.qualcomm.com> <529613CD.8060307@qti.qualcomm.com> <01P1CS3LR0X000004G@mauve.mrochek.com> Date: Sat, 30 Nov 2013 20:31:23 -0800 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=089e016346b42c47db04ec718927 Cc: "draft-ietf-appsawg-malformed-mail@tools.ietf.org" , IETF Apps Discuss , Pete Resnick , SM , "appsawg-chairs@tools.ietf.org" , The IESG Subject: Re: [apps-discuss] Pete Resnick's Yes on draft-ietf-appsawg-malformed-mail-10: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Dec 2013 04:31:28 -0000 --089e016346b42c47db04ec718927 Content-Type: text/plain; charset=ISO-8859-1 Concur. I'll send that out momentarily to you guys and, if no objections, I'll send it to the RFC Editor to replace -11. -MSK On Fri, Nov 29, 2013 at 9:39 AM, Ned Freed wrote: > Everything in the diff you sent looks great. Just one outstanding bit: >> > > On 11/26/13 12:23 PM, Murray S. Kucherawy wrote: >> > >> > 7.5 - >> > What's the difference between 3& 4? Or maybe I don't >> > know what "compound >> > instance" means in 3. >> > >> > >> > You never did answer that question. >> > >> > >> > I thought I clarified that in the latest draft by explaining what was >> > meant by "compound instance". >> > > Could you give me an example of 3 (a compound instance) which is not a 4? >> > > I don't know of any in RFC 5322, but I've seen content-disposition > information > scattered across multiple instances of the header. But not often enough to > bother coding any kind of support to handle it. > > That said, "3 but not 4" would appear to be sufficiently obscure that I > have no > problem with combining them. > > Ned > --089e016346b42c47db04ec718927 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Concur.=A0 I'll send that out momentarily to you = guys and, if no objections, I'll send it to the RFC Editor to replace -= 11.

-MSK


On Fri, Nov 29, 2013 at 9:39 AM, Ned Freed <ned.freed@mrochek.com&= gt; wrote:
Everything in the diff you sent looks great. Just one outstanding bit:

On 11/26/13 12:23 PM, Murray S. Kucherawy wrote:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 7.5 -
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 What's the difference between 3&am= p; =A04? Or maybe I don't
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 know what "compound
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 instance" means in 3.
>
>
> =A0 =A0 You never did answer that question.
>
>
> I thought I clarified that in the latest draft by explaining what was<= br> > meant by "compound instance".

Could you give me an example of 3 (a compound instance) which is not a 4?

I don't know of any in RFC 5322, but I've seen content-disposition = information
scattered across multiple instances of the header. But not often enough to<= br> bother coding any kind of support to handle it.

That said, "3 but not 4" would appear to be sufficiently obscure = that I have no
problem with combining them.=

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ned

--089e016346b42c47db04ec718927-- From superuser@gmail.com Sat Nov 30 20:33:05 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470E91AE2DF; Sat, 30 Nov 2013 20:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdkiT9K0XQQQ; Sat, 30 Nov 2013 20:33:03 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id E49301AE08F; Sat, 30 Nov 2013 20:33:02 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id en1so3416843wid.15 for ; Sat, 30 Nov 2013 20:33:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HcwA4JJ2IeeMbvdQ2yHlQC5bVlyhRs7uW4eVsNkCFg8=; b=HjcCPaTfJizCyExXdvPCU9CgaGDZTjdWVJWlirBiHSM4s6gDUgk43mlJBEj+4JwQnD A7OkFlR7q4g/kJDcv6+r4Oak1mQJaRLnzgtsQwefxHru8FzElOApovYaK3fJA98jB7j/ L4e048eQKaiVH1BgivoLX2pf4DuQTNeZQsmU/XjkmuxWlWYgRJ+0LmSPiLIliAJUMo6E C0cCsZ+ZxG1R5Dh+y8FskqIvrIGr2L6BJ4o5IjUfoElmTf8oeW9dsy1YzomYw+xptGTm MnfFbXPTMQ9B6P3k1YwDGZZ+2mm6ovTyV8HLBb69UKxxDasFl9FCSXwzSN5KcbW8hdML 5HAw== MIME-Version: 1.0 X-Received: by 10.180.182.136 with SMTP id ee8mr12927080wic.19.1385872380677; Sat, 30 Nov 2013 20:33:00 -0800 (PST) Received: by 10.181.13.230 with HTTP; Sat, 30 Nov 2013 20:33:00 -0800 (PST) In-Reply-To: References: <20131120223533.8958.23858.idtracker@ietfa.amsl.com> <01P14CWFCE5A00004G@mauve.mrochek.com> <5294DDEE.4070000@qti.qualcomm.com> <529613CD.8060307@qti.qualcomm.com> <01P1CS3LR0X000004G@mauve.mrochek.com> Date: Sat, 30 Nov 2013 20:33:00 -0800 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=089e016346b4f454c704ec718ee5 Cc: "draft-ietf-appsawg-malformed-mail@tools.ietf.org" , IETF Apps Discuss , Pete Resnick , SM , "appsawg-chairs@tools.ietf.org" , The IESG Subject: Re: [apps-discuss] Pete Resnick's Yes on draft-ietf-appsawg-malformed-mail-10: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 01 Dec 2013 04:33:05 -0000 --089e016346b4f454c704ec718ee5 Content-Type: text/plain; charset=ISO-8859-1 http://www.blackops.org/~msk/draft-ietf-appsawg-malformed-mail-from--10.diff.html I'll send it Monday unless I hear otherwise. On Sat, Nov 30, 2013 at 8:31 PM, Murray S. Kucherawy wrote: > Concur. I'll send that out momentarily to you guys and, if no objections, > I'll send it to the RFC Editor to replace -11. > > -MSK > > > On Fri, Nov 29, 2013 at 9:39 AM, Ned Freed wrote: > >> Everything in the diff you sent looks great. Just one outstanding bit: >>> >> >> On 11/26/13 12:23 PM, Murray S. Kucherawy wrote: >>> > >>> > 7.5 - >>> > What's the difference between 3& 4? Or maybe I don't >>> > know what "compound >>> > instance" means in 3. >>> > >>> > >>> > You never did answer that question. >>> > >>> > >>> > I thought I clarified that in the latest draft by explaining what was >>> > meant by "compound instance". >>> >> >> Could you give me an example of 3 (a compound instance) which is not a 4? >>> >> >> I don't know of any in RFC 5322, but I've seen content-disposition >> information >> scattered across multiple instances of the header. But not often enough to >> bother coding any kind of support to handle it. >> >> That said, "3 but not 4" would appear to be sufficiently obscure that I >> have no >> problem with combining them. >> >> Ned >> > > --089e016346b4f454c704ec718ee5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sat,= Nov 30, 2013 at 8:31 PM, Murray S. Kucherawy <superuser@gmail.com&g= t; wrote:
Concur.=A0 I'll se= nd that out momentarily to you guys and, if no objections, I'll send it= to the RFC Editor to replace -11.

-MSK=


On Fri, Nov 29, 2013 at 9:39 AM, Ned Freed <ned.freed@mrochek.com&= gt; wrote:
Everything in the diff you sent looks great. Just one outstanding bit:

On 11/26/13 12:23 PM, Murray S. Kucherawy wrote:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 7.5 -
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 What's the difference between 3&am= p; =A04? Or maybe I don't
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 know what "compound
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 instance" means in 3.
>
>
> =A0 =A0 You never did answer that question.
>
>
> I thought I clarified that in the latest draft by explaining what was<= br> > meant by "compound instance".

Could you give me an example of 3 (a compound instance) which is not a 4?

I don't know of any in RFC 5322, but I've seen content-disposition = information
scattered across multiple instances of the header. But not often enough to<= br> bother coding any kind of support to handle it.

That said, "3 but not 4" would appear to be sufficiently obscure = that I have no
problem with combining them.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ned


--089e016346b4f454c704ec718ee5--