From vesely@tana.it Thu Aug 1 05:11: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 8B70B21F9CDF for ; Thu, 1 Aug 2013 05:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 o6tuhpDjkPkE for ; Thu, 1 Aug 2013 05:11:21 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9316D21F996A for ; Thu, 1 Aug 2013 05:09:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1375358938; bh=NsWwZZCpRJm2KbpVSUQ06J1CgnXO1ILomiGok1lwnyA=; l=1956; h=Date:From:To; b=QXuniwLPda1IV9f81gD//pi28zPjee797wGFjZN+EgJnEMD/f2Ni4hgxGKSUJT87u OUJCdqX+lgMV61DB0bU/qex/IUTD2M+8KPbSYKEtjK54bzFeUnWFOTtEispGUo2J4r R4EQqbzK5MYnrl0PO5e9GOTcbdWWZ9jIJgu7zCVw= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [130.129.21.254] (dhcp-15fe.meeting.ietf.org [130.129.21.254]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3, 256bits, AES256-SHA) by wmail.tana.it with ESMTPSA; Thu, 01 Aug 2013 14:08:58 +0200 id 00000000005DC035.0000000051FA4FDA.00006516 Message-ID: <51FA4FD9.3030902@tana.it> Date: Thu, 01 Aug 2013 14:08:57 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: IETF Apps Discuss Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] An Authentication-Results method for white (and black) lists 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, 01 Aug 2013 12:11:32 -0000 Comparing *dnswl*, http://www.dnswl.org/tech Categories (127.0.X.y): 2 - Financial services 3 - Email Service Providers 4 - Organisations (both for-profit [ie companies] and non-profit) 5 - Service/network providers 6 - Personal/private servers 7 - Travel/leisure industry 8 - Public sector/governments 9 - Media and Tech companies 10 - some special cases 11 - Education, academic 12 - Healthcare 13 - Manufacturing/Industrial 14 - Retail/Wholesale/Services 15 - Email Marketing Providers Trustworthiness / Score (127.0.x.Y): 0 = none - only avoid outright blocking (eg Hotmail, Yahoo mailservers, -0.1) 1 = low - reduce chance of false positives (-1.0) 2 = medium - make sure to avoid false positives but allow override for clear cases (-10.0) 3 = high - avoid override (-100.0). and *swl*, http://www.spamhauswhitelist.com/en/usage.html 127.0.2.2 IP sending individual mail 127.0.2.3 IP sending transactions 127.0.2.102 IP sending individual mail - Temporary Courtesy Listing (entry will expire) 127.0.2.103 IP sending transactions - Temporary Courtesy Listing (entry will expire) I find the score is an actionable value, as it can be directly compared with scores obtained by other means (spamassassin). Interesting as the other values are, I'm not clear on if/how they are used. In order to uniformize the result of a lookup, one would need a default value, e.g. one could assign a score of 50 to the entries in the swl, as swl provides no hint on how to compute one. I posted an attempt in http://tools.ietf.org/html/draft-vesely-authmethod-dnswl-01 Any suggestion on how to improve that? Please note that version 00 of that thing simply provided for copying any A and/or TXT records retrieved from a list, as if there were only one list, whose encoding could then be assumed as the de-facto standard. ("TXT" still appears in a few places of version 01, erroneously.) From Peter.Rushforth@NRCan-RNCan.gc.ca Thu Aug 1 09:22: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 556C611E8121 for ; Thu, 1 Aug 2013 09:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=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 vO-gapPJ41Pi for ; Thu, 1 Aug 2013 09:22:25 -0700 (PDT) Received: from nrcan.gc.ca (s-bsc-edge1.nrcan.gc.ca [132.156.238.13]) by ietfa.amsl.com (Postfix) with ESMTP id 731E211E811E for ; Thu, 1 Aug 2013 09:22:12 -0700 (PDT) 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; Thu, 1 Aug 2013 12:22:10 -0400 Received: from S-BSC-MBX1.nrn.nrcan.gc.ca ([169.254.1.190]) by S-BSC-CAS2.nrn.nrcan.gc.ca ([fe80::48d4:f168:78ba:d4e8%19]) with mapi id 14.02.0342.003; Thu, 1 Aug 2013 12:22:10 -0400 From: "Rushforth, Peter" To: Erik Wilde Thread-Topic: New Version Notification for draft-wilde-atom-profile-02.txt Thread-Index: AQHOjDCI9XQy2nN2qEqEl76+2ahvXJl7we3Q Date: Thu, 1 Aug 2013 16:22:09 +0000 Message-ID: <1CD55F04538DEA4F85F3ADF7745464AF24A50613@S-BSC-MBX1.nrn.nrcan.gc.ca> References: <20130729071438.10957.87683.idtracker@ietfa.amsl.com> <51F61F2A.8030403@berkeley.edu> In-Reply-To: <51F61F2A.8030403@berkeley.edu> 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] New Version Notification for draft-wilde-atom-profile-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, 01 Aug 2013 16:22:30 -0000 Hi dret, In general I think this is a good addition to profiles. A few points thou= gh. This specification should consider updating RFC 5023 instead of 4287, since the atomsvc+xml and atomcat+xml sub-types are defined by 5023=20 and could/should also leverage the profile media type parameter. In the Examples section 2.3, the draft says that clients requesting a colle= ction from an AtomPub feed have no indication that the service supports=20 atompub. This is not true, as the service can send the 'type=3Dfeed' media type parameter, which is defined by RFC 5023, indicating the feed has atompub support. http://tools.ietf.org/html/rfc5023#section-12 This was associated with the application/atom+xml media type by the RFC 5023 registration: http://tools.ietf.org/html/rfc5023#page-43 In the Section 1, paragraph 2, http://tools.ietf.org/html/draft-wilde-atom-= profile-02#section-1 you describe a profile as being additional semantics layered on the original media type semantics so long as they don't change the semantics of the original media type, only add to them. Furthermore, in paragraph 3 you say that profiles are identified by URI. This brings to mind link re= lations,=20 and its my suggestion that profiles should use the same model, i.e. a URI f= or=20 a non-registered profile and a simple token for a registered profile, where= the registration maintains the syntax and semantics of the profile. It would then be the 'responsibility' of the URI owner to provide a definit= ion for=20 the extended semantics, while a token-based profile would have its semantic= s in the central registry. In this way, I think, the self-describing messages constraint of REST can b= e respected by mime types carrying profile parameters. We have _experimentally_ implemented the profile media type parameter and l= ink relation in our (beta) service, categories, feed and entry documents: http://geogratis.gc.ca/api/beta/en/nrcan-rncan/ http://geogratis.gc.ca/api/beta/en/nrcan-rncan/ess-sst/$categories http://geogratis.gc.ca/api/beta/en/nrcan-rncan/ess-sst/ http://geogratis.gc.ca/api/beta/en/nrcan-rncan/ess-sst/647e6de7-5192-5fb0-8= 631-ac3d7263e2ee Note: add ?alt=3Dxml to the above URIs to view the xml in a browser, or neg= otiate for the appropriate=20 application/atom(*)+xml to view the profile media type parameter. Any feedback would be appreciated. If you like, I will send you the requ= ested information for the implementation section per specs below. Cheers, Peter=20 > -----Original Message----- > From: Erik Wilde [mailto:dret@berkeley.edu]=20 > Sent: July 29, 2013 03:52 > To: apps-discuss@ietf.org application-layer protocols;=20 > Atom-Syntax; Atom-Protocol > Cc: REST-Discuss > Subject: Fw: New Version Notification for=20 > draft-wilde-atom-profile-02.txt >=20 > hello. >=20 > a new version of draft-wilde-atom-profile has been posted. if=20 > you are using profiles with atom, and specifically the=20 > proposed profile media type parameter, please get in touch.=20 > it would be great to add implementations to > http://tools.ietf.org/html/draft-wilde-atom-profile-02#section -5 (please see http://tools.ietf.org/html/rfc6982#section-2 for > a descrip= tion of the implementation information needed). >=20 > thanks and cheers, >=20 > dret. >=20 > ---------------------------------------------------------------------- >=20 > On 2013-07-29 9:14 , internet-drafts@ietf.org wrote: > > A new version of I-D, draft-wilde-atom-profile-02.txt has been=20 > > successfully submitted by Erik Wilde and posted to the IETF=20 > > repository. > > > > Filename: draft-wilde-atom-profile > > Revision: 02 > > Title: Profile Support for the Atom Syndication Format > > Creation date: 2013-07-29 > > Group: Individual Submission > > Number of pages: 9 > > URL: =20 > http://www.ietf.org/internet-drafts/draft-wilde-atom-profile-02.txt > > Status: =20 > http://datatracker.ietf.org/doc/draft-wilde-atom-profile > > Htmlized: =20 > http://tools.ietf.org/html/draft-wilde-atom-profile-02 > > Diff: =20 > http://www.ietf.org/rfcdiff?url2=3Ddraft-wilde-atom-profile-02 > > > > Abstract: > > The Atom syndication format is a generic XML format for=20 > representing > > collections. Profiles are one way how Atom feeds can=20 > indicate that > > they support specific extensions. To make this support=20 > visible on > > the media type level, this specification adds an=20 > optional "profile" > > media type parameter to the Atom media type. This=20 > allows profiles to > > become visible at the media type level, so that servers=20 > as well as > > clients can indicate support for specific Atom profiles in > > conversations, for example when communicating via HTTP. This > > specification updates RFC 4287 by adding the "profile"=20 > media type > > parameter to the application/atom+xml media type registration. > = From mnot@mnot.net Thu Aug 1 22:37: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 9690311E8234 for ; Thu, 1 Aug 2013 22:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.636 X-Spam-Level: X-Spam-Status: No, score=-104.636 tagged_above=-999 required=5 tests=[AWL=-2.656, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, 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 VAvtwuE6xroR for ; Thu, 1 Aug 2013 22:37:18 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1C58E11E81D2 for ; Thu, 1 Aug 2013 22:37:18 -0700 (PDT) Received: from [10.59.1.187] (unknown [217.110.189.162]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id ABF8822E255 for ; Fri, 2 Aug 2013 01:37:11 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Aug 2013 07:37:10 +0200 References: <20130802053631.31249.90545.idtracker@ietfa.amsl.com> To: Apps Discuss Message-Id: <60F8F2C3-9139-4E63-8A3F-3C6187A06E71@mnot.net> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [apps-discuss] Fwd: New Version Notification for draft-nottingham-uri-get-off-my-lawn-00.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, 02 Aug 2013 05:37:22 -0000 FYI. Comments / suggestions welcome, as always. Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-nottingham-uri-get-off-my-lawn-00.txt > Date: 2 August 2013 7:36:31 AM GMT+02:00 > To: Mark Nottingham >=20 >=20 > A new version of I-D, draft-nottingham-uri-get-off-my-lawn-00.txt > has been successfully submitted by Mark Nottingham and posted to the > IETF repository. >=20 > Filename: draft-nottingham-uri-get-off-my-lawn > Revision: 00 > Title: Standardising Structure in URIs > Creation date: 2013-08-02 > Group: Individual Submission > Number of pages: 7 > URL: = http://www.ietf.org/internet-drafts/draft-nottingham-uri-get-off-my-lawn-0= 0.txt > Status: = http://datatracker.ietf.org/doc/draft-nottingham-uri-get-off-my-lawn > Htmlized: = http://tools.ietf.org/html/draft-nottingham-uri-get-off-my-lawn-00 >=20 >=20 > Abstract: > It is sometimes attractive to specify a particular structure for = URIs > (or parts thereof) to add support for a new feature, application or > facility. This memo provides guidelines for such situations in > standards documents. >=20 >=20 >=20 >=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. >=20 > The IETF Secretariat >=20 -- Mark Nottingham http://www.mnot.net/ From superuser@gmail.com Thu Aug 1 23:32: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 C4D3311E824A for ; Thu, 1 Aug 2013 23:32:15 -0700 (PDT) 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.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 jErXsuqtzsrg for ; Thu, 1 Aug 2013 23:32:15 -0700 (PDT) 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 0D09911E8249 for ; Thu, 1 Aug 2013 23:32:14 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hj13so207222wib.5 for ; Thu, 01 Aug 2013 23:32:14 -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=VdizmNAQei43MWDV5D9BoB6j6qMXSxaNlk6/EVeR0co=; b=Z1/UxXm6pdnMO2rcUqg8p0KlPacEDsVBN7jW12PmqG/d46UKxjmPLIovsOW6ENvPne 9woa9b1G2BrwcayL+n8ZL4bKq/r3J4tXaMw6mxlMHJDuxWwO1hRqu9iZgXaPqzky8kDg A8HG6iSYjBpmKVnMoIYIM/s+iiBIUOa2VJNnplvnneUuFYmBKpy2VBhz0luEq0zcoOXt 1i0+U0oaMICzsdtaX44DskroQ97m0VpdPZ/GJRjeHVrcQ6NCeyf+Jn1yZKfbXo+N4Ij4 wPtWMhkvCAqFmIJ08zQ4XrTcSAeEWAuAdZUKaNY0c+OLcGZja3VyEiS+3jjYxd8/FgPh EhiA== MIME-Version: 1.0 X-Received: by 10.194.239.225 with SMTP id vv1mr3729488wjc.63.1375425134083; Thu, 01 Aug 2013 23:32:14 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Thu, 1 Aug 2013 23:32:14 -0700 (PDT) Date: Fri, 2 Aug 2013 08:32:14 +0200 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=089e0149338488445804e2f11e32 Subject: [apps-discuss] Draft minutes from IETF 87 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: Fri, 02 Aug 2013 06:32:16 -0000 --089e0149338488445804e2f11e32 Content-Type: text/plain; charset=ISO-8859-1 http://www.ietf.org/proceedings/87/minutes/minutes-87-appsawg The co-chairs thank John Levine for once again taking notes for us during the meeting. Please provide any corrections by August 30th. If none are received, the current version will stand as official. -MSK, APPSAWG co-chair --089e0149338488445804e2f11e32 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The co-chairs thank John Levine for once= again taking notes for us during the meeting.

Please provide any corrections by August 30th.=A0 If none are rec= eived, the current version will stand as official.

-MSK, APPSA= WG co-chair

--089e0149338488445804e2f11e32-- From barryleiba.mailing.lists@gmail.com Fri Aug 2 00: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 5C01B11E8286 for ; Fri, 2 Aug 2013 00:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.97 X-Spam-Level: X-Spam-Status: No, score=-101.97 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Y6B1EAcedF5C for ; Fri, 2 Aug 2013 00:56:44 -0700 (PDT) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 728E111E829D for ; Fri, 2 Aug 2013 00:56:43 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id oz10so323232veb.31 for ; Fri, 02 Aug 2013 00:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=aAruOf1Fy0qSKnRTcQkIwERObBncYLfJv85wfusOKDk=; b=CMX6QFTcYqwUk/3bT7CVKkjPEw/72O3xps8QzIjDTV3OcC+GiGJHSeaT6MEiQDqzDh U9LKPqqdAznMPtoiq4nc7QSKvnd5m4PMaEpTAorgPBMgesZ5B8SmZ2gS5m17qfLzrJ1o 8GHInIDsQESU0QEmWijTNS2yWGJkd5JYgxWlQICy4M0Bjgwq96W2Ezj3CWBuHeje3Uen G/I5RhBNNk1pGYZ48m1zCrhu/7kbFIRmI1u5hllaBTePKJl9p10AWrJZld8CI7HxZEcT FyqtGKIAhcw4AKctKcNOQ622Ix40E842pJ0d6OJddSm3YE6KrrUavqEHaW2yDtk70ft3 ZJ/Q== MIME-Version: 1.0 X-Received: by 10.52.164.227 with SMTP id yt3mr1363668vdb.107.1375430200590; Fri, 02 Aug 2013 00:56:40 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.137.227 with HTTP; Fri, 2 Aug 2013 00:56:40 -0700 (PDT) In-Reply-To: References: Date: Fri, 2 Aug 2013 09:56:40 +0200 X-Google-Sender-Auth: RLAP2bEbEZrNVamaTUTh4rJOzPI Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Draft minutes from IETF 87 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: Fri, 02 Aug 2013 07:56:45 -0000 > http://www.ietf.org/proceedings/87/minutes/minutes-87-appsawg > > The co-chairs thank John Levine for once again taking notes for us during > the meeting. I could probably guess, without your telling me: the last item (John's) has much more detail than the rest. So, can you (perhaps from memory, perhaps from a review of the audio stream) put a comparable level of detail into any of the other items? In particular, in the "openness of process" and "area review" items there are questions, but no sense of the discussion. Editorial: "New WGs chairs described the new WGs" -- needs some sort of punctuation. "Discuss changes in review and management process Questions of managing traffic" -- punctuation here too. "about half the room through it was a relevant problem" -- "thought", not "through". Barry From salvatore.loreto@ericsson.com Fri Aug 2 02:47:38 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 0C21711E82FA for ; Fri, 2 Aug 2013 02:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.671 X-Spam-Level: X-Spam-Status: No, score=-103.671 tagged_above=-999 required=5 tests=[AWL=-1.072, 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 JwOUYJiUuWuk for ; Fri, 2 Aug 2013 02:47:31 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 42D3711E82E8 for ; Fri, 2 Aug 2013 02:47:30 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-3e-51fb8031817d Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 2D.84.11907.1308BF15; Fri, 2 Aug 2013 11:47:29 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.149) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.2.328.9; Fri, 2 Aug 2013 11:47:28 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id DC23E110233 for ; Fri, 2 Aug 2013 12:47:28 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 4415F558FB for ; Fri, 2 Aug 2013 12:47:24 +0300 (EEST) Received: from dhcp-154a.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EA11D5005B for ; Fri, 2 Aug 2013 12:47:23 +0300 (EEST) Message-ID: <51FB802F.1090709@ericsson.com> Date: Fri, 2 Aug 2013 11:47:27 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "apps-discuss@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgluLIzCtJLcpLzFFi42KZGfG3Vtew4XegwexFkharX65gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxusliQVbWCoWfvjJ1sB4ibmLkZNDQsBE4t2FSywQtpjEhXvr 2boYuTiEBI4ySrxYcpMdJCEksJ5RYs09fYjETUaJ/18nskM4pxglTrz8ygbnLFh7mrWLkYOD V0Bb4sMqDZBuFgEViePH2sAmsQmYSTx/uAVstahAssT7K3fAbF4BQYmTM5+AnSEiYCwxafMS NhBbWMBK4m33RrBeZgFbiQtzrrNA2PIS29/OgXpBTeLquU3MEJdqSfSe7WSawCg0C8nYWUja ZyFpX8DIvIqRozi1OCk33chgEyMwNA9u+W2xg/HyX5tDjNIcLErivFv0zgQKCaQnlqRmp6YW pBbFF5XmpBYfYmTi4JQChuInAz7baeuvzynfw5j0zDjWQo+hdM7br3M9fFLNp0fwxnT9NVDP 5/535eLWmNmp8itDKrqCuBrF2ffqCR+NZLZ9cH6JzsOb8tLb1H+tn5lvMiHUMTqwVK/VR/iX rMPKQ6zV80SWxtxrXPZL/8Tqd06X17ZlT7oSwr1595wZhZnPQj9Nb3KSUmIpzkg01GIuKk4E AOE/TJ0bAgAA Subject: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field 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, 02 Aug 2013 09:47:38 -0000 This is a call for adoption for draft-wmills-rrvs-header-field [1] There is a pretty good thread going on apps-discuss [2] that shows an interest within this working group about this work, and it appears to be material that falls within our charter. Accordingly, we'll adopt this as a working group item within the next couple of weeks unless there's objection to such processing. /Salvatore [1] http://www.ietf.org/id/draft-wmills-rrvs-header-field-00.txt [2] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10013.html From kurta@drkurt.com Fri Aug 2 07:34: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 655BC11E80E7 for ; Fri, 2 Aug 2013 07:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 gdB42CN8QyqJ for ; Fri, 2 Aug 2013 07:34:41 -0700 (PDT) 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 BABF121E80D4 for ; Fri, 2 Aug 2013 07:34:30 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so593230wes.12 for ; Fri, 02 Aug 2013 07:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=sV1e8/UD/OiZWcVuaGcmvwX8LgIkxGkCdcdZYY2Rfjw=; b=T0m4tUhd/+DmztY05aqPk35ugXjYoTRWqYpfwtakVgrqpk7E6AZJY6k1W2oXYcxiU2 F+f7lcSTRgrJ65PoYWbN6e+iZms9KL1XwCNLlDsIQU3FUHE93mwUQfKmLw158LgECHeN /MKy0jVZSKOJIbBS3xH0xj3cNThC6tuhI+DTQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=sV1e8/UD/OiZWcVuaGcmvwX8LgIkxGkCdcdZYY2Rfjw=; b=aVCxEhkMNnGqFEQZb9PbeA8AMNKk4/E+3vLTSBuF9YxmLxqyWKj0MUG725R/Ttxcvh ytiYrmrIaRhoHfphOosaW8yzTJG0LPqkMdfGOaISyHx9msK8+9V7Px5OEmcwm6sFkgFD u8xnInhbqp5lSKK72F8sRdeUtNOMKunYwHUg4F0mgQ3IFNVWvN1v0rzgC5tkt+ij9lkP iNbrOJntv63RhLSr1qei7PAfXz6fp+xx5oMz67J+T1NBebBcFYa7Jt+GlcIIJRRMWqHo 0qu/tcQ+c4e60xskaPTvXYClznDeutMV67fvelwphDp5Qv4oXszemlZ9Im0vk0JCnDmG WfVw== X-Gm-Message-State: ALoCoQnu+7z+YRQtBEd19nOD6V7Msr9Ahd7vWOcwE0tYyV/IAEwWB6mbjmvKGBhxm5oEoK1aQCln MIME-Version: 1.0 X-Received: by 10.181.13.145 with SMTP id ey17mr2086929wid.43.1375454069715; Fri, 02 Aug 2013 07:34:29 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.194.249.73 with HTTP; Fri, 2 Aug 2013 07:34:29 -0700 (PDT) Date: Fri, 2 Aug 2013 07:34:29 -0700 X-Google-Sender-Auth: 8D_XX7LhKV_KK9Ssh6zKFYzZse8 Message-ID: From: Kurt Andersen To: IETF Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] Consensus to change time field in draft-wmills-rrvs-header-field-00? 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, 02 Aug 2013 14:34:41 -0000 I'd like to propose changing the time field in the draft-wmills-rrvs-header from [MAIL]'s human-oriented text string to epoch seconds (as used in the DKIM headers [RFC6376 et al]). Such a usage would be more in keeping with the automated nature of the messages that are anticipated to make the most use of this header. Quoting from RFC6376: The format is the number of seconds since 00:00:00 on January 1, 1970 in the UTC time zone. The value is expressed as an unsigned integer in decimal ASCII. This value is not constrained to fit into a 31- or 32-bit integer. Please reply if in favor. Thanks, Kurt Andersen From yoshiro.yoneya@jprs.co.jp Fri Aug 2 09:17: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 5551F21E80ED for ; Fri, 2 Aug 2013 09:17:28 -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 k7jnWBxti3Ii for ; Fri, 2 Aug 2013 09:17:27 -0700 (PDT) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id B3A7221E80EB for ; Fri, 2 Aug 2013 09:17:27 -0700 (PDT) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id r72GHQWr015282 for ; Sat, 3 Aug 2013 01:17:26 +0900 X-AuditID: ac120820-b7f306d00000490a-98-51fbdb934c38 Received: from NOTE340 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id D7.F2.18698.39BDBF15; Sat, 3 Aug 2013 01:17:26 +0900 (JST) Date: Sat, 3 Aug 2013 01:17:17 +0900 From: Yoshiro YONEYA To: apps-discuss@ietf.org Message-Id: <20130803011717.2340e40783b7831775df0b94@jprs.co.jp> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsWyRoiFT3fa7d+BBgf7RCxWv1zB5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIXP97EV/GWrWNt4iK2BcRNrFyMnh4SAicTvnX8ZIWwxiQv3 1rN1MXJxCAkcZ5S4OfM4O0iCRUBFouPALGYQm03AQOLXst9MILaIgKTEvlmTweLCAqoSBzY+ Bqrn4OAVcJDoO+oFMdNC4kJTB1RYUOLvDmGQMLOAlsTDX7dYIGx5ie1v5zBPYOSZhVA1C0nV LCRVCxiZVzHK5Kel6Ran5qUU56YbGOqVVObrZRUUFeslg+hNjOBQ4VDYwTjjlMEhRgEORiUe 3g8FvwKFWBPLiitzDzFKcjApifKevPU7UIgvKT+lMiOxOCO+qDQntfgQowQHs5IIb/sFoBxv SmJlVWpRPkxKmoNFSZz3+J8zgUIC6YklqdmpqQWpRTBZGQ4OJQneBpChgkWp6akVaZk5JQhp Jg5OkOE8QMMPgNTwFhck5hZnpkPkTzFKSonz+oMkBEASGaV5cL2vGMWBXhDm7QPJ8gDjHq7r FdBAJqCBSnN+gQwsSURISTUwsp+U4tAI/DVBs/r3+uLrTMdET8/cOvW8C3tGBc/MOOvF7vu+ PXZK/+o3ReeZW6OelShn4V7j74/rn4oqXNHsSJGYEjFX6cePdUbq7lkseqorT0+edEfny5Rk pylXmdkYGv2Eu8LlGMruTY6Vkr1sIvdG/e4UebPJEsynmTz5/krUC2Yuj3mqxFKckWioxVxU nAgAXqcTLLgCAAA= Subject: [apps-discuss] IETF87 WG Summary: precis wg 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, 02 Aug 2013 16:17:28 -0000 precis WG met on Friday from 09:00 to 11:00. We discussed four WG I-Ds and one individual I-D. - framework Comparison of output from two independent implementations which generate derived property code table will take place by the end of August. Will move to WG LC after that. - nickname Waiting for write-up and then send it to IESG. - mappings A document update will be done and then the document will be moved to WG LC. - saslprepbis Will add guidance for precis profile authors who doesn't use SASL for credentials. - httpauthprep Investigate if (new) saslprepbis is applicable. Add clear texts about what and when clients and servers prepare strings. After httpauthprep discussion, there was a question that which WG, httpauth or precis, is appropriate to discuss httpauthprep. Our AD will consult it to IESG. Marc & Yoshiro From mca@amundsen.com Fri Aug 2 21:37: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 E065211E80DC for ; Fri, 2 Aug 2013 21:37:18 -0700 (PDT) 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 GIvAQF+FmbC1 for ; Fri, 2 Aug 2013 21:37:15 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0119121F9A33 for ; Fri, 2 Aug 2013 21:37:14 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hj13so64659wib.5 for ; Fri, 02 Aug 2013 21:37:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=yHeVhquKPc/z+yb+50ERERjGCse1mYwKUvqAgQrKtQ4=; b=UZTz5VVz/0xEVoMFLceMwp5HwffiHTiiFGDFmNnwxZNmx7K44h5GBU2/f7swbUBfYn ZrmpuPSHGLkP1vt2x/4wwNpzmYaRVpZZ7BBa75S3e78F6G6yGw0MptI4a0AzqSfFdo5+ sqKXsh2Lds+Axxrc9zLyxSrCfpQjvpduP83JjSu7nZ7Ac/moqjGV+YtmfDboAesWdRNu fXC4pPDAxhDvczHOFsFYqgVhQMAcRQ2Jy2pE2C/3Na6YC7fZ0ANOxxHV8BNLp/38WpYa QaiImUwtGpMtE4l7WTD5GdtgE+Cwv84HpejAMEqMeSjt7R74rbsAojXP8cLiZZIE3KQc 2WGg== X-Received: by 10.194.173.71 with SMTP id bi7mr7000325wjc.2.1375504632862; Fri, 02 Aug 2013 21:37:12 -0700 (PDT) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.151.103 with HTTP; Fri, 2 Aug 2013 21:36:52 -0700 (PDT) In-Reply-To: <60F8F2C3-9139-4E63-8A3F-3C6187A06E71@mnot.net> References: <20130802053631.31249.90545.idtracker@ietfa.amsl.com> <60F8F2C3-9139-4E63-8A3F-3C6187A06E71@mnot.net> From: mike amundsen Date: Sat, 3 Aug 2013 00:36:52 -0400 X-Google-Sender-Auth: vdK0g18qqnivHnEObX528t970eg Message-ID: To: Mark Nottingham Content-Type: multipart/alternative; boundary=089e0112cf9a07701704e303a1c6 X-Gm-Message-State: ALoCoQnXTJUIWCrD4njFkmsWUwkDnrAP1rTD0GqGkWwta7dij6ZUOTzJh8UewLJMTjqXvFiI2Z2+ Cc: Apps Discuss Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-nottingham-uri-get-off-my-lawn-00.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: Sat, 03 Aug 2013 04:37:19 -0000 --089e0112cf9a07701704e303a1c6 Content-Type: text/plain; charset=ISO-8859-1 here are some people who need to read this draft: http://appurl.org/docs/quickstart 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/mikeamundsen On Fri, Aug 2, 2013 at 1:37 AM, Mark Nottingham wrote: > FYI. Comments / suggestions welcome, as always. > > > Begin forwarded message: > > > From: internet-drafts@ietf.org > > Subject: New Version Notification for > draft-nottingham-uri-get-off-my-lawn-00.txt > > Date: 2 August 2013 7:36:31 AM GMT+02:00 > > To: Mark Nottingham > > > > > > A new version of I-D, draft-nottingham-uri-get-off-my-lawn-00.txt > > has been successfully submitted by Mark Nottingham and posted to the > > IETF repository. > > > > Filename: draft-nottingham-uri-get-off-my-lawn > > Revision: 00 > > Title: Standardising Structure in URIs > > Creation date: 2013-08-02 > > Group: Individual Submission > > Number of pages: 7 > > URL: > http://www.ietf.org/internet-drafts/draft-nottingham-uri-get-off-my-lawn-00.txt > > Status: > http://datatracker.ietf.org/doc/draft-nottingham-uri-get-off-my-lawn > > Htmlized: > http://tools.ietf.org/html/draft-nottingham-uri-get-off-my-lawn-00 > > > > > > Abstract: > > It is sometimes attractive to specify a particular structure for URIs > > (or parts thereof) to add support for a new feature, application or > > facility. This memo provides guidelines for such situations in > > standards documents. > > > > > > > > > > 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 > > > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --089e0112cf9a07701704e303a1c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
here are some people who need to read this draft:




On Fri, Aug 2, 2013 at 1:37 AM, Mark Not= tingham <mnot@mnot.net> wrote:
FYI. Comments / suggestions welcome, as always.


Begin forwarded message:

> From: internet-drafts@ietf= .org
> Subject: New Version Notification for draft-nottingham-uri-get-off-my-= lawn-00.txt
> Date: 2 August 2013 7:36:31 AM GMT+02:00
> To: Mark Nottingham <mnot@mnot.net= >
>
>
> A new version of I-D, draft-nottingham-uri-get-off-my-lawn-00.txt
> has been successfully submitted by Mark Nottingham and posted to the > IETF repository.
>
> Filename: =A0 =A0 =A0draft-nottingham-uri-get-off-my-lawn
> Revision: =A0 =A0 =A000
> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Standardising Structure in URIs=
> Creation date: =A0 =A0 =A0 =A0 2013-08-02
> Group: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission
> Number of pages: 7
> URL: =A0 =A0 =A0 =A0 =A0 =A0 http:/= /www.ietf.org/internet-drafts/draft-nottingham-uri-get-off-my-lawn-00.txt
> Status: =A0 =A0 =A0 =A0 =A0http://datatracker.= ietf.org/doc/draft-nottingham-uri-get-off-my-lawn
> Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/h= tml/draft-nottingham-uri-get-off-my-lawn-00
>
>
> Abstract:
> =A0 It is sometimes attractive to specify a particular structure for U= RIs
> =A0 (or parts thereof) to add support for a new feature, application o= r
> =A0 facility. =A0This memo provides guidelines for such situations in<= br> > =A0 standards documents.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>

--
Mark Nottingham =A0 http= ://www.mnot.net/



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

--089e0112cf9a07701704e303a1c6-- From ned.freed@mrochek.com Sun Aug 4 14:25:02 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 B34B421E8096 for ; Sun, 4 Aug 2013 14:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=-0.630, BAYES_20=-0.74] 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 JO2kHYKfHkWW for ; Sun, 4 Aug 2013 14:24:58 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C175521F9FF2 for ; Sun, 4 Aug 2013 14:24:58 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OWTLIKIQ9S0018WR@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 4 Aug 2013 14:19:52 -0700 (PDT) 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 <01OWSMNAGGN400004R@mauve.mrochek.com>; Sun, 4 Aug 2013 14:19:47 -0700 (PDT) Message-id: <01OWTLIHMZWM00004R@mauve.mrochek.com> Date: Sun, 04 Aug 2013 14:13:18 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 02 Aug 2013 07:34:29 -0700" References: To: Kurt Andersen DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1375651191; bh=eX/Iq1BsQjJkAXdTSNLCibcYp4whIZdTn1wRAJdy7uA=; h=MIME-version:Content-type:Cc:Message-id:Date:From:Subject: In-reply-to:References:To; b=lq/+pMHtBOuAJfPqSYviDjevAXpFrAGKkDyk1OB7buxr/TckncqdgmM3WOsYq4jvA oAUjyVYrj3JevdHWWch8/0mdgEymOVYGq8/ZK9DjL+faPB4YEYdsLvpafsCmkIEV3r 9BUM+dPD7eOu2H63p8IC8FQCBFyb8wBQN/sOcFaw= Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Consensus to change time field in draft-wmills-rrvs-header-field-00? 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, 04 Aug 2013 21:25:02 -0000 I strongly object to the change. DKIM is one thing; signature verification requires unambiguous inputs and interpretation of the field requires DKIM software in any case. The situation here is different - the input requirements are far less strict, and readability of the field is going to be important when problems arise - and rest assure they are going to. If RFC 5322 format dates are really a problem - and I don't think they are - then that's what RFC 3339 is for. Ned > I'd like to propose changing the time field in the > draft-wmills-rrvs-header from [MAIL]'s human-oriented text string to > epoch seconds (as used in the DKIM headers [RFC6376 et al]). Such a > usage would be more in keeping with the automated nature of the > messages that are anticipated to make the most use of this header. > Quoting from RFC6376: > The format is the number of seconds > since 00:00:00 on January 1, 1970 in the UTC time zone. The value > is expressed as an unsigned integer in decimal ASCII. This value > is not constrained to fit into a 31- or 32-bit integer. > Please reply if in favor. > Thanks, > Kurt Andersen > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From johnl@iecc.com Sun Aug 4 15:46: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 C13F621E80AC for ; Sun, 4 Aug 2013 15:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.03 X-Spam-Level: X-Spam-Status: No, score=-106.03 tagged_above=-999 required=5 tests=[AWL=-3.431, 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 PyS8RL1N8IfX for ; Sun, 4 Aug 2013 15:46:43 -0700 (PDT) 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 59B1711E80F5 for ; Sun, 4 Aug 2013 15:46:42 -0700 (PDT) Received: (qmail 83263 invoked from network); 4 Aug 2013 22:46:42 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 4 Aug 2013 22:46:42 -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=51fed9d2.xn--btvx9d.k1308; i=johnl@user.iecc.com; bh=MWs8R+TbOpGnon+YJEDJLIKysZXFjoGspNJu+76hGUo=; b=R4nTvDwPViuqgZ+6fw1LJIV5mAnr5kJ7qOOcFKpawv9lFJy/yAqCxCKSwIJVevWyslg5TsnwpJjkUQPShAl8cg0xsdP2oX07sM7VR+PBk81gciNK2QkdD9qxhIoS0Rc9TWZISeqTVutsJSpVParIY0PyIDkg6PAXf6SlE8p5j6FWg+vyodooALnTz+0Sv38OBdIhKA3aWGfMZZxYqxblhLVw/HWDLF5ecCB8fHdtTrE/VFjsQo4BPD7aZZ2XCry9 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=51fed9d2.xn--btvx9d.k1308; olt=johnl@user.iecc.com; bh=MWs8R+TbOpGnon+YJEDJLIKysZXFjoGspNJu+76hGUo=; b=RazRRn6npJK6rqU210KI0lBrp+6xe4khLrbc4OKy18CdpKib2dV9gtDuWdpCVhrnA0+Wd2/q5ywIIZjcAPE1JtzeECDCt/ZCLat6bBMB2DvemGGq+1KqQPUn0gwzeNp2bgRyrY6QeeU02N/aZiS4XYrDu4/Bg6Qv7dsCFB2cXakmSFsPeBPWCOe6mkAzDeeKJ+LrwbpY4cWXKKwuqfvRAlfkFsBZ7Kgtwt2NMaq9EG5xOQ4/kHIoVyfj38bwNGbx Date: 4 Aug 2013 22:46:19 -0000 Message-ID: <20130804224619.4689.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <01OWTLIHMZWM00004R@mauve.mrochek.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: ned.freed@mrochek.com Subject: Re: [apps-discuss] Consensus to change time field in draft-wmills-rrvs-header-field-00? 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, 04 Aug 2013 22:46:47 -0000 In article <01OWTLIHMZWM00004R@mauve.mrochek.com> you write: >I strongly object to the change. DKIM is one thing; signature verification >requires unambiguous inputs and interpretation of the field requires DKIM >software in any case. I'm with Ned. It's the same format as a Date: header, so if you can't parse that, you can't handle the rest of the message. Date parsing libraries are cheap and plentiful. R's, John From sm@elandsys.com Sun Aug 4 16:30: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 9783B21F9B5C; Sun, 4 Aug 2013 16:30:22 -0700 (PDT) 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.032, 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 f-PaoarQ0iZp; Sun, 4 Aug 2013 16:30:21 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FF911E80FF; Sun, 4 Aug 2013 16:30:19 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.130.143]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r74NU3Do007707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Aug 2013 16:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1375659016; bh=j+QnkPandXnA4FQa0AMzGkuj8iwl9ABWi7aMScyDyoo=; h=Date:To:From:Subject:Cc; b=kR0mzylkOY9CjXHyLJCj+i1m7HFFqliKo4d9oWcfEVyY0Ib+xUiVpxkL02duvxUC+ OC2giRzX2NAPfqmRNkuH0zBNQjkkXYF8DS5UHnE3/+IALo4UPgvFYDH8GIy3vLgYzu kcTUOFbGSVStiW1RoMZc+8CDn9gy5UhmbuwchuBI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1375659016; i=@elandsys.com; bh=j+QnkPandXnA4FQa0AMzGkuj8iwl9ABWi7aMScyDyoo=; h=Date:To:From:Subject:Cc; b=bSUHCYWUdCkEKrg4bWF4r9yyhoRy991o79tCEQuedetXEKXJijQWJn1JshoM5kJPQ JVKVW4M2ojQbPFdK5T1QWUT2D/FswOxBPZM7LwbLBAE0r6WiGXNP1YYoINd+pM1nZI eSUlzNeLDs6tlgG6y86+E7XWRkzgQhk+I77ABfTc= Message-Id: <6.2.5.6.2.20130804152246.0c672f50@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 04 Aug 2013 16:25:46 -0700 To: apps-discuss@ietf.org, iesg@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-petithuguenin-behave-turn-uris.all@tools.ietf.org Subject: [apps-discuss] APPSDIR review of draft-petithuguenin-behave-turn-uris-05 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, 04 Aug 2013 23:30:22 -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-petithuguenin-behave-turn-uris-05 Title: Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers Reviewer: S. Moonesamy Review Date: August 4, 2013 IETF Last Call Date: July 19, 2013 Summary: This document is nearly ready for publication as a Proposed Standard. This document defines two URI schemes to provision the TURN Resolution Mechanism. Major issues: None Minor issues: The Terminology Section is different from the usual RFC 2119 boilerplate. I am listing this as a minor issue for the attention of the Apps ADs. This document restates the ABNF from RFC 3986. I suggest including it by reference. Please note that I read Appendix B. Nits: This review does not include editorial nits. Regards, S. Moonesamy From jhildebr@cisco.com Mon Aug 5 10:43: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 E431821F9F4F; Mon, 5 Aug 2013 10:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.66 X-Spam-Level: X-Spam-Status: No, score=-10.66 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Zt7QNd+k30q3; Mon, 5 Aug 2013 10:43:35 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id EBE4A21F9F21; Mon, 5 Aug 2013 10:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25628; q=dns/txt; s=iport; t=1375724611; x=1376934211; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=t0pNcc++f7DtoC2yZhB+4YA1X8NBjMYZguO3w53V21k=; b=QfQHTlpDj/mIoKVjVwruirZ1LupUc0zm1XZEEAvbX4AazdGdsNC4+mM6 jSzakb67Nr3JrrfqC1FQbNlzgI0FeqVIcKxl1aVayZut62Ps2ZKB1AIzp Oyz/Vaew/EJBFxNLgPmlsg7CP2TIFRbwL3lSMp0YRUf+d/TvIY/mGSw4m U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAA7j/1GtJXHB/2dsb2JhbABbgwY1UL51gSEWdIIkAQEBAwEODA0TKwIHCwUNAQgiFDERJQIEAQ0FCBaHYAMJBgysQA2IWgSNJ4EkBQsBBoEGMQeDGXQDlAmBbo4RhSeDF4FoAR8i X-IronPort-AV: E=Sophos;i="4.89,819,1367971200"; d="scan'208";a="243695153" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 05 Aug 2013 17:43:30 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r75HhUZw026822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Aug 2013 17:43:30 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Mon, 5 Aug 2013 12:43:29 -0500 From: "Joe Hildebrand (jhildebr)" To: Martin Thomson , "draft-bormann-cbor-04.all@tools.ietf.org" , IETF Apps Discuss Thread-Topic: [apps-discuss] Gen-ART review of draft-bormann-cbor-04 Thread-Index: AQHOjPNCXWeGtSFAj0iRwScRzl7yuJmG2+2A Date: Mon, 5 Aug 2013 17:43:29 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.21.116.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "gen-art@ietf.org" Subject: Re: [apps-discuss] Gen-ART review of draft-bormann-cbor-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: Mon, 05 Aug 2013 17:43:41 -0000 Sorry, my response is also correspondingly long. There are some original comments at the end that are not just responses to Martin. On 7/30/13 9:05 AM, "Martin Thomson" wrote: >I'm glad that I held this review until Paul's appsarea presentation. >This made it very clear to me that the types of concerns I have are >considered basically irrelevant by the authors because they aren't >interested in changing the design goals. I don't find the specific >design goals to be interesting and am of the opinion that the goals >are significant as a matter of general application. I hope that is >clear from my review. I don't think you made it clear which of the design goals you thought weren't interesting. I'll give my take on each of them here: > 1. The representation must be able to unambiguously encode most > common data formats used in Internet standards. Seems reasonable. For example, dates *do* come up quite often (e.g. MIME headers). > 2. The code for an encoder or parser must be able to be compact in > order to support systems with very limited memory and processor > power and instruction sets. Seems reasonable, particularly if you're targeting embedded devices and sensors. One of the other corollaries they ought to mention here is that devices that have small implementations should be able to receive a subset of the value of the format, implementing only the parts that they need to and skipping everything they don't understand. > 3. Data must be able to be parsed without a schema description. I'd put this first. It's an absolute must-have for future extensibility. > 4. The serialization must be reasonably compact, but data > compactness is secondary to code compactness for the encoder and > parser. This is one of the things that people don't like about XML, which leads them to come up with aggressively complicated approaches like EXI. I might argue that it's a little more important than code compactness for my use cases, but I think CBOR currently strikes an adequate balance. > 5. The format must be applicable to both constrained nodes and high- > volume applications. In IoT applications, both will be true at the same time, so I like this requirement. Low CPU usually means less battery usage anyway. > 6. The format must support all JSON data types for conversion to and > from JSON. Why not? There are some bits that don't convert quite cleanly enough to JSON, but it's pretty close. > 7. The format must be extensible, with the extended data being able > to be parsed by earlier parsers. This is interesting, and I would be willing to give up several kinds of extensibility to get more simplicity. Perhaps this is your greatest issue, and I don't think you are necessarily wrong. >I have reviewed the mailing list feedback, and it's not clear to me >that there is consensus to publish this. It might be that the dissent >that I have observed is not significant in Barry's learned judgment, >or that this is merely dissent on design goals and therefore >irrelevant. The fact that this work isn't a product of a working >group still concerns me. I'm actually interested in why this is >AD-sponsored rather than a working group product. I think this draft is interesting, and might benefit from a short-lived working group to ensure that enough people have reviewed it. As well, I think there might need to be a BCP70-style document that explores how to design protocols using CBOR, after we've got some implementation experience. I do think that rather a lot of the dissent from the list was heard and incorporated, including streaming, which I personally think is an over-complication, but others really seemed to want. >Major issues: >My major concerns with this document might be viewed as disagreements >with particular design choices. And, I consider it likely that the >authors will conclude that the document is still worth publishing as >is, or perhaps with some minor changes. In the end, I have no issue >with that, but expect that the end result will be that the resulting >RFC is ignored. I don't agree that CBOR will be ignored if published in the current form, but I do believe it could use a little more review and polish. >What would cause this to be tragic, is if publication of this were >used to prevent other work in this area from subsequently being >published. (For those drawing less-than-charitable inferences from >this, I have no desire to throw my hat into this particular ring, >except perhaps in jest [1].) There will be other formats, even if this is published. >This design is far too complex and large. Regardless of how >well-considered it might be, or how well this meets the stated design >goals, I can't see anything but failure in this document's future. >JSON succeeds largely because it doesn't attempt to address so many >needs at once, but I could even make a case for why JSON contains too >many features. I've implemented it twice now, using two different approaches. The second time, I separated the lexing and generation using a SAX-style eventing model. There were a total of eight events fired: - value=20 - array start/stop - map start/stop - stream start/stop - end That seems roughly minimal for data shaped similarly to JSON (except for streams), and significantly less complex than the equivalent SAX2 set for XML. >In comparison with JSON, this document does one major thing wrong: it >has more options than JSON in several dimensions. There are more >types, there are several more dimensions for extensibility than JSON: >types extensions, values extensions (values of 28-30 in the lower bits >of the type byte), plus the ability to apply arbitrary tags to any >value. I believe all of these to be major problems that will cause >them to be ignored, poorly implemented, and therefore useless. I agree that not everyone will implement all of the semantic tags, but the fact that you can continue parsing even if you receive a tag you don't implement is an interesting and useful property. I do agree that the extensibility of the patterns 28-30 is scary; those came about when streaming was added. >In part, this complexity produces implementations that are far more >complex than they might need to be, unless additional standardization >is undertaken. That idea is something I'm uncomfortable with. I didn't find either of those properties to be challenging to code around. I error on bit patterns for 28-30, capture but ignore tags in the eventing layer, and in the generation layer am able to implement new tags with code that looks like: tag_DATE_STRING: (val)-> new Date(val) Which doesn't seem like an onerous burden for the upside of being able to round-trip all of the built-in JavaScript types. I guess I disagree with your characterization of overcomplexity, based on implementation experience. >Design issue: extensibility: >This document avoids discussion of issues regarding schema-less >document formats that I believe to be fundamental. These issues are >critical when considering the creation of a new interchange format. >By choosing this specific design it makes a number of trade-offs that >in my opinion are ill-chosen. This may be in part because the >document is unclear about how applications intend to use the documents >it describes. > >You may conclude after reading this review that this is simply because >the document does not explain the rationale for selecting the approach >it takes. I hope that isn't the conclusion you reach, but appreciate >the reasons why you might do so. > >I believe the fundamental problem to be one that arises from a >misunderstanding about what it means to have no schema. Aside from >formats that require detailed contextual knowledge to interpret, there >are several steps toward the impossible, platonic ideal of a perfectly >self-describing format. It's impossible because ultimately the entity >that consumes the data is required at some level to understand the >semantics that are being conveyed. In practice, no generic format can >effectively self-describe to the level of semantics. > >This draft describes a format that is more capable at self-description >than JSON. I believe that to not just be unnecessary, but >counterproductive. At best, it might provide implementations with a >way to avoid an occasional extra line of code for type conversion. As an example, the binary string type would be quite useful for JOSE-style documents that need to reproduce a set of octets exactly. Today, Base64 is required for that in JSON, which is causing the JOSE working group to limit the size (and therefore the ease of understanding) of value names, as multiple layers of Base64 can expand their output size past the external limits placed on applications by browsers. Secondly, numeric types in JSON are pretty woefully underspecified, and cannot be fixed. Transmitting both integers and floats with precise understanding of how they will be received is often quite useful. I don't see either of these as simple type conversion issues. >Extensibility as it relates to types: >The use of extensive typing in CBOR implies an assumption of a major >role for generic processing. XML schema and XQuery demonstrate that >this desire is not new, but they also demonstrate the folly of >pursuing those goals. XML schema keeps these bits in a (quite complex) separate stream, which requires significant extra processing to add type information into the parse stream. I agree that we've learned that this approach doesn't work well. I don't think that either XSD or XQuery prove anything about putting some type information into the data stream itself. >JSON relies on a single mechanism for extensibility. JSON maps that >contain unknown or unsupported keys are (usually) ignored. This >allows new values to be added to documents without destroying the >ability of an old processor to extract the values that it supports. >The limited type information JSON carries leaks out, but it's unclear >what value this has to a generic processor. All of the generic uses >I've seen merely carry that type information, no specific use is made >of the knowledge it provides. I don't see how this is relevant. Most CBOR extensibility for a given protocol will follow this model exactly. >ASN.1 extensibility, as encoded in PER, leads to no type information >leaking. Unsupported extensions are skipped based on a length field. I'd say that CBOR has a slight advantage here, because you can still get some interesting information out of many tag types, even if you don't support that tag type. That allows a non-extensible parsing system to be used, if desired. >(As an aside, PER is omitted from the analysis in the appendix, which >I note from the mailing lists is due to its dependency on schema. >Interestingly, I believe it to be possible - though not trivial - to >create an ASN.1 description with all the properties described in CBOR >that would have roughly equivalent, if not fully equivalent, >properties to CBOR when serialized.) Let's add PER to the analysis. I don't think it will have the properties desired, since the decoder has to have access to the same schema the sender had. I agree that it might be possible to create CBOR Encoding Rules or the moral equivalent, but I'm not sure I agree that it would be worth the effort. >By defining an extensibility scheme for types, CBOR effectively >acknowledges that a generic processor doesn't need type information >(just delineation information), but it then creates an extensive type >system. That seems wasteful. In a given system using CBOR, the protocol designers will decide which types to use. All of the tooling in that ecosystem will parse and encode the selected types. Think of the extensibility here being more for generating lots of different protocols on top of CBOR, not lots of different types in one protocol. >Design issue: types: >The addition of the ability to carry uninterpreted binary data is a >valuable and important feature. If that was all this document did, >then that might have been enough. But instead it adds numerous >different types. I agree that binary is the most important. However, unambiguous, unescaped, UTF8-only text is also a big win over JSON. Precise floats are a distant third for me, but seem to be the most important for folks that do remote sensors. >I can understand why multiple integer encoding sizes are desirable, >and maybe even floating point representations, but this describes >bignums in both base 2 and 10, I agree that the bignums are overkill. I implemented them the second time, but I made sure they were slow. :) Seriously, I don't see using these in any applications, unless the security folks decide they are a good fit for an RSA modulus. >embedded CBOR documents in three forms, >URIs, base64 encoded strings, regexes, MIME bodies, date and times in >two different forms, and potentially more. I think I may be responsible for having suggested URIs and regexes, and would fully support removing them from the base draft, along with all of the baseX and the (underspecified) MIME stuff. Please keep the dates. >I also challenge the assertion made where the code required for >parsing a data type produces larger code sizes if performed outside of >a common shared library. That's arguably provably true, but last time >I checked a few extra procedure calls (or equivalent) weren't the >issue for code size. Sheer number of options on the other hand might >be. That assertion is also unconvincing to me. However, I'd really like my docs to round-trip, and dates are a big hole in that. I personally want precisely one date type (rather than two), and don't care which one is selected. Javascript floating point milliseconds before/after the epoch seems like a reasonable starting point, for example. >Half-precision floating point numbers are a good example of excessive >exuberance. They are not available in many languages for good reason: >they aren't good for much. They're also relatively new. >They actually tend to cause errors in >software in the same way that threading libraries do: it's not that >it's hard to use them, it's that it's harder than people think. And >requiring that implementations parse these creates unnecessary >complexity. =20 I know that it took me an hour or two with the IEEE754 docs to implement them in JavaScript, and that code passes a ton of unit tests, including subnormals, +/- infinity, and NaNs. That said, I don't need halfs for my use cases, but if sensor folks feel strongly about them, I'm willing to keep that code in place. It's *really* nice to be able to encode NaN and +/- Infinity as separate from null, which JSON does not allow. >I do not believe that for the very small subset of cases >where half precision is actually useful, the cost of transmitting the >extra 2 bytes of a single-precision number is not going to be a >burden. However, the cost of carrying the code required to decode >them is not as trivial as this makes out. The fact that this requires >an appendix would seem to indicate that this is special enough that >inclusion should have been very carefully considered. To be honest, >if it were my choice, I would have excluded single-precision floating >point numbers as well, they too create more trouble than they are >worth. I'd be fine with that for my use cases, too, but realize there are other use cases where people care about both half- and single-precision, and am willing to write a couple of extra lines of code to get them onboard. >Design issue: optionality >CBOR embraces the idea that support for types is optional. Given the >extensive nature of the type system, it's almost certain that >implementations will choose to avoid implementation of some subset of >the types. The document makes no statements about what types are >mandatory for implementations, so I'm not sure how it is possible to >provide interoperable implementations. I think it should say that *none* of the types is mandatory, which I think is implied by the text in section 2.4. >If published in its current form, I predict that only a small subset >of types will be implemented and become interoperable. I'd say let's agree on what those types are, and move all of the others to separate drafts. My list: - Date (one type) - CBOR (sometimes parsed, other times kept intact for processing as a byte stream) >Design issue: tagging >The tagging feature has a wonderful property: the ability to create >emergency complexity. Given that a tag itself can be arbitrarily >complex, I'm almost certain that this is a feature you do not want. I'm not sure I understand fully what your issue is. Protocol designers can abuse any format, and when they do, implementors curse them down the ages. Don't do that. >Minor issues: >Design issue: negative numbers >Obviously, the authors will be well-prepared for arguments that >describe as silly the separation of integer types into distinct >positive and negative types. But it's true, this is a strange choice, >and a very strange design. I think it came from some of the other things in this space (e.g. zigzag-encoding). I think another option would be to have both signed and unsigned types. This choice didn't bother me too much in implementation, except when it was repeated in bigints. >The fact that this format is capable of describing 64-bit negative >numbers creates a problem for implementations that I'm surprised >hasn't been raised already. In most languages I use, there is no >native type that is capable of carrying the most negative value that >can be expressed in this format. -2^64 is twice as large as a 64-bit >twos-complement integer can store. Yes, that should be mentioned in the doc, probably with a MUST NOT. >It almost looks as though CBOR is defining a 65-bit, 33-bit or 17-bit >twos complement integer format, with the most significant bit isolated >from the others, except that the negative expression doesn't even have >the good sense to be properly sortable. Given that and the fact that >bignums are also defined, I find this choice to be baffling. This is a quite valid concern. Let's get it fixed. >Document issue: Canonicalization >Please remove Section 3.6. c14n is hard, and this format actually >makes it impossible to standardize a c14n scheme, that says a lot >about it. In comparison, JSON is almost trivial to canonicalize. Agree with removing section 3.6, and moving to another doc if really desired. STRONGLY disagree that JSON is trivial to canonicalize. The Unicode issues notwithstanding (escaping, etc), the numeric format is a mess to get into canonical form. >If the intent of this section is to describe some of the possible >gotchas, such as those described in the last paragraph, then that >would be good. Changing the focus to "Canonicalization >Considerations" might help. > >I believe that there are several issues that this section would still >need to consider. For instance, the use of the types that contain >additional JSON encoding hints carry additional semantics that might >not be significant to the application protocol. > >Extension based on minor values 28-30 (the "additional information" >space): >...is impossible as defined. Section 5.1 seems to imply otherwise. >I'm not sure how that would ever happen without breaking existing >parsers. Section 5.2 actually makes this worse by making a >wishy-washy commitment to size for 28 and 29, but no commitment at all >for 30. +1. I'd prefer we remove streaming and tighten the additional information bits back up to all being used as in previous versions of the draft. >Nits: >Section 3.7 uses the terms "well-formed" and "valid" in a sense that I >believe to be consistent with their use in XML and XML Schema. I >found the definition of "valid" to be a little difficult to parse; >specifically, it's not clear whether invalid is the logical inverse of >valid. Agree that language needs to be massaged. >Appendix B/Table 4 has a TBD on it. Can this be checked? Sure. >Table 4 keeps getting forward references, but it's hidden in an >appendix. I found that frustrating as a reader because the forward >references imply that there is something important there. And that >implication was completely right, this needs promotion. I know why >it's hidden, but that reason just supports my earlier theses. I think it should not be referred to earlier. It's an implementation choice, and not one that I (for example) made. Thinking about that table made it more difficult for me to get started. >Section 5.1 says "An IANA registry is appropriate here.". Why not >reference Section 7.1? Yes, that needs to be fixed. >[1] https://github.com/martinthomson/aweson Add binary, and remove the string quoting requirements, please. :) Other things that ought to be discussed: I would like to see another design goal: "May be implemented in modern web browsers". That should be possible with the new binary types. I still don't see the need for non-string map keys. JSON mapping would be easier without them, as would uniqueness checking. If they are to be retained, they should have some motivation in the spec, describing how and why they might be used. I wish I could think of another good simple value that we might register one day. The only one I've come up with is "no-op", which I might use in a streaming application as a trivial keep-alive or a marker between records to ensure parser state sync. I wouldn't classify that as "good" however. Nested tags ought to be forbidden until we come up with a strong use case for them. I could use some implementation guidance on how to generate the most compact floating-point type for a given number, assuming we keep all of the floating-point types. I don't like 2.4.4.2 "Expected Later Encoding for CBOR to JSON Converters". Having a sender care about the encoding of a second format at the same time seems unnecessarily complex. I'd like to see this section and the corresponding tags moved to another spec, or just removed. Similar for tags 33 and 34. Just send the raw bytes as a byte string; there's no need to actually base64 encode. Section 3.2.3, we should call out the heresy of including UTF-16 surrogates encoded as UTF-8 for those that can't read the UTF-8 spec. Overall in section 3.2, "should probably issue an error but might take some other action" seems like it will cause some interop surprises in practice. Section 3.3, "all number representations are equivalent" is unclear, even with the clarifying phrase afterward. If section 3.6 stays, the numerics need more work. +/- Infinity should be treated like NaN. "if the result is the same value" would benefit from some more clarity. The tags section is also somewhat unclear. Section 4.2, what about numbers with uninteresting fractional parts, like 1.0? What about numbers in exponential format without fractional parts, like 1e10? I would recommend against even suggest encoding in place. It's likely to cause a security issue for the reason mentioned. Section 6, including the diagnostic notation is a little strange. I would at least like "it is not meant to be parsed" to be strengthened to "MUST NOT be parsed". Section 7.1, simple values 0..15 can never be used with this construction. If that's intentional, then give a good reason. Section 7.2, do we have language we can use about how to reclaim first-come-first-serve tags that aren't being used anymore? e.g. the web page is down and the requestor may be dead. In section 7.3, yes, we should make "application/mmmmm+cbor" valid. In section 8, perhaps mention a stack attack like: 0x818181818181818181... I implemented depth counting with a maximum as an approach to avoid this. There are likely to be lots of other security concerns. I have checked all of the examples in Appendix A. I would have expected 2(h'010000000000000000') | 0xc249010000000000000000 Not 18446744073709551616, since in the diagnostic, I don't necessarily support bignums. Same with 0xc349010000000000000000. For numbers, section 9.8.1 of ECMA-262 (JSON.stringify) is relevant. So: 5.960464477539063e-8 | 0xf90001 (not e-08) 0.00006103515625 | 0xf90400 (not e-05) In Appendix B, there are holes in the jump table. If you're going to have a table, call out the invalid values, such as 0x1c-0x1f. In Appendix C, the use of the variable "breakable" is unclear, and it's not obvious how you'll get to the "no enclosing indefinite" case. In Appendix D, shouldn't the input be unsigned or an array of bytes? Appendix E.1, aren't there some cases of DER where you need the schema to parse? Add PER. Appendix E, we should mention Smile, since the first two octets are so cute. Overall, I think this doc shows a lot of promise, and I'm looking forward to having something on standards track that has these properties. --=20 Joe Hildebrand From zach@sensinode.com Mon Aug 5 10:51: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 A1CA421F8F3C; Mon, 5 Aug 2013 10:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmZXlsUo5DcG; Mon, 5 Aug 2013 10:51:06 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 2473821F9CC5; Mon, 5 Aug 2013 10:50:55 -0700 (PDT) Received: from [10.37.109.3] ([77.95.242.69]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id r75HomTd026733 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 5 Aug 2013 20:50:49 +0300 X-Authenticated-User: sensinodecom Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Zach Shelby In-Reply-To: Date: Mon, 5 Aug 2013 20:50:49 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <607B7E5D-EEF3-4D53-A5C1-5484795B64C7@sensinode.com> References: To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.1503) Cc: "draft-bormann-cbor-04.all@tools.ietf.org" , "gen-art@ietf.org" , IETF Apps Discuss Subject: Re: [apps-discuss] Gen-ART review of draft-bormann-cbor-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: Mon, 05 Aug 2013 17:51:11 -0000 On Aug 5, 2013, at 8:43 PM, "Joe Hildebrand (jhildebr)" = wrote: >> 7. The format must be extensible, with the extended data being able >> to be parsed by earlier parsers. >=20 >=20 > This is interesting, and I would be willing to give up several kinds = of > extensibility to get more simplicity. Perhaps this is your greatest > issue, and I don't think you are necessarily wrong. As an IoT end-user of this kind of format, I would have no issues with = giving up quite a bit of extensibility for more simplicity. If that is = the major push-back, then I think we should look at reassessing the need = for e.g. tags.=20 Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com @SensinodeIoT Mobile: +358 40 7796297 Twitter: @zach_shelby LinkedIn: http://fi.linkedin.com/in/zachshelby 6LoWPAN Book: http://6lowpan.net From tbray@textuality.com Mon Aug 5 10:51: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 0E0BC21F8F3C for ; Mon, 5 Aug 2013 10:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.735 X-Spam-Level: X-Spam-Status: No, score=-2.735 tagged_above=-999 required=5 tests=[AWL=0.242, 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 4wbNFv7+UCMg for ; Mon, 5 Aug 2013 10:51:22 -0700 (PDT) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) by ietfa.amsl.com (Postfix) with ESMTP id B20E621F9D7D for ; Mon, 5 Aug 2013 10:51:14 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id d10so3436757vea.19 for ; Mon, 05 Aug 2013 10:51:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=7RVUOPOBougtHZVVSi1ntw7Zb9mIW72rHzJvdigzBY4=; b=DLj7iZ8k1wgrfwGdmY/yPTjlXRzIx26FqhZ+6+O7cj3bDTVRHjQKfn7uREMMx1TN+l CgmHh6kydtYgJnhsGW7/nQts1UmYqdLddyuGzw8yVnsNgQlhqET62CCR/vTmDtuAFrzN ZgpKsw6oJFPyvlTIb16/Qgh1o9559rQiRfROXGk9MHL6I2tYFY3icfI+eroLAc4MFYvY E5KDETwHeg2Z0wVotzZt/K48bSpq+y/oazY+K4cCb8tATCHi4838AqmafqxtIQHEy+Jm fqPfNtBCcETbI0n2QpviZLfaOgYCUfZK40QX7QNJ81A7T0Yhjksm1W7qBLHIw65c6VUo dIpQ== MIME-Version: 1.0 X-Received: by 10.58.85.161 with SMTP id i1mr6015300vez.97.1375725074035; Mon, 05 Aug 2013 10:51:14 -0700 (PDT) Received: by 10.220.212.202 with HTTP; Mon, 5 Aug 2013 10:51:13 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: References: Date: Mon, 5 Aug 2013 10:51:13 -0700 Message-ID: From: Tim Bray To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=047d7b6da6ac58c4a504e336f480 X-Gm-Message-State: ALoCoQnzfHBbfW3ffUYLsAvyxUhNz0MuHisHU8eGffK61YJAmEMOvRnJ0U4mhcaXlTDPLVge2TOF Cc: "draft-bormann-cbor-04.all@tools.ietf.org" , "gen-art@ietf.org" , IETF Apps Discuss Subject: Re: [apps-discuss] Gen-ART review of draft-bormann-cbor-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: Mon, 05 Aug 2013 17:51:36 -0000 --047d7b6da6ac58c4a504e336f480 Content-Type: text/plain; charset=UTF-8 I like the design of CBOR but my big question is how much code-size and memory-size and performance it actually buys you. My experience is that the performance of software that parses XML & JSON is often dominated by memory allocation as it builds the structures to hold the parsed data. Do we have any data? -T On Mon, Aug 5, 2013 at 10:43 AM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > Sorry, my response is also correspondingly long. There are some original > comments at the end that are not just responses to Martin. > > On 7/30/13 9:05 AM, "Martin Thomson" wrote: > > >I'm glad that I held this review until Paul's appsarea presentation. > >This made it very clear to me that the types of concerns I have are > >considered basically irrelevant by the authors because they aren't > >interested in changing the design goals. I don't find the specific > >design goals to be interesting and am of the opinion that the goals > >are significant as a matter of general application. I hope that is > >clear from my review. > > I don't think you made it clear which of the design goals you thought > weren't interesting. I'll give my take on each of them here: > > > 1. The representation must be able to unambiguously encode most > > common data formats used in Internet standards. > > > Seems reasonable. For example, dates *do* come up quite often (e.g. MIME > headers). > > > 2. The code for an encoder or parser must be able to be compact in > > order to support systems with very limited memory and processor > > power and instruction sets. > > > Seems reasonable, particularly if you're targeting embedded devices and > sensors. One of the other corollaries they ought to mention here is that > devices that have small implementations should be able to receive a subset > of the value of the format, implementing only the parts that they need to > and skipping everything they don't understand. > > > 3. Data must be able to be parsed without a schema description. > > > I'd put this first. It's an absolute must-have for future extensibility. > > > > 4. The serialization must be reasonably compact, but data > > compactness is secondary to code compactness for the encoder and > > parser. > > > This is one of the things that people don't like about XML, which leads > them to come up with aggressively complicated approaches like EXI. I > might argue that it's a little more important than code compactness for my > use cases, but I think CBOR currently strikes an adequate balance. > > > 5. The format must be applicable to both constrained nodes and high- > > volume applications. > > In IoT applications, both will be true at the same time, so I like this > requirement. Low CPU usually means less battery usage anyway. > > > > 6. The format must support all JSON data types for conversion to and > > from JSON. > > > Why not? There are some bits that don't convert quite cleanly enough to > JSON, but it's pretty close. > > > 7. The format must be extensible, with the extended data being able > > to be parsed by earlier parsers. > > > This is interesting, and I would be willing to give up several kinds of > extensibility to get more simplicity. Perhaps this is your greatest > issue, and I don't think you are necessarily wrong. > > > > >I have reviewed the mailing list feedback, and it's not clear to me > >that there is consensus to publish this. It might be that the dissent > >that I have observed is not significant in Barry's learned judgment, > >or that this is merely dissent on design goals and therefore > >irrelevant. The fact that this work isn't a product of a working > >group still concerns me. I'm actually interested in why this is > >AD-sponsored rather than a working group product. > > I think this draft is interesting, and might benefit from a short-lived > working group to ensure that enough people have reviewed it. As well, I > think there might need to be a BCP70-style document that explores how to > design protocols using CBOR, after we've got some implementation > experience. > > I do think that rather a lot of the dissent from the list was heard and > incorporated, including streaming, which I personally think is an > over-complication, but others really seemed to want. > > >Major issues: > >My major concerns with this document might be viewed as disagreements > >with particular design choices. And, I consider it likely that the > >authors will conclude that the document is still worth publishing as > >is, or perhaps with some minor changes. In the end, I have no issue > >with that, but expect that the end result will be that the resulting > >RFC is ignored. > > I don't agree that CBOR will be ignored if published in the current form, > but I do believe it could use a little more review and polish. > > >What would cause this to be tragic, is if publication of this were > >used to prevent other work in this area from subsequently being > >published. (For those drawing less-than-charitable inferences from > >this, I have no desire to throw my hat into this particular ring, > >except perhaps in jest [1].) > > There will be other formats, even if this is published. > > > >This design is far too complex and large. Regardless of how > >well-considered it might be, or how well this meets the stated design > >goals, I can't see anything but failure in this document's future. > >JSON succeeds largely because it doesn't attempt to address so many > >needs at once, but I could even make a case for why JSON contains too > >many features. > > I've implemented it twice now, using two different approaches. The second > time, I separated the lexing and generation using a SAX-style eventing > model. There were a total of eight events fired: > > - value > - array start/stop > - map start/stop > - stream start/stop > - end > > That seems roughly minimal for data shaped similarly to JSON (except for > streams), and significantly less complex than the equivalent SAX2 set for > XML. > > >In comparison with JSON, this document does one major thing wrong: it > >has more options than JSON in several dimensions. There are more > >types, there are several more dimensions for extensibility than JSON: > >types extensions, values extensions (values of 28-30 in the lower bits > >of the type byte), plus the ability to apply arbitrary tags to any > >value. I believe all of these to be major problems that will cause > >them to be ignored, poorly implemented, and therefore useless. > > I agree that not everyone will implement all of the semantic tags, but the > fact that you can continue parsing even if you receive a tag you don't > implement is an interesting and useful property. > > I do agree that the extensibility of the patterns 28-30 is scary; those > came about when streaming was added. > > >In part, this complexity produces implementations that are far more > >complex than they might need to be, unless additional standardization > >is undertaken. That idea is something I'm uncomfortable with. > > I didn't find either of those properties to be challenging to code around. > I error on bit patterns for 28-30, capture but ignore tags in the > eventing layer, and in the generation layer am able to implement new tags > with code that looks like: > > tag_DATE_STRING: (val)-> > new Date(val) > > Which doesn't seem like an onerous burden for the upside of being able to > round-trip all of the built-in JavaScript types. > > > I guess I disagree with your characterization of overcomplexity, based on > implementation experience. > > >Design issue: extensibility: > >This document avoids discussion of issues regarding schema-less > >document formats that I believe to be fundamental. These issues are > >critical when considering the creation of a new interchange format. > >By choosing this specific design it makes a number of trade-offs that > >in my opinion are ill-chosen. This may be in part because the > >document is unclear about how applications intend to use the documents > >it describes. > > > >You may conclude after reading this review that this is simply because > >the document does not explain the rationale for selecting the approach > >it takes. I hope that isn't the conclusion you reach, but appreciate > >the reasons why you might do so. > > > >I believe the fundamental problem to be one that arises from a > >misunderstanding about what it means to have no schema. Aside from > >formats that require detailed contextual knowledge to interpret, there > >are several steps toward the impossible, platonic ideal of a perfectly > >self-describing format. It's impossible because ultimately the entity > >that consumes the data is required at some level to understand the > >semantics that are being conveyed. In practice, no generic format can > >effectively self-describe to the level of semantics. > > > >This draft describes a format that is more capable at self-description > >than JSON. I believe that to not just be unnecessary, but > >counterproductive. At best, it might provide implementations with a > >way to avoid an occasional extra line of code for type conversion. > > As an example, the binary string type would be quite useful for JOSE-style > documents that need to reproduce a set of octets exactly. Today, Base64 > is required for that in JSON, which is causing the JOSE working group to > limit the size (and therefore the ease of understanding) of value names, > as multiple layers of Base64 can expand their output size past the > external limits placed on applications by browsers. > > Secondly, numeric types in JSON are pretty woefully underspecified, and > cannot be fixed. Transmitting both integers and floats with precise > understanding of how they will be received is often quite useful. > > I don't see either of these as simple type conversion issues. > > >Extensibility as it relates to types: > >The use of extensive typing in CBOR implies an assumption of a major > >role for generic processing. XML schema and XQuery demonstrate that > >this desire is not new, but they also demonstrate the folly of > >pursuing those goals. > > XML schema keeps these bits in a (quite complex) separate stream, which > requires significant extra processing to add type information into the > parse stream. I agree that we've learned that this approach doesn't work > well. I don't think that either XSD or XQuery prove anything about > putting some type information into the data stream itself. > > > >JSON relies on a single mechanism for extensibility. JSON maps that > >contain unknown or unsupported keys are (usually) ignored. This > >allows new values to be added to documents without destroying the > >ability of an old processor to extract the values that it supports. > >The limited type information JSON carries leaks out, but it's unclear > >what value this has to a generic processor. All of the generic uses > >I've seen merely carry that type information, no specific use is made > >of the knowledge it provides. > > I don't see how this is relevant. Most CBOR extensibility for a given > protocol will follow this model exactly. > > >ASN.1 extensibility, as encoded in PER, leads to no type information > >leaking. Unsupported extensions are skipped based on a length field. > > I'd say that CBOR has a slight advantage here, because you can still get > some interesting information out of many tag types, even if you don't > support that tag type. That allows a non-extensible parsing system to be > used, if desired. > > >(As an aside, PER is omitted from the analysis in the appendix, which > >I note from the mailing lists is due to its dependency on schema. > >Interestingly, I believe it to be possible - though not trivial - to > >create an ASN.1 description with all the properties described in CBOR > >that would have roughly equivalent, if not fully equivalent, > >properties to CBOR when serialized.) > > Let's add PER to the analysis. I don't think it will have the properties > desired, since the decoder has to have access to the same schema the > sender had. I agree that it might be possible to create CBOR Encoding > Rules or the moral equivalent, but I'm not sure I agree that it would be > worth the effort. > > >By defining an extensibility scheme for types, CBOR effectively > >acknowledges that a generic processor doesn't need type information > >(just delineation information), but it then creates an extensive type > >system. That seems wasteful. > > In a given system using CBOR, the protocol designers will decide which > types to use. All of the tooling in that ecosystem will parse and encode > the selected types. > > Think of the extensibility here being more for generating lots of > different protocols on top of CBOR, not lots of different types in one > protocol. > > >Design issue: types: > >The addition of the ability to carry uninterpreted binary data is a > >valuable and important feature. If that was all this document did, > >then that might have been enough. But instead it adds numerous > >different types. > > I agree that binary is the most important. However, unambiguous, > unescaped, UTF8-only text is also a big win over JSON. Precise floats are > a distant third for me, but seem to be the most important for folks that > do remote sensors. > > >I can understand why multiple integer encoding sizes are desirable, > >and maybe even floating point representations, but this describes > >bignums in both base 2 and 10, > > I agree that the bignums are overkill. I implemented them the second > time, but I made sure they were slow. :) > > Seriously, I don't see using these in any applications, unless the > security folks decide they are a good fit for an RSA modulus. > > >embedded CBOR documents in three forms, > >URIs, base64 encoded strings, regexes, MIME bodies, date and times in > >two different forms, and potentially more. > > I think I may be responsible for having suggested URIs and regexes, and > would fully support removing them from the base draft, along with all of > the baseX and the (underspecified) MIME stuff. > > Please keep the dates. > > >I also challenge the assertion made where the code required for > >parsing a data type produces larger code sizes if performed outside of > >a common shared library. That's arguably provably true, but last time > >I checked a few extra procedure calls (or equivalent) weren't the > >issue for code size. Sheer number of options on the other hand might > >be. > > That assertion is also unconvincing to me. However, I'd really like my > docs to round-trip, and dates are a big hole in that. I personally want > precisely one date type (rather than two), and don't care which one is > selected. Javascript floating point milliseconds before/after the epoch > seems like a reasonable starting point, for example. > > >Half-precision floating point numbers are a good example of excessive > >exuberance. They are not available in many languages for good reason: > >they aren't good for much. > > They're also relatively new. > > >They actually tend to cause errors in > >software in the same way that threading libraries do: it's not that > >it's hard to use them, it's that it's harder than people think. And > >requiring that implementations parse these creates unnecessary > >complexity. > > I know that it took me an hour or two with the IEEE754 docs to implement > them in JavaScript, and that code passes a ton of unit tests, including > subnormals, +/- infinity, and NaNs. That said, I don't need halfs for my > use cases, but if sensor folks feel strongly about them, I'm willing to > keep that code in place. > > It's *really* nice to be able to encode NaN and +/- Infinity as separate > from null, which JSON does not allow. > > >I do not believe that for the very small subset of cases > >where half precision is actually useful, the cost of transmitting the > >extra 2 bytes of a single-precision number is not going to be a > >burden. However, the cost of carrying the code required to decode > >them is not as trivial as this makes out. The fact that this requires > >an appendix would seem to indicate that this is special enough that > >inclusion should have been very carefully considered. To be honest, > >if it were my choice, I would have excluded single-precision floating > >point numbers as well, they too create more trouble than they are > >worth. > > I'd be fine with that for my use cases, too, but realize there are other > use cases where people care about both half- and single-precision, and am > willing to write a couple of extra lines of code to get them onboard. > > >Design issue: optionality > >CBOR embraces the idea that support for types is optional. Given the > >extensive nature of the type system, it's almost certain that > >implementations will choose to avoid implementation of some subset of > >the types. The document makes no statements about what types are > >mandatory for implementations, so I'm not sure how it is possible to > >provide interoperable implementations. > > I think it should say that *none* of the types is mandatory, which I think > is implied by the text in section 2.4. > > >If published in its current form, I predict that only a small subset > >of types will be implemented and become interoperable. > > I'd say let's agree on what those types are, and move all of the others to > separate drafts. My list: > > - Date (one type) > - CBOR (sometimes parsed, other times kept intact for processing as a byte > stream) > > >Design issue: tagging > >The tagging feature has a wonderful property: the ability to create > >emergency complexity. Given that a tag itself can be arbitrarily > >complex, I'm almost certain that this is a feature you do not want. > > I'm not sure I understand fully what your issue is. Protocol designers > can abuse any format, and when they do, implementors curse them down the > ages. Don't do that. > > >Minor issues: > >Design issue: negative numbers > >Obviously, the authors will be well-prepared for arguments that > >describe as silly the separation of integer types into distinct > >positive and negative types. But it's true, this is a strange choice, > >and a very strange design. > > I think it came from some of the other things in this space (e.g. > zigzag-encoding). I think another option would be to have both signed and > unsigned types. This choice didn't bother me too much in implementation, > except when it was repeated in bigints. > > >The fact that this format is capable of describing 64-bit negative > >numbers creates a problem for implementations that I'm surprised > >hasn't been raised already. In most languages I use, there is no > >native type that is capable of carrying the most negative value that > >can be expressed in this format. -2^64 is twice as large as a 64-bit > >twos-complement integer can store. > > Yes, that should be mentioned in the doc, probably with a MUST NOT. > > >It almost looks as though CBOR is defining a 65-bit, 33-bit or 17-bit > >twos complement integer format, with the most significant bit isolated > >from the others, except that the negative expression doesn't even have > >the good sense to be properly sortable. Given that and the fact that > >bignums are also defined, I find this choice to be baffling. > > This is a quite valid concern. Let's get it fixed. > > >Document issue: Canonicalization > >Please remove Section 3.6. c14n is hard, and this format actually > >makes it impossible to standardize a c14n scheme, that says a lot > >about it. In comparison, JSON is almost trivial to canonicalize. > > Agree with removing section 3.6, and moving to another doc if really > desired. > > STRONGLY disagree that JSON is trivial to canonicalize. The Unicode > issues notwithstanding (escaping, etc), the numeric format is a mess to > get into canonical form. > > >If the intent of this section is to describe some of the possible > >gotchas, such as those described in the last paragraph, then that > >would be good. Changing the focus to "Canonicalization > >Considerations" might help. > > > >I believe that there are several issues that this section would still > >need to consider. For instance, the use of the types that contain > >additional JSON encoding hints carry additional semantics that might > >not be significant to the application protocol. > > > >Extension based on minor values 28-30 (the "additional information" > >space): > >...is impossible as defined. Section 5.1 seems to imply otherwise. > >I'm not sure how that would ever happen without breaking existing > >parsers. Section 5.2 actually makes this worse by making a > >wishy-washy commitment to size for 28 and 29, but no commitment at all > >for 30. > > +1. I'd prefer we remove streaming and tighten the additional information > bits back up to all being used as in previous versions of the draft. > > >Nits: > >Section 3.7 uses the terms "well-formed" and "valid" in a sense that I > >believe to be consistent with their use in XML and XML Schema. I > >found the definition of "valid" to be a little difficult to parse; > >specifically, it's not clear whether invalid is the logical inverse of > >valid. > > Agree that language needs to be massaged. > > >Appendix B/Table 4 has a TBD on it. Can this be checked? > > Sure. > > >Table 4 keeps getting forward references, but it's hidden in an > >appendix. I found that frustrating as a reader because the forward > >references imply that there is something important there. And that > >implication was completely right, this needs promotion. I know why > >it's hidden, but that reason just supports my earlier theses. > > I think it should not be referred to earlier. It's an implementation > choice, and not one that I (for example) made. Thinking about that table > made it more difficult for me to get started. > > >Section 5.1 says "An IANA registry is appropriate here.". Why not > >reference Section 7.1? > > Yes, that needs to be fixed. > > >[1] https://github.com/martinthomson/aweson > > Add binary, and remove the string quoting requirements, please. :) > > > > Other things that ought to be discussed: > > I would like to see another design goal: "May be implemented in modern web > browsers". That should be possible with the new binary types. > > > I still don't see the need for non-string map keys. JSON mapping would be > easier without them, as would uniqueness checking. If they are to be > retained, they should have some motivation in the spec, describing how and > why they might be used. > > I wish I could think of another good simple value that we might register > one day. The only one I've come up with is "no-op", which I might use in > a streaming application as a trivial keep-alive or a marker between > records to ensure parser state sync. I wouldn't classify that as "good" > however. > > Nested tags ought to be forbidden until we come up with a strong use case > for them. > > I could use some implementation guidance on how to generate the most > compact floating-point type for a given number, assuming we keep all of > the floating-point types. > > I don't like 2.4.4.2 "Expected Later Encoding for CBOR to JSON > Converters". Having a sender care about the encoding of a second format > at the same time seems unnecessarily complex. I'd like to see this > section and the corresponding tags moved to another spec, or just removed. > > Similar for tags 33 and 34. Just send the raw bytes as a byte string; > there's no need to actually base64 encode. > > > Section 3.2.3, we should call out the heresy of including UTF-16 > surrogates encoded as UTF-8 for those that can't read the UTF-8 spec. > > Overall in section 3.2, "should probably issue an error but might take > some other action" seems like it will cause some interop surprises in > practice. > > Section 3.3, "all number representations are equivalent" is unclear, even > with the clarifying phrase afterward. > > If section 3.6 stays, the numerics need more work. +/- Infinity should be > treated like NaN. "if the result is the same value" would benefit from > some more clarity. The tags section is also somewhat unclear. > > Section 4.2, what about numbers with uninteresting fractional parts, like > 1.0? What about numbers in exponential format without fractional parts, > like 1e10? I would recommend against even suggest encoding in place. > It's likely to cause a security issue for the reason mentioned. > > Section 6, including the diagnostic notation is a little strange. I would > at least like "it is not meant to be parsed" to be strengthened to "MUST > NOT be parsed". > > Section 7.1, simple values 0..15 can never be used with this construction. > If that's intentional, then give a good reason. > > Section 7.2, do we have language we can use about how to reclaim > first-come-first-serve tags that aren't being used anymore? e.g. the web > page is down and the requestor may be dead. > > In section 7.3, yes, we should make "application/mmmmm+cbor" valid. > > In section 8, perhaps mention a stack attack like: > > 0x818181818181818181... > > I implemented depth counting with a maximum as an approach to avoid this. > > There are likely to be lots of other security concerns. > > I have checked all of the examples in Appendix A. I would have expected > > 2(h'010000000000000000') | 0xc249010000000000000000 > > Not 18446744073709551616, since in the diagnostic, I don't necessarily > support bignums. > > Same with 0xc349010000000000000000. > > For numbers, section 9.8.1 of ECMA-262 (JSON.stringify) is relevant. So: > > 5.960464477539063e-8 | 0xf90001 (not e-08) > 0.00006103515625 | 0xf90400 (not e-05) > > > > In Appendix B, there are holes in the jump table. If you're going to have > a table, call out the invalid values, such as 0x1c-0x1f. > > In Appendix C, the use of the variable "breakable" is unclear, and it's > not obvious how you'll get to the "no enclosing indefinite" case. > > In Appendix D, shouldn't the input be unsigned or an array of bytes? > > Appendix E.1, aren't there some cases of DER where you need the schema to > parse? Add PER. > > Appendix E, we should mention Smile, since the first two octets are so > cute. > > Overall, I think this doc shows a lot of promise, and I'm looking forward > to having something on standards track that has these properties. > > -- > Joe Hildebrand > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --047d7b6da6ac58c4a504e336f480 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I like the design of CBOR but my big question is how much = code-size and memory-size and performance it actually buys you.=C2=A0 My ex= perience is that the performance of software that parses XML & JSON is = often dominated by memory allocation as it builds the structures to hold th= e parsed data.=C2=A0 Do we have any data? -T


On Mon,= Aug 5, 2013 at 10:43 AM, Joe Hildebrand (jhildebr) <<= a href=3D"mailto:jhildebr@cisco.com" target=3D"_blank">jhildebr@cisco.com> wrote:
Sorry, my response is also correspondingly l= ong. =C2=A0There are some original
comments at the end that are not just responses to Martin.

On 7/30/13 9:05 AM, "Martin Thomson" <martin.thomson@gmail.com> wrote:

>I'm glad that I held this review until Paul's appsarea presenta= tion.
>This made it very clear to me that the types of concerns I have are
>considered basically irrelevant by the authors because they aren't<= br> >interested in changing the design goals. =C2=A0I don't find the spe= cific
>design goals to be interesting and am of the opinion that the goals
>are significant as a matter of general application. =C2=A0I hope that i= s
>clear from my review.

I don't think you made it clear which of the design goals you thought weren't interesting. =C2=A0I'll give my take on each of them here:<= br>
> 1. =C2=A0The representation must be able to unambiguously encode most<= br> > common data formats used in Internet standards.


Seems reasonable. =C2=A0For example, dates *do* come up quite often (e.g. M= IME
headers).

> 2. =C2=A0The code for an encoder or parser must be able to be compact = in
> order to support systems with very limited memory and processor
> power and instruction sets.


Seems reasonable, particularly if you're targeting embedded devices and=
sensors. =C2=A0One of the other corollaries they ought to mention here is t= hat
devices that have small implementations should be able to receive a subset<= br> of the value of the format, implementing only the parts that they need to and skipping everything they don't understand.

> 3. =C2=A0Data must be able to be parsed without a schema description.<= br>

I'd put this first. =C2=A0It's an absolute must-have for future ext= ensibility.


> 4. =C2=A0The serialization must be reasonably compact, but data
> compactness is secondary to code compactness for the encoder and
> parser.


This is one of the things that people don't like about XML, which leads=
them to come up with aggressively complicated approaches like EXI. =C2=A0I<= br> might argue that it's a little more important than code compactness for= my
use cases, but I think CBOR currently strikes an adequate balance.

> 5. =C2=A0The format must be applicable to both constrained nodes and h= igh-
> volume applications.

In IoT applications, both will be true at the same time, so I like this
requirement. =C2=A0Low CPU usually means less battery usage anyway.


> 6. =C2=A0The format must support all JSON data types for conversion to= and
> from JSON.


Why not? =C2=A0There are some bits that don't convert quite cleanly eno= ugh to
JSON, but it's pretty close.

> 7. =C2=A0The format must be extensible, with the extended data being a= ble
> to be parsed by earlier parsers.


This is interesting, and I would be willing to give up several kinds of
extensibility to get more simplicity. =C2=A0Perhaps this is your greatest issue, and I don't think you are necessarily wrong.



>I have reviewed the mailing list feedback, and it's not clear to me=
>that there is consensus to publish this. =C2=A0It might be that the dis= sent
>that I have observed is not significant in Barry's learned judgment= ,
>or that this is merely dissent on design goals and therefore
>irrelevant. =C2=A0The fact that this work isn't a product of a work= ing
>group still concerns me. =C2=A0I'm actually interested in why this = is
>AD-sponsored rather than a working group product.

I think this draft is interesting, and might benefit from a short-lived
working group to ensure that enough people have reviewed it. =C2=A0As well,= I
think there might need to be a BCP70-style document that explores how to design protocols using CBOR, after we've got some implementation
experience.

I do think that rather a lot of the dissent from the list was heard and
incorporated, including streaming, which I personally think is an
over-complication, but others really seemed to want.

>Major issues:
>My major concerns with this document might be viewed as disagreements >with particular design choices. =C2=A0And, I consider it likely that th= e
>authors will conclude that the document is still worth publishing as >is, or perhaps with some minor changes. =C2=A0In the end, I have no iss= ue
>with that, but expect that the end result will be that the resulting >RFC is ignored.

I don't agree that CBOR will be ignored if published in the current for= m,
but I do believe it could use a little more review and polish.

>What would cause this to be tragic, is if publication of this were
>used to prevent other work in this area from subsequently being
>published. =C2=A0(For those drawing less-than-charitable inferences fro= m
>this, I have no desire to throw my hat into this particular ring,
>except perhaps in jest [1].)

There will be other formats, even if this is published.


>This design is far too complex and large. =C2=A0Regardless of how
>well-considered it might be, or how well this meets the stated design >goals, I can't see anything but failure in this document's futu= re.
>JSON succeeds largely because it doesn't attempt to address so many=
>needs at once, but I could even make a case for why JSON contains too >many features.

I've implemented it twice now, using two different approaches. =C2=A0Th= e second
time, I separated the lexing and generation using a SAX-style eventing
model. =C2=A0There were a total of eight events fired:

- value
- array start/stop
- map start/stop
- stream start/stop
- end

That seems roughly minimal for data shaped similarly to JSON (except for streams), and significantly less complex than the equivalent SAX2 set for XML.

>In comparison with JSON, this document does one major thing wrong: it >has more options than JSON in several dimensions. =C2=A0There are more<= br> >types, there are several more dimensions for extensibility than JSON: >types extensions, values extensions (values of 28-30 in the lower bits<= br> >of the type byte), plus the ability to apply arbitrary tags to any
>value. =C2=A0I believe all of these to be major problems that will caus= e
>them to be ignored, poorly implemented, and therefore useless.

I agree that not everyone will implement all of the semantic tags, but the<= br> fact that you can continue parsing even if you receive a tag you don't<= br> implement is an interesting and useful property.

I do agree that the extensibility of the patterns 28-30 is scary; those
came about when streaming was added.

>In part, this complexity produces implementations that are far more
>complex than they might need to be, unless additional standardization >is undertaken. =C2=A0That idea is something I'm uncomfortable with.=

I didn't find either of those properties to be challenging to code arou= nd.
=C2=A0I error on bit patterns for 28-30, capture but ignore tags in the
eventing layer, and in the generation layer am able to implement new tags with code that looks like:

tag_DATE_STRING: (val)->
=C2=A0 new Date(val)

Which doesn't seem like an onerous burden for the upside of being able = to
round-trip all of the built-in JavaScript types.


I guess I disagree with your characterization of overcomplexity, based on implementation experience.

>Design issue: extensibility:
>This document avoids discussion of issues regarding schema-less
>document formats that I believe to be fundamental. =C2=A0These issues a= re
>critical when considering the creation of a new interchange format.
>By choosing this specific design it makes a number of trade-offs that >in my opinion are ill-chosen. =C2=A0This may be in part because the
>document is unclear about how applications intend to use the documents<= br> >it describes.
>
>You may conclude after reading this review that this is simply because<= br> >the document does not explain the rationale for selecting the approach<= br> >it takes. =C2=A0I hope that isn't the conclusion you reach, but app= reciate
>the reasons why you might do so.
>
>I believe the fundamental problem to be one that arises from a
>misunderstanding about what it means to have no schema. =C2=A0Aside fro= m
>formats that require detailed contextual knowledge to interpret, there<= br> >are several steps toward the impossible, platonic ideal of a perfectly<= br> >self-describing format. =C2=A0It's impossible because ultimately th= e entity
>that consumes the data is required at some level to understand the
>semantics that are being conveyed. =C2=A0In practice, no generic format= can
>effectively self-describe to the level of semantics.
>
>This draft describes a format that is more capable at self-description<= br> >than JSON. =C2=A0I believe that to not just be unnecessary, but
>counterproductive. =C2=A0At best, it might provide implementations with= a
>way to avoid an occasional extra line of code for type conversion.

As an example, the binary string type would be quite useful for JOSE-style<= br> documents that need to reproduce a set of octets exactly. =C2=A0Today, Base= 64
is required for that in JSON, which is causing the JOSE working group to limit the size (and therefore the ease of understanding) of value names, as multiple layers of Base64 can expand their output size past the
external limits placed on applications by browsers.

Secondly, numeric types in JSON are pretty woefully underspecified, and
cannot be fixed. Transmitting both integers and floats with precise
understanding of how they will be received is often quite useful.

I don't see either of these as simple type conversion issues.

>Extensibility as it relates to types:
>The use of extensive typing in CBOR implies an assumption of a major >role for generic processing. =C2=A0XML schema and XQuery demonstrate th= at
>this desire is not new, but they also demonstrate the folly of
>pursuing those goals.

XML schema keeps these bits in a (quite complex) separate stream, which
requires significant extra processing to add type information into the
parse stream. =C2=A0I agree that we've learned that this approach doesn= 't work
well. =C2=A0I don't think that either XSD or XQuery prove anything abou= t
putting some type information into the data stream itself.


>JSON relies on a single mechanism for extensibility. JSON maps that
>contain unknown or unsupported keys are (usually) ignored. =C2=A0This >allows new values to be added to documents without destroying the
>ability of an old processor to extract the values that it supports.
>The limited type information JSON carries leaks out, but it's uncle= ar
>what value this has to a generic processor. =C2=A0All of the generic us= es
>I've seen merely carry that type information, no specific use is ma= de
>of the knowledge it provides.

I don't see how this is relevant. =C2=A0Most CBOR extensibility for a g= iven
protocol will follow this model exactly.

>ASN.1 extensibility, as encoded in PER, leads to no type information >leaking. =C2=A0Unsupported extensions are skipped based on a length fie= ld.

I'd say that CBOR has a slight advantage here, because you can still ge= t
some interesting information out of many tag types, even if you don't support that tag type. =C2=A0That allows a non-extensible parsing system to= be
used, if desired.

>(As an aside, PER is omitted from the analysis in the appendix, which >I note from the mailing lists is due to its dependency on schema.
>Interestingly, I believe it to be possible - though not trivial - to >create an ASN.1 description with all the properties described in CBOR >that would have roughly equivalent, if not fully equivalent,
>properties to CBOR when serialized.)

Let's add PER to the analysis. =C2=A0I don't think it will have the= properties
desired, since the decoder has to have access to the same schema the
sender had. =C2=A0I agree that it might be possible to create CBOR Encoding=
Rules or the moral equivalent, but I'm not sure I agree that it would b= e
worth the effort.

>By defining an extensibility scheme for types, CBOR effectively
>acknowledges that a generic processor doesn't need type information=
>(just delineation information), but it then creates an extensive type >system. =C2=A0That seems wasteful.

In a given system using CBOR, the protocol designers will decide which
types to use. =C2=A0All of the tooling in that ecosystem will parse and enc= ode
the selected types.

Think of the extensibility here being more for generating lots of
different protocols on top of CBOR, not lots of different types in one
protocol.

>Design issue: types:
>The addition of the ability to carry uninterpreted binary data is a
>valuable and important feature. =C2=A0If that was all this document did= ,
>then that might have been enough. =C2=A0But instead it adds numerous >different types.

I agree that binary is the most important. =C2=A0However, unambiguous,
unescaped, UTF8-only text is also a big win over JSON. =C2=A0Precise floats= are
a distant third for me, but seem to be the most important for folks that do remote sensors.

>I can understand why multiple integer encoding sizes are desirable,
>and maybe even floating point representations, but this describes
>bignums in both base 2 and 10,

I agree that the bignums are overkill. =C2=A0I implemented them the second<= br> time, but I made sure they were slow. :)

Seriously, I don't see using these in any applications, unless the
security folks decide they are a good fit for an RSA modulus.

>embedded CBOR documents in three forms,
>URIs, base64 encoded strings, regexes, MIME bodies, date and times in >two different forms, and potentially more.

I think I may be responsible for having suggested URIs and regexes, and
would fully support removing them from the base draft, along with all of the baseX and the (underspecified) MIME stuff.

Please keep the dates.

>I also challenge the assertion made where the code required for
>parsing a data type produces larger code sizes if performed outside of<= br> >a common shared library. =C2=A0That's arguably provably true, but l= ast time
>I checked a few extra procedure calls (or equivalent) weren't the >issue for code size. =C2=A0Sheer number of options on the other hand mi= ght
>be.

That assertion is also unconvincing to me. =C2=A0However, I'd really li= ke my
docs to round-trip, and dates are a big hole in that. =C2=A0I personally wa= nt
precisely one date type (rather than two), and don't care which one is<= br> selected. =C2=A0Javascript floating point milliseconds before/after the epo= ch
seems like a reasonable starting point, for example.

>Half-precision floating point numbers are a good example of excessive >exuberance. =C2=A0They are not available in many languages for good rea= son:
>they aren't good for much.

They're also relatively new.

>They actually tend to cause errors in
>software in the same way that threading libraries do: it's not that=
>it's hard to use them, it's that it's harder than people th= ink. =C2=A0And
>requiring that implementations parse these creates unnecessary
>complexity.

I know that it took me an hour or two with the IEEE754 docs to implement them in JavaScript, and that code passes a ton of unit tests, including
subnormals, +/- infinity, and NaNs. =C2=A0That said, I don't need halfs= for my
use cases, but if sensor folks feel strongly about them, I'm willing to=
keep that code in place.

It's *really* nice to be able to encode NaN and +/- Infinity as separat= e
from null, which JSON does not allow.

>I do not believe that for the very small subset of cases
>where half precision is actually useful, the cost of transmitting the >extra 2 bytes of a single-precision number is not going to be a
>burden. =C2=A0However, the cost of carrying the code required to decode=
>them is not as trivial as this makes out. =C2=A0The fact that this requ= ires
>an appendix would seem to indicate that this is special enough that
>inclusion should have been very carefully considered. =C2=A0To be hones= t,
>if it were my choice, I would have excluded single-precision floating >point numbers as well, they too create more trouble than they are
>worth.

I'd be fine with that for my use cases, too, but realize there are othe= r
use cases where people care about both half- and single-precision, and am willing to write a couple of extra lines of code to get them onboard.

>Design issue: optionality
>CBOR embraces the idea that support for types is optional. =C2=A0Given = the
>extensive nature of the type system, it's almost certain that
>implementations will choose to avoid implementation of some subset of >the types. =C2=A0The document makes no statements about what types are<= br> >mandatory for implementations, so I'm not sure how it is possible t= o
>provide interoperable implementations.

I think it should say that *none* of the types is mandatory, which I think<= br> is implied by the text in section 2.4.

>If published in its current form, I predict that only a small subset >of types will be implemented and become interoperable.

I'd say let's agree on what those types are, and move all of the ot= hers to
separate drafts. =C2=A0My list:

- Date (one type)
- CBOR (sometimes parsed, other times kept intact for processing as a byte<= br> stream)

>Design issue: tagging
>The tagging feature has a wonderful property: the ability to create
>emergency complexity. =C2=A0Given that a tag itself can be arbitrarily<= br> >complex, I'm almost certain that this is a feature you do not want.=

I'm not sure I understand fully what your issue is. =C2=A0Protocol desi= gners
can abuse any format, and when they do, implementors curse them down the ages. =C2=A0Don't do that.

>Minor issues:
>Design issue: negative numbers
>Obviously, the authors will be well-prepared for arguments that
>describe as silly the separation of integer types into distinct
>positive and negative types. =C2=A0But it's true, this is a strange= choice,
>and a very strange design.

I think it came from some of the other things in this space (e.g.
zigzag-encoding). =C2=A0I think another option would be to have both signed= and
unsigned types. =C2=A0This choice didn't bother me too much in implemen= tation,
except when it was repeated in bigints.

>The fact that this format is capable of describing 64-bit negative
>numbers creates a problem for implementations that I'm surprised >hasn't been raised already. =C2=A0In most languages I use, there is= no
>native type that is capable of carrying the most negative value that >can be expressed in this format. =C2=A0-2^64 is twice as large as a 64-= bit
>twos-complement integer can store.

Yes, that should be mentioned in the doc, probably with a MUST NOT.

>It almost looks as though CBOR is defining a 65-bit, 33-bit or 17-bit >twos complement integer format, with the most significant bit isolated<= br> >from the others, except that the negative expression doesn't even h= ave
>the good sense to be properly sortable. =C2=A0Given that and the fact t= hat
>bignums are also defined, I find this choice to be baffling.

This is a quite valid concern. =C2=A0Let's get it fixed.

>Document issue: Canonicalization
>Please remove Section 3.6. =C2=A0c14n is hard, and this format actually=
>makes it impossible to standardize a c14n scheme, that says a lot
>about it. =C2=A0In comparison, JSON is almost trivial to canonicalize.<= br>
Agree with removing section 3.6, and moving to another doc if really
desired.

STRONGLY disagree that JSON is trivial to canonicalize. =C2=A0The Unicode issues notwithstanding (escaping, etc), the numeric format is a mess to
get into canonical form.

>If the intent of this section is to describe some of the possible
>gotchas, such as those described in the last paragraph, then that
>would be good. =C2=A0Changing the focus to "Canonicalization
>Considerations" might help.
>
>I believe that there are several issues that this section would still >need to consider. =C2=A0For instance, the use of the types that contain=
>additional JSON encoding hints carry additional semantics that might >not be significant to the application protocol.
>
>Extension based on minor values 28-30 (the "additional information= "
>space):
>...is impossible as defined. =C2=A0Section 5.1 seems to imply otherwise= .
>I'm not sure how that would ever happen without breaking existing >parsers. =C2=A0Section 5.2 actually makes this worse by making a
>wishy-washy commitment to size for 28 and 29, but no commitment at all<= br> >for 30.

+1. =C2=A0I'd prefer we remove streaming and tighten the additional inf= ormation
bits back up to all being used as in previous versions of the draft.

>Nits:
>Section 3.7 uses the terms "well-formed" and "valid"= ; in a sense that I
>believe to be consistent with their use in XML and XML Schema. =C2=A0I<= br> >found the definition of "valid" to be a little difficult to p= arse;
>specifically, it's not clear whether invalid is the logical inverse= of
>valid.

Agree that language needs to be massaged.

>Appendix B/Table 4 has a TBD on it. =C2=A0Can this be checked?

Sure.

>Table 4 keeps getting forward references, but it's hidden in an
>appendix. =C2=A0I found that frustrating as a reader because the forwar= d
>references imply that there is something important there. =C2=A0And tha= t
>implication was completely right, this needs promotion. =C2=A0I know wh= y
>it's hidden, but that reason just supports my earlier theses.

I think it should not be referred to earlier. =C2=A0It's an implementat= ion
choice, and not one that I (for example) made. =C2=A0Thinking about that ta= ble
made it more difficult for me to get started.

>Section 5.1 says "An IANA registry is appropriate here.". =C2= =A0Why not
>reference Section 7.1?

Yes, that needs to be fixed.

>[1] https://github.com/martinthomson/aweson

Add binary, and remove the string quoting requirements, please. :)



Other things that ought to be discussed:

I would like to see another design goal: "May be implemented in modern= web
browsers". =C2=A0That should be possible with the new binary types.

I still don't see the need for non-string map keys. =C2=A0JSON mapping = would be
easier without them, as would uniqueness checking. =C2=A0If they are to be<= br> retained, they should have some motivation in the spec, describing how and<= br> why they might be used.

I wish I could think of another good simple value that we might register one day. =C2=A0The only one I've come up with is "no-op", whi= ch I might use in
a streaming application as a trivial keep-alive or a marker between
records to ensure parser state sync. =C2=A0I wouldn't classify that as = "good"
however.

Nested tags ought to be forbidden until we come up with a strong use case for them.

I could use some implementation guidance on how to generate the most
compact floating-point type for a given number, assuming we keep all of
the floating-point types.

I don't like 2.4.4.2 "Expected Later Encoding for CBOR to JSON
Converters". =C2=A0Having a sender care about the encoding of a second= format
at the same time seems unnecessarily complex. =C2=A0I'd like to see thi= s
section and the corresponding tags moved to another spec, or just removed.<= br>
Similar for tags 33 and 34. =C2=A0Just send the raw bytes as a byte string;=
there's no need to actually base64 encode.


Section 3.2.3, we should call out the heresy of including UTF-16
surrogates encoded as UTF-8 for those that can't read the UTF-8 spec.
Overall in section 3.2, "should probably issue an error but might take=
some other action" seems like it will cause some interop surprises in<= br> practice.

Section 3.3, "all number representations are equivalent" is uncle= ar, even
with the clarifying phrase afterward.

If section 3.6 stays, the numerics need more work. =C2=A0+/- Infinity shoul= d be
treated like NaN. =C2=A0"if the result is the same value" would b= enefit from
some more clarity. =C2=A0The tags section is also somewhat unclear.

Section 4.2, what about numbers with uninteresting fractional parts, like 1.0? =C2=A0What about numbers in exponential format without fractional part= s,
like 1e10? =C2=A0I would recommend against even suggest encoding in place.<= br> It's likely to cause a security issue for the reason mentioned.

Section 6, including the diagnostic notation is a little strange. =C2=A0I w= ould
at least like "it is not meant to be parsed" to be strengthened t= o "MUST
NOT be parsed".

Section 7.1, simple values 0..15 can never be used with this construction.<= br> =C2=A0If that's intentional, then give a good reason.

Section 7.2, do we have language we can use about how to reclaim
first-come-first-serve tags that aren't being used anymore? =C2=A0e.g. = the web
page is down and the requestor may be dead.

In section 7.3, yes, we should make "application/mmmmm+cbor" vali= d.

In section 8, perhaps mention a stack attack like:

0x818181818181818181...

I implemented depth counting with a maximum as an approach to avoid this.
There are likely to be lots of other security concerns.

I have checked all of the examples in Appendix A. =C2=A0I would have expect= ed

2(h'010000000000000000') | 0xc249010000000000000000

Not 18446744073709551616, since in the diagnostic, I don't necessarily<= br> support bignums.

Same with 0xc349010000000000000000.

For numbers, section 9.8.1 of ECMA-262 (JSON.stringify) is relevant. =C2=A0= So:

5.960464477539063e-8 | 0xf90001 =C2=A0 (not e-08)
0.00006103515625 | 0xf90400 =C2=A0 =C2=A0 =C2=A0 (not e-05)



In Appendix B, there are holes in the jump table. =C2=A0If you're going= to have
a table, call out the invalid values, such as 0x1c-0x1f.

In Appendix C, the use of the variable "breakable" is unclear, an= d it's
not obvious how you'll get to the "no enclosing indefinite" c= ase.

In Appendix D, shouldn't the input be unsigned or an array of bytes?
Appendix E.1, aren't there some cases of DER where you need the schema = to
parse? =C2=A0Add PER.

Appendix E, we should mention Smile, since the first two octets are so
cute.

Overall, I think this doc shows a lot of promise, and I'm looking forwa= rd
to having something on standards track that has these properties.

--
Joe Hildebrand

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

--047d7b6da6ac58c4a504e336f480-- From andy@hxr.us Mon Aug 5 11:09: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 F403121F9967 for ; Mon, 5 Aug 2013 11:09:45 -0700 (PDT) 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] 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 RuK7RUuhp0zY for ; Mon, 5 Aug 2013 11:09:40 -0700 (PDT) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by ietfa.amsl.com (Postfix) with ESMTP id BB14921F9F2B for ; Mon, 5 Aug 2013 11:09:33 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id z11so3537951pdj.3 for ; Mon, 05 Aug 2013 11:09:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=K3IT/V37Sp2gjxlEEqIFJm9xRLROYVRE1wy1KtqXh5E=; b=SZa85+w1OGvCIR3xoVw8Sq27YVwnAEq5E6ymz9BEnwZM6Jev+Bye6uRBlaQl/HQl1m E/ZfU8JnDr5azBWvatHf86cx8bJVQZclsKCzaWpELCiktclbknHJa1RJy0jYcDr/wxMX aKHZIZawvxUUn6PplCIIsmBplPBDzxaBfpomlBrREK8x1L78G2poAHGA+v29fHSemBKL qv180yAEmH+93W5n20570+uYYruZx4bcJM2ybW2/9iWyiuAj11XBmLnZQU+w2TExfhEs YheDvERFhoDlW7UINWPZRVigSVrClV09HqtJure7Rf/RpIZs7jN4C8pSjy3ERGQ2HXIp wn3g== MIME-Version: 1.0 X-Received: by 10.66.145.4 with SMTP id sq4mr26551933pab.46.1375726171066; Mon, 05 Aug 2013 11:09:31 -0700 (PDT) Received: by 10.68.203.69 with HTTP; Mon, 5 Aug 2013 11:09:31 -0700 (PDT) X-Originating-IP: [192.149.252.11] Date: Mon, 5 Aug 2013 14:09:31 -0400 Message-ID: From: Andrew Newton To: "apps-discuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnncJ+cee7ZtR/xSvdVnelS8OUoe6De9yc9N0sOlZXZ22DP9SnPIDYhv7eG6qCDhz4j97u4 Subject: [apps-discuss] WG Summary: URNBIS 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, 05 Aug 2013 18:09:46 -0000 URNBIS met on Friday at 11:20. Scheduled time for the working group was 1 hour, but the session did not need the full hour. On the agenda were issues discussions for both 2141bis and 3406bis. 2141bis did not require much discussion. Discussion on 3406bis were largely related to changing the acquisition of new URN namespaces from RFC required to Expert Review, and changes in the IANA registration template to make application of URN namespaces a more straightforward process. Shortly after the meeting 2141bis was revised, and should be moving to working group last call shortly. 3406bis will also be revised and may move to WGLC if there are no additional list discussions on the revision. -andy From dhc@dcrocker.net Mon Aug 5 15:56: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 9726721F9F3D for ; Mon, 5 Aug 2013 15:56:58 -0700 (PDT) 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 Cyz4yKG6WZ-1 for ; Mon, 5 Aug 2013 15:56:53 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id AFCD321F9F12 for ; Mon, 5 Aug 2013 15:56:53 -0700 (PDT) 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 r75MukRi024697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Aug 2013 15:56:50 -0700 Message-ID: <52002DAC.9040702@dcrocker.net> Date: Tue, 06 Aug 2013 00:56:44 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Salvatore Loreto References: <51FB802F.1090709@ericsson.com> In-Reply-To: <51FB802F.1090709@ericsson.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]); Mon, 05 Aug 2013 15:56:50 -0700 (PDT) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 05 Aug 2013 22:56:58 -0000 On 8/2/2013 11:47 AM, Salvatore Loreto wrote: > > This is a call for adoption for draft-wmills-rrvs-header-field [1] +1 I've assorted editorial comments, but the technical approach looks reasonable to me. I think the only technical wrinkle that's significant is the restriction to a single addressee, but I'm told that's been relaxed for the latest version of the spec. (Admittedly, permitting multiple addressees does introduce privacy and probably other concerns.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From kurta@drkurt.com Mon Aug 5 16:04:02 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 16C1E21F9E9D for ; Mon, 5 Aug 2013 16:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 jUoFaZMTNydf for ; Mon, 5 Aug 2013 16:04:01 -0700 (PDT) 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 6B5ED21F9D6F for ; Mon, 5 Aug 2013 16:04:01 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id hi8so2091681wib.9 for ; Mon, 05 Aug 2013 16:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=bF7iBgpk6J0uWH2f0bVK6JIhxnGQBvp6FWNa/G62m20=; b=Oe7pp0i7lLXtDb5ojjZfghwkxONAWchYb9nV1Dq8jxljJojn1MNv/vvX2C2/gSppof VgGLDQCNJuM/mr8ukueLJ/dXtvnX5jW7Id6NwyRgXoDDmdfj8r9oa8k9WQSMwWqEuM43 uw+2WnZY0klAwnO3qqZF2woqSVLWC25XDqDZc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=bF7iBgpk6J0uWH2f0bVK6JIhxnGQBvp6FWNa/G62m20=; b=WqS0IFzpH7Z9Dlu7rmcV3SIZeQqcvF1JSqBjlpuwzL1fJhQJsxjYYzeS5Bk7blKGLY co4hF+JZjkXiidXGzOGvcq2t243dTj3CYcBn0ficcvbrX5MR3nOZfI39livVaWWDaGsL WzWC6B/5k5m3maM2zJIYY+peEw72ud5m1b0qOrW5R3/jlzRGvZtfQ5q02ndoX6oe6qi7 UydYlh+4cvoZisn4dyuMtZyd5FDiFW6mxVIYDY1cYAv1PfAmNBQeUgRJiIq1BXY8JGks vUqSkP+ZTV30aVNZG3xLIYsfxDIffQMrGfOo2ESUSJzt6ymYl9rUz+2qJFZzxTNPBCrm cmsQ== MIME-Version: 1.0 X-Received: by 10.194.122.103 with SMTP id lr7mr14798056wjb.15.1375743840415; Mon, 05 Aug 2013 16:04:00 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.194.21.97 with HTTP; Mon, 5 Aug 2013 16:04:00 -0700 (PDT) In-Reply-To: <52002DAC.9040702@dcrocker.net> References: <51FB802F.1090709@ericsson.com> <52002DAC.9040702@dcrocker.net> Date: Mon, 5 Aug 2013 16:04:00 -0700 X-Google-Sender-Auth: hhGLNi9yQ6pAGkjYLDv-Mg42Smw Message-ID: From: Kurt Andersen To: "apps-discuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkXj5AT49GTAga1YbIssYmT9fSlbLl1jzyY7a1Di2LkG45Fb/CdAzAg+J4vCHgM1RJj5ek/ Subject: Re: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field 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, 05 Aug 2013 23:04:02 -0000 On 8/2/2013 11:47 AM, Salvatore Loreto wrote: > > > This is a call for adoption for draft-wmills-rrvs-header-field > +1 Would be nice to get this stabilized before we start implementing it too widely (being driven by Yahoo!'s email recycling which starts on 15 August). --Kurt Andersen From kurta@drkurt.com Mon Aug 5 16: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 0876421F9DED for ; Mon, 5 Aug 2013 16:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 0QZDXmvsn8+c for ; Mon, 5 Aug 2013 16:08:44 -0700 (PDT) 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 91DC321F9F6C for ; Mon, 5 Aug 2013 16:08:37 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so2895197wes.26 for ; Mon, 05 Aug 2013 16:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=WDFuLAv3Vfy2SDFE4iRI18oqo5VWno6acfYX9s4gvqw=; b=GwUEmivrOrPBlTqL28lh1vjFTDlka4OAjfUI5fXsdzojNYIYjrNN5gL7wxw8rEKBdC t5t+ZTYJlb0u+X6kc6QeXD3yDsNJZzK5NQV/S7kRt5XdXPbTy2OZjCPM6xv46hEO80Pa 3baiYuUM5l9uKxg52RZ/cNzaweZYv8LsRJY54= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=WDFuLAv3Vfy2SDFE4iRI18oqo5VWno6acfYX9s4gvqw=; b=Xm5nmeas9Y41Sud2pM012yoyOPy7EuYovKgNz0viFDNlMHME6X2ea45cAHU3e2nPvg XdgRl7OPGW7gkrC5Judjkk6w/846CnzcZRVxTjGMxOt5x4Fk3qolyn9/W7ewkZdjqIeM XzgeNrlTsznpIa908ncyEIpgxcppGf7ijYEkNYqaMFKW6+cJUei2u6zeqY27BLIo9HCy TaJ+ft6g6DJw7en+cAwFlc4k+R2BuEeXnpBqUezBeK2rIbgSwj92eqbPIF/zKlvrvO5G GcCWP0FZ5IDq9G/+ySq/VI94IEXpBTsS4X24GrEbcJwRSaZTs3QCwOdTQPaw5bEDgTuA X0qg== MIME-Version: 1.0 X-Received: by 10.194.173.71 with SMTP id bi7mr14830510wjc.2.1375744116741; Mon, 05 Aug 2013 16:08:36 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.194.21.97 with HTTP; Mon, 5 Aug 2013 16:08:36 -0700 (PDT) In-Reply-To: <01OWTLIHMZWM00004R@mauve.mrochek.com> References: <01OWTLIHMZWM00004R@mauve.mrochek.com> Date: Mon, 5 Aug 2013 16:08:36 -0700 X-Google-Sender-Auth: 6AtAT_ZN72X35uNAJds4QrDxZRo Message-ID: From: Kurt Andersen To: Ned Freed Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmaN2Z5CDayiAPd/M0TrsETK8sjGxyPjBl6/I3CJCr+Q4Et6MMVexUaa86LpMzYaK7bwyVs Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Consensus to change time field in draft-wmills-rrvs-header-field-00? 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, 05 Aug 2013 23:08:45 -0000 On Sun, Aug 4, 2013 at 2:13 PM, Ned Freed wrote: > I strongly object to the change [from human-readable to epoch seconds]. > DKIM is one thing; signature verification > requires unambiguous inputs and interpretation of the field requires DKIM > software in any case. > > The situation here is different - the input requirements are far less strict, > and readability of the field is going to be important when problems arise - and > rest assure they are going to. I would argue that a security-related header such as this one is exactly parallel to DKIM. When the header is stripped out through normal processing as advised in the -01 draft, I'm not sure what the format of the time field will have to do with solving problems for the no-longer-extant header. I acknowledge John's comment about date processing libraries being commonplace, but I think that putting the data into a machine-oriented format is more in keeping with the security measure that this header is supposed to be providing. --Kurt From superuser@gmail.com Mon Aug 5 16:52: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 EE63F21F9CBF for ; Mon, 5 Aug 2013 16:52:03 -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, 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 OrCVi34uDuee for ; Mon, 5 Aug 2013 16:52:03 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 437F521F9BEF for ; Mon, 5 Aug 2013 16:52:03 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q56so2963911wes.7 for ; Mon, 05 Aug 2013 16:52:01 -0700 (PDT) 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=pA/3qLY6EAc0/M8FAch+qBDpeCftDmgobSWgUmEvuIs=; b=uy7WbN3QcT4YTXYo4VTFsnVFgVk1k3vATY3rt5APSd1QGx/LzgRcU0G/1IsBY65eok s1+tRgSF8sLC4piJL9lOkecQPZI2b5CihDYnXQ0TJ80pCWxYYWPtLPy5eIbEnqPeiNE2 SVZpGDimWoBR6T/SDOZMpUxLVfaxvNbqvcXwQNHOoihc5yfAfyBDAQvsXNtzv5Wt3TdC 7mWf1nd1OpmH90vVXgHIGdVkboqjrQ00uWVSj1ek2UuMJ9tLp4wyQO4FDouc0+QSTwBb MbfOUy5lNq4qpgGWUWz1FUQheirUxh5JoStljLKjlHnNejOlFp+EdIHC6SkAyDjPKLmr N3PQ== MIME-Version: 1.0 X-Received: by 10.194.201.168 with SMTP id kb8mr7723816wjc.63.1375746721138; Mon, 05 Aug 2013 16:52:01 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Mon, 5 Aug 2013 16:52:01 -0700 (PDT) In-Reply-To: References: <01OWTLIHMZWM00004R@mauve.mrochek.com> Date: Mon, 5 Aug 2013 16:52:01 -0700 Message-ID: From: "Murray S. Kucherawy" To: Kurt Andersen Content-Type: multipart/alternative; boundary=047d7ba9730e9d4de104e33bfe50 Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] Consensus to change time field in draft-wmills-rrvs-header-field-00? 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, 05 Aug 2013 23:52:04 -0000 --047d7ba9730e9d4de104e33bfe50 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 5, 2013 at 4:08 PM, Kurt Andersen wrote: > I acknowledge John's comment about date processing libraries being > commonplace, but I think that putting the data into a machine-oriented > format is more in keeping with the security measure that this header > is supposed to be providing. > I think Bill and I are in agreement that we don't have a strong preference as to which form is used and will go with consensus, but here's a minor counter-argument: If there's no DKIM verification code in effect at a receiver, then there's nothing that knows about epoch time format (not that it's complicated) in use at that receiver; however, that same receiver is probably already equipped to parse a Date: field. -MSK --047d7ba9730e9d4de104e33bfe50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 5, 2013 at 4:08 PM, Kurt Andersen <kboth@drkur= t.com> wrote:
I acknowledge John's comment about date = processing libraries being
commonplace, but I think that putting the data into a machine-oriented
format is more in keeping with the security measure that this header
is supposed to be providing.

I think Bill= and I are in agreement that we don't have a strong preference as to wh= ich form is used and will go with consensus, but here's a minor counter= -argument:

If there's no DKIM verification code in effect at a rece= iver, then there's nothing that knows about epoch time format (not that= it's complicated) in use at that receiver; however, that same receiver= is probably already equipped to parse a Date: field.

-MSK
--047d7ba9730e9d4de104e33bfe50-- From johnl@iecc.com Mon Aug 5 17:34: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 5433421F9A1C for ; Mon, 5 Aug 2013 17:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.25 X-Spam-Level: X-Spam-Status: No, score=-110.25 tagged_above=-999 required=5 tests=[AWL=0.949, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 Sapl8HH-JgHR for ; Mon, 5 Aug 2013 17:34:37 -0700 (PDT) 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 E3B7621F99AE for ; Mon, 5 Aug 2013 17:34:36 -0700 (PDT) Received: (qmail 66292 invoked from network); 6 Aug 2013 00:34:35 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Aug 2013 00:34:35 -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=5200449b.xn--yuvv84g.k1308; i=johnl@user.iecc.com; bh=L0RqclhN/nySujXditVVLTdIEhwBiJnvsBf8LVqaEfE=; b=cdtfN6McR8hDsXWtyCfStbw06AmBlI/PYRAj/dQzJwCYI3G5ApNHyXEBH3dMUxQhbWPlU9VzDkxqyoSetsrkNmG8ERXfb1o27Ax42uRrVj+uAd/UiWUtw5H1rY7YEVX9MzXIgjHLEkJFCqSW7DK+trAzVvuq6oQWN43uJSSGblWhX9IO5OcjuWIl4bpaHL32/u0wna1s7V5CXi7peWVRuF1qbNy8dsY3caWLA4aMB5V3P5vfOQVhLcqa9kQ3T2gZ 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=5200449b.xn--yuvv84g.k1308; olt=johnl@user.iecc.com; bh=L0RqclhN/nySujXditVVLTdIEhwBiJnvsBf8LVqaEfE=; b=U+6CIF8PY36XDpjPXgcJkc8VM3yGjJr9vj00qFKgw3cI1vShw8SYc3T8CdyhMm1LGNa1DrGerwEz/rSaW76Of7AuCzWPU/+vdKTC+JsNMCG7Hgn04bGD0PnvFg9+huskaPnxt9IQTRJAAn5Z4bbtXbhm/+1i0I7BaXwVV3/W15XDP7BJdO1CtypB8WKd+pyAz4ssmG3uzNe4dbdrgbaXrebT46EuNNm6YPtNjb33gtHhDkDd3LOp1BlN+iGJ9EpU Date: 6 Aug 2013 00:34:13 -0000 Message-ID: <20130806003413.25008.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] Consensus to change time field in draft-wmills-rrvs-header-field-00? 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, 06 Aug 2013 00:34:41 -0000 >If there's no DKIM verification code in effect at a receiver, then there's >nothing that knows about epoch time format (not that it's complicated) in >use at that receiver; however, that same receiver is probably already >equipped to parse a Date: field. Right. Keep in mind that operating systems designed in suburban Seattle use internal date formats very unlike the Unix 1970 epoch, and converting from Unix epoch to their format is not a whole lot easier than parsing Date: fields. R's, John From johnl@iecc.com Mon Aug 5 18:55: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 51B2C21F9D53 for ; Mon, 5 Aug 2013 18:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.293 X-Spam-Level: X-Spam-Status: No, score=-110.293 tagged_above=-999 required=5 tests=[AWL=0.906, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 iouSt7xAPxju for ; Mon, 5 Aug 2013 18:55:38 -0700 (PDT) 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 E5D6321F9DF6 for ; Mon, 5 Aug 2013 18:55:35 -0700 (PDT) Received: (qmail 81274 invoked from network); 6 Aug 2013 01:55:35 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Aug 2013 01:55:35 -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=52005797.xn--hew.k1308; i=johnl@user.iecc.com; bh=AE7ntyu9pxCInkR0YnUfLibgjN6F2ZgNBxoGM2lHWvg=; b=VDUR5+C9hmQx7rLf0hcAYjMbmrbIma7VyZteSVm1MZdx7QZlCL5hosM6NjlgwxLTK2CtCakF4457FHAuRq80A5SWJ76Advr6SynhXGbyNwyBEe4tQdorFMR/ZOmjZq62fvuvYMUWTR+U2XRNDxemqfZEWvC4PYqXdHtyyrOMCa+EGFQ3734r8/Bowrof085U8cDlblh8fGQ2sQraSTDOAtGLB5TjaZDtrp5gALh+O0OZ5pqF8Z5lP8Qp4bXu2G9g 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=52005797.xn--hew.k1308; olt=johnl@user.iecc.com; bh=AE7ntyu9pxCInkR0YnUfLibgjN6F2ZgNBxoGM2lHWvg=; b=E9kuDRJ32DFuxJDe+oyi+4Eoz9y73qoR/cIpmmQAxabK5sufQISqkHu4ogleIkcIMVSmxY5qzT3UgVevsYIM055Bt8sy1fLhO4Sq/gE3maVOidzJ3t6OvT1KQ6LjWLE/xe+cH8y+q+ruFJ0xysyHERwF/62DbmMbZXGE6dhNZXFlz5N951uZndw6XB8hNcriQiF1I6PZn4CYA+yYsZQtF9XCowdKhR32xQrh5JyVKU5wzzwd/ghy4qwSPjUCWl2o Date: 6 Aug 2013 01:55:12 -0000 Message-ID: <20130806015512.25482.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <52002DAC.9040702@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: dcrocker@bbiw.net Subject: Re: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field 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, 06 Aug 2013 01:55:42 -0000 >I think the only technical wrinkle that's significant is the restriction >to a single addressee, but I'm told that's been relaxed for the latest >version of the spec. (Admittedly, permitting multiple addressees does >introduce privacy and probably other concerns.) I don't understand how multiple addresses would work, given the combinatorial explosion of various addresses that do or don't appear in the rrvs header, the To: header, and the envelope, but I guess I should wait and see what the next draft says. From wmills@yahoo-inc.com Mon Aug 5 20:33: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 257F021F9FC8 for ; Mon, 5 Aug 2013 20:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.739 X-Spam-Level: X-Spam-Status: No, score=-15.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 eolBv7wmLZEu for ; Mon, 5 Aug 2013 20:33:14 -0700 (PDT) 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 5C36D21F9FE1 for ; Mon, 5 Aug 2013 20:33:13 -0700 (PDT) Received: from BF1-EX10-CAHT08.y.corp.yahoo.com (bf1-ex10-caht08.corp.bf1.yahoo.com [10.74.209.196]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r763WaoR064547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 5 Aug 2013 20:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1375759957; bh=Rzo6NxbJqDP7HO3R41EzbdXLnaOLMSKo6W3Z2XrsS5E=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=AfMaw54smUVc1BpdUy2XnrVymUMvee5x8Hw9WsJcF/z8Ca+xPC2OgxKwYY8jaqBxv 9Bcu4Oa53z69qQGTtZquoyPaFcK3w1kyKG5Oh7u6Sm7VdWJK/sMW3cq328HZzWIo/j ktRJ57/Uv/JU/kU/GIZd5ZY99H0yE8z6pAFWUhHA= Received: from omp1039.mail.ne1.yahoo.com (98.138.88.239) by BF1-EX10-CAHT08.y.corp.yahoo.com (10.74.209.170) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 5 Aug 2013 23:32:35 -0400 Received: (qmail 19294 invoked by uid 1000); 6 Aug 2013 03:32:35 -0000 Received: (qmail 15383 invoked by uid 60001); 6 Aug 2013 03:32:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1375759955; bh=SHYRQcgGPmRNQ7f0AqdKa+D/Wnq25cAVxSiwn8EV3Wk=; 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=oq/6TfcRel3NqWJZlED49qY2d19QOuQoQQKHmYXuDhbLZlQDvODxiKvDmtI+d6O1hTvlZYrD1NUJ6sdYGzldXZ8H/zzFJ37f+QNmdoqAvXk8fGaEim4S4VBl9iyJmDOfqvfsSbk1shYwgYSqbm+i1o6f9m66CTAb8tVctAjCRgs= 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=sWBqIpe9YdnxzeF9SFfJbgoiHyPtYhjH+4IfxMpdYbK1a4p6vFKDF/7/959IG7d4FZ3p21KOjZezl9hPDezepVkFQR9ECq4dktS/fBaQAfT0/7M3aIiI16CCv+BvXz7AMZ6oZtJB7JI4+GA2ooq472+cR02pd9HGMFXJ1/Tlwnw=; X-YMail-OSG: ze_.8A0VM1lE48MIei8DQgRcHyQjT5ENImWQedOYd4S4g3g Sr90w_ndZGcO_GDGU_Q_1n.LmkOky.IJENcuETv3Els.GZEvSBU9rhpXy64n JJVbBDv1.Yf6TbEFdeWPayJlOJ.u09AI_7NBi6HyO93Yb.ua2bgtxq92dKW0 BdYfO2UKvFLLXCQ2zBTAtyn.1E3vomLS0e7YdxEtph7y60I5a6Tl4dwkKc5p r743XBslEDlZA_48OH3cxmYmvqCkCAswZGJm_c527WJYwvs_w8QjF3qkWVPs 11kmIjuEhdtKEd4.HZJfLcuAwkex3zhBG9qL_ Received: from [99.31.212.42] by web125604.mail.ne1.yahoo.com via HTTP; Mon, 05 Aug 2013 20:32:35 PDT X-Rocket-MIMEInfo: 002.001, QW4gUlJWUyBoZWFkZXIgYXBwbGllcyBvbmx5IGZvciB0aGUgcmVjaXBpZW50IHNwZWNpZmllZCBpbiB0aGUgaGVhZGVyLCBhbmQgYWZmZWN0cyBkZWxpdmVyeSBvbmx5IHRvIHRoYXQgcmVjaXBpZW50LsKgwqAgU28gdGhlIHdheSB0aGlzIHdpbGwgd29ya2lzIHlvdSBuZWVkIGFuIFJWUyBoZWFkZXIgZm9yIGVhY2ggcmVjaXBpZW50IHRoZSBzZW5kZXIgd2FudHMgdG8gYWZmZWN0IHdpdGggUlJWUy4KCgrCoAotYmlsbAoKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpXaWxsaWFtIEouIE1pbGwBMAEBAQE- X-Mailer: YahooMailWebService/0.8.152.567 References: <52002DAC.9040702@dcrocker.net> <20130806015512.25482.qmail@joyce.lan> Message-ID: <1375759955.54940.YahooMailNeo@web125604.mail.ne1.yahoo.com> Date: Mon, 5 Aug 2013 20:32:35 -0700 From: Bill Mills To: John Levine , "apps-discuss@ietf.org" In-Reply-To: <20130806015512.25482.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-685807438-2109059515-1375759955=:54940" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 759956001 Cc: "dcrocker@bbiw.net" Subject: Re: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field 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: Tue, 06 Aug 2013 03:33:19 -0000 ---685807438-2109059515-1375759955=:54940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable An RRVS header applies only for the recipient specified in the header, and = affects delivery only to that recipient.=A0=A0 So the way this will workis = you need an RVS header for each recipient the sender wants to affect with R= RVS.=0A=0A=0A=A0=0A-bill=0A=0A=0A=0A--------------------------------=0AWill= iam J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A=0A=0A____________________________= ____=0A From: John Levine =0ATo: apps-discuss@ietf.org =0A= Cc: dcrocker@bbiw.net =0ASent: Monday, August 5, 2013 6:55 PM=0ASubject: Re= : [apps-discuss] call for adoption: draft-wmills-rrvs-header-field=0A =0A= =0A>I think the only technical wrinkle that's significant is the restrictio= n =0A>to a single addressee, but I'm told that's been relaxed for the lates= t =0A>version of the spec.=A0 (Admittedly, permitting multiple addressees d= oes =0A>introduce privacy and probably other concerns.)=0A=0AI don't unders= tand how multiple addresses would work, given the=0Acombinatorial explosion= of various addresses that do or don't appear=0Ain the rrvs header, the To:= header, and the envelope, but I guess I=0Ashould wait and see what the nex= t draft says.=0A=0A_______________________________________________=0Aapps-d= iscuss mailing list=0Aapps-discuss@ietf.org=0Ahttps://www.ietf.org/mailman/= listinfo/apps-discuss ---685807438-2109059515-1375759955=:54940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
An RRVS h= eader applies only for the recipient specified in the header, and affects d= elivery only to that recipient.   So the way this will workis you= need an RVS header for each recipient the sender wants to affect with RRVS= .

 
-bill


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


<= div dir=3D"ltr">
From: John Levine <johnl@taugh.c= om>
To: apps-discus= s@ietf.org
Cc: dcrocke= r@bbiw.net
Sent: Mond= ay, August 5, 2013 6:55 PM
Subjec= t: Re: [apps-discuss] call for adoption: draft-wmills-rrvs-heade= r-field

>I think t= he only technical wrinkle that's significant is the restriction
>to = a single addressee, but I'm told that's been relaxed for the latest
>= ;version of the spec.  (Admittedly, permitting multiple addressees doe= s
>introduce privacy and probably other concerns.)

I don't un= derstand how multiple addresses would work, given the
combinatorial expl= osion of various addresses that do or don't appear
in the rrvs header, t= he To: header, and the envelope, but I guess I
should wait and see what th= e next draft says.

_______________________________________________apps-discuss mailing list
apps-discuss@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/apps-discuss


---685807438-2109059515-1375759955=:54940-- From dhc@dcrocker.net Mon Aug 5 20:48: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 243C411E80D2 for ; Mon, 5 Aug 2013 20:48:49 -0700 (PDT) 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 jaE2lUJ4L4QS for ; Mon, 5 Aug 2013 20:48:44 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 40E8E11E80D1 for ; Mon, 5 Aug 2013 20:48:43 -0700 (PDT) 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 r763mdnm028788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Aug 2013 20:48:42 -0700 Message-ID: <52007215.6020400@dcrocker.net> Date: Tue, 06 Aug 2013 05:48:37 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Bill Mills References: <52002DAC.9040702@dcrocker.net> <20130806015512.25482.qmail@joyce.lan> <1375759955.54940.YahooMailNeo@web125604.mail.ne1.yahoo.com> In-Reply-To: <1375759955.54940.YahooMailNeo@web125604.mail.ne1.yahoo.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]); Mon, 05 Aug 2013 20:48:42 -0700 (PDT) Cc: John Levine , "dcrocker@bbiw.net" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 03:48:49 -0000 On 8/6/2013 5:32 AM, Bill Mills wrote: > An RRVS header applies only for the recipient specified in the header, > and affects delivery only to that recipient. So the way this will > workis you need an RVS header for each recipient the sender wants to > affect with RRVS. I suspect that a failure for one needs to be a failure for all, at the end of the SMTP DATA command. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From wmills@yahoo-inc.com Mon Aug 5 21:00: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 53B3D21F8BFD for ; Mon, 5 Aug 2013 21:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.598 X-Spam-Level: X-Spam-Status: No, score=-18.598 tagged_above=-999 required=5 tests=[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 xbs1tKW0g9fh for ; Mon, 5 Aug 2013 21:00:37 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8825621F94FF for ; Mon, 5 Aug 2013 21:00:37 -0700 (PDT) Received: from BF1-EX10-CAHT01.y.corp.yahoo.com (bf1-ex10-caht01.corp.bf1.yahoo.com [10.74.209.56]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r76408wT008698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 5 Aug 2013 21:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1375761610; bh=PBRPN506U2A72UxUEId2dWp0z+qSs75GliwTm2Qg+hU=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=AwUhLMb/WPkXsEqRGIEY7tkmdhHWqQg09FizHvGqMpzXE3/ZFIShRdh9ETybcGsYR aOjNfPj5eH+ZRxOK5lExY+Ge2njx/qtkKLSlZmQHFBThHN73jjiLH5N9rSFFP/j7+P KwyZ+8fVvoLWeMPAhmBNsYVSlu1BhnlJj0c8seew= Received: from omp1015.mail.ne1.yahoo.com (98.138.86.157) by BF1-EX10-CAHT01.y.corp.yahoo.com (10.74.209.170) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 6 Aug 2013 00:00:08 -0400 Received: (qmail 94311 invoked by uid 1000); 6 Aug 2013 04:00:07 -0000 Received: (qmail 36530 invoked by uid 60001); 6 Aug 2013 04:00:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1375761607; bh=+PPOE4iJaxN0pu9Ks+5dNqETcaj/nzu/cb7tCYb5HAs=; 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=ZUebczibLGbcO2ZEcUptfTAmLNJvIV39nhu9tO2VNMMdo/+iKDTB1N2d7uqMmCZYZef7FNlPhGMkmEHfZs7ZVoMZsSKmYpoWTvqNaQ4xetYVoYvEiYogZXG9v/pDYcd4kryVpRpw9xDL2fMGCRsmW/rM+180crCXsFBlDe8yeHE= 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=lV8VbGD3CrG8eyR/n1m+Xays2zm8d2Kll7mhpiuThrnJBRPtIj3qI5KJ9ghUT8gJtO9WVfTs4ROqUOenmaQduWt8JeUqM1PvpdI5jn1UR82xFZtnVx1+yaBxMNsiV8IkI+3691LiKS0DHBF8khY6SDXRF9anCAwFIjcOW9nA5gY=; X-YMail-OSG: GL7eWJEVM1lUTvlGsoHIZEnlBcPYfQmB4I7Ar6amPTP9SkK hxjmYF2kVyu0iAuI5YSsi1OgF5ckXGq.ARXZcE7t.HgcTOJ.GKiagx_wTk1I Z0QBAplG5J0mKpgD7VFswLS7zCxJwaPryuJ6ysTRMfHijWsjRAPrDmY0vx9N 0PTb3UZ9qREKNJebZoprZnZ5BGvM4FgbQ.NVCnb2rXh6fFc5fza9JsS4V5OQ KDwAmeDA1UA1_if1_HNaAS8Km4oybE1sa05yu0eeyJVI6QVMEKSsgTg32ME2 MRt59Ab7iAGczuLzNI.OaBC70 Received: from [209.131.62.115] by web125604.mail.ne1.yahoo.com via HTTP; Mon, 05 Aug 2013 21:00:07 PDT X-Rocket-MIMEInfo: 002.001, WWVhaCwgdGhhdCdzIGdvbm5hIG1ha2UgaXQgbW9yZSBpbnRlcmVzdGluZy7CoCBJcyB0aGVyZSBhbnkgb3RoZXIgY2FzZSB3aGVyZSB5b3UgbWlnaHQgZGVsaXZlciB0byBvbmUgcmVjaXBpZW50IGFmdGVyIHRoZSBEQVRBIGNvbW1hbmQgYnV0IG5vdCBhbm90aGVyIGZvciB0aGUgc2FtZSBtZXNzYWdlP8KgIENhbid0IGZpdCB0aGUgbWVzc2FnZSBpbiB0aGUgdXNlcidzIHJlbWFpbmluZyBxdW90YSBwZXJoYXBzPwoKCsKgCi1iaWxsCgoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCldpbGxpYW0BMAEBAQE- X-Mailer: YahooMailWebService/0.8.152.567 References: <52002DAC.9040702@dcrocker.net> <20130806015512.25482.qmail@joyce.lan> <1375759955.54940.YahooMailNeo@web125604.mail.ne1.yahoo.com> <52007215.6020400@dcrocker.net> Message-ID: <1375761607.30738.YahooMailNeo@web125604.mail.ne1.yahoo.com> Date: Mon, 5 Aug 2013 21:00:07 -0700 From: Bill Mills To: "dcrocker@bbiw.net" In-Reply-To: <52007215.6020400@dcrocker.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-685807438-1495402846-1375761607=:30738" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 761610002 Cc: John Levine , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field 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: Tue, 06 Aug 2013 04:00:42 -0000 ---685807438-1495402846-1375761607=:30738 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yeah, that's gonna make it more interesting.=A0 Is there any other case whe= re you might deliver to one recipient after the DATA command but not anothe= r for the same message?=A0 Can't fit the message in the user's remaining qu= ota perhaps?=0A=0A=0A=A0=0A-bill=0A=0A=0A=0A-------------------------------= -=0AWilliam J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A=0A=0A____________________= ____________=0A From: Dave Crocker =0ATo: Bill Mills =0ACc: John Levine ; "apps-discuss@ietf= .org" ; "dcrocker@bbiw.net" =0AS= ent: Monday, August 5, 2013 8:48 PM=0ASubject: Re: [apps-discuss] call for = adoption: draft-wmills-rrvs-header-field=0A =0A=0AOn 8/6/2013 5:32 AM, Bill= Mills wrote:=0A> An RRVS header applies only for the recipient specified i= n the header,=0A> and affects delivery only to that recipient.=A0 So the w= ay this will=0A> workis you need an RVS header for each recipient the sende= r wants to=0A> affect with RRVS.=0A=0A=0AI suspect that a failure for one n= eeds to be a failure for all, at the =0Aend of the SMTP DATA command.=0A=0A= d/=0A=0A-- =0ADave Crocker=0ABrandenburg InternetWorking=0Abbiw.net ---685807438-1495402846-1375761607=:30738 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yeah, tha= t's gonna make it more interesting.  Is there any other case where you= might deliver to one recipient after the DATA command but not another for = the same message?  Can't fit the message in the user's remaining quota= perhaps?

 
-bill

--------------------------------
William J. Mills
"Paranoid" Ya= hoo!


= From: Dave Crocker <dhc@dcrocker= .net>
To: Bill Mill= s <wmills@yahoo-inc.com>
Cc= : John Levine <johnl@taugh.com>; "apps-discuss@ietf.org" &= lt;apps-discuss@ietf.org>; "dcrocker@bbiw.net" <dcrocker@bbiw.net>=
Sent: Monday, August= 5, 2013 8:48 PM
Subject:<= /b> Re: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field

On 8/6/2013 5:32 AM, Bi= ll Mills wrote:
> An RRVS header applies only for the recipient speci= fied in the header,
> and affects delivery only to that recipient.&nb= sp; So the way this will
> workis you need an RVS header for each re= cipient the sender wants to
> affect with RRVS.


I suspect = that a failure for one needs to be a failure for all, at the
end of the SMT= P DATA command.

d/

--
Dave Crocker
Brandenburg Interne= tWorking
bbiw.net


---685807438-1495402846-1375761607=:30738-- From superuser@gmail.com Mon Aug 5 22:47: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 ED9FA21F9E1A for ; Mon, 5 Aug 2013 22:47:21 -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, 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 gZ0BYd1ettnf for ; Mon, 5 Aug 2013 22:47:21 -0700 (PDT) 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 3D5E621F9DF6 for ; Mon, 5 Aug 2013 22:47:21 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id hi8so2296270wib.9 for ; Mon, 05 Aug 2013 22:47:20 -0700 (PDT) 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=8h8ZLHG+XTltBKNc5RKrUcqa0ZeGhq/qNF4N7NEESy0=; b=Vp82apYkNmzkQQddIK38yghWK0ToucG5ks6zGw8BbbClFv/jyuKmN2BK53NiVmmJRk 5AMYzYnqIoaTchr7sfB+BSHpqsgr3j/WAqU2dn3YxWGUxwiHaW2M4+u30faUdw4pKKHl fyOz61WcmP3bVor6I2eR/GPY9Lwc80AN/e3/QyBEUWv3Hx0QcerMuKfFeiVdGnYmZcyZ /fu/+bIkZv4/jwa3/GaQOpWjLCuyerMQ7I9Fpvbe6vfsChZeLA+FmT0nTZfBOgFVYVaz 8uMONbUiVv3I8Z0eHVUDQQ3tmTo8V8I/QdlLVbdZ2X8raawMrhDtgTovElGOwROp4GE0 Hdbg== MIME-Version: 1.0 X-Received: by 10.180.89.231 with SMTP id br7mr745024wib.19.1375768040427; Mon, 05 Aug 2013 22:47:20 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Mon, 5 Aug 2013 22:47:20 -0700 (PDT) In-Reply-To: <52007215.6020400@dcrocker.net> References: <52002DAC.9040702@dcrocker.net> <20130806015512.25482.qmail@joyce.lan> <1375759955.54940.YahooMailNeo@web125604.mail.ne1.yahoo.com> <52007215.6020400@dcrocker.net> Date: Mon, 5 Aug 2013 22:47:20 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=e89a8f3ba25557d52604e340f57c Cc: John Levine , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field 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, 06 Aug 2013 05:47:22 -0000 --e89a8f3ba25557d52604e340f57c Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 5, 2013 at 8:48 PM, Dave Crocker wrote: > > I suspect that a failure for one needs to be a failure for all, at the end > of the SMTP DATA command. > > Right. Once upon a time there was an SMTP extension proposed that would allow different status to be returned for each recipient in reply to the DATA command, but it never made it to publication. I think there were a few trial implementations, however. -MSK --e89a8f3ba25557d52604e340f57c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 5, 2013 at 8:48 PM, Dave Crocker <dhc@dcrocker= .net> wrote:

I suspect that a failure for one needs to be a failure for all, at the end = of the SMTP DATA command.


Right.=A0 Once upon a time there was an SMTP extension pr= oposed that would allow different status to be returned for each recipient = in reply to the DATA command, but it never made it to publication.=A0 I thi= nk there were a few trial implementations, however.

-MSK

--e89a8f3ba25557d52604e340f57c-- From alexey.melnikov@isode.com Tue Aug 6 02:54: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 4E24C21F9D87 for ; Tue, 6 Aug 2013 02:54:00 -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 Y2EHl+1kbq-f for ; Tue, 6 Aug 2013 02:53:59 -0700 (PDT) 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 C4D3321F9D4C for ; Tue, 6 Aug 2013 02:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1375782831; d=isode.com; s=selector; i=@isode.com; bh=wCKcF88qxA++P+lj0w9W/wdCrVkFWcl3wiIZDL493FQ=; 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=uNi4Iz/9C0WZjDTW8Fo2QowzZgNf/CgcHD5c6ge14JjlWjwkeB20But9Sea2/p7Hqn+VtP ouZxwlNpIhPC1p+SXXqWJYfHoq6bwdK0pNMLJZaOCfBUIw4OHOBthpzBG0CPhl3UL/0itu heI9jQTcmkAw1U2V70tlT75QVdLQudQ=; Received: from [172.24.101.47] ((unknown) [193.104.215.11]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 6 Aug 2013 10:53:51 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <5200C7AE.9020300@isode.com> Date: Tue, 06 Aug 2013 10:53:50 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Salvatore Loreto References: <51FB802F.1090709@ericsson.com> In-Reply-To: <51FB802F.1090709@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field 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, 06 Aug 2013 09:54:01 -0000 On 02/08/2013 10:47, Salvatore Loreto wrote: > > This is a call for adoption for draft-wmills-rrvs-header-field [1] > > There is a pretty good thread going on apps-discuss [2] > that shows an interest within this working group about this work, > and it appears to be material that falls within our charter. > > Accordingly, we'll adopt this as a working group item within the next > couple > of weeks unless there's objection to such processing. > > /Salvatore I am not entirely convinced how useful this end up being (in particular if deployments of this are not widespread), but if this work is to be done, I prefer if it is done in the AppsaWG. So "+1". > [1] http://www.ietf.org/id/draft-wmills-rrvs-header-field-00.txt > [2] > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10013.html > From vesely@tana.it Tue Aug 6 05:53: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 1C19B21F9371 for ; Tue, 6 Aug 2013 05:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 BNuZ9Yr4GU4O for ; Tue, 6 Aug 2013 05:53:35 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8A81E21F8B4E for ; Tue, 6 Aug 2013 05:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1375793613; bh=8noOqbxweVo/HwPI2WONg2y5glIRDPoN3a7hGkq4Jnc=; l=868; h=Date:From:To:References:In-Reply-To; b=LlapjZur0gcoxm1/NIkHFEazul5lQrcaU4ON15tv6qkHsogCL3w/uowOGx+RWBPdh l8Bj/3LngnlbuWoFAqfNASxyKe4LUw/PMvBoNUIaGr/wEzuQ7/dHD8mDOj1hNJJbvO Np716KDfcWh6rm5jaZNrME19xhbDQRDhKBi/5aLU= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 06 Aug 2013 14:53:33 +0200 id 00000000005DC039.000000005200F1CD.000059F2 Message-ID: <5200F1CD.5060005@tana.it> Date: Tue, 06 Aug 2013 14:53:33 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130704 Icedove/17.0.7 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <52002DAC.9040702@dcrocker.net> <20130806015512.25482.qmail@joyce.lan> <1375759955.54940.YahooMailNeo@web125604.mail.ne1.yahoo.com> <52007215.6020400@dcrocker.net> <1375761607.30738.YahooMailNeo@web125604.mail.ne1.yahoo.com> In-Reply-To: <1375761607.30738.YahooMailNeo@web125604.mail.ne1.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field 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, 06 Aug 2013 12:53:40 -0000 On Tue 06/Aug/2013 06:00:07 +0200 Bill Mills wrote: > *From:* Dave Crocker >> >> I suspect that a failure for one needs to be a failure for all, at the >> end of the SMTP DATA command. > > Yeah, that's gonna make it more interesting. Is there any other > case where you might deliver to one recipient after the DATA > command but not another for the same message? Can't fit the > message in the user's remaining quota perhaps? I think it is quite common, to avoid backscatter, to split recipients so as to insulate those who are likely to reject after data from those who will accept. That has to be done in advance, by replying 4xx to the recipients of the second group. Just like LMTP, that technique is based on the envelop. Ned's comments will have to be addressed if the I-D is adopted, so +1 for adoption from me as well. From johnl@iecc.com Tue Aug 6 08:00: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 5688721F9E44 for ; Tue, 6 Aug 2013 08:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.402 X-Spam-Level: X-Spam-Status: No, score=-110.402 tagged_above=-999 required=5 tests=[AWL=0.797, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.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 pcM3msPSdxCm for ; Tue, 6 Aug 2013 08:00:19 -0700 (PDT) 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 D582A21F9D4A for ; Tue, 6 Aug 2013 08:00:18 -0700 (PDT) Received: (qmail 30260 invoked from network); 6 Aug 2013 15:00:16 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Aug 2013 15:00:16 -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=52010f80.xn--3zv.k1308; i=johnl@user.iecc.com; bh=nKWxFkFKMaYtLoV4d7QSLmiiBtMJCUMk4vy6BY6LJok=; b=B13nvO+TcFpIg/0VuOjmACnBh1ipOZnAIfWv9IISpZxFS++NvH/O48hsAzxy8VvDqvZa5JRyMlERkaoimdp8rLtmlXqwXCND0snoopJvnFnzmzCCOMfCvqjC1TTLq8Bred0ZQKP2kZppIzWkDGzBhw+Kuy+fGtmXpp7beBDMWvoYF2GiSFeLgcXbaAoyrVpkBqTARGj+fIUxLrX8sYAyHtBNRVx/j0kdejsyT47Y+E5Q0MvWM2YkC/bfr5hGtZoD 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=52010f80.xn--3zv.k1308; olt=johnl@user.iecc.com; bh=nKWxFkFKMaYtLoV4d7QSLmiiBtMJCUMk4vy6BY6LJok=; b=oDKCYXn2YSjB2Ksqb3/u56PSk6CmwHXLbhnh4RNLHIp1vrNoNtqLYqU4ZFB74ttWCOx5OoN5/RF8jzMeiCk+HEzjjJ1vIVDuMaRgTbRn4YqMYFPLNM6ZLT4tZhQOSAsok3H89FzRyV5A+f1FOvQmRfq80kaE+vYMcXumuZhOmZsCb8Ry3DBBFCr9ZVKiZEPkkjy1nrYm3iG8Y0SdPNHGOJ+9B2StjZFddQFwbZrOMRr+UjkvDgPUWcdDssI0hHPS Date: 6 Aug 2013 14:59:54 -0000 Message-ID: <20130806145954.35360.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <52007215.6020400@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: dcrocker@bbiw.net Subject: Re: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field 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, 06 Aug 2013 15:00:24 -0000 >I suspect that a failure for one needs to be a failure for all, at the >end of the SMTP DATA command. This is the swamp I was alluding to. If a sender puts two rrvs headers on a message, and the recipient system rejects at the end of data, there's no way to tell which of them was the problem, short of implementing SMTP extensions that people have considered and declined to implement before. I suppose you could then split the message and send it separately to each and see what happens, but that seems like more complication than it's worth. The main application for this hack is transaction messages which by their nature rarely go to more than one address, so it's perfectly reasonable to say that the results of using more than one rrvs header are indeterminate, so don't do 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 From wmills@yahoo-inc.com Tue Aug 6 08:14: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 2319F21F9D0E for ; Tue, 6 Aug 2013 08:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.598 X-Spam-Level: X-Spam-Status: No, score=-18.598 tagged_above=-999 required=5 tests=[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 5g0CtE8bnHJx for ; Tue, 6 Aug 2013 08:13:59 -0700 (PDT) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by ietfa.amsl.com (Postfix) with ESMTP id B60F021F9D0A for ; Tue, 6 Aug 2013 08:13:56 -0700 (PDT) Received: from GQ1-EX10-CAHT04.y.corp.yahoo.com (gq1-ex10-caht04.corp.gq1.yahoo.com [10.73.118.83]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r76FDIEn024021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 6 Aug 2013 08:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1375801999; bh=ioMtWuKIrF3nK0OjoG9oMHm2BZchz9gtzakTXZJsuf4=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=a/naGfyu7hGaDqHNBV/3V+BVCwSMK3+9WktTjPAaSm6+FRAydcbtx//WglINlC0U7 NUnKiu0MJPBzCKcwW5RHq4DKUb70KzsjUp4NRISgEyCOOUW/k9xfNTz0E6US649CD1 gSdIi/1Myutovkrw+PhWYHE+CWMjlVRrEZNl6uVE= Received: from omp1038.mail.ne1.yahoo.com (98.138.88.238) by GQ1-EX10-CAHT04.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 6 Aug 2013 08:13:18 -0700 Received: (qmail 479 invoked by uid 1000); 6 Aug 2013 15:13:17 -0000 Received: (qmail 25735 invoked by uid 60001); 6 Aug 2013 15:13:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1375801997; bh=8cZ2B2JJk9JMDDyXaULBtLvDMVF9wn9ylVJaxUvnCe4=; 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=II69AmgU/nfm1wmOvenoencYxI0KPnS4/VBoC4Iwtm/nyGTNv1Ketmc4xoXTRQFYw3miOtqsHe40KbmtkDkJ77toK7fgC5XYBN+NxPdKdPAj8SD3YBQ1TJUlnZD3NSPNyiS95IVV1UtyH43FxW2Yw1KVH8hw0x3IP3todKgqmnE= 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=WCQV9kIm1LAIa/6Cp4fgUs7ija7rPYN2vPFjnEaLk1n/EakswxNLuF2wNc/BSiXuMBMTgYcQ2cbaeoAMfczjECEwlHeDkCUp9R0aqYf08zpRtZp7cmnhIuh9p0tmh2JFeOz8kRRT/hA41vHJgBU7AnNCDhd0rJ/i/ytCQ3aJMOQ=; X-YMail-OSG: cDzJ1LQVM1m1zrNxZBX6wwdxZzRx9JGq7VclwrJVfrASUY1 IoYJNHYqgBmB.V_w4ouEYOP48KeWhmg6CHAYHdx08XNnt3Z.hwNbJAkpZgyF xYNoMbjkg5OYDdguk.HOWQwAPmZAzDFZlWDQcAo_TL_kEnp2YJu5s980DE1g ZKsW5DJyVRV17BDowUr0n6.wyEXGHlKwRKaEFapZQoYVZ.QwSg5kLq1kGEhZ Fmx5juafFuFet._5JH_VL6HprxBXRvo8Bmh.v6aFLs6.Cp6LxR9UHxa5V_Ce r27Xw8ZgJjeVazCXi0y3DzG8Z Received: from [209.131.62.115] by web125602.mail.ne1.yahoo.com via HTTP; Tue, 06 Aug 2013 08:13:16 PDT X-Rocket-MIMEInfo: 002.001, RG9lcyB0aGlzIHByb3Blcmx5IGNhcHR1cmUgd2hhdCB5b3UncmUgc2F5aW5nLCAiVGhlIHJlc3VsdHMgb2YgdXNpbmcgbW9yZSB0aGFuIG9uZSBSUlZTIGhlYWRlciBhcmUgaW5kZXRlcm1pbmF0ZSBzaW5jZSB0aGVyZSBpcyBubyB3YXkgdG8gcmV0dXJuIG1haWxib3ggc3BlY2lmaWMgZGVsaXZlcnkgcmVzdWx0cyBhZnRlciB0aGUgREFUQSBjb21tYW5kLCBmb3IgdGhhdCByZWFzb24gdXNlIG9mIG11bHRpcGxlIFJSVlMgaXMgTk9UIFJFQ09NTUVOREVELiI_CgoKwqAKLWJpbGwKCgoKLS0tLS0tLS0tLS0tLS0BMAEBAQE- X-Mailer: YahooMailWebService/0.8.152.567 References: <52007215.6020400@dcrocker.net> <20130806145954.35360.qmail@joyce.lan> Message-ID: <1375801996.24654.YahooMailNeo@web125602.mail.ne1.yahoo.com> Date: Tue, 6 Aug 2013 08:13:16 -0700 From: Bill Mills To: John Levine , "apps-discuss@ietf.org" In-Reply-To: <20130806145954.35360.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1088529044-1119762348-1375801996=:24654" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 801999000 Cc: "dcrocker@bbiw.net" Subject: Re: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field 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: Tue, 06 Aug 2013 15:14:04 -0000 ---1088529044-1119762348-1375801996=:24654 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does this properly capture what you're saying, "The results of using more t= han one RRVS header are indeterminate since there is no way to return mailb= ox specific delivery results after the DATA command, for that reason use of= multiple RRVS is NOT RECOMMENDED."?=0A=0A=0A=A0=0A-bill=0A=0A=0A=0A-------= -------------------------=0AWilliam J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A= =0A=0A________________________________=0A From: John Levine =0ATo: apps-discuss@ietf.org =0ACc: dcrocker@bbiw.net =0ASent: Tuesday, A= ugust 6, 2013 7:59 AM=0ASubject: Re: [apps-discuss] call for adoption: draf= t-wmills-rrvs-header-field=0A =0A=0A>I suspect that a failure for one needs= to be a failure for all, at the =0A>end of the SMTP DATA command.=0A=0AThi= s is the swamp I was alluding to.=0A=0AIf a sender puts two rrvs headers on= a message, and the recipient=0Asystem rejects at the end of data, there's = no way to tell which of=0Athem was the problem, short of implementing SMTP = extensions that=0Apeople have considered and declined to implement before.= =A0 I suppose=0Ayou could then split the message and send it separately to = each and=0Asee what happens, but that seems like more complication than it'= s=0Aworth.=0A=0AThe main application for this hack is transaction messages = which by=0Atheir nature rarely go to more than one address, so it's perfect= ly=0Areasonable to say that the results of using more than one rrvs header= =0Aare indeterminate, so don't do that.=0A=0ARegards,=0AJohn Levine, johnl@= iecc.com, Primary Perpetrator of "The Internet for Dummies",=0APlease consi= der the environment before reading this e-mail. http://jl.ly=0A=0A_________= ______________________________________=0Aapps-discuss mailing list=0Aapps-d= iscuss@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/apps-discuss ---1088529044-1119762348-1375801996=:24654 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Does this= properly capture what you're saying, "The results of using more than one R= RVS header are indeterminate since there is no way to return mailbox specif= ic delivery results after the DATA command, for that reason use of multiple= RRVS is NOT RECOMMENDED."?

 
-bill


--------------------------------
William J. Mill= s
"Paranoid" Yahoo!


From: John Lev= ine <johnl@taugh.com>
To: apps-discuss@ietf.org
C= c: dcrocker@bbiw.net
= Sent: Tuesday, August 6, 2013 7:59 AM
Subject: Re: [apps-discuss] call for adoption: d= raft-wmills-rrvs-header-field

>I suspect that a failure for one needs to be a failure for all= , at the
>end of the SMTP DATA command.

This is the swamp I w= as alluding to.

If a sender puts two rrvs headers on a message, and = the recipient
system rejects at the end of data, there's no way to tell = which of
them was the problem, short of implementing SMTP extensions tha= t
people have considered and declined to implement before.  I suppose
you could then split the message and send it separately to each= and
see what happens, but that seems like more complication than it'sworth.

The main application for this hack is transaction messages = which by
their nature rarely go to more than one address, so it's perfec= tly
reasonable to say that the results of using more than one rrvs heade= r
are indeterminate, so don't do that.

Regards,
John Levine, <= a ymailto=3D"mailto:johnl@iecc.com" href=3D"mailto:johnl@iecc.com">johnl@ie= cc.com, Primary Perpetrator of "The Internet for Dummies",
Please co= nsider the environment before reading this e-mail. http://jl.ly

_______________________________= ________________
apps-discuss mailing list
apps-discuss@ietf.o= rg
https://www.ietf.org/mailman/listinfo/apps-discuss

---1088529044-1119762348-1375801996=:24654-- From johnl@taugh.com Tue Aug 6 08:16: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 542B621F9C17 for ; Tue, 6 Aug 2013 08:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGx9rnfwenuA for ; Tue, 6 Aug 2013 08:16:32 -0700 (PDT) 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 EFA3A21F9D0A for ; Tue, 6 Aug 2013 08:16:30 -0700 (PDT) Received: (qmail 43246 invoked from network); 6 Aug 2013 15:16:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=a8ed.5201134e.k1308; bh=YpoiVINYTsmYoMtE3OaY4qjsOCay3OXf4u8HS9JU/ZA=; b=NsUyyR+ckIf496zsL+EFMrIv0497LNtSnpfKciR2iY0r0nLtozdK9K9zWMW8UlyvZ+Ndza2VohODJlfEi60WJytOtZKF5wz3YJB90i9jSJkV4gujnV+fdRA6CXDMvnoUGydQmlw+bwLDSKhAestXB2ksbExAiOJSOOsAWE/u21fx+8vyYxpEjdH0LSlTWo8y3RuAmWNRtbSsamz84nwvm7FE6IPqH+YjotQh2pfrnghiZ719qePMEYQB2+O+rSKh DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=a8ed.5201134e.k1308; bh=YpoiVINYTsmYoMtE3OaY4qjsOCay3OXf4u8HS9JU/ZA=; b=MzUI7G1bzVi22DiF4kpy8T+VcmNWLCOuusHEeqee6JBo+T2iN1N+52PZiyx0CmH2YWcplUUR3uQNrSDuBjMiqv5KQyBHijWNAVxs1VeqvMP4ZbOWk5240X6OoF1xFEwquy/gxBFc5spizpU7bua24KPOj0FvoyG6MBvMCrVmZxPw/M64M0AluZ3EkhTFEea86Eu6UuMFsxBNM2vIgZIMcB5zhwdad/Nlt4XAXAoSlcCK4Oj3hqrZUBT8h3Ol5s8B Received: (ofmipd 127.0.0.1); 6 Aug 2013 15:16:08 -0000 Date: 6 Aug 2013 11:16:30 -0400 Message-ID: From: "John R Levine" To: "Bill Mills" In-Reply-To: <1375801996.24654.YahooMailNeo@web125602.mail.ne1.yahoo.com> References: <52007215.6020400@dcrocker.net> <20130806145954.35360.qmail@joyce.lan> <1375801996.24654.YahooMailNeo@web125602.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-1806316578-1375802190=:34740" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field 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, 06 Aug 2013 15:16:33 -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-1806316578-1375802190=:34740 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT > Does this properly capture what you're saying, "The results of using > more than one RRVS header are indeterminate since there is no way to > return mailbox specific delivery results after the DATA command, for > that reason use of multiple RRVS is NOT RECOMMENDED."? Close enough. R's, John >> I suspect that a failure for one needs to be a failure for all, at the >> end of the SMTP DATA command. > > This is the swamp I was alluding to. > > If a sender puts two rrvs headers on a message, and the recipient > system rejects at the end of data, there's no way to tell which of > them was the problem, short of implementing SMTP extensions that > people have considered and declined to implement before.  I suppose > you could then split the message and send it separately to each and > see what happens, but that seems like more complication than it's > worth. > > The main application for this hack is transaction messages which by > their nature rarely go to more than one address, so it's perfectly > reasonable to say that the results of using more than one rrvs header > are indeterminate, so don't do 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 > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-1806316578-1375802190=:34740-- From ned.freed@mrochek.com Tue Aug 6 10:01: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 1F8DA21F9F9D for ; Tue, 6 Aug 2013 10:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.615, 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 lPR+37GMr135 for ; Tue, 6 Aug 2013 10:01:23 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 880D221F9DA1 for ; Tue, 6 Aug 2013 10:01:23 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OWW4WJ0I4G001ETJ@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 6 Aug 2013 09:56:20 -0700 (PDT) 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 <01OWVWVG24QO00004R@mauve.mrochek.com>; Tue, 6 Aug 2013 09:56:17 -0700 (PDT) Message-id: <01OWW4WH6U0S00004R@mauve.mrochek.com> Date: Tue, 06 Aug 2013 09:53:44 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 06 Aug 2013 10:53:50 +0100" <5200C7AE.9020300@isode.com> References: <51FB802F.1090709@ericsson.com> <5200C7AE.9020300@isode.com> To: Alexey Melnikov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1375808180; bh=QL9qEbBurIXDNmO2KT8fyojheyJTaVctr3ZthXnOFMA=; h=MIME-version:Content-type:Cc:Message-id:Date:From:Subject: In-reply-to:References:To; b=TT4eFZWPQawRZ4JEI+xteH4yYkbpudtx+EZYqPiw1ADJ0BGd6uQOkgKX5s905RnUO cBy7M+L4cRxL+4Y9BBqIRrvOeFqCt56kQ5SqfrLOXafNexpkcu16fOw8AXwM4PBwdQ FM4PBF5DHQ874Yz8jflIRiX24/Hw3yi9EDUiZ0Ms= Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field 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, 06 Aug 2013 17:01:28 -0000 > On 02/08/2013 10:47, Salvatore Loreto wrote: > > > > This is a call for adoption for draft-wmills-rrvs-header-field [1] > > > > There is a pretty good thread going on apps-discuss [2] > > that shows an interest within this working group about this work, > > and it appears to be material that falls within our charter. > > > > Accordingly, we'll adopt this as a working group item within the next > > couple > > of weeks unless there's objection to such processing. > > > > /Salvatore > I am not entirely convinced how useful this end up being (in particular > if deployments of this are not widespread), but if this work is to be > done, I prefer if it is done in the AppsaWG. So "+1". Indeed. I've already noted the cost-benefit asymmetry in a previous note. Unfortunately the biggst cost is likely going to be making the necessary account information available to the email system. But I'm willing to code it and see if anyone uses it. And appsawg seems a good a place as any to do the work. Ned From ned.freed@mrochek.com Tue Aug 6 10:21: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 40F6F21F9FF7 for ; Tue, 6 Aug 2013 10:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.410, 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 4-ZgR04JXyux for ; Tue, 6 Aug 2013 10:21:40 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id EB52F21F9D34 for ; Tue, 6 Aug 2013 10:21:39 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OWW5LKCXXS00168X@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 6 Aug 2013 10:16:32 -0700 (PDT) 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 <01OWVWVG24QO00004R@mauve.mrochek.com>; Tue, 6 Aug 2013 10:16:27 -0700 (PDT) Message-id: <01OWW5LHXNUC00004R@mauve.mrochek.com> Date: Tue, 06 Aug 2013 10:06:58 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 06 Aug 2013 14:59:54 +0000" <20130806145954.35360.qmail@joyce.lan> References: <52007215.6020400@dcrocker.net> <20130806145954.35360.qmail@joyce.lan> To: John Levine DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1375809391; bh=xzg4fZU+KWs/YqEzKqJFsdhpgP2gbhY3YFVd2stPCXM=; h=MIME-version:Content-type:Cc:Message-id:Date:From:Subject: In-reply-to:References:To; b=ccntCoSGY53Jz1zpDO7dQQrm20gpt2JLQoR1EboKaI+j0JVvclO94I0Gxt809e3n+ YpUO38gRyCoj2mTaYXnxhFDGlrNa2rzCaHvHtIuIvR0NGaDj4jZRBMSWP3KNZwoY0x Z6DcIdvZ1oxuz8SBED8+Cnxl+x0TM8R7KqVIgUIQ= Cc: dcrocker@bbiw.net, apps-discuss@ietf.org Subject: Re: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field 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, 06 Aug 2013 17:21:47 -0000 > >I suspect that a failure for one needs to be a failure for all, at the > >end of the SMTP DATA command. Nonsense. This would be fundamentally changing the semantics of email - you're essentially saying that the presence of this field changes the envelope to an all-or-nothing deal. We went through this in tedious detail back in the days of Sieve ereject; let's please not repeat that discussion. SMTP servers are *required* to be able to handle a mixture of recipient address states at the end of DATA; if this includes partial-accept and partial-reject you have to generate DSNs. This is reality; suck it up and move on. > This is the swamp I was alluding to. > If a sender puts two rrvs headers on a message, and the recipient > system rejects at the end of data, there's no way to tell which of > them was the problem, short of implementing SMTP extensions that > people have considered and declined to implement before. I suppose > you could then split the message and send it separately to each and > see what happens, but that seems like more complication than it's > worth. > The main application for this hack is transaction messages which by > their nature rarely go to more than one address, so it's perfectly > reasonable to say that the results of using more than one rrvs header > are indeterminate, so don't do that. On the contrary, it isn't reasonable at all. A mechanism like this that causes delivery failures requires a crisp and complete specification. Failure to do that should disqualify this from the standards track. You can say that having more than one means all of them MUST be ignored, or you can specify how multiple headers can be handled. I'll also note that the multiplicity of this field has zero effect on the need to generate DSNs. A single field could apply to one recipient and not another. Ned From wmills@yahoo-inc.com Tue Aug 6 10:35: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 3C0D221F9B53 for ; Tue, 6 Aug 2013 10:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.598 X-Spam-Level: X-Spam-Status: No, score=-18.598 tagged_above=-999 required=5 tests=[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 qwup+XNF2c4j for ; Tue, 6 Aug 2013 10:35:13 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1590221F99E1 for ; Tue, 6 Aug 2013 10:34:53 -0700 (PDT) Received: from BF1-EX10-CAHT09.y.corp.yahoo.com (bf1-ex10-caht09.corp.bf1.yahoo.com [10.74.209.198]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r76HXwEq026331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 6 Aug 2013 10:33:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1375810439; bh=EOAp1CEoFayhAljXhN5EzqxHmGSVAs2pPinS361k9NU=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=cZxeOKMgR9U2cxtyGneEHhK/u90Lx2eTKUAqdy9O1PAOCG9qkSu1e9/LC2kdPRiHh q1WYlPGfjMGheW/mcJ5NVPXlgxQHZo7aIoRDRv//ay9Tix20eUo0lpDlETG4s2prui h47ApoAvxis8QBDaiv6SqZ5SReyz1ZPkC499UOag= Received: from omp1034.mail.ne1.yahoo.com (98.138.88.234) by BF1-EX10-CAHT09.y.corp.yahoo.com (10.74.209.170) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 6 Aug 2013 13:33:57 -0400 Received: (qmail 94052 invoked by uid 1000); 6 Aug 2013 17:33:57 -0000 Received: (qmail 72351 invoked by uid 60001); 6 Aug 2013 17:33:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1375810437; bh=oeAoTl4RhXJWKX8ngro+KJr8vCycSoYVNxJk6EcZsGM=; 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=Zz3SgGjdZulCbMHnIb6DEgeTI3WE/cosdA88SU3Pl3WLlstxq08l4me1qX7OC0Dl4sk0rYP3pafRIABLJojz4AX/fzHlijly6mD63+F3DXv7+WsIPTXbQpF0Cb1C7liq1AJ5v/NKFIdNdP6obndsbLDwKpaZrBtgbu1XcjuP0BU= 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=smT9OykfmlJy+ZpO3R9Th2PmFLsxV9HtDndsMHHr1CictWoY3ryumNWGuiLfaMynT8YUYmyW/XkJzJbGw+dW4xHFNBPM8rNjJmqVs2KVMvyDJ5xuvfwqawNgYQiXm8E+gmpqZzqv2JIuzQIbpQ4ORSoRpHp24jBkAoQn8gd2Kts=; X-YMail-OSG: Pem77IoVM1lF8lsGnlgXfQft2Gkf_OGtoT33PDqYliCavqV K37Qtw9SjaXcUQ82ED0qsO7JsvwPrTmfzMZF4u4OT1tvwXrLSMNVsw7F9u4D G7muxIkPa1wgX6XlK5CojLJf8aXt6ypVibwEtH5.YAENSZcMkhYqGtgLJZeG hMKglgpZ6w91ywzWKbXwr8wqtLoA63q3qAHd_pvQCmPTYMrouZPUtHfjAKar N3J9W.fnDgetE2fVpSoEagl5mJWAL33uY5mbY5bRAibOMyNJANqflCQT3AvK .R9gguB7ZoktC9gkquRw- Received: from [209.131.50.178] by web125604.mail.ne1.yahoo.com via HTTP; Tue, 06 Aug 2013 10:33:57 PDT X-Rocket-MIMEInfo: 002.001, V2Ugd2VyZSBob3BpbmcgZm9yIGltbWVkaWF0ZSBmZWVkYmFjaywgc291bmRzIGxpa2Ugd2UgbWF5IG5lZWQgdG8gZGlzY3VzcyBEU05zIGluIHRoZSBkcmFmdCB0aGVuLsKgIENhbiB3ZSBnaXZlIGFueSBndWlkYW5jZSB0aGF0IGRpcmVjdCBmZWVkYmFjayBpcyBwcmVmZXJyZWQ_CgoKwqAKLWJpbGwKCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KV2lsbGlhbSBKLiBNaWxscwoiUGFyYW5vaWQiIFlhaG9vIQoKCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206IE5lZCABMAEBAQE- X-Mailer: YahooMailWebService/0.8.152.567 References: <52007215.6020400@dcrocker.net> <20130806145954.35360.qmail@joyce.lan> <01OWW5LHXNUC00004R@mauve.mrochek.com> Message-ID: <1375810437.43598.YahooMailNeo@web125604.mail.ne1.yahoo.com> Date: Tue, 6 Aug 2013 10:33:57 -0700 From: Bill Mills To: Ned Freed , John Levine In-Reply-To: <01OWW5LHXNUC00004R@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-685807438-2127154194-1375810437=:43598" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 810439002 Cc: "dcrocker@bbiw.net" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field 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: Tue, 06 Aug 2013 17:35:19 -0000 ---685807438-2127154194-1375810437=:43598 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We were hoping for immediate feedback, sounds like we may need to discuss D= SNs in the draft then.=A0 Can we give any guidance that direct feedback is = preferred?=0A=0A=0A=A0=0A-bill=0A=0A=0A=0A--------------------------------= =0AWilliam J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A=0A=0A_____________________= ___________=0A From: Ned Freed =0ATo: John Levine =0ACc: dcrocker@bbiw.net; apps-discuss@ietf.org =0ASent: Tu= esday, August 6, 2013 10:06 AM=0ASubject: Re: [apps-discuss] call for adopt= ion: draft-wmills-rrvs-header-field=0A =0A=0A> >I suspect that a failure fo= r one needs to be a failure for all, at the=0A> >end of the SMTP DATA comma= nd.=0A=0ANonsense. This would be fundamentally changing the semantics of em= ail - =0Ayou're essentially saying that the presence of this field changes = the envelope=0Ato an all-or-nothing deal.=0A=0AWe went through this in tedi= ous detail back in the days of Sieve ereject;=0Alet's please not repeat tha= t discussion. SMTP servers are *required* =0Ato be able to handle a mixture= of recipient address states at the end of=0ADATA; if this includes partial= -accept and partial-reject you have to generate=0ADSNs. =0A=0AThis is reali= ty; suck it up and move on.=0A=0A> This is the swamp I was alluding to.=0A= =0A> If a sender puts two rrvs headers on a message, and the recipient=0A> = system rejects at the end of data, there's no way to tell which of=0A> them= was the problem, short of implementing SMTP extensions that=0A> people hav= e considered and declined to implement before.=A0 I suppose=0A> you could t= hen split the message and send it separately to each and=0A> see what happe= ns, but that seems like more complication than it's=0A> worth.=0A=0A> The m= ain application for this hack is transaction messages which by=0A> their na= ture rarely go to more than one address, so it's perfectly=0A> reasonable t= o say that the results of using more than one rrvs header=0A> are indetermi= nate, so don't do that.=0A=0A=0AOn the contrary, it isn't reasonable at all= . A mechanism like this that causes=0Adelivery failures requires a crisp an= d complete specification. Failure to do=0Athat should disqualify this from = the standards track.=0A=0AYou can say that having more than one means all o= f them MUST be ignored, or you =0Acan specify how multiple headers can be h= andled.=0A=0AI'll also note that the multiplicity of this field has zero ef= fect on the=0Aneed to generate DSNs. A single field could apply to one reci= pient and not=0Aanother.=0A=0A=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 Ned= =0A_______________________________________________=0Aapps-discuss mailing l= ist=0Aapps-discuss@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/apps-di= scuss ---685807438-2127154194-1375810437=:43598 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
We were h= oping for immediate feedback, sounds like we may need to discuss DSNs in th= e draft then.  Can we give any guidance that direct feedback is prefer= red?

 
-bill


=
--------------------------------
William J. Mills
"Paranoid" Yahoo!<= br>


From: Ned Freed <ned.freed@mrochek.com>
To= : John Levine <johnl@taugh.com>
Cc: dcrocker@bbiw.net; apps-discuss@ietf.org Sent: Tuesday, August 6,= 2013 10:06 AM
Subject: Re: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field
=

> >I suspect that a= failure for one needs to be a failure for all, at the
> >end of t= he SMTP DATA command.

Nonsense. This would be fundamentally changing= the semantics of email -
you're essentially saying that the presence o= f this field changes the envelope
to an all-or-nothing deal.

We w= ent through this in tedious detail back in the days of Sieve ereject;
le= t's please not repeat that discussion. SMTP servers are *required*
to b= e able to handle a mixture of recipient address states at the end of
DATA= ; if this includes partial-accept and partial-reject you have to generateDSNs.

This is reality; suck it up and move on.

> This i= s the swamp I was alluding to.

> If a sender puts two rrvs header= s on a message, and the recipient
> system rejects at the end of data= , there's no way to tell which of
> them was the problem, short of im= plementing SMTP extensions that
> people have considered and declined= to implement before.  I suppose
> you could then split the mess= age and send it separately to each and
> see what happens, but that s= eems like more complication than it's
> worth.

> The main a= pplication for this hack is transaction messages which by
> their nat= ure rarely go to more than one address, so it's perfectly
> reasonabl= e to say that the results of using more than one rrvs header
> are indeterminate, so don't do that.


On the contrary, it isn't = reasonable at all. A mechanism like this that causes
delivery failures r= equires a crisp and complete specification. Failure to do
that should di= squalify this from the standards track.

You can say that having more= than one means all of them MUST be ignored, or you
can specify how mul= tiple headers can be handled.

I'll also note that the multiplicity o= f this field has zero effect on the
need to generate DSNs. A single fiel= d could apply to one recipient and not
another.

   = ;             Ned
_________= ______________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

---685807438-2127154194-1375810437=:43598-- From superuser@gmail.com Tue Aug 6 10:43: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 79E6821F9D34 for ; Tue, 6 Aug 2013 10:43:19 -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, 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 73ZNbytVOPDz for ; Tue, 6 Aug 2013 10:43:18 -0700 (PDT) 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 5399F21F9F5C for ; Tue, 6 Aug 2013 10:43:18 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n5so656609wev.28 for ; Tue, 06 Aug 2013 10:43:17 -0700 (PDT) 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=Z7jdRp/lM75S1xd4JxMgqUJAI9TDKbZ40kf2unSlpfU=; b=lDl/sdtw89JVOQOYRD75tB4kebwAXovjRt12QRYsbj7o9xfnEIU1qGQVpLL9b6SmuM uUco8PSHAV4r75Rd0jOkrFtBhnks9Qeej1ULF09U2NssIYDKo72dUpyKTv6qlqMzt8O3 7hcWFbgvWz85z3iqUcwDjVrBtN0KWvdqA7uXhL1tFYQnvjnk+rFEv9m7b5PqZIfeKb+F of9Mj4ckHeeFFvAmG6OfQdcxsm8w8O+Go11fU+w71mDhNZKimQQmeUpswuAeLPkNhWKE 3mwcYdWWRs7zJop4bW2Z53u/OX8GgoTDHxhPJ7MEOfsWYdkol4xpiMdQOOSyvNcYLbRt a0UQ== MIME-Version: 1.0 X-Received: by 10.180.84.196 with SMTP id b4mr1878577wiz.19.1375810997104; Tue, 06 Aug 2013 10:43:17 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Tue, 6 Aug 2013 10:43:16 -0700 (PDT) In-Reply-To: <1375810437.43598.YahooMailNeo@web125604.mail.ne1.yahoo.com> References: <52007215.6020400@dcrocker.net> <20130806145954.35360.qmail@joyce.lan> <01OWW5LHXNUC00004R@mauve.mrochek.com> <1375810437.43598.YahooMailNeo@web125604.mail.ne1.yahoo.com> Date: Tue, 6 Aug 2013 10:43:16 -0700 Message-ID: From: "Murray S. Kucherawy" To: Bill Mills Content-Type: multipart/alternative; boundary=f46d04426e2ac2b7ec04e34af5f6 Cc: John Levine , Ned Freed , "dcrocker@bbiw.net" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field 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, 06 Aug 2013 17:43:19 -0000 --f46d04426e2ac2b7ec04e34af5f6 Content-Type: text/plain; charset=ISO-8859-1 Seems to me that's always the case anyway, is it not? If it is, I don't think we need to say it explicitly. On Tue, Aug 6, 2013 at 10:33 AM, Bill Mills wrote: > We were hoping for immediate feedback, sounds like we may need to discuss > DSNs in the draft then. Can we give any guidance that direct feedback is > preferred? > > > > -bill > > > -------------------------------- > William J. Mills > "Paranoid" Yahoo! > > > ------------------------------ > *From:* Ned Freed > *To:* John Levine > *Cc:* dcrocker@bbiw.net; apps-discuss@ietf.org > *Sent:* Tuesday, August 6, 2013 10:06 AM > > *Subject:* Re: [apps-discuss] call for adoption: > draft-wmills-rrvs-header-field > > > >I suspect that a failure for one needs to be a failure for all, at the > > >end of the SMTP DATA command. > > Nonsense. This would be fundamentally changing the semantics of email - > you're essentially saying that the presence of this field changes the > envelope > to an all-or-nothing deal. > > We went through this in tedious detail back in the days of Sieve ereject; > let's please not repeat that discussion. SMTP servers are *required* > to be able to handle a mixture of recipient address states at the end of > DATA; if this includes partial-accept and partial-reject you have to > generate > DSNs. > > This is reality; suck it up and move on. > > > This is the swamp I was alluding to. > > > If a sender puts two rrvs headers on a message, and the recipient > > system rejects at the end of data, there's no way to tell which of > > them was the problem, short of implementing SMTP extensions that > > people have considered and declined to implement before. I suppose > > you could then split the message and send it separately to each and > > see what happens, but that seems like more complication than it's > > worth. > > > The main application for this hack is transaction messages which by > > their nature rarely go to more than one address, so it's perfectly > > reasonable to say that the results of using more than one rrvs header > > are indeterminate, so don't do that. > > > On the contrary, it isn't reasonable at all. A mechanism like this that > causes > delivery failures requires a crisp and complete specification. Failure to > do > that should disqualify this from the standards track. > > You can say that having more than one means all of them MUST be ignored, > or you > can specify how multiple headers can be handled. > > I'll also note that the multiplicity of this field has zero effect on the > need to generate DSNs. A single field could apply to one recipient and not > another. > > Ned > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --f46d04426e2ac2b7ec04e34af5f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Seems to me that's always the case anyway, is it not?= =A0 If it is, I don't think we need to say it explicitly.


On Tue, Aug 6, 20= 13 at 10:33 AM, Bill Mills <wmills@yahoo-inc.com> wrote:<= br>
We were hoping for immed= iate feedback, sounds like we may need to discuss DSNs in the draft then.= =A0 Can we give any guidance that direct feedback is preferred?


=A0
-bill


<= div style=3D"font-style:normal;font-size:13px;background-color:transparent;= font-family:arial,helvetica,clean,sans-serif">-----------------------------= ---
William J. Mills
"Paranoid" Yahoo!


From: Ned Freed <ned.freed@m= rochek.com>
To: J= ohn Levine <johnl@t= augh.com>
Cc: dcrocker@bbiw.net; apps-discuss@ietf.org
Sent: Tuesday, August 6, 2013 10:0= 6 AM

Subject: Re: [apps-disc= uss] call for adoption: draft-wmills-rrvs-header-field

> >I suspect that a failure for = one needs to be a failure for all, at the
> >end of the SMTP DATA command.

Nonsense. This would be funda= mentally changing the semantics of email -
you're essentially sayin= g that the presence of this field changes the envelope
to an all-or-noth= ing deal.

We went through this in tedious detail back in the days of Sieve erejec= t;
let's please not repeat that discussion. SMTP servers are *requir= ed*
to be able to handle a mixture of recipient address states at the end of
DATA= ; if this includes partial-accept and partial-reject you have to generateDSNs.

This is reality; suck it up and move on.

> This i= s the swamp I was alluding to.

> If a sender puts two rrvs headers on a message, and the recipient<= br>> system rejects at the end of data, there's no way to tell which= of
> them was the problem, short of implementing SMTP extensions tha= t
> people have considered and declined to implement before.=A0 I suppose<= br>> you could then split the message and send it separately to each and=
> see what happens, but that seems like more complication than it= 9;s
> worth.

> The main application for this hack is transaction m= essages which by
> their nature rarely go to more than one address, s= o it's perfectly
> reasonable to say that the results of using mo= re than one rrvs header
> are indeterminate, so don't do that.


On the contrary, it is= n't reasonable at all. A mechanism like this that causes
delivery fa= ilures requires a crisp and complete specification. Failure to do
that s= hould disqualify this from the standards track.

You can say that having more than one means all of them MUST be ignored= , or you
can specify how multiple headers can be handled.

I'= ll also note that the multiplicity of this field has zero effect on the
need to generate DSNs. A single field could apply to one recipient and not<= br>another.

=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 Ned
_________= ______________________________________
apps-discuss mailing list
apps-discuss@ietf.or= g
https://www.ietf.org/mailman/listinfo/apps-discuss



____________________________= ___________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--f46d04426e2ac2b7ec04e34af5f6-- From johnl@iecc.com Tue Aug 6 11:10: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 2E80021F8C65 for ; Tue, 6 Aug 2013 11:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 oZvTWdM+y5Az for ; Tue, 6 Aug 2013 11:10:58 -0700 (PDT) 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 9668311E80A2 for ; Tue, 6 Aug 2013 11:10:52 -0700 (PDT) Received: (qmail 83273 invoked from network); 6 Aug 2013 18:10:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=14548.52013c2a.k1308; bh=5zYKEBC+tb+pVTcTInlR84kj6f5rmlFRVZ3cUmg32IE=; b=JVnqtQw1pHSpMTGxYSPsTUF/e2qW5I+5Oxs+KZyUg9tXjroRHVaUE5IWcyyotJlF+5gee82ZLCdWQrMcmDtARHJHrAu9duiCoQ1V3i4nvoSdUwJp6Avs1SRAlpG+njJSB0wcS5mvicvQ/XvSbTdW4Nmuojb2+fiEdR9GJhyXZkSwukeIoD4L+y7ZtoTCcYevd91PL0zubnc5pZZsFKZU+xBFxj4P9CHkCi6htMpd1Ccyhn7QLuoXPtf7eET1twFP Received: (ofmipd 127.0.0.1); 6 Aug 2013 18:10:28 -0000 Date: 6 Aug 2013 14:10:50 -0400 Message-ID: From: "John R. Levine" To: "Ned Freed" In-Reply-To: <01OWW5LHXNUC00004R@mauve.mrochek.com> References: <52007215.6020400@dcrocker.net> <20130806145954.35360.qmail@joyce.lan> <01OWW5LHXNUC00004R@mauve.mrochek.com> 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: John Levine , apps-discuss@ietf.org Subject: Re: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field 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, 06 Aug 2013 18:10:59 -0000 > You can say that having more than one means all of them MUST be ignored, or you > can specify how multiple headers can be handled. The former seems fine to me. The practical advantages of a more complex spec seem minimal. 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 From superuser@gmail.com Tue Aug 6 12:08: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 3A06721E809B for ; Tue, 6 Aug 2013 12:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_62=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 AiRs0rdI+4n3 for ; Tue, 6 Aug 2013 12:08:12 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id E4B7121E8090 for ; Tue, 6 Aug 2013 12:08:11 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id m15so713744wgh.5 for ; Tue, 06 Aug 2013 12:08:09 -0700 (PDT) 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=UOkYkmg3r/jiR1rY5gCQ+LPkVefBlR10RuiH4mQmwXM=; b=AFLt6wiEM48+hqWsgRtYIeZUr6hHI+xkFuCCMx0OvNM9/19MaemczjThYyUmg1n9Bm Ky5gRBtWNKr7NquUYOGIyDsJO+rj9VyXMxy9szbffXSdRDcvIop47DV3xiUpyPV8+v00 Q4iENfLddbgZxM2EhJpZ4EifeBaQDcIr95Qt9+/zITgkrxkboycG080o4YwBjiZDDcPF SyRgtGpnf15RvPiLGn9GNcaoIbD4uqdOBmTYq//oYZi/RI78crWt6e2QJOZRpkw77SPL Oe08FXFFevSPgV6/kzI2g5JdQi5s0VeKTogmD/IwVhtHOYyw3u14Tm+w43yud5S1acSR bQ9w== MIME-Version: 1.0 X-Received: by 10.180.189.9 with SMTP id ge9mr1993687wic.52.1375816089642; Tue, 06 Aug 2013 12:08:09 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Tue, 6 Aug 2013 12:08:09 -0700 (PDT) In-Reply-To: <51FA4FD9.3030902@tana.it> References: <51FA4FD9.3030902@tana.it> Date: Tue, 6 Aug 2013 12:08:09 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=001a11c343024cae0204e34c2544 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] An Authentication-Results method for white (and black) lists 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, 06 Aug 2013 19:08:13 -0000 --001a11c343024cae0204e34c2544 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 1, 2013 at 5:08 AM, Alessandro Vesely wrote: > I posted an attempt in > http://tools.ietf.org/html/draft-vesely-authmethod-dnswl-01 > > Any suggestion on how to improve that? > > > This is a good start. Some comments to get you going: General: There are several places throughout the document where you refer to DNSWL or DNSBL where I think it should be DNSxL, since the mechanism is the same in both cases. Section 1: The comments about saving resources could refer instead to Appendix C in RFC5451, which gives a pretty thorough treatment of that topic. Section 2: You should say up front that the authentication method you're registering is called "dnsxl". I don't know what an "outsourced extension" is. I'm not sure about "policy.score". Is it not enough to report pass/fail according to the local policy parameters at the MTA where this is being evaluated? You could put score information in comments for debugging but the point here is to have downstream agents (e.g., MUAs) be as simple as possible. The definition of "policy." in RFC5451 doesn't agree with this usage either. What you have as "policy.contact" should just use the existing "reason" portion of the A-R field, or also be in a comment. The result definitions are fine, except for "fail" you should have "IP address" instead of just "IP". Section 3: Please don't reserve a name that you don't fully specify ("dnswl" in this case). It's also ambiguous to the one you're defining here ('dnsxl"). This is a good start, but I suggest you model the registrations after some other document that already does this sort of work. Section 5 of RFC6212 is probably a good basic reference. Section 4: You should copy the complete boilerplate from RFC6982 if you want to use it. There's probably a lot more detail in here about Courier-MTA than we really need to evaluate implementation. I'm also not sure that describing use of dnswl.org is relevant, since they don't implement this header field but rather provide the DNSxL service that an MTA will query. Section 5: You might also want to refer to the Security Considerations of RFC5782. Appendix A: Your example doesn't appear to match your definitions. In particular: - dnswl should be dnsxl - dns.zone should be policy.dnszone - policy.ip is not defined - policy.txt was discussed above -MSK --001a11c343024cae0204e34c2544 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 1, 2013 at 5:08 AM, Alessandro Vesely <vesely@ta= na.it> wrote:
I posted an attempt in
http://tools.ietf.org/html/draft-vesely-authmethod-dnswl-01<= /a>

Any suggestion on how to improve that?



You should say up front that the authentication method you're regi= stering is called "dnsxl".

I don't know what an "= outsourced extension" is.

I'm not sure about &qu= ot;policy.score".=A0 Is it not enough to report pass/fail according to= the local policy parameters at the MTA where this is being evaluated?=A0 Y= ou could put score information in comments for debugging but the point here= is to have downstream agents (e.g., MUAs) be as simple as possible.=A0 The= definition of "policy." in RFC5451 doesn't agree with this u= sage either.

What you have as "policy.contact" should just use = the existing "reason" portion of the A-R field, or also be in a c= omment.

The result definitions are fine, except for "= ;fail" you should have "IP address" instead of just "IP= ".

Section 3:

Please don't reserve a name= that you don't fully specify ("dnswl" in this case).=A0 It&#= 39;s also ambiguous to the one you're defining here ('dnsxl").=

This is a good start, but I suggest you model the registrati= ons after some other document that already does this sort of work.=A0 Secti= on 5 of RFC6212 is probably a good basic reference.

Secti= on 4:

--001a11c343024cae0204e34c2544-- From scott@kitterman.com Tue Aug 6 13:30: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 963D421F9B26 for ; Tue, 6 Aug 2013 13:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_62=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 AKHax3qEIVg2 for ; Tue, 6 Aug 2013 13:30:01 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7DED421F9AA1 for ; Tue, 6 Aug 2013 13:30:00 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id A025BD0407E; Tue, 6 Aug 2013 16:29:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1375820996; bh=znUdU55QfC4YF2pSxEzS8VrjyM0BRas7rAQlRBH8Gb8=; h=In-Reply-To:References:Subject:From:Date:To:From; b=d8Vpzpq4+th9zICddqDrylX+N0E0DJisKEJ5StAqjbQcS2p3cZO7Fd+XlSVWuzIgK dSR2lUNbk+qD7QRDwk1n2amD2zsBc1QmxLjH4p6kufQGYVNyPb5WWsECWe3J2xg3Qj KJBxxk0iZcc0a8sj2VB5iqLYcGO+ymExbrdpbX2Y= Received: from [IPV6:2600:1003:b107:1d5a:5908:1648:595c:9cac] (unknown [IPv6:2600:1003:b107:1d5a:5908:1648:595c:9cac]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 1BE5CD0403E; Tue, 6 Aug 2013 16:29:55 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: References: <51FA4FD9.3030902@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 06 Aug 2013 16:30:15 -0400 To: IETF Apps Discuss Message-ID: <7580ef50-27af-4eb2-893e-75165be161a6@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [apps-discuss] An Authentication-Results method for white (and black) lists 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, 06 Aug 2013 20:30:04 -0000 "Murray S. Kucherawy" wrote: >On Thu, Aug 1, 2013 at 5:08 AM, Alessandro Vesely >wrote: > >> I posted an attempt in >> http://tools.ietf.org/html/draft-vesely-authmethod-dnswl-01 >> >> Any suggestion on how to improve that? >> >> >> >This is a good start. Some comments to get you going: > >General: > >There are several places throughout the document where you refer to >DNSWL >or DNSBL where I think it should be DNSxL, since the mechanism is the >same >in both cases. > >Section 1: > >The comments about saving resources could refer instead to Appendix C >in >RFC5451, which gives a pretty thorough treatment of that topic. > >Section 2: > >You should say up front that the authentication method you're >registering >is called "dnsxl". > >I don't know what an "outsourced extension" is. > >I'm not sure about "policy.score". Is it not enough to report >pass/fail >according to the local policy parameters at the MTA where this is being >evaluated? You could put score information in comments for debugging >but >the point here is to have downstream agents (e.g., MUAs) be as simple >as >possible. The definition of "policy." in RFC5451 doesn't agree with >this >usage either. > >What you have as "policy.contact" should just use the existing "reason" >portion of the A-R field, or also be in a comment. > >The result definitions are fine, except for "fail" you should have "IP >address" instead of just "IP". > >Section 3: > >Please don't reserve a name that you don't fully specify ("dnswl" in >this >case). It's also ambiguous to the one you're defining here ('dnsxl"). > >This is a good start, but I suggest you model the registrations after >some >other document that already does this sort of work. Section 5 of >RFC6212 >is probably a good basic reference. > >Section 4: > >You should copy the complete boilerplate from RFC6982 if you want to >use it. > >There's probably a lot more detail in here about Courier-MTA than we >really >need to evaluate implementation. I'm also not sure that describing use >of >dnswl.org is relevant, since they don't implement this header field but >rather provide the DNSxL service that an MTA will query. > >Section 5: > >You might also want to refer to the Security Considerations of RFC5782. > >Appendix A: > >Your example doesn't appear to match your definitions. In particular: > >- dnswl should be dnsxl >- dns.zone should be policy.dnszone >- policy.ip is not defined >- policy.txt was discussed above A dnsxl doesn't authenticate anything. Isn't something related to repute more appropriate? Scott K From dhc@dcrocker.net Tue Aug 6 13:38: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 96AA321E809F for ; Tue, 6 Aug 2013 13:38:19 -0700 (PDT) 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 dlDRRFN2-jFh for ; Tue, 6 Aug 2013 13:38:14 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id ACB5221E809E for ; Tue, 6 Aug 2013 13:38:14 -0700 (PDT) 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 r76KcBf6015967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Aug 2013 13:38:14 -0700 Message-ID: <52015EB0.4080807@dcrocker.net> Date: Tue, 06 Aug 2013 13:38:08 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ned Freed References: <52007215.6020400@dcrocker.net> <20130806145954.35360.qmail@joyce.lan> <01OWW5LHXNUC00004R@mauve.mrochek.com> In-Reply-To: <01OWW5LHXNUC00004R@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]); Tue, 06 Aug 2013 13:38:14 -0700 (PDT) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 20:38:20 -0000 On 8/6/2013 10:06 AM, Ned Freed wrote: > Nonsense. This would be fundamentally changing the semantics of email - > you're essentially saying that the presence of this field changes the envelope > to an all-or-nothing deal. > > We went through this in tedious detail back in the days of Sieve ereject; > let's please not repeat that discussion. SMTP servers are*required* > to be able to handle a mixture of recipient address states at the end of > DATA; if this includes partial-accept and partial-reject you have to generate > DSNs. ack. So... When the text is modified to cover the multiple header field (addressee) case, it will be worth citing the spec details that cover established practice for handling errors... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ned.freed@mrochek.com Tue Aug 6 15:41: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 EACE521F9346 for ; Tue, 6 Aug 2013 15:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=0.307, 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 k5PfORVnG3Ay for ; Tue, 6 Aug 2013 15:41:44 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8086721F963C for ; Tue, 6 Aug 2013 15:41:44 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OWWGSIQ8G0000ONH@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 6 Aug 2013 15:36:42 -0700 (PDT) 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 <01OWVWVG24QO00004R@mauve.mrochek.com>; Tue, 6 Aug 2013 15:36:40 -0700 (PDT) Message-id: <01OWWGSH801A00004R@mauve.mrochek.com> Date: Tue, 06 Aug 2013 15:18:24 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 06 Aug 2013 13:38:08 -0700" <52015EB0.4080807@dcrocker.net> References: <52007215.6020400@dcrocker.net> <20130806145954.35360.qmail@joyce.lan> <01OWW5LHXNUC00004R@mauve.mrochek.com> <52015EB0.4080807@dcrocker.net> To: Dave Crocker DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1375828601; bh=A4jcLbTBRIuXuL0mx+OStukP4db4EsPWEhLKxhDQctM=; h=MIME-version:Content-type:Cc:Message-id:Date:From:Subject: In-reply-to:References:To; b=JUKvyZ+KKMWChnUUx3T/MrhCN9kd4O+53OrWX4PeZqiS8/tPp1NdSlOS5R72t41fj YL0in3ts8s6PVEtE/hBA35fTncRbgxu7o+i6ObssRCCCoLrcEXUg2fm9Lcv8UWarv5 iAk5IcVhmEiElg7CgURGE3c4nhPvDYyAujTAhE8w= Cc: Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field 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, 06 Aug 2013 22:41:49 -0000 > On 8/6/2013 10:06 AM, Ned Freed wrote: > > Nonsense. This would be fundamentally changing the semantics of email - > > you're essentially saying that the presence of this field changes the envelope > > to an all-or-nothing deal. > > > > We went through this in tedious detail back in the days of Sieve ereject; > > let's please not repeat that discussion. SMTP servers are*required* > > to be able to handle a mixture of recipient address states at the end of > > DATA; if this includes partial-accept and partial-reject you have to generate > > DSNs. > ack. > So... > When the text is modified to cover the multiple header field (addressee) > case, That's already been done, and posted. I have essentially no issues with the current version. > it will be worth citing the spec details that cover established > practice for handling errors... That would be RFC 5429 section 2.1.2. It's done in a fairly Sieve-specific way, however. Again the case arises irrespective of whether or not you allow the field to be repeated. All it takes is multiple envelope recipients. Really, I don't see why this is generating such concern. As others have noted, the primary use-case here is one involving a single recipient. We have to cover the other cases not because they're incredibly useful, but rather because mechanisms that cause mail to be rejected need to be completely and fully specified. A check against the envelope is necessary for multiple reasons. Given that's the case, all this does is join the long, long, long list of mixed result situations that cannot be detected at RCPT TO time. If there's any real cause for concern, it should be for implementations that find it difficult to perform an SMTP-level rejection after the DATA even in the single-recipient case. Those implementations will be generating a DSN every time. I don't know the state of play on this currently, but there used to be implementations with this issue. Which would argue for making this a RCPT TO parameter instead of a header field. Ned From Bert.Greevenbosch@huawei.com Tue Aug 6 18:41: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 A749C21E80C3; Tue, 6 Aug 2013 18:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.498 X-Spam-Level: X-Spam-Status: No, score=-4.498 tagged_above=-999 required=5 tests=[AWL=2.102, 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 wUUCWho8LHOj; Tue, 6 Aug 2013 18:41:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AD0B521E80C1; Tue, 6 Aug 2013 18:41:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUD88414; Wed, 07 Aug 2013 01:41:02 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 7 Aug 2013 02:40:50 +0100 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 7 Aug 2013 02:40:59 +0100 Received: from szxeml558-mbx.china.huawei.com ([169.254.7.152]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.007; Wed, 7 Aug 2013 09:40:55 +0800 From: Bert Greevenbosch To: "apps-discuss@ietf.org" , "iesg@ietf.org" , "draft-ietf-tls-oob-pubkey.all@tools.ietf.org" Thread-Topic: Applications Area Directorate Review of draft-ietf-tls-oob-pubkey-09 Thread-Index: Ac5oDNerh7dhbvRBRF2N44qjOGB5Zwqdp3dw Date: Wed, 7 Aug 2013 01:40:54 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63D7D4E65@szxeml558-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.162.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [apps-discuss] Applications Area Directorate Review of draft-ietf-tls-oob-pubkey-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: Wed, 07 Aug 2013 01:41:09 -0000 Document: draft-ietf-tls-oob-pubkey-09 Title: Out-of-band Public Key Validation for Transport Layer Security (TLS) Reviewer: Bert Greevenbosch Review Date: 7 August 2013 IETF Last Call Date: until 16 August 2013 IESG Telechat Date: [include if known] Summary: Given the goal of reducing network usage and processing cost, the = Raw Public Key as defined in a draft indeed does a good job. It alone canno= t provide the same level of security as PKI, but I think the "Security Cons= iderations" section indeed addresses the related trade-offs in security suf= ficiently. I think the draft is close to finalised state, but it needs some= changes as proposed below. Major Issues: (M1) The certificate negotiation (by including client_certificate_type and = server_certificate_type in client_hello and server_hello) brings along some= security issues. More specifically, as the hello messages are not integrit= y protected it allows an adversary to change the certificate format options= , especially to create a preference towards a weaker certificate format. I = suggest to add text about this, recommending that a receiving party verifie= s that a certificate is indeed in one of the forms it requested. (I can see= deployments were an entity has different certificate requirements for diff= erent situations, so not advertising a format does not necessarily mean the= entity does not support the format.) (M2) Page 7: "In order to indicate the support of out-of-band raw public ke= ys ...". Are these keys really out-of-band? It seems that the draft focuses= on the delivery of Raw Public Keys (RPKs) within an TLS exchange, so it se= ems that out-of-band is incorrect here. If out-of-band RPK delivery is supp= orted, then how does this work? Does that need any standardisation or is it= proprietary by nature? Maybe it is up to the out-of-band delivery method s= pecification to define the used format. The text on page 7 "If the client h= ello indicates support of raw public keys in the 'client_certificate_type' = extension and the server chooses to use raw public keys then the TLS server= MUST place the SubjectPublicKeyInfo structure into the Certificate payload= ." also seems to point at in-band delivery of RPKs. Minor Issues: (m1) The title of the draft is misleading. It seems that the document defin= es a mechanism for key validation, whereas in fact it defines a format and = TLS handshake extension for Raw Public Keys. Validation of the key (authent= ication, binding) is explicitly left out of scope of the draft. I suggest t= o change the title, e.g. to "Raw Public Key" or "A TLS extension to support= Raw Public Keys". Nits: (n1) Page 3, I propose to change "As part of the manufacturing process, the= embedded device may be configured with the address and the public key of a= dedicated CoAP server, as well as a public key for the client itself." to = "As part of the manufacturing process, the embedded device may be configure= d with the address and the public key of a dedicated CoAP server, as well a= s a public/private key pair for the client itself." (n2) The "Certificate" struct is an adaptation of its original form in RFC5= 246. It would be good to say this explicitly. (n3) On page 4, change "an DER encoded ASN.1 format" to "a DER encoded ASN.= 1 format". (n4) On page 4, figure 3, I suggest to change "Digital Signature Algorithm = (DSS)" to "Digital Signature Algorithm (DSA)", although DSA indeed is defin= ed in the Digital Signature Standard (DSS). (n5) On page 5, figure 4, add a comma behind "client_certificate_type". From dhc@dcrocker.net Tue Aug 6 19:27: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 A661D21E8063 for ; Tue, 6 Aug 2013 19:27:57 -0700 (PDT) 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 89nrka3Q3Ekv for ; Tue, 6 Aug 2013 19:27:52 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id EBFE521E808D for ; Tue, 6 Aug 2013 19:27:45 -0700 (PDT) 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 r772RfZn022055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Aug 2013 19:27:45 -0700 Message-ID: <5201B094.5080802@dcrocker.net> Date: Tue, 06 Aug 2013 19:27:32 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ned Freed References: <52007215.6020400@dcrocker.net> <20130806145954.35360.qmail@joyce.lan> <01OWW5LHXNUC00004R@mauve.mrochek.com> <52015EB0.4080807@dcrocker.net> <01OWWGSH801A00004R@mauve.mrochek.com> In-Reply-To: <01OWWGSH801A00004R@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]); Tue, 06 Aug 2013 19:27:45 -0700 (PDT) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] call for adoption: draft-wmills-rrvs-header-field X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 02:27:57 -0000 On 8/6/2013 3:18 PM, Ned Freed wrote: > Really, I don't see why this is generating such concern. My only concern is with making the documentation be careful for this. As the thread has demonstrated, it concerns a failure scenario about which there obviously is an, ummmm, varying level of community understanding. I think the new mechanism is better for being able to handle multiple header-fields (ie, addressees). But the best documentation for handling it appears to be buried in a specific, secondary protocol. In terms of the new mechanism, I'm fine with that, but it highlights the need for a bit more documentation than otherwise might be warranted (say, if the handling behavior were built into SMTP documentation...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From mnot@mnot.net Wed Aug 7 06:30: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 70B2221E811B for ; Wed, 7 Aug 2013 06:30:31 -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 Yg-sci7OLRve for ; Wed, 7 Aug 2013 06:30:27 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id ED92621F9E88 for ; Wed, 7 Aug 2013 06:30:23 -0700 (PDT) Received: from syd-mpyvy.munich.corp.akamai.com (unknown [213.61.213.58]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4925122E200 for ; Wed, 7 Aug 2013 09:30:05 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Aug 2013 15:30:03 +0200 References: <20130807132941.3553.98557.idtracker@ietfa.amsl.com> To: Apps Discuss Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [apps-discuss] Fwd: New Version Notification for draft-nottingham-uri-get-off-my-lawn-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, 07 Aug 2013 13:30:31 -0000 FYI; update based upon feedback. Cheers, Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-nottingham-uri-get-off-my-lawn-01.txt > Date: 7 August 2013 3:29:41 PM GMT+02:00 > To: Mark Nottingham >=20 >=20 > A new version of I-D, draft-nottingham-uri-get-off-my-lawn-01.txt > has been successfully submitted by Mark Nottingham and posted to the > IETF repository. >=20 > Filename: draft-nottingham-uri-get-off-my-lawn > Revision: 01 > Title: Standardising Structure in URIs > Creation date: 2013-08-07 > Group: Individual Submission > Number of pages: 8 > URL: = http://www.ietf.org/internet-drafts/draft-nottingham-uri-get-off-my-lawn-0= 1.txt > Status: = http://datatracker.ietf.org/doc/draft-nottingham-uri-get-off-my-lawn > Htmlized: = http://tools.ietf.org/html/draft-nottingham-uri-get-off-my-lawn-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-nottingham-uri-get-off-my-lawn-01= >=20 > Abstract: > Sometimes, it is attractive to add features to protocols or > applications by specifying a particular structure for URIs (or parts > thereof). This document cautions against this practice in standards > (sometimes called "URI Squatting"). >=20 >=20 >=20 >=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. >=20 > The IETF Secretariat >=20 -- Mark Nottingham http://www.mnot.net/ From vesely@tana.it Wed Aug 7 07:20: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 AA0CA21F9F2B for ; Wed, 7 Aug 2013 07:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.119 X-Spam-Level: X-Spam-Status: No, score=-4.119 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_34=0.6, J_CHICKENPOX_62=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 vmRYU1HG-15e for ; Wed, 7 Aug 2013 07:20:42 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDFF21F9E47 for ; Wed, 7 Aug 2013 07:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1375885231; bh=NZWP9CeiCvpv7FkMAAAGM0A4GkT2b65T6HtzWnpbdpk=; l=5238; h=Date:From:To:References:In-Reply-To; b=U/HRfqD/QaYlAA43JY65HqXSqYMxkcb9bBsZsdqesBUzyXhMFJNCJb33pc327WUYF TEEvGit/EoE6ZYxxAiPzpl3gZ9s5tp+KKQrpdls8h3ERfPaEXWKew3evc4fnCa8f5x Etw42tPpzApOjWfXNo+YFtf+tyCTHWECCTn3zBrk= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 07 Aug 2013 16:20:31 +0200 id 00000000005DC039.00000000520257AF.00007A3B Message-ID: <520257AF.9070003@tana.it> Date: Wed, 07 Aug 2013 16:20:31 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130704 Icedove/17.0.7 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <51FA4FD9.3030902@tana.it> <7580ef50-27af-4eb2-893e-75165be161a6@email.android.com> In-Reply-To: <7580ef50-27af-4eb2-893e-75165be161a6@email.android.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] An Authentication-Results method for white (and black) lists 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, 07 Aug 2013 14:20:49 -0000 On Tue 06/Aug/2013 22:30:15 +0200 Scott Kitterman wrote: > "Murray S. Kucherawy" wrote: >>On Thu, Aug 1, 2013 at 5:08 AM, Alessandro Vesely >>wrote: >> >>> I posted an attempt in >>> http://tools.ietf.org/html/draft-vesely-authmethod-dnswl-01 >> >>This is a good start. Some comments to get you going: >> >>General: >> >> There are several places throughout the document where you refer >> to DNSWL or DNSBL where I think it should be DNSxL, since the >> mechanism is the same in both cases. Albeit the mechanism is the same, the semantics is different. The description of pass and fail, for example, hinges on that. Any specific case where factoring would be worth? >> Section 1: >> >> The comments about saving resources could refer instead to >> Appendix C in RFC5451, which gives a pretty thorough treatment of >> that topic. Added a reference to Appendix D of I-D.ietf-appsawg-rfc5451bis. >> Section 2: >> >> You should say up front that the authentication method you're >> registering is called "dnsxl". Added in the abstract and at the end of the introduction. >> I don't know what an "outsourced extension" is. I'm not 100% clear on what a policy is. Considering it an intrinsic concept, I assume it can be extended, and its extensions can be outsourced rather than brewed inhaus. I split those sentences to: The receiving MTA needs to determine whether the data returned is applicable; that is, usable as an outsourced extension of its local policy. In that case, it stores a uniformized version of the data in the apposite properties of the Authentication-Results header field. Is that any better? >> I'm not sure about "policy.score". Is it not enough to report >> pass/fail according to the local policy parameters at the MTA >> where this is being evaluated? You could put score information >> in comments for debugging but the point here is to have >> downstream agents (e.g., MUAs) be as simple as possible. If the score is going to be used by an automated tool --some SA- equivalent filter that sums up all the scores and delivers the message according to the result-- then it is more straightforward to parse a property than a comment. >> The definition of "policy." in RFC5451 doesn't agree with >> this usage either. Why not? A "ptype" value of "policy" indicates a policy decision about the message not specific to a property of the message that could be extracted. The score is not extracted from the message, but imported according to the local policy. >> What you have as "policy.contact" should just use the existing >> "reason" portion of the A-R field, or also be in a comment. The policy.contact is designed to be used automatically: In case the recipient signals the message as spam, an MTA implementing RFC 6650 will send an ARF message to that contact. >> The result definitions are fine, except for "fail" you should >> have "IP address" instead of just "IP". Done. >> Section 3: >> >> Please don't reserve a name that you don't fully specify ("dnswl" >> in this case). It's also ambiguous to the one you're defining >> here ('dnsxl"). I can add more information on "dnswl". Since the I-D is Informational, describing is not standardizing. The point is if it is possible to register that a "dnswl" method is used in the wild. >> This is a good start, but I suggest you model the registrations >> after some other document that already does this sort of work. >> Section 5 of RFC6212 is probably a good basic reference. Done. >> Section 4: >> >> You should copy the complete boilerplate from RFC6982 if you want >> to use it. That sounds unpractical for readers, unless I structure the section into subsections. >> There's probably a lot more detail in here about Courier-MTA than >> we really need to evaluate implementation. Yes. >> I'm also not sure that describing use of dnswl.org is relevant, >> since they don't implement this header field but rather provide >> the DNSxL service that an MTA will query. It helps understanding the use case, though. >> Section 5: >> >> You might also want to refer to the Security Considerations of >> RFC5782. Added. >> Appendix A: >> >> Your example doesn't appear to match your definitions. In particular: >> >> - dnswl should be dnsxl >> - dns.zone should be policy.dnszone >> - policy.ip is not defined >> - policy.txt was discussed above Yes, I realized I hadn't changed it right after uploading version 01 :-( I'll fix that before next upload. > A dnsxl doesn't authenticate anything. Isn't something related to > repute more appropriate? I agree DNSBLs do not. However, dnswl.org, for one, does. It reports the registered domain of the sender IP address, so that the receiver learns the policy.contact. In addition, it may make sense to register what the reputation value was at the time a message was received. I believe that practice will come as soon as hands-on repute experience will have been gained. DNSWLs have existed for years, and their usage seems to be mature enough to allow for more methodical deployments. From mikeadouglass@gmail.com Wed Aug 7 07:46: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 1AF9721E8134; Wed, 7 Aug 2013 07:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuylDjh3ZkUU; Wed, 7 Aug 2013 07:46:03 -0700 (PDT) Received: from mail-ye0-x22d.google.com (mail-ye0-x22d.google.com [IPv6:2607:f8b0:4002:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1A87711E8139; Wed, 7 Aug 2013 07:46:03 -0700 (PDT) Received: by mail-ye0-f173.google.com with SMTP id m14so562118yen.32 for ; Wed, 07 Aug 2013 07:46:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=zv8xgcHIIw4mIZX373KvJpdJ9AiOWTZ+3aqSQ25Bkmw=; b=irYN+baZvPT/mRuswqsn5hEzIwrEMwBV31Xks1NjAE5FFSoZoJFrdP+z0tMOWctRTm uZzkQ2rsW1mv66P4gUrnV0vttydnUTRsXj08C9uvhbf7Z1ACetcM54+CUaH6y8zLBO/r QqnbX8qv71T7k1FPciqOutJK3itmeKyNrXgdir+jWE+tiRV0K2cxxxz+65Dh9W9B9J2L DIngBp6ymZ/Zet3OCNTECxvdNlNU/ML2rijXbKDJYnZwjuQfz2Tyro81MJLZXbNLRmkP Nmg9rTff0MF+FCvNM65B7nj4FAK1tIGpGJjZAYAvVxRUAuHcexyiXCsZPSwjVQnaZPEM FHrQ== X-Received: by 10.236.179.135 with SMTP id h7mr2021370yhm.216.1375886762646; Wed, 07 Aug 2013 07:46:02 -0700 (PDT) Received: from ?IPv6:2620:0:2820:2:d55e:5f9e:2c17:6d53? ([2620:0:2820:2:d55e:5f9e:2c17:6d53]) by mx.google.com with ESMTPSA id d68sm10018731yhk.7.2013.08.07.07.46.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Aug 2013 07:46:01 -0700 (PDT) Message-ID: <52025DA8.4070407@gmail.com> Date: Wed, 07 Aug 2013 10:46:00 -0400 From: Mike Douglass User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: IETF Apps Discuss , IETF Calsify Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Resource type registry 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, 07 Aug 2013 14:46:04 -0000 In a couple of CalConnect technical committees we are working on specifying extensions to RFC5545, https://datatracker.ietf.org/doc/draft-douglass-calendar-extension/ and an upcoming extension for tasks: and have identified a need for some sort of resource type registry along the lines of the location registry defined by RFC4589. https://datatracker.ietf.org/doc/rfc4589/ It seems that somewhere there might to be such a registry but we have been unable to locate one. Does anybody know of such a registry that could be used and has the right characteristics (unencumbered, extensible)? Or should we go ahead and define such a registry along the lines of 4589 and seed it with what we consider useful values? From superuser@gmail.com Wed Aug 7 11:23:54 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 0AD5D21F9F50 for ; Wed, 7 Aug 2013 11:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 8ffVnoON1TGV for ; Wed, 7 Aug 2013 11:23:52 -0700 (PDT) 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 18ACA21F9F1C for ; Wed, 7 Aug 2013 11:23:51 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hr7so2013821wib.6 for ; Wed, 07 Aug 2013 11:23:51 -0700 (PDT) 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=fvrijETbJ8lFYvH9sW5pDizKdsBJgQ591f9LU/kReIU=; b=Nv6C1boTG8+r1iTbnVtUEaKXUIH3fWKkTEv4g4GXGHOyvPAm7B7gDK7QRBSaV4eF40 0mGNe4bapBycbRm5jv0dj3bFGqIRtBZow8OWbH47e7NN1myOFdSqRDHVFBwctd3VTzT/ KztFSP1diCExkGzS7EUsPLGiO614c15SSkQwt7OvpIfIRDQU4HyWRGeSJSd2HJiEPiut mo1ITh8rQk81KUe8ia9QUQoiMdp1onvRDIdFu0BI471DbAYk2dfnzVWSkfa+8M8q65xQ 1dpehah4MXeRV82Z4rLBDyaG5/LQHJrX3qljSUh7mO2WwkxMVb2KO+YjPa+Akp5dNIBa FI1Q== MIME-Version: 1.0 X-Received: by 10.180.84.196 with SMTP id b4mr2993009wiz.19.1375899831154; Wed, 07 Aug 2013 11:23:51 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Wed, 7 Aug 2013 11:23:50 -0700 (PDT) In-Reply-To: <520257AF.9070003@tana.it> References: <51FA4FD9.3030902@tana.it> <7580ef50-27af-4eb2-893e-75165be161a6@email.android.com> <520257AF.9070003@tana.it> Date: Wed, 7 Aug 2013 11:23:50 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=f46d04426e2aaec16a04e35fa42e Cc: IETF Apps Discuss Subject: Re: [apps-discuss] An Authentication-Results method for white (and black) lists 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, 07 Aug 2013 18:23:54 -0000 --f46d04426e2aaec16a04e35fa42e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 7, 2013 at 7:20 AM, Alessandro Vesely wrote: > >> There are several places throughout the document where you refer > >> to DNSWL or DNSBL where I think it should be DNSxL, since the > >> mechanism is the same in both cases. > > Albeit the mechanism is the same, the semantics is different. The > description of pass and fail, for example, hinges on that. Any > specific case where factoring would be worth? > The semantics are that being listed on a DNSWL means the message should be allowed through while being listed on DNSBL means the message should not be allowed through, and not being listed on either doesn't tell you anything. You could register two methods, "dnswl" and "dnsbl" and thus encode the meaning of a "pass" in the name itself. You would have to update your registrations and definitions accordingly. > >> I don't know what an "outsourced extension" is. > > I'm not 100% clear on what a policy is. Considering it an intrinsic > concept, I assume it can be extended, and its extensions can be > outsourced rather than brewed inhaus. > > I split those sentences to: > > The receiving MTA needs to determine whether the data returned is > applicable; that is, usable as an outsourced extension of its > local policy. In that case, it stores a uniformized version of > the data in the apposite properties of the Authentication-Results > header field. > > Is that any better? > I still don't know what you mean by "outsourced". Do you mean the filtering agent is making a decision to trust a third party's opinion about the trustworthiness of the source? I also don't know what "uniformized" means; did you mean "canonical" or "distilled"? The use of "policy" as a ptype is meant to indicate that some kind of local policy is superseding what would normally take place. The specific example I can remember is a DKIM signature that passes, but the Subject: field was not included in what the signature covered, and local policy requires that it is. In that case you would generate something like "dkim=pass header.d= example.com policy.dkim-unsigned=subject". There, "dkim-unsigned" is the name given to the local policy that checks to see whether a required set of fields was covered by a DKIM signature, and the value indicates which field(s) DKIM didn't cover. Policy names are created locally, so they're not specified in the RFC or registered with IANA. > >> I'm not sure about "policy.score". Is it not enough to report > >> pass/fail according to the local policy parameters at the MTA > >> where this is being evaluated? You could put score information > >> in comments for debugging but the point here is to have > >> downstream agents (e.g., MUAs) be as simple as possible. > > If the score is going to be used by an automated tool --some SA- > equivalent filter that sums up all the scores and delivers the message > according to the result-- then it is more straightforward to parse a > property than a comment. > OK, but unfortunately "policy" is not the mechanism to do that. Really, putting acceptance decisions in the hands of downstream filters or MUAs is kind of against the whole model that A-R attempts to provide. Instead, the handling thresholds should be encoded in the method result. Maybe you want something more granular in your result codes than just "pass" and "fail"? > >> The definition of "policy." in RFC5451 doesn't agree with > >> this usage either. > > Why not? > See above. > >> What you have as "policy.contact" should just use the existing > >> "reason" portion of the A-R field, or also be in a comment. > > The policy.contact is designed to be used automatically: In case the > recipient signals the message as spam, an MTA implementing RFC 6650 > will send an ARF message to that contact. > An MTA doing so already has this information. It doesn't need to relay it to downstream filters or MUAs. Or are you talking about MUAs implementing RFC6650 themselves? > >> Section 3: > >> > >> Please don't reserve a name that you don't fully specify ("dnswl" > >> in this case). It's also ambiguous to the one you're defining > >> here ('dnsxl"). > > I can add more information on "dnswl". Since the I-D is > Informational, describing is not standardizing. The point is if it is > possible to register that a "dnswl" method is used in the wild. > Yes, but if this gets published, an IANA registry entry created will point to this document, which (at present) says nothing about "dnswl". If you really want to reserve that name, you should consider registering "dnsbl" and "dnswl", and not "dnsxl". > >> Section 4: > >> > >> You should copy the complete boilerplate from RFC6982 if you want > >> to use it. > > That sounds unpractical for readers, unless I structure the section > into subsections. > RFC6982 sections are deleted before publication. They're only meaningful during evaluation of the document. > > A dnsxl doesn't authenticate anything. Isn't something related to > > repute more appropriate? > > I agree DNSBLs do not. However, dnswl.org, for one, does. It reports > the registered domain of the sender IP address, so that the receiver > learns the policy.contact. > That's a database lookup, not authentication work. However, to Scott's point, VBR is not itself an authentication method either, but it has A-R entries. That drew no objections at the time, but that could've been an oversight. > In addition, it may make sense to register what the reputation value > was at the time a message was received. I believe that practice will > come as soon as hands-on repute experience will have been gained. > DNSWLs have existed for years, and their usage seems to be mature > enough to allow for more methodical deployments. > > All true, except that providing the details of the evaluation to downstream agents is not what A-R is for. The ultimate goal is to indicate to MUAs that this message did or did not pass a particular set of tests, and these are the message properties that are worth highlighting in some way. For a DNSXL, that model doesn't indicating anything about a scalar reputation. You could restrict "pass" to mean "listed and above a certain score" if you like, but that's not something that's meant (in this model) to be exposed to MUAs. It passed your test, or it did not. -MSK --f46d04426e2aaec16a04e35fa42e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 7, 2013 at 7:20 AM, Alessandro Vesely <vesely@ta= na.it> wrote:
>> There are several places throughout= the document where you refer
>> to DNSWL or DNSBL where I think it should be DNSxL, since the
>> mechanism is the same in both cases.

Albeit the mechanism is the same, the semantics is different. =A0The<= br> description of pass and fail, for example, hinges on that. =A0Any
specific case where factoring would be worth?

The semantics are that being listed on a DNSWL means the message sho= uld be allowed through while being listed on DNSBL means the message should= not be allowed through, and not being listed on either doesn't tell yo= u anything.

You could register two methods, "dnswl" and "= dnsbl" and thus encode the meaning of a "pass" in the name i= tself.=A0 You would have to update your registrations and definitions accor= dingly.
=A0
>> I don't know what = an "outsourced extension" is.

I'm not 100% clear on what a policy is. =A0Considering it an intr= insic
concept, I assume it can be extended, and its extensions can be
outsourced rather than brewed inhaus.

I split those sentences to:

=A0 =A0The receiving MTA needs to determine whether the data returned is =A0 =A0applicable; that is, usable as an outsourced extension of its
=A0 =A0local policy. =A0In that case, it stores a uniformized version of =A0 =A0the data in the apposite properties of the Authentication-Results =A0 =A0header field.

Is that any better?

I still don't k= now what you mean by "outsourced".=A0 Do you mean the filtering a= gent is making a decision to trust a third party's opinion about the tr= ustworthiness of the source?

I also don't know what "uniformized" means; did you mean = "canonical" or "distilled"?

The use o= f "policy" as a ptype is meant to indicate that some kind of loca= l policy is superseding what would normally take place.=A0 The specific exa= mple I can remember is a DKIM signature that passes, but the Subject: field= was not included in what the signature covered, and local policy requires = that it is.=A0 In that case you would generate something like "dkim=3D= pass header.d=3Dexample.com policy.dkim-= unsigned=3Dsubject".=A0 There, "dkim-unsigned" is the name g= iven to the local policy that checks to see whether a required set of field= s was covered by a DKIM signature, and the value indicates which field(s) D= KIM didn't cover.=A0 Policy names are created locally, so they're n= ot specified in the RFC or registered with IANA.


>> I'm not sure about "policy.score". =A0Is it not enou= gh to report
>> pass/fail according to the local policy parameters at the MTA
>> where this is being evaluated? =A0You could put score information<= br> >> in comments for debugging but the point here is to have
>> downstream agents (e.g., MUAs) be as simple as possible.

If the score is going to be used by an automated tool --some SA-
equivalent filter that sums up all the scores and delivers the message
according to the result-- then it is more straightforward to parse a
property than a comment.

OK, but unfort= unately "policy" is not the mechanism to do that.=A0 Really, putt= ing acceptance decisions in the hands of downstream filters or MUAs is kind= of against the whole model that A-R attempts to provide.=A0 Instead, the h= andling thresholds should be encoded in the method result.=A0 Maybe you wan= t something more granular in your result codes than just "pass" a= nd "fail"?
=A0
>> The definition of "policy." in RFC5451= doesn't agree with
>> this usage either.

Why not?

See above.
=A0
>> What you have as "policy.contact" should just use the ex= isting
>> "reason" portion of the A-R field, or also be in a comme= nt.

The policy.contact is designed to be used automatically: =A0In case t= he
recipient signals the message as spam, an MTA implementing RFC 6650
will send an ARF message to that contact.

An MTA doing so already has this information.=A0 It doesn't need to = relay it to downstream filters or MUAs.=A0 Or are you talking about MUAs im= plementing RFC6650 themselves?
=A0
>> Section 3:
>>
>> Please don't reserve a name that you don't fully specify (= "dnswl"
>> in this case). =A0It's also ambiguous to the one you're de= fining
>> here ('dnsxl").

I can add more information on "dnswl". =A0Since the I-D is<= br> Informational, describing is not standardizing. =A0The point is if it is possible to register that a "dnswl" method is used in the wild.

Yes, but if this gets published, an IANA= registry entry created will point to this document, which (at present) say= s nothing about "dnswl".=A0 If you really want to reserve that na= me, you should consider registering "dnsbl" and "dnswl"= , and not "dnsxl".
=A0
>> Section 4:
>>
>> You should copy the complete boilerplate from RFC6982 if you want<= br> >> to use it.

That sounds unpractical for readers, unless I structure the section into subsections.

RFC6982 sections are = deleted before publication.=A0 They're only meaningful during evaluatio= n of the document.
=A0
> A dnsxl doesn't authenticate anything. Isn't something related= to
> repute more appropriate?

I agree DNSBLs do not. =A0However, dnswl.org, for one, does. =A0It reports
the registered domain of the sender IP address, so that the receiver
learns the policy.contact.

That's a= database lookup, not authentication work.

However, to Sc= ott's point, VBR is not itself an authentication method either, but it = has A-R entries.=A0 That drew no objections at the time, but that could'= ;ve been an oversight.
=A0
In addition, it may make sense to register what the reputation value
was at the time a message was received. =A0I believe that practice will
come as soon as hands-on repute experience will have been gained.
DNSWLs have existed for years, and their usage seems to be mature
enough to allow for more methodical deployments.
<= div>=A0

= All true, except that providing the details of the evaluation to downstream= agents is not what A-R is for.=A0 The ultimate goal is to indicate to MUAs= that this message did or did not pass a particular set of tests, and these= are the message properties that are worth highlighting in some way.=A0 For= a DNSXL, that model doesn't indicating anything about a scalar reputat= ion.=A0 You could restrict "pass" to mean "listed and above = a certain score" if you like, but that's not something that's = meant (in this model) to be exposed to MUAs.=A0 It passed your test, or it = did not.

-MSK
--f46d04426e2aaec16a04e35fa42e-- From vesely@tana.it Thu Aug 8 04:07: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 7622421F9946 for ; Thu, 8 Aug 2013 04:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.119 X-Spam-Level: X-Spam-Status: No, score=-4.119 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_65=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 ygc8XfJmw6OW for ; Thu, 8 Aug 2013 04:07:08 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5F911E8126 for ; Thu, 8 Aug 2013 04:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1375960010; bh=vv582/BYlNxbGQioBq5t2GeasaGiZFO5iJT2HbiHZLM=; l=8702; h=Date:From:To:References:In-Reply-To; b=LWX8RinWtFl4jiVqcg3kp513A1B4unUQhd2TA8Xh3/ToAlbB8L6As6O0k7FWxHWpI yzJTB1TlofOm+h2sH1YC8FWB3j37Vphj+7J12htt/3Njky3gCcBuQIMkyVmCKH8OQf 17apsAMWM+abgvdzzocs8iN2DrC2EGi8kx27s6Kw= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.129] (93-32-157-98.ip34.fastwebnet.it [93.32.157.98]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Thu, 08 Aug 2013 13:06:50 +0200 id 00000000005DC03F.0000000052037BCA.00006834 Message-ID: <52037BC5.2080504@tana.it> Date: Thu, 08 Aug 2013 13:06:45 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <51FA4FD9.3030902@tana.it> <7580ef50-27af-4eb2-893e-75165be161a6@email.android.com> <520257AF.9070003@tana.it> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] An Authentication-Results method for white (and black) lists 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, 08 Aug 2013 11:07:16 -0000 On Wed 07/Aug/2013 20:23:50 +0200 Murray S. Kucherawy wrote: > On Wed, Aug 7, 2013 at 7:20 AM, Alessandro Vesely wrote: > >> I split those sentences to: >> >> The receiving MTA needs to determine whether the data returned is >> applicable; that is, usable as an outsourced extension of its >> local policy. In that case, it stores a uniformized version of >> the data in the apposite properties of the Authentication-Results >> header field. >> >> Is that any better? > > I still don't know what you mean by "outsourced". Do you mean the > filtering agent is making a decision to trust a third party's opinion about > the trustworthiness of the source? Yes. It is the receiving ADMD, rather than the filter, who makes the decision of acquiring the policy extension from an external supplier. > I also don't know what "uniformized" means; did you mean "canonical" or > "distilled"? Canonical, or homogeneous. > The use of "policy" as a ptype is meant to indicate that some kind of local > policy is superseding what would normally take place. If that is meant to be normative, it ought to be specified better (in 5451-ter?) W.r.t. the example quoted below, the evaluation of a DKIM signature, rather than an IP address, is affected by a local policy. It is not obvious why would policy.dkim-unsigned be valid given that policy.score is not. > The specific example I can remember is a DKIM signature that passes, > but the Subject: field was not included in what the signature > covered, and local policy requires that it is. In that case you > would generate something like "dkim=pass header.d= example.com > policy.dkim-unsigned=subject". There, "dkim-unsigned" is the name > given to the local policy that checks to see whether a required set > of fields was covered by a DKIM signature, and the value indicates > which field(s) DKIM didn't cover. Policy names are created locally, > so they're not specified in the RFC or registered with IANA. Registration of "dnswl" and "dnsxl" can get much simpler if some names can be omitted, e.g. because they are created locally. But how should parsing software behave in such cases? I thought that the example given near the end of Section 2.2 referred to some yet unspecified method, since no method registered a "policy" ptype. (I see now that there is a "policy.iprev" property at IANA's. Where does it come from?) >>> I'm not sure about "policy.score". >> >> [It might be used by] an automated tool --some SA- equivalent >> filter that sums up all the scores and delivers the message >> according to the result. > > OK, but unfortunately "policy" is not the mechanism to do that. Really, > putting acceptance decisions in the hands of downstream filters or MUAs is > kind of against the whole model that A-R attempts to provide. Eh? I must have misunderstood much of 5451-bis: The intent of the header field is to create a place to collect such data when message authentication mechanisms are in use so that a Mail User Agent (MUA) and downstream filters can make filtering decisions [...] What is the difference between acceptance decisions and filtering decisions? > Instead, the handling thresholds should be encoded in the method > result. That doesn't allow a final decision to be made by weighting contributions from many upstream filters. > Maybe you want something more granular in your result codes than just > "pass" and "fail"? I'm not (yet) using the score, so I can follow the consensus on this issue. >>> What you have as "policy.contact" should just use the existing >>> "reason" portion of the A-R field, or also be in a comment. >> >> The policy.contact is designed to be used automatically: In case the >> recipient signals the message as spam, an MTA implementing RFC 6650 >> will send an ARF message to that contact. > > An MTA doing so already has this information. It doesn't need to relay it > to downstream filters or MUAs. Or are you talking about MUAs implementing > RFC6650 themselves? No, the MUA just signals the message, possibly by moving it in a "Spam" folder. At this point, the server formats the message according to ARF and sends it to policy.contact. In the current implementation, the contact is already in a database at that point. However, it made it into the database after parsing the "policy.txt" property of the existing "dnswl" method. If "policy.txt" can stay non-registered, like locally created names, I'd be happy to revert to version 00 "dnswl". It looks much simpler than standardizing the score. Would it be possible to update 5451-bis so as to add "dns"? >>> Section 3: >>> >>> Please don't reserve a name that you don't fully specify ("dnswl" >>> in this case). It's also ambiguous to the one you're defining >>> here ('dnsxl"). >> >> I can add more information on "dnswl". Since the I-D is >> Informational, describing is not standardizing. The point is if it is >> possible to register that a "dnswl" method is used in the wild. > > Yes, but if this gets published, an IANA registry entry created will point > to this document, which (at present) says nothing about "dnswl". If you > really want to reserve that name, you should consider registering "dnsbl" > and "dnswl", and not "dnsxl". For "dnsbl", Scott's objection is valid. See below. >>> Section 4: >>> >>> You should copy the complete boilerplate from RFC6982 if you want >>> to use it. >> >> That sounds unpractical for readers, unless I structure the section >> into subsections. > > RFC6982 sections are deleted before publication. They're only > meaningful during evaluation of the document. Yes, but I slightly stretched the spirit of RFC 6982 trying to better recount the use case. Readability would be at stake if distinguishing boilerplate from other notes became difficult. >>> [Scott:] A dnsxl doesn't authenticate anything. Isn't something >>> related to repute more appropriate? >> >> I agree DNSBLs do not. However, dnswl.org, for one, does. It reports >> the registered domain of the sender IP address, so that the receiver >> learns the policy.contact. > > That's a database lookup, not authentication work. The former is a means to achieve the latter. > However, to Scott's point, VBR is not itself an authentication method > either, but it has A-R entries. That drew no objections at the time, but > that could've been an oversight. Hm... Establishing the identity of an actor is not really different from authenticating: The tokens that we authenticate, names or IP numbers, are strongly related to the identity of the actor who bears them. And an identity is the collection of multiple traits and properties that make an actor recognizable and possibly trustworthy. In that sense, both SWL (VBR) and dnswl.org (this) are means to authenticate a sender. >> In addition, it may make sense to register what the reputation value >> was at the time a message was received. I believe that practice will >> come as soon as hands-on repute experience will have been gained. >> DNSWLs have existed for years, and their usage seems to be mature >> enough to allow for more methodical deployments. > > All true, except that providing the details of the evaluation to downstream > agents is not what A-R is for. The ultimate goal is to indicate to MUAs > that this message did or did not pass a particular set of tests, and these > are the message properties that are worth highlighting in some way. MUAs are a difficult target for A-R, unless they are aware of the internal processing details of the unique ADMD that they fetch messages from. In the latter case, they can be considered internal filters, albeit interactive. My understanding of A-R, until now, is that it is a convenient means to pass authentication results to downstream filters. An omnibus. What am I missing? > For a DNSXL, that model doesn't indicate anything about a scalar > reputation. You could restrict "pass" to mean "listed and above a > certain score" if you like, but that's not something that's meant (in > this model) to be exposed to MUAs. It passed your test, or it did > not. Well, some more granularity might be useful in some cases. The granularity offered by dnswl.org encoding is nowhere near the continuity of a real scalar, though. I agree that real values belong rather to fuzzy evaluations, such as Bayesian statistics. IMHO, those fuzzy filters ought to run under the direct control of recipients, not on a server. Yet, it might be useful for A-R to inter-operate with those processes. Dunno. From alexey.melnikov@isode.com Thu Aug 8 06:48: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 DFF7211E8139; Thu, 8 Aug 2013 06:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.952 X-Spam-Level: X-Spam-Status: No, score=-100.952 tagged_above=-999 required=5 tests=[AWL=-1.647, BAYES_00=-2.599, FB_WORD2_END_DOLLAR=3.294, 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 wz1987iDcnJp; Thu, 8 Aug 2013 06:48:49 -0700 (PDT) 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 8777F21E804E; Thu, 8 Aug 2013 06:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1375969725; d=isode.com; s=selector; i=@isode.com; bh=F4qYzm/dInBP85OT6qr5xAgQXHuHgFL1+Ml3O+vS40M=; 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=fTfyI1e/DlCr09/d6j3I0CWUoOe8rNgSWF6yICVGa00kFY2JTFN/uuZ0SwTKBx2oGcHe0J rJyUkmc5ITfOquBo0DTjN01Sj7nzrRJyFUshCQWuAc31TBv0+GeHc+8kR3UYD7VsUV4WE/ iZcxCka1inllMjaB2545O9Zvc4Q+JDk=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 8 Aug 2013 14:48:44 +0100 Message-ID: <5203A1C0.80709@isode.com> Date: Thu, 08 Aug 2013 14:48:48 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: draft-ietf-geopriv-relative-location.all@tools.ietf.org, apps-discuss@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IESG Subject: [apps-discuss] AppsDir review of draft-ietf-geopriv-relative-location-06 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, 08 Aug 2013 13:48:50 -0000 Hello all, 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-geopriv-relative-location-06 Title: Relative Location Representation Reviewer: Alexey Melnikov Review Date: 8 August 2013 Summary: The document is nearly ready for publication. Only minor fixes are needed, mostly missing references. Major issues: none Minor Issues: In Section 3: Optionally, a reference to a 'map' document can be provided. The reference is a URI. URI needs a normative reference. The document could be an image or dataset that represents a map, floorplan or other form. The type of document the URI points to is described as a MIME media type. MIME media type needs a normative reference. 4.9.5.1. XML encoding An arc-band is represented in and converted from GML using the following template: $Coordinate-1 $Coordinate-2$ $Inner-Radius$ $Inner-Radius$ I think you meant $Outer-Radius$ above. $Start-Angle$ $Opening-Angle$ 4.11.1. Map URL In XML, the map is a element defined within and contains the URL. The URL is encoded as a UTF-8 encoded string. An "http:" or "https:" URL MUST be used unless the entity creating http/https need Normative references. the PIDF-LO is able to ensure that authorized recipients of this data are able to use other URI schemes. 4.11.2.1. Map Reference Point Offset The map referenc point uses a type code of 129. Typo: referenc +------+------+ | 129 |Length| +------+------+------+------+ | Coordinate-1 | +------+------+------+------+ | Coordinate-2 | +------+------+------+------+ | (3D-only) Coordinate-3 | +------+------+------+------+ Map Reference Point Coordinates TLV If omitted, a value containing all zeros is assumed. If the coordinates provided contain fewer values than are needed, the first value from the set is applied in place of any missing values. I couldn't understand what are you talking about here. Are you talking about the 3rd coordinate missing? What is "the set"? Nits: none From cabo@tzi.org Thu Aug 8 12:58: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 360C611E8225; Thu, 8 Aug 2013 12:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 9gCERiLa0Jry; Thu, 8 Aug 2013 12:58:49 -0700 (PDT) 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 CB6C411E822F; Thu, 8 Aug 2013 12:58:26 -0700 (PDT) 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 r78JwJrM009599; Thu, 8 Aug 2013 21:58:19 +0200 (CEST) Received: from [192.168.217.105] (p5489221B.dip0.t-ipconnect.de [84.137.34.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 86A8C152; Thu, 8 Aug 2013 21:58:18 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Thu, 8 Aug 2013 21:58:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.1508) Cc: draft-bormann-cbor-04.all@tools.ietf.org, gen-art@ietf.org, "ietf@ietf.org Mailing List" , IETF Apps Discuss Subject: Re: [apps-discuss] Gen-ART review of draft-bormann-cbor-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: Thu, 08 Aug 2013 19:58:55 -0000 On Jul 30, 2013, at 09:05, Martin Thomson = wrote: > What would cause this to be tragic, is if publication of this were > used to prevent other work in this area from subsequently being > published. Indeed. As Paul and I have repeatedly said, CBOR is not trying to be the final, = definitive, binary object representation for all purposes. It was = written to some specific objectives, clearly stated in the document. It = is being proposed for standards-track because specific ongoing work that = works well with these objectives will benefit greatly from being able to = reference a common specification. If the objectives for other work are = different, that work may benefit from using a different format, existing = or newly designed. We had some offline discussion of what can be done to make this more = apparent from the document, and decided to start at the most visible = part, the abstract. In -04, the abstract says: The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. Now this seemed fairly clear to the authors, but without context it = might be read as trying to be the final, end-all format because it only = talks about earlier formats. We propose to fix this (at the danger of being slightly tautological) by = making it clear other formats will be created in the future: The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack, or other binary serializations that may be created in the future. Serialization/encoding of data structures for transmission continues to = be an exciting (if sometimes arcane) subject of computer science and its = long history will not end with CBOR. (CC to ietf@ietf.org because some discussion there appears to be = related.) Gr=FC=DFe, Carsten From cabo@tzi.org Thu Aug 8 13:03: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 56A6711E821C for ; Thu, 8 Aug 2013 13:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 TMTfnQ-W8U4h for ; Thu, 8 Aug 2013 13:03:35 -0700 (PDT) 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 6310F11E8205 for ; Thu, 8 Aug 2013 13:03:35 -0700 (PDT) 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 r78K3XWS020138 for ; Thu, 8 Aug 2013 22:03:33 +0200 (CEST) Received: from [192.168.217.105] (p5489221B.dip0.t-ipconnect.de [84.137.34.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B40FF157; Thu, 8 Aug 2013 22:03:32 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Aug 2013 22:03:31 +0200 To: apps-discuss@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [apps-discuss] WG summary: CoRE 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, 08 Aug 2013 20:03:40 -0000 Summary of CoRE sessions @ IETF87 See agenda at http://www.ietf.org/proceedings/87/agenda/agenda-87-core and consolidated slides at http://www.ietf.org/proceedings/87/slides/slides-87-core-0.pdf WG status: After recently completing the base specification for CoAP (draft-ietf-core-coap-18 now in RFC editor queue waiting for two security MISSREFs), the WG is in a transition phase. Several complementary documents are nearing completion, with some of them receiving little recent review and implementation, compounded by the current vacation time. There is considerable interest in adding new work, though. Monday: Substantive discussion on the new subject of authorization, with multiple drafts; there seems to be energy to review them even though few had read the drafts in advance. (A self-organized ad-hoc group of 9 people had a lunch meeting between the two CoRE slots and created an action plan for work until IETF88; work on this is active.) On the recently added WG documents, a very quiet room and largely presentation-style; somewhat inevitable given that there was much more interest in the new work being brought in to the group. Thursday: MUCH more discussion, every item had worthwhile comments. Advanced congestion control is developing slowly, only one group doing substantive work presented preliminary results, so that will take some time. Of the older active work items, the block transfer draft had good guidance on its remaining issues. Links-json has little independent implementation experience at this time, and so will wait for that. The alternative transports subject had much discussion, and the group will seek guidance on the URL/URI issues surrounding transport selection. Finally, conditional observation had some good guidance, that draft is still fairly incomplete but has a path for further development. Gr=FC=DFe, Carsten From alexey.melnikov@isode.com Fri Aug 9 02:37: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 DBEFB21F9DDE; Fri, 9 Aug 2013 02:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.328 X-Spam-Level: X-Spam-Status: No, score=-100.328 tagged_above=-999 required=5 tests=[AWL=-1.023, BAYES_00=-2.599, FB_WORD2_END_DOLLAR=3.294, 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 WhdrWhpAsR9S; Fri, 9 Aug 2013 02:37:43 -0700 (PDT) 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 CFBC221F9DCB; Fri, 9 Aug 2013 02:37:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1376041061; d=isode.com; s=selector; i=@isode.com; bh=UBL/TWis1urPSB1LuiInCdF6OHKa11ugTv87X9GLrDY=; 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=Knl4UTqbWDrslpB/XbphXqeUAOPc78gttb93kvnBMjCAzUpz7HCOsq6G76mCZRSyTXqQia WrHC2GMPCa69aQ4aYqCHwSKIv4P86nAl6UCYp0z6Uz5Ot+UyCvXa2854E/berPts2J9nCX qx6/r45VZCT8F4h4FpbQsMNsu6USB2o=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 9 Aug 2013 10:37:41 +0100 Message-ID: <5204B868.3030304@isode.com> Date: Fri, 09 Aug 2013 10:37:44 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: draft-ietf-geopriv-relative-location.all@tools.ietf.org, apps-discuss@ietf.org References: <5203A1C0.80709@isode.com> In-Reply-To: <5203A1C0.80709@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IESG Subject: Re: [apps-discuss] AppsDir review of draft-ietf-geopriv-relative-location-06 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, 09 Aug 2013 09:37:44 -0000 On 08/08/2013 14:48, Alexey Melnikov wrote: > Hello all, > > 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-geopriv-relative-location-06 > > Title: Relative Location Representation > Reviewer: Alexey Melnikov > Review Date: 8 August 2013 > > > Summary: The document is nearly ready for publication. Only minor > fixes are needed, mostly missing references. > > Major issues: > > none Actually there is one new issue: Visual Studio 2010 complains that "application/octet-stream" media type doesn't conform to the media type patter in the XML schema. > Minor Issues: > > In Section 3: > > Optionally, a reference to a 'map' document can be provided. The > reference is a URI. > > URI needs a normative reference. > > The document could be an image or dataset that > represents a map, floorplan or other form. The type of document the > URI points to is described as a MIME media type. > > MIME media type needs a normative reference. > > > 4.9.5.1. XML encoding > > An arc-band is represented in and converted from GML using the > following template: > > xmlns:gs="http://www.opengis.net/pidflo/1.0" > srsName="urn:ietf:params:geopriv:relative:2d"> > $Coordinate-1 $Coordinate-2$ > > $Inner-Radius$ > > > $Inner-Radius$ > > I think you meant $Outer-Radius$ above. > > > > $Start-Angle$ > > > $Opening-Angle$ > > > > 4.11.1. Map URL > > In XML, the map is a element defined within > and contains the URL. The URL is encoded as a UTF-8 encoded string. > An "http:" or "https:" URL MUST be used unless the entity creating > > http/https need Normative references. > > the PIDF-LO is able to ensure that authorized recipients of this data > are able to use other URI schemes. > > 4.11.2.1. Map Reference Point Offset > > The map referenc point uses a type code of 129. > > Typo: referenc > > +------+------+ > | 129 |Length| > +------+------+------+------+ > | Coordinate-1 | > +------+------+------+------+ > | Coordinate-2 | > +------+------+------+------+ > | (3D-only) Coordinate-3 | > +------+------+------+------+ > > Map Reference Point Coordinates TLV > > If omitted, a value containing all zeros is assumed. If the > coordinates provided contain fewer values than are needed, the first > value from the set is applied in place of any missing values. > > I couldn't understand what are you talking about here. Are you talking > about the 3rd coordinate missing? What is "the set"? > > > Nits: > > none From alexey.melnikov@isode.com Fri Aug 9 05:52: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 25F9921F997E for ; Fri, 9 Aug 2013 05:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.771 X-Spam-Level: X-Spam-Status: No, score=-101.771 tagged_above=-999 required=5 tests=[AWL=0.828, 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 gy+xM8Y6Hf3x for ; Fri, 9 Aug 2013 05:52:38 -0700 (PDT) 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 7968521F92A5 for ; Fri, 9 Aug 2013 05:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1376052729; d=isode.com; s=selector; i=@isode.com; bh=tQupTd3vHfbIIjLgmzzWPxuY0kOZgRxuHZUzsfS3e9U=; 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=N8O2Gd/L/md6q1JSt4/2/gBMKFb0I8U64oWkHGayoaRZIDYte4xP0LJcEHreBg9Psn8v+4 fabZVo9iz1uuxmFX3syft2bSWJz4wKtNibbkH6WiCYMVrcGwCoJ0f9UUKrkqf+0Phj1P6v CSC0QHs/GQGd0aoTGVO83SBxIz8CawY=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 9 Aug 2013 13:52:09 +0100 Message-ID: <5204E5F8.7000105@isode.com> Date: Fri, 09 Aug 2013 13:52:08 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Salvatore Loreto References: <51F6283B.1010000@ericsson.com> In-Reply-To: <51F6283B.1010000@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-malformed-mail-07 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, 09 Aug 2013 12:52:39 -0000 On 29/07/2013 09:30, Salvatore Loreto wrote: > this mail is to initiate the WG Last Call on > draft-ietf-appsawg-malformed-mail-07 > ( http://tools.ietf.org/html/draft-ietf-appsawg-malformed-mail-07 ) > the WGLC will end on Friday, August 16th. > > Please send your reviews, as well as expression of support regarding > document readiness for IESG (or not) to the apps-discuss mailing list. > > Comments like "I've read the document and it is OK to publish" or > "I've read the document and it has the following issues" > are useful and would be gratefully accepted by chairs. This is a very useful document. I reviewed it and I think it is ready for publication. I sent information about typos I spotted directly to Murray. From apps-discuss@lapsedordinary.net Fri Aug 9 06:55: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 20AAF21F9C9A for ; Fri, 9 Aug 2013 06:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.639 X-Spam-Level: X-Spam-Status: No, score=0.639 tagged_above=-999 required=5 tests=[AWL=2.317, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] 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 XC0pLYBkMCqQ for ; Fri, 9 Aug 2013 06:55:34 -0700 (PDT) Received: from mail.lapsedordinary.net (thinksmall.vps.bitfolk.com [85.119.83.85]) by ietfa.amsl.com (Postfix) with ESMTP id C25ED21F9C89 for ; Fri, 9 Aug 2013 06:55:34 -0700 (PDT) Received: by mail.lapsedordinary.net (Postfix, from userid 1000) id F004E34023; Fri, 9 Aug 2013 14:45:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lapsedordinary.net; s=mail; t=1376059528; bh=6/ZMgukDPysjX9cSSGd+Dmr97UPBgWIhHEnjY25a/iw=; h=Date:From:To:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=lVKq54d2AQgxDQy5278jaP7mqzPwQ2HzOwru8jVigjZusr4gCuboK8E2Pw9czM1I7 ipYOXg1HMY/QK122CVCwBshthZsSgp4nTGG69ESZ2OoSts6JzAWHbGZPqgaxY2GAFV O4EAj2fGD8DgY/X31DmjQnTBTbU/JgntdzEj4AR8= Received: from localhost (localhost [127.0.0.1]) by mail.lapsedordinary.net (Postfix) with ESMTP id E945C34021 for ; Fri, 9 Aug 2013 14:45:28 +0000 (UTC) Date: Fri, 9 Aug 2013 14:45:28 +0000 (UTC) From: Martijn Grooten X-X-Sender: martijn@home.lapsedordinary.net To: "apps-discuss@ietf.org" In-Reply-To: <5204E5F8.7000105@isode.com> Message-ID: References: <51F6283B.1010000@ericsson.com> <5204E5F8.7000105@isode.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-malformed-mail-07 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, 09 Aug 2013 13:55:39 -0000 On Fri, 9 Aug 2013, Alexey Melnikov wrote: > This is a very useful document. I reviewed it and I think it is ready for > publication. I sent information about typos I spotted directly to Murray. +1 I think I've previously said how I think a document like this would be very useful. I've read through this version and I think it's very good - and ready to be published. Martijn. From internet-drafts@ietf.org Fri Aug 9 09:15: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 5864021F99C2; Fri, 9 Aug 2013 09:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.004, 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 QhHrxuo7Sr1h; Fri, 9 Aug 2013 09:15:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA4121F9C7E; Fri, 9 Aug 2013 09:07:20 -0700 (PDT) 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.70.p1 Message-ID: <20130809160720.15582.5916.idtracker@ietfa.amsl.com> Date: Fri, 09 Aug 2013 09:07:20 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-17.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, 09 Aug 2013 16:15: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 : WebFinger Author(s) : Paul E. Jones Gonzalo Salgueiro Joseph Smarr Filename : draft-ietf-appsawg-webfinger-17.txt Pages : 25 Date : 2013-08-09 Abstract: This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-17 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-17 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 johnl@iecc.com Fri Aug 9 11:42: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 3DEEC21F9C76 for ; Fri, 9 Aug 2013 11:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.94 X-Spam-Level: X-Spam-Status: No, score=-105.94 tagged_above=-999 required=5 tests=[AWL=-3.341, 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 G1VHzAMVS+7y for ; Fri, 9 Aug 2013 11:42:14 -0700 (PDT) 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 5E15221F9B86 for ; Fri, 9 Aug 2013 11:34:01 -0700 (PDT) Received: (qmail 53047 invoked from network); 9 Aug 2013 18:34:01 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 9 Aug 2013 18:34:01 -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=52053619.xn--hew.k1308; i=johnl@user.iecc.com; bh=J75nmR1gAw39zHPYlVWLxG862f+nISS+dxqQ/eGKkio=; b=NTRsZelk23OJQp6x6WoYvgha/z/KeveKul1z8G9dn9bYAwzEAl0KwxwzNEyIKzWUJEGiPQc4KZ8AbD+EHq0DGlEsd4gefynICAQK2zvC7/RSv0Z5/hreNXPqfbdMJZVUBtTigl/AgEamGJPXqg5BEZrbszn4cDZruFVf9lzh+nNoQ6PR2GoukC9J8XNkYO2Jq40aj/oMh+wdLmNa3sKKMG0X6VSE2O5fwfePPJ+zvU951dEqkDzsvS6vDzHNr0FR 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=52053619.xn--hew.k1308; olt=johnl@user.iecc.com; bh=J75nmR1gAw39zHPYlVWLxG862f+nISS+dxqQ/eGKkio=; b=k8xfeoifzrkqLaa9SVIebnshOjjb8hZdA4cEtx+u4z+DqGb7oNT2WbuMH3pNu9bnP3gU9DLT52QcdW/Z6eVqBfSTtoErdA96KUzEUi0C+hvuI2UmYZeeYR0zcEYmZwNc6gD8ngEWVKGdrdM8bRGSaVWL+Pym5LydOcmyP85GUXOe8nEsqrQsFoot+Pujyem8dORAzlgQkfFxAZNGAQ9H9dmybevMQpb45qY2qpqwvXaFpOX9P+byZ5qZoDpRQP+D Date: 9 Aug 2013 18:33:38 -0000 Message-ID: <20130809183338.68581.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <51F6283B.1010000@ericsson.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-malformed-mail-07 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, 09 Aug 2013 18:42:18 -0000 I've read it and find its advice useful. Before publication, I'd want to combine or otherwise reconcile sections 7.5 and 7.8 which address the same issue using different words. In 7.8, the advice is to combine duplicated headers, which works for the From and Subject headers in the examples, but what about Date or Sender ? This shouldn't be hard to fix. Otherwise it's fine. R's, John From martin.thomson@gmail.com Fri Aug 9 12:22: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 3330F21F9C6F; Fri, 9 Aug 2013 12:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.119, 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 50+FLKPGeH8K; Fri, 9 Aug 2013 12:22:18 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0905121F9CA4; Fri, 9 Aug 2013 12:15:59 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id hq12so54075wib.8 for ; Fri, 09 Aug 2013 12:15:59 -0700 (PDT) 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=P80X2GWxj+KN8MQRcIAotFWswVu1xzQmFUH0eR05jqg=; b=pRdcidlps6o6xqI500MMoX7u1d5nnpQSvgxqWo98PED0/IBEjjC2+tgsJvXaERH5tD p83zrtM58bNtvF+O7iw9bwqVOpcjNu2z8syowuaWdSDR3/Dg0RsTNZIlMwFqS86Ieiss ORUHTufnUh7SEFLZzu0eaBr3u4aeXsezcPUYUC703ZjbQshZvReNYT/qiFPM2p6zytkZ aE63qcY72Nka3BTAy26hBZLIdPzAR7wdEWNPb9YapDr33zMt0szQb0eyC97QjW/3DBYu y6OzIXaRUEG48G2FNb8qG5ts5nYM2Y9k5ioZTzC+u1mZ7a+4OoO4iCPfNbKr5fBuMwII lNYw== MIME-Version: 1.0 X-Received: by 10.194.78.110 with SMTP id a14mr1234019wjx.84.1376075759165; Fri, 09 Aug 2013 12:15:59 -0700 (PDT) Received: by 10.194.28.39 with HTTP; Fri, 9 Aug 2013 12:15:59 -0700 (PDT) In-Reply-To: References: Date: Fri, 9 Aug 2013 20:15:59 +0100 Message-ID: From: Martin Thomson To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=UTF-8 Cc: "draft-bormann-cbor-04.all@tools.ietf.org" , "gen-art@ietf.org" , IETF Apps Discuss Subject: Re: [apps-discuss] Gen-ART review of draft-bormann-cbor-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, 09 Aug 2013 19:22:20 -0000 On 5 August 2013 18:43, Joe Hildebrand (jhildebr) wrote: > Sorry, my response is also correspondingly long. I'll be brief. Though Joe missed my point on several of his rebuttals (which I found to be an odd thing to do anyway), I see no reason to quibble. I think that the bulk of the comments are valid, though I might disagree on several. From hallam@gmail.com Fri Aug 9 13:30: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 919FF21F9DAA; Fri, 9 Aug 2013 13:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 ufrSwvlQUNL9; Fri, 9 Aug 2013 13:30:05 -0700 (PDT) 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 786DE21F9D04; Fri, 9 Aug 2013 13:23:50 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id k13so3834728wgh.13 for ; Fri, 09 Aug 2013 13:23:49 -0700 (PDT) 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=lZt2kAum6Lhz6sJP+VZLDs6zCLH27vodXKdpafMc3sU=; b=sqO/Ixbmju/+Hxj0FXBksN9R6Qf5OQ6KIMDnBX4/qBsQIB+ObcHV1RRkPq6EVFLWOe pMZU66RIRcwndpVE8etl0hv89CSQWvyPBUbVeTVVb4m4tnhg+MsJH2+Z9LUKuJIxWhQ8 juNsKOZykykvHAIqNvuwxuZtHkMA4LvtyrAS2aWJfzq6s6EIkWNe2eUfZXGNfzaobj7H nMAQ/dRmShIyEiag7c1I7p+rAUOallznftvpKks27BRtZStQ+lylGWF2zGabmi+FIzIF MAWf5MuFGb+rOrHJN5qK/tly9yf7Rw/r1YuQSZeDm85vGbxq624TrOyUii+wNZx47/3v dvqw== MIME-Version: 1.0 X-Received: by 10.180.95.133 with SMTP id dk5mr1181291wib.33.1376079829481; Fri, 09 Aug 2013 13:23:49 -0700 (PDT) Received: by 10.194.6.67 with HTTP; Fri, 9 Aug 2013 13:23:49 -0700 (PDT) In-Reply-To: References: Date: Fri, 9 Aug 2013 16:23:49 -0400 Message-ID: From: Phillip Hallam-Baker To: Carsten Bormann Content-Type: multipart/alternative; boundary=f46d0444e87f6b418c04e3898da9 Cc: draft-bormann-cbor-04.all@tools.ietf.org, General Area Review Team , "ietf@ietf.org Mailing List" , IETF Apps Discuss Subject: Re: [apps-discuss] Gen-ART review of draft-bormann-cbor-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, 09 Aug 2013 20:30:06 -0000 --f46d0444e87f6b418c04e3898da9 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 8, 2013 at 3:58 PM, Carsten Bormann wrote: > On Jul 30, 2013, at 09:05, Martin Thomson > wrote: > > > What would cause this to be tragic, is if publication of this were > > used to prevent other work in this area from subsequently being > > published. > > Indeed. > > As Paul and I have repeatedly said, CBOR is not trying to be the final, > definitive, binary object representation for all purposes. It was written > to some specific objectives, clearly stated in the document. It is being > proposed for standards-track because specific ongoing work that works well > with these objectives will benefit greatly from being able to reference a > common specification. If the objectives for other work are different, that > work may benefit from using a different format, existing or newly designed. > I do not expect you to succeed in being the final definitive format. But if you are not prepared to try then I don't want the result. You keep talking about your design requirements, but where are the use cases that drive them? When I am discussing a specification I am always referring to illustrative use cases that motivate the requirements. When you are discussing your spec you wave away every objection by saying it isn't a design requirement but I have never seen you give the rationale. Coming back to Martin's comments about the type system. I think that is what JSON does so well. It has exactly as much type system as is useful and no more. The developers realized that there was no need to distinguish lists and sets because both are going to serialize as lists on the wire. -- Website: http://hallambaker.com/ --f46d0444e87f6b418c04e3898da9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Aug 8, 2013 at 3:58 PM, Carsten Bormann &= lt;cabo@tzi.org> wrote:
On Jul 30, 2013, at 09:05,= Martin Thomson <martin.thom= son@gmail.com> wrote:

> What would cause this to be tragic, is if publication of this were
> used to prevent other work in this area from subsequently being
> published.

Indeed.

As Paul and I have repeatedly said, CBOR is not trying to be the final, def= initive, binary object representation for all purposes. =A0It was written t= o some specific objectives, clearly stated in the document. =A0It is being = proposed for standards-track because specific ongoing work that works well = with these objectives will benefit greatly from being able to reference a c= ommon specification. =A0If the objectives for other work are different, tha= t work may benefit from using a different format, existing or newly designe= d.

I do not expect you to succeed in being th= e final definitive format.

But if you are not prep= ared to try then I don't want the result.


You keep talking about your design requirements, but where a= re the use cases that drive them? When I am discussing a specification I am= always referring to illustrative use cases that motivate the requirements.= When you are discussing your spec you wave away every objection by saying = it isn't a design requirement but I have never seen you give the ration= ale.

Coming back to Martin's comments about the type sys= tem. I think that is what JSON does so well. It has exactly as much type sy= stem as is useful and no more. The developers realized that there was no ne= ed to distinguish lists and sets because both are going to serialize as lis= ts on the wire.=A0
=A0

--
Website: http://hallambaker.com/
--f46d0444e87f6b418c04e3898da9-- From pierre@nothos.net Fri Aug 9 16:09: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 057EE21F9E22 for ; Fri, 9 Aug 2013 16:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBGvYTNh4jDD for ; Fri, 9 Aug 2013 16:09:40 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by ietfa.amsl.com (Postfix) with ESMTP id 8118F11E810D for ; Fri, 9 Aug 2013 16:03:25 -0700 (PDT) Received: from mfilter15-d.gandi.net (mfilter15-d.gandi.net [217.70.178.143]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id D5DA6172089 for ; Sat, 10 Aug 2013 01:03:13 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter15-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter15-d.gandi.net (mfilter15-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id rNPDgxjonauc for ; Sat, 10 Aug 2013 01:03:11 +0200 (CEST) X-Originating-IP: 80.112.184.89 Received: from nothos.net (5070B859.static.ziggozakelijk.nl [80.112.184.89]) (Authenticated sender: pierre@nothos.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id E835B172055 for ; Sat, 10 Aug 2013 01:03:09 +0200 (CEST) Received: by nothos.net (sSMTP sendmail emulation); Sat, 10 Aug 2013 01:03:07 +0200 From: "Pierre Thierry" Date: Sat, 10 Aug 2013 01:03:06 +0200 To: apps-discuss@ietf.org Message-ID: <20130809230304.GC1895@amoureux.home> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+OVWeTxrbAwQuiek" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [apps-discuss] CBOR and BULK (was Re: Gen-ART review of draft-bormann-cbor-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, 09 Aug 2013 23:09:47 -0000 --+OVWeTxrbAwQuiek Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 08, 2013 at 09:58:17PM +0200, Carsten Bormann wrote: > [CBOR] was written to some specific objectives, clearly stated in > the document. Hi all, I just subscribed to this list and just learned the existence of CBOR. A few days ago, I just submitted a few independant I-D specifications also for a binary object representation. It's very interesting because many of our objectives are the same. The main differences, as I see them, are that I didn't base my data model on JSON's and that I didn't specifically cared about constrained environments. I was more aiming at implementation simplicity in general and it paid off as a side-effect: I think my current design can be parsed on a class 0 node. Also, the balance between the requirement on future extensibility and size of wire data is different, my design being a bit more verbose than CBOR. I also envisioned a jump table parser like CBOR's, but in my case, I always use a whole byte as marker, where CBOR use 3 bits. > As Paul and I have repeatedly said, CBOR is not trying to be the > final, definitive, binary object representation for all purposes. I would expect it to be an established fact that no single binary format can accomplish both simplicity of parsing, generality, extensibility and optimal size of wire data and processing speed. I don't see how a general and extensible format could do as well as formats like Ethernet, TCP/IP, Ogg or DivX. But for the rest, from documents, images, or executables to RPC messages, I suspect the jury should still be out. One format to rule them all might be possible. Maybe I suffer from a bit too much enthusiasm, but I hope BULK might be able to do just that (at least I'm sure it could be the basis of something that does). I'm implementing a simple BULK reader/writer and I plan to implement a few utilities before March (a file compressor/encrypter, BULK/XML and BULK/JSON translators, an archive creator), as I was hoping to attend the IETF meeting in London. Here are the I-Ds: https://datatracker.ietf.org/doc/search/?name=3Dthierry-bulk&activedrafts= =3Don&sort=3D I would be glad to hear feedback on BULK from CBOR's authors. Regards, Pierre Thierry --=20 pierre@nothos.net OpenPGP OxD9D50D8A --+OVWeTxrbAwQuiek Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlIFdSYACgkQxe13INnVDYqcqACg9PYnHuT20BJfqCR+lCY8A1YH recAnAtPHO64637Go79+jJ4nsOnmM5BG =cXMp -----END PGP SIGNATURE----- --+OVWeTxrbAwQuiek-- From marc@petit-huguenin.org Thu Aug 8 07:47:54 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 CD7A021E809E; Thu, 8 Aug 2013 07:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id po7uUdPve8Vl; Thu, 8 Aug 2013 07:47:54 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id C73C121E809D; Thu, 8 Aug 2013 07:47:53 -0700 (PDT) Received: from [IPv6:2601:9:4b80:1a3:e85d:abbe:a7b8:a55f] (unknown [IPv6:2601:9:4b80:1a3:e85d:abbe:a7b8:a55f]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 83E552021A; Thu, 8 Aug 2013 16:47:51 +0200 (CEST) Message-ID: <5203AF95.5010300@petit-huguenin.org> Date: Thu, 08 Aug 2013 07:47:49 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: S Moonesamy References: <6.2.5.6.2.20130804152246.0c672f50@elandnews.com> In-Reply-To: <6.2.5.6.2.20130804152246.0c672f50@elandnews.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 10 Aug 2013 09:47:41 -0700 Cc: draft-petithuguenin-behave-turn-uris.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-petithuguenin-behave-turn-uris-05 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, 08 Aug 2013 14:47:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Thanks for your review. After discussion between authors, we decided to keep the ABNF as it is in the document, but to update the design note. Here's a first draft of the revised design note: "o The ABNF in this document duplicates the , , and productions and other dependent productions from [RFC3986], instead of referencing them. This is because the definitions in RFC 3986 are for hierarchical URIs, so using these references in an opaque URI made reviewers think that a hierarchical URI parser could be used to parse the URIs defined in this document." As for the RFC 2119 boilerplate, it follows the new boilerplate suggestion at http://trac.tools.ietf.org/group/iesg/trac/wiki/Draft2119BoilerplateSuggestions, minus the keywords not used in the document. Thanks. On 08/04/2013 04:25 PM, 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. > > Document: draft-petithuguenin-behave-turn-uris-05 Title: Traversal Using > Relays around NAT (TURN) Uniform Resource Identifiers Reviewer: S. > Moonesamy Review Date: August 4, 2013 IETF Last Call Date: July 19, 2013 > > Summary: This document is nearly ready for publication as a Proposed > Standard. > > This document defines two URI schemes to provision the TURN Resolution > Mechanism. > > Major issues: None > > Minor issues: > > The Terminology Section is different from the usual RFC 2119 boilerplate. I > am listing this as a minor issue for the attention of the Apps ADs. > > This document restates the ABNF from RFC 3986. I suggest including it by > reference. Please note that I read Appendix B. > > Nits: > > This review does not include editorial nits. > > Regards, S. Moonesamy > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBCAAGBQJSA6+UAAoJECnERZXWan7EqOoQALutBKNXxUuBwcHCPk8imbgZ bY6/3l7FngiGCBvLEsDNIQuh516AYuPbSnkw9uV7GB1O1NdBO9o37Zrsq8uyhLRC wYqG/ZnQ/2zfSeQbS/mkXXoNQy34p0CaVz4YIB2wMc+YNicW9/i1chW+uT4r4ax5 Ez2qxloaLXZRCy6eAh0r0Gqgw7dU1VhjxmCPezrz++OaJjoFDA/vThzetyCUEoWq gPkZ3P07E0v6MqPgyHFYet6oIrLjbw7yHQbnzNsFePWMV6NaAGg9YNSWayISBxKS S2b2G7pWuwhze2SiIRwocaLjCeDt20v9RWCPKloZ4lzvY41GIZ62bpneji2bnCPU YXm3rLQ1iQtsjDA3ycCS2Mf50xRV+5IR09ZYF7URyCsM9vRO7R8Kuqp4FJXxVcdm EPWk3AbgEtYwKeUrco5kjcm4OVAylDMMsH4nnhgU8u3P+gNq0gqPoVrTUmrqoePx lgcVEP3tEq8btjYoYc7GXuraPayGQqbDLDYEQKcZhIs5U6S6JjwZ96aawV5eVTD0 MbIY3VCCPLBsSzxRky+a9qMPC/B2nLiBEXrziLxGRMoL+j2PefBo+jHGCb+u/tt0 IPmAndwaVFp1j1ba3Hj4QrQV2bFS70HD0FhJPSyGHr/HCv5xnTKGM1fQg/vs0TI6 6PUPhbO5rXFmEchd9Lvl =Buh4 -----END PGP SIGNATURE----- From mary.ietf.barnes@gmail.com Thu Aug 8 16:17: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 4431111E8161; Thu, 8 Aug 2013 16:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.386 X-Spam-Level: X-Spam-Status: No, score=-102.386 tagged_above=-999 required=5 tests=[AWL=0.213, 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 ap5WHpsOtx2e; Thu, 8 Aug 2013 16:17:04 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 25CA821F9A51; Thu, 8 Aug 2013 16:16:49 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id s1so1885177qcw.37 for ; Thu, 08 Aug 2013 16:16:49 -0700 (PDT) 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=ahXsmnH3sC/CZJzm4r1ciE0v/x5wWpK+Wk+6L+y+ums=; b=jk34DDcqmH1nKJF15aGxsVHcZ2JwaBy+9V8pgAqZKki1yq05lSZwdBExTORpMr/IRN jxwuyqhtOEc0EL160Sqg09SQEtpq56dvaf/tPTVIe0Pd6wWlEnrQCz6CVw3MewtTnSA+ k5R5yzeaAHg5l0TYWulog9Mig/Yog03u/dEm5HC8sYZK3IA0Ev2+9cN5RxUZr6c2xlzQ Ov6tPZtwp9UKV80Br9RMFr2qO2K80M2qr5G+dkzX8tU0SFXa36RS7TPSlJEeVNQsNNrJ VUaOeH0wxJMoLDYgd4zMhbvO911uuCLaXXdbjUPOxAKqsgUMH6M9lRJvWgZiw1b3d8X1 mSKg== MIME-Version: 1.0 X-Received: by 10.49.28.9 with SMTP id x9mr8585934qeg.8.1376003809324; Thu, 08 Aug 2013 16:16:49 -0700 (PDT) Received: by 10.49.48.36 with HTTP; Thu, 8 Aug 2013 16:16:49 -0700 (PDT) In-Reply-To: <2BBEF519D867E04EA729626C246A978702E7A200@eusaamb101.ericsson.se> References: <2BBEF519D867E04EA729626C246A978702E7A200@eusaamb101.ericsson.se> Date: Thu, 8 Aug 2013 18:16:49 -0500 Message-ID: From: Mary Barnes To: Glenn Parsons Content-Type: multipart/alternative; boundary=047d7bdc077443b59204e377daf2 X-Mailman-Approved-At: Sat, 10 Aug 2013 09:47:50 -0700 Cc: "draft-yusef-dispatch-ccmp-indication.all@tools.ietf.org" , "apps-discuss@ietf.org" , IESG Subject: Re: [apps-discuss] AppsDir review of draft-yusef-dispatch-ccmp-indication-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: Thu, 08 Aug 2013 23:17:06 -0000 --047d7bdc077443b59204e377daf2 Content-Type: text/plain; charset=ISO-8859-1 Hi Glenn, Sorry for the delay in responding. Thanks for your careful review. Our responses are below [MB]. Mary On Fri, Jul 19, 2013 at 5:21 AM, Glenn Parsons wrote: > Hello all, > > 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-yusef-dispatch-ccmp-indication-04 > > Title: Conference Focus Indicating CCMP Support > > Reviewer: Glenn Parsons > Review Date: July 19th, 2013 > > Summary: The document is needs some improvements in explanation and then > would be ready for publication. > > Major issues: > > There are 4 approaches described here. And two are standardized. The > abstract indicates that pros/cons are explained, but these only appear for > the two not chosen. The reader would benefit from understanding the > difference in choosing between the two approaches standardized. Further, > what is the recommendation for the two not chosen? Could these still be > used and they are shown as a guide? Or must they not be used? > [MB] Very good point. We did have some of this text in earlier versions and can pull that back into this version. For the Call-Info header (section 2.1), the following is the reason it was selected as a preferred solution - we can add this to the first paragraph right after the intro sentence: The use of the Call-Info header is consistent with SIP in terms of the mechanism by which a UA determines the capabilities of a SIP intermediary. It also enables the discovery of the CCMP capability by any network element that is not using the conference event package. For section 2.2, we can add text something like the following after the first sentence: Note that the definition of an additional URI 'purpose' of 'ccmp' associated with the 'confs-uris' element in the SIP conferencing event package was also considered (as discussed in A.2). However, it was decided that the use of the 'service-uris' element was a bit cleaner since clients that had no interest in CCMP wouldn't need to even bother looking at that element in the event package. As far as the two not chosen, since both require specification (i.e., IANA registrations), it wouldn't make sense for someone to use those. We included them in the appendix for completeness in case someone later asked why we didn't standardize those approaches. We can add a paragraph in the appendix reflecting this and note that the consensus of the community at the time of this specification was that the two mechanisms being standardized in this specification were more than sufficient. [/MB] > > Minor Issues: > > In the abstract: > > ...the XCON conference event package RFC 4575 [RFC4575] ... This appears > to be incorrect. Do you want to refer the RFC 6502 or 4575 here? I > suspect it is the former, and if so some mention of this in the body of the > document (like in 2.1 with XCON-URI) is needed as well as a reference. > [MB] Yep - you are correct.[/MB] > > In the Introduction: > > RFC 5238 [RFC5239] defines a... -> RFC 5239 [RFC5239] defines a... > [MB] We'll fix this. [/MB] > > In 2.1, 4.2: > Focus -> conference focus. Perhaps a reference to the definition of this > term would be helpful. > [MB] We probably should reword the first paragraph of section 2 to provide some more background, introducing the term, maybe something like the following: This section defines two mechanisms that can be used to discover whether the conference which a client has joined, per the SIP signaling procedures defined in RFC 4579, supports CCMP. Specifically, the mechanisms allow the client to know that the URI representing the conference focus, as defined in RFC 4579 and RFC 5239, is an XCON-URI as defined in RFC 6501. [/MB] > > > Nits: > > None. > --047d7bdc077443b59204e377daf2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Glenn,

Sorry for the delay in respon= ding. =A0Thanks for your careful review. =A0Our responses are below [MB].

Mary


On Fri, Jul 19, 2013 at 5:21 AM, Glenn Parsons <glenn.parsons@eri= csson.com> wrote:
Hello all,

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 m= ay receive. Please wait for direction from your document shepherd or AD bef= ore posting a new version of the draft.

Document: =A0draft-yusef-dispatch-ccmp-indication-04

Title: Conference Focus Indicating CCMP Support

Reviewer: Glenn Parsons
Review Date: July 19th, 2013

Summary: The document is needs some improvements in explanation and then wo= uld be ready for publication.

Major issues:

There are 4 approaches described here. =A0And two are standardized. =A0The = abstract indicates that pros/cons are explained, but these only appear for = the two not chosen. =A0The reader would benefit from understanding the diff= erence in choosing between the two approaches standardized. =A0Further, wha= t is the recommendation for the two not chosen? =A0Could these still be use= d and they are shown as a guide? =A0Or must they not be used?
The use of the Call-Info header is consistent with SIP in terms of the mechanism by which a UA determines the capabilities of a SIP intermediary. It also enables the discovery of the CCMP capa= bility by any network element that is not using the conference even= t package.

For section 2.2, we can add text something like the following aft= er the first sentence:

Note that the = definition of an additional URI 'purpose' of 'ccmp' associ= ated with the 'confs-uris' element in the SIP confere= ncing event package was also considered (as discu= ssed in A.2). However, it was decided that the use of the 'service-uris= ' element was a bit cleaner since clients that had no interest in CCMP = wouldn't need to even bother looking at that element in the event packa= ge.

As far as the two not chosen, since both= require specification (i.e., IANA registrations), it wouldn't make sen= se for someone to use those. We included them in the appendix for complete= ness in case someone later asked why we didn't standardize those approa= ches. We can add a paragraph in the appendix reflecting this and note that= the consensus of the community at the time of this specification was that = the two mechanisms being standardized in this specification were more than = sufficient.
[/MB]

Minor Issues:

In the abstract:

...the XCON conference event package RFC 4575 [RFC4575] ... This appears to= be incorrect. =A0Do you want to refer the RFC 6502 or 4575 here? =A0I susp= ect it is the former, and if so some mention of this in the body of the doc= ument (like in 2.1 with XCON-URI) is needed as well as a reference.
[MB] Yep - you are correct.[/MB]=A0

In the Introduction:

=A0RFC 5238 [RFC5239] defines a... -> =A0RFC 5239 [RFC5239] defines a...=
[MB] We'll fix this. [/MB]=A0

In 2.1, 4.2:
Focus -> conference focus. =A0Perhaps a reference to the definition of t= his term would be helpful.
[MB] We probably should rew= ord the first paragraph of section 2 to provide some more background, intro= ducing the term, =A0maybe something like the following:

This secti= on defines two mechanisms that can be used to discover whether the conferen= ce which a client has joined, per the SIP signaling procedures defined in R= FC 4579, supports CCMP. Specifically, the mechanisms= allow the client to know that the URI representing the conference focus, a= s defined in RFC 4579 and RFC 5239, is an XCON-URI as defined in RFC 6501. =
[/MB]=A0


Nits:

None.

--047d7bdc077443b59204e377daf2-- From ray.polk@oracle.com Sat Aug 10 14:12: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 CB23D21F99D2; Sat, 10 Aug 2013 14:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 XeLGnhPR8f3V; Sat, 10 Aug 2013 14:12:21 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id E041B21F9957; Sat, 10 Aug 2013 14:03:12 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7AL32kh017212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 10 Aug 2013 21:03:02 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7AL2xbI002505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Aug 2013 21:02:59 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7AL2wjQ029020; Sat, 10 Aug 2013 21:02:58 GMT Received: from [192.168.1.77] (/68.89.236.138) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 10 Aug 2013 14:02:58 -0700 Message-ID: <5206AA6C.5080702@oracle.com> Date: Sat, 10 Aug 2013 15:02:36 -0600 From: ray polk Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Claudio Allocchio , draft-bormann-cbor.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org References: <0c97e5e4-52b2-44e7-b910-5343d4f55d4b@default> <52052B51.1010202@oracle.com> <0d21de34-1a6d-4265-89f2-c1f581afead8@email.android.com> In-Reply-To: <0d21de34-1a6d-4265-89f2-c1f581afead8@email.android.com> Content-Type: multipart/alternative; boundary="------------010602070801010705050301" X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: Re: [apps-discuss] review of draft-bormann-cbor-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: Sat, 10 Aug 2013 21:12:26 -0000 This is a multi-part message in MIME format. --------------010602070801010705050301 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I have been selected as the Applications Area Review Team reviewer for this draft. For background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team Document: draft-bormann-cbor-04 Title: Concise Binary Object Representation (CBOR) Reviewer: Ray Polk Review Date: 10 August 2013 Summary: This draft is ready for publication as a Proposed Standard. Major Issues: - none -- After pouring over the binary/hex and the mapping to/from json, I couldn't find a single mistake. It meets its objectives and addresses the primary issues of msgpack (extensibility, open standard, different types for string and byte streams) Minor Issues: - none Editorial / Nits: 2. - Consider striking "For the impatient reader," or rephrasing for tone. - Consider referring to the type section after "...the major type (the high-order 3 bits)..." ? - "Every item between the byte string with the indefinite length indicator and..." Consider something like "...CBOR item with type byte string..." ? 2.3. - Consider swapping the last two paragraphs; providing detail about simple type before discussing floating point (to match order laid out in Table 1). 2.4. - consider continuing the use of "preceded by" as found in the first sentence; perhaps eliminating the "enclosed by" phrasing. use of the term "enclosed by" implies a closing "break" or closing tag. - "A secondary purpose it to allow..." > "A secondary purpose is to allow..." - consider using MAY in this section to highlight its optional nature. 2.4.3. - consider breaking up the run-on sentence that begins: "An example of a decimal fraction is that the number 273.15..." 3. - Much of section 3 could be condensed (or even moved into an informational RFC?). It's a little verbose/redundant. The most helpful bits are obfuscated/diluted by the less helpful ones. For example, sections 3.2.2 & 3.2.3. are redundant. consider making them one paragraph instead of three: A parser may come across a simple value Section 2.3 or a tag Section 2.4 that it does not recognize, such as a value that was added to the IANA registry after the parser was deployed or a value that the parser chose not to implement. Further, a parser might or might not want to verify that the sequence of bytes in an UTF-8 string (major type 3) is actually valid UTF-8. In these cases, the parser might issue a warning, might stop processing altogether, might handle the error and make the incorrectly-typed value available to the application as such, or take some other type of action. I think similar improvements could be made to other 3.x subsections. Appendix E The draft states, "BSON specification is 'baroque,' clouded by requirements for DB" -- consider adding a corresponding objective that this violates and citing it here. > On 7/17/2013 1:25 PM, Ray Polk wrote: > > I will complete a review by August 9th. Regards, Ray ----- > Original Message ----- From: Claudio.Allocchio@garr.it To: > ray.polk@oracle.com Cc: appsdir@ietf.org Sent: Wednesday, July > 17, 2013 11:45:17 AM GMT -07:00 US/Canada Mountain Subject: > review of draft-bormann-cbor-04 Hello Ray, could you please > perform a review of draft-bormann-cbor-04 by August 13th > (which is the LC end date) ? Please let us know and ack ! > thanks indeed and all th best! > ------------------------------------------------------------------------ > Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior T! > echnical 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 > > --------------010602070801010705050301 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I have been selected as the Applications Area Review Team reviewer for this draft.  For background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team
 
Document: draft-bormann-cbor-04
Title: Concise Binary Object Representation (CBOR)
Reviewer: Ray Polk
Review Date: 10 August 2013

Summary: This draft is ready for publication as a Proposed Standard.

Major Issues:
- none -- After pouring over the binary/hex and the mapping to/from json, I couldn't find a single mistake.  It meets its objectives and addresses the primary issues of msgpack (extensibility,  open standard, different types for string and byte streams)

Minor Issues:
- none

Editorial / Nits:
2. 
- Consider striking "For the impatient reader," or rephrasing for tone.
- Consider referring to the type section after "...the major type (the high-order 3 bits)..." ?
- "Every item between the byte string with the indefinite length indicator and..."
Consider something like "...CBOR item with type byte string..." ?

2.3.
- Consider swapping the last two paragraphs; providing detail about simple type before discussing floating point (to match order laid out in Table 1).

2.4.
- consider continuing the use of "preceded by" as found in the first sentence; perhaps eliminating the "enclosed by" phrasing.  use of the term "enclosed by" implies a closing "break" or closing tag.
- "A secondary purpose it to allow..." > "A secondary purpose is to allow..."
- consider using MAY in this section to highlight its optional nature.

2.4.3.
- consider breaking up the run-on sentence that begins:  "An example of a decimal fraction is that the number 273.15..."

3.
- Much of section 3 could be condensed (or even moved into an informational RFC?).  It's a little verbose/redundant.  The most helpful bits are obfuscated/diluted by the less helpful ones.

For example, sections 3.2.2 & 3.2.3. are redundant.  consider making them one paragraph instead of three:

A parser may come across a simple value Section 2.3 or a tag Section 2.4 that it does not recognize, such as a value that was added to the IANA registry after the parser was deployed or a value that the parser chose not to implement.  Further, a parser might or might not want to verify that the sequence of bytes in an UTF-8 string (major type 3) is actually valid UTF-8.  In these cases, the parser might issue a warning, might stop processing altogether, might handle the error and make the incorrectly-typed value available to the application as such, or take some other type of action.

I think similar improvements could be made to other 3.x subsections.

Appendix E
The draft states, "BSON specification is 'baroque,' clouded by requirements for DB" -- consider adding a corresponding objective that this violates and citing it here.

On 7/17/2013 1:25 PM, Ray Polk wrote:

I will complete a review by August 9th.

Regards,
Ray

----- Original Message -----
From: Claudio.Allocchio@garr.it
To: ray.polk@oracle.com
Cc: appsdir@ietf.org
Sent: Wednesday, July 17, 2013 11:45:17 AM GMT -07:00 US/Canada Mountain
Subject: review of draft-bormann-cbor-04


Hello Ray,

could you please perform a review of draft-bormann-cbor-04 by August 13th
(which is the LC end date) ?

Please let us know and ack !

thanks indeed and all th best!



Claudio Allocchio             G   A   R   R          Claudio.Allocchio@garr.it
Senior T!
 echnical
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

--------------010602070801010705050301-- From paul.hoffman@vpnc.org Sat Aug 10 15:58: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 8C1E221F8D0D; Sat, 10 Aug 2013 15:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.331 X-Spam-Level: X-Spam-Status: No, score=-102.331 tagged_above=-999 required=5 tests=[AWL=0.268, 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 m2FwfX5cxy4U; Sat, 10 Aug 2013 15:58:23 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 61B8F21F99C1; Sat, 10 Aug 2013 15:52:40 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r7AMnq68086850 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 10 Aug 2013 15:49:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <5206AA6C.5080702@oracle.com> Date: Sat, 10 Aug 2013 15:49:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0c97e5e4-52b2-44e7-b910-5343d4f55d4b@default> <52052B51.1010202@oracle.com> <0d21de34-1a6d-4265-89f2-c1f581afead8@email.android.com> <5206AA6C.5080702@oracle.com> To: ray polk X-Mailer: Apple Mail (2.1508) Cc: iesg@ietf.org, apps-discuss@ietf.org, draft-bormann-cbor.all@tools.ietf.org Subject: Re: [apps-discuss] review of draft-bormann-cbor-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: Sat, 10 Aug 2013 22:58:23 -0000 Thanks for the review! Many of your editorial clarifications will appear = in the -05. --Paul Hoffman= From olaf@NLnetLabs.nl Sun Aug 11 04:41: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 0725621F84B1; Sun, 11 Aug 2013 04:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.073 X-Spam-Level: X-Spam-Status: No, score=-101.073 tagged_above=-999 required=5 tests=[AWL=-1.528, BAYES_00=-2.599, FRT_ADOBE2=2.455, J_CHICKENPOX_42=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 ln4J6kIXvRa0; Sun, 11 Aug 2013 04:41:08 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D20B21F9FA7; Sun, 11 Aug 2013 04:34:07 -0700 (PDT) Received: from [IPv6:2001:980:2282:1:c9bb:a125:a7c7:a355] ([IPv6:2001:980:2282:1:c9bb:a125:a7c7:a355]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id r7BBXxGD081975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 11 Aug 2013 13:34:01 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl DKIM-Filter: OpenDKIM Filter v2.8.3 open.nlnetlabs.nl r7BBXxGD081975 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1376220843; bh=izHjUQlDG+fmhlRXMovzA+L9CYRYXdrLNKFGtdrT4p8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=GjTuOw8KoYHJyOPro0zWSrIrSLSluLZ39dy9e2zgX+3kso+1ZFM6jjk9rDy6U2kEX Uc0jpqKnFxpeS0zR+cWwAxZ/2PC7LwmEUtUD0lj2VI+SNIvprjNDF9ku2ANzFW4ig7 e2N1aCCqm1T2DwOy20xQLNClC2sFu4bprYapIlJs= Content-Type: multipart/signed; boundary="Apple-Mail=_8E067A84-22A9-4FB9-8C2A-6212DA2E74DF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Olaf Kolkman In-Reply-To: Date: Sun, 11 Aug 2013 13:33:58 +0200 Message-Id: <11D5DC92-4993-4D50-A243-C87FEF70B116@NLnetLabs.nl> References: To: Larry Masinter X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Sun, 11 Aug 2013 13:34:02 +0200 (CEST) X-Mailman-Approved-At: Mon, 12 Aug 2013 00:27:27 -0700 Cc: draft-ietf-weirds-using-http.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org, "weirds@ietf.org Group" Subject: Re: [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 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, 11 Aug 2013 11:41:09 -0000 --Apple-Mail=_8E067A84-22A9-4FB9-8C2A-6212DA2E74DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Larry, [ Adding the WG, for transparency purposes. ] In my role of doc-shepherd I've put some comments in-line. Overall I am = trying to tease out the actionable bits and try to suggest some = resolutions. I leave it to the document editors to come up with concrete = text. It is clear to me that addressing Larry's comments will lead to a better = context which will help future implementors. Thanks for that Larry. On Jul 31, 2013, at 2:19 PM, Larry Masinter wrote: > I have been selected as the Applications Area Directorate reviewer for = this draft (for background on appsdir, please see = =E2=80=8Bhttp://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDir= ectorate ). >=20 > Please resolve these comments along with any other Last Call comments = you may receive. Please wait for direction from your document shepherd = or AD before posting a new version of the draft. >=20 > Document: draft-ietf-weirds-using-http-07 > Title: HTTP usage in the Registration Data Access Protocol (RDAP) > Reviewer: Larry Masinter=09 > Review Date: 7/31/2013 > IETF Last Call Date: [include if known] > IESG Telechat Date: On agenda of 2013-08-15 IESG telechat > Summary: The document needs quite a bit of editorial work, but the = protocol itself seems OK, modulo a few questions. >=20 > Major Issues/Minor issues: I think the document suffers enough = editorial confusion that they rise to the level of "Major" >=20 > Please define what "Registration Data" is on first use. > Please define what "Registration Data Directory Services" are. > Please supply a reference for "RESTful" >=20 > Please explain what you mean by "better" in: > "By giving the various Directory Services common > behavior, a single client is better able to retrieve data from > Directory Services adhering to this behavior." > Better how? >=20 > Please explain or give an example about what is insufficient in: > "the WHOIS protocol is insufficient to > modern registration data service requirements." >=20 >=20 > The sentence > =E2=80=9D Where complexity may reside, it is the goal of this = document..." > is awkward, suggest just striking "Where complexity may > reside". >=20 >=20 > Please explain who "SSAC" is and why their opinion about WHOIS is = relevant. > in " As is noted in SSAC Report ..." >=20 > Please give a reference for RDAP >=20 This whole set of comments suggest that for somebody not active in the = Internet Registry world this work falls out of thin air. At IETF last = call Subremanian Moonesamy had similar comments. I believe your = suggestions for expansions would go a long way fixing that. >=20 > Section 2 Terminology: > " In this document, an RDAP client is an HTTP User Agent performing = an > RDAP query, and an RDAP server is an HTTP server providing an RDAP > response. RDAP query and response formats are described in other > documents in the collection of RDAP specifications, while this > document describes how RDAP clients and servers use HTTP to = exchange > queries and responses." >=20 > I think you're defining a way of layering RDAP-like functionality = using > HTTP instead of something lower level. This doesn't seem like = "terminology" -- > this document defines a kind of RDAP client and a kind of RDAP server. Action: Change of header ? >=20 > Section 3 "Design Intents" >=20 > Neither "design intents" or "design ctriteria" seems to fit > what you're talking about. "Design constraints"? "Design > considerations" ? Notable "design decisions" ? >=20 > I don't understand whether restricting responses to zero or one > result is a difficult or onerous constraint. >=20 Suggested action: Change the first sentence to: "In this document made a number of design choices are made"=20 > "First, each query is meant ..." Each RDAP query itself? In all RDAP > applications ever? If not, in what circumstances? Which RDAP > queries have this constraint? >=20 I believe this to be Each RDAP query by all RDAP applications ever. If = that is a misunderstanding (and the working-group will no-doubt correct = me if I misunderstand) then we probably need clarifying text . > Is it the "semantics" of the "request/response" that allows > for future response formats? I think you're saying something > about the protocol being extensible in the future to allow > other formats than JSON. >=20 Correct. Would adding something like "i.e. the protocol is extendable to = allow other formats than JSON" help to clarify? > Moving "including cache control, authorization, compression, and > redirection" to after "HTTP offers a number of mechanisms" (surrounded = by > parentheses) will make the sentence clearer.=20 Clear action. >=20 > However, I'm not convinced that you can avoid giving more > specific advice about how cache control, authorization,=20 > compression and redirection work with RDAP. For example, > the cache-busting section indicates that cache control headers > aren't sufficient. >=20 > How will RDAP over HTTP work on a hotel network which redirects HTTP > requests each day at noon? I do not recall this to be discussed in detail in the WG. Are there = references for generic approaches to these sort of problems?=20 Also, how specific does this need to be given that the protocol serves a = specify use case with specific users (producers and clients of Internet = Registry data that is currently published in WHOIS databases). The actions are either "don't be more specific", add a reference, or add = text.=20 >=20 > " an RDAP specific JSON media > type, the generic JSON media type, or both." >=20 > Please be explicit "application/json" for "the generic JSON media = type" > and give an explicit example of "an RDAP specific JSON media type" > and provide references where those are defined. Those seem very clear suggestions for resolution, thanks. Action: Editorial clarification. >=20 > 5.1 Positive Answers >=20 > can you be more explicit about what kind of response is expected? Would it be sufficient to refer to the fact that a JSON object will be = returned? >=20 > Please address the use of HTTPS with TLS vs. HTTP. Would a reference to = http://tools.ietf.org/html/draft-ietf-weirds-rdap-sec suffice? >=20 > I question the use of 404 Not Found to indicate "no information > regarding the query", since it doesn't distinguish between "no = information" > and "wrong query". Not sure what you mean with 'wrong query'. If you mean "Malformed Query" then that is addressed by section 5.4.=20= If you mean "No business asking" then that is addressed in the last = paragraph of 5.3. >=20 > Please be more explicit about "a RDAP-HTTP Server" rather than > "a server" in 5.3, 5.4 etc. >=20 Clear action. > " Optionally, it MAY > include additional information regarding the negative answer in the > HTTP entity body." > how can this be used interoperably with such little specified? >=20 > I admit I am baffled by the Extensibility section 6, since I can't see > how it allows extensions.... for what? Under what cicumstances? > How do you distinguish between known and unknown extensions? >=20 > Section 7: Security Considerations > Normally, a security considerations section might outline threats > and mitigations for them. This section doesn't seem to. I think this is also where we see that the specifications are a bit = targeted to a specific audience of Internet Registry producers and = clients. I am of the impression that the WG wants to keep the mesh of normative = cross references to other documents to a minimum. but maybe a reference = to http://tools.ietf.org/html/draft-ietf-weirds-rdap-sec would help here = to? >=20 > Section 9.1 URIs and IRIs > This is confusing, of course clients can use whatever internally > they want. =20 >=20 > How is a "URI" used in a response? The response is RDAP information. e.g. in redirects. >=20 > Transforming URIs to IRIs is a potentially buggy heuristic process > and should not be recommended here. The Internationalization aspects have been discussed ad nausea in the = WG. Most of the i18n takes place in constructing the query = (http://tools.ietf.org/html/draft-ietf-weirds-rdap-query) there the only = elements that are subject to i18n are the DNS names used(in the queries) = and their translation is well defined. So what is left for transforming the URIs is the mapping between A- and = U- Labels for the domain part of the URI itself.=20 (Would sort of clarification help in the document?) >=20 > 9.2=20 > "Under most scenarios" -- a few scenarios would be helpful. >=20 Action for editors? Thanks for the Review. --Olaf --Apple-Mail=_8E067A84-22A9-4FB9-8C2A-6212DA2E74DF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJSB3amAAoJEFRqER47aqpkfBwP/jaqqM1l8VN7Pvo5QHcNvkze QjWFSk0vwm78I1wddDkTmN3/Ra4NPvBa/uAvi93jEBlkZtUJVbQUx1H+PGusTD1K 1g2ZXw6gPZQF6o7NtIiC27mwIXqEkQGlTrua8Cd7zyQBkVmz8J583PNjLsz1zNgt 3M4n3VD0IX3z7R14lehL40dFtu0vTCn2TWd6wsJxFTAHVOqp/CvLCjJ+8/0am2YG 8KS13Bte/t8MbgeT9wRiX48NX17+bb/RgLQzF/Vk5WMD/pOpdeNRbrSLQtKAtYPG B5wphMfXjKtCzaIuWgw4i/AY1KSZUPNLTriXOXOk43Owli6WuitzTK/NzkJz+0ST euC9xaE+kcZx/dLD+pFKgBy84u5RctrXgQrcBKgTf/b65KkPbBB+nuCpaEeqmaHn 8RZX7XuqDY/y1nQhI/hqGGXJUnhfAatTpvyg1TM8WT7kVDnq/jJvCTYhflnoDJa3 DvEChyDjouLOyeCSimQDuU63XVO1kGQjqXtwuD1/tRUZT7isqYuorOz5gYkSGvKa cx+icd0FSxu4TKYqNbixaXz3C7EKoxblSs/XPBJke+dQDzuNVa+dZwyINBpkieNC YPA1bJ63zphp6ddz3hRmRrgboYGoULw009c1IPopw8ZnIcj7JxeeWrkMZmyWIEd/ TOcsI71iQaVfM8FyPxfO =qWXl -----END PGP SIGNATURE----- --Apple-Mail=_8E067A84-22A9-4FB9-8C2A-6212DA2E74DF-- From cabo@tzi.org Mon Aug 12 12:28: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 1902721F9976; Mon, 12 Aug 2013 12:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.166 X-Spam-Level: X-Spam-Status: No, score=-105.166 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 s7+aBbeGXauj; Mon, 12 Aug 2013 12:28:45 -0700 (PDT) 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 D8A0921F994C; Mon, 12 Aug 2013 12:28:44 -0700 (PDT) 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 r7CJSW8A004192; Mon, 12 Aug 2013 21:28:32 +0200 (CEST) Received: from [192.168.217.105] (p54894F9F.dip0.t-ipconnect.de [84.137.79.159]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E2C59ED8; Mon, 12 Aug 2013 21:28:31 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Mon, 12 Aug 2013 21:28:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Joe Hildebrand (jhildebr) X-Mailer: Apple Mail (2.1508) Cc: "draft-bormann-cbor-04.all@tools.ietf.org" , "gen-art@ietf.org" , IETF Apps Discuss Subject: Re: [apps-discuss] Gen-ART review of draft-bormann-cbor-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: Mon, 12 Aug 2013 19:28:51 -0000 On Aug 5, 2013, at 19:43, Joe Hildebrand (jhildebr) = wrote: > Sorry, my response is also correspondingly long. =20 The present message wraps up the more general comments sent by Joe Hildebrand concerning CBOR. Lots of juicy comments. Thanks to all! For these, we are not using the line-by-line style because many of the topics were touched on by more than one person. A separate message will follow with line-by-line replies to the more specific comments. # Data model ## Extensibility It is easy to fall into the trap of optimizing for the current environment. Experience says there will be some future requirements that are genuinely unknown today, which may require extending a format in unforeseen ways. CBOR plans for this by leaving ~ 10 % of the encoding space unused (additional information 28..30). There is fundamentally no way to guarantee backward compatibility for this kind of unpredicted extension process. Leaving code space unallocated may allow for forward compatibility, though. CBOR also will be used in multiple environments. Instead of forcing each environment to invent their own format, CBOR allows adapting the format by providing extensible tagging and extensible primitive ("simple") values. Both are based on registries. Tags are more important in practice (and likely to be more numerous). The tagging scheme even allows first-come-first-served registration. Obviously, there is a trade-off between adaptability and interoperability. CBOR tries to maximize interoperability by allowing a generic parser to easily handle tags and primitives the registration of which it is not aware of. This will also enable evolving the decoders and the applications using them on separate timescales, if that is desired. We have the same cognitive dissonance as everybody else about opening the floodgates to extensibility. The alternative, making it painful or impossible to adapt the spec to a specific environment, is not necessarily more desirable. Many existing data formats make extensibility impossible; if a protocol or application wants one of those, that's fine; in fact, some of the other data formats that have been brought up since we started the discussion of CBOR have also chosen the "no extensibility" path. ## Tags CBOR has a number of predefined tags. This is one of the pain points for extensibility: most tags will not be of interest to some application or protocol developers, but having them specified early in the process will lead to better interoperability for those who want them. During the early development of the spec, Paul and I disagreed about which tags should be in the first RFC, but ultimately it doesn't really matter because the choice of tags is up to the protocol or application that uses CBOR. For all of these tags, a specific CBOR application will specify which of them are actually in use. There is little disagreement that we need a tag for a date/time format; there is probably no way to agree on a single one, so the document currently includes both RFC 3339 and epoch-based formats. Bignums (integer) may be less obvious to some, they are very obvious in other environments. Having (extended precision) base2 floating point as well as a base10 floating point in there also seems obvious for those environments that need it. These are the typical programming language types. YAGNI doesn't apply; leaving them out of the spec just means that there likely will be several, incompatible versions of them. Four tags on strings indicate further likely kinds of data. Nesting CBOR encoding into a byte string seems natural to support. We also included tags for URIs, regular expressions, and MIME messages (OK, maybe less obvious). Then we have two tags that indicate that a text string is encoded in Base64/Base64url (33/34). The argument could be made that these could be decoded and sent as byte strings; however, there may be a need to keep the exact format (whitespace and padding), e.g. for signature checking. Tags 21-23 do the inverse: they tag byte strings with the base encoding that any JSON converter on the path should be using. Converter hints may be a new concept in a data format; in a world where JSON is widely used in processing chains, they could be eminently useful (Paul and I still disagree on this one.) Tags can be nested. Actually, since every tag specifies its possible contents, none of the tags specified in -04 can be nested. To cite an obvious example where nested tagging would be used, tag 1 accepts a floating point value and might be changed to also accept a base10 floating point value (tag 1 currently does not allow that, though). Disallowing the nesting of tags just forces a protocol designer to turn tag1(tag2(x)) into something more complex like tag1([tag2(x)]). We don't think forcing the introduction of this complexity reduces complexity. For an implementation that does know both tags, the processing will be natural. Any other implementation can ignore the unknown tags or (preferably) hand them to the application in a similar way the other containing data structures are handed to the application (i.e, tagx(y) is not much different in handling from [x, y] or {x: y}). A later BCP might want to warn specifiers of future tags that designing them in such a way you get recursion (as opposed to mere nesting) is not such a good idea, but you have to come up with very contrived examples before that becomes a concern. # Encoding issues ## Numbers Interchanging numbers is a much more complicated issue than one would think. Recent discussions of number precision issues in the JSON WG show that it is easy to underestimate the problem and get this wrong. In the area of integer numbers, CBOR is highly opinionated in favor of unsigned (i.e., non-negative) numbers =97 this is what is actually needed in the majority of applications. Many applications also will clearly need negative numbers, so they have their own encoding. Obviously, if you encode N bits for a negative number, you need N+1 bits in a signed representation of that since you need to add the sign bit. We chose to keep N at 8, 16, 32, 64, so N+1 has a slightly odd size, which implementers indeed need to be aware of if that is larger than their number range (not a problem, e.g., for JavaScript). CBOR protocols should be explicit about the number range and precision that is expected to be supported. In the area of floating point numbers, CBOR ignores IEEE 754 decimal numbers (in favor of its own, simpler format) and only supports three sizes of the IEEE 754 binary floating point numbers. That is, again, opinionated (but can be fixed in a pinch by introducing appropriate tags). The inclusion of 16-bit floating point is motivated by its usefulness for low-precision sensor data. The reason this may not be obvious to many is likely that programming languages evolve on time scales where this 2008 addition to IEEE 754 is still very, very recent. ## Maps As with most modern programming languages, CBOR has a map type; this is intended to be a general map and not to be limited to text string keys as in JSON objects. Dependent specifications have already been started that make good use of non-text keys. In particular, integer keys are a good match for environments that already maintain some form of registry based on integers. CBOR maps are intended to be maps, not multimaps. Duplicate keys are an encoding error. Unfortunately, what should be considered duplicate is often application dependent (are 0 and 0.0 the same key? "=C5" and "=C5"?), so a generic parser will only be able to do part of the work. CBOR maps do not ascribe meaning to the order of items in the map. This is hard to prescribe in the format; it is a requirement on the applications using it. # Implementation issues Complexity/Code size: We will leave an assessment of that to those who have implemented the spec (and we have heard from a few). The pseudo-code in Appendix C should give some impression how a minimal implementation could look like. Performance: Memory allocation indeed is a significant contributor to the CPU use of a format decoder. CBOR tries to help a bit by providing right at the start of a data item the size of the object that needs to be allocated (as opposed to the length of its representation as in ASN.1 BER). Of course, that is not possible in indefinite length encoding ("streaming"); here we trade off some additional CPU in the decoder (needed for reallocation/copying of unknown-length structures) against less complexity in the encoder, for those cases where the encoder would need to perform significant buffering to obtain these sizes before encoding a data item. # Document issues We are open to suggestions for replacement words for "well-formed" and "valid" in Section 3.7. A definition of "valid" is not actually needed; that term is only used in its English sense in the discussion of generic parsers (and the connotation with XML's sense of valid is unfortunate). "Well-formed" is defined algorithmically in the pseudocode in Appendix C. For a binary format, there is a strong requirement for a diagnostic notation that everyone understands that is trying to get an application going. So defining it in the document is the best way to get this. This definition is not needed for interop, so we can do away with ABNF etc. I started out by saying something equivalent to "MUST NOT be parsed", but an RFC 2119 MUST struck me as silly when diagnostic notation is not meant for interop in the first place. (Also, there might be tools for encoding test vectors etc. that do parse diagnostic notation; in -05, we have added a pointer to YAML as another format that may be useful for text-based specification of CBOR data items in configuration files.) Gr=FC=DFe, Carsten From barryleiba.mailing.lists@gmail.com Mon Aug 12 12:56: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 D168C21F9D18; Mon, 12 Aug 2013 12:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.248 X-Spam-Level: X-Spam-Status: No, score=-101.248 tagged_above=-999 required=5 tests=[AWL=-0.759, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, 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 N09rG1txlm2t; Mon, 12 Aug 2013 12:56:31 -0700 (PDT) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 27D6B21F9D05; Mon, 12 Aug 2013 12:56:31 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id cy12so2874509veb.18 for ; Mon, 12 Aug 2013 12:56:30 -0700 (PDT) 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=nWUMmJCLU+HjXvOzMAcI22mmUL99uS4ZWaiVQ0wMvtI=; b=qBn/iGaDSbmGRzswm5Q31aLo/HrY5iO2e5c9Ew/rm7ncA4+3UWbOzb2SkOhQQaqlaT EkPf9aeZN962r/kgbJs99jjUw6otE8dqIoESFf2EpjB44mfksqpQ3wYMObn9czDlv5ZA g+dhCsY3w+gTZHKNUBugx69fGp60sv+MYqCrkyAieAr05kp7pNIk8qeLosdSISundrig lnFwxqtKh24H5bxWq/6WQJ4nXAIfgjWgSDrj39gMN9pyhc7aDyCHwCwiEg7NK1IuhNzG MtIJL9kmaFfkyWKty5sfwG18jJ6ti7G9s+g1BYsmyJv6FHL+bFpVZcpWEjB6EQ/6pJTx yWrg== MIME-Version: 1.0 X-Received: by 10.58.73.202 with SMTP id n10mr573312vev.7.1376337390518; Mon, 12 Aug 2013 12:56:30 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.137.227 with HTTP; Mon, 12 Aug 2013 12:56:30 -0700 (PDT) In-Reply-To: <11D5DC92-4993-4D50-A243-C87FEF70B116@NLnetLabs.nl> References: <11D5DC92-4993-4D50-A243-C87FEF70B116@NLnetLabs.nl> Date: Mon, 12 Aug 2013 21:56:30 +0200 X-Google-Sender-Auth: Tsy_8L7DMNmN89XyakoOHxW6fms Message-ID: From: Barry Leiba To: Olaf Kolkman Content-Type: text/plain; charset=ISO-8859-1 Cc: "weirds@ietf.org Group" , draft-ietf-weirds-using-http.all@tools.ietf.org, IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 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, 12 Aug 2013 19:56:32 -0000 >> I question the use of 404 Not Found to indicate "no information >> regarding the query", since it doesn't distinguish between "no information" >> and "wrong query". > > Not sure what you mean with 'wrong query'. > If you mean "Malformed Query" then that is addressed by section 5.4. > If you mean "No business asking" then that is addressed in the last paragraph of 5.3. 404 is meant to say that the URL you're asking for doesn't exist (or the server isn't willing to disclose that it exists). When you use HTTP to retrieve a web page, there doesn't need to be a distinction between "the web page doesn't exist" and "the web page is empty" (that is, there's no information for me to give you). I'll just give you no information. When you use RDAP, presumably there *is* a useful distinction between the two. Larry's questioning whether it's wise to use 404 for the latter -- what you're asking for exists, but there's nothing to say about it. And so the question is whether there's a useful distinction in RDAP between "you're querying about something that doesn't exist" and "you're querying about something that exists, but there's no information available about it." If not, then 404 might be OK. If so, though, there should be different status codes, and 404 belongs to the former. Barry From cabo@tzi.org Mon Aug 12 13:37: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 1E2C921F9FD6; Mon, 12 Aug 2013 13:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.098 X-Spam-Level: X-Spam-Status: No, score=-105.098 tagged_above=-999 required=5 tests=[AWL=-1.015, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 oW6sw8fnEPk4; Mon, 12 Aug 2013 13:37:35 -0700 (PDT) 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 9502421F9E45; Mon, 12 Aug 2013 13:37:35 -0700 (PDT) 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 r7CKbUYQ012599; Mon, 12 Aug 2013 22:37:30 +0200 (CEST) Received: from [192.168.217.105] (p54894F9F.dip0.t-ipconnect.de [84.137.79.159]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 38411F01; Mon, 12 Aug 2013 22:37:29 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Mon, 12 Aug 2013 22:37:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2B377A8B-C954-4DEE-B19C-506CE8B295A2@tzi.org> References: To: Joe Hildebrand (jhildebr) X-Mailer: Apple Mail (2.1508) Cc: "draft-bormann-cbor-04.all@tools.ietf.org" , "gen-art@ietf.org" , IETF Apps Discuss Subject: Re: [apps-discuss] Gen-ART review of draft-bormann-cbor-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: Mon, 12 Aug 2013 20:37:47 -0000 On Aug 5, 2013, at 19:43, Joe Hildebrand (jhildebr) = wrote: > Sorry, my response is also correspondingly long. There are some = original > comments at the end=20 [...] We have worked a bit on the detail remarks of your review. (The previous message addressed the grander aspects). Item-by-item replies below: Other things that ought to be discussed: I would like to see another design goal: "May be implemented in = modern web browsers". That should be possible with the new binary types. Indeed, implementability on a wide set of platforms is an important goal, somewhat implicit in out objective 2. I believe the design goal was achieved. I still don't see the need for non-string map keys. JSON = mapping would be easier without them, as would uniqueness checking. If they are = to be retained, they should have some motivation in the spec, = describing how and why they might be used. I'm not sure they particularly need to be motivated in the spec. = However, we will add something like "For example, using numbers for keys is useful in cases where the values are numeric and numeric ordering of keys is = important." Further, data formats have been using complex map keys for a long time, e.g. cf. YAML. As an example, CBOR (diagnostic notation) { {"country": "DE", "license": "HB-MH 765"}: {"make": "Ford", "km": = 192735.2}, {"country": "FI", "license": "601 ICE"}: {"make": "BMW", "km": = 68923.1} } might be used to describe a map of cars, indexed by their license plate, where the license plate uses a country identifier and the plate text as its two components. In JSON, I would be forced to munge together the unrelated country and license strings using some custom delimiter syntax (say, "DE/HB-MH 765"); in CBOR (or YAML), I can keep them nice and semantic. In YAML: --- ? country: DE license: HB-MH 765 : make: Ford km: 192735.2 ? country: FI license: 601 ICE : make: BMW km: 68923.1 As always, protocols based on CBOR do not have to use this functionality; in section 3.4 we encourage using strings, or integers, as map keys (and =BBkeys should be of a single CBOR type=AB). I wish I could think of another good simple value that we might = register one day. The only one I've come up with is "no-op", which I = might use in a streaming application as a trivial keep-alive or a marker = between records to ensure parser state sync. I wouldn't classify that = as "good" however. This is indeed the less likely avenue of extension of the format. However, as an example, we would have used simple values for the Infinities and NaN if the IEEE 754 formats didn't already provide a good representation. Nested tags ought to be forbidden until we come up with a strong = use case for them. The tag 55799 ("self-describing CBOR", allowing to start a CBOR data item with 0xd9d9f7 for file type disambiguation) in -05 is a pretty strong use case; you should be able to use it independent of whether the data item is top-level tagged or not. I could use some implementation guidance on how to generate the = most compact floating-point type for a given number, assuming we keep = all of the floating-point types. I hope to have my C code for this on github, soon... I did it like this: void cbor_encoder_write_double(double v) { float fv =3D v; if (fv =3D=3D v) { // i.e., the 32-bit float value doesn't lose data // ... do the same thing for half; encode as half or single } else { // ... encode as double } } If your platform doesn't give you the necessary floating point types, but you have (possibly coded yourself) the bitwise access to the floating point representation you need to send binary doubles, this is a bit more work, which I haven't done yet (it will probably look a bit like the Python code in Appendix D). I don't like 2.4.4.2 "Expected Later Encoding for CBOR to JSON Converters". Having a sender care about the encoding of a = second format at the same time seems unnecessarily complex. I'd like to see = this section and the corresponding tags moved to another spec, or = just removed. I think we have a pretty good use case in constrained implementations that marshal data for later use a CBOR to JSON converter. (See other message.) Similar for tags 33 and 34. Just send the raw bytes as a byte = string; there's no need to actually base64 encode. (See other message.) Section 3.2.3, we should call out the heresy of including UTF-16 surrogates encoded as UTF-8 for those that can't read the UTF-8 = spec. I'm with you on the subject matter, but I'm not sure if adorning normative references with "hey, we really mean this" should be necessary... Overall in section 3.2, "should probably issue an error but = might take some other action" seems like it will cause some interop = surprises in practice. -05 will have some cleanups here. Section 3.3, "all number representations are equivalent" is = unclear, even with the clarifying phrase afterward. Slightly clarified. If section 3.6 stays, the numerics need more work. +/- Infinity = should be treated like NaN. (Why?) "if the result is the same value" would benefit from some more clarity. The tags section is also somewhat unclear. Clarified slightly. Section 4.2, what about numbers with uninteresting fractional = parts, like 1.0? What about numbers in exponential format without = fractional parts, like 1e10? I would recommend against even suggest encoding in = place. It's likely to cause a security issue for the reason mentioned. Clarified in -05 that it is actually warning against the in-place strategy. Section 6, including the diagnostic notation is a little = strange. I would at least like "it is not meant to be parsed" to be strengthened = to "MUST NOT be parsed". (See other message.) Section 7.1, simple values 0..15 can never be used with this = construction. If that's intentional, then give a good reason. (Fixed the wording based on IANA input.) Section 7.2, do we have language we can use about how to reclaim first-come-first-serve tags that aren't being used anymore? = e.g. the web page is down and the requestor may be dead. It is generally impossible to reclaim IANA values once assigned -- even if the requestor is no longer active, the data may still be in use on the wire or in some archive. Our registry should be no different than anyone else's. In section 7.3, yes, we should make "application/mmmmm+cbor" = valid. Added section 7.4 based on text suggested by Tony Hansen. In section 8, perhaps mention a stack attack like: 0x818181818181818181... I implemented depth counting with a maximum as an approach to = avoid this. There are likely to be lots of other security concerns. Added a paragraph on resource exhaustion attacks. I have checked all of the examples in Appendix A. I would have = expected 2(h'010000000000000000') | 0xc249010000000000000000 Not 18446744073709551616, since in the diagnostic, I don't = necessarily support bignums. Same with 0xc349010000000000000000. I prefer to keep the explanatory value of actually giving the decoded bignum value. Text added: =BBIn the diagnostic notation provided for bignums, their intended numeric value is shown as a decimal number (such as 18446744073709551616) instead of showing a tagged byte string (such as 2(h'010000000000000000')).=AB For numbers, section 9.8.1 of ECMA-262 (JSON.stringify) is = relevant. So: 5.960464477539063e-8 | 0xf90001 (not e-08) 0.00006103515625 | 0xf90400 (not e-05) Changed this way in -05. In Appendix B, there are holes in the jump table. If you're = going to have a table, call out the invalid values, such as 0x1c-0x1f. This may be shortened to rather call out the remaining valid values. Done in -05. In Appendix C, the use of the variable "breakable" is unclear, = and it's not obvious how you'll get to the "no enclosing indefinite" = case. breakable starts out as false. It is given as true where instead of a data item a "break" stop code is allowed to occur. The "no enclosing indefinite" case is reached if breakable is not set and an 0xFF is encountered anyway. In Appendix D, shouldn't the input be unsigned or an array of = bytes? It could also be unsigned short (which would be widened to int anyway), but in this case it shouldn't matter. (Array of bytes would just be slightly more tedious.) Appendix E.1, aren't there some cases of DER where you need the = schema to parse? As opposed to in BER? I'm not aware of that. (DER is a restricted subset of BER.) DER and BER are not exactly enabling schemaless decoding; they have in common that that implicit tagging may hide the data type information so you may need the schema information (ASN.1 definition) to find out the actual data type in use. (However, you can parse the surface structure of a BER/DER object without schema information.) We included this not because it is an alternative to CBOR, but because its use in the IETF is widespread. Add PER. PER does need schema information even for parsing and would require its own little dissertation, so we left this off. Appendix E, we should mention Smile, since the first two octets = are so cute. :) (Smile was on my initial list of formats to cover in the appendix, but it is rather complicated and would need large amounts of text, beyond what would be appropriate for this little appendix.) Overall, I think this doc shows a lot of promise, and I'm = looking forward to having something on standards track that has these = properties. Thank you for this detailed review! Gr=FC=DFe, Carsten From jhildebr@cisco.com Mon Aug 12 14:41: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 47EAD21F9F44; Mon, 12 Aug 2013 14:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.635 X-Spam-Level: X-Spam-Status: No, score=-10.635 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 BLiHwp8MECFP; Mon, 12 Aug 2013 14:41:49 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0B18F21F9EE1; Mon, 12 Aug 2013 14:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1544; q=dns/txt; s=iport; t=1376343709; x=1377553309; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=hh5P89+HJrpOPIUiHsJwPmEDK+1zKRZsomVxADyZp2A=; b=BcJibycpQD9yqDh0Xq1qUiN6cx0DVweS3rCBEf/zQDcv8tflNIYzn4lo Yk8f6bFGcDDnwkpWZ5vzhUTl1FMjkuKVDC4uQP4ep+Av3KX513tg/z0Bx 6X3yaKHVSeIidyuOz8ZdafXbKUetVCV2Uvhb2UqKyGoRGgQ281LQmbtgh E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFADtWCVKtJXG+/2dsb2JhbABbgwaBBb5XgRwWdIIkAQEBAwE6PwUNAQgOFBRCJQIEDgUIiAIGtnaQCjEHgxt2A5QNlSiDG4Iq X-IronPort-AV: E=Sophos;i="4.89,864,1367971200"; d="scan'208";a="246479680" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 12 Aug 2013 21:41:24 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7CLfNG2019159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Aug 2013 21:41:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Mon, 12 Aug 2013 16:41:23 -0500 From: "Joe Hildebrand (jhildebr)" To: Carsten Bormann Thread-Topic: [apps-discuss] Gen-ART review of draft-bormann-cbor-04 Thread-Index: AQHOjPNCXWeGtSFAj0iRwScRzl7yuJmG2+2AgAuVgwD//61EgA== Date: Mon, 12 Aug 2013 21:41:23 +0000 Message-ID: In-Reply-To: <2B377A8B-C954-4DEE-B19C-506CE8B295A2@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.21.146.155] Content-Type: text/plain; charset="us-ascii" Content-ID: <720240F1A24B6246958F976DA5B2D52E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-bormann-cbor-04.all@tools.ietf.org" , "gen-art@ietf.org" , IETF Apps Discuss Subject: Re: [apps-discuss] Gen-ART review of draft-bormann-cbor-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: Mon, 12 Aug 2013 21:41:55 -0000 On 8/12/13 2:37 PM, "Carsten Bormann" wrote: > If section 3.6 stays, the numerics need more work. +/- Infinity >should be > treated like NaN. > >(Why?) Having more than one way to encode +/- Infinity seems like a recipe for generating slightly different canonical output. For example, in my code right now, I think I'm always generating a half-precision Infinity, and I'm thinking about changing that to always be the 4-byte version. I now see that this section is just a recipe for how to define a canonicalization, not the actual rules you need to follow, and my comment may be moot. However, I suggest that section 3.6 is therefore not terribly useful, and it might be removed without harming the document. > In Appendix D, shouldn't the input be unsigned or an array of >bytes? > >It could also be unsigned short (which would be widened to int >anyway), but in this case it shouldn't matter. >(Array of bytes would just be slightly more tedious.) Agree that it's merely a tedious transformation, but I think it would be a lot more clear. Semantically, the input isn't an integer of any size. It's two bytes in a specific order. > Add PER. > >PER does need schema information even for parsing and would require >its own little dissertation, so we left this off. I think it's useful to call out an example that is explicitly schema-ridden, particularly since it has been called out in this conversation as something relevant. --=20 Joe Hildebrand From martin.thomson@gmail.com Mon Aug 12 14:51: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 DDC0A21F9FD6; Mon, 12 Aug 2013 14:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.114, 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 sMulzN-rECQV; Mon, 12 Aug 2013 14:51:37 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 42FE221F9F9D; Mon, 12 Aug 2013 14:51:37 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w60so6055812wes.15 for ; Mon, 12 Aug 2013 14:51:34 -0700 (PDT) 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:content-transfer-encoding; bh=iT/YWtLfJX7b5J47Ymo5M9Lp1Ne5+pXoAYrpiq7vhvA=; b=PmZCKiCKxH0rQG84QVwSM3cyNDqLBvXoE4n1VNGUa0HsHZ/MnfbLHMegVC+hHiyJQF seuExi+B73xBvm1Nw0CMolFK7H4Ti2msQFFsuvmrqIk4la5Ijvb7GT4ygC+9U6MnXXQ8 K4Y5ecpRfwpYdsNIqjG87Nen5dDcj+txG3xHZQwmLwAXLf2ovOUt9i+78Yde9boyjlpM pZV+ZLU1DR1l++kpCVmyFhSLt4jRdYjG25UIJfMcGplOdyDfQ8dXzdfX2OuZLSMceMI4 u8VWllt4g1l7bYGfAecHL1kdMr0j3CeT2EVdwNtkocdMiHsOpc2JLVZgqNm4UWSpDzS+ C3+g== MIME-Version: 1.0 X-Received: by 10.180.187.2 with SMTP id fo2mr516200wic.65.1376344294802; Mon, 12 Aug 2013 14:51:34 -0700 (PDT) Received: by 10.194.28.39 with HTTP; Mon, 12 Aug 2013 14:51:34 -0700 (PDT) In-Reply-To: References: Date: Mon, 12 Aug 2013 22:51:34 +0100 Message-ID: From: Martin Thomson To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "gen-art@ietf.org" , IETF Apps Discuss , draft-bormann-cbor.all@tools.ietf.org Subject: Re: [apps-discuss] Gen-ART review of draft-bormann-cbor-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: Mon, 12 Aug 2013 21:51:40 -0000 Hi Carsten, I wasn't really looking for a defense of the design in the form you just provided, cogent as it was. I want to know what value you get from these extensibility features, not a reiteration (and expansion) of the characteristics of those features. My operating assumption was that JSON was successful precisely because it was only extensible in one limited direction. In some ways, this is the challenge I wanted to set by writing my review. Can you a) invalidate that theory somehow, and b) motivate the addition of each axis of extensibility. As I said privately, I have no problem with shipping a proposed standard RFC that has a clear set of goals, and I think that you are doing the right thing in that regard. What I really want to do is have is that other conversation. And maybe long review threads are the wrong place for that conversation, I don't know (maybe I'll drop gen-art on my next reply). On 12 August 2013 20:28, Carsten Bormann wrote: > CBOR maps are intended to be maps, not multimaps. Duplicate keys are > an encoding error. Unfortunately, what should be considered duplicate > is often application dependent (are 0 and 0.0 the same key? "=C3=85" and > "=C3=85"?), so a generic parser will only be able to do part of the work. Ouch, really? Add this to the list of things that a using application/specification needs to worry about. SASLprep anyone? Maybe there should be a list of those somewhere in the draft, which includes: The types to implement (and whether to disallow or ignore others) What map keys to permit and how to compare them (with a special note about IEEE 754 NaN values, which might be bit-exact, but don't compare equal) The extension points to implement (and how to ignore 28-30) Whether to allow tags Which tags to ignore What date format(s) to use What to do about JSON if you are performing translation (see tags) What types to permit indefinite length encoding for ... and I'm sure I've missed something --Martin From fanf2@hermes.cam.ac.uk Tue Aug 13 04:15: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 4263721F9EE1; Tue, 13 Aug 2013 04:15:21 -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 S6ukHyXTHJkM; Tue, 13 Aug 2013 04:15:20 -0700 (PDT) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f42]) by ietfa.amsl.com (Postfix) with ESMTP id 8875E21F86DD; Tue, 13 Aug 2013 04:14:30 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:45907) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1V9CYO-000824-81 (Exim 4.80_167-5a66dd3) (return-path ); Tue, 13 Aug 2013 12:14:20 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1V9CYO-0006Af-Do (Exim 4.72) (return-path ); Tue, 13 Aug 2013 12:14:20 +0100 Date: Tue, 13 Aug 2013 12:14:20 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Carsten Bormann In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "ietf@ietf.org Mailing List" , IETF Apps Discuss Subject: Re: [apps-discuss] Gen-ART review of draft-bormann-cbor-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, 13 Aug 2013 11:15:21 -0000 Carsten Bormann wrote: > > The Concise Binary Object Representation (CBOR) is a data format > whose design goals include the possibility of extremely small code > size, fairly small message size, and extensibility without the need > for version negotiation. These design goals make it different from > earlier binary serializations such as ASN.1 and MessagePack, or other > binary serializations that may be created in the future. I have a small problem with this abstract: the three goals that it picks out are satisfied by MessagePack better than CBOR, since MessagePack is simpler so will need even less code. As far as I can tell what makes CBOR different from MessagePack is support for richer types, especially strings. Streaming support is useful but it wasn't one of the original goals. Regarding PHB's criticisms of complexity: Type tags don't really need to be part of the serialization format: they can be encoded in a simpler format by the application. The advantage of doing so would be a more direct translation into typical dynamic language data structures, and better interop with JSON. The disadvantage is slightly more verbosity. You would need a clear tagging convention to replace the syntactic framework. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From sm@elandsys.com Tue Aug 13 05:07: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 D0F0311E8173; Tue, 13 Aug 2013 05:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.174 X-Spam-Level: X-Spam-Status: No, score=-101.174 tagged_above=-999 required=5 tests=[AWL=1.425, 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 b6zXrHCjopz8; Tue, 13 Aug 2013 05:07:37 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C53111E8174; Tue, 13 Aug 2013 05:07:33 -0700 (PDT) Received: from sm-THINK.elandsys.com ([197.224.133.219]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7DC7BoY012433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Aug 2013 05:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1376395651; bh=Q2vWOasHnxPAaJuT0s0gqAbmciIi3zlbvath6OGspfE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HRv1aqtfEbdKaDu1Cz1ZFKR6JKnXeTC+VmHl1FXNgIXKXg6Yv4CaZwRHw5gf272i/ l13KtzgLSTEx4XEXeVA/Gscv8REmuT6K4cQVTpKBCcqmOPEoWqU3hwPsiDxFjL//Ff f3/X20muGfygHeXvF0q88R+xoA3vfS3FWGTJbRoc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1376395651; i=@elandsys.com; bh=Q2vWOasHnxPAaJuT0s0gqAbmciIi3zlbvath6OGspfE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dHapC35/4ig52bdfBkFbTl9d6Loq/XmXj7KKn/B6iejWUmWt7fWyHcKjcALR2o9ek rcEMob0wjlWzf5M152km1zxYj/XdDKhnb8nF00slqWNu4Q6grWc/yH0LtTtrLNfa/G eCIxc584EMkM85vZ4WgB6EJFK7Bm0yH3G+exWQvM= Message-Id: <6.2.5.6.2.20130813040956.0ae736a0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Aug 2013 04:13:30 -0700 To: Marc Petit-Huguenin From: S Moonesamy In-Reply-To: <5203AF95.5010300@petit-huguenin.org> References: <6.2.5.6.2.20130804152246.0c672f50@elandnews.com> <5203AF95.5010300@petit-huguenin.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-petithuguenin-behave-turn-uris.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-petithuguenin-behave-turn-uris-05 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, 13 Aug 2013 12:07:48 -0000 Hi Marc, At 07:47 AM 8/8/2013, Marc Petit-Huguenin wrote: >Thanks for your review. After discussion between authors, we decided to keep >the ABNF as it is in the document, but to update the design note. Here's a >first draft of the revised design note: > >"o The ABNF in this document duplicates the , > , and productions and other dependent > productions from [RFC3986], instead of referencing them. This is > because the definitions in RFC 3986 are for hierarchical URIs, so > using these references in an opaque URI made reviewers think that > a hierarchical URI parser could be used to parse the URIs defined > in this document." Thanks for addressing the comments. Regards, S. Moonesamy From barryleiba@gmail.com Tue Aug 13 05:46: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 50F0E21E812D; Tue, 13 Aug 2013 05:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 fR1053DhYrs1; Tue, 13 Aug 2013 05:46:21 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3520321E8135; Tue, 13 Aug 2013 05:46:19 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id bq6so275749qab.18 for ; Tue, 13 Aug 2013 05:46:17 -0700 (PDT) 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=nIgYVMiAxv7OIFy9GM+Mv5tfNwkqe/gJ4wEkSNfnumo=; b=ya/LKi+CTs7LgXilCAkJz96IxcTHffKDLjbC+2iQ0nwr9Kh0vND+SBp0vdVZd9bN6H ij0PUwZ/aR3COyG9dqxQntHJUsCtcXcHh+EEAkPmIF4+XfcGlsziVsKtDvqqbIUriKPb U0zxZPu+K2UQ51mI8MOUP84egc3+dmWnJ3HoutUb2yepo35b9rRJiNZh9WyUj/uPyy8Z w89DZOyLVb1lBDofoqjFM2/qFKCYbxof5ULYTi6BwSfLAlW213L91Nl8UOGFD12Qji+R De918v6PabLjrZ12ZXlo91a7kbg7mWPkxwY9gdI856zPJTwV1ASuTWs08CbIiPLZ8QK5 PXJQ== MIME-Version: 1.0 X-Received: by 10.224.34.68 with SMTP id k4mr4565564qad.17.1376397977586; Tue, 13 Aug 2013 05:46:17 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.59.211 with HTTP; Tue, 13 Aug 2013 05:46:17 -0700 (PDT) In-Reply-To: <0B607DD5-4ADE-48FB-8B61-8D57421BA87E@NLnetLabs.nl> References: <11D5DC92-4993-4D50-A243-C87FEF70B116@NLnetLabs.nl> <0B607DD5-4ADE-48FB-8B61-8D57421BA87E@NLnetLabs.nl> Date: Tue, 13 Aug 2013 14:46:17 +0200 X-Google-Sender-Auth: 6yinPbn3FWJGNKBjdZROAet0Cxg Message-ID: From: Barry Leiba To: Olaf Kolkman Content-Type: text/plain; charset=ISO-8859-1 Cc: "weirds@ietf.org Group" , draft-ietf-weirds-using-http.all@tools.ietf.org, IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 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, 13 Aug 2013 12:46:22 -0000 >> And so the question is whether there's a useful distinction in RDAP >> between "you're querying about something that doesn't exist" and >> "you're querying about something that exists, but there's no >> information available about it." If not, then 404 might be OK. If >> so, though, there should be different status codes, and 404 belongs to >> the former. > > I can see 3 cases, which (I think) are all addressed: > > * Malformed query (I cannot answer this type of query) (5.4: 400) > * I can parse the query but have no data (5.3 first paragraph: 404) > * I can parse the query but don't want to hand you the data (5.3: 4XX range, with optional information in the body) > > The last option is really of the form "there's no information for me to give you" Hm. Specific example: I make a query to you at this URL: http://rdap.example.com/ip/203.0.113.0/24 That is clearly a properly formed query, so 400 is not on the table. Case 1: You are *not* the right place to ask about 203.0.113.0/24. This is what the HTTP 404 code is meant for, and I would think you'd respond with a 404. Case 2: You *are* the right place to ask about 203.0.113.0/24, but your policies do not allow you to give me the data. This is your third case above, and you will respond with some 4XX code. Case 3: You *are* the right place to ask about 203.0.113.0/24, and your policies allow you to give me the data... but there's just no data to give me. Is this a real case? Can it happen? If it happens, what status code will you send back? If case 3 can't happen, and it really is only cases 1 and 2 (and malformed), then we're done, and the stuff about 404 is fine. If case 3 can happen, we need to talk about it. Barry From barryleiba@gmail.com Tue Aug 13 06:56: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 B068D21E8149; Tue, 13 Aug 2013 06:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 t+r5dE4mi6TP; Tue, 13 Aug 2013 06:56:19 -0700 (PDT) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 132DE21E80D8; Tue, 13 Aug 2013 06:56:15 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id i11so4286761qej.5 for ; Tue, 13 Aug 2013 06:56:15 -0700 (PDT) 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=/hLboLeqb4QV9SsNxrafNzmxLoM5YCHeRJj5XE+P8ik=; b=JtoOs2JRqcf874H4xnyWPuQvRTMKuWJ2jTo47HAGIuZNFb1mB6/eFJmTJ+wanY6KPD 2mCQEYGF2aO+xn2q3pEwkggDZG+FkmU8l8koJOGaloKSov5fkaPUooldYYx5G74IcQUH 1QsNk+tRXVe4oyhDAErufVs880kESZsH1npNmbYXqAiPi9PwUDXjsFV+mJheP+LGkhgO NwGDpR0U6Px59v4zTgHKNaRKS0jFrwoR+0d3LsT6GDogMhMVFfQyzbs2cb8mEwD0NeKP AXyGYJjOXcxkUf30n7i0PWmwdqUpmglUKAWLAOASN9EVKyntnn5T0balH85x7YnlpXs1 saYQ== MIME-Version: 1.0 X-Received: by 10.49.127.179 with SMTP id nh19mr4843814qeb.1.1376402175251; Tue, 13 Aug 2013 06:56:15 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.59.211 with HTTP; Tue, 13 Aug 2013 06:56:15 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Aug 2013 15:56:15 +0200 X-Google-Sender-Auth: Uq1rqnbzy0H6KUnAO9GVIM50Igc Message-ID: From: Barry Leiba To: Andy Newton Content-Type: text/plain; charset=ISO-8859-1 Cc: Olaf Kolkman , "apps-discuss@ietf.org" , "draft-ietf-weirds-using-http.all@tools.ietf.org" , "weirds@ietf.org Group" , IESG Subject: Re: [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 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, 13 Aug 2013 13:56:37 -0000 > In case 3, if 203.0.113.0/24 is not an exact boundary for a network > registration, the proper thing to do according to the query draft is to > return the network registration that encompasses 203.0.113.0/24. Therefore > I think case 3 cannot happen. There are similar semantics for autnum > ranges. For domains, name servers, and entities, either they exist or they > don't. > > Does the help? It does. If it's not possible to have a valid query that's been sent to the right place, but to have no data to return... then we're OK. Perhaps part of the problem here is that using-http seems to depend on rdap-query, but there's no normative reference to rdap-query here (only from rdap-query to using-http). Does using-http really make *any* sense at all without rdap-query? Barry From cabo@tzi.org Tue Aug 13 07:06: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 B772321E8144; Tue, 13 Aug 2013 07:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[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 guUZ88RDRVgE; Tue, 13 Aug 2013 07:06:32 -0700 (PDT) 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 E88AE21E8123; Tue, 13 Aug 2013 07:06:31 -0700 (PDT) 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 r7DE6QK5020593; Tue, 13 Aug 2013 16:06:26 +0200 (CEST) Received: from [192.168.217.105] (p5489267F.dip0.t-ipconnect.de [84.137.38.127]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C710648C; Tue, 13 Aug 2013 16:06:25 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 13 Aug 2013 16:06:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <923B1D67-3325-418A-AFA8-FE1A7543B68D@tzi.org> References: To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.1508) Cc: "gen-art@ietf.org Review Team" , IETF Apps Discuss , draft-bormann-cbor.all@tools.ietf.org Subject: Re: [apps-discuss] Gen-ART review of draft-bormann-cbor-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, 13 Aug 2013 14:06:45 -0000 On Aug 12, 2013, at 23:41, "Joe Hildebrand (jhildebr)" = wrote: > Having more than one way to encode +/- Infinity seems like a recipe = for > generating slightly different canonical output. For example, in my = code > right now, I think I'm always generating a half-precision Infinity, = and > I'm thinking about changing that to always be the 4-byte version. Ah, got it. Infinity/-Infinity are supposed to be covered by the float shortening = rule (which just doesn't work with NaNs). We'll make that explicit. Gr=FC=DFe, Carsten From cabo@tzi.org Tue Aug 13 07: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 43DC021E816C; Tue, 13 Aug 2013 07:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[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 e4LUUbz5AcDU; Tue, 13 Aug 2013 07:29:00 -0700 (PDT) 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 637C521E811A; Tue, 13 Aug 2013 07:28:49 -0700 (PDT) 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 r7DESIAN000411; Tue, 13 Aug 2013 16:28:18 +0200 (CEST) Received: from [192.168.217.105] (p5489267F.dip0.t-ipconnect.de [84.137.38.127]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 75E1F4CC; Tue, 13 Aug 2013 16:28:18 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Tue, 13 Aug 2013 16:28:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tony Finch X-Mailer: Apple Mail (2.1508) Cc: "ietf@ietf.org Mailing List" , IETF Apps Discuss Subject: Re: [apps-discuss] Gen-ART review of draft-bormann-cbor-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, 13 Aug 2013 14:29:06 -0000 On Aug 13, 2013, at 13:14, Tony Finch wrote: > Type tags don't really need to > be part of the serialization format: they can be encoded in a simpler > format by the application.=20 Yes, and we also can get rid of maps {"a": 1, "b": 2}. Just represent them as arrays of two-element arrays [["a", 1], ["b", = 2]]. Or, actually, as arrays where the even-indexed elements are the keys = ["a", 1, "b", 2]. (This is, in the end, close to what happens in the encoder anyway.) There is a reason why we provide some type tagging (here: distinguish = arrays and maps) in the encoding: The decoder may be able to factor out = some common handling that otherwise would need to be done on the = application. In other words, removing maps in the name of simplicity just moves the = complexity elsewhere, in this case to the application. Now, the application may already be prepared to handle the complexity, = and if you come from a JSON world, you are probably *used* to having it = handle the equivalent of CBOR's tags in the application: JSON doesn't = have tags. Supporting applications that do that is a reason why the use = of tags is optional. Gr=FC=DFe, Carsten From paul.hoffman@vpnc.org Tue Aug 13 08:12: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 0206721E818D; Tue, 13 Aug 2013 08:12:50 -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 zuY3yYpdXQzw; Tue, 13 Aug 2013 08:12:49 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5479A21E818A; Tue, 13 Aug 2013 08:12:48 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r7DFCH3J081236 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Aug 2013 08:12:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Tue, 13 Aug 2013 08:12:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tony Finch X-Mailer: Apple Mail (2.1508) Cc: "ietf@ietf.org list" , IETF Apps Discuss Subject: Re: [apps-discuss] Gen-ART review of draft-bormann-cbor-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, 13 Aug 2013 15:12:50 -0000 On Aug 13, 2013, at 4:14 AM, Tony Finch wrote: > Carsten Bormann wrote: >>=20 >> The Concise Binary Object Representation (CBOR) is a data format >> whose design goals include the possibility of extremely small code >> size, fairly small message size, and extensibility without the need >> for version negotiation. These design goals make it different from >> earlier binary serializations such as ASN.1 and MessagePack, or = other >> binary serializations that may be created in the future. >=20 > I have a small problem with this abstract: the three goals that it = picks > out are satisfied by MessagePack better than CBOR, since MessagePack = is > simpler so will need even less code. MsgPack is not extensible. If it was, we might have been able to avoid = all of this. > As far as I can tell what makes CBOR > different from MessagePack is support for richer types, especially > strings. Streaming support is useful but it wasn't one of the original > goals. It *was* part of the original goals; it wasn't part of the original = format. Some people on the AppsAWG list pointed out to us that our = format was not meeting its goals by not supporting streaming, so we = added it. Yes, this added a bit of complexity for decoders, but we = handled that as best we could. --Paul Hoffman From olaf@NLnetLabs.nl Tue Aug 13 00:41: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 2BFAC21E80C6; Tue, 13 Aug 2013 00:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 Qc4-0-aeTkRB; Tue, 13 Aug 2013 00:41:44 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E79F21E80E0; Tue, 13 Aug 2013 00:41:40 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:7211:24ff:fe8c:627a] ([IPv6:2001:7b8:206:1:7211:24ff:fe8c:627a]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id r7D7fSOf092467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Aug 2013 09:41:29 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl DKIM-Filter: OpenDKIM Filter v2.8.3 open.nlnetlabs.nl r7D7fSOf092467 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1376379691; bh=02nsMptkDneobbH5xfuqqAnp5VAeEb3suCJEyFQ/+zY=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Zq1+lFTG68QRGX/2CNyXsTpT00JLlJpYhH/YHqFcqj1aS2vEfWuOUaSLi+WrOmbpM yPEw83Y2WFHVsYV+5aNujYLpSVpbM5Qpdtgzi4VocIQK8sLC0T1yvxIaBIU1D58mcd leKigKE/WOfR9tkU9+QjQz1frY7WsLwsmQkp+xjI= Content-Type: multipart/signed; boundary="Apple-Mail=_14D2DE08-DF23-4CD9-AFE1-6D33BE8F738C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Olaf Kolkman In-Reply-To: Date: Tue, 13 Aug 2013 09:41:30 +0200 Message-Id: <0B607DD5-4ADE-48FB-8B61-8D57421BA87E@NLnetLabs.nl> References: <11D5DC92-4993-4D50-A243-C87FEF70B116@NLnetLabs.nl> To: Barry Leiba X-Mailer: Apple Mail (2.1508) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Tue, 13 Aug 2013 09:41:31 +0200 (CEST) X-Mailman-Approved-At: Tue, 13 Aug 2013 11:36:20 -0700 Cc: "weirds@ietf.org Group" , draft-ietf-weirds-using-http.all@tools.ietf.org, IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 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, 13 Aug 2013 07:41:45 -0000 --Apple-Mail=_14D2DE08-DF23-4CD9-AFE1-6D33BE8F738C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Aug 12, 2013, at 9:56 PM, Barry Leiba = wrote: >>> I question the use of 404 Not Found to indicate "no information >>> regarding the query", since it doesn't distinguish between "no = information" >>> and "wrong query". >>=20 >> Not sure what you mean with 'wrong query'. >> If you mean "Malformed Query" then that is addressed by section = 5.4. >> If you mean "No business asking" then that is addressed in the last = paragraph of 5.3. >=20 > 404 is meant to say that the URL you're asking for doesn't exist (or > the server isn't willing to disclose that it exists). >=20 > When you use HTTP to retrieve a web page, there doesn't need to be a > distinction between "the web page doesn't exist" and "the web page is > empty" (that is, there's no information for me to give you). I'll > just give you no information. >=20 > When you use RDAP, presumably there *is* a useful distinction between > the two. Larry's questioning whether it's wise to use 404 for the > latter -- what you're asking for exists, but there's nothing to say > about it. >=20 > And so the question is whether there's a useful distinction in RDAP > between "you're querying about something that doesn't exist" and > "you're querying about something that exists, but there's no > information available about it." If not, then 404 might be OK. If > so, though, there should be different status codes, and 404 belongs to > the former. I can see 3 cases, which (I think) are all addressed: * Malformed query (I cannot answer this type of query) (5.4: 400) * I can parse the query but have no data (5.3 first paragraph: 404) * I can parse the query but don't want to hand you the data (5.3: 4XX = range, with optional information in the body) The last option is really of the form "there's no information for me to = give you" Am I misreading? Do not hesitate to use the clue-bat, if I am. --Olaf --Apple-Mail=_14D2DE08-DF23-4CD9-AFE1-6D33BE8F738C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJSCeMqAAoJEFRqER47aqpkXkYP/1peknyY+Uf8a88XNZstnXag 1GGc8EZnF/lqQLNRdRS21HuKkATKwe+LFrW/nw/Nb2qB0toU5e39iQILsJ/qxm4x rAWNFjGpGXF2s786QNZHZYlpON8sQnnj7q3hXlnfL5lTYnO1lxGPvnItdnBOpc/e LFU5ooXycM4PdxK3eynuW4d1wVvQdnUTskJCqdgOgGwaMLWtIStrioKpkJ57b8TT 1EirEvuI0zMqecbR9KyErImoKNkdvUjWiLCMD8K/FIH59N0WJpe7xDb1oTQ7hNK4 5eskLPLFomL89vIOfoJAEBn9KQKpciHBo5WMvMBa90wYTuXG+JkkJbfPA9XcODGo En6WiZxyGtdf1YkqwhbpjaFBjATqOi83yJS6i2jD49mgcPkQjp2zksgLId/Md/Bp HV8WmcZUvhxsCzk33+LnrhkOEe1OihNgYzDbz2hea+PEK+fhQjc9g20PD4Z9tcyD ElmujighkNBZVyZRiWG1sBzQ2/hu8LIFidxevAiD5TzYQ/atU/Dty/m2s2BVKL+K fmZJZ+sW4CC5z/yL+Ryi3zwt1dVFtonauF9nojmcDy4UbpNvLw/JJapi1l8ihCjb Z0DKliT/z44P7kygpp907iu7VfYbx7PWoju3X8E4ngqzoBMCYz/3i7MsujrOJUFb rb1N+b7vq2P/ZhLoBGum =BGzn -----END PGP SIGNATURE----- --Apple-Mail=_14D2DE08-DF23-4CD9-AFE1-6D33BE8F738C-- From andy@arin.net Tue Aug 13 06:32:12 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 E923B21E8159; Tue, 13 Aug 2013 06:32:12 -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 aVnSiyI1hKVo; Tue, 13 Aug 2013 06:32:07 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 6432A21E812F; Tue, 13 Aug 2013 06:32:07 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 16406165143; Tue, 13 Aug 2013 09:32:07 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 9BEE916512F; Tue, 13 Aug 2013 09:32:04 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 13 Aug 2013 09:32:04 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.236]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Tue, 13 Aug 2013 09:32:04 -0400 From: Andy Newton To: Barry Leiba , Olaf Kolkman Thread-Topic: [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 Thread-Index: AQHOmCM64I/D2mWoDEWTDZ8arUS4bpmTIrSA Date: Tue, 13 Aug 2013 13:32:02 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 13 Aug 2013 11:36:20 -0700 Cc: "weirds@ietf.org Group" , "draft-ietf-weirds-using-http.all@tools.ietf.org" , IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 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, 13 Aug 2013 13:32:13 -0000 On 8/13/13 8:46 AM, "Barry Leiba" wrote: > >Specific example: > >I make a query to you at this URL: >http://rdap.example.com/ip/203.0.113.0/24 > >That is clearly a properly formed query, so 400 is not on the table. > >Case 1: You are *not* the right place to ask about 203.0.113.0/24. >This is what the HTTP 404 code is meant for, and I would think you'd >respond with a 404. > >Case 2: You *are* the right place to ask about 203.0.113.0/24, but >your policies do not allow you to give me the data. >This is your third case above, and you will respond with some 4XX code. > >Case 3: You *are* the right place to ask about 203.0.113.0/24, and >your policies allow you to give me the data... but there's just no >data to give me. >Is this a real case? Can it happen? If it happens, what status code >will you send back? > >If case 3 can't happen, and it really is only cases 1 and 2 (and >malformed), then we're done, and the stuff about 404 is fine. If case >3 can happen, we need to talk about it. > >Barry > Barry, In case 3, if 203.0.113.0/24 is not an exact boundary for a network registration, the proper thing to do according to the query draft is to return the network registration that encompasses 203.0.113.0/24. Therefore I think case 3 cannot happen. There are similar semantics for autnum ranges. For domains, name servers, and entities, either they exist or they don't. Does the help? -andy From tbray@textuality.com Tue Aug 13 18:32: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 A3BD511E81D6 for ; Tue, 13 Aug 2013 18:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[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 LXl-T9tJ2L0C for ; Tue, 13 Aug 2013 18:32:20 -0700 (PDT) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by ietfa.amsl.com (Postfix) with ESMTP id 49B0B11E81D1 for ; Tue, 13 Aug 2013 18:32:19 -0700 (PDT) Received: by mail-ve0-f180.google.com with SMTP id pb11so7291936veb.11 for ; Tue, 13 Aug 2013 18:32:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=3CsdDmN5ENvAgAJJa7oywtWEX+wL3/cOYF8nlSRpcfk=; b=B1cG2B6eDRcESXgAzPPHg1aMnrbxH7mXU9+8Mg4LQ2AiJwPTqY+Iqq7HCijgo83Yio bMi55fvgDqhbUG1ajPkpfeA12s3z8yhz/QRIGAY0+5g/sUKtf7znEKV6xmeZd8Eonf3e 0YAWOWmU+5MNI9xKDUx9VsmarGlIAkQEMEKyowC4nkCjj2WQy+1SveoU/KVnwe974Vya XjK9OeVtp5+zvnhm1oP72LtaXT8zjAkkYj9F9/L8M+QS3ssnfKklDTl2HnpRbSDcS0nU ZH+PsdGPGnokl06ldwNnYyM4zY45geRL+h1vMR6bTsNN1STFI8/SFc5UwLoZK8TB70Wi Cjuw== X-Gm-Message-State: ALoCoQmwnldm8+xmCK34mvH111v+M12rxAAVMXEXn+a2S/HUj9PjVxjAYQnR/KORGzQB+d9cCsXc MIME-Version: 1.0 X-Received: by 10.220.164.202 with SMTP id f10mr6981054vcy.25.1376443930849; Tue, 13 Aug 2013 18:32:10 -0700 (PDT) Received: by 10.220.212.202 with HTTP; Tue, 13 Aug 2013 18:32:10 -0700 (PDT) X-Originating-IP: [2620:0:1000:147d:5e7:c757:6800:2fe5] Date: Tue, 13 Aug 2013 18:32:10 -0700 Message-ID: From: Tim Bray To: "apps-discuss@ietf.org" , draft-allen-dispatch-imei-urn-as-instanceid.all@tools.ietf.org, The IESG Content-Type: multipart/alternative; boundary=001a11c1e9808d77d504e3de539a Subject: [apps-discuss] Apps Area review of draft-allen-dispatch-imei-urn-as-instanceid-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: Wed, 14 Aug 2013 01:32:25 -0000 --001a11c1e9808d77d504e3de539a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/are= a /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-allen-dispatch-imei-urn-as-instanceid-10 Title: Using the International Mobile station Equipment Identity(IMEI)URN as an Instance ID Reviewer: Tim Bray Review Date: August 13 Summary: The document needs a certain amount of editorial polishing, and the issues raised on the IETF mailing list need to be considered by the IESG. That aside, the description of the usage of the IMEI URN seems OK. Major Issues: The discussion on the ietf@ mailing list is included here by reference. Minor Issues: In section 3, The quality of the English is sufficiently bad as to make the section hard to read and understand. It is severely in need of more commas and paragraph breaks. Nits: Abstract: =E2=80=9Can RFC (from the IETF stream)=E2=80=9D is a little ambiguous, ther= e are multiple IETF streams The acronym =E2=80=9CUA=E2=80=9D is never defined. User-Agent? Section 1. s/sub namespace/sub-namespace/ =E2=80=9CURN as per RFC 2141=E2=80=9D standardize RFC cite syntax =E2=80=9Cso that registrar can recognize that the contacts=E2=80=9D - what registrar? Not defined. Oh wait... is the ref to RFC 5626 enough? - s/registrar/the registrar/ =E2=80=9CRFC 5626 [1] defines that a UA SHOULD=E2=80=9D - s/defines/specifi= es/ or /requires/ =E2=80=9Cother URN schemes to be used=E2=80=9D s/to be used// =E2=80=9Coutbound behavior and=E2=80=9D - comma before =E2=80=9Cand=E2=80= =9D =E2=80=9CThe GSMA IMEI URN is a namespace for the IMEI a globally unique identifier=E2=80=9D - there=E2=80=99s something broken in this sentence. D= o you mean this is a URN namespace? URNs normally aren=E2=80=99t namespaces in and of them= selves, so some more explanation is required. Section 5. =E2=80=9Cother than equal to 0=E2=80=9D - s/equal to// =E2=80=9CThe UAC MUST provide lexically equivalent URNs in each registratio= n=E2=80=9D - the term =E2=80=9Clexically equivalent=E2=80=9D is probably underspecified; see= Section 6 of RFC3986. If you mean =E2=80=9Ccharacter-by-character identical=E2=80=9D you= should probably say so (and I suspect you do). --001a11c1e9808d77d504e3de539a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have been selected as the Applications Area Directorate reviewer for this dra= ft (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=20 comments you may receive. Please wait for direction from your document=20 shepherd or AD before posting a new version of the draft.

Document: = draft-allen-dispatch-imei-urn-as-instanceid-10
Title: Using the International Mobile station Equipment Identity(IMEI)URN a= s an Instance ID
Reviewer: Tim Bray
Review Date: August 13

Summary: The document needs a = certain amount of editorial polishing, and the issues raised on the IETF ma= iling list need to be considered by the IESG. That aside, the description o= f the usage of the IMEI URN seems OK.

Major Issues: The discussion on the ietf@ mailing list is included here= by reference.

Minor Issues: In section 3, The quality of= the English is sufficiently bad as to make the section hard to read and understand.=C2=A0 It is severely i= n need of more commas and paragraph breaks.

Nits:

Abstract:

=E2=80=9Can RFC (from the IETF stre= am)=E2=80=9D is a little ambiguous, there are multiple IETF streams

The acronym =E2=80=9CUA=E2=80=9D is never defined. User-Agent?

Section 1.

s/sub namespace/sub-namespac= e/

=E2=80=9CURN as per RFC 2141=E2=80=9D standardize RFC cite syntax=

=E2=80=9Cso that registrar can recognize that the contacts=E2=80=9D=
- what registrar? Not defined. Oh wait... is the ref to RFC 5626 enough?- s/registrar/the registrar/

=E2=80=9CRFC 5626 [1] defines that a U= A SHOULD=E2=80=9D - s/defines/specifies/ or /requires/

=E2=80=9Cothe= r URN schemes to be used=E2=80=9D s/to be used//

=E2=80=9Coutbound behavior and=E2=80=9D - comma before =E2=80=9Cand=E2= =80=9D

=E2=80=9CThe GSMA IMEI URN is a namespace for the IMEI a glob= ally unique identifier=E2=80=9D - there=E2=80=99s something broken in this = sentence.=C2=A0 Do you mean this is a URN namespace?=C2=A0 URNs normally ar= en=E2=80=99t namespaces in and of themselves, so some more explanation is r= equired.

Section 5.

=E2=80=9Cother than equal to 0=E2=80=9D - = s/equal to//

=E2=80=9CThe UAC MUST provide lexically equivalent URNs= in each registration=E2=80=9D - the term =E2=80=9Clexically equivalent=E2= =80=9D is probably underspecified; see Section 6 of RFC3986. If you mean = =E2=80=9Ccharacter-by-character identical=E2=80=9D you should probably say = so (and I suspect you do).

--001a11c1e9808d77d504e3de539a-- From superuser@gmail.com Tue Aug 13 22:52: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 1DDC811E8103 for ; Tue, 13 Aug 2013 22:52:46 -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, 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 Ve6PAgsXk91Z for ; Tue, 13 Aug 2013 22:52:45 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id C2FCE11E8101 for ; Tue, 13 Aug 2013 22:52:44 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id p61so7341454wes.39 for ; Tue, 13 Aug 2013 22:52:43 -0700 (PDT) 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=WOc/HWIDrlIheK94fx09RK5z8eA8kDZry0rrB9s4ebs=; b=ZryKWOeJ/iB5mk4KjEm5bQZaZH/G1qkZC5Lm8XX3Mzihpyjq2ILYNDcHzMc6o08qQG C6+E+cj/LltCByQezvURRGE6YYjHGI+ypVvONfItzfkTchY4XhV3ek0I5kfWpZ33p5nE M55SlG+U0TiczUAedGNTefz70z1xIY8asA18ChsHmtjO1fsHVJYgMIMrDrqCUacGfbQq 16QltzzNlmlusondFV1MJO6DDxWwzvAsxDOdvj/hCnSWGHc8rM1/pAv6uzauqWbWa+D+ MLARhVj48ZLxHSHaGgywGrtPynhnrxNWzoZkZ+PF3ReSNUYOoV1noJ4ZIAgNF6dlJOCv hlCw== MIME-Version: 1.0 X-Received: by 10.180.84.196 with SMTP id b4mr5072133wiz.19.1376459563911; Tue, 13 Aug 2013 22:52:43 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Tue, 13 Aug 2013 22:52:43 -0700 (PDT) In-Reply-To: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> Date: Tue, 13 Aug 2013 22:52:43 -0700 Message-ID: From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Content-Type: multipart/alternative; boundary=f46d04426e2a5acfe004e3e1f79d 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, 14 Aug 2013 05:52:46 -0000 --f46d04426e2a5acfe004e3e1f79d Content-Type: text/plain; charset=ISO-8859-1 Colleagues, A gentle reminder that this WGLC is in effect, closing in a few days. To date there have been no comments or reviews on the WGLC at all. It will be hard for me to argue that consensus exists without at least a few reviews on the record. Please take a moment to review it and post comments in by the end of this week. -MSK, APPSAWG co-chair and document shepherd On Mon, Jul 29, 2013 at 1:08 AM, Murray S. Kucherawy wrote: > This note begins a Working Group Last Call for > draft-ietf-appsawg-xml-mediatypes, ending on Friday, August 16. Please > provide reviews and comments on this list or privately to the authors as > soon as possible. > > -MSK, APPSAWG co-chair and document shepherd --f46d04426e2a5acfe004e3e1f79d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

A gentle reminder that this WGLC i= s in effect, closing in a few days.=A0 To date there have been no comments = or reviews on the WGLC at all.=A0 It will be hard for me to argue that cons= ensus exists without at least a few reviews on the record.

Please take a moment to review it and post comments in by th= e end of this week.

-MSK, APPSAWG co-chair and document s= hepherd



On Mon, Jul 29, 2013 at 1:08 AM, Murray S. Kucherawy <= superuser@gmail.co= m> wrote:
This note begins a Working Group Last Call for draft-ietf-appsawg-xml-media= types, ending on Friday, August 16. =A0Please provide reviews and comments = on this list or privately to the authors as soon as possible.

-MSK, APPSAWG co-chair and document shepherd

--f46d04426e2a5acfe004e3e1f79d-- From superuser@gmail.com Tue Aug 13 22: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 CABE421E809A for ; Tue, 13 Aug 2013 22:58:04 -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, 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 CbX1AvtyNYtB for ; Tue, 13 Aug 2013 22:58:04 -0700 (PDT) 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 1E96321E8098 for ; Tue, 13 Aug 2013 22:58:03 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hj13so1510272wib.11 for ; Tue, 13 Aug 2013 22:57:59 -0700 (PDT) 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=HYQWOVdcjDALkyGps/ntwheXPF6B2/wYiDclOM/es14=; b=fpmoWk9AzmyCohIRfXsXQz3mBSaZlkpFXj15ndy1KlFtytii46h3SY1nPYi8ZBtqc1 pJLfhBlSjp+s0jlcEFaDvrO74/uUAEmGP4WpN7qh8GUTGruEWrjAwjUerIs6Zf4w3NCs cw1+fE8ZX426uAem+CQ5LOHyJknLfjzz3bTrwPMilGNE94FPxu/4p9BufxeU3SpBS94a DzPxWOJ0MlZGpYwlMdw37ByFtBRWobZMPC5JZzh9DBe/Faek5RWMiFEqztAFPMFJUT5+ tozRRQlTqj7NellDR6LlqLcTCRTOgpckz51XIvPyve6fcY6kLQYUcDiDbD4hh0X8qN73 MOoQ== MIME-Version: 1.0 X-Received: by 10.180.187.17 with SMTP id fo17mr4967815wic.60.1376459879133; Tue, 13 Aug 2013 22:57:59 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Tue, 13 Aug 2013 22:57:59 -0700 (PDT) In-Reply-To: <2021301683.11717.1375088679807.JavaMail.zimbra@peachymango.org> References: <51F6283B.1010000@ericsson.com> <2021301683.11717.1375088679807.JavaMail.zimbra@peachymango.org> Date: Tue, 13 Aug 2013 22:57:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=001a11c26a5e24ba0604e3e20a3c Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-malformed-mail-07 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, 14 Aug 2013 05:58:04 -0000 --001a11c26a5e24ba0604e3e20a3c Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 29, 2013 at 2:04 AM, Franck Martin wrote: > I have read the document an it is ok to publish, I would only point to > some neat-picking > > 7.1.6 > To: "Joe" likely a typo conversion from xml to html > Fixed. > > 7.1.7 > a note on idn@idn may be needed so it is not interpreted as a group(?) ie: > To: Joe; > > > Do you have something specific in mind here? Can you propose text to be added? -MSK --001a11c26a5e24ba0604e3e20a3c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jul 29, 2013 at 2:04 AM, Franck Martin <fr= anck@peachymango.org> wrote:
I have read the document an it is ok to publ= ish, I would only point to some neat-picking

7.1.6
To: "Joe" <joe@example.com<= /a>&gt
likely a typo conversion from xml to html

Fixed.
=A0

7.1.7
a note on idn@idn may be needed so it is not interpreted as a group(?) ie:<= br> To: Joe;




<= /div> --001a11c26a5e24ba0604e3e20a3c-- From superuser@gmail.com Tue Aug 13 23:00: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 2404621E8098 for ; Tue, 13 Aug 2013 23:00:05 -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, 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 rWiXS5kDEWBb for ; Tue, 13 Aug 2013 23:00:04 -0700 (PDT) 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 6675A21E8054 for ; Tue, 13 Aug 2013 23:00:04 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so7126608wes.26 for ; Tue, 13 Aug 2013 23:00:03 -0700 (PDT) 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=QkMSLlKiClpq6S5eB5zr9d01sE+7kG3WUs3+1oZgfPM=; b=k/o2r1BWRB0Rqx58fdCJd8cyJVD1Q4XzP59P1i255my10KDQZyEVDWzp9kGwNu+nhe S0Ocuue53mhBIJU8IXKUBHr0qvDO/P6zpUmPsLuTsb7dY1yhhyVGq0ccre4KaWp+wYbI +CoZ/dX8tNPkwsmmLDCvFsOjBruLyfji5u80MpIkWAEjwq9/zOWXdQnsAOdT3ZYQdwt/ CRipOvJgrZt1KDSID8kqPAdquKEjrDlgrva9MZ9FkHSNo53Wbk/nD8muENdB6wVTbWhs hilJ2aff7Xn+YPyTxraWZyy/lD9emM9NyCn9NwnNIhH6un0naylT4uC1WJwk2/KPujSF H/WQ== MIME-Version: 1.0 X-Received: by 10.194.250.6 with SMTP id yy6mr5436728wjc.13.1376460003544; Tue, 13 Aug 2013 23:00:03 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Tue, 13 Aug 2013 23:00:03 -0700 (PDT) In-Reply-To: <5204E5F8.7000105@isode.com> References: <51F6283B.1010000@ericsson.com> <5204E5F8.7000105@isode.com> Date: Tue, 13 Aug 2013 23:00:03 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a11c1ba4a8f169104e3e211cf Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-malformed-mail-07 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, 14 Aug 2013 06:00:05 -0000 --001a11c1ba4a8f169104e3e211cf Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 9, 2013 at 5:52 AM, Alexey Melnikov wrote: > > This is a very useful document. I reviewed it and I think it is ready for > publication. I sent information about typos I spotted directly to Murray. > > All fixed in the working copy. Thanks! -MSK --001a11c1ba4a8f169104e3e211cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Aug 9, 2013 at 5:52 AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:

This is a very useful document. I reviewed it and I think it is ready for p= ublication. I sent information about typos I spotted directly to Murray.


All fixed in the working copy.=A0 Thanks!

-MSK
=
--001a11c1ba4a8f169104e3e211cf-- From superuser@gmail.com Tue Aug 13 23:22: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 9039111E812A for ; Tue, 13 Aug 2013 23:22:41 -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=[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 Q0m0CFqhxAeb for ; Tue, 13 Aug 2013 23:22:41 -0700 (PDT) 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 C25BE11E8126 for ; Tue, 13 Aug 2013 23:22:40 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id hi8so1522539wib.3 for ; Tue, 13 Aug 2013 23:22:39 -0700 (PDT) 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=Q1jep0mi4A1m43MTOuj9i6AUn118KFH0tvxrOL6O+9E=; b=ysmA6heZUuqSD9ozGz7CJfC17+nbSV8O6qYWAVMiNgJ1YtqnV8Kq670mOrfUO42gkr eHF0e4WBjn5rKwPbfALRHwR4mom20tWWpfOi8zAWPjSvDJRLnBjgJNm5o7F3z0WdEwWy TPDZzjI6abDJe30N7j7tHVT9aaSkSJ4gfaUKyj0lkBRCnDpKt4hQ8HfrfEeTjE14OsoO t3rAIaea0rl2eE7ZuOUOiht2J5JS5ZfhVlRZ4JUeKegdgZ+vd5mRjoVpdRLXj09Q8NUy AXHYplsYc5fZYQ4pLE7HUVFxK5RVAsTLvZMpEJusKEUAItmOP0Wn0qEelklKUpdfC4qb qvRA== MIME-Version: 1.0 X-Received: by 10.180.109.35 with SMTP id hp3mr993730wib.52.1376461359923; Tue, 13 Aug 2013 23:22:39 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Tue, 13 Aug 2013 23:22:39 -0700 (PDT) In-Reply-To: <20130809183338.68581.qmail@joyce.lan> References: <51F6283B.1010000@ericsson.com> <20130809183338.68581.qmail@joyce.lan> Date: Tue, 13 Aug 2013 23:22:39 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=e89a8f3ba25b67ca4c04e3e26242 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-malformed-mail-07 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, 14 Aug 2013 06:22:41 -0000 --e89a8f3ba25b67ca4c04e3e26242 Content-Type: text/plain; charset=ISO-8859-1 Thanks, hadn't noticed that before. Done in the working copy. -MSK On Fri, Aug 9, 2013 at 11:33 AM, John Levine wrote: > I've read it and find its advice useful. > > Before publication, I'd want to combine or otherwise reconcile > sections 7.5 and 7.8 which address the same issue using different > words. In 7.8, the advice is to combine duplicated headers, which > works for the From and Subject headers in the examples, but > what about Date or Sender ? > > This shouldn't be hard to fix. Otherwise it's fine. > > R's, > John > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --e89a8f3ba25b67ca4c04e3e26242 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks, hadn't noticed that before.=A0 Done in th= e working copy.

-MSK

<= br>
On Fri, Aug 9, 2013 at 11:33 AM, John Levine = <= johnl@taugh.com> wrote:
I've read it and find its advice useful.=

Before publication, I'd want to combine or otherwise reconcile
sections 7.5 and 7.8 which address the same issue using different
words. =A0In 7.8, the advice is to combine duplicated headers, which
works for the From and Subject headers in the examples, but
what about Date or Sender ?

This shouldn't be hard to fix. =A0Otherwise it's fine.

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

--e89a8f3ba25b67ca4c04e3e26242-- From sm@resistor.net Tue Aug 13 23:48:54 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 59D9921E8083 for ; Tue, 13 Aug 2013 23:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.053 X-Spam-Level: X-Spam-Status: No, score=-102.053 tagged_above=-999 required=5 tests=[AWL=0.546, 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 w9VCqpERMj91 for ; Tue, 13 Aug 2013 23:48:53 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0AA21E8093 for ; Tue, 13 Aug 2013 23:48:53 -0700 (PDT) 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 r7E6mlGj020563 for ; Tue, 13 Aug 2013 23:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1376462932; bh=PCv0T70i7Q7WbQsYLyZa8iQ6NYd8AiuvCM9DIRYbFmY=; h=Date:To:From:Subject:In-Reply-To:References; b=H4jlXX7H7vety76O7KEayOc0oL07q4ueBnYbe07uLNyc8SVjfH44gnb3cnVWZIvrO oZIaav7siESCFh1OfS7Bp6G3svBxZxJmP/fuOONNPMApNQiJpGrA1LUYtxe9spc4/o e9T/O0WV1M7hcS/mR/qReMWAN1+PXmSZjeHapkzo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1376462932; i=@resistor.net; bh=PCv0T70i7Q7WbQsYLyZa8iQ6NYd8AiuvCM9DIRYbFmY=; h=Date:To:From:Subject:In-Reply-To:References; b=Q3gDBQT4QSm+e1QmKwtJA3x+yuMLbFJexVLH5gouejpiCEPI9rWwWpZqmf7XCtx3q CHWhlPbZK51Trhy+GAH7rveHuwjPQpRSPHop1YRtlhs0DXDST0x26NMFtJXOAd8KFi ffIW79V6YVT/CxKmscrEbx3f34TFp4ia8ddPCJBg= Message-Id: <6.2.5.6.2.20130813230340.0b0d4968@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Aug 2013 23:44:11 -0700 To: apps-discuss@ietf.org From: SM In-Reply-To: References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, 14 Aug 2013 06:48:54 -0000 At 22:52 13-08-2013, Murray S. Kucherawy wrote: >A gentle reminder that this WGLC is in effect, closing in a few >days. To date there have been no comments or reviews on the WGLC at >all. It will be hard for me to argue that These are quick comments about draft-ietf-appsawg-xml-mediatypes-02 In Section 3: "However, developers of such media types are STRONGLY RECOMMENDED to use this specification as a basis for their registration." The sentence needs an editorial pass, i.e. it is RECOMMENDED. I suggest dropping the "STRONGLY" instead of having to explain the uppercase. The first paragraph of Section 1 and the first paragraph of Section 3 could be merged instead of having "this specification standardizes" repeated. In Section 5: "Document authors SHOULD NOT use unregistered schemes. Scheme authors SHOULD register their schemes." I suggest turning the above two sentences into "it is RECOMMENDED to only use the schemes listed in the XPointer Scheme Registry" and add a pointer to how to register a scheme. I suggest moving Section 9 to an appendix as it is non-normative. The draft updates RFC 4289. There isn't any explanation about what is being updated. I suggest referencing draft-ietf-httpbis-p3-payload-18 instead of discussing about RFC 2616 and the HTTPbis drafts. Regards, -sm From cabo@tzi.org Wed Aug 14 00: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 F34FD11E8127; Wed, 14 Aug 2013 00:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 eYsmpFnLSeDA; Wed, 14 Aug 2013 00:12:54 -0700 (PDT) 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 01C0711E80C5; Wed, 14 Aug 2013 00:12:53 -0700 (PDT) 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 r7E7CpNC011437; Wed, 14 Aug 2013 09:12:51 +0200 (CEST) Received: from [192.168.217.105] (p54890CE5.dip0.t-ipconnect.de [84.137.12.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B698D752; Wed, 14 Aug 2013 09:12:50 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <20130716195803.9658.64560.idtracker@ietfa.amsl.com> Date: Wed, 14 Aug 2013 09:12:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130716195803.9658.64560.idtracker@ietfa.amsl.com> To: ietf@ietf.org X-Mailer: Apple Mail (2.1508) Cc: IETF Apps Discuss Subject: [apps-discuss] cbor-05 (was: Last Call: (Concise Binary Object Representation (CBOR)) to Proposed Standard) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "ietf@ietf.org Mailing List" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 07:12:59 -0000 This was a rather productive IETF Last Call! Thank you all for the many comments. Paul and I have taken your comments and believe that we have incorporated the ones that we said we would. The -05 has just been published: http://tools.ietf.org/html/draft-bormann-cbor-05 ... and there are lots of diffs; see http://tools.ietf.org/rfcdiff?url2=3Ddraft-bormann-cbor-05 We would particularly like review of the changes we made in section 3, where we tightened up a lot of the "might" language for parsers. We also clarified that what we were too-loosely calling a "parser" was actually a "decoder" that has two sub-parts: a parser (grammar only) and semantic processor (checking for validity). We hope that this major edit alleviates most concerns, but further comments are certainly appreciated. Gr=FC=DFe, Carsten From duerst@it.aoyama.ac.jp Wed Aug 14 05:59: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 D102511E8152; Wed, 14 Aug 2013 05:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.79 X-Spam-Level: X-Spam-Status: No, score=-103.79 tagged_above=-999 required=5 tests=[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 Q+LxxNyckZNB; Wed, 14 Aug 2013 05:58:55 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2F511E81DD; Wed, 14 Aug 2013 05:58:54 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r7ECwiqV002945; Wed, 14 Aug 2013 21:58:45 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 3263_3d2e_406ba228_04e1_11e3_9183_001e6722eec2; Wed, 14 Aug 2013 21:58:44 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 13954BFBC0; Wed, 14 Aug 2013 21:58:06 +0900 (JST) Message-ID: <520B7EE9.8010708@it.aoyama.ac.jp> Date: Wed, 14 Aug 2013 21:58:17 +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: Barry Leiba References: <11D5DC92-4993-4D50-A243-C87FEF70B116@NLnetLabs.nl> <0B607DD5-4ADE-48FB-8B61-8D57421BA87E@NLnetLabs.nl> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Olaf Kolkman , draft-ietf-weirds-using-http.all@tools.ietf.org, "weirds@ietf.org Group" , "apps-discuss@ietf.org" , IESG Subject: Re: [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 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, 14 Aug 2013 12:59:02 -0000 On 2013/08/13 21:46, Barry Leiba wrote: > Case 3: You *are* the right place to ask about 203.0.113.0/24, and > your policies allow you to give me the data... but there's just no > data to give me. > Is this a real case? Can it happen? If it happens, what status code > will you send back? > > If case 3 can't happen, and it really is only cases 1 and 2 (and > malformed), then we're done, and the stuff about 404 is fine. If case > 3 can happen, we need to talk about it. There is no need for a special status code for empty documents, they can be expressed in HTTP. Just in case case 3 could happen, what about something like Content-Length: 0 Or an 'empty' XML or JSON document or whatever the payload is? Regards, Martin. From tobias.gondrom@gondrom.org Wed Aug 14 09:28: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 48E5C11E81F2 for ; Wed, 14 Aug 2013 09:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.362 X-Spam-Level: X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.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 satiV58d9Lc6 for ; Wed, 14 Aug 2013 09:28:16 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 477F011E8176 for ; Wed, 14 Aug 2013 09:28:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=ME28G8JhckRv9tznTFuUBhZ+XC2MVrHOAHXR5BglgIhRnAUbMZ7D1DYSk5ek1VcWQn4wx/Qw926PtDpV1my/EYCe7dBlZwnAKhiEfOlJ22lLNGCOr4BxDLyeZMUiNBnm; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Enigmail-Version:Content-Type; Received: (qmail 15917 invoked from network); 14 Aug 2013 18:28:13 +0200 Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.64?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 14 Aug 2013 18:28:13 +0200 Message-ID: <520BB01C.6040502@gondrom.org> Date: Wed, 14 Aug 2013 17:28:12 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: apps-discuss@ietf.org, draft-ietf-repute-considerations.all@tools.ietf.org, superuser@gmail.com X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------000603090104080804010603" Cc: iesg@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-repute-considerations-02 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, 14 Aug 2013 16:28:21 -0000 This is a multi-part message in MIME format. --------------000603090104080804010603 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, 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-repute-considerations-02 Title: Operational Considerations Regarding Reputation Services Reviewer: Tobias Gondrom Review Date: Aug-14 Status: Informational Summary: I believe the draft is ready for publication. Review: The draft points out a number of good points and pitfalls regarding reputation systems and over-reliance on them. And I believe it is ready to publication. Two suggestions: 1. in section 5: before you pointed out correctly the potential problem with false positives (falsely backlisted) and that a RSP should have a mechanism/process to handle such cases. Especially if an operation blocks based on the results from the RSP. It might be a useful idea to add this recommendation to the list of bullet points after paragraph 5 in section 5, e.g. something like: "- a pointer to a resolution process for disputed or inaccurate results being reported by the RSP." 2. if the outlined information (aka the bullet point list in section 5) is not available, a pointer to a system where this information can be queried automatically should be provided by the RSP. Potentially including advice on how the result has been computed and if it has been wrongfully assigned to the blacklist, why this might have happened and how this can be corrected. Nits: - section 5, 3rd paragraph s/Reptuations should/Reputations should s/i.e., some property/i.e. some property - section 5, 5th paragraph s/For example, it shoudl be possible/For example, it should be possible Best regards, Tobias --------------000603090104080804010603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi,

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-repute-considerations-02
Title: Operational Considerations Regarding Reputation Services
Reviewer: Tobias Gondrom
Review Date: Aug-14

Status: Informational

Summary: I believe the draft is ready for publication.

Review:
The draft points out a number of good points and pitfalls regarding reputation systems and over-reliance on them.
And I believe it is ready to publication.

Two suggestions:
1. in section 5: before you pointed out correctly the potential problem with false positives (falsely backlisted) and that a RSP should have a mechanism/process to handle such cases. Especially if an operation blocks based on the results from the RSP. It might be a useful idea to add this recommendation to the list of bullet points after paragraph 5 in section 5, e.g. something like:
"- a pointer to a resolution process for disputed or inaccurate results being reported by the RSP."
2. if the outlined information (aka the bullet point list in section 5) is not available, a pointer to a system where this information can be queried automatically should be provided by the RSP. Potentially including advice on how the result has been computed and if it has been wrongfully assigned to the blacklist, why this might have happened and how this can be corrected.

Nits:
- section 5, 3rd paragraph
s/Reptuations should/Reputations should
s/i.e., some property/i.e. some property
- section 5, 5th paragraph
s/For example, it shoudl be possible/For example, it should be possible

Best regards, Tobias
--------------000603090104080804010603-- From mark@coactus.com Wed Aug 14 11:12: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 2924411E810B for ; Wed, 14 Aug 2013 11:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 q3Qll2qgSBCv for ; Wed, 14 Aug 2013 11:12:23 -0700 (PDT) Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA8711E8128 for ; Wed, 14 Aug 2013 11:12:23 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id g10so6703660pdj.40 for ; Wed, 14 Aug 2013 11:12:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FRyYLok2++Jw0s+WqDIV5GOzBdhAbm28tiy9j5wb3co=; b=Q2+UHhVcwhRfrQr1+DAQ1P1jPdjcvRtWJK9i5tfbKBUWXPrEX8y8WghA0QsluRrfEd UQ0cgHAOmp4HO7TvmclAZtI9PdXtYXpzS5ale0/BbMgW0UnWeu2Gf3CYJ/5zHFbDO26I uFH3gocdLao4SMS3yOzKQsOHIeP6h7yR5XlScrVe1EJzd2kBVmG0arltPKyyB8gYZZ5I vrqpf51z2O/PEVarsoxkplYQApXj3NBoeKrJLCFroYF3EDDko2nG+NdagjjRD53Ajm0X xyaFw+t3ufgcZBkSRUzcOVvxCWSV9phubhhyHeckTnTUnXJmi109USY7Ma80izqtmnMM iWTw== X-Gm-Message-State: ALoCoQl0pVDZgxmlYySjZnWmticpLUTL2dVsvuyDeRwAzz8336Eevv17dAp2cj7KVAl51cTGa5Fb MIME-Version: 1.0 X-Received: by 10.66.154.1 with SMTP id vk1mr11375008pab.85.1376503942883; Wed, 14 Aug 2013 11:12:22 -0700 (PDT) Sender: mark@coactus.com Received: by 10.70.25.67 with HTTP; Wed, 14 Aug 2013 11:12:22 -0700 (PDT) X-Originating-IP: [24.212.223.132] In-Reply-To: References: Date: Wed, 14 Aug 2013 14:12:22 -0400 X-Google-Sender-Auth: OAlh8lJfWT01k90MD4XxUMKkw7E Message-ID: From: Mark Baker To: "apps-discuss@ietf.org" , "draft-ietf-weirds-using-http.all@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: "iesg@ietf.org" Subject: Re: [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 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, 14 Aug 2013 18:12:34 -0000 Greetings, I'd like to step back a moment from the minutiae of the specification to ask the meta question, "Why is this needed"? What's so special about registration data that it needs a separate specification about how HTTP should be used with it? HTML doesn't have one of those, nor does any other data format on the Web that I'm familiar with. The introduction states "The purpose of this document is to clarify the use of standard HTTP mechanisms for this application", but I don't understand what needs clarification. Indeed, many of the requirements of this "protocol" imply a profile of HTTP which is quite non-RESTful (where REST was apparently the motivational style for this work, kudos for that). Consider; sec 4.1 "Accept header". There's no normative requirements in this section, and it appears to just summarize the meaning of Accept. What's the value? sec 4.2 "Query Parameters". If this were RESTful, then that wouldn't be required because RESTful clients only construct URI based on the explicit direction of a server. This MUST could also be interpreted as defining the equivalence of URIs, for example http://example.org/ip/192.168.1.1 and http://example.org/ip/192.168.1.1?someparam=somevalue, but in a non-RESTful way as the equivalence isn't made visible to non-RDAP aware applications. sec 5.1 "Positive Answers" seems as unnecessary as 4.1 as it simply rehashes what HTTP already does. Ditto for 5.2, 5.3, and 5.4. I fear that these sections could be interpreted by implementors as restricting/subsetting the types of possible HTTP interactions; though I applaud the final paragraph of section 3 which expresses a desire for this not to be the case, this specification could easily be interpreted as a profile, making reuse of existing HTTP software more difficult. 5.5 is also not strictly necessary for the same reasons above, but since 429 is a relatively new but valuable status code, calling out its value for this application shouldn't be a problem. It just seems more like a community best-practice that should be in wiki somewhere rather than in specification prose. I haven't studied the breadth of the WEIRDS work product, but it seems to me that it's making a mountain out of a molehill in trying to solve what appears to be a simple problem. To use the Web correctly, IMO, all that should be required is a hypermedia data format and perhaps some additional link types. Or perhaps just the latter, if HTML were used with rich markup such as Schema.org or RDFa (probably a fairly radical idea at this stage, but it's a good option IMO). Mark. From stpeter@stpeter.im Wed Aug 14 13:08: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 21A2721E808C; Wed, 14 Aug 2013 13:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.164 X-Spam-Level: X-Spam-Status: No, score=-102.164 tagged_above=-999 required=5 tests=[AWL=0.435, 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 jifqt7tPfJZR; Wed, 14 Aug 2013 13:08:46 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 447D521E80D6; Wed, 14 Aug 2013 13:08:44 -0700 (PDT) Received: from ergon.local (unknown [64.101.72.39]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9855EE8346; Wed, 14 Aug 2013 14:11:43 -0600 (MDT) Message-ID: <520BE3CA.9000503@stpeter.im> Date: Wed, 14 Aug 2013 14:08:42 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Tim Bray References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: draft-allen-dispatch-imei-urn-as-instanceid.all@tools.ietf.org, "apps-discuss@ietf.org" , The IESG Subject: Re: [apps-discuss] Apps Area review of draft-allen-dispatch-imei-urn-as-instanceid-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: Wed, 14 Aug 2013 20:08:52 -0000 On 8/13/13 7:32 PM, Tim Bray wrote: > “The UAC MUST provide lexically equivalent URNs in each registration” - > the term “lexically equivalent” is probably underspecified; see Section > 6 of RFC3986. If you mean “character-by-character identical” you should > probably say so (and I suspect you do). Well, to be fair, RFC 2141 and RFC 3406, which predate RFC 3986, use the term "lexically equivalent", so I can understand the confusion. However, draft-ietf-urnbis-rfc2141bis-urn-06 (submitted 12 days ago) removes the term "lexically" to align the URNBIS work with RFC 3986, and the next version of draft-ietf-urnbis-rfc3406bis-urn-ns-reg will do the same. Peter -- Peter Saint-Andre https://stpeter.im/ From martin.thomson@skype.net Tue Aug 13 14:40: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 00BD421F9302; Tue, 13 Aug 2013 14:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNZGAqBP8GPZ; Tue, 13 Aug 2013 14:40:28 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id D2B6621F9A74; Tue, 13 Aug 2013 14:40:20 -0700 (PDT) Received: from BLUPR03CA037.namprd03.prod.outlook.com (10.141.30.30) by BLUPR03MB602.namprd03.prod.outlook.com (10.255.124.39) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 13 Aug 2013 21:09:57 +0000 Received: from BL2FFO11FD003.protection.gbl (2a01:111:f400:7c09::25) by BLUPR03CA037.outlook.office365.com (2a01:111:e400:879::30) with Microsoft SMTP Server (TLS) id 15.0.745.25 via Frontend Transport; Tue, 13 Aug 2013 21:09:58 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD003.mail.protection.outlook.com (10.173.160.103) with Microsoft SMTP Server (TLS) id 15.0.745.15 via Frontend Transport; Tue, 13 Aug 2013 21:09:57 +0000 Received: from TK5EX14MBXC296.redmond.corp.microsoft.com ([169.254.2.2]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0136.001; Tue, 13 Aug 2013 21:08:57 +0000 From: Martin Thomson To: Alexey Melnikov , "draft-ietf-geopriv-relative-location.all@tools.ietf.org" , "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] AppsDir review of draft-ietf-geopriv-relative-location-06 Thread-Index: AQHOlOQmar34horJf0+a9CmqguVBWpmTpg6A Date: Tue, 13 Aug 2013 21:08:56 +0000 Message-ID: <88EA7D224AA4F24F9D7628368F7572A91A65EEE4@TK5EX14MBXC296.redmond.corp.microsoft.com> References: <5203A1C0.80709@isode.com> <5204B868.3030304@isode.com> In-Reply-To: <5204B868.3030304@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51914003)(31014004)(51704005)(189002)(199002)(16406001)(54356001)(69226001)(74876001)(4396001)(49866001)(47776003)(79102001)(20776003)(47736001)(81542001)(53806001)(74502001)(81342001)(31966008)(74662001)(47446002)(46406003)(54316002)(76482001)(56776001)(80976001)(77096001)(50986001)(63696002)(56816003)(74706001)(50466002)(80022001)(65816001)(66066001)(55846006)(77982001)(59766001)(74366001)(51856001)(6806004)(23726002)(46102001)(47976001)(83072001)(19580395003)(19580405001)(76796001)(44976005)(76786001)(33656001)(81686001)(83322001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB602; H:mail.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0937FB07C5 X-OriginatorOrg: DuplicateDomain-9e79206f-3253-44e7-9aa6-8e1280886b67.skype.net X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 131.107.125.37 X-MS-Exchange-CrossPremises-AuthSource: BL2FFO11FD003.protection.gbl X-MS-Exchange-CrossPremises-AuthAs: Anonymous X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: BLUPR03MB602.namprd03.prod.outlook.com X-Mailman-Approved-At: Wed, 14 Aug 2013 13:19:28 -0700 Cc: IESG Subject: Re: [apps-discuss] AppsDir review of draft-ietf-geopriv-relative-location-06 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, 13 Aug 2013 21:40:37 -0000 Thanks for the review Alexey. > From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] > Actually there is one new issue: Visual Studio 2010 complains that > "application/octet-stream" media type doesn't conform to the media type > patter in the XML schema. VS2012 doesn't complain... As long as I remove the redundant whitespace fr= om the pattern. I've added a note about that. It's a little hard to inclu= de really long lines in drafts/RFCs. > If omitted, a value containing all zeros is assumed. If the > coordinates provided contain fewer values than are needed, the first > value from the set is applied in place of any missing values. > > I couldn't understand what are you talking about here. Are you talking ab= out the 3rd coordinate missing? What is "the set"? I added some explanatory text. You were right, this was hard to follow. NEW: If omitted, a value containing all zeros is assumed. If the coordi= nates provided contain fewer values than are needed, the first value from the set is appli= ed in place of any absent values. Thus, if a single value is provided, that value is used fo= r Coordinate-2 and Coordinate-3 (if required). If two values are provided and three a= re required, the value of Coordinate-1 is used in place of Coordinate-3. From spencerdawkins.ietf@gmail.com Wed Aug 14 06:33: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 68DD011E815B; Wed, 14 Aug 2013 06:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 jMypKiA7eWiE; Wed, 14 Aug 2013 06:33:14 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id A5C6D21F9BCA; Wed, 14 Aug 2013 06:33:14 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id f8so1631343obp.36 for ; Wed, 14 Aug 2013 06:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=le26r+8OEyi/rMTzCxe1eZOpHbpuBHB+FkJqRetF42E=; b=dJZvbc+q2WrzqsFYVWyoKzvSiODojEDCJgZKRrAXRei6LyY0cVtg5ppz+e+ewjo4aa j5xfBCJPgwbJN8Z5fEMiglswlIj641R39rwRUYv9fwgVSucBvFnoaVse5lPMNTCbxwyM 4gbJ/NFlAPcsWnWr0qrP8pxNLxakebEaoMFnEzolXSYlvqBpY2xK7qlS+TGyyXXFQ2/z BevCVnVhKo3BDcygIFbxJXTVlif6wfbSH4+tGlwrJ4pO4fOIQ6ZTBZuw5/JoF3ISbcC5 WaA0uIXlYDnEvPS4w02NHYk3cNG5ecYa8XrxZzkxGeiS74KyE7opuxJf2jNs9Zj0oZgV SNdA== X-Received: by 10.60.60.41 with SMTP id e9mr9587676oer.47.1376487193104; Wed, 14 Aug 2013 06:33:13 -0700 (PDT) Received: from [192.168.0.30] (99-200-110-204.pools.spcsdns.net. [99.200.110.204]) by mx.google.com with ESMTPSA id r4sm46372649oem.3.2013.08.14.06.32.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Aug 2013 06:33:12 -0700 (PDT) Message-ID: <520B8702.5030004@gmail.com> Date: Wed, 14 Aug 2013 08:32:50 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <11D5DC92-4993-4D50-A243-C87FEF70B116@NLnetLabs.nl> <0B607DD5-4ADE-48FB-8B61-8D57421BA87E@NLnetLabs.nl> <520B7EE9.8010708@it.aoyama.ac.jp> In-Reply-To: <520B7EE9.8010708@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 14 Aug 2013 13:19:28 -0700 Cc: Olaf Kolkman , "apps-discuss@ietf.org" , draft-ietf-weirds-using-http.all@tools.ietf.org, "weirds@ietf.org Group" , Barry Leiba , IESG Subject: Re: [apps-discuss] Applications Area Directorate Review of draft-ietf-weirds-using-http-07 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, 14 Aug 2013 13:33:15 -0000 On 8/14/2013 7:58 AM, "Martin J. Dürst" wrote: > On 2013/08/13 21:46, Barry Leiba wrote: > >> Case 3: You *are* the right place to ask about 203.0.113.0/24, and >> your policies allow you to give me the data... but there's just no >> data to give me. >> Is this a real case? Can it happen? If it happens, what status code >> will you send back? >> >> If case 3 can't happen, and it really is only cases 1 and 2 (and >> malformed), then we're done, and the stuff about 404 is fine. If case >> 3 can happen, we need to talk about it. > > There is no need for a special status code for empty documents, they > can be expressed in HTTP. > > Just in case case 3 could happen, what about something like > Content-Length: 0 > > Or an 'empty' XML or JSON document or whatever the payload is? > > Regards, Martin. FWIW, I was sympathetic to Larry's concern about 404 overload expressed during IESG evaluation, at the Comment level. Of course, I'm not the right guy to say whether a new status code is required. If you tell people how to distinguish between "I can't tell you what I know" and "I can't tell you because I don't know anything" using a zero-length document in the response, that would address my comment without introducing a new status code. Thanks, Spencer From vkg@bell-labs.com Wed Aug 14 13:30: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 B811E21F9FE5; Wed, 14 Aug 2013 13:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.65 X-Spam-Level: X-Spam-Status: No, score=-108.65 tagged_above=-999 required=5 tests=[AWL=-1.950, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 SnlpqXbsKP4b; Wed, 14 Aug 2013 13:30:55 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3311A21F9FDA; Wed, 14 Aug 2013 13:30:54 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r7EKUqiY017027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 14 Aug 2013 15:30:53 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r7EKUqbZ008176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Aug 2013 15:30:52 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r7EKUpJG005029; Wed, 14 Aug 2013 15:30:52 -0500 (CDT) Message-ID: <520BEA11.6050203@bell-labs.com> Date: Wed, 14 Aug 2013 15:35:29 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: draft-kaplan-insipid-session-id.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: IESG IESG , "apps-discuss@ietf.org" Subject: [apps-discuss] APPSDIR review of draft-kaplan-insipid-session-id-03 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, 14 Aug 2013 20:30:59 -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-kaplan-insipid-session-id-03 Title: A Session Identifier for the Session Initiation Protocol (SIP) Reviewer: Vijay K. Gurbani Review Date: Aug-14-2013 IETF Last Call Date: Aug-30-2013 IESG Telechat Date: Not known Summary: This draft is almost ready for publication as an Informational RFC but has a few issues that should be fixed before publication. As a general comment, I believe that the document can benefit from an editing session (overuse of commas at some places and using use of "which" where "that" will suffice). In some portions, the document is written in a more colloquial style (e.g., "The following requirements drive the need...", "In general, B2BUA behavior cannot be dictated by standards. They do whatever their owners/operators wish them to do, or whatever is necessary to make their applications work."). Such an approach drives a conversational style that is helpful in getting the work understood and accepted. However, as the work heads towards the RFC stage, it may be better to substitute this style with the more pedantic and scholarly style better suited to RFCs. That said, the document was an excellent read. Major comments: 2 Minor comments: 9 Nits: 9 Major: ====== - S4.1: HMAC-SHA1 normally generates a 160-bit digest: $ echo '' | php 6438adc3c8337e75579a2a9b22875444943f09ca $ However, you want to create a 128-bit digest. So the assumption is that implementations just truncate the last 4 bytes. Maybe being a bit explicit here will not hurt. - S9.2, second paragraph: "One such weakness may be that a UAC generates one or more Call-IDs which have a property that makes determining the key more likely." Here, do you mean that the weakness is that the UAC uses the same key to generate one or more Session-IDs with different Call-IDs thereby allowing the attacker to guess the key? Ergo, we should use different secret keys each time we generate a Session-ID? I would think that given the cryptographic strength of SHA1 it will hard to determine patterns in the digest such that one is able to predict anything. Given today's processors, SHA1 collisions using commodity hardware is not foreseen until 2018 the earliest (source http://www.schneier.com/blog/archives/2012/10/when_will_we_se.html). And furthermore, even if we assume that the same key was used to create Session-IDs for multiple Call-IDs, the attacker does not know whether the Session-ID seen in a message used the Call-ID in the same message or not. For all the attacker knows, some B2BUA upstream may have changed the Call-ID but left the Session-ID alone. In other words, if the fear is that a new key should be used for each generated Session-ID, then I think we are okay. Minor: ====== - The first paragraph of the Abstract also appears as the first para- graph in the Introduction section; I would suggest you remove it from the Abstract. - S1, second paragraph: s/for matching to/for finding/ - S1, third paragraph: why is the end-to-end message path logical? It could, and indeed is, physical as well. I suspect that removing the "logical" adjective does not harm to the original sentence. - S1.1: I am not sure I understand the need to assign probabilities to the requirements. A requirement is either supported or not, it is a binary decision and not one that involves a continuous value. - S1.1, last bullet: I am not sure what the "SIP layer" is --- well, I know what it is from having trawled in this space for a while. But a neophyte user who reads this may wonder what a "SIP layer" is. Better instead to say, "The identifier must not affect the processing, behaviour, or other semantics associated with receiving and sending of SIP messages." - S5, second paragraph: "Furthermore, out-of-dialog REFER and INVITE with [RFC3891] Replaces requests use the appropriate Session-ID values." Here, what is "the appropriate Session-ID value"? Later on you go on to say that the Session-ID values for such requests are inherited. May be simpler just to point to the relevant sections or say that "Furthermore, out-of-dialog REFER and INVITE with [RFC3891] Replaces requests use the appropriate Session-ID values as described below." - S6, last paragraph: The problem with what is described in this para- graph is that the Session-ID looses its efficacy. Since the UAC did not support the Session-ID extension and the edge proxy did not either, the operator of the UAC has no way to trace the call until it gets back a response from the UAS with the Session-ID header. So, at least when the call is being routed from the UAC, the operator has no way to track it. I am not sure whether we need to come up with a solution for this, but may be worth mentioning in the text. - S9.1, "The requirement ...", better to point out which requirement you are referring to (REQ2b). - S9.2, first paragraph: "Because the algorithm..." --- note the lack of an "of", as in "Because of the algorithm ...". But more importantly, which algorithm are you referring to? SHA-1? HMAC? HMAC is defined in rfc2104 and SHA1 is probably in some NIST FIPS publication. What we are defining in this document is using HMAC-SHA1 on a Call-ID plus a secret key. The properties of one-way hash you appear to refer to in the quoted text are inherent in HMAC-SHA1, no? Nits: ===== - S1, third paragraph, last sentence: why the asterisk in *must*? They don't render the ASCII text with any adoration, I would suggest that s/*must*/must/ Same issue with a *not* in S4.5.1. - S1, last paragraph: s/or have any/or possess any/ - S3, end of first paragraph: s/one which crosses B2BUAs and which has no/one that crosses B2BUAs and does not contain any/ - S4.1, I believe the construct in rfc2104 is HMAC-H-t, which when applied to SHA-1 with 128 bit digest output yields "HMAC-SHA1-128" and not "HMAC-SHA-1-128". - S5, second paragraph: s/well, in/well in/ - S5, second paragraph: "This assumes, of course, ..." --- clearly any UA that supports this document will support Session-ID. Thus, I think that prefacing text with statements of support for the document just add clutter. Unless you are discussing backward compatibility issues, it is best to simply describe behaviour and expectations that are assumed of agents that support this document. - S6, last paragraph: s/UAC which/UAC that/ also, s/B2BUA which/B2BUA that/ also, s/UASs which/UASs that/ - S9.1, s/indentifier which/identifier that/ Many such occurrences in S9.2 as well. - S9.2, second paragraph: s/behavior, by/behaviour by/ Thanks, - 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 cabo@tzi.org Wed Aug 14 13:47: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 63C4511E8187; Wed, 14 Aug 2013 13:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 C93vMKWag9eG; Wed, 14 Aug 2013 13:46:54 -0700 (PDT) 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 4960411E8118; Wed, 14 Aug 2013 13:46:53 -0700 (PDT) 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 r7EKkLTL010851; Wed, 14 Aug 2013 22:46:22 +0200 (CEST) Received: from [192.168.217.105] (p54890CE5.dip0.t-ipconnect.de [84.137.12.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8A17FB0; Wed, 14 Aug 2013 22:46:21 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 14 Aug 2013 22:46:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6B9ACBC6-7552-4A55-9C3F-A773A373C0DE@tzi.org> References: To: Tony Finch X-Mailer: Apple Mail (2.1508) Cc: "ietf@ietf.org Mailing List" , IETF Apps Discuss Subject: Re: [apps-discuss] Gen-ART review of draft-bormann-cbor-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: Wed, 14 Aug 2013 20:47:00 -0000 On Aug 13, 2013, at 13:14, Tony Finch wrote: > MessagePack is simpler so will need even less code FWIW, earlier today I had a nice afternoon with the msgpack-ruby C code, = converting it to encoding and decoding CBOR instead. Saved ~ 250 lines of C code. Of course, I'm filling in that gap now by implementing some of the = optional tags of CBOR. In the end, the implementation of a generic CBOR encoder/decoder with a = sizable collection of optional tags will probably indeed be slightly = larger. But if you just need the features of MessagePack, I now have one data = point where CBOR measurably wins on the implementation complexity = metric. Gr=FC=DFe, Carsten From hallam@gmail.com Thu Aug 15 00:41: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 379FA21E80A3; Thu, 15 Aug 2013 00:41: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, 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 P9NPrXZTMt-k; Thu, 15 Aug 2013 00:41:47 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D9C6521F9F74; Thu, 15 Aug 2013 00:41:46 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id r10so402322lbi.1 for ; Thu, 15 Aug 2013 00:41:44 -0700 (PDT) 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=c5SLoSXtuzm2isTALKxxEK1MVD9O/xsJrYWgbQ8RmFs=; b=XMyk5731a9WEKLnb8Zcab6Ag3nQRXe7he8zQJxFLiV0KIr5ML/lv4dqU7f4ZAmmElt vkGLsGtHpnVAbhRtVowGHQ2Bc3xRRqtgixsCRBGmN0REoUwFQvHE0Ny9ae2ZUOwLhJWk Hx8f1gw9WP7wYRD9L0Lo0mCpNicqdKs5QNQCalkl1RQEtizDxFhidZSjJhSSPVJBXJ8R d5nnWAAJeSFC8SbGi09/E/WmdIRo9lsLKIVjRNxeQHUy9TsxyNuCh2Pt2dk4oX9OXy8R gGOJIKg7h+g8/AHZCNiOSPlkQHoVCYiHRG2zKN0NsCPjNgVnTEfDQn0bGQupFiw74CjP 7fig== MIME-Version: 1.0 X-Received: by 10.112.136.38 with SMTP id px6mr11493103lbb.29.1376552504259; Thu, 15 Aug 2013 00:41:44 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Thu, 15 Aug 2013 00:41:44 -0700 (PDT) In-Reply-To: <6B9ACBC6-7552-4A55-9C3F-A773A373C0DE@tzi.org> References: <6B9ACBC6-7552-4A55-9C3F-A773A373C0DE@tzi.org> Date: Thu, 15 Aug 2013 08:41:44 +0100 Message-ID: From: Phillip Hallam-Baker To: Carsten Bormann Content-Type: multipart/alternative; boundary=089e0112cc6a07f87f04e3f79b47 Cc: "ietf@ietf.org Mailing List" , IETF Apps Discuss Subject: Re: [apps-discuss] Gen-ART review of draft-bormann-cbor-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: Thu, 15 Aug 2013 07:41:48 -0000 --089e0112cc6a07f87f04e3f79b47 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Aug 14, 2013 at 9:46 PM, Carsten Bormann wrote: > On Aug 13, 2013, at 13:14, Tony Finch wrote: > > > MessagePack is simpler so will need even less code > > FWIW, earlier today I had a nice afternoon with the msgpack-ruby C code, > converting it to encoding and decoding CBOR instead. > > Saved ~ 250 lines of C code. > > Of course, I'm filling in that gap now by implementing some of the > optional tags of CBOR. > In the end, the implementation of a generic CBOR encoder/decoder with a > sizable collection of optional tags will probably indeed be slightly larg= er. > But if you just need the features of MessagePack, I now have one data > point where CBOR measurably wins on the implementation complexity metric. > > Gr=FC=DFe, Carsten > > How does it compare to JSON-B which is considerably simpler than CBOR? Getting Proposed Standard this way is not going to count for anything because your proposal that you named after yourself was never in competition with anything else. No other competitors were allowed. And, no, no apologies for complaining about this farce. --=20 Website: http://hallambaker.com/ --089e0112cc6a07f87f04e3f79b47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Aug 14, 2013 at 9:46 PM, Carsten Bormann = <cabo@tzi.org><= /span> wrote:
On Aug 13, 2013, at 13:14,= Tony Finch <dot@dotat.at> wrote:=

> MessagePack is simpler so will need even less = code

FWIW, earlier today I had a nice afternoon with the msgpack-ruby C co= de, converting it to encoding and decoding CBOR instead.

Saved ~ 250 lines of C code.

Of course, I'm filling in that gap now by implementing some of the opti= onal tags of CBOR.
In the end, the implementation of a generic CBOR encoder/decoder with a siz= able collection of optional tags will probably indeed be slightly larger. But if you just need the features of MessagePack, I now have one data point= where CBOR measurably wins on the implementation complexity metric.

Gr=FC=DFe, Carsten


How does it compare to JSON-B which is considerably = simpler than CBOR?

Getting Proposed Standard this way is not going to count for a= nything because your proposal that you named after yourself was never in co= mpetition with anything else. No other competitors were allowed.


<= div class=3D"gmail_extra">And, no, no apologies for complaining about this = farce.

--
Website: http://hallambaker.com/
--089e0112cc6a07f87f04e3f79b47-- From masinter@adobe.com Thu Aug 15 11:30: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 42D7011E81FB for ; Thu, 15 Aug 2013 11:30:03 -0700 (PDT) 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 eRk-Lp8t8vYs for ; Thu, 15 Aug 2013 11:29:58 -0700 (PDT) Received: from exprod6og123.obsmtp.com (exprod6og123.obsmtp.com [64.18.1.241]) by ietfa.amsl.com (Postfix) with ESMTP id 464C211E8183 for ; Thu, 15 Aug 2013 11:29:57 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob123.postini.com ([64.18.5.12]) with SMTP ID DSNKUg0eJMhGvWph/0ZC16hLPN+BGplbhNab@postini.com; Thu, 15 Aug 2013 11:29:58 PDT 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 r7FIQQD8014128; Thu, 15 Aug 2013 11:26:26 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r7FIPCwB000637; Thu, 15 Aug 2013 11:29:54 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Thu, 15 Aug 2013 11:28:42 -0700 From: Larry Masinter To: "apps-discuss@ietf.org" Date: Thu, 15 Aug 2013 11:28:39 -0700 Thread-Topic: Feedback on multipart/form-data Thread-Index: Ac6Z42DyQFQ/iycLRw+sZckifzMy8A== Message-ID: 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: Ian Hickson Subject: [apps-discuss] Feedback on multipart/form-data 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, 15 Aug 2013 18:30:03 -0000 I'm working on a revision to RFC 2388 multipart/form-data=20 but I want some feedback before submitting a first draft. I sent a pointer before,=20 https://www.w3.org/Bugs/Public/show_bug.cgi?id=3D16909#c8 but perhaps you can comment instead on=20 https://github.com/masinter/multipart-form-data RFC 2388 was clear: Field names originally in non-ASCII character sets may be encoded within the value of the "name" parameter using the standard method described in RFC 2047. For reasons I don't understand, browsers did different, incompatible things.=20 I think the main advice is:=20 * those creating HTML forms=20 SHOULD use ASCII field names, since deployed HTML processors vary, and field names shouldn't be visible to the user anyway. * Those developing server infrastructure to read multipart/form-data upload= s SHOULD be aware of the varying behavior of the browsers in translating non-ASCII field names, and look for any of the variants (if they're=20 expecting non-ASCII field names).=20 * Those developing browsers should migrate toward a standard=20 encoding, but the server infrastructure will still have to do fuzzy match for a long while. What should the browsers migrate to? http://www.rfc-editor.org/rfc/rfc5987.txt=20 seems like a more recent proposal and possibly implemented in HTTP anyway. Sites that use non-ASCII field names and want to work with multiple browsers already have to do fuzzy matching. The problem is that the fuzzy matchers already deployed might not recognize any *NEW* encodings. So I suppose having a name* value would be necessary. From sm@elandsys.com Fri Aug 16 07:54: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 24EB211E8286; Fri, 16 Aug 2013 07:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.699 X-Spam-Level: X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMoGXw4N1pUp; Fri, 16 Aug 2013 07:54:29 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B1B11E828E; Fri, 16 Aug 2013 07:54:26 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.232.196]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7GEs6Ax012626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Aug 2013 07:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1376664860; bh=jcO/tHy+h6rNaYdQjNN/qS0I4Mr3oTI+HHtP1No37DI=; h=Date:To:From:Subject:Cc; b=bFG0O0nu3A/xsg11BiudoHCXDJ1OJJhCyqYFh+VFSeqfDN5Rqio+vRefu/gy5KpRr KSJwKNKTLhTmI+PdXIVf8tiydXkF4V8niJ4meYuO+oiG7ZnfvJZefgg11d/AFjguoK OsovyCh2kKqqUWEon8ejL7Q9ZIrN7p4KfVjSIqQI= Message-Id: <6.2.5.6.2.20130816075127.0d5b05b0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 16 Aug 2013 07:53:41 -0700 To: apps-discuss@ietf.org From: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= (by way of S Moonesamy ) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: draft-montemurro-gsma-imei-urn@tools.ietf.org, IESG Subject: [apps-discuss] APPSDIR review of draft-montemurro-gsma-imei-urn-16 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, 16 Aug 2013 14:54:30 -0000 I have been selected as the Applications Area=20 Directorate reviewer for this draft (for=20 background on APPSDIR, please see=20 http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any=20 other Last Call comments you may receive. Please=20 wait for direction from your document shepherd or=20 AD before posting a new version of the draft. Document: draft-montemurro-gsma-imei-urn-16 Title: A Uniform Resource Name Namespace for the=20 GSM Association (GSMA) and the International=20 Mobile station Equipment Identity (IMEI) Reviewer: Martin D=FCrst Review Date: August 16, 2013 IETF Last Call Date: August 16, 2013 Note: I'm on vacation, so the review and in=20 particular the writeup is rather cursory. Summary: This document is nearly ready for publication as a Proposed= Standard. Major issues: The document registers both the 'gsma' URN=20 Namespace ID as well as a single subspace=20 therein. It would be overkill to write two=20 separate documents for this, but it would clearly=20 make the document more readable (and make future=20 addditions easier) if the 'gsma' Namespace ID and=20 the subnamespace were clearly separated. This=20 would also simplify/untangle the grammar. The syntax after the subnamespace ID=20 (gsma-specifier) is too specific. It is geared=20 towards the current needs only, and may be too=20 restrictive. I'd change the overall syntax to something like the following: gsma-urn =3D "urn:gsma:" gsma-specifier *(":" gsma-specifier-defined-substring) gsma-specifier =3D gsma-specifier-defined-string gsma-specifier-defined-string =3D gsma-approved-nonempty-string gsma-specifier-defined-substring =3D ; allow any URN character gsma-approved-nonempty-string =3D 1*unreserved ; needs to be ; approved by GSMA unreserved =3D ALPHA / DIGIT / "-" / "." / "_" The 'vers' parameter is overkill. I'm not a GSMA=20 expert, but my feeling is that such a basic=20 identifier is changed extremely rarely. If that=20 happens, it's much easier to just create 'imei2'.=20 That would also eliminate the need to define that=20 the absence of this parameter is the same as "vers=3D0". Likewise, I'd remove the 'svn' parameter, and=20 either use 'imeisv' or just make the IDs with=20 software versions a few digits longer (they can=20 easily be distinguished by length). [One could=20 then completely get rid of the parameter syntax.] I don't understand why the check digit (spare) is=20 set to '0'. URIs in general and URNs in=20 particular are often used by humans, and in that=20 context, a check digit is valuable (although I=20 understand that imeis shouldn't be passed among=20 humans too often for privacy reasons). The draft says: Any identifier in GSMA namespaces can be compared using the normal mechanisms for percent-encoded UTF-8 strings. The syntax currently doesn't allow=20 percent-encoded UTF-8 strings, but it should. In sections 4.1.4 and 4.2.4, things are rather=20 unclear. 4.1.4 has least to most, 4.2.4 has most=20 to most as a correspondence. Given the text, I'd=20 have no confidence at all to get this right.=20 Also, sometimes half of an octet isn't used; this=20 should be explained and shown in the drawings.=20 Also, if an octet spans two decimal digits, there=20 should be no 'tic' in the middle of the octet value. I.e., like this: +-----+-----+-----+-----+-----+-----+-----+--- 1 2 3 4 5 6 7 8 Octets and not like this: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1 2 3 4 5 6 7 8 Octets Wording addressing the issue brought up by Tim=20 Bray on ietf@ietf.org is still missing. Minor issues: The draft says: A sub-namespace for the IMEI is defined under the GSMA namespace. Other sub-namespaces may be defined in the future to include other identifiers in the GSM, UMTS or LTE networks or future networks deployed by members of the GSMA. This seems needlessly restricted to networks.=20 Just saying something like "for future identifiers needed by the GSMA". The draft says: Each field has its value printed as a decimal digit string with the most significant digit first. "printed" is too narrow. Change to 'visual=20 representation', or better yet, change to=20 'representation for humans' (which includes=20 auditory and tactile representations). The draft says: Identifier uniqueness considerations: Identifiers in the "gsma" namespace are defined and assigned in the requested namespace by the GSMA after ensuring that the URNs to be assigned are unique. Uniqueness is achieved by checking against the registry of previously assigned names. Does the GSMA indeed plan to set up a registry?=20 Or is this just implicit, i.e., check all the=20 relevant RFCs? In the later case, please don't=20 use the term 'registry'. In the former case,=20 please be more explicit about location,... The draft says: Identifier persistence considerations: The GSMA is committed to maintaining uniqueness and persistence of all resources identified by assigned URNs. IMEIs identify devices, but the GMSA can't=20 guarantee the persistence of a device (I can shred and burn my cell phone). The draft says: As the NID sought is "gsma" and GSMA is the long standing acronym for the trade association that represents the mobile phone operators the URN should also persist indefinitely (at least as long as there is a need for its use). The assignment process guarantees that names are not reassigned. The binding between the name and its resource is permanent. I don't think this paragraph is necessary. The=20 parsistence consideratios are abuout persistence=20 in the namespace, not of the namespace ID itself. RFC 5234 needs to be normative. Editorial: There are many abbreviations, many of them not=20 very familiar with IETF people, and some of them=20 not or not consistently expanded. E.g. GSM=20 appears in the second line of the abstract, but=20 is only expanded at the end of the abstract. There's no need for section 3.1, because it's the=20 only subsection in section 3. On the other hand,=20 it would be good if it could have subsections.=20 Because this is a template, that may be=20 impossible. As an alternative, I suggest=20 shortening the template by moving descriptive=20 materail out of the template into separate subsections. Intro (and maybe elswhhere): Please put the=20 namespace name into quotes, like this: 'gsma'. References: if possible, please replace numeric=20 reference ids (e.g. [8]) with something like=20 [RFC5234]. That reduces manual lookups. Intro: "so this namespace would be managed by the=20 GSMA": When the document is published, this is no=20 longer a conditional, so please change "would" to "is". There are inconsistencies with punctuation. E.g.=20 "TS" (an acronym that's not expanded) is spelled=20 "TS" as we0ll as "TS.". Also, there should always=20 be spaces outside parentheses. (if parameters are kept) means that the "=3D" character can only occur as an operator for =3D> means that the "=3D" character can only occur as a separator ... The security sectiion needs a careful grammar check (singular/plural,...) "Phone: unlisted": Just remove these useless fields. Regards, Martin. From ted.ietf@gmail.com Fri Aug 16 10:04: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 E0C1E11E8186; Fri, 16 Aug 2013 10:04:52 -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, 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 g70XegKnposM; Fri, 16 Aug 2013 10:04:52 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 434BF11E8174; Fri, 16 Aug 2013 10:04:52 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id w15so3775380iea.19 for ; Fri, 16 Aug 2013 10:04:51 -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=lt45mtsEGFFp3SHvLet/POaM8kKKj/yjzDGh+oChKig=; b=hN5SPGVf85kvU8aEWEXb5ho81msg9VasPUBkqUwkEisvD1cDKCugHRX7iiDbIm5gmy n3jpeKloMP8SVsaDXBEnQLKK9z3q+1Aq+yx8Uu+5t8jCKgXnsTwqRaMDh5hnXeKqfmS0 FgsmYoRoPs8rcheCNv1Yl/G6enAMdfcQU+V1oBpljzRpdwl+DvHNz3VYHxmEa+cMa0OX kf3vvkvzNBkQOQ3W/stSU6ZsB7NWpifLvbZWhYppDvRf38ho4xWrSmE5I0luCbIZ4tgz 5gfIWkRl7I7eewzB4oztXl8fZvlcIS5T8LmS+1hBVdLS4z6V0Z2u5lmx6cKFHjDhhQS1 8bKQ== MIME-Version: 1.0 X-Received: by 10.42.127.199 with SMTP id j7mr1353361ics.20.1376672691888; Fri, 16 Aug 2013 10:04:51 -0700 (PDT) Received: by 10.42.29.202 with HTTP; Fri, 16 Aug 2013 10:04:51 -0700 (PDT) Date: Fri, 16 Aug 2013 10:04:51 -0700 Message-ID: From: Ted Hardie To: draft-nandakumar-rtcweb-stun-uri.all@tools.ietf.org, "apps-discuss@ietf.org" , IESG Content-Type: multipart/alternative; boundary=20cf3010e99fc5ac4104e413967b Subject: [apps-discuss] Apps directorate review of draft-nandakumar-rtcweb-stun-uri-5.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, 16 Aug 2013 17:04:53 -0000 --20cf3010e99fc5ac4104e413967b Content-Type: text/plain; charset=ISO-8859-1 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-nandakumar-rtcweb-stun-uri-5.txt Title: URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol Reviewer: Ted Hardie Review Date: August 16th, 2013 Summary: This document is ready to be published as an informational RFC; it currently gives a target of standards track, but I do not believe this is required. Discussion: The draft has had some discussion in response to comments by Graham Klyne, the Designated Expert for URI schemes. I personally believe that this document has sufficient utility to qualify for permanent registration, both in the WebRTC context and potentially in similar contexts. I also am not terribly worried that it duplicates the ABNF of RFC 3986; while it certainly could have done it differently, the chances of drift in definition in this case seem low enough to be harmless. Nit: The document recommends removal of the implementation status section, but not the appendices, including the one which gives the design rationale. I'd either move the implementation status to an appendix and keep the all, or remove them all. But this is obviously an editorial choice, not a substantive issue. --20cf3010e99fc5ac4104e413967b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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/wik= i/ApplicationsAreaDirectorate ).

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

Document:=A0 draft-nandakumar-rtcweb-stun-uri-5.txt

Title: URI Scheme for Session Trav= ersal Utilities for NAT (STUN) Protocol

Reviewer: Ted Hardie
Review Date: August 16th, 2013

Summary: This document is ready to be published as an informational RFC; it currently gives a target of standards track, but=A0 I do not believe=20 this is required.

Discussion:=A0 The draft has had some discussion in= response to comments by Graham Klyne, the Designated Expert for URI scheme= s.=A0 I personally believe that this document has sufficient utility to qua= lify for permanent registration, both in the WebRTC context and potentially= in similar contexts.=A0 I also am not terribly worried that it duplicates = the ABNF of RFC 3986; while it certainly could have done it differently, th= e chances of drift in definition in this case seem low enough to be harmles= s.

Nit:=A0 The document recommends removal of the implementation status sec= tion, but not the appendices, including the one which gives the design rati= onale.=A0 I'd either move the implementation status to an appendix and = keep the all, or remove them all.=A0 But this is obviously an editorial cho= ice, not a substantive issue.


--20cf3010e99fc5ac4104e413967b-- From stpeter@stpeter.im Fri Aug 16 20: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 875B611E819A for ; Fri, 16 Aug 2013 20:17:07 -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=[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 Y4VA3vNEGUuP for ; Fri, 16 Aug 2013 20:17:03 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1F50F21F9F96 for ; Fri, 16 Aug 2013 20:17:03 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4BE4D414F7; Fri, 16 Aug 2013 21:20:08 -0600 (MDT) Message-ID: <520EEB2B.1010608@stpeter.im> Date: Fri, 16 Aug 2013 21:16:59 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] RFC 5785: registering well-known URIs 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, 17 Aug 2013 03:17:07 -0000 RFC 5785 provides a way to register well-known URIs. It seems to me that there are gaps in the spec regarding the registration procedures. As an example, consider the recently-approved specification for Enrollment over Secure Transport: https://datatracker.ietf.org/doc/draft-ietf-pkix-est/ That specification registers a URI suffix of "est" but in fact defines and uses a number of well-known URIs, such as: /.well-known/est/cacerts /.well-known/est/simpleenroll /.well-known/est/csrattrs /.well-known/est/serverkeygen How is IANA supposed to know whether it needs to also register all of those well-known URIs? Is IANA supposed to disallow future registration requests that begin with "est"? (For example, is it expected that IANA will deny a request to register "/.well-known/estimation" since "est" is a registered suffix?) RFC 5785 tries to cover these issues by saying the following: Typically, a registration will reference a specification that defines the format and associated media type to be obtained by dereferencing the well-known URI. It MAY also contain additional information, such as the syntax of additional path components, query strings and/or fragment identifiers to be appended to the well-known URI, or protocol-specific details (e.g., HTTP [RFC2616] method handling). However, at least in the case of the EST spec the registration request doesn't contain enough information for the IANA to really know what to do: IANA is to update the well-known URI registry with the following filled-in template from [RFC5785]. URI suffix: est Change controller: IETF I'm of the opinion that RFC 5785 is missing some details here, however if I'm the only one who finds it lacking then I won't pursue the issue further and will leave it up to the designated expert for the well-known URI registry to handle things on a case-by-case basis. Peter -- Peter Saint-Andre https://stpeter.im/ From sm@resistor.net Fri Aug 16 21:38: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 58B8F11E8208 for ; Fri, 16 Aug 2013 21:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 140K7-55omM5 for ; Fri, 16 Aug 2013 21:38:31 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E115511E80D2 for ; Fri, 16 Aug 2013 21:38:30 -0700 (PDT) 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 r7H4cMJK002868; Fri, 16 Aug 2013 21:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1376714307; bh=xpXumwQZv62i0BWavn3ulfdvFVbMW9ba8la95IQIHYI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=mhqVuwu4LmRF6NeUGQJUtasI1HDJMO9tSjuzHK3pZ7M4dYU1lZh/nBKixeAS8r2FI 7Oij6DYhJBfkba26+QhdgpRzyqUjTV4m27rqNM8QXbAhs+eBES3lH2Ktut7i7AxVrG 0pwYCLAIaSehcb/tj6KhI0UxPeW1HzBbJJL+y+t0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1376714307; i=@resistor.net; bh=xpXumwQZv62i0BWavn3ulfdvFVbMW9ba8la95IQIHYI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=CRhGyJDi53jckAgN2bew7g9aUa8OLcI5up22ypzfKIqhcNjttcZbwlbQJMYZkw/nA TTGtuV7c3/g4Dog3uppvEOTiDi2g6JJ8pAr9M4Xr+QCFduh2cEoi6uVvF1zI1ZhR2m riVciNYRcs/C7VFM8EOzdVoJIcxwJzrMxOFYIVGE= Message-Id: <6.2.5.6.2.20130816212016.0b0c1fe8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 16 Aug 2013 21:38:18 -0700 To: Peter Saint-Andre From: SM In-Reply-To: <520EEB2B.1010608@stpeter.im> References: <520EEB2B.1010608@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] RFC 5785: registering well-known URIs 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, 17 Aug 2013 04:38:34 -0000 Hi Peter, At 20:16 16-08-2013, Peter Saint-Andre wrote: >RFC 5785 provides a way to register well-known URIs. It seems to me that >there are gaps in the spec regarding the registration procedures. As an >example, consider the recently-approved specification for Enrollment >over Secure Transport: > >https://datatracker.ietf.org/doc/draft-ietf-pkix-est/ > >That specification registers a URI suffix of "est" but in fact defines >and uses a number of well-known URIs, such as: > >/.well-known/est/cacerts >/.well-known/est/simpleenroll >/.well-known/est/csrattrs >/.well-known/est/serverkeygen > >How is IANA supposed to know whether it needs to also register all of >those well-known URIs? Is IANA supposed to disallow future registration >requests that begin with "est"? (For example, is it expected that IANA >will deny a request to register "/.well-known/estimation" since "est" is >a registered suffix?) RFC 5785 says that: "Well-known URIs are registered on the advice of one or more Designated Experts (appointed by the IESG or their delegate)" To answer the above question, IANA asks the Designated Expert. What I need to know is why I am seeing a "/.well-known/est/cacerts" request in my web server logs. If the information is available through the relevant registry it is not a problem. >RFC 5785 tries to cover these issues by saying the following: > > Typically, a registration will reference a specification that defines > the format and associated media type to be obtained by dereferencing > the well-known URI. > > It MAY also contain additional information, such as the syntax of > additional path components, query strings and/or fragment identifiers > to be appended to the well-known URI, or protocol-specific details > (e.g., HTTP [RFC2616] method handling). My reading of the above is that the information can listed there. I would say that it is unclear to the person asking for registration as the submission template only mentions citations in that field. Regards, -sm From internet-drafts@ietf.org Sun Aug 18 10: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 048FA21F92B8; Sun, 18 Aug 2013 10:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, 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 Y9Q+1+S4PRN9; Sun, 18 Aug 2013 10:55:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD0621F8FDC; Sun, 18 Aug 2013 10:55:35 -0700 (PDT) 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.70.p1 Message-ID: <20130818175535.13042.70378.idtracker@ietfa.amsl.com> Date: Sun, 18 Aug 2013 10:55:35 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-00.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: Sun, 18 Aug 2013 17:55: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 Author(s) : William J. Mills Murray S. Kucherawy Filename : draft-ietf-appsawg-rrvs-header-field-00.txt Pages : 11 Date : 2013-08-18 Abstract: This document defines an email header field, 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 header field is on automatically generated messages that might contain sensitive information. 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-00 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 ietf-secretariat-reply@ietf.org Sun Aug 18 11:12: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 08C1E11E80EF for ; Sun, 18 Aug 2013 11:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.047, 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 JCb9AOMAOXwx for ; Sun, 18 Aug 2013 11:12:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5301A11E814B for ; Sun, 18 Aug 2013 11:12:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130818181228.14861.13699.idtracker@ietfa.amsl.com> Date: Sun, 18 Aug 2013 11:12:28 -0700 From: IETF Secretariat Subject: [apps-discuss] Milestones changed for appsawg WG 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, 18 Aug 2013 18:12:29 -0000 URL: http://datatracker.ietf.org/wg/appsawg/charter/ From ietf-secretariat-reply@ietf.org Sun Aug 18 12:38: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 1A0D111E811F for ; Sun, 18 Aug 2013 12:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.050, 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 d7lRi6LwjHGG for ; Sun, 18 Aug 2013 12:38:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 523D811E8164 for ; Sun, 18 Aug 2013 12:38:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130818193800.1681.49561.idtracker@ietfa.amsl.com> Date: Sun, 18 Aug 2013 12:38:00 -0700 From: IETF Secretariat Subject: [apps-discuss] Milestones changed for appsawg WG 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, 18 Aug 2013 19:38:01 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-rrvs-header-field", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/appsawg/charter/ From msk@blackops.org Mon Aug 19 00:03: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 7B31821F9950; Mon, 19 Aug 2013 00:03:49 -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 Jl4gYyICLumw; Mon, 19 Aug 2013 00:03:45 -0700 (PDT) Received: from medusa.blackops.org (medusa.blackops.org [208.69.40.157]) by ietfa.amsl.com (Postfix) with ESMTP id 140F321F97E6; Mon, 19 Aug 2013 00:03:45 -0700 (PDT) Received: from medusa.blackops.org (msk@localhost.blackops.org [127.0.0.1]) by medusa.blackops.org (8.14.5/8.14.5) with ESMTP id r7J73e8W064637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Aug 2013 00:03:41 -0700 (PDT) (envelope-from msk@medusa.blackops.org) DKIM-Filter: OpenDKIM Filter v2.8.3 medusa.blackops.org r7J73e8W064637 X-SenderID: Sendmail Sender-ID Filter v1.0.0 medusa.blackops.org r7J73e8W064637 Authentication-Results: medusa.blackops.org; sender-id=permerror header.from=superuser@gmail.com; spf=none smtp.mfrom=msk@medusa.blackops.org Received: (from msk@localhost) by medusa.blackops.org (8.14.5/8.14.5/Submit) id r7J73c0h064636; Mon, 19 Aug 2013 00:03:38 -0700 (PDT) (envelope-from msk) Date: Mon, 19 Aug 2013 00:03:38 -0700 (PDT) Message-Id: <201308190703.r7J73c0h064636@medusa.blackops.org> From: "Murray S. Kucherawy" To: apps-discuss@ietf.org, draft-ietf-geopriv-res-gw-lis-discovery.all@tools.ietf.org Cc: iesg@ietf.org Subject: [apps-discuss] AppsDir reivew of draft-ietf-geopriv-res-gw-lis-discovery 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, 19 Aug 2013 07:03:49 -0000 I have been selected as the Applications Area Directorate (appsdir) 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-geopriv-res-gw-lis-discovery Title: Location Information Server (LIS) Discovery using IP address and Reverse DNS Reviewer: Murray S. Kucherawy Review Date: August 18, 2013 IETF Last Call Date: Completed July 31, 2013 IESG Telechat Date: N/A SUMMARY: This document is mostly ready to go as an Informational document, but a few things in terms of document flow need to be reviewed, plus some other minor points need consideration. MAJOR ISSUES: I found an issue with the flow of the document going from 4.1 to 4.2. I had to re-read 4.2 several times to understand what's going on here. Maybe a quick set of ordered bullets that show the general steps the algorithm will follow, probably up in Section 4, would help. Something like: "The goal here is to produce a small set of NAPTR queries to find the LIS based on a set of derived IP addresses. The steps of the algorithm are: 1. collect some IP addresses that refer to the Device 2. convert them into in-addr.arpa or ip6.arpa style names 3. issue NAPTR queries on those names 4. progressively shorten the names and repeat the queries until a hit is found" ..using wording to your liking. Then Section 4.1 maps to step 1 and Section 4.2 maps to steps 2-4 quite nicely. You could break Section 4.2 up such that each step has its own (small) section as well, and turn what you have now as 4.3 into 5, and so on downward. The main point is that I didn't really understand how you were trying to accomplish your goal until I was most of the way through 4.2. MINOR ISSUES: The use of "Device" as (apparently) a proper noun without a definition is curious. There are some uses of "device" as well, and I don't know how they're different. In Section 3.1, the sixth paragraph ("Existing residential gateways...") seems unnecessary given the content of the one right before it. In Section 4.2, the SHOULD NOT doesn't seem to be right to me as it doesn't affect this protocol at all should that advice be ignored. I agree a bunch of extra unnecessary DNS traffic is avoided if an operator complies, which is hardly a bad thing, but this specific protocol is unaffected. Section 4.2 would really benefit from at least one example. The second paragraph of Section 4.6 seems redundant to the discussion in Section 4.1. Are the SHOULDs in Section 4.7 meant to describe protocol interoperability requirements, or capability requirements (a la an Applicability Statement)? Sections 4.2 and 4.7 talk about the "upward" walk to find the NAPTR record. If, say, a v4 operator only puts a record at a /16 node, then it's guaranteed to get three queries for every Device connecting. It's guaranteed four in the case of a v6 operator who only puts a record at a /32 node. I wonder if this is worth mentioning as a tradeoff versus a smaller zone file, or if it's just plain obvious, or if caching is expected to handle most of this. Shouldn't RFC3424 be Informative? NITS: Section 1: s/when it is considered/when one considers/ Section 4: OLD: "...each IP address that it is potentially reachable from." NEW: "...each IP address from which it is potentially reachable." Section 4.1: OLD: "...by any access network these methods are not mandated." NEW: "...by any access network, these methods are not mandated." Section 4.6: OLD: "Configuration of STUN server ..." NEW: "Configuration of a STUN server ..." The acronym "UNSAF" has to make at least some security people giggle. From GK@ninebynine.org Mon Aug 19 03:10: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 2997211E823B for ; Mon, 19 Aug 2013 03:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 BBapY7LRQJ2s for ; Mon, 19 Aug 2013 03:10:17 -0700 (PDT) Received: from relay12.mail.ox.ac.uk (relay12.mail.ox.ac.uk [129.67.1.163]) by ietfa.amsl.com (Postfix) with ESMTP id 4211411E8232 for ; Mon, 19 Aug 2013 03:10:17 -0700 (PDT) Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay12.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1VBMPa-0007MO-da; Mon, 19 Aug 2013 11:10:10 +0100 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1VBMPZ-0003u0-9S; Mon, 19 Aug 2013 11:10:10 +0100 Message-ID: <5211C4CF.5020806@ninebynine.org> Date: Mon, 19 Aug 2013 08:10:07 +0100 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: SM References: <520EEB2B.1010608@stpeter.im> <6.2.5.6.2.20130816212016.0b0c1fe8@resistor.net> In-Reply-To: <6.2.5.6.2.20130816212016.0b0c1fe8@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] RFC 5785: registering well-known URIs 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, 19 Aug 2013 10:10:23 -0000 On 17/08/2013 05:38, SM wrote: > Hi Peter, > At 20:16 16-08-2013, Peter Saint-Andre wrote: >> RFC 5785 provides a way to register well-known URIs. It seems to me that >> there are gaps in the spec regarding the registration procedures. As an >> example, consider the recently-approved specification for Enrollment >> over Secure Transport: >> >> https://datatracker.ietf.org/doc/draft-ietf-pkix-est/ >> >> That specification registers a URI suffix of "est" but in fact defines >> and uses a number of well-known URIs, such as: >> >> /.well-known/est/cacerts >> /.well-known/est/simpleenroll >> /.well-known/est/csrattrs >> /.well-known/est/serverkeygen >> >> How is IANA supposed to know whether it needs to also register all of >> those well-known URIs? Is IANA supposed to disallow future registration >> requests that begin with "est"? (For example, is it expected that IANA >> will deny a request to register "/.well-known/estimation" since "est" is >> a registered suffix?) > > RFC 5785 says that: > > "Well-known URIs are registered on the advice of one or more > Designated Experts (appointed by the IESG or their delegate)" > > To answer the above question, IANA asks the Designated Expert. What I need to > know is why I am seeing a "/.well-known/est/cacerts" request in my web server > logs. If the information is available through the relevant registry it is not a > problem. Without taking a view on the broader question, I don't think this really answers the issue raised. As designated reviewer for two other registries, I regard my role is not to make technical judgements so much as to provide a cross-check that the intent of the registration rules is being followed. As such, I rely quite heavily on the registration procedure documents to help me separate my own technical preferences from the requirements set out in the registration procedures. Where there is lack of clarity in the registration procedure, that makes my job harder. And a thought: updating a registration RFC is relatively hard work. Something that might be useful is an IETF wiki somewhere which can be used to collect registration guidance notes, based on conversations between the designated expert, IANA and other interested parties. We've discussed something vaguely along these lines previously, but that effort sort of fizzled out. So what I suggest here is to use a wiki in a very lightweight way to act as a kind of "group memory" for issues like this as they are raised and resolved, so we have a better chance of maintaining consistency over time and changes of peropkle involved. #g -- > >> RFC 5785 tries to cover these issues by saying the following: >> >> Typically, a registration will reference a specification that defines >> the format and associated media type to be obtained by dereferencing >> the well-known URI. >> >> It MAY also contain additional information, such as the syntax of >> additional path components, query strings and/or fragment identifiers >> to be appended to the well-known URI, or protocol-specific details >> (e.g., HTTP [RFC2616] method handling). > > My reading of the above is that the information can listed there. I would say > that it is unclear to the person asking for registration as the submission > template only mentions citations in that field. > > Regards, > -sm > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From barryleiba.mailing.lists@gmail.com Mon Aug 19 07:09: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 9DBB911E8102 for ; Mon, 19 Aug 2013 07:09:13 -0700 (PDT) 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.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 FRdn3p5-jkLn for ; Mon, 19 Aug 2013 07:09:13 -0700 (PDT) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1881C11E80E3 for ; Mon, 19 Aug 2013 07:09:12 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id ha12so3012434vcb.37 for ; Mon, 19 Aug 2013 07:09:12 -0700 (PDT) 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=QJvypTCpuikuz6bA3Fol/jk7TqV6CpKmOIwxZEi3u1g=; b=yE8YuaA2PN6db4gd+BWHXNMJ25x0D3IUkJTTbItqzkVbwZ0YZsomtMB1yhhZxwh3Dj ZQK3UCaT76VUJFtXa2na+wSCtIlxn0/MYzqqrSfliRVAeAXFbUmCzUNpN9CGpwct4kzE jp6M6Envv27YCOARkIpZ5wLXxkQoqnknqfQ1ixOtmYs1a+Mg2j98NEgbS7JRRRgqXLNv QyJ9B6nbLkQ2FJRInTPC8Np/hsC8+/kec+ZmW3aVSAvkW7T0oSloGVT7Mu7OnkAFbA4t updQ3WyBqf4V71gMy0ONZkKVs1DdkIrDZdY2H6L+xX9lnfu5J3VC98eusThPTJr4MvoL ORig== MIME-Version: 1.0 X-Received: by 10.58.235.69 with SMTP id uk5mr13738132vec.17.1376921352083; Mon, 19 Aug 2013 07:09:12 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.215.16 with HTTP; Mon, 19 Aug 2013 07:09:12 -0700 (PDT) In-Reply-To: <520EEB2B.1010608@stpeter.im> References: <520EEB2B.1010608@stpeter.im> Date: Mon, 19 Aug 2013 16:09:12 +0200 X-Google-Sender-Auth: -X0-T2kkiPesoSxTVjRrxSvgwHQ Message-ID: From: Barry Leiba To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] RFC 5785: registering well-known URIs 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, 19 Aug 2013 14:09:13 -0000 > That specification registers a URI suffix of "est" but in fact defines > and uses a number of well-known URIs, such as: > > /.well-known/est/cacerts > /.well-known/est/simpleenroll > /.well-known/est/csrattrs > /.well-known/est/serverkeygen > > How is IANA supposed to know whether it needs to also register all of > those well-known URIs? Is IANA supposed to disallow future registration > requests that begin with "est"? (For example, is it expected that IANA > will deny a request to register "/.well-known/estimation" since "est" is > a registered suffix?) There are two issues here: how to handle the "est" situation, and how to deal with the situation in general. My view of the first is that this should be clearly specified in the document that does the registration; it should clearly say that it is registering "est" and reserves the entire hierarchy below that, if that's what it means to do. For the second, we do have an open question. The intent of RFC 5785 is to provide, with .well-known, an entry point for a particular purpose. Using that thinking, the "est" document should register four well-known URIs, not just one. And if someone should want to use "/est/banana" later, that should have to be separately registered. It's certainly easy to argue that this is a better approach. If we allow it to be open-ended, then the "est" document theoretically reserves "/est/banana" and "/est/apple", but doesn't define their uses or meanings. There's also the issue of how to handle existing registrations. Are we now saying that "/caldav/office", "/core/sensors", and "/webfinger/author" are reserved? If so, what do they mean? Do they make sense without a specification? If they don't, then why not just have them reserved by a new specification when they're needed? On the other hand, if a specification such as "est" expects extensions and wants to reserve the namespace -- "/est/banana" isn't defined, but can only be reserved by an "est" extension -- perhaps it should be reasonable for it to be able to do that. I think if we want that feature, we can decide that it's how this case will work, and then submit a document that updates 5785 to generalize it. Barry From tbray@textuality.com Mon Aug 19 07:21: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 0ABC011E8102 for ; Mon, 19 Aug 2013 07:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[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 xz+dEmIEkyIN for ; Mon, 19 Aug 2013 07:21:21 -0700 (PDT) Received: from mail-vb0-f42.google.com (mail-vb0-f42.google.com [209.85.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id AFD7F21F8EC3 for ; Mon, 19 Aug 2013 07:21:17 -0700 (PDT) Received: by mail-vb0-f42.google.com with SMTP id e12so3252873vbg.15 for ; Mon, 19 Aug 2013 07:21:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=X5PlopsuBce948P4TaZC0r03tQnys8TDOTdvaknA73Y=; b=fqX5HTmNzQ8OUI+4Q1bDLP1i8pweqFxvgKoa/VF9MH3jnCVdHcDdfZlOavMI2kDeVN ve4Jdjtvgc+IkBqDOCRWq7I5WyC9P4Tpp10QDhaWSU6uKOonl/BUMia0i7mM/9Bsxsdh UE805EqFr1NJ51nAz5xOlIrdlmh9/RooSnvM4xv9LtG8Q2y1dMPAuAjhgiopyGINBnYY Nqq3WIf0WZmIYG991FV9+5lS/Bbdi6I9UPJt1e0C0gS2aVeXbKChA61aqZHackBxMlBF uxyJvKSlkeDDkSceTt0H9MRlTIWvMXWs9d2MHfOmkReGw0VnOPTc5RbFKRjICqcawHLC I0Hw== X-Gm-Message-State: ALoCoQl4o63w/+4vvrC4Ktvn80fkxKOFXOiMNyCD11sdvA82V366T1Ji1FUJGMDg6pI5YDJp89Xr MIME-Version: 1.0 X-Received: by 10.58.106.82 with SMTP id gs18mr7782015veb.18.1376922076296; Mon, 19 Aug 2013 07:21:16 -0700 (PDT) Received: by 10.220.212.202 with HTTP; Mon, 19 Aug 2013 07:21:16 -0700 (PDT) X-Originating-IP: [209.121.225.226] In-Reply-To: References: <520EEB2B.1010608@stpeter.im> Date: Mon, 19 Aug 2013 07:21:16 -0700 Message-ID: From: Tim Bray To: Barry Leiba Content-Type: multipart/alternative; boundary=047d7b6d88c83dc6c104e44da7ea Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] RFC 5785: registering well-known URIs 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, 19 Aug 2013 14:21:26 -0000 --047d7b6d88c83dc6c104e44da7ea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hm, I could imagine a situation in which I register /.well-known/foo and all URIs that begin that way, but if I did that I think I=E2=80=99d have to= provide rules on how they=E2=80=99re constructed and use. So, failing that... what = Barry said -T On Mon, Aug 19, 2013 at 7:09 AM, Barry Leiba wrote= : > > That specification registers a URI suffix of "est" but in fact defines > > and uses a number of well-known URIs, such as: > > > > /.well-known/est/cacerts > > /.well-known/est/simpleenroll > > /.well-known/est/csrattrs > > /.well-known/est/serverkeygen > > > > How is IANA supposed to know whether it needs to also register all of > > those well-known URIs? Is IANA supposed to disallow future registration > > requests that begin with "est"? (For example, is it expected that IANA > > will deny a request to register "/.well-known/estimation" since "est" i= s > > a registered suffix?) > > There are two issues here: how to handle the "est" situation, and how > to deal with the situation in general. > > My view of the first is that this should be clearly specified in the > document that does the registration; it should clearly say that it is > registering "est" and reserves the entire hierarchy below that, if > that's what it means to do. > > For the second, we do have an open question. The intent of RFC 5785 > is to provide, with .well-known, an entry point for a particular > purpose. Using that thinking, the "est" document should register four > well-known URIs, not just one. And if someone should want to use > "/est/banana" later, that should have to be separately registered. > It's certainly easy to argue that this is a better approach. If we > allow it to be open-ended, then the "est" document theoretically > reserves "/est/banana" and "/est/apple", but doesn't define their uses > or meanings. > > There's also the issue of how to handle existing registrations. Are > we now saying that "/caldav/office", "/core/sensors", and > "/webfinger/author" are reserved? If so, what do they mean? Do they > make sense without a specification? If they don't, then why not just > have them reserved by a new specification when they're needed? > > On the other hand, if a specification such as "est" expects extensions > and wants to reserve the namespace -- "/est/banana" isn't defined, but > can only be reserved by an "est" extension -- perhaps it should be > reasonable for it to be able to do that. > > I think if we want that feature, we can decide that it's how this case > will work, and then submit a document that updates 5785 to generalize > it. > > Barry > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --047d7b6d88c83dc6c104e44da7ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hm, I could imagine a situation in which I register /= .well-known/foo and all URIs that begin that way, but if I did that I think= I=E2=80=99d have to provide rules on how they=E2=80=99re constructed and u= se. So, failing that... what Barry said
=C2=A0-T


On Mon, Aug 19, 2013 at 7:09 AM, Barry Leiba &= lt;barryleiba@= computer.org> wrote:
> That specification registers a URI suff= ix of "est" but in fact defines
> and uses a number of well-known URIs, such as:
>
> /.well-known/est/cacerts
> /.well-known/est/simpleenroll
> /.well-known/est/csrattrs
> /.well-known/est/serverkeygen
>
> How is IANA supposed to know whether it needs to also register all of<= br> > those well-known URIs? Is IANA supposed to disallow future registratio= n
> requests that begin with "est"? (For example, is it expected= that IANA
> will deny a request to register "/.well-known/estimation" si= nce "est" is
> a registered suffix?)

There are two issues here: how to handle the "est" situation, and= how
to deal with the situation in general.

My view of the first is that this should be clearly specified in the
document that does the registration; it should clearly say that it is
registering "est" and reserves the entire hierarchy below that, i= f
that's what it means to do.

For the second, we do have an open question. =C2=A0The intent of RFC 5785 is to provide, with .well-known, an entry point for a particular
purpose. =C2=A0Using that thinking, the "est" document should reg= ister four
well-known URIs, not just one. =C2=A0And if someone should want to use
"/est/banana" later, that should have to be separately registered= .
It's certainly easy to argue that this is a better approach. =C2=A0If w= e
allow it to be open-ended, then the "est" document theoretically<= br> reserves "/est/banana" and "/est/apple", but doesn'= t define their uses
or meanings.

There's also the issue of how to handle existing registrations. =C2=A0A= re
we now saying that "/caldav/office", "/core/sensors", a= nd
"/webfinger/author" are reserved? =C2=A0If so, what do they mean?= =C2=A0Do they
make sense without a specification? =C2=A0If they don't, then why not j= ust
have them reserved by a new specification when they're needed?

On the other hand, if a specification such as "est" expects exten= sions
and wants to reserve the namespace -- "/est/banana" isn't def= ined, but
can only be reserved by an "est" extension -- perhaps it should b= e
reasonable for it to be able to do that.

I think if we want that feature, we can decide that it's how this case<= br> will work, and then submit a document that updates 5785 to generalize
it.

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

--047d7b6d88c83dc6c104e44da7ea-- From vkg@bell-labs.com Mon Aug 19 08:26: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 77D0811E80E1; Mon, 19 Aug 2013 08:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.836 X-Spam-Level: X-Spam-Status: No, score=-109.836 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, 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 0rYEtN-Il7tt; Mon, 19 Aug 2013 08:26:37 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id DE1C611E810A; Mon, 19 Aug 2013 08:26:36 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r7JFQZ2l008641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Aug 2013 10:26:35 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r7JFQYwl006239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Aug 2013 10:26:35 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r7JFQWiW010749; Mon, 19 Aug 2013 10:26:34 -0500 (CDT) Message-ID: <52123A42.6030405@bell-labs.com> Date: Mon, 19 Aug 2013 10:31:14 -0500 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: draft-ietf-dime-overload-reqs.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: IESG IESG , "apps-discuss@ietf.org" Subject: [apps-discuss] APPSDIR review of draft-ietf-dime-overload-reqs-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: Mon, 19 Aug 2013 15:26:41 -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-dime-overload-reqs-10 Title: Diameter Overload Control Requirements Reviewer: Vijay K. Gurbani Review Date: Aug-19-2013 IETF Last Call Date: Not known IESG Telechat Date: Not known Summary: This draft is ready for publication as an Informational RFC; two minor issues follow. Major comments: 0 Minor comments: 1 Nits: 1 Minor: ====== - Abstract - You may consider taking out the Section numbers in the Abstract. They really do not belong there, and you can impart the same information without using the section numbers (e.g., "Existing Diameter mechanisms are not sufficient for this purpose. This document describes the limitations of the existing mechanisms and proposes requirements for new overload management mechanisms.") Nits: ===== - S3.2, first paragraph: "This document is a work in progress...", here, "This" refers to TR23.843 or does it refer to dime-overload- reqs-10? Please clarify. On further reading, there are more "this document" spread in the subsection with providing an adequate text that qualifies the "this". Thanks, - 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 gsalguei@cisco.com Mon Aug 19 21:38: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 4768911E819A for ; Mon, 19 Aug 2013 21:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 A9uh5yJhxk43 for ; Mon, 19 Aug 2013 21:38:11 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 085A911E80F9 for ; Mon, 19 Aug 2013 21:38:09 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7K4c5fe020647 for ; Tue, 20 Aug 2013 06:38:06 +0200 (CEST) Received: from rtp-gsalguei-8917.cisco.com (rtp-gsalguei-8917.cisco.com [10.116.132.56]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7K4c3GO021878; Tue, 20 Aug 2013 00:38:03 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Gonzalo Salgueiro In-Reply-To: Date: Tue, 20 Aug 2013 00:38:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ted Hardie X-Mailer: Apple Mail (2.1508) Cc: IESG , apps-discuss@ietf.org, draft-nandakumar-rtcweb-stun-uri.all@tools.ietf.org Subject: Re: [apps-discuss] Apps directorate review of draft-nandakumar-rtcweb-stun-uri-5.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: Tue, 20 Aug 2013 04:38:17 -0000 Ted -=20 Thanks for your review and feedback. Some comments inline... On Aug 16, 2013, at 1:04 PM, Ted Hardie 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. > Document: draft-nandakumar-rtcweb-stun-uri-5.txt >=20 > Title: URI Scheme for Session Traversal Utilities for NAT (STUN) = Protocol >=20 > Reviewer: Ted Hardie > Review Date: August 16th, 2013 > Summary: This document is ready to be published as an informational = RFC; it currently gives a target of standards track, but I do not = believe this is required. While registration of a URI does not mandate a Standards Track document, = I suspect there is some level of subjectivity here. Our view is that If = we had gone to the IETF after the fact (i.e., the URIs were used in = products) and then we documented them in an RFC, then yes, we would = agree that Informational is more appropriate. But in this instance that = was not the case . We went to the IETF first and interacted with = experts to develop a normative specification that provides protocol = directive. This, Standard Track seems the more appropriate status in = this case. >=20 > Discussion: The draft has had some discussion in response to comments = by Graham Klyne, the Designated Expert for URI schemes. I personally = believe that this document has sufficient utility to qualify for = permanent registration, both in the WebRTC context and potentially in = similar contexts. I also am not terribly worried that it duplicates the = ABNF of RFC 3986; while it certainly could have done it differently, the = chances of drift in definition in this case seem low enough to be = harmless. Good to hear as that our (the authors) collective position on this as = well. >=20 > Nit: The document recommends removal of the implementation status = section, but not the appendices, including the one which gives the = design rationale. I'd either move the implementation status to an = appendix and keep the all, or remove them all. But this is obviously an = editorial choice, not a substantive issue. The reason we proceeded as we have is because removing the = implementation status report was mandated by RFC 6982, while the design = notes were important for future implementers to understand the choices = (and was done at the request of the document Shepherd). Cheers, Gonzalo >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From jouni.nospam@gmail.com Mon Aug 19 11:31: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 8B41811E814E; Mon, 19 Aug 2013 11:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 SkHt7ICVTHVv; Mon, 19 Aug 2013 11:31:21 -0700 (PDT) Received: from mail-ea0-x234.google.com (mail-ea0-x234.google.com [IPv6:2a00:1450:4013:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8D111E813F; Mon, 19 Aug 2013 11:31:21 -0700 (PDT) Received: by mail-ea0-f180.google.com with SMTP id h10so2480689eaj.11 for ; Mon, 19 Aug 2013 11:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=z8GnioHPlfAmd07RsNkp0iH2XT39qoPA16y27aAbBa0=; b=al2oAk7xT202c0eAYLF7FHwwrrCHHF3lcSViAudc+6ApgtjIk59hCOfEjhshV2z8yX fqMz6YLXPg3HyDHWuNooDLveurpMtEUK7S5p4sMDAU2kuMhtp2d4rFxjNOi7iVkS2tcR ZICTTDFx4NizcM5N9J8ZJGJwlICg4w0CqbRTcaRc1AstcxKEPh3VzNGp6CtCfA45BmCv ob+bZFBRf8P3VaJwWTwFPudoPqtNSs8R/05iAsNtdK/yNc3ybR6rjWPu1QyJ9Igfmnig oBEjfZneXTXuHgvbBJIKiRPjZRaxr2AC7rHzjIoYSGL9WCn4PSiNrvZyKu0hKmLfZuTj 4jsQ== X-Received: by 10.14.183.2 with SMTP id p2mr14944319eem.44.1376937079622; Mon, 19 Aug 2013 11:31:19 -0700 (PDT) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id a6sm19111789eei.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Aug 2013 11:31:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: <52123A42.6030405@bell-labs.com> Date: Mon, 19 Aug 2013 21:31:15 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4D7F7392-6216-4E43-BD8D-C0CEB7FC53BF@gmail.com> References: <52123A42.6030405@bell-labs.com> To: Vijay K. Gurbani X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Tue, 20 Aug 2013 09:18:26 -0700 Cc: draft-ietf-dime-overload-reqs.all@tools.ietf.org, IESG IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-dime-overload-reqs-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: Mon, 19 Aug 2013 18:31:22 -0000 Thanks Vijay, Regarding > - S3.2, first paragraph: "This document is a work in progress...", > here, "This" refers to TR23.843 or does it refer to dime-overload- > reqs-10? Please clarify. On further reading, there are more "this document" is supposed to refer to TR23.843. We'll makes the reference more clear. - Jouni On Aug 19, 2013, at 6:31 PM, Vijay K. Gurbani wrote: > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see =E2=80=8B > = 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. >=20 > Document: draft-ietf-dime-overload-reqs-10 > Title: Diameter Overload Control Requirements > Reviewer: Vijay K. Gurbani > Review Date: Aug-19-2013 > IETF Last Call Date: Not known > IESG Telechat Date: Not known >=20 > Summary: This draft is ready for publication as an Informational > RFC; two minor issues follow. >=20 > Major comments: 0 > Minor comments: 1 > Nits: 1 >=20 > Minor: > =3D=3D=3D=3D=3D=3D > - Abstract - You may consider taking out the Section numbers in the > Abstract. They really do not belong there, and you can impart the same > information without using the section numbers (e.g., "Existing > Diameter mechanisms are not sufficient for this purpose. This > document describes the limitations of the existing mechanisms and > proposes requirements for new overload management mechanisms.") >=20 > Nits: > =3D=3D=3D=3D=3D > - S3.2, first paragraph: "This document is a work in progress...", > here, "This" refers to TR23.843 or does it refer to dime-overload- > reqs-10? Please clarify. On further reading, there are more > "this document" spread in the subsection with providing an adequate > text that qualifies the "this". >=20 > Thanks, >=20 > - vijay > --=20 > 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 superuser@gmail.com Wed Aug 21 16:59: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 CE1AE11E816D for ; Wed, 21 Aug 2013 16:59:39 -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=[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 9-45FX5KTYVl for ; Wed, 21 Aug 2013 16:59:39 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id EF6B311E80F5 for ; Wed, 21 Aug 2013 16:59:38 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hr7so1399550wib.4 for ; Wed, 21 Aug 2013 16:59:37 -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=fWSRm1MfMS0J7fKANJiHzBixQG0XWeWAwV31L0yKDis=; b=kr17AqPmECv9ProBDrQpDy0RKbLtXxtS4pCYI8Ux+r9wgSx1wiHBntyjLy5Pcnt8wr dDUUuHW0/oDIEFh3BzNSAkw/oIWxv9KxsQw5FvuEa9OizPozVH/QtmHh5s4H0YQ73JSf NWk+nzkmVRKAEVcrXNrHw8ClL1vbnjZjJzWbwIqN7xXwIVYxMM/ARlJqjyyDwqn/eko0 CCZHnvop8ImEY1Y5bHaE/8z0RFVzzg6bz1aic6LBCBLeqst3vyiuXz1dpkfjXoZXGUyl +ESAmmBhDXwn4vZoU6hAHXXOtTUYfKUdxGwzZUxnQoibnEIhyH9CyQIC2vjGYnseDmaM ua0w== MIME-Version: 1.0 X-Received: by 10.180.109.35 with SMTP id hp3mr18366105wib.52.1377129577777; Wed, 21 Aug 2013 16:59:37 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Wed, 21 Aug 2013 16:59:37 -0700 (PDT) Date: Wed, 21 Aug 2013 16:59:37 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=e89a8f3ba25b4b0f3604e47df7ca Subject: [apps-discuss] DNS work 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, 21 Aug 2013 23:59:40 -0000 --e89a8f3ba25b4b0f3604e47df7ca Content-Type: text/plain; charset=ISO-8859-1 In giving the audio from IETF 87 a re-listen, it seems as if the two DNS items we had at the end of the agenda had a non-trivial amount of interest. I wonder if we could engage the group about adopting some of that here, or at least someplace in APPS. The first is draft-levine-dnsextlang, which proposes a method to describe the syntax of new DNS RRTYPEs so that various kinds of DNS software can auto-provision. There was explicit support from a few people for the notion of doing this work, with some discussion about whether this would be in the DNS itself or elsewhere. The second was the two proposals by Andrew Sullivan and John Levine for ways to add a mechanism to the DNS for identifying administrative boundaries in the DNS. It also got some discussion because there are some extant (and in some cases long-lived) needs for this in the applications space. So two questions on each of these: 1) Is there support for doing this kind of work in the APPS area? In particular, is anyone prepared to commit to reviews and comments on this sort of work if it were to appear formally in some way? 2) Again in each case, if the answer to the above is yes, is the work appropriate for APPSAWG, or should the proponents look at getting BoFs together (perhaps in time for Vancouver) to form separate working groups to advance it? -MSK, APPSAWG co-chair --e89a8f3ba25b4b0f3604e47df7ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In giving the audio from IETF 87 = a re-listen, it seems as if the two DNS items we had at the end of the agen= da had a non-trivial amount of interest.=A0 I wonder if we could engage the= group about adopting some of that here, or at least someplace in APPS.

The first is draft-levine-dnsextlang, which proposes a method to = describe the syntax of new DNS RRTYPEs so that various kinds of DNS softwar= e can auto-provision.=A0 There was explicit support from a few people for t= he notion of doing this work, with some discussion about whether this would= be in the DNS itself or elsewhere.

The second was the two proposals by Andrew Sullivan and John Levine for= ways to add a mechanism to the DNS for identifying administrative boundari= es in the DNS.=A0 It also got some discussion because there are some extant= (and in some cases long-lived) needs for this in the applications space.
So two questions on each of these:

1) Is there suppo= rt for doing this kind of work in the APPS area?=A0 In particular, is anyon= e prepared to commit to reviews and comments on this sort of work if it wer= e to appear formally in some way?

2) Again in each case, if the answer to the above is yes, is the = work appropriate for APPSAWG, or should the proponents look at getting BoFs= together (perhaps in time for Vancouver) to form separate working groups t= o advance it?

-MSK, APPSAWG co-chair

--e89a8f3ba25b4b0f3604e47df7ca-- From superuser@gmail.com Wed Aug 21 17: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 E789211E8161 for ; Wed, 21 Aug 2013 17:06:40 -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, 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 nHI3oPpwyWxd for ; Wed, 21 Aug 2013 17:06:39 -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 514A811E812E for ; Wed, 21 Aug 2013 17:06:39 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id f12so973153wgh.3 for ; Wed, 21 Aug 2013 17:06:30 -0700 (PDT) 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=nLHeQXDTeR5BNfWUtK8o/jIYIowP+3d2ysHxw2mQxWE=; b=G54jDiHCp0Og4G717t+CMGgY1MBj31G+gwdCdXOf0wr6kHw1aHn+Wvs9altuST8ELn dsHuccgB80IUmWmU3yXS572sH/GfgcPdN1sJlWfuxMHq+6L95tjCQ0SdGAAdFbW4B4Ln 441ase6AnNpKuk0OIVn64hNktvRU0feqJavcEw2c3BENULqIf1ekL9S29iY4GjrOjE10 XWXnBC55nnXYY5gvBEouKk7Zh1SJEanVJS2gwpLpWwv0uUxfUENKSa55kll4AnCX9JWK GOv4VJeNJa3qhFT98jtYX3CN9zB4AgIHHM4MO2zePd4xeELjpgd0tiAmefI5L1H2YI7o j4BQ== MIME-Version: 1.0 X-Received: by 10.180.84.196 with SMTP id b4mr7483906wiz.19.1377129990784; Wed, 21 Aug 2013 17:06:30 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Wed, 21 Aug 2013 17:06:30 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 Aug 2013 17:06:30 -0700 Message-ID: From: "Murray S. Kucherawy" To: Barry Leiba Content-Type: multipart/alternative; boundary=f46d04426e2ae90d9e04e47e0f53 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Draft minutes from IETF 87 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: Thu, 22 Aug 2013 00:06:42 -0000 --f46d04426e2ae90d9e04e47e0f53 Content-Type: text/plain; charset=ISO-8859-1 I did a full listen of the audio from the session and just uploaded a set of minutes from scratch. Please let me know if I missed anything that should've been included. http://www.ietf.org/proceedings/87/minutes/minutes-87-appsawg -MSK On Fri, Aug 2, 2013 at 12:56 AM, Barry Leiba wrote: > > http://www.ietf.org/proceedings/87/minutes/minutes-87-appsawg > > > > The co-chairs thank John Levine for once again taking notes for us during > > the meeting. > > I could probably guess, without your telling me: the last item > (John's) has much more detail than the rest. So, can you (perhaps > from memory, perhaps from a review of the audio stream) put a > comparable level of detail into any of the other items? > > In particular, in the "openness of process" and "area review" items > there are questions, but no sense of the discussion. > > Editorial: > > "New WGs chairs described the new WGs" -- needs some sort of punctuation. > > "Discuss changes in review and management process Questions of > managing traffic" -- punctuation here too. > > "about half the room through it was a relevant problem" -- "thought", > not "through". > > Barry > --f46d04426e2ae90d9e04e47e0f53 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I did a full listen of the audio from the session and= just uploaded a set of minutes from scratch.=A0 Please let me know if I mi= ssed anything that should've been included.

http://www.ietf.org/p= roceedings/87/minutes/minutes-87-appsawg

-MSK


On Fri, Aug 2, 2013 at 12:56 AM, Barry Leiba &= lt;barryleiba@= computer.org> wrote:
> http= ://www.ietf.org/proceedings/87/minutes/minutes-87-appsawg
>
> The co-chairs thank John Levine for once again taking notes for us dur= ing
> the meeting.

I could probably guess, without your telling me: the last item
(John's) has much more detail than the rest. =A0So, can you (perhaps from memory, perhaps from a review of the audio stream) put a
comparable level of detail into any of the other items?

In particular, in the "openness of process" and "area review= " items
there are questions, but no sense of the discussion.

Editorial:

"New WGs chairs described the new WGs" -- needs some sort of punc= tuation.

"Discuss changes in review and management process Questions of
managing traffic" -- punctuation here too.

"about half the room through it was a relevant problem" -- "= thought",
not "through".

Barry

--f46d04426e2ae90d9e04e47e0f53-- From ned.freed@mrochek.com Wed Aug 21 17:39: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 6FB6121F938E for ; Wed, 21 Aug 2013 17:39:26 -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 60Wyy9LV6F3q for ; Wed, 21 Aug 2013 17:39:21 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id CBF0721F8F3C for ; Wed, 21 Aug 2013 17:39:21 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OXHJ9H6XO000269G@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 21 Aug 2013 17:34:17 -0700 (PDT) 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 <01OX3Y8NLHWW00004R@mauve.mrochek.com>; Wed, 21 Aug 2013 17:34:12 -0700 (PDT) Message-id: <01OXHJ9EDE6800004R@mauve.mrochek.com> Date: Wed, 21 Aug 2013 17:32:24 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 21 Aug 2013 16:59:37 -0700" References: To: "Murray S. Kucherawy" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1377131657; bh=pzMlz5wB238UXwntztQ0Qco4e9ysbMvi24QbAg4/L4w=; h=MIME-version:Content-type:Cc:Message-id:Date:From:Subject: In-reply-to:References:To; b=hSz7NqUWv6+xXhRMm8x6w0ieOz5ntIs0moztBBG4N1M8ILcDM70QhMDKRFtpYNENC u+1OZx4+bZOcpTkA+RYas2ocDCw8fzQc+JBGuMt8Aju8taB7J2NyAyXlKS+5UZ6igl /VCieaMklVhaUeCHx0Jufq1kz4qwMgrqI20AUIMY= Cc: IETF Apps Discuss Subject: Re: [apps-discuss] DNS work 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, 22 Aug 2013 00:39:26 -0000 > In giving the audio from IETF 87 a re-listen, it seems as if the two DNS > items we had at the end of the agenda had a non-trivial amount of > interest. I wonder if we could engage the group about adopting some of > that here, or at least someplace in APPS. > The first is draft-levine-dnsextlang, which proposes a method to describe > the syntax of new DNS RRTYPEs so that various kinds of DNS software can > auto-provision. There was explicit support from a few people for the > notion of doing this work, with some discussion about whether this would be > in the DNS itself or elsewhere. I think this is very important work and strongly support it, although doing it in APPS seems a little odd. But I care a lot less about where than I do about getting it done. > The second was the two proposals by Andrew Sullivan and John Levine for > ways to add a mechanism to the DNS for identifying administrative > boundaries in the DNS. It also got some discussion because there are some > extant (and in some cases long-lived) needs for this in the applications > space. I don't know enough about this space to comment either way. Ned From stpeter@stpeter.im Wed Aug 21 18:13: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 1F3EA11E81A8 for ; Wed, 21 Aug 2013 18:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.218, 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 HAfO3qQZKKQY for ; Wed, 21 Aug 2013 18:12:56 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DF82C11E81A2 for ; Wed, 21 Aug 2013 18:12:55 -0700 (PDT) Received: from sjc-vpn5-285.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D8FC441513; Wed, 21 Aug 2013 19:16:08 -0600 (MDT) Message-ID: <5215658B.3060502@stpeter.im> Date: Wed, 21 Aug 2013 19:12:43 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ned Freed References: <01OXHJ9EDE6800004R@mauve.mrochek.com> In-Reply-To: <01OXHJ9EDE6800004R@mauve.mrochek.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] DNS work 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, 22 Aug 2013 01:13:01 -0000 On 8/21/13 6:32 PM, Ned Freed wrote: >> In giving the audio from IETF 87 a re-listen, it seems as if the two DNS >> items we had at the end of the agenda had a non-trivial amount of >> interest. I wonder if we could engage the group about adopting some of >> that here, or at least someplace in APPS. > >> The first is draft-levine-dnsextlang, which proposes a method to describe >> the syntax of new DNS RRTYPEs so that various kinds of DNS software can >> auto-provision. There was explicit support from a few people for the >> notion of doing this work, with some discussion about whether this would be >> in the DNS itself or elsewhere. > > I think this is very important work and strongly support it, although doing > it in APPS seems a little odd. But I care a lot less about where than I do > about getting it done. > >> The second was the two proposals by Andrew Sullivan and John Levine for >> ways to add a mechanism to the DNS for identifying administrative >> boundaries in the DNS. It also got some discussion because there are some >> extant (and in some cases long-lived) needs for this in the applications >> space. > > I don't know enough about this space to comment either way. I'm more interested in the latter work than the former, but I suggest that the proponents of both might try to generate some discussion, feedback, and perhaps even implementation before we take the relevant I-Ds on as WG items. I for one would volunteer to review both of the administrative boundary documents. Peter -- Peter Saint-Andre https://stpeter.im/ From johnl@iecc.com Wed Aug 21 19:02: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 2112511E8196 for ; Wed, 21 Aug 2013 19:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.7 X-Spam-Level: X-Spam-Status: No, score=-102.7 tagged_above=-999 required=5 tests=[AWL=-0.101, 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 FoPgyu4laEoy for ; Wed, 21 Aug 2013 19:02:12 -0700 (PDT) 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 C3D3111E8192 for ; Wed, 21 Aug 2013 19:02:11 -0700 (PDT) Received: (qmail 82337 invoked from network); 22 Aug 2013 02:02:10 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Aug 2013 02:02:10 -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=52157122.xn--9vv.k1308; i=johnl@user.iecc.com; bh=XxamIuVvAFiaeHGCrdUbaSwrR1KeLt+BEY8+SgV/FE0=; b=vUuWkwSmbIcepGP6I8o57r+/+HFWMshS9UBMaT26VQjCDG+J1RO4CNOTtPtbu9j4eXFFHZfLwxt67RTdwL+6c2/0M7t7dZ0vi6btUynuGT9wYXVXhPLHytcSwgUKQRJvr5ng9RYOQj1YMsSyLwbbhcKU6Y3zvD5JEeAwtvRtf1S+GGUbXEDkH5mWqOOwHSkXrXwt4Y2SE0HoTsiYk2roInfE6UqyO/aRokwiYg0nFSztqNWtYe9DjU3Vcty1n8QO 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=52157122.xn--9vv.k1308; olt=johnl@user.iecc.com; bh=XxamIuVvAFiaeHGCrdUbaSwrR1KeLt+BEY8+SgV/FE0=; b=pD3j083K4XmrCzj/VhZVb42U1PEFzZ8bAxBuD3rfn6jrAn42styUy9oDN6YLhXvbOHQ11MVymscKlR2wmWn+AIbrwY0tcqZ+HEdYc+ASWRjRxqBaPMTVuP2t9miKlKjpFiHss8q6vXBGrLI7lDh4zztfzZW8D8/IZUtYam5mCd1fVSUFvRjwGz28ufWylf78ElQeDwf7J5GaODZzM8FQLoqn5/QJXv0hyMH1djULfSUYTGAmxWxkkkCY0IxxO8w4 Date: 22 Aug 2013 02:01:47 -0000 Message-ID: <20130822020147.91910.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <5215658B.3060502@stpeter.im> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] DNS work 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, 22 Aug 2013 02:02:16 -0000 >I'm more interested in the latter work than the former, but I suggest >that the proponents of both might try to generate some discussion, >feedback, and perhaps even implementation before we take the relevant >I-Ds on as WG items. I'm currently rewriting my Web Crudware(tm) DNS front end and will do the dns extension language stuff. I believe that Tony Finch implemnented a version of it last year. R's, John From yaojk@cnnic.cn Thu Aug 22 00:30: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 D91CE21F9E1D for ; Thu, 22 Aug 2013 00:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.024 X-Spam-Level: X-Spam-Status: No, score=-99.024 tagged_above=-999 required=5 tests=[AWL=1.821, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 YpcHAwGC4GmJ for ; Thu, 22 Aug 2013 00:30:44 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id E7F1221F9E13 for ; Thu, 22 Aug 2013 00:30:42 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO healthyao-think) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 22 Aug 2013 15:30:25 +0800 Date: Thu, 22 Aug 2013 15:30:25 +0800 From: "Jiankang Yao" To: "Murray S. Kucherawy" , =?iso-8859-1?B?PGFwcHMtZGlzY3Vzc0BpZXRmLm9yZz4=?= References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <2013082215302176584418@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart668501436701_=----" Subject: Re: [apps-discuss] DNS work X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: yaojk List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 07:30:50 -0000 This is a multi-part message in MIME format. ------=_001_NextPart668501436701_=---- Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQpGcm9tOiBNdXJyYXkgUy4gS3VjaGVyYXd5DQpEYXRlOiAyMDEzLTA4LTIyIDA3OjU5DQpUbzog SUVURiBBcHBzIERpc2N1c3MNClN1YmplY3Q6IFthcHBzLWRpc2N1c3NdIEROUyB3b3JrDQoNCg0K U28gdHdvIHF1ZXN0aW9ucyBvbiBlYWNoIG9mIHRoZXNlOg0KDQoNCjEpIElzIHRoZXJlIHN1cHBv cnQgZm9yIGRvaW5nIHRoaXMga2luZCBvZiB3b3JrIGluIHRoZSBBUFBTIGFyZWE/ICBJbiBwYXJ0 aWN1bGFyLCBpcyBhbnlvbmUgcHJlcGFyZWQgdG8gY29tbWl0IHRvIHJldmlld3MgYW5kIGNvbW1l bnRzIG9uIHRoaXMgc29ydCBvZiB3b3JrIGlmIGl0IHdlcmUgdG8gYXBwZWFyIGZvcm1hbGx5IGlu IHNvbWUgd2F5Pw0KW0ppYW5rYW5nIFlhb10gIEkgcGVyc29uYWxseSBzdXBwb3J0IHRoaXMga2lu ZCBvZiB3b3JrIGluIEFQUFMgYXJlYS4gDQoNCg0KMikgQWdhaW4gaW4gZWFjaCBjYXNlLCBpZiB0 aGUgYW5zd2VyIHRvIHRoZSBhYm92ZSBpcyB5ZXMsIGlzIHRoZSB3b3JrIGFwcHJvcHJpYXRlIGZv ciBBUFBTQVdHLCBvciBzaG91bGQgdGhlIHByb3BvbmVudHMgbG9vayBhdCBnZXR0aW5nIEJvRnMg dG9nZXRoZXIgKHBlcmhhcHMgaW4gdGltZSBmb3IgVmFuY291dmVyKSB0byBmb3JtIHNlcGFyYXRl IHdvcmtpbmcgZ3JvdXBzIHRvIGFkdmFuY2UgaXQ/DQoNCltKaWFua2FuZyBZYW9dIElmIGl0IGlz IGluIHRoZSBBUFBTQVdHLCBpdCBtYXkgY2F1c2UgbWFueSBkaXNjdXNzaW9uIGFib3V0IEROUyBp biB0aGlzIGxpc3QuIEl0IHNlZW1zIHRoYXQgQk9GcyBhcmUgYmV0dGVyLiA= ------=_001_NextPart668501436701_=---- Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Date: 2013-08-22 07:59
Subject: [apps-discuss] DNS work

 
So two questions on each of these:

1) Is= there=20 support for doing this kind of work in the APPS area?  In particular,= is=20 anyone prepared to commit to reviews and comments on this sort of work if = it=20 were to appear formally in some way?
= [Jiankang=20 Yao]  I personally support this kind of work in APPS=20 area. 

2) Again in each case, if the answe= r to=20 the above is yes, is the work appropriate for APPSAWG, or should the propo= nents=20 look at getting BoFs together (perhaps in time for Vancouver) to form sepa= rate=20 working groups to advance it?

= [Jiankang=20 Yao] If it is in the APPSAWG, it may cause many discuss= ion=20 about DNS in this list. It seems that BOFs are=20 better. 

------=_001_NextPart668501436701_=------ From superuser@gmail.com Thu Aug 22 01:15: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 1682211E818A for ; Thu, 22 Aug 2013 01:15:06 -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, 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 X9wdS5AKHQAt for ; Thu, 22 Aug 2013 01:15:05 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7D5DE11E8168 for ; Thu, 22 Aug 2013 01:14:42 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x54so1343940wes.32 for ; Thu, 22 Aug 2013 01:14:41 -0700 (PDT) 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=FkbeBALKQ9hqYHPDE85LiU7tW7fEbMh7/CZ2qyi1HKA=; b=Cdzhdzjd7JqjHjMKjmsC8PAsKpJF+2BraUIhtQMl1yV1ue8EsgFJTo501ugd5VLhH8 oaCs6cl10awlcLef3oUIoD3OT1ja+sDxGfer+/LwZ+t9rNW9MN37wD7B9rp3VKsc4RtY hXg3DmNzizZ0NuBZjwWIo2BBrMXGTuIJddH6tJCPVpiAZTcJFHUpEpjbwdrPcm3091WA 6oAdgfG6TL9ZynsNHaIopmmdw8oAMR2nQ5RocPrIZuOcrODFqi2faURlK1I01T228W1S Lte92hbKpSVSr+pvEYslGo/8dIaG6ol/rnsEZdJprkhA+GFMbw4a1GuA61bChBDyyc1C iSOg== MIME-Version: 1.0 X-Received: by 10.180.189.132 with SMTP id gi4mr19956509wic.19.1377159281665; Thu, 22 Aug 2013 01:14:41 -0700 (PDT) Received: by 10.180.125.36 with HTTP; Thu, 22 Aug 2013 01:14:41 -0700 (PDT) In-Reply-To: <2013082215302176584418@cnnic.cn> References: <2013082215302176584418@cnnic.cn> Date: Thu, 22 Aug 2013 01:14:41 -0700 Message-ID: From: "Murray S. Kucherawy" To: yaojk Content-Type: multipart/alternative; boundary=001a11c35294c86e8004e484e18d Cc: "" Subject: Re: [apps-discuss] DNS work 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, 22 Aug 2013 08:15:06 -0000 --001a11c35294c86e8004e484e18d Content-Type: text/plain; charset=ISO-8859-1 We don't need to constrain APPSAWG work to this list. As we did with webfinger (and should've done sooner), specific work items can get their own lists if traffic warrants. That is, however, sometimes a hint that the work does warrant its own working group. -MSK On Thu, Aug 22, 2013 at 12:30 AM, Jiankang Yao wrote: > ** > > *From:* Murray S. Kucherawy > *Date:* 2013-08-22 07:59 > *To:* IETF Apps Discuss > *Subject:* [apps-discuss] DNS work > > > So two questions on each of these: > > 1) Is there support for doing this kind of work in the APPS area? In > particular, is anyone prepared to commit to reviews and comments on this > sort of work if it were to appear formally in some way? > *[Jiankang Yao]* I personally support this kind of work in APPS area. > > 2) Again in each case, if the answer to the above is yes, is the work > appropriate for APPSAWG, or should the proponents look at getting BoFs > together (perhaps in time for Vancouver) to form separate working groups to > advance it? > > *[Jiankang Yao]* If it is in the APPSAWG, it may cause many discussion > about DNS in this list. It seems that BOFs are better. > > --001a11c35294c86e8004e484e18d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We don't need to constrain APPSAWG work to this l= ist.=A0 As we did with webfinger (and should've done sooner), specific = work items can get their own lists if traffic warrants.=A0 That is, however= , sometimes a hint that the work does warrant its own working group.

-MSK


On Thu, Aug 22, 2013 at 12:30 AM, Jiankang Yao <yaojk@cnni= c.cn> wrote:
=A0
Date:=A02013-08-22=A007:59
Subject:=A0[apps-discuss] DNS work

=A0
So two questions on each of these:

1) Is the= re=20 support for doing this kind of work in the APPS area?=A0 In particular, is= =20 anyone prepared to commit to reviews and comments on this sort of work if i= t=20 were to appear formally in some way?
[Jiankang=20 Yao]=A0 I personally support this kind of work in APPS=20 area.=A0

2) Again in each case= , if the answer to=20 the above is yes, is the work appropriate for APPSAWG, or should the propon= ents=20 look at getting BoFs together (perhaps in time for Vancouver) to form separ= ate=20 working groups to advance it?

[Jiankang=20 Yao]=A0If it is in the=A0APPSAWG, it may cause=A0many discussion=20 about DNS in this list.=A0It seems that BOFs are=20 better.=A0


--001a11c35294c86e8004e484e18d-- From alexey.melnikov@isode.com Thu Aug 22 03:14: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 43FDE11E814C for ; Thu, 22 Aug 2013 03:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.043 X-Spam-Level: X-Spam-Status: No, score=-103.043 tagged_above=-999 required=5 tests=[AWL=-0.444, 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 G90hT+obxkN4 for ; Thu, 22 Aug 2013 03:14:15 -0700 (PDT) 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 486A521F9FFF for ; Thu, 22 Aug 2013 03:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1377166453; d=isode.com; s=selector; i=@isode.com; bh=jsVJyU8RmX0tx+hkcwS+YGcaLarOBAC2XMD8Kx2Fapw=; 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=uer/FblszF5QY9LebD3+dTnr3YE1ydQFCB5WCGr8k04W/y2OTBpwHSPAojJ9QG+534wH6N gZ+2O36o5NRJMhLX66UTlAkyIhVjnXM8Z1pI7KE1uKNzPXRUMvLIJgQydxJtgEh3BqVTck jikKadJ9cT3pBInjp6EKNCGdAYCk3QA=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 22 Aug 2013 11:14:13 +0100 Message-ID: <5215E48F.3030401@isode.com> Date: Thu, 22 Aug 2013 11:14:39 +0100 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: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] DNS work 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, 22 Aug 2013 10:14:16 -0000 On 22/08/2013 00:59, Murray S. Kucherawy wrote: > In giving the audio from IETF 87 a re-listen, it seems as if the two > DNS items we had at the end of the agenda had a non-trivial amount of > interest. I wonder if we could engage the group about adopting some > of that here, or at least someplace in APPS. > > The first is draft-levine-dnsextlang, which proposes a method to > describe the syntax of new DNS RRTYPEs so that various kinds of DNS > software can auto-provision. There was explicit support from a few > people for the notion of doing this work, with some discussion about > whether this would be in the DNS itself or elsewhere. This looks like a useful piece of work. I have no opinion about the best place to do it. > > The second was the two proposals by Andrew Sullivan and John Levine > for ways to add a mechanism to the DNS for identifying administrative > boundaries in the DNS. It also got some discussion because there are > some extant (and in some cases long-lived) needs for this in the > applications space. > > So two questions on each of these: > > 1) Is there support for doing this kind of work in the APPS area? In > particular, is anyone prepared to commit to reviews and comments on > this sort of work if it were to appear formally in some way? Yes, this is needed. > 2) Again in each case, if the answer to the above is yes, is the work > appropriate for APPSAWG, or should the proponents look at getting BoFs > together (perhaps in time for Vancouver) to form separate working > groups to advance it? This is an interesting question. I don't have a gut feeling for how long it would take proponents to converge on 1 proposal (or decide that 2 are really needed, as they serve different puprose). A BoF sounds like a good idea. Possibly a non WG forming one. From stephen.farrell@cs.tcd.ie Thu Aug 22 03:18: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 D4BF421F9F34 for ; Thu, 22 Aug 2013 03:18:48 -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=[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 s5LWDS3ktEAs for ; Thu, 22 Aug 2013 03:18:43 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id DDAE821F9DF0 for ; Thu, 22 Aug 2013 03:18:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4F89EBE77; Thu, 22 Aug 2013 11:18:42 +0100 (IST) 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 ke9WtYgNiCjc; Thu, 22 Aug 2013 11:18:37 +0100 (IST) Received: from [10.87.48.4] (unknown [86.46.19.36]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7E159BE7C; Thu, 22 Aug 2013 11:18:35 +0100 (IST) Message-ID: <5215E573.4060907@cs.tcd.ie> Date: Thu, 22 Aug 2013 11:18:27 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] DNS work 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, 22 Aug 2013 10:18:48 -0000 On 08/22/2013 12:59 AM, Murray S. Kucherawy wrote: > The second was the two proposals by Andrew Sullivan and John Levine for > ways to add a mechanism to the DNS for identifying administrative > boundaries in the DNS. It also got some discussion because there are some > extant (and in some cases long-lived) needs for this in the applications > space. I take it that these proposals aim to fix the problems of the public-suffix list. That list is used in various places so it'd be important that the different interests are involved and might buy into using DNS instead. A BoF to try figure out if a solution might get traction would seem to be called for before discussing the venue for work. S. From stpeter@stpeter.im Thu Aug 22 07:16: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 EE5DF11E81BA for ; Thu, 22 Aug 2013 07:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.357 X-Spam-Level: X-Spam-Status: No, score=-102.357 tagged_above=-999 required=5 tests=[AWL=0.242, 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 G-P2MW1oE6yT for ; Thu, 22 Aug 2013 07:16:33 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F19E211E81C5 for ; Thu, 22 Aug 2013 07:16:29 -0700 (PDT) Received: from sjc-vpn3-612.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BDFA441510; Thu, 22 Aug 2013 08:19:51 -0600 (MDT) Message-ID: <52161D38.2000302@stpeter.im> Date: Thu, 22 Aug 2013 08:16:24 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Stephen Farrell References: <5215E573.4060907@cs.tcd.ie> In-Reply-To: <5215E573.4060907@cs.tcd.ie> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] DNS work 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, 22 Aug 2013 14:16:42 -0000 On 8/22/13 4:18 AM, Stephen Farrell wrote: > > > On 08/22/2013 12:59 AM, Murray S. Kucherawy wrote: >> The second was the two proposals by Andrew Sullivan and John Levine for >> ways to add a mechanism to the DNS for identifying administrative >> boundaries in the DNS. It also got some discussion because there are some >> extant (and in some cases long-lived) needs for this in the applications >> space. > > I take it that these proposals aim to fix the problems of the > public-suffix list. That's how I see it. > That list is used in various places so it'd > be important that the different interests are involved and might > buy into using DNS instead. Agreed. > A BoF to try figure out if a solution might get traction would seem > to be called for before discussing the venue for work. Sounds reasonable. Peter -- Peter Saint-Andre https://stpeter.im/ From Claudio.Allocchio@garr.it Thu Aug 22 09:24: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 F216211E8200; Thu, 22 Aug 2013 09:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 PkdQD-b26TdJ; Thu, 22 Aug 2013 09:24:09 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id E8F4B11E81CD; Thu, 22 Aug 2013 09:24:07 -0700 (PDT) Received: internal info suppressed Date: Thu, 22 Aug 2013 18:24:05 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@synx02.dir.garr.it To: apps-discuss@ietf.org In-Reply-To: <520BA199.8070200@dcrocker.net> Message-ID: References: <520A62E8.8050401@dcrocker.net> <520B47D9.5020308@isode.com> <520BA199.8070200@dcrocker.net> 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=1377188646; bh=9H7Ul2s1hRXToaiJeDU9zLnoX2lptiHme9n/O4bR3JQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=iWD08RqaAm90PFUjrz+/wxccImIvGZcYZcuO3o2ZsN0A5iv5hAOSKg7LyMhcMlggJ 7C/zbHvO3RCWux4+nt1waBQzpUBk3zZEnb9A1I5Cc9jX0toVqytqiz9tnz2+FYrgDA s1L1uLmvplCEKo512RLB2Y6UXv9no+/wH5Rc9JUw= Cc: appsdir@ietf.org Subject: [apps-discuss] Updated links to the list of reviews page 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, 22 Aug 2013 16:24:13 -0000 On Wed, 14 Aug 2013, Dave Crocker wrote: > On 8/14/2013 6:28 AM, Claudio Allocchio wrote: >> I'll add a link to the wiki pages I can edit as soon as I'm back next >> week and I have a better connectivity... I did add a set of more evident links to our AppsDir wiki pages thus they should show more the http://trac.tools.ietf.org/area/app/trac/wiki/tracker page. Now it's up to ADs and IESG to decide how to make this also more generally visible! ------------------------------------------------------------------------------ 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 dhc@dcrocker.net Thu Aug 22 09:32: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 C96ED11E81F2; Thu, 22 Aug 2013 09:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 T8e2rxILPO+q; Thu, 22 Aug 2013 09:32:06 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8097C11E81F3; Thu, 22 Aug 2013 09:32:06 -0700 (PDT) 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 r7MGVm1I015406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Aug 2013 09:31:52 -0700 Message-ID: <52163CDA.9070602@dcrocker.net> Date: Thu, 22 Aug 2013 09:31:22 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Claudio Allocchio References: <520A62E8.8050401@dcrocker.net> <520B47D9.5020308@isode.com> <520BA199.8070200@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 22 Aug 2013 09:31:52 -0700 (PDT) Cc: appsdir@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [appsdir] Updated links to the list of reviews page X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 16:32:10 -0000 On 8/22/2013 9:24 AM, Claudio Allocchio wrote: > > > On Wed, 14 Aug 2013, Dave Crocker wrote: > >> On 8/14/2013 6:28 AM, Claudio Allocchio wrote: >>> I'll add a link to the wiki pages I can edit as soon as I'm back next >>> week and I have a better connectivity... > > I did add a set of more evident links to our AppsDir wiki pages thus > they should show more the > http://trac.tools.ietf.org/area/app/trac/wiki/tracker page. > > Now it's up to ADs and IESG to decide how to make this also more > generally visible! ack. tnx. and while we have this thread going, I'll wonder out loud about an additional thought: The sequence of reviews various people do for a doc should be linked to the document history in the datatracker. (A link, not a copy, in the tracker.) This would require some sort of addressing convention for the review -- and possibly more conventions than that -- probably for one of the .* addresses. I think it should all be kept quite simple and open. For example, anyone wanting to offer a "review" should be allowed to; don't restrict the sources of reviews. If someone abuses that, then remove the link by hand. My guess is that that won't be a significant problem. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Thu Aug 22 10:39: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 738E611E81BA for ; Thu, 22 Aug 2013 10:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.683 X-Spam-Level: X-Spam-Status: No, score=-102.683 tagged_above=-999 required=5 tests=[AWL=-0.084, 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 F73Z85fvje8N for ; Thu, 22 Aug 2013 10:39:22 -0700 (PDT) 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 1A65E21F9BB5 for ; Thu, 22 Aug 2013 10:39:21 -0700 (PDT) Received: (qmail 9034 invoked from network); 22 Aug 2013 17:39:21 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Aug 2013 17:39:21 -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=52164cc9.xn--30v786c.k1308; i=johnl@user.iecc.com; bh=wNyXph4MDkbxSGinWDpv+VRPFtAfkGKDLthP4Ods32k=; b=AtLGzdDsvSmIbmA6Q1RBAfu9IHJPm3kBRdjO2ka/JFeuwCTy+mWacJToi6XpLdc2D/HpoYrdR/q2FH+qvXbpZMnkfjK1aSTRa1NlzU3wTerfyHiqtoZkwdbPlMJ8emhmCxc12Q+pJyrAA2EEZ/a5cut7RSJfg5eyQu6vKtRmTRZXBF8B8hLC2iYWT5/4GbQaKbk9LJIR/sXwYFPOjFlWFXowxuwymR0Lfwd5gVipCBbrCqmXF5GXNvneWeem1bkM 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=52164cc9.xn--30v786c.k1308; olt=johnl@user.iecc.com; bh=wNyXph4MDkbxSGinWDpv+VRPFtAfkGKDLthP4Ods32k=; b=LIGijg3yZVpx07SGxq5YeSaz6aeH/hcrk65fc2gT0zfLYyYvOBF+SN3aJGwsxzLxWqbI5drPkGoLPkk7yaCRcstplhcBk9+x2Be7uRc1TogZoATnTQD1f5IwXhcDTv4LQ+xzOWR1VjwRLYsS8/xKc3p9ISANbKwSzxPi89/exkHospondqMeYGbXVnAzqcxbuslg8ZXHwoXm7me4Lt7vpWRrYbJYxuQ92dh9Fd45TpFbz/sAs3/XedOpsPIXJgxn Date: 22 Aug 2013 17:38:58 -0000 Message-ID: <20130822173858.5573.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <5215E573.4060907@cs.tcd.ie> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] DNS work 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, 22 Aug 2013 17:39:26 -0000 >> The second was the two proposals by Andrew Sullivan and John Levine for >> ways to add a mechanism to the DNS for identifying administrative >> boundaries in the DNS. It also got some discussion because there are some >> extant (and in some cases long-lived) needs for this in the applications >> space. > >I take it that these proposals aim to fix the problems of the >public-suffix list. That list is used in various places so it'd >be important that the different interests are involved and might >buy into using DNS instead. That was my intention. It's slightly more urgent than it has been in the past because draft-kucherawy-dmarc-base seems likely to become a standards track RFC, and it uses public suffix. >A BoF to try figure out if a solution might get traction would seem >to be called for before discussing the venue for work. Seems reasonable, although it's a sufficently well known problem that I'd think we could get a reasonable sense of the situation in e-mail. Andrew's proposal and mine are technically quite different, we later realized because we're solving different technical problems that happen both to use public suffix as the current kludge. R's, John From stpeter@stpeter.im Thu Aug 22 11:46: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 2FD3F21F9FE7 for ; Thu, 22 Aug 2013 11:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=0.198, 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 lW7n7z2uQ1cm for ; Thu, 22 Aug 2013 11:46:21 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5A54F21F9F08 for ; Thu, 22 Aug 2013 11:46:12 -0700 (PDT) Received: from sjc-vpn2-649.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 67306414D6; Thu, 22 Aug 2013 12:49:36 -0600 (MDT) Message-ID: <52165C71.9050101@stpeter.im> Date: Thu, 22 Aug 2013 12:46:09 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: John Levine References: <20130822173858.5573.qmail@joyce.lan> In-Reply-To: <20130822173858.5573.qmail@joyce.lan> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] DNS work 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, 22 Aug 2013 18:46:26 -0000 On 8/22/13 11:38 AM, John Levine wrote: >>> The second was the two proposals by Andrew Sullivan and John Levine for >>> ways to add a mechanism to the DNS for identifying administrative >>> boundaries in the DNS. It also got some discussion because there are some >>> extant (and in some cases long-lived) needs for this in the applications >>> space. >> >> I take it that these proposals aim to fix the problems of the >> public-suffix list. That list is used in various places so it'd >> be important that the different interests are involved and might >> buy into using DNS instead. > > That was my intention. It's slightly more urgent than it has been in > the past because draft-kucherawy-dmarc-base seems likely to become a > standards track RFC, and it uses public suffix. > >> A BoF to try figure out if a solution might get traction would seem >> to be called for before discussing the venue for work. > > Seems reasonable, although it's a sufficently well known problem that > I'd think we could get a reasonable sense of the situation in e-mail. > > Andrew's proposal and mine are technically quite different, we later > realized because we're solving different technical problems that > happen both to use public suffix as the current kludge. That's good to know. It would be helpful to capture that understanding in your respective I-Ds. Peter -- Peter Saint-Andre https://stpeter.im/ From vkg@bell-labs.com Thu Aug 22 14:03: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 33C6F21F9D75; Thu, 22 Aug 2013 14:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.372 X-Spam-Level: X-Spam-Status: No, score=-110.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, 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 31lBu6eiCM69; Thu, 22 Aug 2013 14:03:43 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9A08121F9D82; Thu, 22 Aug 2013 14:03:36 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r7ML3Xaj001461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 22 Aug 2013 16:03:33 -0500 (CDT) 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 r7ML3XnR007594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Aug 2013 16:03:33 -0500 Received: from shoonya.ih.lucent.com (vkg.lra.lucent.com [135.244.36.56]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r7ML3WoS028399; Thu, 22 Aug 2013 16:03:32 -0500 (CDT) Message-ID: <52167DBF.8040305@bell-labs.com> Date: Thu, 22 Aug 2013 16:08:15 -0500 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: Eric McMurry References: <52123A42.6030405@bell-labs.com> <1E23FFA4-7990-437A-B334-F2E65E61E406@computer.org> In-Reply-To: <1E23FFA4-7990-437A-B334-F2E65E61E406@computer.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: draft-ietf-dime-overload-reqs.all@tools.ietf.org, IESG IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-dime-overload-reqs-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, 22 Aug 2013 21:03:48 -0000 On 08/22/2013 03:45 PM, Eric McMurry wrote: >> Nits: >> ===== >> - S3.2, first paragraph: "This document is a work in progress...", >> here, "This" refers to TR23.843 or does it refer to dime-overload- >> reqs-10? Please clarify. On further reading, there are more >> "this document" spread in the subsection with providing an adequate >> text that qualifies the "this". > > we can clear this this up. that should not be a problem :-) > > more specifically, for the first paragraph of 3.2, how about > changing "this document" to "this technical report". Eric: Better yet, why not simply change it to TR23.843? > We searched through the rest of the draft and all of the other > instances of "this document" refer to the draft itself. Is that more > clear when the instance in the first paragraph is addressed? Yes, that should be fine. Thanks for your attention to my comments. - 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 Claudio.Allocchio@garr.it Fri Aug 23 06: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 6736311E80FF; Fri, 23 Aug 2013 06:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.647 X-Spam-Level: X-Spam-Status: No, score=-0.647 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 vZKr7J6Zo2RW; Fri, 23 Aug 2013 06:40:16 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 20B6C21F9E62; Fri, 23 Aug 2013 06:40:15 -0700 (PDT) Received: internal info suppressed Date: Fri, 23 Aug 2013 15:40:04 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@synx02.dir.garr.it To: dcrocker@bbiw.net In-Reply-To: <52163CDA.9070602@dcrocker.net> Message-ID: References: <520A62E8.8050401@dcrocker.net> <520B47D9.5020308@isode.com> <520BA199.8070200@dcrocker.net> <52163CDA.9070602@dcrocker.net> 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=1377265205; bh=KMj6Lgzjm2rnIJIIUFtaThO2mkZCKAA1MqUBhZgLQh8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=RSstzT0fDTR22gsQ3eaP4JHpUkzBpwbdxWoABwvyFRAHAyO6xoC8yaXk+F0UkoUJn fgy98HmS1PeHbHDtWWqYlg/n9+dAb+OGp1FNnJsvKlzjhJQatFZfU5fzVvCPyzYVzP UMHwLj3BZotbW3lEd8PPCEXL/rcllpTwwuo1rW/I= Cc: appsdir@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [appsdir] Updated links to the list of reviews page 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, 23 Aug 2013 13:40:20 -0000 > and while we have this thread going, I'll wonder out loud about an additional > thought: > > The sequence of reviews various people do for a doc should be linked to > the document history in the datatracker. (A link, not a copy, in the > tracker.) that's a good idea (and we should include all reviews, wherever they come from). > This would require some sort of addressing convention for the review -- > and possibly more conventions than that -- probably for one of the name>.* addresses. this is the tricky part... reviews usually are e-mail messages, with not always consistent Subject line (as this is inserted by the sender), and errors in this sort of tagging are always possible. Making the Datatracker be able to pick up automatically from ML archives (like apps-discuss) seems somehow a non simple problem to solve. Maybe enabling some other function (a revier does send the e-mail review message ALSO to a special robot address which then makes the link from the ML to Datatracker automatically); something similar to what we have for e.g. To: bla bla bla... cc: > I think it should all be kept quite simple and open. For example, anyone > wanting to offer a "review" should be allowed to; don't restrict the sources > of reviews. If someone abuses that, then remove the link by hand. My guess > is that that won't be a significant problem. > I Agree. > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > ------------------------------------------------------------------------------ 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 dhc@dcrocker.net Fri Aug 23 06:46: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 B796211E819E; Fri, 23 Aug 2013 06:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 cwZ2Zj74qFHp; Fri, 23 Aug 2013 06:45:52 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B259311E817A; Fri, 23 Aug 2013 06:45:43 -0700 (PDT) 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 r7NDjTjF004564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Aug 2013 06:45:33 -0700 Message-ID: <5217675E.8040102@dcrocker.net> Date: Fri, 23 Aug 2013 06:45:02 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Claudio Allocchio References: <520A62E8.8050401@dcrocker.net> <520B47D9.5020308@isode.com> <520BA199.8070200@dcrocker.net> <52163CDA.9070602@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 23 Aug 2013 06:45:33 -0700 (PDT) Cc: appsdir@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [appsdir] Updated links to the list of reviews page X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Aug 2013 13:46:08 -0000 On 8/23/2013 6:40 AM, Claudio Allocchio wrote: >> This would require some sort of addressing convention for the review >> -- and possibly more conventions than that -- probably for one of the >> .* addresses. > > this is the tricky part... reviews usually are e-mail messages, with not > always consistent Subject line (as this is inserted by the sender), and > errors in this sort of tagging are always possible. Making the Fair point. And as you describe it, I'd have to agree that some percentage of folk are certain to screw it up, given its free-form nature. > Datatracker be able to pick up automatically from ML archives (like > apps-discuss) seems somehow a non simple problem to solve. Maybe > enabling some other function (a revier does send the e-mail review > message ALSO to a special robot address which then makes the link from > the ML to Datatracker automatically); something similar to what we have for > > > > e.g. > > To: bla bla bla... > cc: yeah, that seems reasonable. if a reviewer doesn't remember to include this address, it's not a big deal for the doc shepherd (or whoever) to forward to that address. so this approach seems like it has both simplicity and robustness to it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From emcmurry@computer.org Thu Aug 22 13:46:02 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 8AE3E11E815A; Thu, 22 Aug 2013 13:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 yd3Ie23WDsBc; Thu, 22 Aug 2013 13:45:57 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2062B21F9EB8; Thu, 22 Aug 2013 13:45:57 -0700 (PDT) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1VCblU-000Ag0-LS; Thu, 22 Aug 2013 20:45:56 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 724EE134D746; Thu, 22 Aug 2013 15:45:54 -0500 (CDT) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19pi9l53j8Y+rDYujpfvMGtUg9k1RhSQuo= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBQycrTCxxrf; Thu, 22 Aug 2013 15:45:54 -0500 (CDT) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 657F5134D73D; Thu, 22 Aug 2013 15:45:54 -0500 (CDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric McMurry In-Reply-To: <52123A42.6030405@bell-labs.com> Date: Thu, 22 Aug 2013 15:45:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1E23FFA4-7990-437A-B334-F2E65E61E406@computer.org> References: <52123A42.6030405@bell-labs.com> To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Fri, 23 Aug 2013 14:13:39 -0700 Cc: draft-ietf-dime-overload-reqs.all@tools.ietf.org, IESG IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-dime-overload-reqs-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, 22 Aug 2013 20:46:02 -0000 Thanks Vijay! Comments inline. Eric On Aug 19, 2013, at 10:31 , Vijay K. Gurbani wrote: > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see =E2=80=8B > = 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. >=20 > Document: draft-ietf-dime-overload-reqs-10 > Title: Diameter Overload Control Requirements > Reviewer: Vijay K. Gurbani > Review Date: Aug-19-2013 > IETF Last Call Date: Not known > IESG Telechat Date: Not known >=20 > Summary: This draft is ready for publication as an Informational > RFC; two minor issues follow. >=20 > Major comments: 0 > Minor comments: 1 > Nits: 1 >=20 > Minor: > =3D=3D=3D=3D=3D=3D > - Abstract - You may consider taking out the Section numbers in the > Abstract. They really do not belong there, and you can impart the same > information without using the section numbers (e.g., "Existing > Diameter mechanisms are not sufficient for this purpose. This > document describes the limitations of the existing mechanisms and > proposes requirements for new overload management mechanisms.") >=20 agree, those can be removed. > Nits: > =3D=3D=3D=3D=3D > - S3.2, first paragraph: "This document is a work in progress...", > here, "This" refers to TR23.843 or does it refer to dime-overload- > reqs-10? Please clarify. On further reading, there are more > "this document" spread in the subsection with providing an adequate > text that qualifies the "this". we can clear this this up. that should not be a problem :-) more specifically, for the first paragraph of 3.2, how about changing = "this document" to "this technical report". We searched through the rest of the draft and all of the other instances = of "this document" refer to the draft itself. Is that more clear when = the instance in the first paragraph is addressed? >=20 > Thanks, >=20 > - vijay > --=20 > 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 emcmurry@computer.org Thu Aug 22 14:09: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 DF97F11E8210; Thu, 22 Aug 2013 14:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 jVk0eg4NdUyN; Thu, 22 Aug 2013 14:09:21 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id CFB3711E8131; Thu, 22 Aug 2013 14:09:20 -0700 (PDT) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1VCc88-000NwD-Da; Thu, 22 Aug 2013 21:09:20 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 327C6134E507; Thu, 22 Aug 2013 16:09:17 -0500 (CDT) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18/831dMHr4xZaaHGdueqePxYQoXgd8Snw= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvqz79C3z77s; Thu, 22 Aug 2013 16:09:17 -0500 (CDT) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 0ECF1134E4FC; Thu, 22 Aug 2013 16:09:17 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric McMurry In-Reply-To: <52167DBF.8040305@bell-labs.com> Date: Thu, 22 Aug 2013 16:09:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <68E69EA4-1624-40E6-B23B-281645124FCC@computer.org> References: <52123A42.6030405@bell-labs.com> <1E23FFA4-7990-437A-B334-F2E65E61E406@computer.org> <52167DBF.8040305@bell-labs.com> To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Fri, 23 Aug 2013 14:13:39 -0700 Cc: draft-ietf-dime-overload-reqs.all@tools.ietf.org, IESG IESG , apps-discuss@ietf.org, Ben Allen Campbell Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-dime-overload-reqs-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, 22 Aug 2013 21:09:26 -0000 works for me. We'll change that and dereference the abstract in the = next version, pending instructions from the shepherd. Thanks! Eric On Aug 22, 2013, at 16:08 , "Vijay K. Gurbani" = wrote: > On 08/22/2013 03:45 PM, Eric McMurry wrote: >>> Nits: >>> =3D=3D=3D=3D=3D >>> - S3.2, first paragraph: "This document is a work in progress...", >>> here, "This" refers to TR23.843 or does it refer to dime-overload- >>> reqs-10? Please clarify. On further reading, there are more >>> "this document" spread in the subsection with providing an adequate >>> text that qualifies the "this". >>=20 >> we can clear this this up. that should not be a problem :-) >>=20 >> more specifically, for the first paragraph of 3.2, how about >> changing "this document" to "this technical report". >=20 > Eric: Better yet, why not simply change it to TR23.843? >=20 >> We searched through the rest of the draft and all of the other >> instances of "this document" refer to the draft itself. Is that more >> clear when the instance in the first paragraph is addressed? >=20 > Yes, that should be fine. >=20 > Thanks for your attention to my comments. >=20 > - vijay > --=20 > 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 lear@cisco.com Sun Aug 25 08: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 080F821F9D35 for ; Sun, 25 Aug 2013 08:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.555 X-Spam-Level: X-Spam-Status: No, score=-110.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 tMDSaVUwTJ1U for ; Sun, 25 Aug 2013 08:14:02 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 79DAA21F9D31 for ; Sun, 25 Aug 2013 08:14:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22053; q=dns/txt; s=iport; t=1377443641; x=1378653241; h=message-id:date:from:mime-version:to:cc:subject; bh=63RzhhBwE9BwEbEMjbEPUdN19on/Fz96G+8oyNYlE4M=; b=UUKKqEZYyXFTphbbhgWSRqE0Cbtq0i/Q//pOddy2rdwQc6F98bioZO2/ 2vDkF469ojOR87fzCZ7cNZO78UNz7ue+9HwhJuhRrzRmAjauzldrIH+1Z MCfScgfhTC/x9CQURKZeCe/9V1p7ofpaGeeBb6JjF051ZvxtzSqbEvuXG k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAI4eGlKQ/khN/2dsb2JhbABZgwc1g3iFXbcRgRoWdIIkAQEBAyRVAQUqDRYLAgsDAgECASstAQcBARABBodgBgykSpFtjy8QgSgREIJfgTEDl26BLZA0gyA6gTU X-IronPort-AV: E=Sophos;i="4.89,951,1367971200"; d="scan'208,217";a="17482101" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 25 Aug 2013 15:13:56 +0000 Received: from mctiny.local ([10.61.174.183]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7PFDrwA018248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Aug 2013 15:13:53 GMT Message-ID: <521A1F31.8080402@cisco.com> Date: Sun, 25 Aug 2013 17:13:53 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: draft-ietf-spfbis-4408bis.all@tools.ietf.org X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------050408030003090400090000" Cc: spfbis@ietf.org, Apps Discuss , 'IESG' Subject: [apps-discuss] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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: Sun, 25 Aug 2013 15:14:07 -0000 This is a multi-part message in MIME format. --------------050408030003090400090000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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-spfbis-4408bis-19 Title: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 Reviewer: Eliot Lear Review Date: 25 Aug 2013 IETF Last Call Date: 19 Aug 2013 IESG Telechat Date: 12 Sep 2013 Summary: This draft is not yet ready for publication as a Proposed Standard and should be revised before publication. Major issues: 1. Deprecation of SPF record not properly justified in text and in the wrong place Deprecation of the SPF record is given short shrift in Section 13.1 which is the IANA considerations section. A persistent reader would not understand why the record was in fact deprecated. Here's what is 13.1 (there are a few words about 6686 in 3.1 as well, but nobody would care if this was simply a matter of low implementation/deployment). > Studies have shown that RRTYPE 99 has not seen any substantial use, > and in fact its existence and mechanism defined in [RFC4408] has led > to some interoperability issues. First, this text should be moved out of the IANA considerations sections and forward to Section 3.1. Second it should explain what those interoperability issues are or have a normative (and retrievable) reference. At the very least, the winning argument(s) should be elucidated, and not just for posterity: the claim is that there is an interoperability problem. If so, then might administrators want to know that? The matter of handling garbage in garbage out is not well enough specified in Section 3. I would go considerably further and state that (a) records that do not begin with "v=spf1" MUST NOT be processed further, and (b) that any record that does not conform to the stated grammar MUST be ignored. Also, did the working group consider a DKIM-like solution? They all but establish an _spf label in this document (I'll come to that in a moment). There is a general issue about when to deprecate an RR and the ability to add new RRs into the DNS. That issue has to be addressed in the longer term, no matter what the IESG and community decide here. Furthermore, to be clear, please do not read into the above comments an opinion about deprecation of the record itself, which I am withholding until there is clear text about the interoperability issues that are mentioned. 2. So-called "Utility Labels" Throughout the document _spf.example.com is used, as is the term "common utility labels". Maybe bind doesn't cough up blood on underscores, but this is also not what we would call a sanctioned practice by our RFCs. If this is truly first use (and I could be wrong), then the utility of utility labels need to be made clear. As this is, IMHO, *not* the focus of this standard, my suggestion would be to change the example. 3. Retain a summary of changes since 4408. A -bis document usually has a change list that can assist implementers familiar with previous work. Appendix J is pretty close to what I would want, but it needs some editing. Minor Issues: There are areas where the document seems to go to lengths to avoid the use of normative language. If either the WG or the IESG cares, I can go through a few that could stand to be MAYs, but here is but one example: > A mail receiver can perform a set of SPF checks for each mail message > it receives. As I say below, this text actually adds nothing to the document, but if the author decides to leave it in, this is a prime example of where MAY was intended to be useful. Similarly, there is the occasional "ought to", such as that found in Section 3. If the WG considered normative text and rejected it, fine. But if they didn't, they should. This is a complex specification, and our normative language definitions are there to provide clarity and consistency. Throughout the document is used as the macro expansion of . I don't recommend that. While much of SPF seems an exercise in indirection, the actual RFC should not be. Better to simply say " or its macro-expansion." And no, I wouldn't care about this in most documents, but the sheer number of forward and backward references in this document has me (and will have other readers) constantly flipping backward and forward. Section 2.2, 1st para > Typically, such checks are done > by a receiving MTA, but can be performed elsewhere in the mail > processing chain so long as the required information is available and > reliable People may infer a traipse through Received headers for HELO information. Is that the intent, and is that acceptable, given that they could be forged? My point: the above is vague. Section 2.5: title > 2.5. Location of Checks I don't think you mean location. I think you mean "When to perform checks". Section 4.7, 2nd para, 2nd sentence. > Although the latter > has a default (specifically "?all"), it aids debugging efforts if it > is explicitly provided. How does it aid in debugging? Section 5.6, ABNF: You've gone to some lengths to get ipv4 correct, but you don't do the same with CIDR prefixes. > ip4-cidr-length = "/" 1*DIGIT > ip6-cidr-length = "/" 1*DIGIT Strictly speaking the value range is from 1 to 32, for v4, and 1 to 128 for v6. This isn't quite all legal, but at least it's bounded: ip4-cidr-length = "/" 1*2DIGIT ; value must be > 0 and may not exceed 32 ip6-cidr-length = "/" 1*3DIGIT ; value must be > 0 may not exceed 128 You could do the same as you did with qnum, but perhaps that is overkill. Section 6.2, last para: The following text is confusing: > Note: During recursion into an "include" mechanism, an "exp" modifier > from the MUST NOT be used. In contrast, when executing > a "redirect" modifier, an "exp" modifier from the original domain > MUST NOT be used. When "MUST NOT be used" do you mean MUST NOT be evaluated or processed or MUST NOT be present in the record? e.g., does this MUST apply to operators, implementers, or both? Appendix A: > This section is normative and any discrepancies with the ABNF > fragments in the preceding text are to be resolved in favor of this > grammar. Normally we don't normatively reference Appendices, and it represents a bit of a cultural cognitive dissidence for some. One possible fix: don't make it an Appendix, but the last section. But also, Section 7.1 is entitled "Formal Specification". Don't have two of those. Appendix E: There's probably a case not covered here, but it's close. E.1 describes originating ADMD behavior. Think of the case of a university or professional organization that offers forwarding. The advice given in the first bullet of E.1 is probably applicable, but requires that a new whitelist entry be created for new aliases that contain new hosts on the RHS. I would go just that bit further to explain. Nits: Please stop creating acronyms. Spam = unsolicited bulk email. UBE is obfuscation in this case. Similarly, I'd ask the authors to trying speaking out loud "domain owning ADMDs,", expanding out the acronym. How about just saying "domain owners"? In general your definitions section is unnecessarily verbose and could go for a good "haircut". For example, how about these: Imported Definitions: * MAIL FROM: The RFC5321.MailFrom, as defined in [RFC5321] * HELO: The parameter specified in the HELO or EHLO commands as specified in [RFC5321]. Page 7, Section 1.2: This forward reference is unnecessary, and I would remove the section. 2.1 2nd para, 2nd sentence: > If ADMDs > choose to publish SPF records and want to support receivers making > negative authorization determinations, it is necessary for them to > publish records that end in "-all", or redirect to other records that > do, otherwise, no definitive determination of authorization can be > made. That's grammatically incorrect. Remove everything after "do," and you are fine. Same section further down, please clarify "While offline checks are possible". I think you mean "deferred" or "checks made after delivery" or some such. Section 2.2 first para, first sentence: > A mail receiver can perform a set of SPF checks for each mail message > it receives. What value does this sentence offer the reader? Personally I say none, and would remove. Section 5.4: "mx" > Then it performs an address lookup on each MX name returned. To be precise: "It then performs an address lookup on of the name found in the RDATA of each answer." Section 8.5, 2nd sentence: > The ADMD believes the host is not authorized but is not willing to > make a strong policy statement Which ADMD? Eliot --------------050408030003090400090000 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

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-spfbis-4408bis-19
Title: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
Reviewer: Eliot Lear
Review Date: 25 Aug 2013
IETF Last Call Date: 19 Aug 2013
IESG Telechat Date: 12 Sep 2013

Summary: This draft is not yet ready for publication as a Proposed Standard and should be revised before publication.

Major issues:

1. Deprecation of SPF record not properly justified in text and in the wrong place

Deprecation of the SPF record is given short shrift in Section 13.1 which is the IANA considerations section.  A persistent reader would not understand why the record was in fact deprecated.  Here's what is 13.1 (there are a few words about 6686 in 3.1 as well, but nobody would care if this was simply a matter of low implementation/deployment).

   Studies have shown that RRTYPE 99 has not seen any substantial use,
   and in fact its existence and mechanism defined in [RFC4408] has led
   to some interoperability issues.

First, this text should be moved out of the IANA considerations sections and forward to Section 3.1.  Second it should explain what those interoperability issues are or have a normative (and retrievable) reference.  At the very least, the winning argument(s) should be elucidated, and not just for posterity: the claim is that there is an interoperability problem.  If so, then might administrators want to know that?

The matter of handling garbage in garbage out is not well enough specified in Section 3.  I would go considerably further and state that (a) records that do not begin with "v=spf1" MUST NOT be processed further, and (b) that any record that does not conform to the stated grammar MUST be ignored.  Also, did the working group consider a DKIM-like solution?  They all but establish an _spf label in this document (I'll come to that in a moment).

There is a general issue about when to deprecate an RR and the ability to add new RRs into the DNS.  That issue has to be addressed in the longer term, no matter what the IESG and community decide here.  Furthermore, to be clear, please do not read into the above comments an opinion about deprecation of the record itself, which I am withholding until there is clear text about the interoperability issues that are mentioned.

2.  So-called "Utility Labels"

Throughout the document _spf.example.com is used, as is the term "common utility labels".  Maybe bind doesn't cough up blood on underscores, but this is also not what we would call a sanctioned practice by our RFCs.  If this is truly first use (and I could be wrong), then the utility of utility labels need to be made clear.  As this is, IMHO, not the focus of this standard, my suggestion would be to change the example.

3.  Retain a summary of changes since 4408.

A -bis document usually has a change list that can assist implementers familiar with previous work.  Appendix J is pretty close to what I would want, but it needs some editing.

Minor Issues:

There are areas where the document seems to go to lengths to avoid the use of normative language.   If either the WG or the IESG cares, I can go through a few that could stand to be MAYs, but here is but one example:

   A mail receiver can perform a set of SPF checks for each mail message
   it receives. 
As I say below, this text actually adds nothing to the document, but if the author decides to leave it in, this is a prime example of where MAY was intended to be useful.

Similarly, there is the occasional "ought to", such as that found in Section 3.  If the WG considered normative text and rejected it, fine.  But if they didn't, they should.  This is a complex specification, and our normative language definitions are there to provide clarity and consistency.

Throughout the document <target-name> is used as the macro expansion of <domain-spec>.  I don't recommend that.  While much of SPF seems an exercise in indirection, the actual RFC should not be.  Better to simply say "<domain-spec> or its macro-expansion."  And no, I wouldn't care about this in most documents, but the sheer number of forward and backward references in this document has me (and will have other readers) constantly flipping backward and forward.

Section 2.2, 1st para

   Typically, such checks are done
   by a receiving MTA, but can be performed elsewhere in the mail
   processing chain so long as the required information is available and
   reliable
People may infer a traipse through Received headers for HELO information.  Is that the intent, and is that acceptable, given that they could be forged?  My point: the above is vague.

Section 2.5: title

2.5.  Location of Checks
I don't think you mean location.  I think you mean "When to perform checks".

Section 4.7, 2nd para, 2nd sentence.

   Although the latter
   has a default (specifically "?all"), it aids debugging efforts if it
   is explicitly provided.

How does it aid in debugging?

Section 5.6, ABNF:

You've gone to some lengths to get ipv4 correct, but you don't do the same with CIDR prefixes.

   ip4-cidr-length  = "/" 1*DIGIT
   ip6-cidr-length  = "/" 1*DIGIT
Strictly speaking the value range is from 1 to 32, for v4, and 1 to 128 for v6.  This isn't quite all legal, but at least it's bounded:

    ip4-cidr-length = "/" 1*2DIGIT ; value must be > 0 and may not exceed 32
    ip6-cidr-length = "/" 1*3DIGIT ; value must be > 0 may not exceed 128

You could do the same as you did with qnum, but perhaps that is overkill.

Section 6.2, last para:

The following text is confusing:

   Note: During recursion into an "include" mechanism, an "exp" modifier
   from the <target-name> MUST NOT be used.  In contrast, when executing
   a "redirect" modifier, an "exp" modifier from the original domain
   MUST NOT be used.

When "MUST NOT be used" do you mean MUST NOT be evaluated or processed or MUST NOT be present in the record?  e.g., does this MUST apply to operators, implementers, or both?

Appendix A:

   This section is normative and any discrepancies with the ABNF
   fragments in the preceding text are to be resolved in favor of this
   grammar.
Normally we don't normatively reference Appendices, and it represents a bit of a cultural cognitive dissidence for some.  One possible fix: don't make it an Appendix, but the last section.  But also, Section 7.1 is entitled "Formal Specification".  Don't have two of those.

Appendix E:

There's probably a case not covered here, but it's close.  E.1 describes originating ADMD behavior.  Think of the case of a university or professional organization that offers forwarding.  The advice given in the first bullet of E.1 is probably applicable, but requires that a new whitelist entry be created for new aliases that contain new hosts on the RHS.  I would go just that bit further to explain.

Nits:

Please stop creating acronyms.  Spam = unsolicited bulk email.  UBE is obfuscation in this case.  Similarly, I'd ask the authors to trying speaking out loud "domain owning ADMDs,", expanding out the acronym.  How about just saying "domain owners"?

In general your definitions section is unnecessarily verbose and could go for a good "haircut".  For example, how about these:

Imported Definitions:

  • MAIL FROM: The RFC5321.MailFrom, as defined in [RFC5321]
  • HELO: The parameter specified in the HELO or EHLO commands as specified in [RFC5321].

Page 7, Section 1.2:

This forward reference is unnecessary, and I would remove the section.


2.1 2nd para, 2nd sentence:

If ADMDs
   choose to publish SPF records and want to support receivers making
   negative authorization determinations, it is necessary for them to
   publish records that end in "-all", or redirect to other records that
   do, otherwise, no definitive determination of authorization can be
   made. 

That's grammatically incorrect.  Remove everything after "do," and you are fine.



Same section further down, please clarify "While offline checks are possible".  I think you mean "deferred" or "checks made after delivery" or some such.

Section 2.2 first para, first sentence:

   A mail receiver can perform a set of SPF checks for each mail message
   it receives. 

What value does this sentence offer the reader?  Personally I say none, and would remove.

Section 5.4: "mx"

Then it performs an address lookup on each MX name returned.

To be precise:

"It then performs an address lookup on of the name found in the RDATA of each answer."

Section 8.5, 2nd sentence:

The ADMD believes the host is not authorized but is not willing to make a strong policy statement

Which ADMD?

Eliot

--------------050408030003090400090000-- From ajs@anvilwalrusden.com Sun Aug 25 09:23: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 1E0FE21F9D1C; Sun, 25 Aug 2013 09:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.831 X-Spam-Level: X-Spam-Status: No, score=-0.831 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 lCfT2y3u+Zh8; Sun, 25 Aug 2013 09:23:34 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 50C0521F8E40; Sun, 25 Aug 2013 09:23:34 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 93CEF8A031; Sun, 25 Aug 2013 16:23:33 +0000 (UTC) Date: Sun, 25 Aug 2013 12:23:32 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org, spfbis@ietf.org, iesg@ietf.org Message-ID: <20130825162331.GC8259@mx1.yitter.info> References: <521A1F31.8080402@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <521A1F31.8080402@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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: Sun, 25 Aug 2013 16:23:40 -0000 No hat. On Sun, Aug 25, 2013 at 05:13:53PM +0200, Eliot Lear wrote: > 2. So-called "Utility Labels" > > Throughout the document _spf.example.com is used, as is the term "common > utility labels". Maybe bind doesn't cough up blood on underscores, but > this is also not what we would call a sanctioned practice by our RFCs. > If this is truly first use (and I could be wrong), then the utility of > utility labels need to be made clear. As this is, IMHO, *not* the focus > of this standard, my suggestion would be to change the example. I don't think I understand this critique, but I think your claim is that underscores are somehow not scanctioned by RFC. I think you are mistaken about this. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From lear@cisco.com Sun Aug 25 12:51: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 4939B21F9E43; Sun, 25 Aug 2013 12:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.558 X-Spam-Level: X-Spam-Status: No, score=-110.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 TOrjBJJBUVEO; Sun, 25 Aug 2013 12:51:24 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 6371421F9E3F; Sun, 25 Aug 2013 12:51:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=875; q=dns/txt; s=iport; t=1377460283; x=1378669883; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=mp7Rd1OVFZRKVs6JiCJ2QBTorsqNHF0GsNOQQIqMKtQ=; b=Df/ecVjyNYjV6wwDZAvcwhBx7u3ar9uFKBPZ2KHiN07aZ6CQJd1TIahX tzrf6ZwuKD0j4yc1sQAWl0+kPp+5mzj/vS02evotiwq/87hcXMzxLzTrd pwmjhc3TGVyYMtDopQlkEu9KNXgJVHLs+Ghh8QD8v90GDMtUrR4A2xrxq A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIFAENfGlKQ/khN/2dsb2JhbABZgwc1gzFHvHCBGhZ0giQBAQEEI1UBEAsOCgICBRYLAgIJAwIBAgErGgYNAQcBAYd9pG2Rc4Epj08HgmiBMQOXboEtkDSBY4E9Og X-IronPort-AV: E=Sophos;i="4.89,952,1367971200"; d="scan'208";a="17484622" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 25 Aug 2013 19:51:22 +0000 Received: from mctiny.local ([10.61.174.183]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7PJpJjk009932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Aug 2013 19:51:20 GMT Message-ID: <521A6037.8030208@cisco.com> Date: Sun, 25 Aug 2013 21:51:19 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andrew Sullivan References: <521A1F31.8080402@cisco.com> <20130825162331.GC8259@mx1.yitter.info> In-Reply-To: <20130825162331.GC8259@mx1.yitter.info> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: spfbis@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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: Sun, 25 Aug 2013 19:51:29 -0000 You're correct. For some reason I thought they were reserved. Eliot On 8/25/13 6:23 PM, Andrew Sullivan wrote: > No hat. > > On Sun, Aug 25, 2013 at 05:13:53PM +0200, Eliot Lear wrote: > >> 2. So-called "Utility Labels" >> >> Throughout the document _spf.example.com is used, as is the term "common >> utility labels". Maybe bind doesn't cough up blood on underscores, but >> this is also not what we would call a sanctioned practice by our RFCs. >> If this is truly first use (and I could be wrong), then the utility of >> utility labels need to be made clear. As this is, IMHO, *not* the focus >> of this standard, my suggestion would be to change the example. > I don't think I understand this critique, but I think your claim is > that underscores are somehow not scanctioned by RFC. I think you are > mistaken about this. > > Best, > > A From dhc@dcrocker.net Sun Aug 25 13:24: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 8D5AB21F9EA2 for ; Sun, 25 Aug 2013 13:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 7y4vLPpQNKdc for ; Sun, 25 Aug 2013 13:24:48 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A430B21F9E3C for ; Sun, 25 Aug 2013 13:24:48 -0700 (PDT) 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 r7PKOgeG030417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Aug 2013 13:24:45 -0700 Message-ID: <521A67E9.7040104@dcrocker.net> Date: Sun, 25 Aug 2013 13:24:09 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Eliot Lear References: <521A1F31.8080402@cisco.com> In-Reply-To: <521A1F31.8080402@cisco.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]); Sun, 25 Aug 2013 13:24:48 -0700 (PDT) Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, 'IESG' , Apps Discuss Subject: Re: [apps-discuss] [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 25 Aug 2013 20:24:53 -0000 These are meant as targeted responses, rather than to the review in general: On 8/25/2013 8:13 AM, Eliot Lear wrote: > 1. Deprecation of SPF record not properly justified in text and in the > wrong place > > Deprecation of the SPF record is given short shrift in Section 13.1 > which is the IANA considerations section. A persistent reader would not > understand why the record was in fact deprecated. This is confusing. These are specifications, not historical explanations. IETF specifications /permit/ far more commentary than do most standards groups' documents. However the degree of expectation -- nevermind requirement -- for extended rationale about choices that is being called for here does not match my sense of what is typical for IETF specifications. Can you provide some pointers to recent exemplars that match what you are calling for? > 2. So-called "Utility Labels" > > Throughout the document _spf.example.com is used, as is the term "common > utility labels". Perhaps my search function is off, but I'm only finding one occurrence of "common utility labels". > Maybe bind doesn't cough up blood on underscores, but > this is also not what we would call a sanctioned practice by our RFCs. Use of underscores is not sanctioned? Huh? It's been a standardized practice for more than 10 years. See SRV. If you mean something else, what is it? > There are areas where the document seems to go to lengths to avoid the > use of normative language. If either the WG or the IESG cares, I can > go through a few that could stand to be MAYs, but here is but one example: > >> A mail receiver can perform a set of SPF checks for each mail message >> it receives. > As I say below, this text actually adds nothing to the document, but if > the author decides to leave it in, this is a prime example of where MAY > was intended to be useful. Probably not. It has nothing to do with interoperability. It is, in fact, purely advisory text about possible use. As such, it's actually rather important that it /not/ use normative language. (The text does need to be clear about the line between normative and advisory text, of course.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Sun Aug 25 13:58: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 A3EDE21F918C for ; Sun, 25 Aug 2013 13:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.617 X-Spam-Level: X-Spam-Status: No, score=-102.617 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 y2YNITUbNuH5 for ; Sun, 25 Aug 2013 13:58:38 -0700 (PDT) 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 ED3DE21F8BFD for ; Sun, 25 Aug 2013 13:58:37 -0700 (PDT) Received: (qmail 20074 invoked from network); 25 Aug 2013 20:58:28 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Aug 2013 20:58:28 -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=521a6ff4.xn--btvx9d.k1308; i=johnl@user.iecc.com; bh=LFmsA5RPsE2baa1wrJbOQk7v/p6SrMZpmGbN/T7P6WI=; b=X5KtKqsGXd4Q31I8jzf1pX0eQt8bo8D/Nfa9vSj01PPSPeR5Niw3C/QL4H2Fqx2Ukt2kXMVsWMZyTRoqiLvWW83h7R+aN0OE+bzPbfFS3/1JSZr9TS90e/I1y9XwRZDqFAfG8ZGEY5EcYbOGi/lrywIcNX9RT33hXC455OIKaR1ryA74foHo2kvmYGnOVreTMlSv0Bm6OXrOuBtyxwTvPJSvSFq0foNNnHMUkSVXWahdI9BuVmBIoWBh7to62oHQ 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=521a6ff4.xn--btvx9d.k1308; olt=johnl@user.iecc.com; bh=LFmsA5RPsE2baa1wrJbOQk7v/p6SrMZpmGbN/T7P6WI=; b=fSg5w7/geax2MszYtpAF8yi2PhQekRyYq/UW4nNaXmJ9JdQlz+o6bOqzWFjTEW+QLHBIBPS8r6M4h8wMB9/v6IrywG3F9LcbqCdgMGFf/O1rJmSgjWT6zY/liPN9VYGf5ebBxXhaNJG3ubpRmiTGJJzxKi/pNV3nKeByHLxwoWY7wGbSsWhynOZ9lxxZQjWB6zGnEhY+IPlA7krH9X0+8rQfcQOHYGEJ6p6TLN2JYJtPAeWRUrZH1G2C4pmUm+8d Date: 25 Aug 2013 20:58:06 -0000 Message-ID: <20130825205806.69278.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <521A6037.8030208@cisco.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] underscores, was Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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: Sun, 25 Aug 2013 20:58:42 -0000 In article <521A6037.8030208@cisco.com> you write: >You're correct. For some reason I thought they were reserved. There have been occasional efforts to set up a registry of prefixed names to avoid collisions, but for now it's a free for all. Fortunately, the space of prefixed names is large enough that collisions haven't happened yet. The most recent effort I can find is draft-crocker-dns-attrleaf-06 R's, John From presnick@qti.qualcomm.com Sun Aug 25 14:44: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 B246D11E80E8 for ; Sun, 25 Aug 2013 14:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.477 X-Spam-Level: X-Spam-Status: No, score=-106.477 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 hMPxl7J07k9g for ; Sun, 25 Aug 2013 14:44:55 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 833FA11E80E6 for ; Sun, 25 Aug 2013 14:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1377467095; x=1409003095; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=SqCo+wPvVrsAHzLCXGTyGSuPncruUSUapmooTDTnQN8=; b=oXrO0SvAJ6AVE4qzW9b3f70jM0agD7iNGimIwAlEfYbw81HxLdZk+n9Y yEVgAkH38JpOc4rJkA6A6kThOm9SJehnoXfikW3vpN7mT1H3/oT/C+yvA DC8wT/6Cag+XHAuhgG065UAir4HKPmRuA1ZFp/U++83dLBhn+3kOY1oEh 8=; X-IronPort-AV: E=McAfee;i="5400,1158,7178"; a="70574103" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 25 Aug 2013 14:44:55 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7178"; a="501418358" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 25 Aug 2013 14:44:54 -0700 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.146.2; Sun, 25 Aug 2013 14:44:54 -0700 Message-ID: <521A7AD3.9000704@qti.qualcomm.com> Date: Sun, 25 Aug 2013 16:44:51 -0500 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: Eliot Lear References: <521A1F31.8080402@cisco.com> In-Reply-To: <521A1F31.8080402@cisco.com> Content-Type: multipart/alternative; boundary="------------090401070903030101000308" X-Originating-IP: [172.30.39.5] Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, 'IESG' , Apps Discuss Subject: Re: [apps-discuss] [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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: Sun, 25 Aug 2013 21:44:59 -0000 --------------090401070903030101000308 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 8/25/13 10:13 AM, Eliot Lear wrote: > > Major issues: > > 1. Deprecation of SPF record not properly justified in text and in the > wrong place > > 2. So-called "Utility Labels" > Eliot, I would like to hear some followups to the folks who have posted so far before more folks pile on. I'm hearing for the two above major issues: On 1: Others have said that the document already points to 6686 where quite a bit of justification is made, and in any event the present document isn't the correct place for such justifications. Also, folks have said that the document already says that syntactically incorrect records will fail processing (with a "permerror" -- see section 4.6). On 2: Folks have said that you are incorrect about underscore in labels being a problem as they are already widely used (e.g. SRV). Were your comments misunderstood? I'm not sure why major issue 3 is "major", but I think the WG can consider it (if it has not already) like some of the other things you've mentioned. But like I said, before more people respond on the first two, I'd like to understand what you mean. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------090401070903030101000308 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 8/25/13 10:13 AM, Eliot Lear wrote:

Major issues:

1. Deprecation of SPF record not properly justified in text and in the wrong place

2.  So-called "Utility Labels"


Eliot, I would like to hear some followups to the folks who have posted so far before more folks pile on. I'm hearing for the two above major issues:

On 1: Others have said that the document already points to 6686 where quite a bit of justification is made, and in any event the present document isn't the correct place for such justifications. Also, folks have said that the document already says that syntactically incorrect records will fail processing (with a "permerror" -- see section 4.6).

On 2: Folks have said that you are incorrect about underscore in labels being a problem as they are already widely used (e.g. SRV).

Were your comments misunderstood?

I'm not sure why major issue 3 is "major", but I think the WG can consider it (if it has not already) like some of the other things you've mentioned.

But like I said, before more people respond on the first two, I'd like to understand what you mean.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------090401070903030101000308-- From sm@elandsys.com Sun Aug 25 16:51: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 14FD611E810E for ; Sun, 25 Aug 2013 16:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 CZhrbjoWUSBV for ; Sun, 25 Aug 2013 16:51:41 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E58A11E810C for ; Sun, 25 Aug 2013 16:51:41 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.47]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7PNpPln004066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Aug 2013 16:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377474699; bh=N8crGbG1m2IdozqVRsEq1S5pjUx3oxx0P9CYmk1gWsk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ZhOJElNCzDbodJ2JDKHxWw9ARSp+XzS08iPmaJ2KnVApvZGHG7QQkUBo+XLwLiS3B cj4Nw5cQCWvKSM7r/hJoC0I7Xqyj/zyCAcvvUq5khAt3V3tiRGhYW+N4x8a+J3c8el CcTh6EcC+O7uJacHwOTB5vMjbd9bpYWwhHnYgE5Y= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377474699; i=@elandsys.com; bh=N8crGbG1m2IdozqVRsEq1S5pjUx3oxx0P9CYmk1gWsk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2X17E1HK1Kv62iJrhOxUaWk2vxlqh2B3/cs2OszMje7KZMSxvnOSjx2X5zuya0aSJ YBkVAk9on8L4v/Ru76LQ7YMlGkzFesG6PXA8flXF0W0AttcEHo2u5THrr4TzFciRe7 mQYZZLTF6i3XwOofdI853gAAHCYzIbtUKQ/zEcUs= Message-Id: <6.2.5.6.2.20130825155516.0ae42960@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 25 Aug 2013 16:49:50 -0700 To: Eliot Lear , draft-ietf-spfbis-4408bis.all@tools.ietf.org From: S Moonesamy In-Reply-To: <521A1F31.8080402@cisco.com> References: <521A1F31.8080402@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, Apps Discuss , IESG Subject: Re: [apps-discuss] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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: Sun, 25 Aug 2013 23:51:42 -0000 Hi Eliot, At 08:13 25-08-2013, Eliot Lear wrote: >Summary: This draft is not yet ready for publication as a Proposed >Standard and should be revised before publication. I'll respond to part of the comments. The SPFBIS WG has a tightly-scoped charter. Suggested changes to RFC 2119 keywords, for example, were carefully considered. One of the problems was the way RFC 4408 was written. draft-ietf-spfbis-4408bis is not a complete rewrite of RFC 4408. The clarifications were kept as narrow as possible. >Major issues: [snip] >the stated grammar MUST be ignored. Also, did the working group >consider a DKIM-like solution? They all but establish an _spf label >in this document (I'll come to that in a moment). There is a thread at http://www.ietf.org/mail-archive/web/spfbis/current/msg03964.html about the "_spf" prefix. I went over some of the messages posted during the WG charter discussion to see whether the WG could have considered a DKIM-like solution. In my opinion it would be out-of-scope. >2. So-called "Utility Labels" > >Throughout the document _spf.example.com is used, as is the term >"common utility labels". Maybe bind doesn't cough up blood on >underscores, but this is also not what we would call a sanctioned >practice by our RFCs. If this is truly first use (and I could be >wrong), then the utility of utility labels need to be made >clear. As this is, IMHO, not the focus of this standard, my >suggestion would be to change the example. There is a thread at http://www.ietf.org/mail-archive/web/spfbis/current/msg03996.html in response to your review. The "Utility labels" is a note in the draft. _spf.example.com was used in RFC 4408 for some examples and the text is similar in the draft. My reading of the message at http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10272.html is that the examples do not have to be changed (re. not sanctioned by RFC). >3. Retain a summary of changes since 4408. > >A -bis document usually has a change list that can assist >implementers familiar with previous work. Appendix J is pretty >close to what I would want, but it needs some editing. Did you mean merging some of Appendix J into Appendix C? >Minor Issues: > >There are areas where the document seems to go to lengths to avoid >the use of normative language. If either the WG or the IESG cares, >I can go through a few that could stand to be MAYs, but here is but >one example: >> A mail receiver can perform a set of SPF checks for each mail message >> it receives. >As I say below, this text actually adds nothing to the document, but >if the author decides to leave it in, this is a prime example of >where MAY was intended to be useful. Please refer to my opening comment. >Similarly, there is the occasional "ought to", such as that found in >Section 3. If the WG considered normative text and rejected it, >fine. But if they didn't, they should. This is a complex >specification, and our normative language definitions are there to >provide clarity and consistency. The SPFBIS WG considered whether having the normative text was within scope. I agree with your argument about clarity and consistency. The document shepherd review is at http://www.ietf.org/mail-archive/web/spfbis/current/msg03414.html I did a pass of the RFC 2119 keywords and compared them against what is in RFC 4408. Adding normative language can entail a significant rewrite of the draft. It can create incompatible changes. As you mentioned this is a complex specification and significant changes would require a level of review beyond what has been done up to now to achieve better clarity and consistency. This draft has been a significant effort. I'll leave it to the IESG to assess whether asking the SPFBIS WG to go beyond that is doable. Thanks for the careful review. Regards, S. Moonesamy From johnl@iecc.com Sun Aug 25 20:21: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 EBC6D11E813A for ; Sun, 25 Aug 2013 20:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.616 X-Spam-Level: X-Spam-Status: No, score=-102.616 tagged_above=-999 required=5 tests=[AWL=-0.017, 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 6aj3UBpfCE6d for ; Sun, 25 Aug 2013 20:20:58 -0700 (PDT) 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 6E25F11E8138 for ; Sun, 25 Aug 2013 20:20:58 -0700 (PDT) Received: (qmail 2189 invoked from network); 26 Aug 2013 03:20:56 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Aug 2013 03:20:56 -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=521ac998.xn--btvx9d.k1308; i=johnl@user.iecc.com; bh=Uvr2ic1t0Qv6jznftNJ5AqUA9f0FkAn7XrE1lYW/Tog=; b=ZmGvXaPKQJq0sTVFNEaUtOJWdfS5w0faU3Rb5YInHGzvGJN9VQTw4f1AaElqo6R4+qfywI04U1ZENXAEHBlvqbQhOhR1igd8Q7Cmq3wBoIj1XRqtRuVYZAiSjftcUp12kFxa/XKoqrFs+0FfkVkxI85hdWSGD6V1/dCcF5e9CtWB1ZJeVztew7Y1cQPsIgou4eLfgjrWsKhKB/CqfRw1C2BcOF5qo1NQ5Nc4rpdot8Lu1fE4W57GyviMdlobMTqH 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=521ac998.xn--btvx9d.k1308; olt=johnl@user.iecc.com; bh=Uvr2ic1t0Qv6jznftNJ5AqUA9f0FkAn7XrE1lYW/Tog=; b=tIOZsbOh8WOCzSXM+DC8Me776wD4DaomY33WAnn/yg4fgCB26Yvppha1gwkF/kSQZtp5Cj8Xy47nHpffs8o696ieVcP0mcg3kBhINA3fGY6SI7sc5/P0+Dmb5ncD2Z+SGha74si+HgkWGTOyQ+iGvBELbq7dQQBFfZEdjdSOx0SxsANo2AvTcwTPsHq55zwg5i7hTAfms9o/U/8J+tjRy1yhnWiV9+wT+u06wlRrZkiwWd4dscARC8CUPf+9JIrP Date: 26 Aug 2013 03:20:34 -0000 Message-ID: <20130826032034.70615.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <01OXHJ9EDE6800004R@mauve.mrochek.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: ned.freed@mrochek.com Subject: Re: [apps-discuss] another rev of dnsextlang and some stuff to play with 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, 26 Aug 2013 03:21:03 -0000 >> The first is draft-levine-dnsextlang, which proposes a method to describe >> the syntax of new DNS RRTYPEs so that various kinds of DNS software can >> auto-provision. There was explicit support from a few people for the >> notion of doing this work, with some discussion about whether this would be >> in the DNS itself or elsewhere. I just submitted draft-levine-dnsextlang-07 which cleans up the ABNF and adds a version tag to the DNS records. I also set up rrtype.info with definitions of all of the existing RRTYPEs that I think I can describe with the existing language. Visit http://www.rrtype.info for a link to some resources or try, e.g. $ dig mx.rrtype.info txt ;; QUESTION SECTION: ;mx.rrtype.info. IN TXT ;; ANSWER SECTION: mx.rrtype.info. 7162 IN TXT "RRTYPE=1" "MX:15 Mail exchanger" "I2 Priority (lower values are higher priority)" "N[A,C] Host name" R's, John From lear@cisco.com Sun Aug 25 22:44: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 E6E7E21F9DDE for ; Sun, 25 Aug 2013 22:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.559 X-Spam-Level: X-Spam-Status: No, score=-110.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 GCzMrrQiHEgA for ; Sun, 25 Aug 2013 22:44:25 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 355FA21F9D18 for ; Sun, 25 Aug 2013 22:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7385; q=dns/txt; s=iport; t=1377495865; x=1378705465; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=VMw+96AhMLqJwfn/ISGNjahcabTSrq0g3NAZXHAUe3I=; b=UlMyzh5LOBpH/vB9nU4803DAQNCt5zq3nWZqekbYQyA8P31IBOKhtnCe 33vHEGArxG6eANmg+tTUhbupSjwXFAZPv+PF0MNOEv2k3ss8Pqi0BUUJ1 YK1prlSjVP/2JSdEuYk7PyESP/jYZ4fgaL/u5JArOVn50COiQU6CddviH c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FALfqGlKQ/khL/2dsb2JhbABagweELYVdtw6BIBZ0giQBAQEDASNVARAJAg4KCRYLAgIJAwIBAgErGgYNAQcBAYd3Bolsm0qRfZB4B4JogTEDl26RYYMgOg X-IronPort-AV: E=Sophos;i="4.89,956,1367971200"; d="scan'208,217";a="158892784" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 26 Aug 2013 05:44:22 +0000 Received: from mctiny.local ([10.61.174.183]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7Q5iKYR020884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Aug 2013 05:44:20 GMT Message-ID: <521AEB34.2030909@cisco.com> Date: Mon, 26 Aug 2013 07:44:20 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Pete Resnick References: <521A1F31.8080402@cisco.com> <521A7AD3.9000704@qti.qualcomm.com> In-Reply-To: <521A7AD3.9000704@qti.qualcomm.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------030507010107060701070506" Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, 'IESG' , Apps Discuss Subject: Re: [apps-discuss] [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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, 26 Aug 2013 05:44:31 -0000 This is a multi-part message in MIME format. --------------030507010107060701070506 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 8/25/13 11:44 PM, Pete Resnick wrote: > > Eliot, I would like to hear some followups to the folks who have > posted so far before more folks pile on. I'm hearing for the two above > major issues: > > On 1: Others have said that the document already points to 6686 where > quite a bit of justification is made, and in any event the present > document isn't the correct place for such justifications. Also, folks > have said that the document already says that syntactically incorrect > records will fail processing (with a "permerror" -- see section 4.6). The reference is to Appendix A. Unfortunately, the text there doesn't go far enough. All it says is: > 4. [SPF] itself included a faulty transition plan, likely because of > the late addition of a requirement to develop one -- it said: > > An SPF-compliant domain name SHOULD have SPF records of both RR > types. A compliant domain name MUST have a record of at least > one type. > > which means both can claim to be fully compliant while failing > utterly to interoperate. This reads as if somehow a record is a protocol. What I would suggest (at the very least) is the following: "Because ADMDs have in the past published either SPF or TXT records, and because some MTAs query for only one or the other, it is possible that an MTA will not find a published record. When both records are published it is possible for them to differ." I *think* these are the interoperability issues (I can't say because 6686 isn't clear). Because we know people are querying SPF records (there is ample empirical evidence), the text could even go further and say something like this: "While we are deprecating the SPF record, any ADMD that continues to publish an SPF record at this point MUST also publish the semantically equivalent TXT record." I don't know of instances in the wild where this was a problem, and if it wasn't then this isn't really an interoperability issue worth considering. That goes to a more substantial debate about whether the record should be deprecated. Again, I'm not taking a position about that here. There is matching text for MTAs: "MTAs MUST NOT query for RRTYPE 99 records." The text ALMOST says that in Section 4.4 and again in 13.2, but for some reason stops short. This goes to my other issue, that normative language is not appropriately used. > > On 2: Folks have said that you are incorrect about underscore in > labels being a problem as they are already widely used (e.g. SRV). I withdraw that issue. See exchange between Andrew, John and me. > > Were your comments misunderstood? > > I'm not sure why major issue 3 is "major", but I think the WG can > consider it (if it has not already) like some of the other things > you've mentioned. It's in Appendix C. I was looking at Appendix J. Withdrawn. Eliot --------------030507010107060701070506 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 8/25/13 11:44 PM, Pete Resnick wrote:

Eliot, I would like to hear some followups to the folks who have posted so far before more folks pile on. I'm hearing for the two above major issues:

On 1: Others have said that the document already points to 6686 where quite a bit of justification is made, and in any event the present document isn't the correct place for such justifications. Also, folks have said that the document already says that syntactically incorrect records will fail processing (with a "permerror" -- see section 4.6).

The reference is to Appendix A.  Unfortunately, the text there doesn't go far enough.  All it says is:
   4.  [SPF] itself included a faulty transition plan, likely because of
       the late addition of a requirement to develop one -- it said:

         An SPF-compliant domain name SHOULD have SPF records of both RR
         types.  A compliant domain name MUST have a record of at least
         one type.

       which means both can claim to be fully compliant while failing
       utterly to interoperate.

This reads as if somehow a record is a protocol.  What I would suggest (at the very least) is the following:

"Because ADMDs have in the past published either SPF or TXT records, and because some MTAs query for only one or the other, it is possible that an MTA will not find a published record.  When both records are published it is possible for them to differ."

I *think* these are the interoperability issues (I can't say because 6686 isn't clear).

Because we know people are querying SPF records (there is ample empirical evidence), the text could even go further and say something like this:

"While we are deprecating the SPF record, any ADMD that continues to publish an SPF record at this point MUST also publish the semantically equivalent TXT record."  I don't know of instances in the wild where this was a problem, and if it wasn't then this isn't really an interoperability issue worth considering.  That goes to a more substantial debate about whether the record should be deprecated.  Again, I'm not taking a position about that here.

There is matching text for MTAs: "MTAs MUST NOT query for RRTYPE 99 records."  The text ALMOST says that in Section 4.4 and again in 13.2, but for some reason stops short.  This goes to my other issue, that normative language is not appropriately used.


On 2: Folks have said that you are incorrect about underscore in labels being a problem as they are already widely used (e.g. SRV).

I withdraw that issue.  See exchange between Andrew, John and me.

Were your comments misunderstood?

I'm not sure why major issue 3 is "major", but I think the WG can consider it (if it has not already) like some of the other things you've mentioned.

It's in Appendix C.  I was looking at Appendix J.  Withdrawn.

Eliot
--------------030507010107060701070506-- From sm@elandsys.com Sun Aug 25 23:04: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 6269811E815F for ; Sun, 25 Aug 2013 23:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 5PBrjxh3yBIO for ; Sun, 25 Aug 2013 23:04:35 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC11A11E8131 for ; Sun, 25 Aug 2013 23:04:35 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.47]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7Q64FFn006186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Aug 2013 23:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377497074; bh=In+ExFq9zr5Hgj8KgKDaO4WBYpZSclm8Unf2vm/750s=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=nc5sXsIDF8LJUax9gD7/PzTfryRz/MwYF+kWHbVMHO9piIDJBAD+Z/7AbAMBBhipS XgfJ2NYhDIduhPT6UQzJsuOYhZw2l+dYx++dREVl3zt/xaxUltZHVoN0Ys0H+hijFv vkQhdPW21598IdKvusN4CuW6Z124ppyGiZV0qclM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377497074; i=@elandsys.com; bh=In+ExFq9zr5Hgj8KgKDaO4WBYpZSclm8Unf2vm/750s=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=WQv2VqZ+jgYZn9q+I0uEVj1rSHpeh0osg4hFW0HMxk49amc02ZRoxOjR2T2jbVNF5 ram5zAjG6dSlvVkDy6gw9thYNdxRj8ImRLZTzjV6AFEK0fwXXWjgLaHa2JDwRbvuU9 1eP2jpCzpQ8XSoCYw63dHM090+vMjEy8qCRK+Fpo= Message-Id: <6.2.5.6.2.20130825225335.0ae44820@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 25 Aug 2013 23:01:17 -0700 To: Eliot Lear , Pete Resnick From: S Moonesamy In-Reply-To: <521AEB34.2030909@cisco.com> References: <521A1F31.8080402@cisco.com> <521A7AD3.9000704@qti.qualcomm.com> <521AEB34.2030909@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, IESG , Apps Discuss Subject: Re: [apps-discuss] [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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, 26 Aug 2013 06:04:36 -0000 Hi Eliot, At 22:44 25-08-2013, Eliot Lear wrote: >The reference is to Appendix A. Unfortunately, the text there >doesn't go far enough. All it says is: >> 4. [SPF] itself included a faulty transition plan, likely because of >> the late addition of a requirement to develop one -- it said: >> >> An SPF-compliant domain name SHOULD have SPF records of both RR >> types. A compliant domain name MUST have a record of at least >> one type. >> >> which means both can claim to be fully compliant while failing >> utterly to interoperate. > >This reads as if somehow a record is a protocol. What I would >suggest (at the very least) is the following: Yes, that text might be read in different ways. Your review brought a fresh perspective to the discussion. I'll ask the SPFBIS WG about the text. >I withdraw that issue. See exchange between Andrew, John and me. I'll list Issue 2 ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10270.html ) as addressed. >It's in Appendix C. I was looking at Appendix J. Withdrawn. I'll list Issue 3 ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10270.html ) as addressed. Regards, S. Moonesamy (as document shepherd) From jouni.nospam@gmail.com Fri Aug 23 23:52:54 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 C07A221F889C; Fri, 23 Aug 2013 23:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227] 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 DuYb-QVTpSz9; Fri, 23 Aug 2013 23:52:54 -0700 (PDT) Received: from mail-bk0-x229.google.com (mail-bk0-x229.google.com [IPv6:2a00:1450:4008:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7630121F8895; Fri, 23 Aug 2013 23:52:53 -0700 (PDT) Received: by mail-bk0-f41.google.com with SMTP id na10so525438bkb.0 for ; Fri, 23 Aug 2013 23:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8Fnn1cKAw9LjdKGvje1r92FdR1wT78faKQQy4OXMQTQ=; b=MMDGmzQFrtwHHqhhH+Y3vobNxsj1u4JyoZCkOMlu8MRKT0xqGWQ/SC7nxkxgNhVPyU LG4K0+sQN49cuEJ2QCtrw0Yp1xpnC3ZgcQmql2bQ98qkQVjfyVm70Pe1uFk8AYBVLZTe eikoj9t0GcfAuDXL3u+NqBvD7kdAYEgnocs4f8HXOROwlY/9nKYjxyLx2xNuF5bFaRP8 1gknNjOaU93HqadV2crepYbHdA7GGDe5ICOgwFCnPokAl/HiWdu0nfIDs3h2aIIYT/hj brRiaa0Tle7WNN+YbdObncmEY9/oC8W77lubiGd/A/36qLfg3R8tH3e/vSO5Q8DDavYJ rvxg== X-Received: by 10.205.10.132 with SMTP id pa4mr2207144bkb.15.1377327171277; Fri, 23 Aug 2013 23:52:51 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:3026:e8da:dfce:a4d0? ([2001:1bc8:101:f101:3026:e8da:dfce:a4d0]) by mx.google.com with ESMTPSA id no2sm619009bkb.15.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Aug 2013 23:52:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: <68E69EA4-1624-40E6-B23B-281645124FCC@computer.org> Date: Sat, 24 Aug 2013 09:52:48 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <426EEA42-735F-4B63-8600-BBD5595EDBAF@gmail.com> References: <52123A42.6030405@bell-labs.com> <1E23FFA4-7990-437A-B334-F2E65E61E406@computer.org> <52167DBF.8040305@bell-labs.com> <68E69EA4-1624-40E6-B23B-281645124FCC@computer.org> To: Eric McMurry X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Sun, 25 Aug 2013 23:31:22 -0700 Cc: draft-ietf-dime-overload-reqs.all@tools.ietf.org, "Vijay K. Gurbani" , IESG IESG , apps-discuss@ietf.org, Ben Allen Campbell Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-dime-overload-reqs-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: Sat, 24 Aug 2013 06:52:54 -0000 Authors, The changes needed look rather straight forward and we also seem to have=20= consensus among reviewers. Go ahead and submit a revised version as soon as possible for you. You may, if you wish, circulate a diff before the submission among us but that is IMHO not really needed. - Jouni On Aug 23, 2013, at 12:09 AM, Eric McMurry = wrote: > works for me. We'll change that and dereference the abstract in the = next version, pending instructions from the shepherd. >=20 > Thanks! >=20 > Eric >=20 >=20 > On Aug 22, 2013, at 16:08 , "Vijay K. Gurbani" = wrote: >=20 >> On 08/22/2013 03:45 PM, Eric McMurry wrote: >>>> Nits: >>>> =3D=3D=3D=3D=3D >>>> - S3.2, first paragraph: "This document is a work in progress...", >>>> here, "This" refers to TR23.843 or does it refer to dime-overload- >>>> reqs-10? Please clarify. On further reading, there are more >>>> "this document" spread in the subsection with providing an adequate >>>> text that qualifies the "this". >>>=20 >>> we can clear this this up. that should not be a problem :-) >>>=20 >>> more specifically, for the first paragraph of 3.2, how about >>> changing "this document" to "this technical report". >>=20 >> Eric: Better yet, why not simply change it to TR23.843? >>=20 >>> We searched through the rest of the draft and all of the other >>> instances of "this document" refer to the draft itself. Is that more >>> clear when the instance in the first paragraph is addressed? >>=20 >> Yes, that should be fine. >>=20 >> Thanks for your attention to my comments. >>=20 >> - vijay >> --=20 >> 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 >=20 From spf2@kitterman.com Sun Aug 25 21:13: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 85BDA21F9F6F for ; Sun, 25 Aug 2013 21:13:40 -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 365gvv+PsMG8 for ; Sun, 25 Aug 2013 21:13:35 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6984D21F9CDF for ; Sun, 25 Aug 2013 21:13:35 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5599720E40D5; Mon, 26 Aug 2013 00:13:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1377490414; bh=scqWCiEe6qCfbf8qWwxAthCOMkgTClDNDzWYUk2/xQg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NxmWkYuRLi+UPikgGXjelDB4MDvtyZDPGxMtik7Nzf8F7GVhz17KqFBqP+9ljE9Zu v5JwTT20+tPpT+CbLOKO/a9bVnDtZedB3m5zDCI82wi7C4r/3DyWcgicydGbh0TXq9 wMPbdBHc0fsTyQLUOfOernW1cleTXIqCECG6zhYs= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3971920E4076; Mon, 26 Aug 2013 00:13:33 -0400 (EDT) From: Scott Kitterman To: spfbis@ietf.org Date: Mon, 26 Aug 2013 00:13:31 -0400 Message-ID: <2454227.xOQCZa8CLT@scott-latitude-e6320> User-Agent: KMail/4.10.5 (Linux/3.8.0-29-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <521A1F31.8080402@cisco.com> References: <521A1F31.8080402@cisco.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP X-Mailman-Approved-At: Sun, 25 Aug 2013 23:31:22 -0700 Cc: draft-ietf-spfbis-4408bis.all@tools.ietf.org, 'IESG' , Apps Discuss Subject: Re: [apps-discuss] [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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, 26 Aug 2013 04:13:40 -0000 On Sunday, August 25, 2013 17:13:53 Eliot Lear wrote: > 3. Retain a summary of changes since 4408. > > A -bis document usually has a change list that can assist implementers > familiar with previous work. Appendix J is pretty close to what I would > want, but it needs some editing. That's what Appendix C is meant to accomplish. Appendix J is not meant to be included in the final document. As far as I've noticed, the items that aren't listed in Appendix C that are in Appendix J don't directly affect implementers. Is there something specific missing from Appendix C? Scott K From hsantos@isdg.net Mon Aug 26 05:55: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 2FE0E21E8056 for ; Mon, 26 Aug 2013 05:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, 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 fZeGOgJtiubp for ; Mon, 26 Aug 2013 05:55:34 -0700 (PDT) Received: from catinthebox.net (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 27FEC21F9C53 for ; Mon, 26 Aug 2013 05:55:25 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; t=1377521720; h=Received:Received:Received: Received:Message-ID:Date:From:Organization:To:Subject:List-ID; bh=VEqa0igEiNPAPszmhRQsR0G55kE=; b=CfenujdCFIPbP4D2IqnEP3m9p+59d 1zyWs/2FTcS5Q6NAFJT4++hCG58Xx03umNbfhinfiEe3SVhEP5C2gecNLRri16Yg pSiE3pbHl7VhXUnIJ/fR4Ef2fXuW0iFPKeoVmTXu45xyU7OYvFpDu8wa4KxMG50v syI/BnVfw0raF4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for discuss@apps.ietf.org; Mon, 26 Aug 2013 08:55:20 -0400 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 ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3984230982.7373.4212; Mon, 26 Aug 2013 08:55:19 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; t=1377521398; h=Received:Received:Message-ID: Date:From:Organization:To:Subject:List-ID; bh=JaVgqxQR3DSrk8AF81 h8Fddowx+lvGfakKZzkpBTUg8=; b=iWCPbt8BhRJzrXYie1m/d/evP2GpwijLgZ P2VVeIzLqu2uOrkyKLooO4TMllJcwMyi2mW7nZ6xyekwvKFJcP1/+ZqfM4jUl+GA OrFUiDVtouAnmmQS6iUNEvqQl4g1AtLdytMcTEVuoBkZSlJWPzm+qSiiK8M4r0vF FsAd5rNT4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for discuss@apps.ietf.org; Mon, 26 Aug 2013 08:49:58 -0400 Received: from [192.168.1.74] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3430647018.9.5076; Mon, 26 Aug 2013 08:49:58 -0400 Message-ID: <521B502D.5010106@isdg.net> Date: Mon, 26 Aug 2013 08:55:09 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Eliot Lear References: <521A1F31.8080402@cisco.com> In-Reply-To: <521A1F31.8080402@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 26 Aug 2013 08:18:14 -0700 Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, 'IESG' , Apps Discuss Subject: Re: [apps-discuss] [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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, 26 Aug 2013 12:55:40 -0000 Hi Eliot, I appreciate your review of SPFBIS. I only have a few small input bits to provide: Eliot Lear wrote: > Summary: This draft is not yet ready for publication as a Proposed > Standard and should be revised before publication. +1 > Major issues: > > 1. Deprecation of SPF record not properly justified in text and in the > wrong place > > Deprecation of the SPF record is given short shrift in Section 13.1 > which is the IANA considerations section. A persistent reader would not > understand why the record was in fact deprecated. Here's what is 13.1 > (there are a few words about 6686 in 3.1 as well, but nobody would care > if this was simply a matter of low implementation/deployment). > >> Studies have shown that RRTYPE 99 has not seen any substantial use, >> and in fact its existence and mechanism defined in [RFC4408] has led >> to some interoperability issues. > > First, this text should be moved out of the IANA considerations sections > and forward to Section 3.1. Second it should explain what those > interoperability issues are or have a normative (and retrievable) > reference. At the very least, the winning argument(s) should be > elucidated, and not just for posterity: the claim is that there is an > interoperability problem. If so, then might administrators want to know > that? > > The matter of handling garbage in garbage out is not well enough > specified in Section 3. I would go considerably further and state that > (a) records that do not begin with "v=spf1" MUST NOT be processed > further, and (b) that any record that does not conform to the stated > grammar MUST be ignored. I think the documentation usage of the term "SPF record" can be confusing if the type99 is going to be removed. It can suggest that this "SPF record" is unique and is not residing with other "records." I think the term should be more specific to say the SPF TXT resultant record contains multiple EOL (CRLF or CR or LF terminators) strings and and only a string beginning with the *token* "v=spf1" is a considered a SPF record string. In theory, the parser should tokenizing it to check for "v=" and then only process the v= value "spf1" Perhaps a more specific term such as "SPF Line Record" or String would be clearer. > Also, did the working group consider a > DKIM-like solution? They all but establish an _spf label in this > document (I'll come to that in a moment). Yes. It was but I didn't think it was taken serious. I can see now the draft was leaning towards to publishing method. My particular concern with this is that it also yields a TXT/TXT dual call waste and high redundancy if it doesn't become a learned processed (a domain is known to use _spf. zone). In other words, for large ESP using this method, it will yield a very high overhead in at least TWO TXT lookups. Keep in mind one of the SPF99/TXT concerns is the wasted SPF99 call. > There is a general issue about when to deprecate an RR and the ability > to add new RRs into the DNS. That issue has to be addressed in the > longer term, no matter what the IESG and community decide here. > Furthermore, to be clear, please do not read into the above comments an > opinion about deprecation of the record itself, which I am withholding > until there is clear text about the interoperability issues that are > mentioned. +1. -- HLS From internet-drafts@ietf.org Mon Aug 26 20:50: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 6D0DF11E813F; Mon, 26 Aug 2013 20:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.039, 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 bquofNor5QfH; Mon, 26 Aug 2013 20:50:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA81A11E8140; Mon, 26 Aug 2013 20:50:03 -0700 (PDT) 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.70.p1 Message-ID: <20130827035003.7204.68870.idtracker@ietfa.amsl.com> Date: Mon, 26 Aug 2013 20:50:03 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-18.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: Tue, 27 Aug 2013 03:50:04 -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 : WebFinger Author(s) : Paul E. Jones Gonzalo Salgueiro Michael B. Jones Joseph Smarr Filename : draft-ietf-appsawg-webfinger-18.txt Pages : 25 Date : 2013-08-26 Abstract: This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-18 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 ioseb.dzmanashvili@gmail.com Tue Aug 27 02:03: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 60C7011E816F; Tue, 27 Aug 2013 02:03:06 -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 Y5xYNtvmghJM; Tue, 27 Aug 2013 02:03:05 -0700 (PDT) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 207D611E816D; Tue, 27 Aug 2013 02:03:04 -0700 (PDT) Received: by mail-ea0-f169.google.com with SMTP id k11so2142802eaj.28 for ; Tue, 27 Aug 2013 02:03:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:subject:mime-version:content-type :content-transfer-encoding:content-disposition; bh=N6QsvA/2dGpleIUjePp3tUOTLhDKK4kTBnuMp+88xdc=; b=DPV9uy9FHBVcb4MfboLl/wlAgy+DxjVWgmw/Y5bOnZrA7RXmmFh9gnTJYFZcaQrkCZ YqKrr9ve1d12lFQG47Ty9fYqL4wyG+SfcTm2RJh+iAP1jfukG4Ul7NLphNkvOb5wTi2F hjoZ00IRS9GTrI8XCAAYTLUrW3qE197zLFFG2seGGzbPojxAXhrcAHOXSsVCwt7hKt8y QPMQ2NAxlAtr1E4ehTqDwLEWrB0jzOqUdD+DLepoigdlV2GHZAD3A/hhxXp3oUWj98O0 yW47vluPKYp0JJP1zF2x0HIorEtS8NpRrMbqffvPuai7kKY/mLqlJNkG+23j2P1y6ULB j6Dw== X-Received: by 10.14.174.8 with SMTP id w8mr758357eel.84.1377594182964; Tue, 27 Aug 2013 02:03:02 -0700 (PDT) Received: from [10.131.33.142] ([213.131.60.234]) by mx.google.com with ESMTPSA id f49sm27490889eec.7.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 27 Aug 2013 02:03:02 -0700 (PDT) Date: Tue, 27 Aug 2013 13:03:00 +0400 From: Ioseb Dzmanashvili To: link-relations Message-ID: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: IETF Apps Discuss Subject: [apps-discuss] NEW RELATION: 'action' version update 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, 27 Aug 2013 09:03:06 -0000 Hi All, I've updated the "action" link relation type spec[1] based on initial feedback. As far as initial reactions were very controversial and raised a lot of issues i tried to address all of them and entirely changed the spec. ================================================== When included in a response, the "action" link relation indicates a target resource that is responsible for performing action which MAY: - Affect state of the context resource; or - Initiate process. The "action" link relation type can be used to indicate the availability of actions supported by the target resource. Examples of such actions include: - Enable/Disable - Publish/Unpublish - Start/Stop The "action" link relation type doesn't convey any semantics other than that an indicated resources represent machine readable description of a particular action and representation SHOULD contain all necessary details such as: request method, action URI and other related details to enable agents to be able to construct requests without relying on out-of-band information. Exact type of action SHOULD be indicated through the "action-type" link-extension value as per [RFC5988] and for maintaining shared understanding of action types current specification introduces the registry of actions with initial values of widely accepted and well understood action types. For example, if a resource represents a service, that same representation may include links to resources that represent actions supported by the service: Link: ; rel="action"; action-type="restart" Link: ; rel="action"; action-type="stop" ================================================== 1. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-01 Cheers, ioseb -- Ioseb Dzmanashvili AzRy LLC Software Architect #8, Chachava str. Tbilisi, 0159, Georgia Mobile: +(995) 99753388 azry.com github.com/ioseb twitter.com/iosebi From fanf2@hermes.cam.ac.uk Tue Aug 27 03:10: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 EED1E21F9EB5 for ; Tue, 27 Aug 2013 03:10:29 -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 kVIE9nd5j7rK for ; Tue, 27 Aug 2013 03:10:29 -0700 (PDT) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f33]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC8521F9E77 for ; Tue, 27 Aug 2013 03:10:28 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:43075) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1VEGED-0003jI-j5 (Exim 4.80_167-5a66dd3) (return-path ); Tue, 27 Aug 2013 11:10:25 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1VEGED-0004kj-Sy (Exim 4.72) (return-path ); Tue, 27 Aug 2013 11:10:25 +0100 Date: Tue, 27 Aug 2013 11:10:25 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: John Levine In-Reply-To: <20130822020147.91910.qmail@joyce.lan> Message-ID: References: <20130822020147.91910.qmail@joyce.lan> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] DNS work 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, 27 Aug 2013 10:10:30 -0000 John Levine wrote: > >I'm more interested in the latter work than the former, but I suggest > >that the proponents of both might try to generate some discussion, > >feedback, and perhaps even implementation before we take the relevant > >I-Ds on as WG items. > > I'm currently rewriting my Web Crudware(tm) DNS front end and will do > the dns extension language stuff. I believe that Tony Finch > implemnented a version of it last year. I experimented but didn't manage to finish it. I haven't looked at your recent drafts (sorry) but the early draft I started from was a bit too limited to do what I wanted. My experiments were trying to work out an RDATA description language that could be able to drive code that can: (1) parse and serialize wire format (2) parse and serialize presentation format (3) generate a reasonably friendly form-based editing user interface (There are obviously some complicated RDATA types that need special case code, but generic code could cope with many of the existing types.) Goal (2) implies that the description language needs to be able to handle enumerations with symbolic values, if it is to support a fully standards- conformant parser. Goal (3) implies to me that you need field names, and named flag bit values. (Many, but not all, of the existing RDATA specs include these names.) This is so that the user interface can help the user enter the data correctly. For instance, can you remember what the three numbers in a SRV record mean? Field names also allow an implementation to have tables mapping names to descriptions in different international languages. It is hard to come up with a language that does this simply and economically. I was trying out variations with a line per field with indented lines for enumeration/flag values or special pragmas such as name compression. I'm not sure how to squeeze something like this into the DNS in a readable manner :-) Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From julian.reschke@gmx.de Tue Aug 27 03:15: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 3284B11E8172 for ; Tue, 27 Aug 2013 03:15:29 -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 MGWpbTGuI5mR for ; Tue, 27 Aug 2013 03:15:23 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEC911E8163 for ; Tue, 27 Aug 2013 03:15:22 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LpKrt-1ViLvR3uBZ-00fEa9 for ; Tue, 27 Aug 2013 12:15:21 +0200 Message-ID: <521C7C36.9000505@gmx.de> Date: Tue, 27 Aug 2013 12:15:18 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ioseb Dzmanashvili References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> In-Reply-To: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:6b+09VoygE1Vc2iL5WyU+vFrbnePbvsIh/A3azOG7vJOblFJ1Qg fnqQkLmn+5VPWSjgcaE6n31tk9fSHTLFlj97jJjsfabPvRStfaHmpnLHl+BycBEO43LxTAl HsqLg+6Ka9/5lpZT0u4GyxKDKcqqL+TDEGlOCCk48gUq9YKtvYhAZuQGLhv3SWbtPeBRXiM oO8PyTcqQncpNEkCGxqxQ== Cc: IETF Apps Discuss , link-relations Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 27 Aug 2013 10:15:30 -0000 On 2013-08-27 11:03, Ioseb Dzmanashvili wrote: > Hi All, > > I've updated the "action" link relation type spec[1] based on initial feedback. > > As far as initial reactions were very controversial and raised a lot of issues i tried to address all of them and entirely changed the spec. > > ================================================== > When included in a response, the "action" link relation indicates a > target resource that is responsible for performing action which MAY: > > - Affect state of the context resource; or > - Initiate process. > > The "action" link relation type can be used to indicate the > availability of actions supported by the target resource. Examples > of such actions include: > > - Enable/Disable > - Publish/Unpublish > - Start/Stop > > The "action" link relation type doesn't convey any semantics other > than that an indicated resources represent machine readable > description of a particular action and representation SHOULD contain > all necessary details such as: request method, action URI and other > related details to enable agents to be able to construct requests > without relying on out-of-band information. > > Exact type of action SHOULD be indicated through the "action-type" > link-extension value as per [RFC5988] and for maintaining shared > understanding of action types current specification introduces the > registry of actions with initial values of widely accepted and well > understood action types. > > For example, if a resource represents a service, that same > representation may include links to resources that represent actions > supported by the service: > > Link: ; rel="action"; action-type="restart" > Link: ; rel="action"; action-type="stop" > ... It seems that you are just adding an indirection mechanism. Why is that necessary? Best regards, Julian From mark@coactus.com Tue Aug 27 06:16: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 B897B11E8336 for ; Tue, 27 Aug 2013 06:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[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 IlsFIuPxTaRr for ; Tue, 27 Aug 2013 06:16:01 -0700 (PDT) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4338C11E830B for ; Tue, 27 Aug 2013 06:16:00 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id lf1so4828558pab.10 for ; Tue, 27 Aug 2013 06:16:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ErJOpKndlYmjxpCW9rXL3dXdqBykuQNvDlkWu2+/gAk=; b=LXXGiLZqeqJ9NfjVVHg4jhRtdW6boy+1D+3ZTV7YG24wROgWmpd+DrxnooNg8rewEo aFKpU6uNvtjOps3qsjMOGQ4cQwjuZEeG5HvGufHamxiQ3T/pMUAqCJ5o7oFkaauAkrAy gGuLfniboZ21vhHjHd5xSZ9+wKaj3lWkQvkf0NoW6RaGPffKAYBd7ObqauY2J06O9sS/ K5CeeCkqXKNK2nREIq4cJ8NhRQDYxh9QO/F28uDMXFcMM917kyyG6JTV9TbhL+KL+SO/ QNPttMkK77cgy+Cf27Ce94fjIGCaQYFWHcL0o1THvKD8j64KIzb3sSK6d8Zh0ckwjjFW fShA== X-Gm-Message-State: ALoCoQlLjdJXPjBR23X90WtmC+lS42RdMngPksNgp/AkBu+Y64UgFhCs7FH/VrLj2AvxDpKP1ixn MIME-Version: 1.0 X-Received: by 10.66.255.10 with SMTP id am10mr8889900pad.165.1377609360283; Tue, 27 Aug 2013 06:16:00 -0700 (PDT) Sender: mark@coactus.com Received: by 10.70.25.67 with HTTP; Tue, 27 Aug 2013 06:16:00 -0700 (PDT) X-Originating-IP: [184.148.180.204] Received: by 10.70.25.67 with HTTP; Tue, 27 Aug 2013 06:16:00 -0700 (PDT) In-Reply-To: <521C7C36.9000505@gmx.de> References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> Date: Tue, 27 Aug 2013 09:16:00 -0400 X-Google-Sender-Auth: sEx411EBuCiz3fz7eDpu5vHCAto Message-ID: From: Mark Baker To: Julian Reschke Content-Type: multipart/alternative; boundary=047d7b15fc358f217604e4edac51 Cc: apps-discuss@ietf.org, link-relations Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 27 Aug 2013 13:16:06 -0000 --047d7b15fc358f217604e4edac51 Content-Type: text/plain; charset=ISO-8859-1 On 2013-08-27 6:15 AM, "Julian Reschke" wrote: > It seems that you are just adding an indirection mechanism. Why is that necessary? Agreed. The action-types should be registered as the relations. Also, you might consider reusing the good work of the folks behind Schema.org; http://schema.org/Action --047d7b15fc358f217604e4edac51 Content-Type: text/html; charset=ISO-8859-1


On 2013-08-27 6:15 AM, "Julian Reschke" <julian.reschke@gmx.de> wrote:
> It seems that you are just adding an indirection mechanism. Why is that necessary?

Agreed. The action-types should be registered as the relations.

Also, you might consider reusing the good work of the folks behind Schema.org;

http://schema.org/Action

--047d7b15fc358f217604e4edac51-- From barryleiba@gmail.com Tue Aug 27 07:11: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 16C5011E80FA; Tue, 27 Aug 2013 07:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.983 X-Spam-Level: X-Spam-Status: No, score=-101.983 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 npyIaO0X3agf; Tue, 27 Aug 2013 07:11:54 -0700 (PDT) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7F95711E8312; Tue, 27 Aug 2013 07:11:54 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id f6so2599158qej.19 for ; Tue, 27 Aug 2013 07:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=sukUIGXRSI6vvS2kn5qRBHcfAT1FvknlRzZ8HYBS4yU=; b=JjAGRyr6YPb2MajALzoNK0s+mCVrSbKy2dNtrUaDDifBSyGI5U9wf2dZD+26EZpZCr SAnGzWS9EeSXVzoycDNlXCY1qphPRC1FIMm3t2q37KbUvxU8J7Bz7LqNUUQcXpgfkyKW 5xlVPuLavhGpt6Tpyt4EKUyQjbJTOdlqSUMdIqu3dImoTNbaG1KZe8Cgmxgrc3NQdfPo 8q/2sYs4P6dpgIBUr6OBr7l69o4HsRf62h6wgiYsLz/2M1GYmylwB3mCCPQ/scmhW/YC 8IYSuy3T3cymbsNFc8UGU9x8YBb0znDrWpRi6iLEFLs+onse5g+kaz1ZXZKAwZuFiBjt R2dQ== MIME-Version: 1.0 X-Received: by 10.49.106.226 with SMTP id gx2mr15423149qeb.67.1377612713662; Tue, 27 Aug 2013 07:11:53 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.59.211 with HTTP; Tue, 27 Aug 2013 07:11:53 -0700 (PDT) Date: Tue, 27 Aug 2013 10:11:53 -0400 X-Google-Sender-Auth: AfzahSKszS4LEwQ1LygOoY9XFHw Message-ID: From: Barry Leiba To: IESG Content-Type: text/plain; charset=ISO-8859-1 Cc: "webfinger@ietf.org" , Apps Discuss Subject: [apps-discuss] Approved: draft-ietf-appsawg-webfinger-18 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, 27 Aug 2013 14:11:55 -0000 IESG Secretary (bcc), with FYI to the webfinger and apps-discuss lists: The subject draft is ready for approval, with all DISCUSSes cleared, non-blocking comments reasonably addressed, and final reviews and cross-checks done. No RFC Editor notes needed. Please send out the approval notice, and thanks. Barry From jasnell@gmail.com Tue Aug 27 08:39: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 BBAAF11E837D; Tue, 27 Aug 2013 08:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rj517WPNI8G1; Tue, 27 Aug 2013 08:39:09 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id F018711E8379; Tue, 27 Aug 2013 08:39:08 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id k18so5422498oag.26 for ; Tue, 27 Aug 2013 08:39:08 -0700 (PDT) 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=zuyIxln+pPiHNXyfdwD1SWX0ldcI+uekhOQv7SgVAYU=; b=CWbHa188AY9pKQDBc6Mqhib/3kJ63T43Z9l63XI/Nkpkwq54uJ9UNa0kEoJGlPUd9/ Kvo7d6vOomPmRWgBYo2q+Ae/wZvww/yuarz9Sh2FG5S+W7ZH6ZQpQ32BCy12QnQ0hMUn 7C8X0ShvVpLobgZafydI15W5lrxaHhiJS8Foj9ynMB+7GR4azrdNxtKlXXGZiuWIpW+U 3W33vO02ysFhm1XlsXE67JCmi57HoBLiaFb2AlLQf/QKI7mada4PaTbkYcRU4WjVJbFb zmzFlSP05vrKpiCpFyiIq5zajELvhn9Nv0zNsjIETtHCrIaXmwpmrZUkdVE9z3fq4d27 8Asw== X-Received: by 10.182.87.73 with SMTP id v9mr2376256obz.90.1377617948502; Tue, 27 Aug 2013 08:39:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.124.137 with HTTP; Tue, 27 Aug 2013 08:38:48 -0700 (PDT) In-Reply-To: References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> From: James M Snell Date: Tue, 27 Aug 2013 08:38:48 -0700 Message-ID: To: Mark Baker Content-Type: text/plain; charset=UTF-8 Cc: Julian Reschke , IETF Apps Discuss , link-relations Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 27 Aug 2013 15:39:10 -0000 On Tue, Aug 27, 2013 at 6:16 AM, Mark Baker wrote: > > On 2013-08-27 6:15 AM, "Julian Reschke" wrote: >> It seems that you are just adding an indirection mechanism. Why is that >> necessary? > > Agreed. The action-types should be registered as the relations. > > Also, you might consider reusing the good work of the folks behind > Schema.org; > > http://schema.org/Action > Not to mention activitystrea.ms where many of these verbs already exist (and could easily be used as link relations themselves). Link: ; rel="start" Link: ; rel="restart" Would be generally easier overall. - James > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From darrel.miller@gmail.com Tue Aug 27 10:47: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 83E0E11E83CE; Tue, 27 Aug 2013 10:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0L3gGmF6TL0; Tue, 27 Aug 2013 10:47:15 -0700 (PDT) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id A82A211E83A1; Tue, 27 Aug 2013 10:47:15 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id h1so5867290oag.38 for ; Tue, 27 Aug 2013 10:47:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=4J3ix++KSfXfigQRIlGEybH91BcgJS7D2/Nt5Wxqvks=; b=Kd7BCo+X+WB77/TkHeqd+vU+o9jwWpRFsnHMGUJctduVoPUwI8mHA2uQuvLDnmANc+ +GgsMdeF7mPZPExbxDbvUkqhDX67FscyeUk1A23rdS/KV6wDJAWIuIEwnQsNkLaHTMWj 6Ac0ej5TWZbp1EPkPdcWLVYOmw6WrHyLsZS4mv7SEfOxcGe77WN3aAXCTyCKZXmaMC1m SgXMGfOux6gywgk1qC7dIGwSmgq69eDW9Y6vy6As3tdemBsfZJxDVvDhRTI84sg7n8IX Tex7exhneslwRnReDhi+pLrE8v2f2uxpmfEF5bUgWVqDumvhMpeI/AkreUw4p3AWb9EW uKtg== MIME-Version: 1.0 X-Received: by 10.50.43.170 with SMTP id x10mr10590485igl.45.1377625635219; Tue, 27 Aug 2013 10:47:15 -0700 (PDT) Received: by 10.43.77.66 with HTTP; Tue, 27 Aug 2013 10:47:15 -0700 (PDT) Date: Tue, 27 Aug 2013 13:47:15 -0400 Message-ID: From: Darrel Miller To: IETF Apps Discuss , link-relations Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [apps-discuss] NEW RELATION: 'action' version update X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: darrel@tavis.ca List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 17:47:16 -0000 Unfortunately, I agree that this latest revision of the action link relation spec does not add value beyond what can be done directly with link relations. However, I don't believe that is the case with the original action link relation spec. [1] The original spec defined the action link relation type to convey just enough semantics to allow a client to activate that link. The semantics of the link relation were "perform an unsafe request by performing a POST to the target resource using an empty body". Some user agents have no need to understand the semantics of "start", "restart", "MoveAction", "PlayAction", etc. As long as the hypermedia affordance can be rendered and interpreted by the user, why does the user-agent need to know anything more that POST an empty body to this processing resource upon activation? The feedback received on the link relations list was that this type of link relation would encourage RPC like interactions and the proposal was rejected. I still have not completely understood why a representation that includes a body is OK but a representation that has no body is considered RPC like. >From what I am reading here, in this thread is that rel="start" or rel="restart" are considered valid interactions. Then I see no reason why the more generic and much more widely applicable "action" relation would not be considered valid also. Considering the example James gave, why not this, Link: ; rel="action"; title="Start" Link: ; rel="action"; title="Restart" Darrel Miller [1] http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-00 On Tue, Aug 27, 2013 at 11:38 AM, James M Snell wrote: > On Tue, Aug 27, 2013 at 6:16 AM, Mark Baker wrote: >> >> On 2013-08-27 6:15 AM, "Julian Reschke" wrote: >>> It seems that you are just adding an indirection mechanism. Why is that >>> necessary? >> >> Agreed. The action-types should be registered as the relations. >> >> Also, you might consider reusing the good work of the folks behind >> Schema.org; >> >> http://schema.org/Action >> > > Not to mention activitystrea.ms where many of these verbs already > exist (and could easily be used as link relations themselves). > > Link: ; rel="start" > Link: ; rel="restart" > > Would be generally easier overall. > > - James > >> From emcmurry@computer.org Mon Aug 26 11:17: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 675FC11E81F5; Mon, 26 Aug 2013 11:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] 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 87M3nrwSWiVt; Mon, 26 Aug 2013 11:17:09 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 663D411E81E6; Mon, 26 Aug 2013 11:17:07 -0700 (PDT) Received: from [23.29.115.42] (helo=[10.153.1.6]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1VE1LZ-0004Bb-O9; Mon, 26 Aug 2013 18:17:02 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 23.29.115.42 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19xxIHJuDy0h4XDV4aYb+yYacmViopUs9o= Content-Type: multipart/mixed; boundary="Apple-Mail=_9751E1EA-A0C0-4DD4-AABB-D89C9EE33CD2" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Eric McMurry In-Reply-To: <426EEA42-735F-4B63-8600-BBD5595EDBAF@gmail.com> Date: Mon, 26 Aug 2013 13:16:57 -0500 Message-Id: References: <52123A42.6030405@bell-labs.com> <1E23FFA4-7990-437A-B334-F2E65E61E406@computer.org> <52167DBF.8040305@bell-labs.com> <68E69EA4-1624-40E6-B23B-281645124FCC@computer.org> <426EEA42-735F-4B63-8600-BBD5595EDBAF@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Tue, 27 Aug 2013 10:48:42 -0700 Cc: draft-ietf-dime-overload-reqs.all@tools.ietf.org, "Vijay K. Gurbani" , IESG IESG , apps-discuss@ietf.org, Ben Allen Campbell Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-dime-overload-reqs-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: Mon, 26 Aug 2013 18:17:14 -0000 --Apple-Mail=_9751E1EA-A0C0-4DD4-AABB-D89C9EE33CD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks Jouni, I have submitted the changes (I agree they were minor, and this way we = have full tracking): Filename: draft-ietf-dime-overload-reqs Revision: 11 Title: Diameter Overload Control Requirements Creation date: 2013-08-26 Group: dime Number of pages: 28 URL: = http://www.ietf.org/internet-drafts/draft-ietf-dime-overload-reqs-11.txt Status: = http://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs Htmlized: = http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-11 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-overload-reqs-11 Here is a diff. The changes were small, but please let me know if I've = botched something. --Apple-Mail=_9751E1EA-A0C0-4DD4-AABB-D89C9EE33CD2 Content-Disposition: attachment; filename=draft-ietf-dime-overload-reqs-10_11.html Content-Type: text/html; name="draft-ietf-dime-overload-reqs-10_11.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-dime-overload-reqs-10.txt draft-ietf-dime-overload-reqs-11.txt 

Network Working Group                                         E. McMurry
Internet-Draft                                               B. Campbell
Intended status: Informational                                   Tekelec
Expires: January 30, February 27, 2014                                  July 29,                               August 26, 2013

                 Diameter Overload Control Requirements
                    draft-ietf-dime-overload-reqs-10
                    draft-ietf-dime-overload-reqs-11

Abstract

   When a Diameter server or agent becomes overloaded, it needs to be
   able to gracefully reduce its load, typically by informing clients to
   reduce sending traffic for some period of time.  Otherwise, it must
   continue to expend resources parsing and responding to Diameter
   messages, possibly resulting in congestion collapse.  The existing
   Diameter mechanisms, listed in Section 4 mechanisms are not sufficient for this purpose.  This
   document describes the limitations of the existing
   mechanisms in Section 5. mechanisms.
   Requirements for new overload management mechanisms are provided in Section 7. also
   provided.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 30, February 27, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Documentation Conventions  . . . . . . . . . . . . . . . .  3
     1.2.  Causes of Overload . . . . . . . . . . . . . . . . . . . .  4
     1.3.  Effects of Overload  . . . . . . . . . . . . . . . . . . .  5
     1.4.  Overload vs. Network Congestion  . . . . . . . . . . . . .  5
     1.5.  Diameter Applications in a Broader Network . . . . . . . .  6
   2.  Overload Control Scenarios . . . . . . . . . . . . . . . . . .  6
     2.1.  Peer to Peer Scenarios . . . . . . . . . . . . . . . . . .  7
     2.2.  Agent Scenarios  . . . . . . . . . . . . . . . . . . . . .  9
     2.3.  Interconnect Scenario  . . . . . . . . . . . . . . . . . . 12
   3.  Diameter Overload Case Studies . . . . . . . . . . . . . . . . 13
     3.1.  Overload in Mobile Data Networks . . . . . . . . . . . . . 13
     3.2.  3GPP Study on Core Network Overload  . . . . . . . . . . . 15
   4.  Existing Mechanisms  . . . . . . . . . . . . . . . . . . . . . 15
   5.  Issues with the Current Mechanisms . . . . . . . . . . . . . . 16
     5.1.  Problems with Implicit Mechanism . . . . . . . . . . . . . 17
     5.2.  Problems with Explicit Mechanisms  . . . . . . . . . . . . 17
   6.  Extensibility and Application Independence . . . . . . . . . . 18
   7.  Solution Requirements  . . . . . . . . . . . . . . . . . . . . 19
     7.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . . 19
     7.2.  Performance  . . . . . . . . . . . . . . . . . . . . . . . 20
     7.3.  Heterogeneous Support for Solution . . . . . . . . . . . . 21
     7.4.  Granular Control . . . . . . . . . . . . . . . . . . . . . 21
     7.5.  Priority and Policy  . . . . . . . . . . . . . . . . . . . 22
     7.6.  Security . . . . . . . . . . . . . . . . . . . . . . . . . 22
     7.7.  Flexibility and Extensibility  . . . . . . . . . . . . . . 23
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23 24
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23 24
     9.1.  Access Control . . . . . . . . . . . . . . . . . . . . . . 24
     9.2.  Denial-of-Service Attacks  . . . . . . . . . . . . . . . . 24 25
     9.3.  Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 24 25
     9.4.  Man-in-the-Middle Attacks  . . . . . . . . . . . . . . . . 25
     9.5.  Compromised Hosts  . . . . . . . . . . . . . . . . . . . . 25 26
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 26
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 25 26
     10.2. Informative References . . . . . . . . . . . . . . . . . . 26
   Appendix A.  Contributors  . . . . . . . . . . . . . . . . . . . . 26 27
   Appendix B.  Acknowledgements  . . . . . . . . . . . . . . . . . . 27
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 28

1.  Introduction

   A Diameter [RFC6733] node is said to be overloaded when it has
   insufficient resources to successfully process all of the Diameter
   requests that it receives.  When a node becomes overloaded, it needs
   to be able to gracefully reduce its load, typically by informing
   clients to reduce sending traffic for some period of time.
   Otherwise, it must continue to expend resources parsing and
   responding to Diameter messages, possibly resulting in congestion
   collapse.  The existing mechanisms provided by Diameter are not
   sufficient for this purpose.  This document describes the limitations
   of the existing mechanisms, and provides requirements for new
   overload management mechanisms.

   This document draws on the work done on SIP overload control
   ([RFC5390], [RFC6357]) as well as on experience gained via overload
   handling in Signaling System No. 7 (SS7) networks and studies done by
   the Third Generation Partnership Project (3GPP) (Section 3).

   Diameter is not typically an end-user protocol; rather it is
   generally used as one component in support of some end-user activity.

   For example, a SIP server might use Diameter to authenticate and
   authorize user access.  Overload in the Diameter backend
   infrastructure will likely impact the experience observed by the end
   user in the SIP application.

   The impact of Diameter overload on the client application (a client
   application may use the Diameter protocol and other protocols to do
   its job) is beyond the scope of this document.

   This document presents non-normative descriptions of causes of
   overload along with related scenarios and studies.  Finally, it
   offers a set of normative requirements for an improved overload
   indication mechanism.

1.1.  Documentation Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as defined in [RFC2119], with the
   exception that they are not intended for interoperability of
   implementations.  Rather, they are used to describe requirements
   towards future specifications where the interoperability requirements
   will be defined.

   The terms "client", "server", "agent", "node", "peer", "upstream",
   and "downstream" are used as defined in [RFC6733].

1.2.  Causes of Overload

   Overload occurs when an element, such as a Diameter server or agent,
   has insufficient resources to successfully process all of the traffic
   it is receiving.  Resources include all of the capabilities of the
   element used to process a request, including CPU processing, memory,
   I/O, and disk resources.  It can also include external resources such
   as a database or DNS server, in which case the CPU, processing,
   memory, I/O, and disk resources of those elements are effectively
   part of the logical element processing the request.

   External resources can include upstream Diameter nodes; for example,
   a Diameter agent can become effectively overloaded if one or more
   upstream nodes are overloaded.  While overload is not the same thing
   as network congestion, network congestion can reduce a Diameter nodes
   ability to process and respond to requests, thus contributing to
   overload.

   A Diameter node can become overloaded due to request levels that
   exceed its capacity, a reduction of available resources ( for
   example, a local or upstream hardware failure) or a combination of
   the two.

   Overload can occur for many reasons, including:

   Inadequate capacity:  When designing Diameter networks, that is,
      application layer multi-node Diameter deployments, it can be very
      difficult to predict all scenarios that may cause elevated
      traffic.  It may also be more costly to implement support for some
      scenarios than a network operator may deem worthwhile.  This
      results in the likelihood that a Diameter network will not have
      adequate capacity to handle all situations.

   Dependency failures:  A Diameter node can become overloaded because a
      resource on which it is dependent has failed or become overloaded,
      greatly reducing the logical capacity of the node.  In these
      cases, even minimal traffic might cause the node to go into
      overload.  Examples of such dependency overloads include DNS
      servers, databases, disks, and network interfaces.

   Component failures:  A Diameter node can become overloaded when it is
      a member of a cluster of servers that each share the load of
      traffic, and one or more of the other members in the cluster fail.
      In this case, the remaining nodes take over the work of the failed
      nodes.  Normally, capacity planning takes such failures into
      account, and servers are typically run with enough spare capacity
      to handle failure of another node.  However, unusual failure
      conditions can cause many nodes to fail at once.  This is often
      the case with software failures, where a bad packet or bad
      database entry hits the same bug in a set of nodes in a cluster.

   Network Initiated Traffic Flood:  Issues with the radio access
      network in a mobile network such as radio overlays with frequent
      handovers, and operational changes are examples of network events
      that can precipitate a flood of Diameter signaling traffic, such
      as an avalanche restart.  Failure of a Diameter proxy may also
      result in a large amount of signaling as connections and sessions
      are reestablished.

   Subscriber Initiated Traffic Flood:  Large gatherings of subscribers
      or events that result in many subscribers interacting with the
      network in close time proximity can result in Diameter signaling
      traffic floods.  For example, the finale of a large fireworks show
      could be immediately followed by many subscribers posting
      messages, pictures, and videos concentrated on one portion of a
      network.  Subscriber devices, such as smartphones, may use
      aggressive registration strategies that generate unusually high
      Diameter traffic loads.

   DoS attacks:  An attacker, wishing to disrupt service in the network,
      can cause a large amount of traffic to be launched at a target
      element.  This can be done from a central source of traffic or
      through a distributed DoS attack.  In all cases, the volume of
      traffic well exceeds the capacity of the element, sending the
      system into overload.

1.3.  Effects of Overload

   Modern Diameter networks, comprised of application layer multi-node
   deployments of Diameter elements, may operate at very large
   transaction volumes.  If a Diameter node becomes overloaded, or even
   worse, fails completely, a large number of messages may be lost very
   quickly.  Even with redundant servers, many messages can be lost in
   the time it takes for failover to complete.  While a Diameter client
   or agent should be able to retry such requests, an overloaded peer
   may cause a sudden large increase in the number of transaction
   transactions needing to be retried, rapidly filling local queues or
   otherwise contributing to local overload.  Therefore Diameter devices
   need to be able to shed load before critical failures can occur.

1.4.  Overload vs. Network Congestion

   This document uses the term "overload" to refer to application-layer
   overload at Diameter nodes.  This is distinct from "network
   congestion", that is, congestion that occurs at the lower networking
   layers that may impact the delivery of Diameter messages between
   nodes.  The authors recognize that element overload and network
   congestion are interrelated, and that overload can contribute to
   network congestion and vice versa.

   Network congestion issues are better handled by the transport
   protocols.  Diameter uses TCP and SCTP, both of which include
   congestion management features.  Analysis of whether those features
   are sufficient for transport level congestion between Diameter nodes,
   and any work to further mitigate network congestion is out of scope
   both for this document, and for the work proposed by this document.

1.5.  Diameter Applications in a Broader Network

   Most elements using Diameter applications do not use Diameter
   exclusively.  It is important to realize that overload of an element
   can be caused by a number of factors that may be unrelated to the
   processing of Diameter or Diameter applications.

   An element that doesn't use Diameter exclusively needs to be able to
   signal to Diameter peers that it is experiencing overload regardless
   of the cause of the overload, since the overload will affect that
   element's ability to process Diameter transactions.  If the element
   communicates with other protocols than Diameter, it may also need to
   signal the overload situation on these protocols depending on its
   function and the architecture of the network and application it is
   providing services for.  Whether that is necessary can only be
   decided within the context of that architecture and use cases.  A
   mechanism for signaling overload with Diameter, which this
   specification details the requirements for, provides Diameter nodes
   the ability to signal their Diameter peers of overload, mitigating
   that part of the issue.  Diameter nodes may need to use this, as well
   as other mechanisms, to solve their broader overload issues.
   Indicating overload on protocols other than Diameter is out of scope
   for this document, and for the work proposed by this document.

2.  Overload Control Scenarios

   Several Diameter deployment scenarios exist that may impact overload
   management.  The following scenarios help motivate the requirements
   for an overload management mechanism.

   These scenarios are by no means exhaustive, and are in general
   simplified for the sake of clarity.  In particular, the authors
   assume for the sake of clarity that the client sends Diameter
   requests to the server, and the server sends responses to client,
   even though Diameter supports bidirectional applications.  Each
   direction in such an application can be modeled separately.

   In a large scale deployment, many of the nodes represented in these
   scenarios would be deployed as clusters of servers.  The authors
   assume that such a cluster is responsible for managing its own
   internal load balancing and overload management so that it appears as
   a single Diameter node.  That is, other Diameter nodes can treat it
   as single, monolithic node for the purposes of overload management.

   These scenarios do not illustrate the client application.  As
   mentioned in Section 1, Diameter is not typically an end-user
   protocol; rather it is generally used in support of some other client
   application.  These scenarios do not consider the impact of Diameter
   overload on the client application.

2.1.  Peer to Peer Scenarios

   This section describes Diameter peer-to-peer scenarios.  That is,
   scenarios where a Diameter client talks directly with a Diameter
   server, without the use of a Diameter agent.

   Figure 1 illustrates the simplest possible Diameter relationship.
   The client and server share a one-to-one peer-to-peer relationship.
   If the server becomes overloaded, either because the client exceeds
   the server's capacity, or because the server's capacity is reduced
   due to some resource dependency, the client needs to reduce the
   amount of Diameter traffic it sends to the server.  Since the client
   cannot forward requests to another server, it must either queue
   requests until the server recovers, or itself become overloaded in
   the context of the client application and other protocols it may also
   use.

                         +------------------+
                         |                  |
                         |                  |
                         |     Server       |
                         |                  |
                         +--------+---------+
                                  |
                                  |
                         +--------+---------+
                         |                  |
                         |                  |
                         |     Client       |
                         |                  |
                         +------------------+

                   Figure 1: Basic Peer to Peer Scenario
   Figure 2 shows a similar scenario, except in this case the client has
   multiple servers that can handle work for a specific realm and
   application.  If server 1 becomes overloaded, the client can forward
   traffic to server 2.  Assuming server 2 has sufficient reserve
   capacity to handle the forwarded traffic, the client should be able
   to continue serving client application protocol users.  If server 1
   is approaching overload, but can still handle some number of new
   request, it needs to be able to instruct the client to forward a
   subset of its traffic to server 2.

           +------------------+     +------------------+
           |                  |     |                  |
           |                  |     |                  |
           |     Server 1     |     |     Server 2     |
           |                  |     |                  |
           +--------+-`.------+     +------.'+---------+
                        `.               .'
                          `.           .'
                            `.       .'
                              `.   .'
                        +-------`.'--------+
                        |                  |
                        |                  |
                        |     Client       |
                        |                  |
                        +------------------+

              Figure 2: Multiple Server Peer to Peer Scenario

   Figure 3 illustrates a peer-to-peer scenario with multiple Diameter
   realm and application combinations.  In this example, server 2 can
   handle work for both applications.  Each application might have
   different resource dependencies.  For example, a server might need to
   access one database for application A, and another for application B.
   This creates a possibility that Server 2 could become overloaded for
   application A but not for application B, in which case the client
   would need to divert some part of its application A requests to
   server 1, but should not divert any application B requests.  This
   requires server 2 to be able to distinguish between applications when
   it indicates an overload condition to the client.

   On the other hand, it's possible that the servers host many
   applications.  If server 2 becomes overloaded for all applications,
   it would be undesirable for it to have to notify the client
   separately for each application.  Therefore it also needs a way to
   indicate that it is overloaded for all possible applications.

   +---------------------------------------------+
   | Application A       +----------------------+----------------------+
   |+------------------+ |  +----------------+  |  +------------------+|
   ||                  | |  |                |  |  |                  ||
   ||                  | |  |                |  |  |                  ||
   ||     Server 1     | |  |    Server 2    |  |  |     Server 3     ||
   ||                  | |  |                |  |  |                  ||
   |+--------+---------+ |  +-------+--------+  |  +-+----------------+|
   |         |           |          |           |    |                 |
   +---------+-----------+----------+-----------+    |                 |
             |           |          |                |                 |
             |           |          |                |  Application B  |
             |           +----------+----------------+-----------------+
             ``-.._                 |                |
                   `-..__           |            _.-''
                        `--._       |        _.-''
                             ``-._  |   _.-''
                            +-----`-.-''-----+
                            |                |
                            |                |
                            |     Client     |
                            |                |
                            +----------------+

           Figure 3: Multiple Application Peer to Peer Scenario

2.2.  Agent Scenarios

   This section describes scenarios that include a Diameter agent,
   either in the form of a Diameter relay or Diameter proxy.  These
   scenarios do not consider Diameter redirect agents, since they are
   more readily modeled as end-servers.

   Figure 4 illustrates a simple Diameter agent scenario with a single
   client, agent, and server.  In this case, overload can occur at the
   server, at the agent, or both.  But in most cases, client behavior is
   the same whether overload occurs at the server or at the agent.  From
   the client's perspective, server overload and agent overload is the
   same thing.

                       +------------------+
                       |                  |
                       |                  |
                       |     Server       |
                       |                  |
                       +--------+---------+
                                |
                                |
                       +--------+---------+
                       |                  |
                       |                  |
                       |      Agent       |
                       |                  |
                       +--------+---------+
                                |
                                |
                       +--------+---------+
                       |                  |
                       |                  |
                       |     Client       |
                       |                  |
                       +------------------+

                      Figure 4: Basic Agent Scenario

   Figure 5 shows an agent scenario with multiple servers.  If server 1
   becomes overloaded, but server 2 has sufficient reserve capacity, the
   agent may be able to transparently divert some or all Diameter
   requests originally bound for server 1 to server 2.

   In most cases, the client does not have detailed knowledge of the
   Diameter topology upstream of the agent.  If the agent uses dynamic
   discovery to find eligible servers, the set of eligible servers may
   not be enumerable from the perspective of the client.  Therefore, in
   most cases the agent needs to deal with any upstream overload issues
   in a way that is transparent to the client.  If one server notifies
   the agent that it has become overloaded, the notification should not
   be passed back to the client in a way that the client could
   mistakenly perceive the agent itself as being overloaded.  If the set
   of all possible destinations upstream of the agent no longer has
   sufficient capacity for incoming load, the agent itself becomes
   effectively overloaded.

   On the other hand, there are cases where the client needs to be able
   to select a particular server from behind an agent.  For example, if
   a Diameter request is part of a multiple-round-trip authentication,
   or is otherwise part of a Diameter "session", it may have a
   DestinationHost AVP that requires the request to be served by server
   1.  Therefore the agent may need to inform a client that a particular
   upstream server is overloaded or otherwise unavailable.  Note that
   there can be many ways a server can be specified, which may have
   different implications (e.g. by IP address, by host name, etc).

           +------------------+     +------------------+
           |                  |     |                  |
           |                  |     |                  |
           |     Server 1     |     |     Server 2     |
           |                  |     |                  |
           +--------+-`.------+     +------.'+---------+
                        `.               .'
                         `.           .'
                            `.       .'
                              `.   .'
                        +-------`.'--------+
                        |                  |
                        |                  |
                        |     Agent        |
                        |                  |
                        +--------+---------+
                                 |
                                 |
                                 |
                        +--------+---------+
                        |                  |
                        |                  |
                        |     Client       |
                        |                  |
                        +------------------+

                 Figure 5: Multiple Server Agent Scenario

   Figure 6 shows a scenario where an agent routes requests to a set of
   servers for more than one Diameter realm and application.  In this
   scenario, if server 1 becomes overloaded or unavailable while server
   2 still has available capacity, the agent may effectively operate at
   reduced capacity for application A, but at full capacity for
   application B. Therefore, the agent needs to be able to report that
   it is overloaded for one application, but not for another.

   +--------------------------------------------+
   | Application A       +----------------------+----------------------+
   |+------------------+ |  +----------------+  |  +------------------+|
   ||                  | |  |                |  |  |                  ||
   ||                  | |  |                |  |  |                  ||
   ||     Server 1     | |  |    Server 2    |  |  |     Server 3     ||
   ||                  | |  |                |  |  |                  ||
   |+---------+--------+ |  +-------+--------+  |  +--+---------------+|
   |          |          |          |           |     |                |
   +----------+----------+----------+-----------+     |                |
              |          |          |                 |                |
              |          |          |                 | Application B  |
              |          +----------+-----------------+----------------+
              |                     |                 |
               ``--.__              |                _.
                      ``-.__        |          __.--''
                            `--.._  |    _..--'
                            +----``-+.''-----+
                            |                |
                            |                |
                            |    Agent       |
                            |                |
                            +-------+--------+
                                    |
                                    |
                            +-------+--------+
                            |                |
                            |                |
                            |    Client      |
                            |                |
                            +----------------+

               Figure 6: Multiple Application Agent Scenario

2.3.  Interconnect Scenario

   Another scenario to consider when looking at Diameter overload is
   that of multiple network operators using Diameter components
   connected through an interconnect service, e.g. using IPX.  IPX (IP
   eXchange) [IR.34] is an Inter-Operator IP Backbone that provides
   roaming interconnection network between mobile operators and service
   providers.  The IPX is also used to transport Diameter signaling
   between operators [IR.88].  Figure 7 shows two network operators with
   an interconnect network in-between.  There could be any number of
   these networks between any two network operator's networks.

               +-------------------------------------------+
               |               Interconnect                |
               |                                           |
               |   +--------------+      +--------------+  |
               |   |   Server 3   |------|   Server 4   |  |
               |   +--------------+      +--------------+  |
               |         .'                      `.        |
               +------.-'--------------------------`.------+
                    .'                               `.
                 .-'                                   `.
   ------------.'-----+                             +----`.-------------
         +----------+ |                             | +----------+
         | Server 1 | |                             | | Server 2 |
         +----------+ |                             | +----------+
                      |                             |
   Network Operator 1 |                             | Network Operator 2
   -------------------+                             +-------------------

                Figure 7: Two Network Interconnect Scenario

   The characteristics of the information that an operator would want to
   share over such a connection are different from the information
   shared between components within a network operator's network.
   Network operators may not want to convey topology or operational
   information, which limits how much overload and loading information
   can be sent.  For the interconnect scenario shown, Server 2 may want
   to signal overload to Server 1, to affect traffic coming from Network
   Operator 1.

   This case is distinct from those internal to a network operator's
   network, where there may be many more elements in a more complicated
   topology.  Also, the elements in the interconnect network may not
   support Diameter overload control, and the network operators may not
   want the interconnect network to use overload or loading information.
   They may only want the information to pass through the interconnect
   network without further processing or action by the interconnect
   network even if the elements in the interconnect network do support
   Diameter overload control.

3.  Diameter Overload Case Studies

3.1.  Overload in Mobile Data Networks

   As the number of Third Generation (3G) and Long Term Evolution (LTE)
   enabled smartphone devices continue to expand in mobile networks,
   there have been situations where high signaling traffic load led to
   overload events at the Diameter-based Home Location Registries (HLR)
   and/or Home Subscriber Servers (HSS) [TR23.843].  The root causes of
   the HLR congestion events were manifold but included hardware failure
   and procedural errors.  The result was high signaling traffic load on
   the HLR and HSS.

   The 3GPP architecture [TS23.002] makes extensive use of Diameter.  It
   is used for mobility management [TS29.272] (and others), (IP
   Multimedia Subsystem) IMS [TS29.228] (and others), policy and
   charging control [TS29.212] (and others) as well as other functions.
   The details of the architecture are out of scope for this document,
   but it is worth noting that there are quite a few Diameter
   applications, some with quite large amounts of Diameter signaling in
   deployed networks.

   The 3GPP specifications do not currently address overload for
   Diameter applications or provide an equivalent load control mechanism
   to those provided in the more traditional SS7 elements in (Global
   System for Mobile Communications) GSM [TS29.002].  The capabilities
   specified in the 3GPP standards do not adequately address the
   abnormal condition where excessively high signaling traffic load
   situations are experienced.

   Smartphones, an increasingly large percentage of mobile devices,
   contribute much more heavily, relative to non-smartphones, to the
   continuation of a registration surge due to their very aggressive
   registration algorithms.  Smartphone behavior contributes to network
   loading and can contribute to overload conditions.  The aggressive
   smartphone logic is designed to:

   a.  always have voice and data registration, and

   b.  constantly try to be on 3G or LTE data (and thus on 3G voice or
       VoLTE [IR.92]) for their added benefits.

   Non-smartphones typically have logic to wait for a time period after
   registering successfully on voice and data.

   The smartphone aggressive registration is problematic in two ways:

   o  first by generating excessive signaling load towards the HSS that
      is ten times that from a non-smartphone,

   o  and second by causing continual registration attempts when a
      network failure affects registrations through the 3G data network.

3.2.  3GPP Study on Core Network Overload

   A study in 3GPP SA2 on core network overload has produced the
   technical report [TR23.843].  This enumerates several causes of
   overload in mobile core networks including portions that are signaled
   using Diameter.  This document  TR23.843 is a work in progress and is not complete.
   However, it is useful for pointing out scenarios and the general need
   for an overload control mechanism for Diameter.

   It is common for mobile networks to employ more than one radio
   technology and to do so in an overlay fashion with multiple
   technologies present in the same location (such as 2nd or 3rd
   generation mobile technologies along with LTE).  This presents
   opportunities for traffic storms when issues occur on one overlay and
   not another as all devices that had been on the overlay with issues
   switch.  This causes a large amount of Diameter traffic as locations
   and policies are updated.

   Another scenario called out by this study is a flood of registration
   and mobility management events caused by some element in the core
   network failing.  This flood of traffic from end nodes falls under
   the network initiated traffic flood category.  There is likely to
   also be traffic resulting directly from the component failure in this
   case.  A similar flood can occur when elements or components recover
   as well.

   Subscriber initiated traffic floods are also indicated in this study
   as an overload mechanism where a large number of mobile devices
   attempting to access services at the same time, such as in response
   to an entertainment event or a catastrophic event.

   While this 3GPP study is concerned with the broader effects of these
   scenarios on wireless networks and their elements, they have
   implications specifically for Diameter signaling.  One of the goals
   of this document is to provide guidance for a core mechanism that can
   be used to mitigate the scenarios called out by this study.

4.  Existing Mechanisms

   Diameter offers both implicit and explicit mechanisms for a Diameter
   node to learn that a peer is overloaded or unreachable.  The implicit
   mechanism is simply the lack of responses to requests.  If a client
   fails to receive a response in a certain time period, it assumes the
   upstream peer is unavailable, or overloaded to the point of effective
   unavailability.  The watchdog mechanism [RFC3539] ensures that a
   certain rate of transaction responses occur even when there is
   otherwise little or no other Diameter traffic.

   The explicit mechanism can involve specific protocol error responses,
   where an agent or server tells a downstream peer that it is either
   too busy to handle a request (DIAMETER_TOO_BUSY) or unable to route a
   request to an upstream destination (DIAMETER_UNABLE_TO_DELIVER),
   perhaps because that destination itself is overloaded to the point of
   unavailability.

   Another explicit mechanism, a DPR (Disconnect-Peer-Request) message,
   can be sent with a Disconnect-Cause of BUSY.  This signals the
   sender's intent to close the transport connection, and requests the
   client not to reconnect.

   Once a Diameter node learns that an upstream peer has become
   overloaded via one of these mechanisms, it can then attempt to take
   action to reduce the load.  This usually means forwarding traffic to
   an alternate destination, if available.  If no alternate destination
   is available, the node must either reduce the number of messages it
   originates (in the case of a client) or inform the client to reduce
   traffic (in the case of an agent.)

   Diameter requires the use of a congestion-managed transport layer,
   currently TCP or SCTP, to mitigate network congestion.  It is
   expected that these transports manage network congestion and that
   issues with transport (e.g. congestion propagation and window
   management) are managed at that level.  But even with a congestion-
   managed transport, a Diameter node can become overloaded at the
   Diameter protocol or application layers due to the causes described
   in Section 1.2 and congestion managed transports do not provide
   facilities (and are at the wrong level) to handle server overload.
   Transport level congestion management is also not sufficient to
   address overload in cases of multi-hop and multi-destination
   signaling.

5.  Issues with the Current Mechanisms

   The currently available Diameter mechanisms for indicating an
   overload condition are not adequate to avoid service outages due to
   overload.  This inadequacy may, in turn, contribute to broader
   congestion collapse impacts due to unresponsive Diameter nodes causing
   application or transport layer retransmissions.  In particular, they
   do not allow a Diameter agent or server to shed load as it approaches
   overload.  At best, a node can only indicate that it needs to
   entirely stop receiving requests, i.e. that it has effectively
   failed.  Even that is problematic due to the inability to indicate
   durational validity on the transient errors available in the base
   Diameter protocol.  Diameter offers no mechanism to allow a node to
   indicate different overload states for different categories of
   messages, for example, if it is overloaded for one Diameter
   application but not another.

5.1.  Problems with Implicit Mechanism

   The implicit mechanism doesn't allow an agent or server to inform the
   client of a problem until it is effectively too late to do anything
   about it.  The client does not know to take action until the upstream
   node has effectively failed.  A Diameter node has no opportunity to
   shed load early to avoid collapse in the first place.

   Additionally, the implicit mechanism cannot distinguish between
   overload of a Diameter node and network congestion.  Diameter treats
   the failure to receive an answer as a transport failure.

5.2.  Problems with Explicit Mechanisms

   The Diameter specification is ambiguous on how a client should handle
   receipt of a DIAMETER_TOO_BUSY response.  The base specification
   [RFC6733] indicates that the sending client should attempt to send
   the request to a different peer.  It makes no suggestion that the
   receipt of a DIAMETER_TOO_BUSY response should affect future Diameter
   messages in any way.

   The Authentication, Authorization, and Accounting (AAA) Transport
   Profile [RFC3539] recommends that a AAA node that receives a "Busy"
   response failover all remaining requests to a different agent or
   server.  But while the Diameter base specification explicitly depends
   on RFC3539 to define transport behavior, it does not refer to RFC3539
   in the description of behavior on receipt of DIAMETER_TOO_BUSY.
   There's a strong likelihood that at least some implementations will
   continue to send Diameter requests to an upstream peer even after
   receiving a DIAMETER_TOO_BUSY error.

   BCP 41 [RFC2914] describes, among other things, how end-to-end
   application behavior can help avoid congestion collapse.  In
   particular, an application should avoid sending messages that will
   never be delivered or processed.  The DIAMETER_TOO_BUSY behavior as
   described in the Diameter base specification fails at this, since if
   an upstream node becomes overloaded, a client attempts each request,
   and does not discover the need to failover the request until the
   initial attempt fails.

   The situation is improved if implementations follow the [RFC3539]
   recommendation and keep state about upstream peer overload.  But even
   then, the Diameter specification offers no guidance on how long a
   client should wait before retrying the overloaded destination.  If an
   agent or server supports multiple realms and/or applications,
   DIAMETER_TOO_BUSY offers no way to indicate that it is overloaded for
   one application but not another.  A DIAMETER_TOO_BUSY error can only
   indicate overload at a "whole server" scope.

   Agent processing of a DIAMETER_TOO_BUSY response is also problematic
   as described in the base specification.  DIAMETER_TOO_BUSY is defined
   as a protocol error.  If an agent receives a protocol error, it may
   either handle it locally or it may forward the response back towards
   the downstream peer.  If a downstream peer receives the
   DIAMETER_TOO_BUSY response, it may stop sending all requests to the
   agent for some period of time, even though the agent may still be
   able to deliver requests to other upstream peers.

   DIAMETER_UNABLE_TO_DELIVER, or using DPR with cause code BUSY also
   have no mechanisms for specifying the scope or cause of the failure,
   or the durational validity.

   The issues with error responses in [RFC6733] extend beyond the
   particular issues for overload control and have been addressed in an
   ad hoc fashion by various implementations.  Addressing these in a
   standard way would be a useful exercise, but it us beyond the scope
   of this document.

6.  Extensibility and Application Independence

   Given the variety of scenarios Diameter elements can be deployed in,
   and the variety of roles they can fulfill with Diameter and other
   technologies, a single algorithm for handling overload may not be
   sufficient.  For purposes of this discussion, algorithm is inclusive
   of behavior for control of overload, but does not encompass the
   general mechanism or transport of control information.  This effort
   cannot anticipate all possible future scenarios and roles.
   Extensibility, particularly of algorithms used to deal with overload,
   will be important to cover these cases.

   Similarly, the scopes that overload information may apply to may
   include cases that have not yet been considered.  Extensibility in
   this area will also be important.

   The basic mechanism is intended to be application-independent, that
   is, a Diameter node can use it across any existing and future
   Diameter applications and expect reasonable results.  Certain
   Diameter applications might, however, benefit from application-
   specific behavior over and above the mechanism's defaults.  For
   example, an application specification might specify relative
   priorities of messages or selection of a specific overload control
   algorithm.

7.  Solution Requirements

   This section proposes requirements for an improved mechanism to
   control Diameter overload, with the goals of improving the issues
   described in Section 5 and supporting the scenarios described in
   Section 2 2.  These requirements are stated primarily in terms of
   individual node behavior to inform the design of the improved
   mechanism; solution designers should keep in mind that the overall
   goal is improved overall system behavior across all the nodes
   involved, not just improved behavior from specific individual nodes.

7.1.  General

   REQ 1:  The solution MUST provide a communication method for Diameter
           nodes to exchange load and overload information.

   REQ 2:  The solution MUST allow Diameter nodes to support overload
           control regardless of which Diameter applications they
           support.  Diameter clients and agents must be able to use the
           received load and overload information to support graceful
           behavior during an overload condition.  Graceful behavior
           under overload conditions is best described by REQ 3.

   REQ 3:  The solution MUST limit the impact of overload on the overall
           useful throughput of a Diameter server, even when the
           incoming load on the network is far in excess of its
           capacity.  The overall useful throughput under load is the
           ultimate measure of the value of a solution.

   REQ 4:  Diameter allows requests to be sent from either side of a
           connection and either side of a connection may have need to
           provide its overload status.  The solution MUST allow each
           side of a connection to independently inform the other of its
           overload status.

   REQ 5:  Diameter allows nodes to determine their peers via dynamic
           discovery or manual configuration.  The solution MUST work
           consistently without regard to how peers are determined.

   REQ 6:  The solution designers SHOULD seek to minimize the amount of
           new configuration required in order to work.  For example, it
           is better to allow peers to advertise or negotiate support
           for the solution, rather than to require this knowledge to be
           configured at each node.

7.2.  Performance

   REQ 7:   The solution and any associated default algorithm(s) MUST
            ensure that the system remains stable.  At some point after
            an overload condition has ended, the solution MUST enable
            capacity to stabilize and become equal to what it would be
            in the absence of an overload condition.  Note that this
            also requires that the solution MUST allow nodes to shed
            load without introducing non converging oscillations during
            or after an overload condition.

   REQ 8:   Supporting nodes MUST be able to distinguish current
            overload information from stale information.

   REQ 9:   The solution MUST function across fully loaded as well as
            quiescent transport connections.  This is partially derived
            from the requirement for stability in REQ 7.

   REQ 10:  Consumers of overload information MUST be able to determine
            when the overload condition improves or ends.

   REQ 11:  The solution MUST be able to operate in networks of
            different sizes.

   REQ 12:  When a single network node fails, goes into overload, or
            suffers from reduced processing capacity, the solution MUST
            make it possible to limit the impact of this on other nodes
            in the network.  This helps to prevent a small-scale failure
            from becoming a widespread outage.

   REQ 13:  The solution MUST NOT introduce substantial additional work
            for node in an overloaded state.  For example, a requirement
            for an overloaded node to send overload information every
            time it received a new request would introduce substantial
            work.  Existing messaging is likely to have the
            characteristic of increasing as an overload condition
            approaches, allowing for the possibility of increased
            feedback for information piggybacked on it.

   REQ 14:  Some scenarios that result in overload involve a rapid
            increase of traffic with little time between normal levels
            and overload inducing levels.  The solution SHOULD provide
            for rapid feedback when traffic levels increase.

   REQ 15:  The solution MUST NOT interfere with the congestion control
            mechanisms of underlying transport protocols.  For example,
            a solution that opened additional TCP connections when the
            network is congested would reduce the effectiveness of the
            underlying congestion control mechanisms.

7.3.  Heterogeneous Support for Solution

   REQ 16:  The solution is likely to be deployed incrementally.  The
            solution MUST support a mixed environment where some, but
            not all, nodes implement it.

   REQ 17:  In a mixed environment with nodes that support the solution
            and that do not, the solution MUST NOT result in materially
            less useful throughput as would have resulted if the
            solution were not present.  It SHOULD result in less severe
            congestion in this environment.

   REQ 18:  In a mixed environment of nodes that support the solution
            and that do not, the solution MUST NOT preclude elements
            that support overload control from treating elements that do
            not support overload control in a equitable fashion relative
            to those that do.  Users and operators of nodes that do not
            support the solution MUST NOT unfairly benefit from the
            solution.  The solution specification SHOULD provide
            guidance to implementors for dealing with elements not
            supporting overload control.

   REQ 19:  It MUST be possible to use the solution between nodes in
            different realms and in different administrative domains.

   REQ 20:  Any explicit overload indication MUST be clearly
            distinguishable from other errors reported via Diameter.

   REQ 21:  In cases where a network node fails, is so overloaded that
            it cannot process messages, or cannot communicate due to a
            network failure, it may not be able to provide explicit
            indications of the nature of the failure or its levels of
            congestion.  The solution MUST result in at least as much
            useful throughput as would have resulted if the solution was
            not in place.

7.4.  Granular Control
   REQ 22:  The solution MUST provide a way for a node to throttle the
            amount of traffic it receives from a peer node.  This
            throttling SHOULD be graded so that it can be applied
            gradually as offered load increases.  Overload is not a
            binary state; there may be degrees of overload.

   REQ 23:  The solution MUST provide sufficient information to enable a
            load balancing node to divert messages that are rejected or
            otherwise throttled by an overloaded upstream node to other
            upstream nodes that are the most likely to have sufficient
            capacity to process them.

   REQ 24:  The solution MUST provide a mechanism for indicating load
            levels even when not in an overloaded condition, to assist
            nodes making decisions to prevent overload conditions from
            occurring.

7.5.  Priority and Policy

   REQ 25:  The base specification for the solution SHOULD offer general
            guidance on which message types might be desirable to send
            or process over others during times of overload, based on
            application-specific considerations.  For example, it may be
            more beneficial to process messages for existing sessions
            ahead of new sessions.  Some networks may have a requirement
            to give priority to requests associated with emergency
            sessions.  Any normative or otherwise detailed definition of
            the relative priorities of message types during an overload
            condition will be the responsibility of the application
            specification.

   REQ 26:  The solution MUST NOT prevent a node from prioritizing
            requests based on any local policy, so that certain requests
            are given preferential treatment, given additional
            retransmission, not throttled, or processed ahead of others.

7.6.  Security

   REQ 27:  The solution MUST NOT provide new vulnerabilities to
            malicious attack, or increase the severity of any existing
            vulnerabilities.  This includes vulnerabilities to DoS and
            DDoS attacks as well as replay and man-in-the middle
            attacks.  Note that the Diameter base specification
            [RFC6733] lacks end to end security and this must be
            considered.  Note that this requirement was expressed at a
            high level so as to not preclude any particular solution.

            Is is expected that the solution will address this in more
            detail.

   REQ 28:  The solution MUST NOT depend on being deployed in
            environments where all Diameter nodes are completely
            trusted.  It SHOULD operate as effectively as possible in
            environments where other nodes are malicious; this includes
            preventing malicious nodes from obtaining more than a fair
            share of service.  Note that this does not imply any
            responsibility on the solution to detect, or take
            countermeasures against, malicious nodes.

   REQ 29:  It MUST be possible for a supporting node to make
            authorization decisions about what information will be sent
            to peer nodes based on the identity of those nodes.  This
            allows a domain administrator who considers the load of
            their nodes to be sensitive information to restrict access
            to that information.  Of course, in such cases, there is no
            expectation that the solution itself will help prevent
            overload from that peer node.

   REQ 30:  The solution MUST NOT interfere with any Diameter compliant
            method that a node may use to protect itself from overload
            from non-supporting nodes, or from denial of service
            attacks.

7.7.  Flexibility and Extensibility

   REQ 31:  There are multiple situations where a Diameter node may be
            overloaded for some purposes but not others.  For example,
            this can happen to an agent or server that supports multiple
            applications, or when a server depends on multiple external
            resources, some of which may become overloaded while others
            are fully available.  The solution MUST allow Diameter nodes
            to indicate overload with sufficient granularity to allow
            clients to take action based on the overloaded resources
            without unreasonably forcing available capacity to go
            unused.  The solution MUST support specification of overload
            information with granularities of at least "Diameter node",
            "realm", and "Diameter application", and MUST allow
            extensibility for others to be added in the future.

   REQ 32:  The solution MUST provide a method for extending the
            information communicated and the algorithms used for
            overload control.

   REQ 33:  The solution MUST provide a default algorithm that is
            mandatory to implement.

   REQ 34:  The solution SHOULD provide a method for exchanging overload
            and load information between elements that are connected by
            intermediaries that do not support the solution.

8.  IANA Considerations

   This document makes no requests of IANA.

9.  Security Considerations

   A Diameter overload control mechanism is primarily concerned with the
   load and overload related behavior of nodes in a Diameter network,
   and the information used to affect that behavior.  Load and overload
   information is shared between nodes and directly affects the behavior
   and thus is potentially vulnerable to a number of methods of attack.

   Load and overload information may also be sensitive from both
   business and network protection viewpoints.  Operators of Diameter
   equipment want to control visibility to load and overload information
   to keep it from being used for competitive intelligence or for
   targeting attacks.  It is also important that the Diameter overload
   control mechanism not introduce any way in which any other
   information carried by Diameter is sent inappropriately.

   Note that the Diameter base specification [RFC6733] lacks end to end
   security, making verifying the authenticity and ownership of load and
   overload information difficult for non-adjacent nodes.
   Authentication of load and overload information helps to alleviate
   several of the security issues listed in this section.

   This document includes requirements intended to mitigate the effects
   of attacks and to protect the information used by the mechanism.
   This section discusses potential security considerations for overload
   control solutions.  This discussion provides the motivation for
   several normative requirements described in Section 7.  The
   discussion includes specific references to the normative requirements
   that apply for each issue.

9.1.  Access Control

   To control the visibility of load and overload information, sending
   should be subject to some form of authentication and authorization of
   the receiver.  It is also important to the receivers that they are
   confident the load and overload information they receive is from a
   legitimate source.  REQ 28 requires the solution to work without
   assuming that all Diameter nodes in a network are trusted for the
   purposes of exchanging overload and load information.  REQ 29
   requires the solution to let nodes restrict unauthorized parties from
   seeing overload information.  Note that this implies a certain amount
   of configurability on the nodes supporting the Diameter overload
   control mechanism.

9.2.  Denial-of-Service Attacks

   An overload control mechanism provides a very attractive target for
   denial-of-service attacks.  A small number of messages may affect a
   large service disruption by falsely reporting overload conditions.
   Alternately, attacking servers nearing, or in, overload may also be
   facilitated by disrupting their overload indications, potentially
   preventing them from mitigating their overload condition.

   A design goal for the Diameter overload control mechanism is to
   minimize or eliminate the possibility of using the mechanism for this
   type of attack.  More strongly, REQ 27 forbids the solution from
   introducing new vulnerabilities to malicious attack.  Additionally,
   REQ 30 stipulates that the solution not interfere with other
   mechanisms used for protection against denial of service attacks.

   As the intent of some denial-of-service attacks is to induce overload
   conditions, an effective overload control mechanism should help to
   mitigate the effects of an such an attack.

9.3.  Replay Attacks

   An attacker that has managed to obtain some messages from the
   overload control mechanism may attempt to affect the behavior of
   nodes supporting the mechanism by sending those messages at
   potentially inopportune times.  In addition to time shifting, replay
   attacks may send messages to other nodes as well (target shifting).

   A design goal for the Diameter overload control solution is to
   minimize or eliminate the possibility of causing disruption by using
   a replay attack on the Diameter overload control mechanism.
   (Allowing a replay attack using the overload control solution would
   violate REQ 27.)

9.4.  Man-in-the-Middle Attacks

   By inserting themselves in between two nodes supporting the Diameter
   overload control mechanism, an attacker may potentially both access
   and alter the information sent between those nodes.  This can be used
   for information gathering for business intelligence and attack
   targeting, as well as direct attacks.

   REQs 27, 28, and 29 imply a need to prevent man-in-the-middle attacks
   on the overload control solution.  A transport using TLS and/or IPSEC
   may be desirable for this purpose.

9.5.  Compromised Hosts

   A compromised host that supports the Diameter overload control
   mechanism could be used for information gathering as well as for
   sending malicious information to any Diameter node that would
   normally accept information from it.  While is is beyond the scope of
   the Diameter overload control mechanism to mitigate any operational
   interruption to the compromised host, REQs 28 and 29 imply a need to
   minimize the impact that a compromised host can have on other nodes
   through the use of the Diameter overload control mechanism.  Of
   course, a compromised host could be used to cause damage in a number
   of other ways.  This is out of scope for a Diameter overload control
   mechanism.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC6733]  Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
              "Diameter Base Protocol", RFC 6733, October 2012.

   [RFC2914]  Floyd, S., "Congestion Control Principles", BCP 41,
              RFC 2914, September 2000.

   [RFC3539]  Aboba, B. and J. Wood, "Authentication, Authorization and
              Accounting (AAA) Transport Profile", RFC 3539, June 2003.

10.2.  Informative References

   [RFC5390]  Rosenberg, J., "Requirements for Management of Overload in
              the Session Initiation Protocol", RFC 5390, December 2008.

   [RFC6357]  Hilt, V., Noel, E., Shen, C., and A. Abdelal, "Design
              Considerations for Session Initiation Protocol (SIP)
              Overload Control", RFC 6357, August 2011.

   [TR23.843]
              3GPP, "Study on Core Network Overload Solutions", Solutions (Work in
              Progress)", TR 23.843 0.6.0, October 2012.

   [IR.34]    GSMA, "Inter-Service Provider IP Backbone Guidelines",
              IR 34 7.0, January 2012.

   [IR.88]    GSMA, "LTE Roaming Guidelines", IR 88 7.0, January 2012.

   [IR.92]    GSMA, "IMS Profile for Voice and SMS", IR 92 7.0,
              March 2013.

   [TS23.002]
              3GPP, "Network Architecture", TS 23.002 12.0.0,
              September 2012.

   [TS29.272]
              3GPP, "Evolved Packet System (EPS); Mobility Management
              Entity (MME) and Serving GPRS Support Node (SGSN) related
              interfaces based on Diameter protocol", TS 29.272 11.4.0,
              September 2012.

   [TS29.212]
              3GPP, "Policy and Charging Control (PCC) over Gx/Sd
              reference point", TS 29.212 11.6.0, September 2012.

   [TS29.228]
              3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces;
              Signalling flows and message contents", TS 29.228 11.5.0,
              September 2012.

   [TS29.002]
              3GPP, "Mobile Application Part (MAP) specification",
              TS 29.002 11.4.0, September 2012.

Appendix A.  Contributors

   Significant contributions to this document were made by Adam Roach
   and Eric Noel.

Appendix B.  Acknowledgements

   Review of, and contributions to, this specification by Martin Dolly,
   Carolyn Johnson, Jianrong Wang, Imtiaz Shaikh, Jouni Korhonen, Robert
   Sparks, Dieter Jacobsohn, Janet Gunn, Jean-Jacques Trottin, Laurent
   Thiebaut, Andrew Booth, and Lionel Morand were most appreciated.  We
   would like to thank them for their time and expertise.

Authors' Addresses

   Eric McMurry
   Tekelec
   17210 Campbell Rd.
   Suite 250
   Dallas, TX  75252
   US

   Email: emcmurry@computer.org

   Ben Campbell
   Tekelec
   17210 Campbell Rd.
   Suite 250
   Dallas, TX  75252
   US

   Email: ben@nostrum.com
--Apple-Mail=_9751E1EA-A0C0-4DD4-AABB-D89C9EE33CD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks! Eric On Aug 24, 2013, at 1:52 , Jouni Korhonen = wrote: >=20 > Authors, >=20 > The changes needed look rather straight forward and we also seem to = have=20 > consensus among reviewers. Go ahead and submit a revised version as = soon > as possible for you. You may, if you wish, circulate a diff before the > submission among us but that is IMHO not really needed. >=20 >=20 > - Jouni >=20 >=20 > On Aug 23, 2013, at 12:09 AM, Eric McMurry = wrote: >=20 >> works for me. We'll change that and dereference the abstract in the = next version, pending instructions from the shepherd. >>=20 >> Thanks! >>=20 >> Eric >>=20 >>=20 >> On Aug 22, 2013, at 16:08 , "Vijay K. Gurbani" = wrote: >>=20 >>> On 08/22/2013 03:45 PM, Eric McMurry wrote: >>>>> Nits: >>>>> =3D=3D=3D=3D=3D >>>>> - S3.2, first paragraph: "This document is a work in progress...", >>>>> here, "This" refers to TR23.843 or does it refer to dime-overload- >>>>> reqs-10? Please clarify. On further reading, there are more >>>>> "this document" spread in the subsection with providing an = adequate >>>>> text that qualifies the "this". >>>>=20 >>>> we can clear this this up. that should not be a problem :-) >>>>=20 >>>> more specifically, for the first paragraph of 3.2, how about >>>> changing "this document" to "this technical report". >>>=20 >>> Eric: Better yet, why not simply change it to TR23.843? >>>=20 >>>> We searched through the rest of the draft and all of the other >>>> instances of "this document" refer to the draft itself. Is that = more >>>> clear when the instance in the first paragraph is addressed? >>>=20 >>> Yes, that should be fine. >>>=20 >>> Thanks for your attention to my comments. >>>=20 >>> - vijay >>> --=20 >>> 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 >>=20 >=20 --Apple-Mail=_9751E1EA-A0C0-4DD4-AABB-D89C9EE33CD2-- From angel@16bits.net Mon Aug 26 14:11: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 43D1D11E8249; Mon, 26 Aug 2013 14:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 1VER23mIuoYa; Mon, 26 Aug 2013 14:11:36 -0700 (PDT) Received: from mailer.hiddenmail.net (mailer.hiddenmail.net [199.195.249.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD1611E824A; Mon, 26 Aug 2013 14:11:36 -0700 (PDT) Received: from mailer by mailer.hiddenmail.net with local (Exim 4.80) (envelope-from ) id 1VE44K-0007v2-06; Mon, 26 Aug 2013 23:11:26 +0200 Message-ID: <1377551823.905.7.camel@localhost.localdomain> From: =?ISO-8859-1?Q?=C1ngel?= To: Hector Santos Date: Mon, 26 Aug 2013 23:17:03 +0200 In-Reply-To: <521B502D.5010106@isdg.net> References: <521A1F31.8080402@cisco.com> <521B502D.5010106@isdg.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.8.5 Mime-Version: 1.0 X-Mailman-Approved-At: Tue, 27 Aug 2013 10:48:42 -0700 Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, 'IESG' , Apps Discuss Subject: Re: [apps-discuss] [spfbis] Applications Directorate Review of draft-ietf-spfbis-4408bis-19.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, 26 Aug 2013 21:11:41 -0000 Hector Santos wrote: > I think the documentation usage of the term "SPF record" can be=20 > confusing if the type99 is going to be removed. It can suggest that=20 > this "SPF record" is unique and is not residing with other "records." >=20 > I think the term should be more specific to say the SPF TXT resultant=20 > record contains multiple EOL (CRLF or CR or LF terminators) strings=20 > and and only a string beginning with the *token* "v=3Dspf1" is a=20 > considered a SPF record string. In theory, the parser should=20 > tokenizing it to check for "v=3D" and then only process the v=3D value "s= pf1" >=20 > Perhaps a more specific term such as "SPF Line Record" or String would= =20 > be clearer. However, there could be one TXT record with embedded line breaks. I don't think a spf parser should try to extract that. From ioseb.dzmanashvili@gmail.com Tue Aug 27 12:40: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 6FDB121F9EDB; Tue, 27 Aug 2013 12:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_92=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 qFyZLvf6BA-I; Tue, 27 Aug 2013 12:40:08 -0700 (PDT) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id F293821F9CA0; Tue, 27 Aug 2013 12:40:07 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id o10so2524220eaj.27 for ; Tue, 27 Aug 2013 12:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:content-transfer-encoding :content-disposition; bh=ytapiNgrnfcpH97mIRqck563cFMFVsvgU5CBzz+SXfc=; b=PJ0ckQZA1sKZTO7e6xrA7nskJgdHp5cY44n7IfqQGflH38wkKr2IgchIEnfpfhu3TF UqkuzRoLcCGNBUfe9QP02ZPnDkgtl0krBazpPLsQ6bLvH7HDKVh2+A+vGOm3usqIVHah fPJLLPkYbG7WBs3mlxzIjM5ZIF9kSSoNEnEwbs0GklDla9E0XRmQ/5ZeqG8rQgEbd7oS so9ShXbOW4EU6yx/u6LuR9RCMQo5V3Lzp+YYDA5h1253NHZ/mHQIgE3PdoveTeG9rdXA JKPKZfJqFI1ulTB8ZkYRpbK9xNBkuSj2uok7QQNoje4VlMbBITu1KBwKAiDvzhYKp5TW YtUQ== X-Received: by 10.15.48.197 with SMTP id h45mr37173781eew.0.1377632407112; Tue, 27 Aug 2013 12:40:07 -0700 (PDT) Received: from [192.168.1.6] ([176.73.174.236]) by mx.google.com with ESMTPSA id bn13sm31522234eeb.11.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 27 Aug 2013 12:40:06 -0700 (PDT) Date: Tue, 27 Aug 2013 23:40:05 +0400 From: Ioseb Dzmanashvili To: Julian Reschke Message-ID: <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> In-Reply-To: <521C7C36.9000505@gmx.de> References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: IETF Apps Discuss , link-relations Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 27 Aug 2013 19:40:09 -0000 Hi Julian, Thanks for response! On Tuesday, August 27, 2013 at 2:15 PM, Julian Reschke wrote: > On 2013-08-27 11:03, Ioseb Dzmanashvili wrote: > > Hi All, > > > > I've updated the "action" link relation type spec[1] based on initial feedback. > > > > As far as initial reactions were very controversial and raised a lot of issues i tried to address all of them and entirely changed the spec. > > > > ================================================== > > When included in a response, the "action" link relation indicates a > > target resource that is responsible for performing action which MAY: > > > > - Affect state of the context resource; or > > - Initiate process. > > > > The "action" link relation type can be used to indicate the > > availability of actions supported by the target resource. Examples > > of such actions include: > > > > - Enable/Disable > > - Publish/Unpublish > > - Start/Stop > > > > The "action" link relation type doesn't convey any semantics other > > than that an indicated resources represent machine readable > > description of a particular action and representation SHOULD contain > > all necessary details such as: request method, action URI and other > > related details to enable agents to be able to construct requests > > without relying on out-of-band information. > > > > Exact type of action SHOULD be indicated through the "action-type" > > link-extension value as per [RFC5988] and for maintaining shared > > understanding of action types current specification introduces the > > registry of actions with initial values of widely accepted and well > > understood action types. > > > > For example, if a resource represents a service, that same > > representation may include links to resources that represent actions > > supported by the service: > > > > Link: ; rel="action"; action-type="restart" > > Link: ; rel="action"; action-type="stop" > > ... > > > > It seems that you are just adding an indirection mechanism. Why is that > necessary? With indirection mechanism i'm trying to solve issues raised around initial version of the spec[1]. There were several issues: 1. The "action" link relation type doesn't have enough semantics and automated agents can not follow such links if there are several actions included in a representation. With the "action-type" link extension + registry of predefined action types agents can distinguish actions from each other. 2. Initial spec stated that if the "action" link exists in representation, only thing agents should do is to send empty POST request to the target in order to perform action. This approach was considered as an anti pattern(RPCish and non RESTful). With having the "action-type" agents can: a) distinguish action links from each other; b) if necessary dereference the target to obtain instructions for constructing non empty POST/PUT requests; c) send properly constructed request back to the target; and d) it makes possible for servers to dictate structure of the request according to there own needs. Main purpose of the "action" link relation type is to define semantics of particular class of links - actions. This eliminates the need to redefine notion of "action" for each link relation type which may be qualified as action link. The "action-type" is just for naming actions and is particularly useful for automated agents not necessarily for human interaction oriented agents. Having action type registry is important for maintaining shared understanding of particular action types. For example "reset" or "publish" verbs do not need to be redefined from application to application. I also believe that it is not efficient(or feasible) to register all possible actions as link relations. 1. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-00 2. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-01 > > Best regards, Julian Cheers, ioseb From ioseb.dzmanashvili@gmail.com Tue Aug 27 12:46: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 7568011E81C7; Tue, 27 Aug 2013 12:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] 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 EB2MwgtkVQAT; Tue, 27 Aug 2013 12:46:17 -0700 (PDT) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 225A411E81BC; Tue, 27 Aug 2013 12:46:16 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id c13so2488039eek.33 for ; Tue, 27 Aug 2013 12:46:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:content-transfer-encoding :content-disposition; bh=MYdqEO4H/fUsF7MkYle3ag75vf/OOifWsG4rLTQHxvI=; b=dS3UMmC4EMk8EHmH2HSQMJncHVGyxdnl/VnB1tB+p96ON8ogxGrmp0MZ2H0py5KOJo rV/oCltVh1ZfFaOAuWMyoNhhn2RNgoWwt0Y1hyEoZJCsPOfbSCEBqKNGI6XK64oZYR8I RYRupu2rXmfp2F/bY1/mWg2f3MKQjO8oC/llLl/wXzGrtVU0TYdp33NBQNeruZPBFeNV XLDCW1cvhMaD73lhoYUx1Rk71j17sP+q/ZtMLoxpSJ+ErpgqBEggyhPasmvGj1TI8UpC M917V68tu4QH3ShTrpfup4OAoprmDgEB+SSItGh/wngkrscQMhQHWoVmhykvwOEeec+G pBjw== X-Received: by 10.14.182.9 with SMTP id n9mr5953746eem.66.1377632776201; Tue, 27 Aug 2013 12:46:16 -0700 (PDT) Received: from [192.168.1.6] ([176.73.174.236]) by mx.google.com with ESMTPSA id x47sm31559210eea.16.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 27 Aug 2013 12:46:15 -0700 (PDT) Date: Tue, 27 Aug 2013 23:46:12 +0400 From: Ioseb Dzmanashvili To: James M Snell Message-ID: <571BBAACFF6C47A7B0E01B81F8BDED81@gmail.com> In-Reply-To: References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Julian Reschke , IETF Apps Discuss , link-relations Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 27 Aug 2013 19:46:18 -0000 Hi James, Thanks for response! On Tuesday, August 27, 2013 at 7:38 PM, James M Snell wrote: > On Tue, Aug 27, 2013 at 6:16 AM, Mark Baker wrote: > > > > On 2013-08-27 6:15 AM, "Julian Reschke" wrote: > > > It seems that you are just adding an indirection mechanism. Why is that > > > necessary? > > > > > > > > Agreed. The action-types should be registered as the relations. > > > > Also, you might consider reusing the good work of the folks behind > > Schema.org (http://Schema.org); > > > > http://schema.org/Action > > Not to mention activitystrea.ms (http://activitystrea.ms) where many of these verbs already > exist (and could easily be used as link relations themselves). > > Link: ; rel="start" > Link: ; rel="restart" > > Would be generally easier overall. It is not about "start" or "restart" link relation types, i included these as examples. As i already explained in response to Julian, it is about to define what the "action" itself is and make it reusable for particular class of links without the need to redefine meaning of "action" each time. Action type registry is for maintaining minimal shared understanding and is actually only useful for m2m interaction scenarios. > > - James > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org (mailto:apps-discuss@ietf.org) > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > _______________________________________________ > link-relations mailing list > link-relations@ietf.org (mailto:link-relations@ietf.org) > https://www.ietf.org/mailman/listinfo/link-relations Cheers, ioseb From mca@amundsen.com Tue Aug 27 12:58:12 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 1B79E11E81EA for ; Tue, 27 Aug 2013 12:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.521 X-Spam-Level: X-Spam-Status: No, score=0.521 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, J_CHICKENPOX_92=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 2JC80mmB6JzO for ; Tue, 27 Aug 2013 12:58:08 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id CE93011E81D6 for ; Tue, 27 Aug 2013 12:58:07 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id n12so4636713wgh.24 for ; Tue, 27 Aug 2013 12:58:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=iAhl3Zpzp6qgvY7sbFCO+1/3rv75FlQsrWg5kiik63Q=; b=RvNZhAFPP0J6cDorocX6QK4Af7ZazSZLgv2YiTamd6njnk0MNzi+OaB5jj0/pMgu7J N++SbJMRxSm3n5tuv07k+XxoVcCMtjIqSB99kkn/YPnqxTeQE5EIyEEggEOFV7192if3 XaXVfi6CevswQ9ImKzr6on/TR8Q5agXuZpQowifxoTGrhZhKW//5yg5ipkf+yIEsBipr Y8aSxIcYJLdPRk33TtyKk0UXQ0CnyOAN7uIrzq8GCdgv0/5xuMkxv1XP7UStgChgJG2/ WveKJM4uOBnEEFTgDyeaOE6KXsyvpBjNELexHbF8r+Igb8HtqerOeiVXUeJnjjxSFBdJ voaA== X-Gm-Message-State: ALoCoQmVzI+ZdjxvSlCpmtxFCA7et/13zK+DmF2xabnWN/r9lPOJ+yVQvP+f5m6WFMv07sUF+LnR X-Received: by 10.180.198.79 with SMTP id ja15mr12776034wic.36.1377633486861; Tue, 27 Aug 2013 12:58:06 -0700 (PDT) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.151.7 with HTTP; Tue, 27 Aug 2013 12:57:46 -0700 (PDT) In-Reply-To: <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> From: mike amundsen Date: Tue, 27 Aug 2013 15:57:46 -0400 X-Google-Sender-Auth: VZzAFuRJ8FiL2bZPyWyVgcWhRmU Message-ID: To: Ioseb Dzmanashvili Content-Type: multipart/alternative; boundary=047d7b6242529d8fe604e4f34a38 Cc: Julian Reschke , IETF Apps Discuss , link-relations Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 27 Aug 2013 19:58:12 -0000 --047d7b6242529d8fe604e4f34a38 Content-Type: text/plain; charset=ISO-8859-1 Ioseb: it is not clear to me why: is preferable to: talk me down ;) 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/mikeamundsen On Tue, Aug 27, 2013 at 3:40 PM, Ioseb Dzmanashvili < ioseb.dzmanashvili@gmail.com> wrote: > Hi Julian, > > Thanks for response! > > On Tuesday, August 27, 2013 at 2:15 PM, Julian Reschke wrote: > > > On 2013-08-27 11:03, Ioseb Dzmanashvili wrote: > > > Hi All, > > > > > > I've updated the "action" link relation type spec[1] based on initial > feedback. > > > > > > As far as initial reactions were very controversial and raised a lot > of issues i tried to address all of them and entirely changed the spec. > > > > > > ================================================== > > > When included in a response, the "action" link relation indicates a > > > target resource that is responsible for performing action which MAY: > > > > > > - Affect state of the context resource; or > > > - Initiate process. > > > > > > The "action" link relation type can be used to indicate the > > > availability of actions supported by the target resource. Examples > > > of such actions include: > > > > > > - Enable/Disable > > > - Publish/Unpublish > > > - Start/Stop > > > > > > The "action" link relation type doesn't convey any semantics other > > > than that an indicated resources represent machine readable > > > description of a particular action and representation SHOULD contain > > > all necessary details such as: request method, action URI and other > > > related details to enable agents to be able to construct requests > > > without relying on out-of-band information. > > > > > > Exact type of action SHOULD be indicated through the "action-type" > > > link-extension value as per [RFC5988] and for maintaining shared > > > understanding of action types current specification introduces the > > > registry of actions with initial values of widely accepted and well > > > understood action types. > > > > > > For example, if a resource represents a service, that same > > > representation may include links to resources that represent actions > > > supported by the service: > > > > > > Link: ; rel="action"; action-type="restart" > > > Link: ; rel="action"; action-type="stop" > > > ... > > > > > > > > It seems that you are just adding an indirection mechanism. Why is that > > necessary? > > With indirection mechanism i'm trying to solve issues raised around > initial version of the spec[1]. There were several issues: > > 1. The "action" link relation type doesn't have enough semantics and > automated agents can not follow such links if there are several actions > included in a representation. With the "action-type" link extension + > registry of predefined action types agents can distinguish actions from > each other. > > 2. Initial spec stated that if the "action" link exists in representation, > only thing agents should do is to send empty POST request to the target in > order to perform action. This approach was considered as an anti > pattern(RPCish and non RESTful). With having the "action-type" agents can: > > a) distinguish action links from each other; > b) if necessary dereference the target to obtain instructions for > constructing non empty POST/PUT requests; > c) send properly constructed request back to the target; and > d) it makes possible for servers to dictate structure of the request > according to there own needs. > > Main purpose of the "action" link relation type is to define semantics of > particular class of links - actions. This eliminates the need to redefine > notion of "action" for each link relation type which may be qualified as > action link. The "action-type" is just for naming actions and is > particularly useful for automated agents not necessarily for human > interaction oriented agents. > > Having action type registry is important for maintaining shared > understanding of particular action types. For example "reset" or "publish" > verbs do not need to be redefined from application to application. I also > believe that it is not efficient(or feasible) to register all possible > actions as link relations. > > 1. > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-00 > 2. > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-01 > > > > Best regards, Julian > Cheers, > ioseb > > _______________________________________________ > link-relations mailing list > link-relations@ietf.org > https://www.ietf.org/mailman/listinfo/link-relations > --047d7b6242529d8fe604e4f34a38 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ioseb:

it is not clear to me why: <l= ink rel=3D"action;action-type=3D'edit'" href=3D"...&= quot; />
is preferable to: <link rel=3D"edit" hre= f=3D"..." />



On Tue, Aug 27, 2013 at 3:40 PM, Ioseb D= zmanashvili <ioseb.dzmanashvili@gmail.com> wrote:=
Hi Julian,

Thanks for response!

On Tuesday, August 27, 2013 at 2:15 PM, Julian Reschke wrote:

> On 2013-08-27 11:03, Ioseb Dzmanashvili wrote:
> > Hi All,
> >
> > I've updated the "action" link relation type spec[1= ] based on initial feedback.
> >
> > As far as initial reactions were very controversial and raised a = lot of issues i tried to address all of them and entirely changed the spec.=
> >
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
> > When included in a response, the "action" link relation= indicates a
> > target resource that is responsible for performing action which M= AY:
> >
> > - Affect state of the context resource; or
> > - Initiate process.
> >
> > The "action" link relation type can be used to indicate= the
> > availability of actions supported by the target resource. Example= s
> > of such actions include:
> >
> > - Enable/Disable
> > - Publish/Unpublish
> > - Start/Stop
> >
> > The "action" link relation type doesn't convey any = semantics other
> > than that an indicated resources represent machine readable
> > description of a particular action and representation SHOULD cont= ain
> > all necessary details such as: request method, action URI and oth= er
> > related details to enable agents to be able to construct requests=
> > without relying on out-of-band information.
> >
> > Exact type of action SHOULD be indicated through the "action= -type"
> > link-extension value as per [RFC5988] and for maintaining shared<= br> > > understanding of action types current specification introduces th= e
> > registry of actions with initial values of widely accepted and we= ll
> > understood action types.
> >
> > For example, if a resource represents a service, that same
> > representation may include links to resources that represent acti= ons
> > supported by the service:
> >
> > Link: </restart-action>; rel=3D"action"; action-t= ype=3D"restart"
> > Link: </stop-action>; rel=3D"action"; action-type= =3D"stop"
> > ...
>
>
>
> It seems that you are just adding an indirection mechanism. Why is tha= t
> necessary?

With indirection mechanism i'm trying to solve issues raise= d around initial version of the spec[1]. There were several issues:

1. The "action" link relation type doesn't have enough semant= ics and automated agents can not follow such links if there are several act= ions included in a representation. With the "action-type" link ex= tension + registry of predefined action types agents can distinguish action= s from each other.

2. Initial spec stated that if the "action" link exists in repres= entation, only thing agents should do is to send empty POST request to the = target in order to perform action. This approach was considered as an anti = pattern(RPCish and non RESTful). With having the "action-type" ag= ents can:

a) distinguish action links from each other;
b) if necessary dereference the target to obtain instructions for construct= ing non empty POST/PUT requests;
c) send properly constructed request back to the target; and
d) it makes possible for servers to dictate structure of the request accord= ing to there own needs.

Main purpose of the "action" link relation type is to define sema= ntics of particular class of links - actions. This eliminates the need to r= edefine notion of "action" for each link relation type which may = be qualified as action link. The "action-type" is just for naming= actions and is particularly useful for automated agents not necessarily fo= r human interaction oriented agents.

Having action type registry is important for maintaining shared understandi= ng of particular action types. For example "reset" or "publi= sh" verbs do not need to be redefined from application to application.= I also believe that it is not efficient(or feasible) to register all possi= ble actions as link relations.

1. http://tools.ietf.org/html/draft-ioseb-dz= manashvili-action-link-relation-00
2. http://tools.ietf.org/html/draft-ioseb-dz= manashvili-action-link-relation-01
>
> Best regards, Julian
Cheers,
ioseb

_______________________________________________
link-relations mailing list
link-relations= @ietf.org
https://www.ietf.org/mailman/listinfo/link-relations

--047d7b6242529d8fe604e4f34a38-- From ioseb.dzmanashvili@gmail.com Tue Aug 27 16:51: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 F13E111E8100; Tue, 27 Aug 2013 16:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.249 X-Spam-Level: X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_92=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 FCC8GYZI-N5F; Tue, 27 Aug 2013 16:51:08 -0700 (PDT) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB5711E80F5; Tue, 27 Aug 2013 16:51:08 -0700 (PDT) Received: by mail-ea0-f173.google.com with SMTP id g10so2577375eak.4 for ; Tue, 27 Aug 2013 16:51:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:content-transfer-encoding :content-disposition; bh=SCeXUk6LDn3QOLhtECJG/yZiFFQB5CB/ohlrIor3uTE=; b=pgC1C8ojcvdXv07s6uquRxIL4SppV1ibR8dHmEbl2NhbADuJwyenzeYaKdIqgNKcuM xw9OPBURA6mxy0PnJVrDo3vcDQAqOh1eE8+O+l1/BcH98mnE0tqYXrNDHL9CtcoIsO9Z CjGc8kPBQQ4WS2fQoeEGbJzkl0zpuJprFWdduWLuAkcrc0T0008yV1gW9eFJPV4fcizP UnqRIS4UmwAkB96QBFkdH7eW7+BSPqUWGBSrYKgHWVrNTFjtQFVa+Kss3g3jB8LfwfKZ WkL9NFnxHlVlTPLcKItGHCdcD13OVaMZYhG6Mw43uI4rsP/zpdU8igcMobTrw4HSSLr7 ZhMQ== X-Received: by 10.14.122.132 with SMTP id t4mr38629361eeh.20.1377647467321; Tue, 27 Aug 2013 16:51:07 -0700 (PDT) Received: from [192.168.1.6] ([176.73.174.236]) by mx.google.com with ESMTPSA id r48sm32725960eev.14.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 27 Aug 2013 16:51:06 -0700 (PDT) Date: Wed, 28 Aug 2013 03:51:03 +0400 From: Ioseb Dzmanashvili To: mike amundsen Message-ID: <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> In-Reply-To: References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Julian Reschke , IETF Apps Discuss , link-relations Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 27 Aug 2013 23:51:10 -0000 Hi Mike, Thanks for the question=21 =20 On Tuesday, August 27, 2013 at 11:57 PM, mike amundsen wrote: > Ioseb: > =20 > it is not clear to me why: > is preferable to: > =20 > talk me down ;) let me try ;) Question is not about why: Link: <=E2=80=A6>; rel=3D=22action=22; action-= type=3D=22edit=22 is preferable to: Link: <=E2=80=A6>; rel=3D=22edit=22. Of course i'd choose rel=3D=22run-forest-run=22 if there is a registered = link relation type, but: 1. The =22action=22 link relation is generic enough, has well understood = meaning and is useful on its own especially for human oriented agents. 2. The =22action-type=22 optional attribute may be used for specifying ex= act meaning of actions and this makes action links more useful for m2m sc= enarios. Now consider this link: Link: ; rel=3D=22action=22; action-type=3D=22suspend=22;= title=3D=22Suspend=22 What it says=3F 1. it is an action 2. target resource represents description of the action which contains: r= equest method, submit URI, definition of action, other details etc 3. agent can look inside =22action-type=22 to determine whether it needs = this action type or not 4. agent can dereference it, construct request and send it to server now if we add more actions: Link: ; rel=3D=22action=22; action-type=3D=22suspend=22;= title=3D=22Suspend=22 Link: ; rel=3D=22action=22; action-type=3D=22restart=22;= title=3D=22Restart=22 Link: ; rel=3D=22action=22; action-type=3D=22stop=22; title= =3D=22Stop=22 =231, =232, =233 and =234 will be true for all of them without exceptions= . Now consider that representation containing these links is used by GUI ag= ent, in this case even =22action-type=22 is not necessary at all and agen= t can rely on user's choice. Agent only needs to know that: 1. link is an action(and this question is explicitly answered) 2. if user choose one agent needs just to dereference indicated URI 3. construct request =20 4. send request to server 5. show results to user All of these will remain true for any action type. I'm not sure if i talked you down, but i believe =22action=22 relation ty= pe is useful and not because it is better(or simpler) compared to rel=3D=22= edit=22 for example. =20 1. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relati= on-00 2. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relati= on-01 P.S. I was talking about 01 version of spec. 00 is a different story. Cheers, ioseb > 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/mikeamundsen =20 > =20 > =20 > =20 > On Tue, Aug 27, 2013 at 3:40 PM, Ioseb Dzmanashvili wrote: > > Hi Julian, > > =20 > > Thanks for response=21 > > =20 > > On Tuesday, August 27, 2013 at 2:15 PM, Julian Reschke wrote: > > =20 > > > On 2013-08-27 11:03, Ioseb Dzmanashvili wrote: > > > > Hi All, > > > > =20 > > > > I've updated the =22action=22 link relation type spec=5B1=5D base= d on initial feedback. > > > > =20 > > > > As far as initial reactions were very controversial and raised a = lot of issues i tried to address all of them and entirely changed the spe= c. > > > > =20 > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > > > When included in a response, the =22action=22 link relation indic= ates a > > > > target resource that is responsible for performing action which M= AY: > > > > =20 > > > > - Affect state of the context resource; or > > > > - Initiate process. > > > > =20 > > > > The =22action=22 link relation type can be used to indicate the > > > > availability of actions supported by the target resource. Example= s > > > > of such actions include: > > > > =20 > > > > - Enable/Disable > > > > - Publish/Unpublish > > > > - Start/Stop > > > > =20 > > > > The =22action=22 link relation type doesn't convey any semantics = other > > > > than that an indicated resources represent machine readable > > > > description of a particular action and representation SHOULD cont= ain > > > > all necessary details such as: request method, action URI and oth= er > > > > related details to enable agents to be able to construct requests= > > > > without relying on out-of-band information. > > > > =20 > > > > Exact type of action SHOULD be indicated through the =22action-ty= pe=22 > > > > link-extension value as per =5BR=46C5988=5D and for maintaining s= hared > > > > understanding of action types current specification introduces th= e > > > > registry of actions with initial values of widely accepted and we= ll > > > > understood action types. > > > > =20 > > > > =46or example, if a resource represents a service, that same > > > > representation may include links to resources that represent acti= ons > > > > supported by the service: > > > > =20 > > > > Link: ; rel=3D=22action=22; action-type=3D=22res= tart=22 > > > > Link: ; rel=3D=22action=22; action-type=3D=22stop=22= > > > > ... > > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > It seems that you are just adding an indirection mechanism. Why is = that > > > necessary=3F > > > =20 > > =20 > > =20 > > With indirection mechanism i'm trying to solve issues raised around i= nitial version of the spec=5B1=5D. There were several issues: > > =20 > > 1. The =22action=22 link relation type doesn't have enough semantics = and automated agents can not follow such links if there are several actio= ns included in a representation. With the =22action-type=22 link extensio= n + registry of predefined action types agents can distinguish actions fr= om each other. > > =20 > > 2. Initial spec stated that if the =22action=22 link exists in repres= entation, only thing agents should do is to send empty POST request to th= e target in order to perform action. This approach was considered as an a= nti pattern(RPCish and non RESTful). With having the =22action-type=22 ag= ents can: > > =20 > > a) distinguish action links from each other; > > b) if necessary dereference the target to obtain instructions for con= structing non empty POST/PUT requests; > > c) send properly constructed request back to the target; and > > d) it makes possible for servers to dictate structure of the request = according to there own needs. > > =20 > > Main purpose of the =22action=22 link relation type is to define sema= ntics of particular class of links - actions. This eliminates the need to= redefine notion of =22action=22 for each link relation type which may be= qualified as action link. The =22action-type=22 is just for naming actio= ns and is particularly useful for automated agents not necessarily for hu= man interaction oriented agents. > > =20 > > Having action type registry is important for maintaining shared under= standing of particular action types. =46or example =22reset=22 or =22publ= ish=22 verbs do not need to be redefined from application to application.= I also believe that it is not efficient(or feasible) to register all pos= sible actions as link relations. > > =20 > > 1. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-re= lation-00 > > 2. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-re= lation-01 > > > =20 > > > Best regards, Julian > > Cheers, > > ioseb > > =20 > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > link-relations mailing list > > link-relations=40ietf.org (mailto:link-relations=40ietf.org) (mailto:= link-relations=40ietf.org) > > https://www.ietf.org/mailman/listinfo/link-relations > > =20 > =20 > =20 From mca@amundsen.com Tue Aug 27 18:26: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 EB53E21E80F4 for ; Tue, 27 Aug 2013 18:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.321 X-Spam-Level: **** X-Spam-Status: No, score=4.321 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_92=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 HGlp3rN4kwHS for ; Tue, 27 Aug 2013 18:26:51 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by ietfa.amsl.com (Postfix) with ESMTP id EAA2921E80E9 for ; Tue, 27 Aug 2013 18:26:48 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id l12so6154883wiv.0 for ; Tue, 27 Aug 2013 18:26:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=pIinXS3/8DvYc1mgQWEl/YElOz0cuzJ4EbGqtKVBs1g=; b=OcqIQn116ZJ1Rvzzc8pEJo8KL3rf3m6l6q9O9KSUvcUvGvn1UyZ4tUBLnE2zVRbaet jNFnKnpCD0y8vSvCmURjcXhMzXhpRWn+nDL1qYPJtXQs4xMd8qCEuWOoWwWV2QzfiL9A PqA/55OnBPF63XV+6c5BC4Bf8FxQd/gdzlqoRYWDCT9KZ21GHMcquMmNve+Gp6Y8FF23 R+ITZELE21ODEV7bkJKYxiF9kaDd2TMjO6Sv7EWmSkNWAfgntawBBitGgROpBL6Nk1aV T2dJyqOc0zD27QMlZnuBDgzEu5UWMvmMOfgw6Gzlx1U5eq9IenHyB8nw/8uS523THiG8 7Ozw== X-Gm-Message-State: ALoCoQlDxbv8/OXFqFr6l0CRa+CJkTDkIutF9rSD1OImWmRrCDANeCENEOREDrAIgIE3sbvS4BME X-Received: by 10.194.93.105 with SMTP id ct9mr16742481wjb.6.1377653206604; Tue, 27 Aug 2013 18:26:46 -0700 (PDT) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.151.7 with HTTP; Tue, 27 Aug 2013 18:26:25 -0700 (PDT) In-Reply-To: <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> From: mike amundsen Date: Tue, 27 Aug 2013 21:26:25 -0400 X-Google-Sender-Auth: nBnCRhSCvXbikeJCx4Xw1WxK5Ho Message-ID: To: Ioseb Dzmanashvili Content-Type: multipart/alternative; boundary=047d7bb03e7800f0f704e4f7e2cb Cc: Julian Reschke , IETF Apps Discuss , link-relations Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 28 Aug 2013 01:26:57 -0000 --047d7bb03e7800f0f704e4f7e2cb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable OK, from your response i get the following: 1) you want to support a pattern where machine-readable state transition instructions appear at the end of some URL. 2) you want to indicate those instructions are available by marking the URL w/ the string literal "action" (via rel in your illustrations) 3) you want to indicate the reason for using these instructions w/ an "action-type" string (via a link-rel param in your illustrations) that's it. nothing else. do i have this correct? 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/mikeamundsen On Tue, Aug 27, 2013 at 7:51 PM, Ioseb Dzmanashvili < ioseb.dzmanashvili@gmail.com> wrote: > Hi Mike, > > Thanks for the question! > > On Tuesday, August 27, 2013 at 11:57 PM, mike amundsen wrote: > > > Ioseb: > > > > it is not clear to me why: href=3D"..." /> > > is preferable to: > > > > talk me down ;) > let me try ;) > > Question is not about why: Link: <=85>; rel=3D"action"; action-type=3D"ed= it" is > preferable to: Link: <=85>; rel=3D"edit". > > Of course i'd choose rel=3D"run-forest-run" if there is a registered link > relation type, but: > > 1. The "action" link relation is generic enough, has well understood > meaning and is useful on its own especially for human oriented agents. > 2. The "action-type" optional attribute may be used for specifying exact > meaning of actions and this makes action links more useful for m2m > scenarios. > > Now consider this link: > > Link: ; rel=3D"action"; action-type=3D"suspend"; > title=3D"Suspend" > > What it says? > > 1. it is an action > 2. target resource represents description of the action which contains: > request method, submit URI, definition of action, other details etc > 3. agent can look inside "action-type" to determine whether it needs this > action type or not > 4. agent can dereference it, construct request and send it to server > > > now if we add more actions: > > Link: ; rel=3D"action"; action-type=3D"suspend"; > title=3D"Suspend" > Link: ; rel=3D"action"; action-type=3D"restart"; > title=3D"Restart" > > Link: ; rel=3D"action"; action-type=3D"stop"; title=3D"Stop= " > > > #1, #2, #3 and #4 will be true for all of them without exceptions. > > Now consider that representation containing these links is used by GUI > agent, in this case even "action-type" is not necessary at all and agent > can rely on user's choice. Agent only needs to know that: > > 1. link is an action(and this question is explicitly answered) > 2. if user choose one agent needs just to dereference indicated URI > 3. construct request > 4. send request to server > 5. show results to user > > All of these will remain true for any action type. > > I'm not sure if i talked you down, but i believe "action" relation type i= s > useful and not because it is better(or simpler) compared to rel=3D"edit" = for > example. > > 1. > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-= 00 > 2. > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-= 01 > > P.S. > I was talking about 01 version of spec. 00 is a different story. > > Cheers, > ioseb > > 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/mikeamundsen > > > > > > > > On Tue, Aug 27, 2013 at 3:40 PM, Ioseb Dzmanashvili < > ioseb.dzmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com) > (mailto:ioseb.dzmanashvili@gmail.com)> wrote: > > > Hi Julian, > > > > > > Thanks for response! > > > > > > On Tuesday, August 27, 2013 at 2:15 PM, Julian Reschke wrote: > > > > > > > On 2013-08-27 11:03, Ioseb Dzmanashvili wrote: > > > > > Hi All, > > > > > > > > > > I've updated the "action" link relation type spec[1] based on > initial feedback. > > > > > > > > > > As far as initial reactions were very controversial and raised a > lot of issues i tried to address all of them and entirely changed the spe= c. > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > > When included in a response, the "action" link relation indicates= a > > > > > target resource that is responsible for performing action which > MAY: > > > > > > > > > > - Affect state of the context resource; or > > > > > - Initiate process. > > > > > > > > > > The "action" link relation type can be used to indicate the > > > > > availability of actions supported by the target resource. Example= s > > > > > of such actions include: > > > > > > > > > > - Enable/Disable > > > > > - Publish/Unpublish > > > > > - Start/Stop > > > > > > > > > > The "action" link relation type doesn't convey any semantics othe= r > > > > > than that an indicated resources represent machine readable > > > > > description of a particular action and representation SHOULD > contain > > > > > all necessary details such as: request method, action URI and oth= er > > > > > related details to enable agents to be able to construct requests > > > > > without relying on out-of-band information. > > > > > > > > > > Exact type of action SHOULD be indicated through the "action-type= " > > > > > link-extension value as per [RFC5988] and for maintaining shared > > > > > understanding of action types current specification introduces th= e > > > > > registry of actions with initial values of widely accepted and we= ll > > > > > understood action types. > > > > > > > > > > For example, if a resource represents a service, that same > > > > > representation may include links to resources that represent > actions > > > > > supported by the service: > > > > > > > > > > Link: ; rel=3D"action"; action-type=3D"restart" > > > > > Link: ; rel=3D"action"; action-type=3D"stop" > > > > > ... > > > > > > > > > > > > > > > > > > > > > > > > > It seems that you are just adding an indirection mechanism. Why is > that > > > > necessary? > > > > > > > > > > > > > With indirection mechanism i'm trying to solve issues raised around > initial version of the spec[1]. There were several issues: > > > > > > 1. The "action" link relation type doesn't have enough semantics and > automated agents can not follow such links if there are several actions > included in a representation. With the "action-type" link extension + > registry of predefined action types agents can distinguish actions from > each other. > > > > > > 2. Initial spec stated that if the "action" link exists in > representation, only thing agents should do is to send empty POST request > to the target in order to perform action. This approach was considered as > an anti pattern(RPCish and non RESTful). With having the "action-type" > agents can: > > > > > > a) distinguish action links from each other; > > > b) if necessary dereference the target to obtain instructions for > constructing non empty POST/PUT requests; > > > c) send properly constructed request back to the target; and > > > d) it makes possible for servers to dictate structure of the request > according to there own needs. > > > > > > Main purpose of the "action" link relation type is to define semantic= s > of particular class of links - actions. This eliminates the need to > redefine notion of "action" for each link relation type which may be > qualified as action link. The "action-type" is just for naming actions an= d > is particularly useful for automated agents not necessarily for human > interaction oriented agents. > > > > > > Having action type registry is important for maintaining shared > understanding of particular action types. For example "reset" or "publish= " > verbs do not need to be redefined from application to application. I also > believe that it is not efficient(or feasible) to register all possible > actions as link relations. > > > > > > 1. > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-= 00 > > > 2. > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-= 01 > > > > > > > > Best regards, Julian > > > Cheers, > > > ioseb > > > > > > _______________________________________________ > > > link-relations mailing list > > > link-relations@ietf.org (mailto:link-relations@ietf.org) (mailto: > link-relations@ietf.org) > > > https://www.ietf.org/mailman/listinfo/link-relations > > > > > > > > > > > --047d7bb03e7800f0f704e4f7e2cb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
OK, from your = response i get the following:

1) = you want to support a pattern where machine-readable state transition instr= uctions appear at the end of some URL.
2) you want to indicate those i= nstructions are available by marking the URL w/ the string literal "ac= tion" (via rel in your illustrations)
3) you want to indicate the reason for using these = instructions w/ an "action-type" string (via a link-rel param in = your illustrations)

that's it. nothing else.=A0
<= div style>
do i have this correct?




On Tue, Aug 27, 2013 at 7:51 PM, Ioseb D= zmanashvili <ioseb.dzmanashvili@gmail.com> wrote:=
Hi Mike,

Thanks for the question!

On Tuesday, August 27, 2013 at 11:57 PM, mike amundsen wrote:

> Ioseb:
>
> it is not clear to me why: <link rel=3D"action;action-type=3D&= #39;edit'" href=3D"..." />
> is preferable to: <link rel=3D"edit" href=3D"...&quo= t; />
>
> talk me down ;)
let me try ;)

Question is not about why: Link: <=85>; rel=3D"action"; act= ion-type=3D"edit" is preferable to: Link: <=85>; rel=3D&quo= t;edit".

Of course i'd choose rel=3D"run-forest-run" if there is a reg= istered link relation type, but:

1. The "action" link relation is generic enough, has well underst= ood meaning and is useful on its own especially for human oriented agents.<= br> 2. The "action-type" optional attribute may be used for specifyin= g exact meaning of actions and this makes action links more useful for m2m = scenarios.

Now consider this link:

Link: </suspend-action>; rel=3D"action"; action-type=3D&quo= t;suspend"; title=3D"Suspend"

What it says?

1. it is an action
2. target resource represents description of the action which contains: req= uest method, submit URI, definition of action, other details etc
3. agent can look inside "action-type" to determine whether it ne= eds this action type or not
4. agent can dereference it, construct request and send it to server


now if we add more actions:

Link: </suspend-action>; rel=3D"action"; action-type=3D&quo= t;suspend"; title=3D"Suspend"
Link: </restart-action>; rel=3D"action"; action-type=3D&quo= t;restart"; title=3D"Restart"

Link: </stop-action>; rel=3D"action"; action-type=3D"s= top"; title=3D"Stop"


#1, #2, #3 and #4 will be true for all of them without exceptions.

Now consider that representation containing these links is used by GUI agen= t, in this case even "action-type" is not necessary at all and ag= ent can rely on user's choice. Agent only needs to know that:

1. link is an action(and this question is explicitly answered)
2. if user choose one agent needs just to dereference indicated URI
3. construct request
4. send request to server
5. show results to user

All of these will remain true for any action type.

I'm not sure if i talked you down, but i believe "action" rel= ation type is useful and not because it is better(or simpler) compared to r= el=3D"edit" for example.

1. http://tools.ietf.org/html/draft-ioseb-dz= manashvili-action-link-relation-00
2. http://tools.ietf.org/html/draft-ioseb-dz= manashvili-action-link-relation-01

P.S.
I was talking about 01 version of spec. 00 is a different story.

Cheers,
ioseb
> mamund
> +1.859.757.14= 49
> skype: mca.amundsen
> http://amundse= n.com/blog/
> http://twitter= .com/mamund
> https://github= .com/mamund
> = http://www.linkedin.com/in/mikeamundsen
>
>
>
> On Tue, Aug 27, 2013 at 3:40 PM, Ioseb Dz= manashvili <ioseb.dzmana= shvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.com)> wrote:
> > Hi Julian,
> >
> > Thanks for response!
> >
> > On Tuesday, August 27, 2013 at 2:15 PM, Julian Reschke wrote:
> >
> > > On 2013-08-27 11:03, Ioseb Dzmanashvili wrote:
> > > > Hi All,
> > > >
> > > > I've updated the "action" link relation t= ype spec[1] based on initial feedback.
> > > >
> > > > As far as initial reactions were very controversial and= raised a lot of issues i tried to address all of them and entirely changed= the spec.
> > > >
> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
> > > > When included in a response, the "action" lin= k relation indicates a
> > > > target resource that is responsible for performing acti= on which MAY:
> > > >
> > > > - Affect state of the context resource; or
> > > > - Initiate process.
> > > >
> > > > The "action" link relation type can be used t= o indicate the
> > > > availability of actions supported by the target resourc= e. Examples
> > > > of such actions include:
> > > >
> > > > - Enable/Disable
> > > > - Publish/Unpublish
> > > > - Start/Stop
> > > >
> > > > The "action" link relation type doesn't c= onvey any semantics other
> > > > than that an indicated resources represent machine read= able
> > > > description of a particular action and representation S= HOULD contain
> > > > all necessary details such as: request method, action U= RI and other
> > > > related details to enable agents to be able to construc= t requests
> > > > without relying on out-of-band information.
> > > >
> > > > Exact type of action SHOULD be indicated through the &q= uot;action-type"
> > > > link-extension value as per [RFC5988] and for maintaini= ng shared
> > > > understanding of action types current specification int= roduces the
> > > > registry of actions with initial values of widely accep= ted and well
> > > > understood action types.
> > > >
> > > > For example, if a resource represents a service, that s= ame
> > > > representation may include links to resources that repr= esent actions
> > > > supported by the service:
> > > >
> > > > Link: </restart-action>; rel=3D"action"= ; action-type=3D"restart"
> > > > Link: </stop-action>; rel=3D"action"; a= ction-type=3D"stop"
> > > > ...
> > > >
> > >
> > >
> > >
> > >
> > > It seems that you are just adding an indirection mechanism. = Why is that
> > > necessary?
> > >
> >
> >
> > With indirection mechanism i'm trying to solve issues raised = around initial version of the spec[1]. There were several issues:
> >
> > 1. The "action" link relation type doesn't have eno= ugh semantics and automated agents can not follow such links if there are s= everal actions included in a representation. With the "action-type&quo= t; link extension + registry of predefined action types agents can distingu= ish actions from each other.
> >
> > 2. Initial spec stated that if the "action" link exists= in representation, only thing agents should do is to send empty POST reque= st to the target in order to perform action. This approach was considered a= s an anti pattern(RPCish and non RESTful). With having the "action-typ= e" agents can:
> >
> > a) distinguish action links from each other;
> > b) if necessary dereference the target to obtain instructions for= constructing non empty POST/PUT requests;
> > c) send properly constructed request back to the target; and
> > d) it makes possible for servers to dictate structure of the requ= est according to there own needs.
> >
> > Main purpose of the "action" link relation type is to d= efine semantics of particular class of links - actions. This eliminates the= need to redefine notion of "action" for each link relation type = which may be qualified as action link. The "action-type" is just = for naming actions and is particularly useful for automated agents not nece= ssarily for human interaction oriented agents.
> >
> > Having action type registry is important for maintaining shared u= nderstanding of particular action types. For example "reset" or &= quot;publish" verbs do not need to be redefined from application to ap= plication. I also believe that it is not efficient(or feasible) to register= all possible actions as link relations.
> >
> > 1. http://tools.ietf.org/html/draf= t-ioseb-dzmanashvili-action-link-relation-00
> > 2. http://tools.ietf.org/html/draf= t-ioseb-dzmanashvili-action-link-relation-01
> > >
> > > Best regards, Julian
> > Cheers,
> > ioseb
> >
> > _______________________________________________
> > link-relations mailing list
> > link-relat= ions@ietf.org (mailto:link-r= elations@ietf.org) (mailto:l= ink-relations@ietf.org)
> > https://www.ietf.org/mailman/listinfo/link-relations<= br> > >
>
>




--047d7bb03e7800f0f704e4f7e2cb-- From ioseb.dzmanashvili@gmail.com Wed Aug 28 00:35: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 BEC6D11E814B; Wed, 28 Aug 2013 00:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_50=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_92=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 pQIV+qPQU4Ni; Wed, 28 Aug 2013 00:35:09 -0700 (PDT) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A0F6811E8136; Wed, 28 Aug 2013 00:35:08 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id b47so2755703eek.3 for ; Wed, 28 Aug 2013 00:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:content-transfer-encoding :content-disposition; bh=XcqvAfDV2cpY9Ps/U34q5dfqStWHUlY8rdmdzW6X/NA=; b=Xy08Xzid8wnIpktau6Ucf/o47Ns+ipE8w5+haw2nIui0HTirvQ9vqk2VzOxDdLYU9L WmiRJDbR1BUWECkDZ+HKot55qp9Kza7pKYn0WFR7w4yTGHJLehaoPHkUXNdFddrOQT3R 39yEpC5RAr+r8HiVwBdxhRvimaOkmq5KC7Jw473OgWmzmxJY8CSMFA8QS0rtt6sEBpIF RJ+oZ0I9BnTsPHoQWwFWSA4Q7Ix2IJcsCMV+/3NEiHX6x7SICUIuCdrHtA37nErAoiL2 gHLIRMq1jpTvk0EddpYhUldHy8D5kcbMxA+edpLC2uTPiZvE8WN4MdXQqQccs2ru6S1C cbwQ== X-Received: by 10.15.90.132 with SMTP id q4mr213628eez.98.1377675307773; Wed, 28 Aug 2013 00:35:07 -0700 (PDT) Received: from [192.168.1.6] ([176.73.174.236]) by mx.google.com with ESMTPSA id n48sm34927998eeg.17.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 28 Aug 2013 00:35:06 -0700 (PDT) Date: Wed, 28 Aug 2013 11:35:03 +0400 From: Ioseb Dzmanashvili To: mike amundsen Message-ID: <8410EE3EC8FB4ADA93F4209376AF8183@gmail.com> In-Reply-To: References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Julian Reschke , IETF Apps Discuss , link-relations Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 28 Aug 2013 07:35:10 -0000 Mike, On Wednesday, August 28, 2013 at 5:26 AM, mike amundsen wrote: > OK, from your response i get the following: > =20 > 1) you want to support a pattern where machine-readable state transitio= n instructions appear at the end of some URL. =20 > 2) you want to indicate those instructions are available by marking the= URL w/ the string literal =22action=22 (via rel in your illustrations) > 3) you want to indicate the reason for using these instructions w/ an =22= action-type=22 string (via a link-rel param in your illustrations) > =20 > that's it. nothing else. =20 > =20 > do i have this correct=3F =20 > =20 Exactly=21 That's it and nothing else. =20 Cheers, ioseb =20 > =20 > =20 > 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/mikeamundsen =20 > =20 > On Tue, Aug 27, 2013 at 7:51 PM, Ioseb Dzmanashvili wrote: > > Hi Mike, > > =20 > > Thanks for the question=21 > > =20 > > On Tuesday, August 27, 2013 at 11:57 PM, mike amundsen wrote: > > =20 > > > Ioseb: > > > =20 > > > it is not clear to me why: > > > is preferable to: > > > =20 > > > talk me down ;) > > let me try ;) > > =20 > > Question is not about why: Link: <=E2=80=A6>; rel=3D=22action=22; act= ion-type=3D=22edit=22 is preferable to: Link: <=E2=80=A6>; rel=3D=22edit=22= . > > =20 > > Of course i'd choose rel=3D=22run-forest-run=22 if there is a registe= red link relation type, but: > > =20 > > 1. The =22action=22 link relation is generic enough, has well underst= ood meaning and is useful on its own especially for human oriented agents= . > > 2. The =22action-type=22 optional attribute may be used for specifyin= g exact meaning of actions and this makes action links more useful for m2= m scenarios. > > =20 > > Now consider this link: > > =20 > > Link: ; rel=3D=22action=22; action-type=3D=22suspend= =22; title=3D=22Suspend=22 > > =20 > > What it says=3F > > =20 > > 1. it is an action > > 2. target resource represents description of the action which contain= s: request method, submit URI, definition of action, other details etc > > 3. agent can look inside =22action-type=22 to determine whether it ne= eds this action type or not > > 4. agent can dereference it, construct request and send it to server > > =20 > > =20 > > now if we add more actions: > > =20 > > Link: ; rel=3D=22action=22; action-type=3D=22suspend= =22; title=3D=22Suspend=22 > > Link: ; rel=3D=22action=22; action-type=3D=22restart= =22; title=3D=22Restart=22 > > =20 > > Link: ; rel=3D=22action=22; action-type=3D=22stop=22; t= itle=3D=22Stop=22 > > =20 > > =20 > > =231, =232, =233 and =234 will be true for all of them without except= ions. > > =20 > > Now consider that representation containing these links is used by GU= I agent, in this case even =22action-type=22 is not necessary at all and = agent can rely on user's choice. Agent only needs to know that: > > =20 > > 1. link is an action(and this question is explicitly answered) > > 2. if user choose one agent needs just to dereference indicated URI > > 3. construct request > > 4. send request to server > > 5. show results to user > > =20 > > All of these will remain true for any action type. > > =20 > > I'm not sure if i talked you down, but i believe =22action=22 relatio= n type is useful and not because it is better(or simpler) compared to rel= =3D=22edit=22 for example. > > =20 > > 1. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-re= lation-00 > > 2. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-re= lation-01 > > =20 > > P.S. > > I was talking about 01 version of spec. 00 is a different story. > > =20 > > Cheers, > > ioseb > > > mamund > > > +1.859.757.1449 (tel:%2B1.859.757.1449) > > > skype: mca.amundsen > > > http://amundsen.com/blog/ > > > http://twitter.com/mamund > > > https://github.com/mamund > > > http://www.linkedin.com/in/mikeamundsen > > > =20 > > > =20 > > > =20 > > > On Tue, Aug 27, 2013 at 3:40 PM, Ioseb Dzmanashvili wrote: > > > > Hi Julian, > > > > =20 > > > > Thanks for response=21 > > > > =20 > > > > On Tuesday, August 27, 2013 at 2:15 PM, Julian Reschke wrote: > > > > =20 > > > > > On 2013-08-27 11:03, Ioseb Dzmanashvili wrote: > > > > > > Hi All, > > > > > > =20 > > > > > > I've updated the =22action=22 link relation type spec=5B1=5D = based on initial feedback. > > > > > > =20 > > > > > > As far as initial reactions were very controversial and raise= d a lot of issues i tried to address all of them and entirely changed the= spec. > > > > > > =20 > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > > > When included in a response, the =22action=22 link relation i= ndicates a > > > > > > target resource that is responsible for performing action whi= ch MAY: > > > > > > =20 > > > > > > - Affect state of the context resource; or > > > > > > - Initiate process. > > > > > > =20 > > > > > > The =22action=22 link relation type can be used to indicate t= he > > > > > > availability of actions supported by the target resource. Exa= mples > > > > > > of such actions include: > > > > > > =20 > > > > > > - Enable/Disable > > > > > > - Publish/Unpublish > > > > > > - Start/Stop > > > > > > =20 > > > > > > The =22action=22 link relation type doesn't convey any semant= ics other > > > > > > than that an indicated resources represent machine readable > > > > > > description of a particular action and representation SHOULD = contain > > > > > > all necessary details such as: request method, action URI and= other > > > > > > related details to enable agents to be able to construct requ= ests > > > > > > without relying on out-of-band information. > > > > > > =20 > > > > > > Exact type of action SHOULD be indicated through the =22actio= n-type=22 > > > > > > link-extension value as per =5BR=46C5988=5D and for maintaini= ng shared > > > > > > understanding of action types current specification introduce= s the > > > > > > registry of actions with initial values of widely accepted an= d well > > > > > > understood action types. > > > > > > =20 > > > > > > =46or example, if a resource represents a service, that same > > > > > > representation may include links to resources that represent = actions > > > > > > supported by the service: > > > > > > =20 > > > > > > Link: ; rel=3D=22action=22; action-type=3D=22= restart=22 > > > > > > Link: ; rel=3D=22action=22; action-type=3D=22st= op=22 > > > > > > ... > > > > > =20 > > > > > =20 > > > > > =20 > > > > > =20 > > > > > =20 > > > > > It seems that you are just adding an indirection mechanism. Why= is that > > > > > necessary=3F > > > > =20 > > > > =20 > > > > =20 > > > > With indirection mechanism i'm trying to solve issues raised arou= nd initial version of the spec=5B1=5D. There were several issues: > > > > =20 > > > > 1. The =22action=22 link relation type doesn't have enough semant= ics and automated agents can not follow such links if there are several a= ctions included in a representation. With the =22action-type=22 link exte= nsion + registry of predefined action types agents can distinguish action= s from each other. > > > > =20 > > > > 2. Initial spec stated that if the =22action=22 link exists in re= presentation, only thing agents should do is to send empty POST request t= o the target in order to perform action. This approach was considered as = an anti pattern(RPCish and non RESTful). With having the =22action-type=22= agents can: > > > > =20 > > > > a) distinguish action links from each other; > > > > b) if necessary dereference the target to obtain instructions for= constructing non empty POST/PUT requests; > > > > c) send properly constructed request back to the target; and > > > > d) it makes possible for servers to dictate structure of the requ= est according to there own needs. > > > > =20 > > > > Main purpose of the =22action=22 link relation type is to define = semantics of particular class of links - actions. This eliminates the nee= d to redefine notion of =22action=22 for each link relation type which ma= y be qualified as action link. The =22action-type=22 is just for naming a= ctions and is particularly useful for automated agents not necessarily fo= r human interaction oriented agents. > > > > =20 > > > > Having action type registry is important for maintaining shared u= nderstanding of particular action types. =46or example =22reset=22 or =22= publish=22 verbs do not need to be redefined from application to applicat= ion. I also believe that it is not efficient(or feasible) to register all= possible actions as link relations. > > > > =20 > > > > 1. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-lin= k-relation-00 > > > > 2. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-lin= k-relation-01 > > > > > =20 > > > > > Best regards, Julian > > > > Cheers, > > > > ioseb > > > > =20 > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > > > > link-relations mailing list > > > > link-relations=40ietf.org (mailto:link-relations=40ietf.org) (mai= lto:link-relations=40ietf.org) (mailto:link-relations=40ietf.org) > > > > https://www.ietf.org/mailman/listinfo/link-relations > > > =20 > > =20 > =20 From ioseb.dzmanashvili@gmail.com Wed Aug 28 01:04: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 6B94011E815F; Wed, 28 Aug 2013 01:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 1GyVrHrXSHx0; Wed, 28 Aug 2013 01:04:54 -0700 (PDT) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAC211E815C; Wed, 28 Aug 2013 01:04:53 -0700 (PDT) Received: by mail-ee0-f51.google.com with SMTP id c1so2769718eek.10 for ; Wed, 28 Aug 2013 01:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:content-transfer-encoding :content-disposition; bh=/9ogjKtygiho+io8F3gJleY64H2geDeKgqLkzYnBXC4=; b=ov+tjEwHmgKoH8LVEmKDdpL/EU6BneZw7F9cV5DvhZ7/opa6GeM5YdvDm9auq4RBFv E9CbxfEzP3vU3+WETLbDd3BtzYqhZ2FZ3NCjSlkE7QYyKbBTRaoNmha8jv+DbwO0QjUl PMpaaI4ArF0jL0zo84rYAQFrIieQ3LmzQLh29OJZmqPCFBfibYnGeK9e+Gb6W+2UVO+y yAKP7YdF+B5JU+GHgsg/hZQcv0LBaOSc/c2boyzxxj7oacFs1P9T6U61ZsCrTu1F7GEZ 0qj6arjAGqM7fb+zyFW+BAVX+BtH/RMAkl+rfx9/tfHurEEqajhS7E+aB8BRNyuDFklW tTuw== X-Received: by 10.15.26.7 with SMTP id m7mr1647622eeu.56.1377677091582; Wed, 28 Aug 2013 01:04:51 -0700 (PDT) Received: from [192.168.1.6] ([176.73.174.236]) by mx.google.com with ESMTPSA id r48sm35114607eev.14.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 28 Aug 2013 01:04:50 -0700 (PDT) Date: Wed, 28 Aug 2013 12:04:48 +0400 From: Ioseb Dzmanashvili To: Mike Kelly Message-ID: <2815EAE84FC243169D0D4802A0169C21@gmail.com> In-Reply-To: References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Julian Reschke , IETF Apps Discuss , link-relations@ietf.org Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 28 Aug 2013 08:04:55 -0000 Hi Mike, On Wednesday, August 28, 2013 at 11:45 AM, Mike Kelly wrote: > =20 > On 28 Aug 2013 00:51, =22Ioseb Dzmanashvili=22 wrote: > > =20 > > Hi Mike, > > =20 > > Thanks for the question=21 > > =20 > > On Tuesday, August 27, 2013 at 11:57 PM, mike amundsen wrote: > > =20 > > > Ioseb: > > > =20 > > > it is not clear to me why: > > > is preferable to: > > > =20 > > > talk me down ;) > > let me try ;) > > =20 > > Question is not about why: Link: <=E2=80=A6>; rel=3D=22action=22; act= ion-type=3D=22edit=22 is preferable to: Link: <=E2=80=A6>; rel=3D=22edit=22= . > > =20 > > Of course i'd choose rel=3D=22run-forest-run=22 if there is a registe= red link relation type, but: > > =20 > > 1. The =22action=22 link relation is generic enough, has well underst= ood meaning and is useful on its own especially for human oriented agents= . > > 2. The =22action-type=22 optional attribute may be used for specifyin= g exact meaning of actions and this makes action links more useful for m2= m scenarios. > =20 > Hey Ioseb, isn't this what extension relations are for=3F =20 =40mamund perfectly summarised major goals of the spec so i'm copying it = here: 1) you want to support a *pattern* where machine-readable state transitio= n instructions appear at the end of some URL. 2) you want to indicate those instructions are available by marking the U= RL w/ the string literal =22action=22 (via rel in your illustrations) 3) you want to indicate the reason for using these instructions w/ an =22= action-type=22 string (via a link-rel param in your illustrations) Additionally semantics of extension relations may vary from application t= o application. With the =22action-type=22 optional attribute + registry o= f machine readable action type names i'm trying to address the issue of s= hared semantics and at the same time the =22action=22 relation itself sti= ll remains useful for GUI scenarios without the =22action-type=22 attribu= te. Cheers, ioseb =20 > Cheers, > M =20 From enrico.marocco@telecomitalia.it Wed Aug 28 02:02: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 861FE11E826C; Wed, 28 Aug 2013 02:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.719 X-Spam-Level: X-Spam-Status: No, score=-101.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 aVm4haM-GIEy; Wed, 28 Aug 2013 02:02:54 -0700 (PDT) Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by ietfa.amsl.com (Postfix) with ESMTP id E23FB11E8170; Wed, 28 Aug 2013 02:02:52 -0700 (PDT) Received: from grfhub701rm001.griffon.local (10.19.3.8) by GRFEDG702RM001.telecomitalia.it (10.173.88.21) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 28 Aug 2013 11:02:51 +0200 Received: from MacLab.local (10.229.8.70) by smtp.telecomitalia.it (10.19.9.234) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 28 Aug 2013 11:02:50 +0200 Message-ID: <521DBCB9.7010406@telecomitalia.it> Date: Wed, 28 Aug 2013 11:02:49 +0200 From: Enrico Marocco User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050703000106040307090109" X-TI-Disclaimer: Disclaimer1 Cc: IESG Subject: [apps-discuss] APPSDIR review of draft-ietf-dime-realm-based-redirect-11 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, 28 Aug 2013 09:02:58 -0000 --------------ms050703000106040307090109 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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-dime-realm-based-redirect-11 Title: Realm-Based Redirection In Diameter Reviewer: Enrico Marocco Review Date: August 28, 2013 IETF Last Call Date: August 27, 2013 Summary: This draft is almost ready for publication as a Proposed Standard RFC but has one major (easy-to-fix) issue and a minor issue that should be fixed before publication. Major issues: In S. 3.4, both in title and body (easy fix, but "Major" in that it's about a crucial part of the specified mechanism): s/DIAMETER_REDIRECT_INDICATION/DIAMETER_REALM_REDIRECT_INDICATION/ Minor issues: The document makes use of general terms such as "application", "domain", "realm" and "identity" that have a specific meaning in the Diameter context, but it does not provide explicit definitions. It would be useful if the document provided a list of Diamaeter-specific terms, and a pointer to where they are defined. I suggest adding to the Terminology section something along the line of: This document uses the terms "application", "realm", "domain", "identity" [..] consistently with the definitions provided in RFC 6733 (Section 1.2, Section 1.3.4, Section 2.6, [..]). Nits: This review does not include editorial nits. --------------ms050703000106040307090109 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMojCC 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 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGZjCCBU6gAwIBAgIDByD0MA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTMwNzI0MTg1NjUz WhcNMTQwNzI1MTExMzEwWjB1MRkwFwYDVQQNExBJcWRVZVdCRExxaEZ2N1hrMSgwJgYDVQQD DB9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MS4wLAYJKoZIhvcNAQkBFh9lbnJp Y28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA078rvuWkIkHhL41Zi2MjXjy5TU71hLgnrstLepYUATbwALhWSs0Kk6l8FhKrOyCl MPT8NMR5OPG91nEIloDY/AJL7GahjQXomtyqCPXWoRQL95sh+QhlCktlmGhVXm98YAcFWm8E WoanJmv7UxKhJ6bdXLADn/dtxZGNiACG2U+fBaSyUT0Sa12SQ+u59yOZNWoaLRi2tos0hbZx eKKVk7a+vxaIS5IIsvUUgJ3tGwFTsz+o3AFWLI/8U1u2LitbpKF/G91ReDA9bb10k5ay43r+ o1TigZEdHd683i7j4DIdjkY3FybFibDtzx+O054BPx5v4C4Nk8vHOHtif2czMwIDAQABo4IC 5TCCAuEwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBSjX2uvKQFc1dKQOjONZZ1hVH42cTAfBgNVHSMEGDAWgBRTcu2S nODaywFcfH6WNU7y1LhRgjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRh bGlhLml0MIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUH AgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHq MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRp ZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24g cmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcg cGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAQ9Ff1giJV3UOk090vsVroHHsBy4J4eITcDLGg+wJ+M+4kULtKS7i+kJjfd5VZb1e ZsnezvgmhmAaJRy+xl/j7l3UKbSVXfUcnKQ1IVnPVedA+4g6L8nA2cBTGj+vFScEC03HSFqy Q2Shh3AkCo1L6HLoohHxTvSi7+A4P4uayaHSC0OSdVOXWyDOrjnkSWKQiPX4jc0nJofA7b+H TppvjgzM5t+c9EQ0v8ldDfP4Pl6HhJ/xwMAETn3VG3hVuT321Gx/BXCS1TDMyUnXVf5BB+S8 vGlgwoPfX2o2ti0/ZXSt/VRUOmBF5kiePNIJ7MLOa15cbxI/2bF0xXKHEjBcETGCA90wggPZ AgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwcg9DAJBgUrDgMC GgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA4 MjgwOTAyNDlaMCMGCSqGSIb3DQEJBDEWBBTg8iWJR1H5wiNGrS4KRP88L3BusjBsBgkqhkiG 9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkr BgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDByD0 MIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgMHIPQwDQYJKoZIhvcNAQEBBQAEggEAvvjETrM1dDK6fgW7dneFyVCK95Q1szbfe1SX nNHpM/uMAe5Mme6XmCyY2LzcDHWKEi2br8RU3O7Z/yzwVXlHoQPUnKUyujTfqLVfNwNuO6yG gBftk3FFUp++BNwasEbbboQKM7ucF6LiflUBQcLZVp24+tdQjA83u4nCYtYHk17Um52KwtzG piOhS8koPYYrRj4m/SeNTl9EaSCCwndRN09aZ4DpIKN3t/g2hSjDNkRqonnLAIKbmod03FJ2 EEXeDhsXIi331Y1B+AJA4ExdEuFy/uIOzmApNGLstXmb7IZn6dsceJqjMbbOk8U3OrWivfA6 HuUKi7+FznU/Dmiu9AAAAAAAAA== --------------ms050703000106040307090109-- From mca@amundsen.com Wed Aug 28 07:34: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 2EDEE11E813A for ; Wed, 28 Aug 2013 07:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.961 X-Spam-Level: ** X-Spam-Status: No, score=2.961 tagged_above=-999 required=5 tests=[AWL=-1.174, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_92=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 ugD-6hChpKOd for ; Wed, 28 Aug 2013 07:34:00 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0E94C21F9FED for ; Wed, 28 Aug 2013 07:33:59 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id m15so5502048wgh.29 for ; Wed, 28 Aug 2013 07:33:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=gkqxgDTn+mXEwmtKWuZSBLWPRyyzMuFylS//KANAodE=; b=K+2yVaQhlXCJiImmTIJwo29Juf/DPYZfKWXsu0kSqYjSJgYq0CTE4MbaAXhGMe+nQv UYcqs/YMVO08YgAGR+f4PUigpGS7KLnuFwyKerYC3r1mVsW21cCsejfyUbm1tiVdpmwr QuoOGOqMlmsjBSLtH++Muly0TQ1h3eg1jGslQbj17Rve2BgA/dNII6N1FbVRckD2NF0E QdTwvl2E7jkWMGLreKmpVldMre//1Cj0o8SbW6cY/6F0W6DJNF1V5vDLQf8HQg9gu9PX NvFSETu10wPzDWeGG+3VS3a9Q+4sQVvpGVKh25y/qeG/X8YH8TtAYx2YTEvlPCrzA2CU BzoA== X-Gm-Message-State: ALoCoQlrlmrqOYpvqxaNaUoCaHdML3iOQdYTnI9RE+h4HXTFhPYXR+r62eSKSSbvTsL+uItIngJv X-Received: by 10.194.133.167 with SMTP id pd7mr2942855wjb.56.1377700439031; Wed, 28 Aug 2013 07:33:59 -0700 (PDT) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.151.7 with HTTP; Wed, 28 Aug 2013 07:33:38 -0700 (PDT) In-Reply-To: <8410EE3EC8FB4ADA93F4209376AF8183@gmail.com> References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <8410EE3EC8FB4ADA93F4209376AF8183@gmail.com> From: mike amundsen Date: Wed, 28 Aug 2013 10:33:38 -0400 X-Google-Sender-Auth: 8dkwG3SBxVq3FMBh_uiqOAx3oHg Message-ID: To: Ioseb Dzmanashvili Content-Type: multipart/alternative; boundary=089e012292e64696e204e502e1a4 Cc: Julian Reschke , IETF Apps Discuss , link-relations Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 28 Aug 2013 14:34:04 -0000 --089e012292e64696e204e502e1a4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ioseb: now that i understand your aim... it seems the first item (support a pattern...) is the important one and the other two are just means to that end. so why is this a good approach? 1) why use the "action" rel PLUS a param ("start")? why not just use the param ("start") as the rel? 2) why not use two values for the rel as in ? 3) why not use (as mike kelly suggests) an extension URI for the rel as in 4) why not use a unique element attribute/property such as ? 5) why not use a unique document element/property such as or {"action": {"rel":"start", "href":"..."}}? 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/mikeamundsen On Wed, Aug 28, 2013 at 3:35 AM, Ioseb Dzmanashvili < ioseb.dzmanashvili@gmail.com> wrote: > Mike, > > On Wednesday, August 28, 2013 at 5:26 AM, mike amundsen wrote: > > > OK, from your response i get the following: > > > > 1) you want to support a pattern where machine-readable state transitio= n > instructions appear at the end of some URL. > > 2) you want to indicate those instructions are available by marking the > URL w/ the string literal "action" (via rel in your illustrations) > > 3) you want to indicate the reason for using these instructions w/ an > "action-type" string (via a link-rel param in your illustrations) > > > > that's it. nothing else. > > > > do i have this correct? > > > > Exactly! That's it and nothing else. > > Cheers, > ioseb > > > > > > > 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/mikeamundsen > > > > On Tue, Aug 27, 2013 at 7:51 PM, Ioseb Dzmanashvili < > ioseb.dzmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com)> wrote= : > > > Hi Mike, > > > > > > Thanks for the question! > > > > > > On Tuesday, August 27, 2013 at 11:57 PM, mike amundsen wrote: > > > > > > > Ioseb: > > > > > > > > it is not clear to me why: href=3D"..." /> > > > > is preferable to: > > > > > > > > talk me down ;) > > > let me try ;) > > > > > > Question is not about why: Link: <=85>; rel=3D"action"; action-type= =3D"edit" > is preferable to: Link: <=85>; rel=3D"edit". > > > > > > Of course i'd choose rel=3D"run-forest-run" if there is a registered > link relation type, but: > > > > > > 1. The "action" link relation is generic enough, has well understood > meaning and is useful on its own especially for human oriented agents. > > > 2. The "action-type" optional attribute may be used for specifying > exact meaning of actions and this makes action links more useful for m2m > scenarios. > > > > > > Now consider this link: > > > > > > Link: ; rel=3D"action"; action-type=3D"suspend"; > title=3D"Suspend" > > > > > > What it says? > > > > > > 1. it is an action > > > 2. target resource represents description of the action which > contains: request method, submit URI, definition of action, other details > etc > > > 3. agent can look inside "action-type" to determine whether it needs > this action type or not > > > 4. agent can dereference it, construct request and send it to server > > > > > > > > > now if we add more actions: > > > > > > Link: ; rel=3D"action"; action-type=3D"suspend"; > title=3D"Suspend" > > > Link: ; rel=3D"action"; action-type=3D"restart"; > title=3D"Restart" > > > > > > Link: ; rel=3D"action"; action-type=3D"stop"; title=3D"= Stop" > > > > > > > > > #1, #2, #3 and #4 will be true for all of them without exceptions. > > > > > > Now consider that representation containing these links is used by GU= I > agent, in this case even "action-type" is not necessary at all and agent > can rely on user's choice. Agent only needs to know that: > > > > > > 1. link is an action(and this question is explicitly answered) > > > 2. if user choose one agent needs just to dereference indicated URI > > > 3. construct request > > > 4. send request to server > > > 5. show results to user > > > > > > All of these will remain true for any action type. > > > > > > I'm not sure if i talked you down, but i believe "action" relation > type is useful and not because it is better(or simpler) compared to > rel=3D"edit" for example. > > > > > > 1. > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-= 00 > > > 2. > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-= 01 > > > > > > P.S. > > > I was talking about 01 version of spec. 00 is a different story. > > > > > > Cheers, > > > ioseb > > > > mamund > > > > +1.859.757.1449 (tel:%2B1.859.757.1449) > > > > skype: mca.amundsen > > > > http://amundsen.com/blog/ > > > > http://twitter.com/mamund > > > > https://github.com/mamund > > > > http://www.linkedin.com/in/mikeamundsen > > > > > > > > > > > > > > > > On Tue, Aug 27, 2013 at 3:40 PM, Ioseb Dzmanashvili < > ioseb.dzmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com) > (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.co= m)> > wrote: > > > > > Hi Julian, > > > > > > > > > > Thanks for response! > > > > > > > > > > On Tuesday, August 27, 2013 at 2:15 PM, Julian Reschke wrote: > > > > > > > > > > > On 2013-08-27 11:03, Ioseb Dzmanashvili wrote: > > > > > > > Hi All, > > > > > > > > > > > > > > I've updated the "action" link relation type spec[1] based on > initial feedback. > > > > > > > > > > > > > > As far as initial reactions were very controversial and raise= d > a lot of issues i tried to address all of them and entirely changed the > spec. > > > > > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > > > > > > When included in a response, the "action" link relation > indicates a > > > > > > > target resource that is responsible for performing action > which MAY: > > > > > > > > > > > > > > - Affect state of the context resource; or > > > > > > > - Initiate process. > > > > > > > > > > > > > > The "action" link relation type can be used to indicate the > > > > > > > availability of actions supported by the target resource. > Examples > > > > > > > of such actions include: > > > > > > > > > > > > > > - Enable/Disable > > > > > > > - Publish/Unpublish > > > > > > > - Start/Stop > > > > > > > > > > > > > > The "action" link relation type doesn't convey any semantics > other > > > > > > > than that an indicated resources represent machine readable > > > > > > > description of a particular action and representation SHOULD > contain > > > > > > > all necessary details such as: request method, action URI and > other > > > > > > > related details to enable agents to be able to construct > requests > > > > > > > without relying on out-of-band information. > > > > > > > > > > > > > > Exact type of action SHOULD be indicated through the > "action-type" > > > > > > > link-extension value as per [RFC5988] and for maintaining > shared > > > > > > > understanding of action types current specification introduce= s > the > > > > > > > registry of actions with initial values of widely accepted an= d > well > > > > > > > understood action types. > > > > > > > > > > > > > > For example, if a resource represents a service, that same > > > > > > > representation may include links to resources that represent > actions > > > > > > > supported by the service: > > > > > > > > > > > > > > Link: ; rel=3D"action"; action-type=3D"resta= rt" > > > > > > > Link: ; rel=3D"action"; action-type=3D"stop" > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It seems that you are just adding an indirection mechanism. Why > is that > > > > > > necessary? > > > > > > > > > > > > > > > > > > > > With indirection mechanism i'm trying to solve issues raised > around initial version of the spec[1]. There were several issues: > > > > > > > > > > 1. The "action" link relation type doesn't have enough semantics > and automated agents can not follow such links if there are several actio= ns > included in a representation. With the "action-type" link extension + > registry of predefined action types agents can distinguish actions from > each other. > > > > > > > > > > 2. Initial spec stated that if the "action" link exists in > representation, only thing agents should do is to send empty POST request > to the target in order to perform action. This approach was considered as > an anti pattern(RPCish and non RESTful). With having the "action-type" > agents can: > > > > > > > > > > a) distinguish action links from each other; > > > > > b) if necessary dereference the target to obtain instructions for > constructing non empty POST/PUT requests; > > > > > c) send properly constructed request back to the target; and > > > > > d) it makes possible for servers to dictate structure of the > request according to there own needs. > > > > > > > > > > Main purpose of the "action" link relation type is to define > semantics of particular class of links - actions. This eliminates the nee= d > to redefine notion of "action" for each link relation type which may be > qualified as action link. The "action-type" is just for naming actions an= d > is particularly useful for automated agents not necessarily for human > interaction oriented agents. > > > > > > > > > > Having action type registry is important for maintaining shared > understanding of particular action types. For example "reset" or "publish= " > verbs do not need to be redefined from application to application. I also > believe that it is not efficient(or feasible) to register all possible > actions as link relations. > > > > > > > > > > 1. > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-= 00 > > > > > 2. > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-= 01 > > > > > > > > > > > > Best regards, Julian > > > > > Cheers, > > > > > ioseb > > > > > > > > > > _______________________________________________ > > > > > link-relations mailing list > > > > > link-relations@ietf.org (mailto:link-relations@ietf.org) (mailto: > link-relations@ietf.org) (mailto:link-relations@ietf.org) > > > > > https://www.ietf.org/mailman/listinfo/link-relations > > > > > > > > > > > > > --089e012292e64696e204e502e1a4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Ioseb:

now that i understand your= aim...

it seems the first item (suppo= rt a pattern...) is the important one and the other two are just means to t= hat end. =A0so why is this a good approach?

1) why use the "action" rel PLUS = a param ("start")? why not just use the param ("start")= as the rel?
2) why not use two values for the rel as in &l= t;LINK rel=3D"action start" />?
3) why not use (as mike kelly suggests) an extension URI for the= rel as in <LINK rel=3D"http://= actions.io/start" ... />
4) why not use a uniqu= e element attribute/property such as <LINK rel=3D"action" reas= on=3D"start" .../>?=A0
5) why not use a unique document element/property such as <ac= tion rel=3D"start" href=3D"..."/> or {"action&q= uot;: {"rel":"start", "href":"..."}= }?=A0


=


On Wed, Aug 28, 2013 at 3:35 AM, Ioseb D= zmanashvili <ioseb.dzmanashvili@gmail.com> wrote:=
Mike,

On Wednesday, August 28, 2013 at 5:26 AM, mike amundsen wrote:

> OK, from your response i get the following:
>
> 1) you want to support a pattern where machine-readable state transiti= on instructions appear at the end of some URL.
> 2) you want to indicate those instructions are available by marking th= e URL w/ the string literal "action" (via rel in your illustratio= ns)
> 3) you want to indicate the reason for using these instructions w/ an = "action-type" string (via a link-rel param in your illustrations)=
>
> that's it. nothing else.
>
> do i have this correct?
>

Exactly! That's it and nothing else.

Cheers,
ioseb

>
>
> mamund
> +1.859.757.14= 49
> skype: mca.amundsen
> http://amundse= n.com/blog/
> http://twitter= .com/mamund
> https://github= .com/mamund
> = http://www.linkedin.com/in/mikeamundsen
>
> On Tue, Aug 27, 2013 at 7:51 PM, Ioseb Dz= manashvili <ioseb.dzmana= shvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com)> wrote:
> > Hi Mike,
> >
> > Thanks for the question!
> >
> > On Tuesday, August 27, 2013 at 11:57 PM, mike amundsen wrote:
> >
> > > Ioseb:
> > >
> > > it is not clear to me why: <link rel=3D"action;actio= n-type=3D'edit'" href=3D"..." />
> > > is preferable to: <link rel=3D"edit" href=3D&qu= ot;..." />
> > >
> > > talk me down ;)
> > let me try ;)
> >
> > Question is not about why: Link: <=85>; rel=3D"action&= quot;; action-type=3D"edit" is preferable to: Link: <=85>; = rel=3D"edit".
> >
> > Of course i'd choose rel=3D"run-forest-run" if ther= e is a registered link relation type, but:
> >
> > 1. The "action" link relation is generic enough, has we= ll understood meaning and is useful on its own especially for human oriente= d agents.
> > 2. The "action-type" optional attribute may be used for= specifying exact meaning of actions and this makes action links more usefu= l for m2m scenarios.
> >
> > Now consider this link:
> >
> > Link: </suspend-action>; rel=3D"action"; action-t= ype=3D"suspend"; title=3D"Suspend"
> >
> > What it says?
> >
> > 1. it is an action
> > 2. target resource represents description of the action which con= tains: request method, submit URI, definition of action, other details etc<= br> > > 3. agent can look inside "action-type" to determine whe= ther it needs this action type or not
> > 4. agent can dereference it, construct request and send it to ser= ver
> >
> >
> > now if we add more actions:
> >
> > Link: </suspend-action>; rel=3D"action"; action-t= ype=3D"suspend"; title=3D"Suspend"
> > Link: </restart-action>; rel=3D"action"; action-t= ype=3D"restart"; title=3D"Restart"
> >
> > Link: </stop-action>; rel=3D"action"; action-type= =3D"stop"; title=3D"Stop"
> >
> >
> > #1, #2, #3 and #4 will be true for all of them without exceptions= .
> >
> > Now consider that representation containing these links is used b= y GUI agent, in this case even "action-type" is not necessary at = all and agent can rely on user's choice. Agent only needs to know that:=
> >
> > 1. link is an action(and this question is explicitly answered) > > 2. if user choose one agent needs just to dereference indicated U= RI
> > 3. construct request
> > 4. send request to server
> > 5. show results to user
> >
> > All of these will remain true for any action type.
> >
> > I'm not sure if i talked you down, but i believe "action= " relation type is useful and not because it is better(or simpler) com= pared to rel=3D"edit" for example.
> >
> > 1. http://tools.ietf.org/html/draf= t-ioseb-dzmanashvili-action-link-relation-00
> > 2. http://tools.ietf.org/html/draf= t-ioseb-dzmanashvili-action-link-relation-01
> >
> > P.S.
> > I was talking about 01 version of spec. 00 is a different story.<= br> > >
> > Cheers,
> > ioseb
> > > mamund
> > > +1.859.757.1449 (tel:%2B1.859.757.1449)
> > > skype: mca.amundsen
> > > http= ://amundsen.com/blog/
> > > http= ://twitter.com/mamund
> > > http= s://github.com/mamund
> > > http://www.linkedin.com/in/mikeamundsen
> > >
> > >
> > >
> > > On Tue, Aug 27, 2013 at 3:40 PM= , Ioseb Dzmanashvili <io= seb.dzmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.com)= > wrote:
> > > > Hi Julian,
> > > >
> > > > Thanks for response!
> > > >
> > > > On Tuesday, August 27, 2013 at 2:15 PM, Julian Reschke = wrote:
> > > >
> > > > > On 2013-08-27 11:03, Ioseb Dzmanashvili wrote:
> > > > > > Hi All,
> > > > > >
> > > > > > I've updated the "action" link = relation type spec[1] based on initial feedback.
> > > > > >
> > > > > > As far as initial reactions were very controv= ersial and raised a lot of issues i tried to address all of them and entire= ly changed the spec.
> > > > > >
> > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > > > When included in a response, the "action= " link relation indicates a
> > > > > > target resource that is responsible for perfo= rming action which MAY:
> > > > > >
> > > > > > - Affect state of the context resource; or > > > > > > - Initiate process.
> > > > > >
> > > > > > The "action" link relation type can= be used to indicate the
> > > > > > availability of actions supported by the targ= et resource. Examples
> > > > > > of such actions include:
> > > > > >
> > > > > > - Enable/Disable
> > > > > > - Publish/Unpublish
> > > > > > - Start/Stop
> > > > > >
> > > > > > The "action" link relation type doe= sn't convey any semantics other
> > > > > > than that an indicated resources represent ma= chine readable
> > > > > > description of a particular action and repres= entation SHOULD contain
> > > > > > all necessary details such as: request method= , action URI and other
> > > > > > related details to enable agents to be able t= o construct requests
> > > > > > without relying on out-of-band information. > > > > > >
> > > > > > Exact type of action SHOULD be indicated thro= ugh the "action-type"
> > > > > > link-extension value as per [RFC5988] and for= maintaining shared
> > > > > > understanding of action types current specifi= cation introduces the
> > > > > > registry of actions with initial values of wi= dely accepted and well
> > > > > > understood action types.
> > > > > >
> > > > > > For example, if a resource represents a servi= ce, that same
> > > > > > representation may include links to resources= that represent actions
> > > > > > supported by the service:
> > > > > >
> > > > > > Link: </restart-action>; rel=3D"ac= tion"; action-type=3D"restart"
> > > > > > Link: </stop-action>; rel=3D"actio= n"; action-type=3D"stop"
> > > > > > ...
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > It seems that you are just adding an indirection m= echanism. Why is that
> > > > > necessary?
> > > >
> > > >
> > > >
> > > > With indirection mechanism i'm trying to solve issu= es raised around initial version of the spec[1]. There were several issues:=
> > > >
> > > > 1. The "action" link relation type doesn'= t have enough semantics and automated agents can not follow such links if t= here are several actions included in a representation. With the "actio= n-type" link extension + registry of predefined action types agents ca= n distinguish actions from each other.
> > > >
> > > > 2. Initial spec stated that if the "action" l= ink exists in representation, only thing agents should do is to send empty = POST request to the target in order to perform action. This approach was co= nsidered as an anti pattern(RPCish and non RESTful). With having the "= action-type" agents can:
> > > >
> > > > a) distinguish action links from each other;
> > > > b) if necessary dereference the target to obtain instru= ctions for constructing non empty POST/PUT requests;
> > > > c) send properly constructed request back to the target= ; and
> > > > d) it makes possible for servers to dictate structure o= f the request according to there own needs.
> > > >
> > > > Main purpose of the "action" link relation ty= pe is to define semantics of particular class of links - actions. This elim= inates the need to redefine notion of "action" for each link rela= tion type which may be qualified as action link. The "action-type"= ; is just for naming actions and is particularly useful for automated agent= s not necessarily for human interaction oriented agents.
> > > >
> > > > Having action type registry is important for maintainin= g shared understanding of particular action types. For example "reset&= quot; or "publish" verbs do not need to be redefined from applica= tion to application. I also believe that it is not efficient(or feasible) t= o register all possible actions as link relations.
> > > >
> > > > 1. http://tools.ietf.org= /html/draft-ioseb-dzmanashvili-action-link-relation-00
> > > > 2. http://tools.ietf.org= /html/draft-ioseb-dzmanashvili-action-link-relation-01
> > > > >
> > > > > Best regards, Julian
> > > > Cheers,
> > > > ioseb
> > > >
> > > > _______________________________________________
> > > > link-relations mailing list
> > > > = link-relations@ietf.org (mailto:link-relations@ietf.org) (mailto:link-relations@ietf.org) (mailto:link-relations@ietf.org)
> > > > https://www.ietf.org/mailman/listinfo/link-rela= tions
> > >
> >
>




--089e012292e64696e204e502e1a4-- From jasnell@gmail.com Wed Aug 28 08:32: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 3BD1A11E8197; Wed, 28 Aug 2013 08:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dw8N8B2bk2YC; Wed, 28 Aug 2013 08:32:22 -0700 (PDT) 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 9641211E8191; Wed, 28 Aug 2013 08:32:22 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id n10so2272881oag.27 for ; Wed, 28 Aug 2013 08:32:19 -0700 (PDT) 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=4iihFU9wYdtOITvtlEPy46xSnpRXBIN/axCHrsGJWbc=; b=SljaCUz/AVfJd9EAxhmi2PQgVIuxbZedcw4DbWfoA1k6GC2Uv9rqJGm8tFLVCLpijm wwNa+qDgpRdZs9H3V2CHNPOR31mvdiT+NydlClMsNQeAD/qSZlOboDpWMQJD+epTdnZ8 ryirzqkNrajQfE4vNFG7U6zT8fqqTQ0jIBPEoJFX/3QH28gupgD6S3fMEEvxRSP1Ukxj g/g6iARyu5i3i0UVGCAoKLvqDCHi+NsWjhSjU7fT5IsT3SPi5+mp6PKX/I7LSzxf1Oq2 YwQwEdz5UqPK47fshUA/J+keNaFyL2N7+o8wgm9HlO3L8TymUAs+xrFVKCIIDhcm/TYf gxXQ== X-Received: by 10.60.60.5 with SMTP id d5mr24025443oer.0.1377703939203; Wed, 28 Aug 2013 08:32:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.124.137 with HTTP; Wed, 28 Aug 2013 08:31:59 -0700 (PDT) In-Reply-To: <2815EAE84FC243169D0D4802A0169C21@gmail.com> References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <2815EAE84FC243169D0D4802A0169C21@gmail.com> From: James M Snell Date: Wed, 28 Aug 2013 08:31:59 -0700 Message-ID: To: Ioseb Dzmanashvili Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Mike Kelly , Julian Reschke , IETF Apps Discuss , link-relations Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 28 Aug 2013 15:32:23 -0000 I'm still struggling to see the value of a generic "action" link relation here. If I have a set of link relations that I happen to want to mark as "action", I would prefer to eliminate the indirection and simply "flag" the links, for instance: Link: ; rel=3D"restart"; action or in HTML or... This approach would skip the additional registration mechanism for action-type and would allow any link relation to potentially be marked as an action... which seems appropriate. - James On Wed, Aug 28, 2013 at 1:04 AM, Ioseb Dzmanashvili wrote: > Hi Mike, > > On Wednesday, August 28, 2013 at 11:45 AM, Mike Kelly wrote: > >> >> On 28 Aug 2013 00:51, "Ioseb Dzmanashvili" wrote: >> > >> > Hi Mike, >> > >> > Thanks for the question! >> > >> > On Tuesday, August 27, 2013 at 11:57 PM, mike amundsen wrote: >> > >> > > Ioseb: >> > > >> > > it is not clear to me why: >> > > is preferable to: >> > > >> > > talk me down ;) >> > let me try ;) >> > >> > Question is not about why: Link: <=E2=80=A6>; rel=3D"action"; action-t= ype=3D"edit" is preferable to: Link: <=E2=80=A6>; rel=3D"edit". >> > >> > Of course i'd choose rel=3D"run-forest-run" if there is a registered l= ink relation type, but: >> > >> > 1. The "action" link relation is generic enough, has well understood m= eaning and is useful on its own especially for human oriented agents. >> > 2. The "action-type" optional attribute may be used for specifying exa= ct meaning of actions and this makes action links more useful for m2m scena= rios. >> >> Hey Ioseb, isn't this what extension relations are for? > > > > @mamund perfectly summarised major goals of the spec so i'm copying it he= re: > > 1) you want to support a *pattern* where machine-readable state transitio= n instructions appear at the end of some URL. > 2) you want to indicate those instructions are available by marking the U= RL w/ the string literal "action" (via rel in your illustrations) > 3) you want to indicate the reason for using these instructions w/ an "ac= tion-type" string (via a link-rel param in your illustrations) > > > > Additionally semantics of extension relations may vary from application t= o application. With the "action-type" optional attribute + registry of mach= ine readable action type names i'm trying to address the issue of shared se= mantics and at the same time the "action" relation itself still remains use= ful for GUI scenarios without the "action-type" attribute. > > Cheers, > ioseb > >> Cheers, >> M > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From mikekelly321@gmail.com Wed Aug 28 00:45: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 C9EE911E815B; Wed, 28 Aug 2013 00:45:10 -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, 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 iwrHTVQX+yDb; Wed, 28 Aug 2013 00:45:10 -0700 (PDT) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id DEA4421F9F0E; Wed, 28 Aug 2013 00:45:09 -0700 (PDT) Received: by mail-ee0-f51.google.com with SMTP id c1so2687505eek.24 for ; Wed, 28 Aug 2013 00:45:09 -0700 (PDT) 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=TtTHCfcK0VWM/iLMwMqqtkH96x7cJN6Ku6u82phPWIo=; b=PTgW6x/F67Gvb0XInk9hZ5OJjGAVV903WNTbqgssJjRBNmWWrjLInpv39m9qva3FO8 i/Da4VGpcYCPTDKgMQE34fOg6j7LJAd1NgAG5WbL6CEKKWWlU3MnN0hVV2OBogMu6fZC kocEnCOpxNG9FX2yiCI/ZrvI8Xi73YznubpP0yGN4kZkmuckqXq1wogdOp97CY3c2kvp 6H3vAbfHga9B29w9+KWkGtIAkFjDZ6OP/i2fNRwYb/fw0/Gr/Se3tO5bWET09rzpOSKX eJGX9bRVI4+1OPVjt0/TPAsrjNgO5kFcEwVCuML6dMgBh2l30OjIwGbdshFsrVgxepqG 9wrg== MIME-Version: 1.0 X-Received: by 10.15.36.9 with SMTP id h9mr41753874eev.30.1377675909016; Wed, 28 Aug 2013 00:45:09 -0700 (PDT) Received: by 10.223.172.193 with HTTP; Wed, 28 Aug 2013 00:45:08 -0700 (PDT) Received: by 10.223.172.193 with HTTP; Wed, 28 Aug 2013 00:45:08 -0700 (PDT) In-Reply-To: <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> Date: Wed, 28 Aug 2013 08:45:08 +0100 Message-ID: From: Mike Kelly To: Ioseb Dzmanashvili Content-Type: multipart/alternative; boundary=089e0160cd802c50a604e4fd2b3d X-Mailman-Approved-At: Wed, 28 Aug 2013 09:30:50 -0700 Cc: Julian Reschke , IETF Apps Discuss , link-relations@ietf.org Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 28 Aug 2013 07:45:10 -0000 --089e0160cd802c50a604e4fd2b3d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 28 Aug 2013 00:51, "Ioseb Dzmanashvili" wrote: > > Hi Mike, > > Thanks for the question! > > On Tuesday, August 27, 2013 at 11:57 PM, mike amundsen wrote: > > > Ioseb: > > > > it is not clear to me why: > > is preferable to: > > > > talk me down ;) > let me try ;) > > Question is not about why: Link: <=85>; rel=3D"action"; action-type=3D"ed= it" is preferable to: Link: <=85>; rel=3D"edit". > > Of course i'd choose rel=3D"run-forest-run" if there is a registered link relation type, but: > > 1. The "action" link relation is generic enough, has well understood meaning and is useful on its own especially for human oriented agents. > 2. The "action-type" optional attribute may be used for specifying exact meaning of actions and this makes action links more useful for m2m scenarios. > Hey Ioseb, isn't this what extension relations are for? Cheers, M --089e0160cd802c50a604e4fd2b3d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


On 28 Aug 2013 00:51, "Ioseb Dzmanashvili" <ioseb.dzmanashvili@gmail.com> wrote: >
> Hi Mike,
>
> Thanks for the question!
>
> On Tuesday, August 27, 2013 at 11:57 PM, mike amundsen wrote:
>
> > Ioseb:
> >
> > it is not clear to me why: <link rel=3D"action;action-typ= e=3D'edit'" href=3D"..." />
> > is preferable to: <link rel=3D"edit" href=3D"..= ." />
> >
> > talk me down ;)
> let me try ;)
>
> Question is not about why: Link: <=85>; rel=3D"action"= ; action-type=3D"edit" is preferable to: Link: <=85>; rel= =3D"edit".
>
> Of course i'd choose rel=3D"run-forest-run" if there is = a registered link relation type, but:
>
> 1. The "action" link relation is generic enough, has well un= derstood meaning and is useful on its own especially for human oriented age= nts.
> 2. The "action-type" optional attribute may be used for spec= ifying exact meaning of actions and this makes action links more useful for= m2m scenarios.
>

Hey Ioseb, isn't this what extension relations are for?<= /p>

Cheers,
M

--089e0160cd802c50a604e4fd2b3d-- From pezra@barelyenough.org Wed Aug 28 07:15: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 68BF421E8050 for ; Wed, 28 Aug 2013 07:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[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 23aAH8SzmJAx for ; Wed, 28 Aug 2013 07:15:09 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by ietfa.amsl.com (Postfix) with ESMTP id 904CC21E8082 for ; Wed, 28 Aug 2013 07:15:02 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id u14so3764503lbd.26 for ; Wed, 28 Aug 2013 07:15:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7oHB79dgqaHyPdapDLckUC9e7p3ZWbxSu8MMEy2CuJY=; b=Gqe/HwoPdIVSWwp5yvC65mnPqI9ZUdndnvgAwNTA0pKfkLPGJuWsdfLQIwUpLT2euP qrA1snWpfWISQwoZ8jEwTYXBL0hByjr/tW6+ZNp/nHve9O/WwC/UX1r5+Sr+AmWTMbEW E2ISmxUD3eI2ArJ8xGzF2wASkawMAZBpZLmZknHaCSDXnd66QqEoX4fmrhK7o9FNMz/R y8G8mZHUnUr1sHt+30uIso29A2aH4ez3sHNpc7FdIm3Rdtw0ciFerIkZVN5anawte4QC ypS1Jj/zrh/PoJLpjn6g+hwFiZVjQ5UzhD6f29tPEsTQs8lh/dN3azCkhYCH4nCPf1li Rwiw== X-Gm-Message-State: ALoCoQlspdwCC2Z5ls9Hyzfk/YBzaTxCjO1IupIJLFgsYQN5zQjV/iPEre9Pd/x4P6wcGNlCO6xJ MIME-Version: 1.0 X-Received: by 10.152.22.65 with SMTP id b1mr356926laf.46.1377699300001; Wed, 28 Aug 2013 07:15:00 -0700 (PDT) Received: by 10.114.75.137 with HTTP; Wed, 28 Aug 2013 07:14:59 -0700 (PDT) Received: by 10.114.75.137 with HTTP; Wed, 28 Aug 2013 07:14:59 -0700 (PDT) In-Reply-To: <2815EAE84FC243169D0D4802A0169C21@gmail.com> References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <2815EAE84FC243169D0D4802A0169C21@gmail.com> Date: Wed, 28 Aug 2013 08:14:59 -0600 Message-ID: From: Peter Williams To: Ioseb Dzmanashvili Content-Type: multipart/alternative; boundary=089e0158b92a6258d604e5029de0 X-Mailman-Approved-At: Wed, 28 Aug 2013 09:31:17 -0700 Cc: apps-discuss@ietf.org, link-relations@ietf.org Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 28 Aug 2013 14:15:13 -0000 --089e0158b92a6258d604e5029de0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I have a question about how this might affect future relationship registrations. Consider the following scenario: This proposal is adopted. As many apps begin exposing `start` links it becomes obvious that start is a really common relationship. A proposal is made to register a top level relationship `start`. (I am using `start` purely for example purposes, this scenario works for any registered action type.) In this case would you expect the new relationship registration to be a) rejected on the grounds that you can already accomplish it via the action+action-type approach, b) accepted and the action relation updated to declare the start action type archaic, c) accepted and action relation to left as is, leaving it up to implementers to decide which approach to use for themselves? (Or perhaps there is a option I have over looked.) What are the implications for existing representations and consumers under that outcome? What about new representations and consumers? Cheers, Peter Hi Mike, On Wednesday, August 28, 2013 at 11:45 AM, Mike Kelly wrote: > > On 28 Aug 2013 00:51, "Ioseb Dzmanashvili" wrote: > > > > Hi Mike, > > > > Thanks for the question! > > > > On Tuesday, August 27, 2013 at 11:57 PM, mike amundsen wrote: > > > > > Ioseb: > > > > > > it is not clear to me why: > > > is preferable to: > > > > > > talk me down ;) > > let me try ;) > > > > Question is not about why: Link: <=85>; rel=3D"action"; action-type=3D"= edit" is preferable to: Link: <=85>; rel=3D"edit". > > > > Of course i'd choose rel=3D"run-forest-run" if there is a registered li= nk relation type, but: > > > > 1. The "action" link relation is generic enough, has well understood meaning and is useful on its own especially for human oriented agents. > > 2. The "action-type" optional attribute may be used for specifying exact meaning of actions and this makes action links more useful for m2m scenarios. > > Hey Ioseb, isn't this what extension relations are for? @mamund perfectly summarised major goals of the spec so i'm copying it here= : 1) you want to support a *pattern* where machine-readable state transition instructions appear at the end of some URL. 2) you want to indicate those instructions are available by marking the URL w/ the string literal "action" (via rel in your illustrations) 3) you want to indicate the reason for using these instructions w/ an "action-type" string (via a link-rel param in your illustrations) Additionally semantics of extension relations may vary from application to application. With the "action-type" optional attribute + registry of machine readable action type names i'm trying to address the issue of shared semantics and at the same time the "action" relation itself still remains useful for GUI scenarios without the "action-type" attribute. Cheers, ioseb > Cheers, > M _______________________________________________ link-relations mailing list link-relations@ietf.org https://www.ietf.org/mailman/listinfo/link-relations --089e0158b92a6258d604e5029de0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I have a question about how this might affect future relatio= nship registrations. Consider the following scenario:

This proposal is adopted. As many apps begin exposing `start= ` links it becomes obvious that start is a really common relationship. A pr= oposal is made to register a top level relationship `start`. (I am using `s= tart` purely for example purposes, this scenario works for any registered a= ction type.)

In this case would you expect the new relationship registrat= ion to be a) rejected on the grounds that you can already accomplish it via= the action+action-type approach, b) accepted and the action relation updat= ed to declare the start action type archaic, c) accepted and action relatio= n to left as is, leaving it up to implementers to decide which approach to = use for themselves? (Or perhaps there is a option I have over looked.) What= are the implications for existing representations and consumers under that= outcome? What about new representations and consumers?

Cheers,
Peter

Hi Mike,

On Wednesday, August 28, 2013 at 11:45 AM, Mike Kelly wrote:

>
> On 28 Aug 2013 00:51, "Ioseb Dzmanashvili" <ioseb.dzmanashvili@gmail.com (mailto= :ioseb.dzmanashvili@gmail.c= om)> wrote:
> >
> > Hi Mike,
> >
> > Thanks for the question!
> >
> > On Tuesday, August 27, 2013 at 11:57 PM, mike amundsen wrote:
> >
> > > Ioseb:
> > >
> > > it is not clear to me why: <link rel=3D"action;actio= n-type=3D'edit'" href=3D"..." />
> > > is preferable to: <link rel=3D"edit" href=3D&qu= ot;..." />
> > >
> > > talk me down ;)
> > let me try ;)
> >
> > Question is not about why: Link: <=85>; rel=3D"action&= quot;; action-type=3D"edit" is preferable to: Link: <=85>; = rel=3D"edit".
> >
> > Of course i'd choose rel=3D"run-forest-run" if ther= e is a registered link relation type, but:
> >
> > 1. The "action" link relation is generic enough, has we= ll understood meaning and is useful on its own especially for human oriente= d agents.
> > 2. The "action-type" optional attribute may be used for= specifying exact meaning of actions and this makes action links more usefu= l for m2m scenarios.
>
> Hey Ioseb, isn't this what extension relations are for?



@mamund perfectly summarised major goals of the spec so i'm copying it = here:

1) you want to support a *pattern* where machine-readable state transition = instructions appear at the end of some URL.
2) you want to indicate those instructions are available by marking the URL= w/ the string literal "action" (via rel in your illustrations) 3) you want to indicate the reason for using these instructions w/ an "= ;action-type" string (via a link-rel param in your illustrations)



Additionally semantics of extension relations may vary from application to = application. With the "action-type" optional attribute + registry= of machine readable action type names i'm trying to address the issue = of shared semantics and at the same time the "action" relation it= self still remains useful for GUI scenarios without the "action-type&q= uot; attribute.

Cheers,
ioseb

> Cheers,
> M



_______________________________________________
link-relations mailing list
link-relations@ietf.org
https://www.ietf.org/mailman/listinfo/link-relations
--089e0158b92a6258d604e5029de0-- From lionel.morand@orange.com Wed Aug 28 03:32: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 B772C11E81B7; Wed, 28 Aug 2013 03:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.229, 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 HBlLvgnOo5F9; Wed, 28 Aug 2013 03:32:03 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E25AD11E816F; Wed, 28 Aug 2013 03:32:02 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 90A7318C50F; Wed, 28 Aug 2013 12:32:01 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 7189C2380D3; Wed, 28 Aug 2013 12:32:01 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Wed, 28 Aug 2013 12:32:01 +0200 From: To: Enrico Marocco , "apps-discuss@ietf.org" , "draft-ietf-dime-realm-based-redirect.all@tools.ietf.org" Thread-Topic: APPSDIR review of draft-ietf-dime-realm-based-redirect-11 Thread-Index: AQHOo81nZ8bK8Unm4kq1V+hCC3XKapmqaCEQ Date: Wed, 28 Aug 2013 10:32:00 +0000 Message-ID: <6B7134B31289DC4FAF731D844122B36E257025@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <521DBCB9.7010406@telecomitalia.it> In-Reply-To: <521DBCB9.7010406@telecomitalia.it> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0014_01CEA3E8.D5F42310" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.28.100630 X-Mailman-Approved-At: Wed, 28 Aug 2013 09:31:26 -0700 Cc: IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-dime-realm-based-redirect-11 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, 28 Aug 2013 10:32:07 -0000 ------=_NextPart_000_0014_01CEA3E8.D5F42310 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Enrico, Thank you for the review and the good catches. This will be easily fixed in the new version that the authors will = produce soon. Regards, Lionel -----Message d'origine----- De=A0: Enrico Marocco [mailto:enrico.marocco@telecomitalia.it]=20 Envoy=E9=A0: mercredi 28 ao=FBt 2013 11:03 =C0=A0: apps-discuss@ietf.org; draft-ietf-dime-realm-based-redirect.all@tools.ietf.org Cc=A0: IESG Objet=A0: APPSDIR review of draft-ietf-dime-realm-based-redirect-11 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-dime-realm-based-redirect-11 Title: Realm-Based Redirection In Diameter Reviewer: Enrico Marocco Review Date: August 28, 2013 IETF Last Call Date: August 27, 2013 Summary: This draft is almost ready for publication as a Proposed Standard RFC but has one major (easy-to-fix) issue and a minor issue that should be fixed before publication. Major issues: In S. 3.4, both in title and body (easy fix, but "Major" in that it's about a crucial part of the specified mechanism): s/DIAMETER_REDIRECT_INDICATION/DIAMETER_REALM_REDIRECT_INDICATION/ Minor issues: The document makes use of general terms such as "application", "domain", "realm" and "identity" that have a specific meaning in the Diameter context, but it does not provide explicit definitions. It would be useful if the document provided a list of Diamaeter-specific terms, and a pointer to where they are defined. I suggest adding to the Terminology section something along the line of: This document uses the terms "application", "realm", "domain", "identity" [..] consistently with the definitions provided in RFC 6733 (Section 1.2, Section 1.3.4, Section 2.6, [..]). Nits: This review does not include editorial nits. ------=_NextPart_000_0014_01CEA3E8.D5F42310 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIY8jCCBfgw ggPgoAMCAQICAwC2pDANBgkqhkiG9w0BAQUFADBMMRwwGgYDVQQDExNPcmFuZ2UgTGFicyBVc2Vy IENBMQ4wDAYDVQQLEwVBc3BpYzEPMA0GA1UEChMGT3JhbmdlMQswCQYDVQQGEwJGUjAeFw0xMjA3 MDQxMzU3MDBaFw0xNzA3MDMxMzU3MDBaMIGJMQswCQYDVQQGEwJGUjEPMA0GA1UEChMGT3Jhbmdl MQ4wDAYDVQQLEwVBU1BJQzEWMBQGA1UEAxMNTGlvbmVsIE1PUkFORDEYMBYGCgmSJomT8ixkAQET CExPQU03MzEyMScwJQYJKoZIhvcNAQkBFhhsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDbWnP90D92WXdUvss8yZYgfAamXE9+q5b36PH0xk1F tyUrFjgR+1QAlKH9WL7qVUsvrrDQv9DpPO4k1z8zOiZjvgzdLRYJMPTBUF6xo7WVKMBdNsn68oae 9h7waHWkWl2PqH3s1xXd8h/W/H625GZC/vzPsyNg1AIG+Y/TIr5sE2SebwMmIDwXy7h7fPg89auK o5VPyjKVSM2HrJU5Aex6aA4FAB7CHqIjpemIMctYpoRLtKi+XoIKuayQFjm5Zkv2L4mb2+WZS8md v5JyIBuQHoUuVM3QnaVRAoSzK7WRXGI0o5/Q+QWIf7ohK8IAT0+u9APoZMOkScQ6TWyMWw77AgMB AAGjggGjMIIBnzAPBgNVHQ8BAf8EBQMDBzAAMBMGA1UdJQQMMAoGCCsGAQUFBwMEMB0GA1UdDgQW BBRkebViSkL8tBTJfvmVMnaLW7fbDjBVBgNVHSMETjBMgBRjjiU37MIHhhTUjoGjH2EZAX8rMKEv gS1DTj1PcmFuZ2UgTGFicyBVc2VyIENBLE9VPUFzcGljLE89T3JhbmdlLEM9RlKCAwCVMTCBpgYD VR0fBIGeMIGbMDKgMKAuhixodHRwOi8vcC1wa2kucmQuZnJhbmNldGVsZWNvbS5mci91c2VyY3Js LmNybDAyoDCgLoYsaHR0cDovL2wtcGtpLnJkLmZyYW5jZXRlbGVjb20uZnIvdXNlcmNybC5jcmww MaAvoC2GK2h0dHA6Ly9wa2kucmQuZnJhbmNldGVsZWNvbS5jb20vdXNlcmNybC5jcmwwEQYJYIZI AYb4QgEBBAQDAgUgMEUGA1UdEQQ+MDyBGGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbYEgbGlvbmVs Lm1vcmFuZEBvcmFuZ2UtZnRncm91cC5jb20wDQYJKoZIhvcNAQEFBQADggIBABwcSJLaSpTjN9tE BSA16YGRuIqkUhqSw1ZTEbJJOAKuAVOQsdvRlyf2jIr1SXohb11Hcz/T+FIhh4x7p4kpgwR8m+uC 4KlLsl4ZjJr6k+lh3p5bNgXOG+OQph5K2qDFRhl6hLVQSotGD8B91yxzpC3s7SVuHPs0+Yx9SWLe QC8lkhi9bH1d7dawUWsrIIZzKk49PMutYVlX3+hoA1g478be3S4da19jWvw6XCkeHYaFr19FbDBS qyQp80CwSo9ZAkxFA7rMAQk3DQNK4Lc74u8sem38R6cE7ZBjRViQIxpzvFI3Du7vDg/rEIw/asWh i0pjx2FVyu5ljaTWoolK36IYVRMgnVKmxLVmJDu3y0kO+wbYY2NqQ3bzOnjMSwnErW94fN1reJtm GfLIMtBcIaKOiVqJYUYLAXGN5TZ+XAbVVC9sSoAUJOCUlKYydqRtIuH38NoT6SCd8B3OBGXvbr4K SRgMRXRpS/w4Lw+Vmdyc0g9vudA1xqqlw1BOa7F7LawkrSYbfesbMXfKob8l0zn+BBm52+at+D8g yGhBgPXJZYCX8hlIR/PmEt18a9svTN8aCLVCd8FhxE/hFSXYVm1trYFCA8uQTP3SdmDJhD/7JeEz pRZHDA07wlgjb9GFD2HPLP5nlh0+9FM5QzTeU52H06vZqpTANPLPeNMnXQ98MIIGPDCCBCSgAwIB AgIDAJUwMA0GCSqGSIb3DQEBBQUAMEwxCzAJBgNVBAYTAkZSMRwwGgYDVQQDExNPcmFuZ2UgTGFi cyBSb290IENBMQ8wDQYDVQQKEwZPcmFuZ2UxDjAMBgNVBAsTBUFzcGljMB4XDTExMDcwODEzMTYy MVoXDTI2MDcwNDEzMTYyMVowTDELMAkGA1UEBhMCRlIxHDAaBgNVBAMTE09yYW5nZSBMYWJzIFJv b3QgQ0ExDzANBgNVBAoTBk9yYW5nZTEOMAwGA1UECxMFQXNwaWMwggIiMA0GCSqGSIb3DQEBAQUA A4ICDwAwggIKAoICAQDEPF2VmYtE8xhLwiLjXgMdWrf2d87kJJE71yBWW76e5csa/X8oHKp/FMWl cs5gguFM2aVS4ngJXNFOnv8P4ak3EJni1yVRLsOMTQIq+mG+zHFB3Hrylg/URRXjBQMXT1N75UxC UcYFOtbFXarcToXcqyPXJeFixHlCY9OE2LmRgMfWqLlqYBTVuBageH7vL98enMAY5Mjk6b+ciDT5 qBYk42cN8o1adpPi/k/K/XK2PVpYLPRVi/Uz8Ok8f9KXytwjcBn7NlE6tyc07T0FY+zJT6A56q1l 7qcC3qHaaPy+KaufA2QkFQyUxz3p2j48nLpZy0lpbHCD5O7YG1MElruTz2zIlU9d0Vv3IfW2fKpg MKMbfMrMIrJ+ek4gD+BmuPNE0kPElFJx8SnJfgF6cXrO4KBU42h8rDMy0vajI2NeFQP+K9Rsp740 w59OQKu8IySiDFszabM4odNue0bdxiymvOEwX5o0q7sc8E+5duZl0L8BX1aP9Sl6E3fkr+stqWwR yeuxyVtUnRL4jVmwKqMmghBWBTGItxCzke/QvHIPGQO2VpHbWPEm2SFedmb7hg6yM/PsBex4uAot PSjQeQ9CJJX0NrkQhbKKyVgOYph2ClJqMCHczYyjrhquPIGK6LPVXrhjAhzD5ovN43dByikGgW2q vemSRjqNu0G0GaIiewIDAQABo4IBJTCCASEwEgYDVR0TAQH/BAgwBgEB/wIBATAPBgNVHQ8BAf8E BQMDBwYAMB0GA1UdDgQWBBRWW+rBfiW7IY6Zr+5vHUWMK5hDuzAfBgNVHSMEGDAWgBRWW+rBfiW7 IY6Zr+5vHUWMK5hDuzCBpgYDVR0fBIGeMIGbMDKgMKAuhixodHRwOi8vcC1wa2kucmQuZnJhbmNl dGVsZWNvbS5mci9yb290Y3JsLmNybDAyoDCgLoYsaHR0cDovL2wtcGtpLnJkLmZyYW5jZXRlbGVj b20uZnIvcm9vdGNybC5jcmwwMaAvoC2GK2h0dHA6Ly9wa2kucmQuZnJhbmNldGVsZWNvbS5jb20v cm9vdGNybC5jcmwwEQYJYIZIAYb4QgEBBAQDAgEWMA0GCSqGSIb3DQEBBQUAA4ICAQAye4JK2HC3 AmyIjmhewawKnWpAMU1amtAoU0TYbCQwiL9vHETH7ibORsbr7eufIuChQ9bVBOlMRU6TgNQv2g7E SSiWRrktKZJUpctlO98kvLTcAmejfBoaQICSFgWcGNVOhZKiK9AzjkT4E2D5xYE6+kgKrfvvOmKd a+xQQG96XKMsAXFlrWb422HdxRNR3KM7gKk4z+iyNMFDliPFDuDt3iB+j/6snJZLyQLWoZtEhfiS F3jkWHzKxlOV0rpJwebvqsZk3Ext4cNjkS9nzteuf3mPgBT2k87i6F3GnXzTrqC61/U715iL9K+0 HgLuZNgP8CYgOc/NzI1I4bHHIhKdRKSpoYCPvhuF3Hd/lx4gnUWw7Qyic1OB75AAIRmR+2+MCFjR sfuujey3MoP0q2z5xsh8AMOrOa2UCYgaG9Q32aESAF7NZ0iIiLZG0bRH0y0sOTfd05KPddo5brDl tjEHTm5BfCywBjC8nQW7ekJRXA0yzC63ADjqNAt25cfbr1Z83l7+I1N/woGBTQIIfpeG+qzvxsJE nslHNsDexI81NAfP5q730jYTX3cScHLCzjhW8uIheQ7IsqiKfV5vS5eD+EvlsRQ40iDDwPjx8gpc ctgVKtMcgLbspCl/lN3k7F891KZPWNI9KyAZFuUfOlCkjnxTbPHF0JD7X/KrqQMJ5TCCBjwwggQk oAMCAQICAwC2ozANBgkqhkiG9w0BAQUFADBMMRwwGgYDVQQDExNPcmFuZ2UgTGFicyBVc2VyIENB MQ4wDAYDVQQLEwVBc3BpYzEPMA0GA1UEChMGT3JhbmdlMQswCQYDVQQGEwJGUjAeFw0xMjA3MDQx MzU3MDBaFw0xNzA3MDMxMzU3MDBaMIGJMQswCQYDVQQGEwJGUjEPMA0GA1UEChMGT3JhbmdlMQ4w DAYDVQQLEwVBU1BJQzEWMBQGA1UEAxMNTGlvbmVsIE1PUkFORDEYMBYGCgmSJomT8ixkAQETCExP QU03MzEyMScwJQYJKoZIhvcNAQkBFhhsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCOppmOXew5md7Jse3XNBbt4KWiu2QnuPeHjlEi1Ftq4h/K 1lmXf3vityz6/hWnGcCNYVcXLHsi6T9O8mOt0xRldytiz73l+OrrVwB23I+E5eaqNH1wvSvwsUxC NQu+kFEf3msGqIHlXXbwcXmcs6dLPO9X6AzU/X9og/lF7K1efBZHRK73Gkos6dhoOfyOfb7HQz5g XQKGifS++KO2FnlNhxJbgBiH7pFjH3UQ+P4wxzo2tlodSWPKJU109G6eYtv13xG4aT8fzCWQWUCu rbRTKYvRma/C9oyJAjGyeJT+7mvGKkZGu4Gy1o+49G3mmWmCq1B3hAyBCK7ho9kpiHDfAgMBAAGj ggHnMIIB4zAPBgNVHQ8BAf8EBQMDB8AAMCkGA1UdJQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYK KwYBBAGCNxQCAjAdBgNVHQ4EFgQUryp5OkxUTb/4wb6qhFAc0MfrhhYwVQYDVR0jBE4wTIAUY44l N+zCB4YU1I6Box9hGQF/KzChL4EtQ049T3JhbmdlIExhYnMgVXNlciBDQSxPVT1Bc3BpYyxPPU9y YW5nZSxDPUZSggMAlTEwgaYGA1UdHwSBnjCBmzAyoDCgLoYsaHR0cDovL3AtcGtpLnJkLmZyYW5j ZXRlbGVjb20uZnIvdXNlcmNybC5jcmwwMqAwoC6GLGh0dHA6Ly9sLXBraS5yZC5mcmFuY2V0ZWxl Y29tLmZyL3VzZXJjcmwuY3JsMDGgL6AthitodHRwOi8vcGtpLnJkLmZyYW5jZXRlbGVjb20uY29t L3VzZXJjcmwuY3JsMBEGCWCGSAGG+EIBAQQEAwIFoDBzBgNVHREEbDBqoCwGCisGAQQBgjcUAgOg HgwcbG9hbTczMTJAcmQuZnJhbmNldGVsZWNvbS5mcoEYbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29t gSBsaW9uZWwubW9yYW5kQG9yYW5nZS1mdGdyb3VwLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAAQri B71YLKBZyezf8yYscBjQny5K5w42d91tZ7UuahD8oqkmBwISAuMXxVmgpt8azOH5Te87Hka2pbMe 5lVaph7GYMQ3vJx4sUReN203KPRGi2+D669iuT7jBEeBVqpo6waXDMP/miBIN3lIdc7sxQXBznw+ BbuIZdU4rvVbuQi1s5uXlKa9ZT7nVYNgon8YYARvTBI6KK4a6T1qDhxlOJsQ0xm59s0NUFpLYvuZ u8PccDgZm0WotPMjWInT1jRg4q9HwFPAZ6/wW/0sqyTTB6OvTjn0W6cPtMgSURktNMqoV4RDX2K3 1AkPq4s8vf3ZHmwE0gGdgnvFDJ54K9HOhU9DlIqI89vAFrgVyzKHciflQt4Bv4CzDyjeeIUiZKTx G3rLzwkrcVgD71N6yTT9l1g7uuuNOFoa+H8RKgWWG01r93r6SFtR7+oWj6cO04a5bsun0Hc9zDER YgTaiQgNBeVZOejyTZFLjYIfS4jgTzW/VYHjo11oRwiCKqqfDzABSQUwPVkFQxnZ/wN46ZDAHZ1L KqyfU8SUw1vKgmHUwds7e52jyvSqZ6j9j9DepmP4hZqNqCTVk09GM4xzpqhcA/Bse64Z8fyGjGTk Kin99iyttrGOk3oLTCkPqT7zsi0Ne9EjpVursSbGQ4Af599FQPA5pjYUldTe2LTR9Az4VjMwggZy MIIEWqADAgECAgMAlTEwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCRlIxHDAaBgNVBAMTE09y YW5nZSBMYWJzIFJvb3QgQ0ExDzANBgNVBAoTBk9yYW5nZTEOMAwGA1UECxMFQXNwaWMwHhcNMTEw NzA4MTMzMDAwWhcNMjYwNjI5MTMzMDAwWjBMMRwwGgYDVQQDExNPcmFuZ2UgTGFicyBVc2VyIENB MQ4wDAYDVQQLEwVBc3BpYzEPMA0GA1UEChMGT3JhbmdlMQswCQYDVQQGEwJGUjCCAiIwDQYJKoZI hvcNAQEBBQADggIPADCCAgoCggIBAIzzJh7XHEPs9EFpC9Tth4LSX6pJasNL71ABfM5JLugMOmg8 0au7iPThbmRCHgIBxiFaR9MjpCgKBMWs4v6ugfG6y7gLNKDYmauoLT5uQvlJ1df7BLiUlguDLogH LUQDF6ThF7iN1Z0w8/rPHejfwZ+OXHr20rzOvsoCx9KNjZ9s1RB8jeM70Xa4kL9VQ1H6gKO7lY8b W8076+DSwCCV1Hh3QL6Kfy6mtQXeIVFsgc7HvB1E1esw/OG2sTu5yW+6QQXhVMoZDUZhsjIP8GSe y3g9gS0iGfc2P9k+8jIXNHlPpFw3jzsXTepvNz+FvE1wSxUDzO2Tc+ytWFg/13IhemUUxMQ6FLGe 9xmGoz1Yz4KGlUEHHOx5M30xPmEy2oCIy+AUW4Kv5wVMHsT6GBAoUNd9kBXyAZB4yc98lc1xRmsD xnhvsGBpBPiU7K4NQZVz5uolArXVQiKLyk9mBJXFdwpuQwiP/wnMfxtfmbtLgoz81787EgGq5YTp T/w/QqIQNACGNsZDzR1manXkCefw0Mcx/PQ+Y8fW7HzyTjS0L8zUhkG4xWFcm94H9aQS/wbc6Fzi Y13rVFrdx7tJz3DBdq/CoE7O2XLsj21IhT5hYlpm9eq8vi7NfsPENSBizWTW+veVRxARUANInMPK wOMw5qMzyCuhNRYt8cmYsQclyG8VAgMBAAGjggFbMIIBVzASBgNVHRMBAf8ECDAGAQH/AgEAMA8G A1UdDwEB/wQFAwMHBgAwHQYDVR0OBBYEFGOOJTfswgeGFNSOgaMfYRkBfyswMFUGA1UdIwROMEyA FFZb6sF+Jbshjpmv7m8dRYwrmEO7oS+BLUM9RlIsQ049T3JhbmdlIExhYnMgUm9vdCBDQSxPPU9y YW5nZSxPVT1Bc3BpY4IDAJUwMIGmBgNVHR8EgZ4wgZswMqAwoC6GLGh0dHA6Ly9wLXBraS5yZC5m cmFuY2V0ZWxlY29tLmZyL3Jvb3RjcmwuY3JsMDKgMKAuhixodHRwOi8vbC1wa2kucmQuZnJhbmNl dGVsZWNvbS5mci9yb290Y3JsLmNybDAxoC+gLYYraHR0cDovL3BraS5yZC5mcmFuY2V0ZWxlY29t LmNvbS9yb290Y3JsLmNybDARBglghkgBhvhCAQEEBAMCAAcwDQYJKoZIhvcNAQEFBQADggIBAEg4 Yi11FG4RTWFHCs50Hl27Dhe9yh3476beBteslp6vZYUZwaQsBaHtVbAXchzUIUzWmgtea3YAiViI 97E5nxsNf4LQWfFJk9nM66WE7GOR0OBlcm6tkWtzfbZ44DmRVEBraHs0oxW5owCNjFzBWKxxfrNr Cj8rLBI7orspUzcrxQeHNJThff808GXCdaz3qXBPWtHBau9CYWWDlZiBzKzymjJ22i5JLmVnsdgC hpLfKVy9iPeSTCdaqgfZDghPnMApwiZ/xuwlZy2IGX6hfrabWFKJtfkIWI/8WTpq9sQRTNwkAxTF Lo9efjM3RB5FAvwqZZzJaAvBLGGZQebeqBYE4AL7I3UwMzDBhqrrI4OSJmwORK+6f18Q1bhKKFso uqIGmELlIkUzq/t8Xfte904W9Au3jEaM4oRaXHXRoYbw+pvNfTbr9UiH9tkK+TOI1UK3AUu64sVL qm+BPMCXxWqAgCLR3DCtv2Ym16hnvxlxs0fG2a2OP46F1XT6+7xJ/hBkDdec28EvzymsxNhPOoIa hTWkizwOOIzW0R/dUUUyLMxxKD33P7ciUJoBmr/+wTeH168dKza/scs8f3izrxqgk8yau5tDOZTN wagAIYVqy674jZDG84OqVs1b8OU4Sg2SVclNAjq1u0jabsqCrHDW3JYSN02i7IKWMh9/BaEhMYID DjCCAwoCAQEwUzBMMRwwGgYDVQQDExNPcmFuZ2UgTGFicyBVc2VyIENBMQ4wDAYDVQQLEwVBc3Bp YzEPMA0GA1UEChMGT3JhbmdlMQswCQYDVQQGEwJGUgIDALajMAkGBSsOAwIaBQCgggGQMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDgyODEwMTkyNVowIwYJKoZI hvcNAQkEMRYEFJTEVCRgbu0iMzS5zzLcPQJXHfDcMGIGCSsGAQQBgjcQBDFVMFMwTDEcMBoGA1UE AxMTT3JhbmdlIExhYnMgVXNlciBDQTEOMAwGA1UECxMFQXNwaWMxDzANBgNVBAoTBk9yYW5nZTEL MAkGA1UEBhMCRlICAwC2pDBkBgsqhkiG9w0BCRACCzFVoFMwTDEcMBoGA1UEAxMTT3JhbmdlIExh YnMgVXNlciBDQTEOMAwGA1UECxMFQXNwaWMxDzANBgNVBAoTBk9yYW5nZTELMAkGA1UEBhMCRlIC AwC2pDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTANBgkq hkiG9w0BAQEFAASCAQAPtf4++16iZSq8L6hUVeQuqQP4P9hALggXzuqDjTNH/CVdR4hV5SQUhAoY CBnHHLT5QGryzMKj14fY1US2uwl5r3N37HkhTPlPT/JNGoVBBuCsNWhcnRxMVNHMqKCajG0/SS23 ua3zAWEIvaQmGXlyYPqEwNrKiNjf58P68eW5fsS/Bm7THhxRhfVkfts2ewmBizSnNBZPsi/Td3wY wEy9WCbPeVBP5x7ZLw9nmy7soBgx3S4UXNkXbTCUr7rcaqAxjuKWp22D9eb4zYdIOziSgdhDOnyb t7qtbMhVqG9iTVWuj4G0qg7VaNBBaddRdo0Zo91fuXHbofxYBl3oGEFOAAAAAAAA ------=_NextPart_000_0014_01CEA3E8.D5F42310-- From ioseb.dzmanashvili@gmail.com Wed Aug 28 09:41: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 5B09821F9CBD; Wed, 28 Aug 2013 09:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.445 X-Spam-Level: X-Spam-Status: No, score=0.445 tagged_above=-999 required=5 tests=[AWL=-1.445, BAYES_05=-1.11, J_CHICKENPOX_32=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_92=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 Zt2WnsIoUAAg; Wed, 28 Aug 2013 09:41:16 -0700 (PDT) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3370E21F9C7B; Wed, 28 Aug 2013 09:41:14 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id o10so3128622eaj.27 for ; Wed, 28 Aug 2013 09:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:content-transfer-encoding :content-disposition; bh=BaXTeeH5pCEfzkUbn9uUhuSS5kNdRy/++Kh3pqriKeo=; b=cV6tWie8AVokhyQghH3cTI7y6JkqOrsws/Sc6qW2f2yrEBpuxebJwdTcK+OYPf9qiM LYAk4Fh5iQzaiT4X1eGvVw7fpNrb0Gv3g5MwYKHVoynWfJKrFdPV+EP0modXmUqqv1qn WZEgQyhheUH2zMt1n+Bpm91Po61PsfI+4s02h1swv9Ts2/7DWW7Nidn06Ljmzfi2banr xPD37dBz9IriYkXCEbRG8Y736xUbBuSloGi++97VHVqJvJUXQxPK8F7RMIJ6ja7SsLu5 qYgX6HPffPygbbuFCTblPxj6Xx9U8LS3hjRQzDx2RF7piisjuAjvTwn/AR0S/jVTXDGz LJyQ== X-Received: by 10.14.214.136 with SMTP id c8mr43604140eep.6.1377708074278; Wed, 28 Aug 2013 09:41:14 -0700 (PDT) Received: from [192.168.1.6] ([176.73.174.236]) by mx.google.com with ESMTPSA id x47sm38833450eea.16.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 28 Aug 2013 09:41:13 -0700 (PDT) Date: Wed, 28 Aug 2013 20:41:10 +0400 From: Ioseb Dzmanashvili To: mike amundsen Message-ID: In-Reply-To: References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <8410EE3EC8FB4ADA93F4209376AF8183@gmail.com> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Julian Reschke , IETF Apps Discuss , link-relations Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 28 Aug 2013 16:41:18 -0000 Mike, On Wednesday, August 28, 2013 at 6:33 PM, mike amundsen wrote: > Ioseb: > =20 > now that i understand your aim... > =20 > it seems the first item (support a pattern...) is the important one and= the other two are just means to that end. Actually as i see it =231 and =232 are of same importance. > so why is this a good approach=3F =231 and =232 still hold. As i already said =233 makes sense only for m2m= scenarios and for GUI clients just knowing that a link is an action and = how to treat such action links is enough. What i'm trying to achieve with my proposal is to generalise meaning of a= ction and make it consistent across different applications. Unfortunately= i do not see(or know, or was not able to find) better approach yet but i= t is generic enough to solve whole class of problems at least on GUI leve= l + partially for m2m cases with =22action-type=22 attribute even if we t= hrow action type registry idea away. If we simplify definition of the =22= action=22 relation type and say: 1. here is the =22action=22 link 2. it points to a resource which describes the action 3. to perform an action fetch it construct request and send it back to se= rver. 4. if you want to know what this particular action means: 4.1. look inside the =22action-type=22 attribute if it presents; or 4.2. fetch the document and look inside it. Is not it sufficient enough to cover whole class of problems in a consist= ent way which are clearly actions and not just related resources=3F So here is my question: why is it bad=3F > 1) why use the =22action=22 rel PLUS a param (=22start=22)=3F why not j= ust use the param (=22start=22) as the rel=3F =46or several reasons: 1. there is no =22start=22 relation yet. 2. it doesn't have explicit sign that it is an action. 3. there are much more actions which are not registered and also there is= no guarantee that each newly registered relation(which can be qualified = as action) will state that it is an action in a consistent way. 4. the pattern as you noticed is still important(IMHO) > 2) why not use two values for the rel as in =3F It was suggested in the initial proposal though approach has drawbacks. i= f i use more rels=3F how to disti= nguish =22foo=22, =22bar=22 and =22baz=22 from each other=3F does it mean= that my action now has triple meaning=3F =20 > 3) why not use (as mike kelly suggests) an extension URI for the rel as= in =20 > =20 > 4) why not use a unique element attribute/property such as =3F > =20 > =20 is it different from =22action-type=22 attribute=3F or maybe problem is i= n a registry of action types=3F =20 > 5) why not use a unique document element/property such as or =7B=22action=22: =7B=22rel=22:=22start=22= , =22href=22:=22...=22=7D=7D=3F =20 Well, in custom media types i can do anything, though it doesn't make sen= se outside of particular format or domain. Otherwise it is ok and i use s= imilar approach in practice. Cheers, ioseb > =20 > 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/mikeamundsen =20 > =20 > On Wed, Aug 28, 2013 at 3:35 AM, Ioseb Dzmanashvili wrote: > > Mike, > > =20 > > On Wednesday, August 28, 2013 at 5:26 AM, mike amundsen wrote: > > =20 > > > OK, from your response i get the following: > > > =20 > > > 1) you want to support a pattern where machine-readable state trans= ition instructions appear at the end of some URL. > > > 2) you want to indicate those instructions are available by marking= the URL w/ the string literal =22action=22 (via rel in your illustration= s) > > > 3) you want to indicate the reason for using these instructions w/ = an =22action-type=22 string (via a link-rel param in your illustrations) > > > =20 > > > that's it. nothing else. > > > =20 > > > do i have this correct=3F > > =20 > > Exactly=21 That's it and nothing else. > > =20 > > Cheers, > > ioseb > > =20 > > > =20 > > > =20 > > > mamund > > > +1.859.757.1449 (tel:%2B1.859.757.1449) > > > skype: mca.amundsen > > > http://amundsen.com/blog/ > > > http://twitter.com/mamund > > > https://github.com/mamund > > > http://www.linkedin.com/in/mikeamundsen > > > =20 > > > On Tue, Aug 27, 2013 at 7:51 PM, Ioseb Dzmanashvili wrote: > > > > Hi Mike, > > > > =20 > > > > Thanks for the question=21 > > > > =20 > > > > On Tuesday, August 27, 2013 at 11:57 PM, mike amundsen wrote: > > > > =20 > > > > > Ioseb: > > > > > =20 > > > > > it is not clear to me why: > > > > > is preferable to: > > > > > =20 > > > > > talk me down ;) > > > > let me try ;) > > > > =20 > > > > Question is not about why: Link: <=E2=80=A6>; rel=3D=22action=22;= action-type=3D=22edit=22 is preferable to: Link: <=E2=80=A6>; rel=3D=22e= dit=22. > > > > =20 > > > > Of course i'd choose rel=3D=22run-forest-run=22 if there is a reg= istered link relation type, but: > > > > =20 > > > > 1. The =22action=22 link relation is generic enough, has well und= erstood meaning and is useful on its own especially for human oriented ag= ents. > > > > 2. The =22action-type=22 optional attribute may be used for speci= fying exact meaning of actions and this makes action links more useful fo= r m2m scenarios. > > > > =20 > > > > Now consider this link: > > > > =20 > > > > Link: ; rel=3D=22action=22; action-type=3D=22sus= pend=22; title=3D=22Suspend=22 > > > > =20 > > > > What it says=3F > > > > =20 > > > > 1. it is an action > > > > 2. target resource represents description of the action which con= tains: request method, submit URI, definition of action, other details et= c > > > > 3. agent can look inside =22action-type=22 to determine whether i= t needs this action type or not > > > > 4. agent can dereference it, construct request and send it to ser= ver > > > > =20 > > > > =20 > > > > now if we add more actions: > > > > =20 > > > > Link: ; rel=3D=22action=22; action-type=3D=22sus= pend=22; title=3D=22Suspend=22 > > > > Link: ; rel=3D=22action=22; action-type=3D=22res= tart=22; title=3D=22Restart=22 > > > > =20 > > > > Link: ; rel=3D=22action=22; action-type=3D=22stop=22= ; title=3D=22Stop=22 > > > > =20 > > > > =20 > > > > =231, =232, =233 and =234 will be true for all of them without ex= ceptions. > > > > =20 > > > > Now consider that representation containing these links is used b= y GUI agent, in this case even =22action-type=22 is not necessary at all = and agent can rely on user's choice. Agent only needs to know that: > > > > =20 > > > > 1. link is an action(and this question is explicitly answered) > > > > 2. if user choose one agent needs just to dereference indicated U= RI > > > > 3. construct request > > > > 4. send request to server > > > > 5. show results to user > > > > =20 > > > > All of these will remain true for any action type. > > > > =20 > > > > I'm not sure if i talked you down, but i believe =22action=22 rel= ation type is useful and not because it is better(or simpler) compared to= rel=3D=22edit=22 for example. > > > > =20 > > > > 1. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-lin= k-relation-00 > > > > 2. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-lin= k-relation-01 > > > > =20 > > > > P.S. > > > > I was talking about 01 version of spec. 00 is a different story. > > > > =20 > > > > Cheers, > > > > ioseb > > > > > mamund > > > > > +1.859.757.1449 (tel:%2B1.859.757.1449) (tel:%2B1.859.757.1449)= > > > > > skype: mca.amundsen > > > > > http://amundsen.com/blog/ > > > > > http://twitter.com/mamund > > > > > https://github.com/mamund > > > > > http://www.linkedin.com/in/mikeamundsen > > > > > =20 > > > > > =20 > > > > > =20 > > > > > On Tue, Aug 27, 2013 at 3:40 PM, Ioseb Dzmanashvili wrote: > > > > > > Hi Julian, > > > > > > =20 > > > > > > Thanks for response=21 > > > > > > =20 > > > > > > On Tuesday, August 27, 2013 at 2:15 PM, Julian Reschke wrote:= > > > > > > =20 > > > > > > > On 2013-08-27 11:03, Ioseb Dzmanashvili wrote: > > > > > > > > Hi All, > > > > > > > > =20 > > > > > > > > I've updated the =22action=22 link relation type spec=5B1= =5D based on initial feedback. > > > > > > > > =20 > > > > > > > > As far as initial reactions were very controversial and r= aised a lot of issues i tried to address all of them and entirely changed= the spec. > > > > > > > > =20 > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > > > > > > > When included in a response, the =22action=22 link relati= on indicates a > > > > > > > > target resource that is responsible for performing action= which MAY: > > > > > > > > =20 > > > > > > > > - Affect state of the context resource; or > > > > > > > > - Initiate process. > > > > > > > > =20 > > > > > > > > The =22action=22 link relation type can be used to indica= te the > > > > > > > > availability of actions supported by the target resource.= Examples > > > > > > > > of such actions include: > > > > > > > > =20 > > > > > > > > - Enable/Disable > > > > > > > > - Publish/Unpublish > > > > > > > > - Start/Stop > > > > > > > > =20 > > > > > > > > The =22action=22 link relation type doesn't convey any se= mantics other > > > > > > > > than that an indicated resources represent machine readab= le > > > > > > > > description of a particular action and representation SHO= ULD contain > > > > > > > > all necessary details such as: request method, action URI= and other > > > > > > > > related details to enable agents to be able to construct = requests > > > > > > > > without relying on out-of-band information. > > > > > > > > =20 > > > > > > > > Exact type of action SHOULD be indicated through the =22a= ction-type=22 > > > > > > > > link-extension value as per =5BR=46C5988=5D and for maint= aining shared > > > > > > > > understanding of action types current specification intro= duces the > > > > > > > > registry of actions with initial values of widely accepte= d and well > > > > > > > > understood action types. > > > > > > > > =20 > > > > > > > > =46or example, if a resource represents a service, that s= ame > > > > > > > > representation may include links to resources that repres= ent actions > > > > > > > > supported by the service: > > > > > > > > =20 > > > > > > > > Link: ; rel=3D=22action=22; action-type=3D= =22restart=22 > > > > > > > > Link: ; rel=3D=22action=22; action-type=3D=22= stop=22 > > > > > > > > ... > > > > > > > > =20 > > > > > > > =20 > > > > > > > =20 > > > > > > > =20 > > > > > > > =20 > > > > > > > =20 > > > > > > > =20 > > > > > > > It seems that you are just adding an indirection mechanism.= Why is that > > > > > > > necessary=3F > > > > > > > =20 > > > > > > =20 > > > > > > =20 > > > > > > =20 > > > > > > =20 > > > > > > With indirection mechanism i'm trying to solve issues raised = around initial version of the spec=5B1=5D. There were several issues: > > > > > > =20 > > > > > > 1. The =22action=22 link relation type doesn't have enough se= mantics and automated agents can not follow such links if there are sever= al actions included in a representation. With the =22action-type=22 link = extension + registry of predefined action types agents can distinguish ac= tions from each other. > > > > > > =20 > > > > > > 2. Initial spec stated that if the =22action=22 link exists i= n representation, only thing agents should do is to send empty POST reque= st to the target in order to perform action. This approach was considered= as an anti pattern(RPCish and non RESTful). With having the =22action-ty= pe=22 agents can: > > > > > > =20 > > > > > > a) distinguish action links from each other; > > > > > > b) if necessary dereference the target to obtain instructions= for constructing non empty POST/PUT requests; > > > > > > c) send properly constructed request back to the target; and > > > > > > d) it makes possible for servers to dictate structure of the = request according to there own needs. > > > > > > =20 > > > > > > Main purpose of the =22action=22 link relation type is to def= ine semantics of particular class of links - actions. This eliminates the= need to redefine notion of =22action=22 for each link relation type whic= h may be qualified as action link. The =22action-type=22 is just for nami= ng actions and is particularly useful for automated agents not necessaril= y for human interaction oriented agents. > > > > > > =20 > > > > > > Having action type registry is important for maintaining shar= ed understanding of particular action types. =46or example =22reset=22 or= =22publish=22 verbs do not need to be redefined from application to appl= ication. I also believe that it is not efficient(or feasible) to register= all possible actions as link relations. > > > > > > =20 > > > > > > 1. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action= -link-relation-00 > > > > > > 2. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action= -link-relation-01 > > > > > > > =20 > > > > > > > Best regards, Julian > > > > > > Cheers, > > > > > > ioseb > > > > > > =20 > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > > > > > > link-relations mailing list > > > > > > link-relations=40ietf.org (mailto:link-relations=40ietf.org) = (mailto:link-relations=40ietf.org) (mailto:link-relations=40ietf.org) (ma= ilto:link-relations=40ietf.org) (mailto:link-relations=40ietf.org) > > > > > > https://www.ietf.org/mailman/listinfo/link-relations > > > > > > =20 > > > > > =20 > > > > > =20 > > > > =20 > > > > =20 > > > =20 > > > =20 > > =20 > > =20 > =20 > =20 From ioseb.dzmanashvili@gmail.com Wed Aug 28 09:53: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 6418B21E8082; Wed, 28 Aug 2013 09:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.558 X-Spam-Level: X-Spam-Status: No, score=-1.558 tagged_above=-999 required=5 tests=[AWL=1.041, 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 tI4HZ0ARsBKO; Wed, 28 Aug 2013 09:53:40 -0700 (PDT) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEFD21E8064; Wed, 28 Aug 2013 09:53:39 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id e53so3101402eek.13 for ; Wed, 28 Aug 2013 09:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:content-transfer-encoding :content-disposition; bh=KtjN7/HaLnCD90c5Au1S2MOEgJ6SiEqkmaUZW6Ylfuc=; b=NgZu89n6NFOKs/+LnsfD0vW/Lbyyr0aZlxbDGqNNWL9jZkGZTyMCEJuzs4QqIVSL+n H4LOnz1KrXpfThaxsCguZYHos0ZsWFLsfIwHAN6rR/r9uKeOZlZMmc0noJfAkVpIJZGu /5pRFHUxv45QnOxsMGBS3qYDn1b+IPp8zzOEz/XStJcFSO8wgtJ0AyPn5jZ1sJs7MuxR 9iXUE+2FJifzjdsNnXH+5iX50LjaSGNtSdFNnTVTA+4Ptdy+ccTmvf7GvaOu6VwqZa4G RNOgag2FtJwTDNX3zbQOQ+vsXBTqZ+mstnH8LYMoTNDCXlR/T0OdzFZgnw86l4jG3Qfl rbYA== X-Received: by 10.14.225.199 with SMTP id z47mr44637534eep.24.1377708819192; Wed, 28 Aug 2013 09:53:39 -0700 (PDT) Received: from [192.168.1.6] ([176.73.174.236]) by mx.google.com with ESMTPSA id a1sm38913696eem.1.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 28 Aug 2013 09:53:38 -0700 (PDT) Date: Wed, 28 Aug 2013 20:53:34 +0400 From: Ioseb Dzmanashvili To: Peter Williams Message-ID: In-Reply-To: References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <2815EAE84FC243169D0D4802A0169C21@gmail.com> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: apps-discuss@ietf.org, link-relations@ietf.org Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 28 Aug 2013 16:53:41 -0000 Hi Peter, Thanks for feedback=21 =20 On Wednesday, August 28, 2013 at 6:14 PM, Peter Williams wrote: > I have a question about how this might affect future relationship regis= trations. Consider the following scenario: > This proposal is adopted. As many apps begin exposing =60start=60 links= it becomes obvious that start is a really common relationship. A proposa= l is made to register a top level relationship =60start=60. (I am using =60= start=60 purely for example purposes, this scenario works for any registe= red action type.) > In this case would you expect the new relationship registration to be a= ) rejected on the grounds that you can already accomplish it via the acti= on+action-type approach, b) accepted and the action relation updated to d= eclare the start action type archaic, c) accepted and action relation to = left as is, leaving it up to implementers to decide which approach to use= for themselves=3F (Or perhaps there is a option I have over looked.) Wha= t are the implications for existing representations and consumers under t= hat outcome=3F What about new representations and consumers=3F With my proposal i'm trying to solve the problem of particular class - ac= tions. I want to have generalised approach which works from application t= o application without redefining a) notion of action; b) basic interactio= n model; and c) at least minimal shared understanding of particular kinds= of actions. =20 =46or the moment i'm not sure whether action type registry will be adopte= d at all and of course i do not see future implications clearly if the pr= oposal will be accepted. What i can say for sure these cases can covered = in the proposal, but it is not 100% clear for me yet. I believe further d= iscussions will show how to eliminate such cases. Cheers, ioseb > Cheers, > Peter =20 > Hi Mike, > =20 > On Wednesday, August 28, 2013 at 11:45 AM, Mike Kelly wrote: > =20 > > =20 > > On 28 Aug 2013 00:51, =22Ioseb Dzmanashvili=22 wrote: > > > =20 > > > Hi Mike, > > > =20 > > > Thanks for the question=21 > > > =20 > > > On Tuesday, August 27, 2013 at 11:57 PM, mike amundsen wrote: > > > =20 > > > > Ioseb: > > > > =20 > > > > it is not clear to me why: > > > > is preferable to: > > > > =20 > > > > talk me down ;) > > > let me try ;) > > > =20 > > > Question is not about why: Link: <=E2=80=A6>; rel=3D=22action=22; a= ction-type=3D=22edit=22 is preferable to: Link: <=E2=80=A6>; rel=3D=22edi= t=22. > > > =20 > > > Of course i'd choose rel=3D=22run-forest-run=22 if there is a regis= tered link relation type, but: > > > =20 > > > 1. The =22action=22 link relation is generic enough, has well under= stood meaning and is useful on its own especially for human oriented agen= ts. > > > 2. The =22action-type=22 optional attribute may be used for specify= ing exact meaning of actions and this makes action links more useful for = m2m scenarios. > > =20 > > =20 > > Hey Ioseb, isn't this what extension relations are for=3F > =20 > =20 > =20 > =40mamund perfectly summarised major goals of the spec so i'm copying i= t here: > =20 > 1) you want to support a *pattern* where machine-readable state transit= ion instructions appear at the end of some URL. > 2) you want to indicate those instructions are available by marking the= URL w/ the string literal =22action=22 (via rel in your illustrations) > 3) you want to indicate the reason for using these instructions w/ an =22= action-type=22 string (via a link-rel param in your illustrations) > =20 > =20 > =20 > Additionally semantics of extension relations may vary from application= to application. With the =22action-type=22 optional attribute + registry= of machine readable action type names i'm trying to address the issue of= shared semantics and at the same time the =22action=22 relation itself s= till remains useful for GUI scenarios without the =22action-type=22 attri= bute. > =20 > Cheers, > ioseb > =20 > > Cheers, > > M > =20 > =20 > =20 > =20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > link-relations mailing list > link-relations=40ietf.org (mailto:link-relations=40ietf.org) > https://www.ietf.org/mailman/listinfo/link-relations From ioseb.dzmanashvili@gmail.com Wed Aug 28 10: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 28A4511E8283; Wed, 28 Aug 2013 10:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.707 X-Spam-Level: X-Spam-Status: No, score=-1.707 tagged_above=-999 required=5 tests=[AWL=0.892, 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 e1gqG3LrTuLy; Wed, 28 Aug 2013 10:00:38 -0700 (PDT) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D66B421F9D87; Wed, 28 Aug 2013 10:00:25 -0700 (PDT) Received: by mail-ea0-f170.google.com with SMTP id h14so3099015eak.15 for ; Wed, 28 Aug 2013 10:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:content-transfer-encoding :content-disposition; bh=USFQR0BtipAakFu5wImbSxKemAe3f7Q7IXoPVMHx8sk=; b=yet18C+rRwoN66dE9VRkf/NsBC1TjhrNCL5J03/uvahIMsD2I/XcXIzd9/xAzwbk2x WcP/yA5bjm3wLzVT2/fh2VzMLmjTu9IuNyL5mRTmx8MiI7rji86ey0Lq0MjdYqqlF+5q QQOCzIXHyTu337SLXUVoCPNbHZWPaMjjjZ0k1DQv4beux0O8GTR15rCmXs0wLGJkMR+K e5d+Oez9HaHoGSoO9Y261y2illylEpCGKEUUiNNB1v0kU+BC7DINuXJQEAHTFH3MZj0T /W/qy+Z9NuPyIC4UkH0bR2RRxxXcFPGRMoFi78AX0XHzXkvsoDDCvSeaHAMunk2PEB55 9UfA== X-Received: by 10.15.45.8 with SMTP id a8mr44453858eew.1.1377709224549; Wed, 28 Aug 2013 10:00:24 -0700 (PDT) Received: from [192.168.1.6] ([176.73.174.236]) by mx.google.com with ESMTPSA id k7sm38948020eeg.13.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 28 Aug 2013 10:00:23 -0700 (PDT) Date: Wed, 28 Aug 2013 21:00:20 +0400 From: Ioseb Dzmanashvili To: James M Snell Message-ID: <2C7A2CE62064416F9EF0DBB3E17E5829@gmail.com> In-Reply-To: References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <2815EAE84FC243169D0D4802A0169C21@gmail.com> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Mike Kelly , Julian Reschke , IETF Apps Discuss , link-relations Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 28 Aug 2013 17:00:39 -0000 Hi James, On Wednesday, August 28, 2013 at 7:31 PM, James M Snell wrote: > I'm still struggling to see the value of a generic =22action=22 link > relation here. If I have a set of link relations that I happen to want > to mark as =22action=22, I would prefer to eliminate the indirection an= d > simply =22flag=22 the links, for instance: > =20 > Link: ; rel=3D=22restart=22; action > =20 > or in HTML > =20 > or... > > =20 > This approach would skip the additional registration mechanism for > action-type and would allow any link relation to potentially be marked > as an action... which seems appropriate. > =20 How do i advertise this action =22flag=22=3F I can do it in media profile= , i can do somewhere else. But how to do it outside of my domain=3F As I = already said: =20 I want to have generalised approach which works from application to appli= cation without redefining a) notion of action; b) basic interaction model= ; and c) at least minimal shared understanding of particular kinds of act= ions. =20 P.S. Here are more details in response to Mike: http://www.ietf.org/mail-archi= ve/web/link-relations/current/msg00554.html Cheers, ioseb > =20 > - James > =20 > =20 > =20 > =20 > On Wed, Aug 28, 2013 at 1:04 AM, Ioseb Dzmanashvili > wrote: > > Hi Mike, > > =20 > > On Wednesday, August 28, 2013 at 11:45 AM, Mike Kelly wrote: > > =20 > > > =20 > > > On 28 Aug 2013 00:51, =22Ioseb Dzmanashvili=22 wrote: > > > > =20 > > > > Hi Mike, > > > > =20 > > > > Thanks for the question=21 > > > > =20 > > > > On Tuesday, August 27, 2013 at 11:57 PM, mike amundsen wrote: > > > > =20 > > > > > Ioseb: > > > > > =20 > > > > > it is not clear to me why: > > > > > is preferable to: > > > > > =20 > > > > > talk me down ;) > > > > let me try ;) > > > > =20 > > > > Question is not about why: Link: <=E2=80=A6>; rel=3D=22action=22;= action-type=3D=22edit=22 is preferable to: Link: <=E2=80=A6>; rel=3D=22e= dit=22. > > > > =20 > > > > Of course i'd choose rel=3D=22run-forest-run=22 if there is a reg= istered link relation type, but: > > > > =20 > > > > 1. The =22action=22 link relation is generic enough, has well und= erstood meaning and is useful on its own especially for human oriented ag= ents. > > > > 2. The =22action-type=22 optional attribute may be used for speci= fying exact meaning of actions and this makes action links more useful fo= r m2m scenarios. > > > > =20 > > > =20 > > > =20 > > > =20 > > > Hey Ioseb, isn't this what extension relations are for=3F > > =20 > > =20 > > =20 > > =40mamund perfectly summarised major goals of the spec so i'm copying= it here: > > =20 > > 1) you want to support a *pattern* where machine-readable state trans= ition instructions appear at the end of some URL. > > 2) you want to indicate those instructions are available by marking t= he URL w/ the string literal =22action=22 (via rel in your illustrations)= > > 3) you want to indicate the reason for using these instructions w/ an= =22action-type=22 string (via a link-rel param in your illustrations) > > =20 > > =20 > > =20 > > Additionally semantics of extension relations may vary from applicati= on to application. With the =22action-type=22 optional attribute + regist= ry of machine readable action type names i'm trying to address the issue = of shared semantics and at the same time the =22action=22 relation itself= still remains useful for GUI scenarios without the =22action-type=22 att= ribute. > > =20 > > Cheers, > > ioseb > > =20 > > > Cheers, > > > M > > > =20 > > =20 > > =20 > > =20 > > =20 > > =20 > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > apps-discuss mailing list > > apps-discuss=40ietf.org (mailto:apps-discuss=40ietf.org) > > https://www.ietf.org/mailman/listinfo/apps-discuss > > =20 > =20 > =20 From mca@amundsen.com Wed Aug 28 10:39: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 B950011E8196 for ; Wed, 28 Aug 2013 10:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.64 X-Spam-Level: **** X-Spam-Status: No, score=4.64 tagged_above=-999 required=5 tests=[AWL=-0.412, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock10=0.13] 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++4B7OkMPDO for ; Wed, 28 Aug 2013 10:39:39 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id EB82721F9DFA for ; Wed, 28 Aug 2013 10:39:37 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id ey11so3805814wid.0 for ; Wed, 28 Aug 2013 10:39:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=HZbkUTSoLmsbYa1yxV1bqXZBMLLrMLo+N1L9ScCyn0M=; b=a9Eb75MQO7hYWPrGix/wnL6KELZY4hzxo4T/Njc3L72uttXB7o96htcGBsJv4C/57V r9omK0wFcWUiKzquqIlsDCIUN7GSVI+RY2V/LKj0FBbf9qCRSVThJANeG5ha4F89KcV4 xg/lw7aWlJalGw4irU6IVSyUgYbdzUzpYeCyGhJDjfOxIunGEfiHtV4rF/9R8Wt7tKnG hyVX63GYkOuwo5oWocLCr9F1aOvhHGk/Of0dxaJGp50o7BUiBb+Fxxp3+r/vCQ3e+1Ea h8h9/a1avvrkKh2F0BGz7xA6/q8s4FBF3/tJfFlMdGZ7HDrdtRNrpQUIUibir2pGsAZa nwlg== X-Gm-Message-State: ALoCoQnlktVuIQDcI2tXkWn7X5nFZZmtUI+J8RI8U3IbUiLd0r9NDA/zcH44CWuTMP9hhVsFUfWN X-Received: by 10.194.205.164 with SMTP id lh4mr4704792wjc.46.1377711576189; Wed, 28 Aug 2013 10:39:36 -0700 (PDT) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.151.7 with HTTP; Wed, 28 Aug 2013 10:39:16 -0700 (PDT) In-Reply-To: References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <8410EE3EC8FB4ADA93F4209376AF8183@gmail.com> From: mike amundsen Date: Wed, 28 Aug 2013 13:39:16 -0400 X-Google-Sender-Auth: EdwC2KAOL39ebBX_0RgrkfKQJN4 Message-ID: To: Ioseb Dzmanashvili Content-Type: multipart/alternative; boundary=047d7bae47381a1f2704e5057926 Cc: Julian Reschke , IETF Apps Discuss , link-relations Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 28 Aug 2013 17:39:42 -0000 --047d7bae47381a1f2704e5057926 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable So here is my question: why is it bad? 1) creates a new registry for action-type instead of using existing registry for rel (you point this out in the "there is not start relation yet" reasoning) 2) ignores the use of link relation extension values already established in RFC5988 (see Mike Kelly's question) 3) introduces confusion on whether @rel or "action-type" should be used (see Peter Williams' question) 4) uses two values ("action" and "{reason}") where only one is needed (srsly, a constant string AND a variable?) IOW, you have two possible solutions already for the same outcome and are not using them. you've been offered at least one issue on conflicting implementation and at least one on overly-complex implementation. if you are so sure that this implementation detail is important to the _results_ you want to achieve, then start today by doing it via link extensions: you can document and implement this today w/o any need to get an RFC approved or get even buy-in from others. You can create your own registry and open it up to others for adds/edits (similar to the way microformats operates). You can build working implementations, write papers on it, advocate for use in various forums, etc. Over time you can monitor and record adoption, judge the up-take you get and determine whether it proves to be a useful pattern. If it works well and shows adoption, you'll see much less push-back from me (and, i suspect others) and will be able to replace: with and even allow existing implementations to support both. IOW, nothing is stopping you from implementing a compliant version of this approach today and doing it in a way that would be compatible w/ adopting your proposed approach once your approach is proven to be worthy of recording as a standard. finally, i'll say this: Actually as i see it #1 and #2 are of same importance. If the _method_ of achieving your results is non-negotiable, I have little else to offer here. Cheers. 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/mikeamundsen On Wed, Aug 28, 2013 at 12:41 PM, Ioseb Dzmanashvili < ioseb.dzmanashvili@gmail.com> wrote: > Mike, > > On Wednesday, August 28, 2013 at 6:33 PM, mike amundsen wrote: > > Ioseb: > > > > now that i understand your aim... > > > > it seems the first item (support a pattern...) is the important one and > the other two are just means to that end. > Actually as i see it #1 and #2 are of same importance. > > > > so why is this a good approach? > #1 and #2 still hold. As i already said #3 makes sense only for m2m > scenarios and for GUI clients just knowing that a link is an action and h= ow > to treat such action links is enough. > > What i'm trying to achieve with my proposal is to generalise meaning of > action and make it consistent across different applications. Unfortunatel= y > i do not see(or know, or was not able to find) better approach yet but it > is generic enough to solve whole class of problems at least on GUI level = + > partially for m2m cases with "action-type" attribute even if we throw > action type registry idea away. If we simplify definition of the "action" > relation type and say: > > 1. here is the "action" link > 2. it points to a resource which describes the action > 3. to perform an action fetch it construct request and send it back to > server. > 4. if you want to know what this particular action means: > 4.1. look inside the "action-type" attribute if it presents; or > 4.2. fetch the document and look inside it. > > Is not it sufficient enough to cover whole class of problems in a > consistent way which are clearly actions and not just related resources? > > So here is my question: why is it bad? > > > 1) why use the "action" rel PLUS a param ("start")? why not just use th= e > param ("start") as the rel? > For several reasons: > > 1. there is no "start" relation yet. > 2. it doesn't have explicit sign that it is an action. > 3. there are much more actions which are not registered and also there is > no guarantee that each newly registered relation(which can be qualified a= s > action) will state that it is an action in a consistent way. > 4. the pattern as you noticed is still important(IMHO) > > > 2) why not use two values for the rel as in ? > > It was suggested in the initial proposal though approach has drawbacks. i= f > i use more rels? how to distinguish > "foo", "bar" and "baz" from each other? does it mean that my action now h= as > triple meaning? > > > 3) why not use (as mike kelly suggests) an extension URI for the rel as > in > > > > 4) why not use a unique element attribute/property such as rel=3D"action" reason=3D"start" .../>? > > > > > > is it different from "action-type" attribute? or maybe problem is in a > registry of action types? > > > 5) why not use a unique document element/property such as rel=3D"start" href=3D"..."/> or {"action": {"rel":"start", "href":"..."}}= ? > Well, in custom media types i can do anything, though it doesn't make > sense outside of particular format or domain. Otherwise it is ok and i us= e > similar approach in practice. > > Cheers, > ioseb > > > > > 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/mikeamundsen > > > > On Wed, Aug 28, 2013 at 3:35 AM, Ioseb Dzmanashvili < > ioseb.dzmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com) > (mailto:ioseb.dzmanashvili@gmail.com)> wrote: > > > Mike, > > > > > > On Wednesday, August 28, 2013 at 5:26 AM, mike amundsen wrote: > > > > > > > OK, from your response i get the following: > > > > > > > > 1) you want to support a pattern where machine-readable state > transition instructions appear at the end of some URL. > > > > 2) you want to indicate those instructions are available by marking > the URL w/ the string literal "action" (via rel in your illustrations) > > > > 3) you want to indicate the reason for using these instructions w/ > an "action-type" string (via a link-rel param in your illustrations) > > > > > > > > that's it. nothing else. > > > > > > > > do i have this correct? > > > > > > Exactly! That's it and nothing else. > > > > > > Cheers, > > > ioseb > > > > > > > > > > > > > > > mamund > > > > +1.859.757.1449 (tel:%2B1.859.757.1449) > > > > skype: mca.amundsen > > > > http://amundsen.com/blog/ > > > > http://twitter.com/mamund > > > > https://github.com/mamund > > > > http://www.linkedin.com/in/mikeamundsen > > > > > > > > On Tue, Aug 27, 2013 at 7:51 PM, Ioseb Dzmanashvili < > ioseb.dzmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com) > (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.co= m)> > wrote: > > > > > Hi Mike, > > > > > > > > > > Thanks for the question! > > > > > > > > > > On Tuesday, August 27, 2013 at 11:57 PM, mike amundsen wrote: > > > > > > > > > > > Ioseb: > > > > > > > > > > > > it is not clear to me why: href=3D"..." /> > > > > > > is preferable to: > > > > > > > > > > > > talk me down ;) > > > > > let me try ;) > > > > > > > > > > Question is not about why: Link: <=85>; rel=3D"action"; > action-type=3D"edit" is preferable to: Link: <=85>; rel=3D"edit". > > > > > > > > > > Of course i'd choose rel=3D"run-forest-run" if there is a registe= red > link relation type, but: > > > > > > > > > > 1. The "action" link relation is generic enough, has well > understood meaning and is useful on its own especially for human oriented > agents. > > > > > 2. The "action-type" optional attribute may be used for specifyin= g > exact meaning of actions and this makes action links more useful for m2m > scenarios. > > > > > > > > > > Now consider this link: > > > > > > > > > > Link: ; rel=3D"action"; action-type=3D"suspend"; > title=3D"Suspend" > > > > > > > > > > What it says? > > > > > > > > > > 1. it is an action > > > > > 2. target resource represents description of the action which > contains: request method, submit URI, definition of action, other details > etc > > > > > 3. agent can look inside "action-type" to determine whether it > needs this action type or not > > > > > 4. agent can dereference it, construct request and send it to > server > > > > > > > > > > > > > > > now if we add more actions: > > > > > > > > > > Link: ; rel=3D"action"; action-type=3D"suspend"; > title=3D"Suspend" > > > > > Link: ; rel=3D"action"; action-type=3D"restart"; > title=3D"Restart" > > > > > > > > > > Link: ; rel=3D"action"; action-type=3D"stop"; > title=3D"Stop" > > > > > > > > > > > > > > > #1, #2, #3 and #4 will be true for all of them without exceptions= . > > > > > > > > > > Now consider that representation containing these links is used b= y > GUI agent, in this case even "action-type" is not necessary at all and > agent can rely on user's choice. Agent only needs to know that: > > > > > > > > > > 1. link is an action(and this question is explicitly answered) > > > > > 2. if user choose one agent needs just to dereference indicated U= RI > > > > > 3. construct request > > > > > 4. send request to server > > > > > 5. show results to user > > > > > > > > > > All of these will remain true for any action type. > > > > > > > > > > I'm not sure if i talked you down, but i believe "action" relatio= n > type is useful and not because it is better(or simpler) compared to > rel=3D"edit" for example. > > > > > > > > > > 1. > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-= 00 > > > > > 2. > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-= 01 > > > > > > > > > > P.S. > > > > > I was talking about 01 version of spec. 00 is a different story. > > > > > > > > > > Cheers, > > > > > ioseb > > > > > > mamund > > > > > > +1.859.757.1449 (tel:%2B1.859.757.1449) (tel:%2B1.859.757.1449) > > > > > > skype: mca.amundsen > > > > > > http://amundsen.com/blog/ > > > > > > http://twitter.com/mamund > > > > > > https://github.com/mamund > > > > > > http://www.linkedin.com/in/mikeamundsen > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 27, 2013 at 3:40 PM, Ioseb Dzmanashvili < > ioseb.dzmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com) > (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.co= m) > (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.co= m)> > wrote: > > > > > > > Hi Julian, > > > > > > > > > > > > > > Thanks for response! > > > > > > > > > > > > > > On Tuesday, August 27, 2013 at 2:15 PM, Julian Reschke wrote: > > > > > > > > > > > > > > > On 2013-08-27 11:03, Ioseb Dzmanashvili wrote: > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > I've updated the "action" link relation type spec[1] base= d > on initial feedback. > > > > > > > > > > > > > > > > > > As far as initial reactions were very controversial and > raised a lot of issues i tried to address all of them and entirely change= d > the spec. > > > > > > > > > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > > > > > > > > > When included in a response, the "action" link relation > indicates a > > > > > > > > > target resource that is responsible for performing action > which MAY: > > > > > > > > > > > > > > > > > > - Affect state of the context resource; or > > > > > > > > > - Initiate process. > > > > > > > > > > > > > > > > > > The "action" link relation type can be used to indicate t= he > > > > > > > > > availability of actions supported by the target resource. > Examples > > > > > > > > > of such actions include: > > > > > > > > > > > > > > > > > > - Enable/Disable > > > > > > > > > - Publish/Unpublish > > > > > > > > > - Start/Stop > > > > > > > > > > > > > > > > > > The "action" link relation type doesn't convey any > semantics other > > > > > > > > > than that an indicated resources represent machine readab= le > > > > > > > > > description of a particular action and representation > SHOULD contain > > > > > > > > > all necessary details such as: request method, action URI > and other > > > > > > > > > related details to enable agents to be able to construct > requests > > > > > > > > > without relying on out-of-band information. > > > > > > > > > > > > > > > > > > Exact type of action SHOULD be indicated through the > "action-type" > > > > > > > > > link-extension value as per [RFC5988] and for maintaining > shared > > > > > > > > > understanding of action types current specification > introduces the > > > > > > > > > registry of actions with initial values of widely accepte= d > and well > > > > > > > > > understood action types. > > > > > > > > > > > > > > > > > > For example, if a resource represents a service, that sam= e > > > > > > > > > representation may include links to resources that > represent actions > > > > > > > > > supported by the service: > > > > > > > > > > > > > > > > > > Link: ; rel=3D"action"; > action-type=3D"restart" > > > > > > > > > Link: ; rel=3D"action"; action-type=3D"stop= " > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It seems that you are just adding an indirection mechanism. > Why is that > > > > > > > > necessary? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > With indirection mechanism i'm trying to solve issues raised > around initial version of the spec[1]. There were several issues: > > > > > > > > > > > > > > 1. The "action" link relation type doesn't have enough > semantics and automated agents can not follow such links if there are > several actions included in a representation. With the "action-type" link > extension + registry of predefined action types agents can distinguish > actions from each other. > > > > > > > > > > > > > > 2. Initial spec stated that if the "action" link exists in > representation, only thing agents should do is to send empty POST request > to the target in order to perform action. This approach was considered as > an anti pattern(RPCish and non RESTful). With having the "action-type" > agents can: > > > > > > > > > > > > > > a) distinguish action links from each other; > > > > > > > b) if necessary dereference the target to obtain instructions > for constructing non empty POST/PUT requests; > > > > > > > c) send properly constructed request back to the target; and > > > > > > > d) it makes possible for servers to dictate structure of the > request according to there own needs. > > > > > > > > > > > > > > Main purpose of the "action" link relation type is to define > semantics of particular class of links - actions. This eliminates the nee= d > to redefine notion of "action" for each link relation type which may be > qualified as action link. The "action-type" is just for naming actions an= d > is particularly useful for automated agents not necessarily for human > interaction oriented agents. > > > > > > > > > > > > > > Having action type registry is important for maintaining > shared understanding of particular action types. For example "reset" or > "publish" verbs do not need to be redefined from application to > application. I also believe that it is not efficient(or feasible) to > register all possible actions as link relations. > > > > > > > > > > > > > > 1. > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-= 00 > > > > > > > 2. > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-= 01 > > > > > > > > > > > > > > > > Best regards, Julian > > > > > > > Cheers, > > > > > > > ioseb > > > > > > > > > > > > > > _______________________________________________ > > > > > > > link-relations mailing list > > > > > > > link-relations@ietf.org (mailto:link-relations@ietf.org) > (mailto:link-relations@ietf.org) (mailto:link-relations@ietf.org) (mailto= : > link-relations@ietf.org) (mailto:link-relations@ietf.org) > > > > > > > https://www.ietf.org/mailman/listinfo/link-relations > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --047d7bae47381a1f2704e5057926 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
<snip>
So here is my question: why is it bad?
</snip>
1) creates a new registry for action-type in= stead of using existing registry for rel (you point this out in the "t= here is not start relation yet" reasoning)
2) ignores= the use of link relation extension values already established in RFC5988 (= see Mike Kelly's question)
3) introduces confusion on whether @= rel or "action-type" should be used (see Peter Williams' ques= tion)
4) uses two values ("action" and "{reason}") whe= re only one is needed (srsly, a constant string AND a variable?)

IOW, you have two possib= le solutions already for the same outcome and are not using them. you'v= e been offered at least one issue on=A0conflicting=A0implementation and at = least one on overly-complex implementation.

if you are so sure that this implementation d= etail is important to the _results_ you want to achieve, then start today b= y doing it via link extensions:

you can document a= nd implement this today w/o any need to get an RFC approved or get even buy= -in from others. You can create your own registry and open it up to others = for adds/edits (similar=A0to the way microformats operates). You can build = working implementations, write papers on it, advocate for use in various fo= rums, etc. =A0

Over time you can monitor and record adoption= , judge the=A0up-take y= ou get and determine whether it proves to be a useful pattern. If it works = well and shows adoption, you'll see much less push-back from me (and, i= suspect others) and will be able to replace:=A0<LINK rel=3D"http://actions.io/action;action-type=3D"sta= rt" ... />=A0wi= th=A0<LINK rel=3D&qu= ot;action;action-type=3D"start" ... />=A0and even allow existing implementations to s= upport both.

IOW, nothing is stoppin= g you from implementing a compliant version of this approach today and doin= g it in a way that would be compatible w/ adopting your proposed approach o= nce your approach is proven to be worthy of recording as a standard.=A0

finally, i= 'll say this:
<snip>
Actually as i see it #1 and #2 are of = same importance.
<= /snip>
If the _method_= of achieving your results is non-negotiable, I have little else to offer h= ere.=A0

Cheers.

=



On Wed, Aug 28, 2013 at 12:41 PM, Ioseb = Dzmanashvili <ioseb.dzmanashvili@gmail.com> wrote= :
Mike,

On Wednesday, August 28, 2013 at 6:33 PM, mike amundsen wrote:
> Ioseb:
>
> now that i understand your aim...
>
> it seems the first item (support a pattern...) is the important one an= d the other two are just means to that end.
Actually as i see it #1 and #2 are of same importance.


> so why is this a good approach?
#1 and #2 still hold. As i already said #3 makes sense only for m2m s= cenarios and for GUI clients just knowing that a link is an action and how = to treat such action links is enough.

What i'm trying to achieve with my proposal is to generalise meaning of= action and make it consistent across different applications. Unfortunately= i do not see(or know, or was not able to find) better approach yet but it = is generic enough to solve whole class of problems at least on GUI level + = partially for m2m cases with "action-type" attribute even if we t= hrow action type registry idea away. If we simplify definition of the "= ;action" relation type and say:

1. here is the "action" link
2. it points to a resource which describes the action
3. to perform an action fetch it construct request and send it back to serv= er.
4. if you want to know what this particular action means:
4.1. look inside the "action-type" attribute if it presents; or 4.2. fetch the document and look inside it.

Is not it sufficient enough to cover whole class of problems in a consisten= t way which are clearly actions and not just related resources?

So here is my question: why is it bad?

> 1) why use the "action" rel PLUS a param ("start")= ? why not just use the param ("start") as the rel?
For several reasons:

1. there is no "start" relation yet.
2. it doesn't have explicit sign that it is an action.
3. there are much more actions which are not registered and also there is n= o guarantee that each newly registered relation(which can be qualified as a= ction) will state that it is an action in a consistent way.
4. the pattern as you noticed is still important(IMHO)

> 2) why not use two values for the rel as in <LINK rel=3D"actio= n start" />?

It was suggested in the initial proposal though approach has drawback= s. if i use more rels? <LINK rel=3D"action foo bar baz" /> = how to distinguish "foo", "bar" and "baz" fro= m each other? does it mean that my action now has triple meaning?

> 3) why not use (as mike kelly suggests) an extension URI for the rel a= s in <LINK rel=3D"http://actions.io/start" ... />
>
> 4) why not use a unique element attribute/property such as <LINK re= l=3D"action" reason=3D"start" .../>?
>
>

is it different from "action-type" attribute? or maybe prob= lem is in a registry of action types?

> 5) why not use a unique document element/property such as <action r= el=3D"start" href=3D"..."/> or {"action": = {"rel":"start", "href":"..."}}?
Well, in custom media types i can do anything, though it doesn't = make sense outside of particular format or domain. Otherwise it is ok and i= use similar approach in practice.

Cheers,
ioseb

>
> mamund
> +1.859.757.14= 49
> skype: mca.amundsen
> http://amundse= n.com/blog/
> http://twitter= .com/mamund
> https://github= .com/mamund
> = http://www.linkedin.com/in/mikeamundsen
>
> On Wed, Aug 28, 2013 at 3:35 AM, Ioseb Dzmanas= hvili <ioseb.dzmanashvil= i@gmail.com (mailto:ios= eb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.com)> wrote:
> > Mike,
> >
> > On Wednesday, August 28, 2013 at 5:26 AM, mike amundsen wrote: > >
> > > OK, from your response i get the following:
> > >
> > > 1) you want to support a pattern where machine-readable stat= e transition instructions appear at the end of some URL.
> > > 2) you want to indicate those instructions are available by = marking the URL w/ the string literal "action" (via rel in your i= llustrations)
> > > 3) you want to indicate the reason for using these instructi= ons w/ an "action-type" string (via a link-rel param in your illu= strations)
> > >
> > > that's it. nothing else.
> > >
> > > do i have this correct?
> >
> > Exactly! That's it and nothing else.
> >
> > Cheers,
> > ioseb
> >
> > >
> > >
> > > mamund
> > > +1.859.757.1449 (tel:%2B1.859.757.1449)
> > > skype: mca.amundsen
> > > http= ://amundsen.com/blog/
> > > http= ://twitter.com/mamund
> > > http= s://github.com/mamund
> > > http://www.linkedin.com/in/mikeamundsen
> > >
> > > On Tue, Aug 27, 2013 at 7:51 PM= , Ioseb Dzmanashvili <io= seb.dzmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.com)= > wrote:
> > > > Hi Mike,
> > > >
> > > > Thanks for the question!
> > > >
> > > > On Tuesday, August 27, 2013 at 11:57 PM, mike amundsen = wrote:
> > > >
> > > > > Ioseb:
> > > > >
> > > > > it is not clear to me why: <link rel=3D"ac= tion;action-type=3D'edit'" href=3D"..." />
> > > > > is preferable to: <link rel=3D"edit" = href=3D"..." />
> > > > >
> > > > > talk me down ;)
> > > > let me try ;)
> > > >
> > > > Question is not about why: Link: <=85>; rel=3D&qu= ot;action"; action-type=3D"edit" is preferable to: Link: <= ;=85>; rel=3D"edit".
> > > >
> > > > Of course i'd choose rel=3D"run-forest-run&quo= t; if there is a registered link relation type, but:
> > > >
> > > > 1. The "action" link relation is generic enou= gh, has well understood meaning and is useful on its own especially for hum= an oriented agents.
> > > > 2. The "action-type" optional attribute may b= e used for specifying exact meaning of actions and this makes action links = more useful for m2m scenarios.
> > > >
> > > > Now consider this link:
> > > >
> > > > Link: </suspend-action>; rel=3D"action"= ; action-type=3D"suspend"; title=3D"Suspend"
> > > >
> > > > What it says?
> > > >
> > > > 1. it is an action
> > > > 2. target resource represents description of the action= which contains: request method, submit URI, definition of action, other de= tails etc
> > > > 3. agent can look inside "action-type" to det= ermine whether it needs this action type or not
> > > > 4. agent can dereference it, construct request and send= it to server
> > > >
> > > >
> > > > now if we add more actions:
> > > >
> > > > Link: </suspend-action>; rel=3D"action"= ; action-type=3D"suspend"; title=3D"Suspend"
> > > > Link: </restart-action>; rel=3D"action"= ; action-type=3D"restart"; title=3D"Restart"
> > > >
> > > > Link: </stop-action>; rel=3D"action"; a= ction-type=3D"stop"; title=3D"Stop"
> > > >
> > > >
> > > > #1, #2, #3 and #4 will be true for all of them without = exceptions.
> > > >
> > > > Now consider that representation containing these links= is used by GUI agent, in this case even "action-type" is not nec= essary at all and agent can rely on user's choice. Agent only needs to = know that:
> > > >
> > > > 1. link is an action(and this question is explicitly an= swered)
> > > > 2. if user choose one agent needs just to dereference i= ndicated URI
> > > > 3. construct request
> > > > 4. send request to server
> > > > 5. show results to user
> > > >
> > > > All of these will remain true for any action type.
> > > >
> > > > I'm not sure if i talked you down, but i believe &q= uot;action" relation type is useful and not because it is better(or si= mpler) compared to rel=3D"edit" for example.
> > > >
> > > > 1. http://tools.ietf.org= /html/draft-ioseb-dzmanashvili-action-link-relation-00
> > > > 2. http://tools.ietf.org= /html/draft-ioseb-dzmanashvili-action-link-relation-01
> > > >
> > > > P.S.
> > > > I was talking about 01 version of spec. 00 is a differe= nt story.
> > > >
> > > > Cheers,
> > > > ioseb
> > > > > mamund
> > > > > +1.859.757.1449 (tel:%2B1.859.757.1449) (tel:%2B1.85= 9.757.1449)
> > > > > skype: mca.amundsen
> > > > > http://amundsen.com/blog/
> > > > > http://twitter.com/mamund
> > > > > https://github.com/mamund
> > > > > http://www.linkedin.com/in/mikeamundsen
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Aug 27, 2013 = at 3:40 PM, Ioseb Dzmanashvili <ioseb.dzmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.com) (mai= lto:ioseb.dzmanashvili@gmai= l.com) (mailto:ioseb.dz= manashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.com)> wrote:
> > > > > > Hi Julian,
> > > > > >
> > > > > > Thanks for response!
> > > > > >
> > > > > > On Tuesday, August 27, 2013 at 2:15 PM, Julia= n Reschke wrote:
> > > > > >
> > > > > > > On 2013-08-27 11:03, Ioseb Dzmanashvili = wrote:
> > > > > > > > Hi All,
> > > > > > > >
> > > > > > > > I've updated the "action&q= uot; link relation type spec[1] based on initial feedback.
> > > > > > > >
> > > > > > > > As far as initial reactions were ve= ry controversial and raised a lot of issues i tried to address all of them = and entirely changed the spec.
> > > > > > > >
> > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > > > > > When included in a response, the &q= uot;action" link relation indicates a
> > > > > > > > target resource that is responsible= for performing action which MAY:
> > > > > > > >
> > > > > > > > - Affect state of the context resou= rce; or
> > > > > > > > - Initiate process.
> > > > > > > >
> > > > > > > > The "action" link relatio= n type can be used to indicate the
> > > > > > > > availability of actions supported b= y the target resource. Examples
> > > > > > > > of such actions include:
> > > > > > > >
> > > > > > > > - Enable/Disable
> > > > > > > > - Publish/Unpublish
> > > > > > > > - Start/Stop
> > > > > > > >
> > > > > > > > The "action" link relatio= n type doesn't convey any semantics other
> > > > > > > > than that an indicated resources re= present machine readable
> > > > > > > > description of a particular action = and representation SHOULD contain
> > > > > > > > all necessary details such as: requ= est method, action URI and other
> > > > > > > > related details to enable agents to= be able to construct requests
> > > > > > > > without relying on out-of-band info= rmation.
> > > > > > > >
> > > > > > > > Exact type of action SHOULD be indi= cated through the "action-type"
> > > > > > > > link-extension value as per [RFC598= 8] and for maintaining shared
> > > > > > > > understanding of action types curre= nt specification introduces the
> > > > > > > > registry of actions with initial va= lues of widely accepted and well
> > > > > > > > understood action types.
> > > > > > > >
> > > > > > > > For example, if a resource represen= ts a service, that same
> > > > > > > > representation may include links to= resources that represent actions
> > > > > > > > supported by the service:
> > > > > > > >
> > > > > > > > Link: </restart-action>; rel= =3D"action"; action-type=3D"restart"
> > > > > > > > Link: </stop-action>; rel=3D&= quot;action"; action-type=3D"stop"
> > > > > > > > ...
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > It seems that you are just adding an ind= irection mechanism. Why is that
> > > > > > > necessary?
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > With indirection mechanism i'm trying to = solve issues raised around initial version of the spec[1]. There were sever= al issues:
> > > > > >
> > > > > > 1. The "action" link relation type = doesn't have enough semantics and automated agents can not follow such = links if there are several actions included in a representation. With the &= quot;action-type" link extension + registry of predefined action types= agents can distinguish actions from each other.
> > > > > >
> > > > > > 2. Initial spec stated that if the "acti= on" link exists in representation, only thing agents should do is to s= end empty POST request to the target in order to perform action. This appro= ach was considered as an anti pattern(RPCish and non RESTful). With having = the "action-type" agents can:
> > > > > >
> > > > > > a) distinguish action links from each other;<= br> > > > > > > b) if necessary dereference the target to obt= ain instructions for constructing non empty POST/PUT requests;
> > > > > > c) send properly constructed request back to = the target; and
> > > > > > d) it makes possible for servers to dictate s= tructure of the request according to there own needs.
> > > > > >
> > > > > > Main purpose of the "action" link r= elation type is to define semantics of particular class of links - actions.= This eliminates the need to redefine notion of "action" for each= link relation type which may be qualified as action link. The "action= -type" is just for naming actions and is particularly useful for autom= ated agents not necessarily for human interaction oriented agents.
> > > > > >
> > > > > > Having action type registry is important for = maintaining shared understanding of particular action types. For example &q= uot;reset" or "publish" verbs do not need to be redefined fr= om application to application. I also believe that it is not efficient(or f= easible) to register all possible actions as link relations.
> > > > > >
> > > > > > 1. http://tool= s.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-00
> > > > > > 2. http://tool= s.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-01
> > > > > > >
> > > > > > > Best regards, Julian
> > > > > > Cheers,
> > > > > > ioseb
> > > > > >
> > > > > > _____________________________________________= __
> > > > > > link-relations mailing list
> > > > > > link-relations@ietf.org (mailto:link-relations@ietf.org) (mailto:link-relations@ietf.org) (mailto:link-relations@ietf.org) (mailto:link-relations@ietf.org) (mailto:link-relations@ietf.org)
> > > > > > https://www.ietf.org/mailman/listinfo= /link-relations
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>




--047d7bae47381a1f2704e5057926-- From ioseb.dzmanashvili@gmail.com Wed Aug 28 12:38: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 246EE11E81AF; Wed, 28 Aug 2013 12:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.347 X-Spam-Level: * X-Spam-Status: No, score=1.347 tagged_above=-999 required=5 tests=[AWL=-2.384, BAYES_50=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_92=0.6, SARE_RMML_Stock10=0.13] 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 7oFVMzh3JyP0; Wed, 28 Aug 2013 12:38:09 -0700 (PDT) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id DA4D211E8178; Wed, 28 Aug 2013 12:38:08 -0700 (PDT) Received: by mail-ee0-f48.google.com with SMTP id l10so3174802eei.35 for ; Wed, 28 Aug 2013 12:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:content-transfer-encoding :content-disposition; bh=T9DBwMree7sMDDKWoo7Q7JaZnMQVjJbVR6uQjyGKYFc=; b=sEn8mVonIsTxi/9XKD+pQsWZEf2/ZR35vtR04X9uWP4T1ZVmnvdEv03mHyrJJ4Rhon ziP7eKBAb6RClNlW8Elpr/mTM9JgIk/R6JUQx1Y2O48Q23KPSrxJz69znmbbEi0nXl1A ewuars9nIwEQQME2yN6+wkzHispHiqSPrO7NYubhX4HfNFlAMH+RZSi7bxDYzEgaBBq7 RyTr4sNrzm0GxDqfSneu4ykZSzlyN0B+22s7WIPbcLj/kTswpj6J7e6u6nUz4+6AE08D NMhpazAg+FXP7mAkE+Am8lsLVppc70Q/mI83pfFxCYpBWqHGV4iwzpnLlecgLE1cJjya 1x8Q== X-Received: by 10.14.241.74 with SMTP id f50mr45291462eer.29.1377718686934; Wed, 28 Aug 2013 12:38:06 -0700 (PDT) Received: from [192.168.1.6] ([176.73.174.236]) by mx.google.com with ESMTPSA id j7sm40050776eeo.15.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 28 Aug 2013 12:38:06 -0700 (PDT) Date: Wed, 28 Aug 2013 23:38:01 +0400 From: Ioseb Dzmanashvili To: mike amundsen Message-ID: <30BCEBA7E91E4DDF8D20B3311D362B27@gmail.com> In-Reply-To: References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <8410EE3EC8FB4ADA93F4209376AF8183@gmail.com> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Julian Reschke , IETF Apps Discuss , link-relations Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 28 Aug 2013 19:38:11 -0000 Mike, On Wednesday, August 28, 2013 at 9:39 PM, mike amundsen wrote: > > So here is my question: why is it bad=3F > > 1) creates a new registry for action-type instead of using existing reg= istry for rel (you point this out in the =22there is not start relation y= et=22 reasoning) > 2) ignores the use of link relation extension values already establishe= d in R=46C5988 (see Mike Kelly's question) > 3) introduces confusion on whether =40rel or =22action-type=22 should b= e used (see Peter Williams' question) > 4) uses two values (=22action=22 and =22=7Breason=7D=22) where only one= is needed (srsly, a constant string AND a variable=3F) =20 > =20 > IOW, you have two possible solutions already for the same outcome and a= re not using them. you've been offered at least one issue on conflicting = implementation and at least one on overly-complex implementation. =20 > =20 > if you are so sure that this implementation detail is important to the = =5Fresults=5F you want to achieve, then start today by doing it via link = extensions: =20 > > =20 > you can document and implement this today w/o any need to get an R=46C = approved or get even buy-in from others. You can create your own registry= and open it up to others for adds/edits (similar to the way microformats= operates). You can build working implementations, write papers on it, ad= vocate for use in various forums, etc. =20 > =20 I'd prefer to avoid this, i do not have enough resources to publicly main= tain such registry ;-) =20 > Over time you can monitor and record adoption, judge the up-take you ge= t and determine whether it proves to be a useful pattern. If it works wel= l and shows adoption, you'll see much less push-back from me (and, i susp= ect others) and will be able to replace: with and even allow existing implementations to su= pport both. =20 > =20 > IOW, nothing is stopping you from implementing a compliant version of t= his approach today and doing it in a way that would be compatible w/ adop= ting your proposed approach once your approach is proven to be worthy of = recording as a standard. =20 > =20 > finally, i'll say this: > > Actually as i see it =231 and =232 are of same importance. > > If the =5Fmethod=5F of achieving your results is non-negotiable, I have= little else to offer here > =20 All clear. As a conclusion: 1. Having the generic =22action=22 relation is worthless, at list as of 0= 0 and 01 proposals. At least i need to find better way to make it accepta= ble. 2. Action type registry complicates things(and i agree). 3. One possible way is to maintain separate registry(out of IET=46) which= is not feasible for me. 4. Most realistic is to register top level action link rels and i've seve= ral such relations: - start: start service or process - stop: stop service or process - restart: restart service or process - suspend: suspend service or process - reset: reset service or process to its initial state - publish: change state of the resource to published - unpublish: change state of the resource to unpublished - archive: change state of the resource to archived - unarchive: change state of the resource to unarchived - enable: change state of the resource to enabled - disable: change state of the resource to disabled These are actions i used frequently in various applications. Do you think= it is reasonable to register all of these as link relations=3F =46olks=3F What do you think=3F Cheers, ioseb =20 > . =20 > =20 > Cheers. > =20 > =20 > 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/mikeamundsen =20 > =20 > On Wed, Aug 28, 2013 at 12:41 PM, Ioseb Dzmanashvili wrote: > > Mike, > > =20 > > On Wednesday, August 28, 2013 at 6:33 PM, mike amundsen wrote: > > > Ioseb: > > > =20 > > > now that i understand your aim... > > > =20 > > > it seems the first item (support a pattern...) is the important one= and the other two are just means to that end. > > Actually as i see it =231 and =232 are of same importance. > > =20 > > =20 > > > so why is this a good approach=3F > > =231 and =232 still hold. As i already said =233 makes sense only for= m2m scenarios and for GUI clients just knowing that a link is an action = and how to treat such action links is enough. > > =20 > > What i'm trying to achieve with my proposal is to generalise meaning = of action and make it consistent across different applications. Unfortuna= tely i do not see(or know, or was not able to find) better approach yet b= ut it is generic enough to solve whole class of problems at least on GUI = level + partially for m2m cases with =22action-type=22 attribute even if = we throw action type registry idea away. If we simplify definition of the= =22action=22 relation type and say: > > =20 > > 1. here is the =22action=22 link > > 2. it points to a resource which describes the action > > 3. to perform an action fetch it construct request and send it back t= o server. > > 4. if you want to know what this particular action means: > > 4.1. look inside the =22action-type=22 attribute if it presents; or > > 4.2. fetch the document and look inside it. > > =20 > > Is not it sufficient enough to cover whole class of problems in a con= sistent way which are clearly actions and not just related resources=3F > > =20 > > So here is my question: why is it bad=3F > > =20 > > > 1) why use the =22action=22 rel PLUS a param (=22start=22)=3F why n= ot just use the param (=22start=22) as the rel=3F > > =46or several reasons: > > =20 > > 1. there is no =22start=22 relation yet. > > 2. it doesn't have explicit sign that it is an action. > > 3. there are much more actions which are not registered and also ther= e is no guarantee that each newly registered relation(which can be qualif= ied as action) will state that it is an action in a consistent way. > > 4. the pattern as you noticed is still important(IMHO) > > =20 > > > 2) why not use two values for the rel as in =3F > > =20 > > It was suggested in the initial proposal though approach has drawback= s. if i use more rels=3F how to d= istinguish =22foo=22, =22bar=22 and =22baz=22 from each other=3F does it = mean that my action now has triple meaning=3F > > =20 > > > 3) why not use (as mike kelly suggests) an extension URI for the re= l as in > > > =20 > > > 4) why not use a unique element attribute/property such as =3F > > =20 > > is it different from =22action-type=22 attribute=3F or maybe problem = is in a registry of action types=3F > > =20 > > > 5) why not use a unique document element/property such as or =7B=22action=22: =7B=22rel=22:=22s= tart=22, =22href=22:=22...=22=7D=7D=3F > > Well, in custom media types i can do anything, though it doesn't make= sense outside of particular format or domain. Otherwise it is ok and i u= se similar approach in practice. > > =20 > > Cheers, > > ioseb > > =20 > > > =20 > > > mamund > > > +1.859.757.1449 (tel:%2B1.859.757.1449) > > > skype: mca.amundsen > > > http://amundsen.com/blog/ > > > http://twitter.com/mamund > > > https://github.com/mamund > > > http://www.linkedin.com/in/mikeamundsen > > > =20 > > > On Wed, Aug 28, 2013 at 3:35 AM, Ioseb Dzmanashvili wrote: > > > > Mike, > > > > =20 > > > > On Wednesday, August 28, 2013 at 5:26 AM, mike amundsen wrote: > > > > =20 > > > > > OK, from your response i get the following: > > > > > =20 > > > > > 1) you want to support a pattern where machine-readable state t= ransition instructions appear at the end of some URL. > > > > > 2) you want to indicate those instructions are available by mar= king the URL w/ the string literal =22action=22 (via rel in your illustra= tions) > > > > > 3) you want to indicate the reason for using these instructions= w/ an =22action-type=22 string (via a link-rel param in your illustratio= ns) > > > > > =20 > > > > > that's it. nothing else. > > > > > =20 > > > > > do i have this correct=3F > > > > =20 > > > > Exactly=21 That's it and nothing else. > > > > =20 > > > > Cheers, > > > > ioseb > > > > =20 > > > > > =20 > > > > > =20 > > > > > mamund > > > > > +1.859.757.1449 (tel:%2B1.859.757.1449) (tel:%2B1.859.757.1449)= > > > > > skype: mca.amundsen > > > > > http://amundsen.com/blog/ > > > > > http://twitter.com/mamund > > > > > https://github.com/mamund > > > > > http://www.linkedin.com/in/mikeamundsen > > > > > =20 > > > > > On Tue, Aug 27, 2013 at 7:51 PM, Ioseb Dzmanashvili wrote: > > > > > > Hi Mike, > > > > > > =20 > > > > > > Thanks for the question=21 > > > > > > =20 > > > > > > On Tuesday, August 27, 2013 at 11:57 PM, mike amundsen wrote:= > > > > > > =20 > > > > > > > Ioseb: > > > > > > > =20 > > > > > > > it is not clear to me why: > > > > > > > is preferable to: > > > > > > > =20 > > > > > > > talk me down ;) > > > > > > let me try ;) > > > > > > =20 > > > > > > Question is not about why: Link: <=E2=80=A6>; rel=3D=22action= =22; action-type=3D=22edit=22 is preferable to: Link: <=E2=80=A6>; rel=3D= =22edit=22. > > > > > > =20 > > > > > > Of course i'd choose rel=3D=22run-forest-run=22 if there is a= registered link relation type, but: > > > > > > =20 > > > > > > 1. The =22action=22 link relation is generic enough, has well= understood meaning and is useful on its own especially for human oriente= d agents. > > > > > > 2. The =22action-type=22 optional attribute may be used for s= pecifying exact meaning of actions and this makes action links more usefu= l for m2m scenarios. > > > > > > =20 > > > > > > Now consider this link: > > > > > > =20 > > > > > > Link: ; rel=3D=22action=22; action-type=3D=22= suspend=22; title=3D=22Suspend=22 > > > > > > =20 > > > > > > What it says=3F > > > > > > =20 > > > > > > 1. it is an action > > > > > > 2. target resource represents description of the action which= contains: request method, submit URI, definition of action, other detail= s etc > > > > > > 3. agent can look inside =22action-type=22 to determine wheth= er it needs this action type or not > > > > > > 4. agent can dereference it, construct request and send it to= server > > > > > > =20 > > > > > > =20 > > > > > > now if we add more actions: > > > > > > =20 > > > > > > Link: ; rel=3D=22action=22; action-type=3D=22= suspend=22; title=3D=22Suspend=22 > > > > > > Link: ; rel=3D=22action=22; action-type=3D=22= restart=22; title=3D=22Restart=22 > > > > > > =20 > > > > > > Link: ; rel=3D=22action=22; action-type=3D=22st= op=22; title=3D=22Stop=22 > > > > > > =20 > > > > > > =20 > > > > > > =231, =232, =233 and =234 will be true for all of them withou= t exceptions. > > > > > > =20 > > > > > > Now consider that representation containing these links is us= ed by GUI agent, in this case even =22action-type=22 is not necessary at = all and agent can rely on user's choice. Agent only needs to know that: > > > > > > =20 > > > > > > 1. link is an action(and this question is explicitly answered= ) > > > > > > 2. if user choose one agent needs just to dereference indicat= ed URI > > > > > > 3. construct request > > > > > > 4. send request to server > > > > > > 5. show results to user > > > > > > =20 > > > > > > All of these will remain true for any action type. > > > > > > =20 > > > > > > I'm not sure if i talked you down, but i believe =22action=22= relation type is useful and not because it is better(or simpler) compare= d to rel=3D=22edit=22 for example. > > > > > > =20 > > > > > > 1. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action= -link-relation-00 > > > > > > 2. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action= -link-relation-01 > > > > > > =20 > > > > > > P.S. > > > > > > I was talking about 01 version of spec. 00 is a different sto= ry. > > > > > > =20 > > > > > > Cheers, > > > > > > ioseb > > > > > > > mamund > > > > > > > +1.859.757.1449 (tel:%2B1.859.757.1449) (tel:%2B1.859.757.1= 449) (tel:%2B1.859.757.1449) > > > > > > > skype: mca.amundsen > > > > > > > http://amundsen.com/blog/ > > > > > > > http://twitter.com/mamund > > > > > > > https://github.com/mamund > > > > > > > http://www.linkedin.com/in/mikeamundsen > > > > > > > =20 > > > > > > > =20 > > > > > > > =20 > > > > > > > On Tue, Aug 27, 2013 at 3:40 PM, Ioseb Dzmanashvili wrote: > > > > > > > > Hi Julian, > > > > > > > > =20 > > > > > > > > Thanks for response=21 > > > > > > > > =20 > > > > > > > > On Tuesday, August 27, 2013 at 2:15 PM, Julian Reschke wr= ote: > > > > > > > > =20 > > > > > > > > > On 2013-08-27 11:03, Ioseb Dzmanashvili wrote: > > > > > > > > > > Hi All, > > > > > > > > > > =20 > > > > > > > > > > I've updated the =22action=22 link relation type spec= =5B1=5D based on initial feedback. > > > > > > > > > > =20 > > > > > > > > > > As far as initial reactions were very controversial a= nd raised a lot of issues i tried to address all of them and entirely cha= nged the spec. > > > > > > > > > > =20 > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > When included in a response, the =22action=22 link re= lation indicates a > > > > > > > > > > target resource that is responsible for performing ac= tion which MAY: > > > > > > > > > > =20 > > > > > > > > > > - Affect state of the context resource; or > > > > > > > > > > - Initiate process. > > > > > > > > > > =20 > > > > > > > > > > The =22action=22 link relation type can be used to in= dicate the > > > > > > > > > > availability of actions supported by the target resou= rce. Examples > > > > > > > > > > of such actions include: > > > > > > > > > > =20 > > > > > > > > > > - Enable/Disable > > > > > > > > > > - Publish/Unpublish > > > > > > > > > > - Start/Stop > > > > > > > > > > =20 > > > > > > > > > > The =22action=22 link relation type doesn't convey an= y semantics other > > > > > > > > > > than that an indicated resources represent machine re= adable > > > > > > > > > > description of a particular action and representation= SHOULD contain > > > > > > > > > > all necessary details such as: request method, action= URI and other > > > > > > > > > > related details to enable agents to be able to constr= uct requests > > > > > > > > > > without relying on out-of-band information. > > > > > > > > > > =20 > > > > > > > > > > Exact type of action SHOULD be indicated through the = =22action-type=22 > > > > > > > > > > link-extension value as per =5BR=46C5988=5D and for m= aintaining shared > > > > > > > > > > understanding of action types current specification i= ntroduces the > > > > > > > > > > registry of actions with initial values of widely acc= epted and well > > > > > > > > > > understood action types. > > > > > > > > > > =20 > > > > > > > > > > =46or example, if a resource represents a service, th= at same > > > > > > > > > > representation may include links to resources that re= present actions > > > > > > > > > > supported by the service: > > > > > > > > > > =20 > > > > > > > > > > Link: ; rel=3D=22action=22; action-t= ype=3D=22restart=22 > > > > > > > > > > Link: ; rel=3D=22action=22; action-type= =3D=22stop=22 > > > > > > > > > > ... > > > > > > > > > > =20 > > > > > > > > > =20 > > > > > > > > > =20 > > > > > > > > > =20 > > > > > > > > > =20 > > > > > > > > > =20 > > > > > > > > > =20 > > > > > > > > > =20 > > > > > > > > > It seems that you are just adding an indirection mechan= ism. Why is that > > > > > > > > > necessary=3F > > > > > > > > > =20 > > > > > > > > =20 > > > > > > > > =20 > > > > > > > > =20 > > > > > > > > =20 > > > > > > > > =20 > > > > > > > > With indirection mechanism i'm trying to solve issues rai= sed around initial version of the spec=5B1=5D. There were several issues:= > > > > > > > > =20 > > > > > > > > 1. The =22action=22 link relation type doesn't have enoug= h semantics and automated agents can not follow such links if there are s= everal actions included in a representation. With the =22action-type=22 l= ink extension + registry of predefined action types agents can distinguis= h actions from each other. > > > > > > > > =20 > > > > > > > > 2. Initial spec stated that if the =22action=22 link exis= ts in representation, only thing agents should do is to send empty POST r= equest to the target in order to perform action. This approach was consid= ered as an anti pattern(RPCish and non RESTful). With having the =22actio= n-type=22 agents can: > > > > > > > > =20 > > > > > > > > a) distinguish action links from each other; > > > > > > > > b) if necessary dereference the target to obtain instruct= ions for constructing non empty POST/PUT requests; > > > > > > > > c) send properly constructed request back to the target; = and > > > > > > > > d) it makes possible for servers to dictate structure of = the request according to there own needs. > > > > > > > > =20 > > > > > > > > Main purpose of the =22action=22 link relation type is to= define semantics of particular class of links - actions. This eliminates= the need to redefine notion of =22action=22 for each link relation type = which may be qualified as action link. The =22action-type=22 is just for = naming actions and is particularly useful for automated agents not necess= arily for human interaction oriented agents. > > > > > > > > =20 > > > > > > > > Having action type registry is important for maintaining = shared understanding of particular action types. =46or example =22reset=22= or =22publish=22 verbs do not need to be redefined from application to a= pplication. I also believe that it is not efficient(or feasible) to regis= ter all possible actions as link relations. > > > > > > > > =20 > > > > > > > > 1. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-ac= tion-link-relation-00 > > > > > > > > 2. http://tools.ietf.org/html/draft-ioseb-dzmanashvili-ac= tion-link-relation-01 > > > > > > > > > =20 > > > > > > > > > Best regards, Julian > > > > > > > > Cheers, > > > > > > > > ioseb > > > > > > > > =20 > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F > > > > > > > > link-relations mailing list > > > > > > > > link-relations=40ietf.org (mailto:link-relations=40ietf.o= rg) (mailto:link-relations=40ietf.org) (mailto:link-relations=40ietf.org)= (mailto:link-relations=40ietf.org) (mailto:link-relations=40ietf.org) (m= ailto:link-relations=40ietf.org) > > > > > > > > https://www.ietf.org/mailman/listinfo/link-relations > > > > > > > > =20 > > > > > > > =20 > > > > > > > =20 > > > > > > =20 > > > > > > =20 > > > > > =20 > > > > > =20 > > > > =20 > > > > =20 > > > =20 > > > =20 > > =20 > > =20 > =20 > =20 From mca@amundsen.com Wed Aug 28 13:02: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 283CF21F9D53 for ; Wed, 28 Aug 2013 13:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.509 X-Spam-Level: **** X-Spam-Status: No, score=4.509 tagged_above=-999 required=5 tests=[AWL=-1.142, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=2.297, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock10=0.13] 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 JaAcVbLTOWIa for ; Wed, 28 Aug 2013 13:02:45 -0700 (PDT) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by ietfa.amsl.com (Postfix) with ESMTP id A949711E81A8 for ; Wed, 28 Aug 2013 13:02:44 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id q55so5584882wes.22 for ; Wed, 28 Aug 2013 13:02:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=Co0gVadWXsrHgP3exQ3gXN0cwr3wjU72GEVBmVRIsbs=; b=IowdAqPTfkAfi44fD5ra9MVfg2QaPATdX6dvIXlpZlb4P/N/33xTydFq3C97CpPQNR toE/AQCqsMZrDfAVDWTMy1EyE9YzTEFRFSr3+lITcg+j58Gui/kb4v6gT/4/1dtYkFTB mfre1LSvPo3WfMv2iXT+gaKoVSf/Sa1nyjQUnjQ3oYx+oUajn/Emb8PvkCfBMuq09sxq IpdvFNncZbOVTUxTNC8cXvlA5O1IERPmk7GTg/877RFTDc7rd+7qN+/AkFbj+kUQL7Mu xUsX6uwXY+JNsAN/JB6pK0Shq9MyKFAeNBXquTFo5G+cFewAJytdz1CHQzsd6C7YT77P 5wFA== X-Gm-Message-State: ALoCoQneIMDd0/zlUx7NIGh3ShgBtps16CPZd2+j/24Rtp0Iy94ersotSSTo4Q9RUemDeTquSSNK X-Received: by 10.194.93.135 with SMTP id cu7mr5101136wjb.73.1377720159661; Wed, 28 Aug 2013 13:02:39 -0700 (PDT) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.151.7 with HTTP; Wed, 28 Aug 2013 13:02:19 -0700 (PDT) In-Reply-To: <30BCEBA7E91E4DDF8D20B3311D362B27@gmail.com> References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <8410EE3EC8FB4ADA93F4209376AF8183@gmail.com> <30BCEBA7E91E4DDF8D20B3311D362B27@gmail.com> From: mike amundsen Date: Wed, 28 Aug 2013 16:02:19 -0400 X-Google-Sender-Auth: fYDpH5XD66dpILJzv8ltAX4BVOM Message-ID: To: Ioseb Dzmanashvili Content-Type: multipart/alternative; boundary=047d7bb03eb6b782fe04e50778ce Cc: Julian Reschke , IETF Apps Discuss , link-relations Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 28 Aug 2013 20:02:49 -0000 --047d7bb03eb6b782fe04e50778ce Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable If you want to author and register new link relation values i have a couple recommendations: 1) check out the microformats existing rel values page[1] along with the usual IANA Link Relations page[2]. And the Dublin Core page has some good stuff, too[3]. these will give you an idea of what's already out there and some sense of what is in use. Peeking at Schema.org[4] and Activity Streams[5] may help, but i've not done that much lately. 2) when crafting link rel values, i got good advice (I think it was from JulianR?) to cast the definitions as "relations" not just "verbs" or "nouns." for example: "The link relation {value} identifies a target resource that represents {a concept}." There are variations, but you'll get the idea. 3) once you have solid defs/values and documentation, i'd post that publicly as a set and ask for feedback (here is a great place to start) 4) once you feel that the defs and values are solid, i suggest posting them to the microformats wiki first. they are open to edits and also very quick to provide feedback. i've had a good experience there. 5) once you have entries in the microformats list, you're more likely to be able (IMO) to translate late that same set of des/values into something that passes muster as an Informational RFC. Of course, you can start using the values now (and getting others to do the same) by relying on the Link Extension rules from 5988[6]. Watching that unfold will give you and idea on the usefulness/popularity of your proposed values. Finally, i had some (old) random notes on my early work learning about Link-Rel-Values[7] that might still contain some value. Feel free to poke around there. Hope this helps. [1] http://microformats.org/wiki/existing-rel-values [2] http://www.iana.org/assignments/link-relations/link-relations.xml [3] http://dublincore.org/documents/dc-html/ [4] http://schema.org/ [5] http://activitystrea.ms/ [6] http://tools.ietf.org/html/rfc5988#section-4.2 [7] http://amundsen.com/media-types/linkrelations/ 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/mikeamundsen On Wed, Aug 28, 2013 at 3:38 PM, Ioseb Dzmanashvili < ioseb.dzmanashvili@gmail.com> wrote: > Mike, > > On Wednesday, August 28, 2013 at 9:39 PM, mike amundsen wrote: > > > > > So here is my question: why is it bad? > > > > 1) creates a new registry for action-type instead of using existing > registry for rel (you point this out in the "there is not start relation > yet" reasoning) > > 2) ignores the use of link relation extension values already establishe= d > in RFC5988 (see Mike Kelly's question) > > 3) introduces confusion on whether @rel or "action-type" should be used > (see Peter Williams' question) > > 4) uses two values ("action" and "{reason}") where only one is needed > (srsly, a constant string AND a variable?) > > > > IOW, you have two possible solutions already for the same outcome and > are not using them. you've been offered at least one issue on conflicting > implementation and at least one on overly-complex implementation. > > > > if you are so sure that this implementation detail is important to the > _results_ you want to achieve, then start today by doing it via link > extensions: > > > > > > you can document and implement this today w/o any need to get an RFC > approved or get even buy-in from others. You can create your own registry > and open it up to others for adds/edits (similar to the way microformats > operates). You can build working implementations, write papers on it, > advocate for use in various forums, etc. > > > I'd prefer to avoid this, i do not have enough resources to publicly > maintain such registry ;-) > > > Over time you can monitor and record adoption, judge the up-take you ge= t > and determine whether it proves to be a useful pattern. If it works well > and shows adoption, you'll see much less push-back from me (and, i suspec= t > others) and will be able to replace: http://actions.io/action;action-type=3D"start" ... /> with rel=3D"action;action-type=3D"start" ... /> and even allow existing > implementations to support both. > > > > IOW, nothing is stopping you from implementing a compliant version of > this approach today and doing it in a way that would be compatible w/ > adopting your proposed approach once your approach is proven to be worthy > of recording as a standard. > > > > finally, i'll say this: > > > > Actually as i see it #1 and #2 are of same importance. > > > > If the _method_ of achieving your results is non-negotiable, I have > little else to offer here > > > > All clear. > > As a conclusion: > > 1. Having the generic "action" relation is worthless, at list as of 00 an= d > 01 proposals. At least i need to find better way to make it acceptable. > 2. Action type registry complicates things(and i agree). > 3. One possible way is to maintain separate registry(out of IETF) which i= s > not feasible for me. > 4. Most realistic is to register top level action link rels and i've > several such relations: > > - start: start service or process > - stop: stop service or process > - restart: restart service or process > - suspend: suspend service or process > - reset: reset service or process to its initial state > > - publish: change state of the resource to published > - unpublish: change state of the resource to unpublished > - archive: change state of the resource to archived > - unarchive: change state of the resource to unarchived > > - enable: change state of the resource to enabled > - disable: change state of the resource to disabled > > These are actions i used frequently in various applications. Do you think > it is reasonable to register all of these as link relations? > > Folks? What do you think? > > Cheers, > ioseb > > > . > > > > Cheers. > > > > > > 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/mikeamundsen > > > > On Wed, Aug 28, 2013 at 12:41 PM, Ioseb Dzmanashvili < > ioseb.dzmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com)> wrote= : > > > Mike, > > > > > > On Wednesday, August 28, 2013 at 6:33 PM, mike amundsen wrote: > > > > Ioseb: > > > > > > > > now that i understand your aim... > > > > > > > > it seems the first item (support a pattern...) is the important one > and the other two are just means to that end. > > > Actually as i see it #1 and #2 are of same importance. > > > > > > > > > > so why is this a good approach? > > > #1 and #2 still hold. As i already said #3 makes sense only for m2m > scenarios and for GUI clients just knowing that a link is an action and h= ow > to treat such action links is enough. > > > > > > What i'm trying to achieve with my proposal is to generalise meaning > of action and make it consistent across different applications. > Unfortunately i do not see(or know, or was not able to find) better > approach yet but it is generic enough to solve whole class of problems at > least on GUI level + partially for m2m cases with "action-type" attribute > even if we throw action type registry idea away. If we simplify definitio= n > of the "action" relation type and say: > > > > > > 1. here is the "action" link > > > 2. it points to a resource which describes the action > > > 3. to perform an action fetch it construct request and send it back t= o > server. > > > 4. if you want to know what this particular action means: > > > 4.1. look inside the "action-type" attribute if it presents; or > > > 4.2. fetch the document and look inside it. > > > > > > Is not it sufficient enough to cover whole class of problems in a > consistent way which are clearly actions and not just related resources? > > > > > > So here is my question: why is it bad? > > > > > > > 1) why use the "action" rel PLUS a param ("start")? why not just us= e > the param ("start") as the rel? > > > For several reasons: > > > > > > 1. there is no "start" relation yet. > > > 2. it doesn't have explicit sign that it is an action. > > > 3. there are much more actions which are not registered and also ther= e > is no guarantee that each newly registered relation(which can be qualifie= d > as action) will state that it is an action in a consistent way. > > > 4. the pattern as you noticed is still important(IMHO) > > > > > > > 2) why not use two values for the rel as in />? > > > > > > It was suggested in the initial proposal though approach has > drawbacks. if i use more rels? how to > distinguish "foo", "bar" and "baz" from each other? does it mean that my > action now has triple meaning? > > > > > > > 3) why not use (as mike kelly suggests) an extension URI for the re= l > as in > > > > > > > > 4) why not use a unique element attribute/property such as rel=3D"action" reason=3D"start" .../>? > > > > > > is it different from "action-type" attribute? or maybe problem is in = a > registry of action types? > > > > > > > 5) why not use a unique document element/property such as rel=3D"start" href=3D"..."/> or {"action": {"rel":"start", "href":"..."}}= ? > > > Well, in custom media types i can do anything, though it doesn't make > sense outside of particular format or domain. Otherwise it is ok and i us= e > similar approach in practice. > > > > > > Cheers, > > > ioseb > > > > > > > > > > > mamund > > > > +1.859.757.1449 (tel:%2B1.859.757.1449) > > > > skype: mca.amundsen > > > > http://amundsen.com/blog/ > > > > http://twitter.com/mamund > > > > https://github.com/mamund > > > > http://www.linkedin.com/in/mikeamundsen > > > > > > > > On Wed, Aug 28, 2013 at 3:35 AM, Ioseb Dzmanashvili < > ioseb.dzmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com) > (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.co= m)> > wrote: > > > > > Mike, > > > > > > > > > > On Wednesday, August 28, 2013 at 5:26 AM, mike amundsen wrote: > > > > > > > > > > > OK, from your response i get the following: > > > > > > > > > > > > 1) you want to support a pattern where machine-readable state > transition instructions appear at the end of some URL. > > > > > > 2) you want to indicate those instructions are available by > marking the URL w/ the string literal "action" (via rel in your > illustrations) > > > > > > 3) you want to indicate the reason for using these instructions > w/ an "action-type" string (via a link-rel param in your illustrations) > > > > > > > > > > > > that's it. nothing else. > > > > > > > > > > > > do i have this correct? > > > > > > > > > > Exactly! That's it and nothing else. > > > > > > > > > > Cheers, > > > > > ioseb > > > > > > > > > > > > > > > > > > > > > > > mamund > > > > > > +1.859.757.1449 (tel:%2B1.859.757.1449) (tel:%2B1.859.757.1449) > > > > > > skype: mca.amundsen > > > > > > http://amundsen.com/blog/ > > > > > > http://twitter.com/mamund > > > > > > https://github.com/mamund > > > > > > http://www.linkedin.com/in/mikeamundsen > > > > > > > > > > > > On Tue, Aug 27, 2013 at 7:51 PM, Ioseb Dzmanashvili < > ioseb.dzmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com) > (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.co= m) > (mailto:ioseb.dzmanashvili@gmail.com)> wrote: > > > > > > > Hi Mike, > > > > > > > > > > > > > > Thanks for the question! > > > > > > > > > > > > > > On Tuesday, August 27, 2013 at 11:57 PM, mike amundsen wrote: > > > > > > > > > > > > > > > Ioseb: > > > > > > > > > > > > > > > > it is not clear to me why: rel=3D"action;action-type=3D'edit'" href=3D"..." /> > > > > > > > > is preferable to: > > > > > > > > > > > > > > > > talk me down ;) > > > > > > > let me try ;) > > > > > > > > > > > > > > Question is not about why: Link: <=85>; rel=3D"action"; > action-type=3D"edit" is preferable to: Link: <=85>; rel=3D"edit". > > > > > > > > > > > > > > Of course i'd choose rel=3D"run-forest-run" if there is a > registered link relation type, but: > > > > > > > > > > > > > > 1. The "action" link relation is generic enough, has well > understood meaning and is useful on its own especially for human oriented > agents. > > > > > > > 2. The "action-type" optional attribute may be used for > specifying exact meaning of actions and this makes action links more usef= ul > for m2m scenarios. > > > > > > > > > > > > > > Now consider this link: > > > > > > > > > > > > > > Link: ; rel=3D"action"; action-type=3D"suspe= nd"; > title=3D"Suspend" > > > > > > > > > > > > > > What it says? > > > > > > > > > > > > > > 1. it is an action > > > > > > > 2. target resource represents description of the action which > contains: request method, submit URI, definition of action, other details > etc > > > > > > > 3. agent can look inside "action-type" to determine whether i= t > needs this action type or not > > > > > > > 4. agent can dereference it, construct request and send it to > server > > > > > > > > > > > > > > > > > > > > > now if we add more actions: > > > > > > > > > > > > > > Link: ; rel=3D"action"; action-type=3D"suspe= nd"; > title=3D"Suspend" > > > > > > > Link: ; rel=3D"action"; action-type=3D"resta= rt"; > title=3D"Restart" > > > > > > > > > > > > > > Link: ; rel=3D"action"; action-type=3D"stop"; > title=3D"Stop" > > > > > > > > > > > > > > > > > > > > > #1, #2, #3 and #4 will be true for all of them without > exceptions. > > > > > > > > > > > > > > Now consider that representation containing these links is > used by GUI agent, in this case even "action-type" is not necessary at al= l > and agent can rely on user's choice. Agent only needs to know that: > > > > > > > > > > > > > > 1. link is an action(and this question is explicitly answered= ) > > > > > > > 2. if user choose one agent needs just to dereference > indicated URI > > > > > > > 3. construct request > > > > > > > 4. send request to server > > > > > > > 5. show results to user > > > > > > > > > > > > > > All of these will remain true for any action type. > > > > > > > > > > > > > > I'm not sure if i talked you down, but i believe "action" > relation type is useful and not because it is better(or simpler) compared > to rel=3D"edit" for example. > > > > > > > > > > > > > > 1. > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-= 00 > > > > > > > 2. > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-= 01 > > > > > > > > > > > > > > P.S. > > > > > > > I was talking about 01 version of spec. 00 is a different > story. > > > > > > > > > > > > > > Cheers, > > > > > > > ioseb > > > > > > > > mamund > > > > > > > > +1.859.757.1449 (tel:%2B1.859.757.1449) > (tel:%2B1.859.757.1449) (tel:%2B1.859.757.1449) > > > > > > > > skype: mca.amundsen > > > > > > > > http://amundsen.com/blog/ > > > > > > > > http://twitter.com/mamund > > > > > > > > https://github.com/mamund > > > > > > > > http://www.linkedin.com/in/mikeamundsen > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 27, 2013 at 3:40 PM, Ioseb Dzmanashvili < > ioseb.dzmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com) > (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.co= m) > (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.co= m) > (mailto:ioseb.dzmanashvili@gmail.com)> wrote: > > > > > > > > > Hi Julian, > > > > > > > > > > > > > > > > > > Thanks for response! > > > > > > > > > > > > > > > > > > On Tuesday, August 27, 2013 at 2:15 PM, Julian Reschke > wrote: > > > > > > > > > > > > > > > > > > > On 2013-08-27 11:03, Ioseb Dzmanashvili wrote: > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > > > > > I've updated the "action" link relation type spec[1] > based on initial feedback. > > > > > > > > > > > > > > > > > > > > > > As far as initial reactions were very controversial > and raised a lot of issues i tried to address all of them and entirely > changed the spec. > > > > > > > > > > > > > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > > When included in a response, the "action" link > relation indicates a > > > > > > > > > > > target resource that is responsible for performing > action which MAY: > > > > > > > > > > > > > > > > > > > > > > - Affect state of the context resource; or > > > > > > > > > > > - Initiate process. > > > > > > > > > > > > > > > > > > > > > > The "action" link relation type can be used to > indicate the > > > > > > > > > > > availability of actions supported by the target > resource. Examples > > > > > > > > > > > of such actions include: > > > > > > > > > > > > > > > > > > > > > > - Enable/Disable > > > > > > > > > > > - Publish/Unpublish > > > > > > > > > > > - Start/Stop > > > > > > > > > > > > > > > > > > > > > > The "action" link relation type doesn't convey any > semantics other > > > > > > > > > > > than that an indicated resources represent machine > readable > > > > > > > > > > > description of a particular action and representation > SHOULD contain > > > > > > > > > > > all necessary details such as: request method, action > URI and other > > > > > > > > > > > related details to enable agents to be able to > construct requests > > > > > > > > > > > without relying on out-of-band information. > > > > > > > > > > > > > > > > > > > > > > Exact type of action SHOULD be indicated through the > "action-type" > > > > > > > > > > > link-extension value as per [RFC5988] and for > maintaining shared > > > > > > > > > > > understanding of action types current specification > introduces the > > > > > > > > > > > registry of actions with initial values of widely > accepted and well > > > > > > > > > > > understood action types. > > > > > > > > > > > > > > > > > > > > > > For example, if a resource represents a service, that > same > > > > > > > > > > > representation may include links to resources that > represent actions > > > > > > > > > > > supported by the service: > > > > > > > > > > > > > > > > > > > > > > Link: ; rel=3D"action"; > action-type=3D"restart" > > > > > > > > > > > Link: ; rel=3D"action"; action-type=3D"= stop" > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It seems that you are just adding an indirection > mechanism. Why is that > > > > > > > > > > necessary? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > With indirection mechanism i'm trying to solve issues > raised around initial version of the spec[1]. There were several issues: > > > > > > > > > > > > > > > > > > 1. The "action" link relation type doesn't have enough > semantics and automated agents can not follow such links if there are > several actions included in a representation. With the "action-type" link > extension + registry of predefined action types agents can distinguish > actions from each other. > > > > > > > > > > > > > > > > > > 2. Initial spec stated that if the "action" link exists i= n > representation, only thing agents should do is to send empty POST request > to the target in order to perform action. This approach was considered as > an anti pattern(RPCish and non RESTful). With having the "action-type" > agents can: > > > > > > > > > > > > > > > > > > a) distinguish action links from each other; > > > > > > > > > b) if necessary dereference the target to obtain > instructions for constructing non empty POST/PUT requests; > > > > > > > > > c) send properly constructed request back to the target; > and > > > > > > > > > d) it makes possible for servers to dictate structure of > the request according to there own needs. > > > > > > > > > > > > > > > > > > Main purpose of the "action" link relation type is to > define semantics of particular class of links - actions. This eliminates > the need to redefine notion of "action" for each link relation type which > may be qualified as action link. The "action-type" is just for naming > actions and is particularly useful for automated agents not necessarily f= or > human interaction oriented agents. > > > > > > > > > > > > > > > > > > Having action type registry is important for maintaining > shared understanding of particular action types. For example "reset" or > "publish" verbs do not need to be redefined from application to > application. I also believe that it is not efficient(or feasible) to > register all possible actions as link relations. > > > > > > > > > > > > > > > > > > 1. > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-= 00 > > > > > > > > > 2. > http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-= 01 > > > > > > > > > > > > > > > > > > > > Best regards, Julian > > > > > > > > > Cheers, > > > > > > > > > ioseb > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > link-relations mailing list > > > > > > > > > link-relations@ietf.org (mailto:link-relations@ietf.org) > (mailto:link-relations@ietf.org) (mailto:link-relations@ietf.org) (mailto= : > link-relations@ietf.org) (mailto:link-relations@ietf.org) (mailto: > link-relations@ietf.org) > > > > > > > > > https://www.ietf.org/mailman/listinfo/link-relations > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --047d7bb03eb6b782fe04e50778ce Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
If you want to author and register new link relation value= s i have a couple recommendations:

1) check out the micr= oformats existing rel values page[1] along with the usual IANA Link Relatio= ns page[2]. And the Dublin Core page has some good stuff, too[3]. these wil= l give you an idea of what's already out there and some sense of what i= s in use. Peeking at Schema.org[4] and Activity Streams[5] may help, but i&= #39;ve not done that much lately.

2) when crafting link rel values, i got good advice (I = think it was from JulianR?) to cast the definitions as "relations"= ; not just "verbs" or "nouns." for example:
"The link relation {value} identifi= es a target resource that represents {a concept}." There are variation= s, but you'll get the idea.

3) once you have solid defs/values and documentation, i'd post t= hat publicly as a set and ask for feedback (here is a great place to start)=

4) once you feel that the defs and values are solid, i suggest = posting them to the microformats wiki first. they are open to edits and als= o very quick to provide feedback. i've had a good experience there.

5) once you have entries in the microformats list, you're m= ore likely to be able (IMO) to translate late that same set of des/values i= nto something that passes muster as an Informational RFC.

Of course, you can start using the values now (and getting othe= rs to do the same) by relying on the Link Extension rules from 5988[6]. Wat= ching that unfold will give you and idea on the usefulness/popularity of yo= ur proposed values.

Finally, i had some (old) random notes on my early work = learning about Link-Rel-Values[7] that might still contain some value. Feel= free to poke around there.

Hope this helps.




On Wed, Aug 28, 2013 at 3:38 PM, Ioseb D= zmanashvili <ioseb.dzmanashvili@gmail.com> wrote:=
Mike,

On Wednesday, August 28, 2013 at 9:39 PM, mike amundsen wrote:

> <snip>
> So here is my question: why is it bad?
> </snip>
> 1) creates a new registry for action-type instead of using existing re= gistry for rel (you point this out in the "there is not start relation= yet" reasoning)
> 2) ignores the use of link relation extension values already establish= ed in RFC5988 (see Mike Kelly's question)
> 3) introduces confusion on whether @rel or "action-type" sho= uld be used (see Peter Williams' question)
> 4) uses two values ("action" and "{reason}") where= only one is needed (srsly, a constant string AND a variable?)
>
> IOW, you have two possible solutions already for the same outcome and = are not using them. you've been offered at least one issue on conflicti= ng implementation and at least one on overly-complex implementation.
>
> if you are so sure that this implementation detail is important to the= _results_ you want to achieve, then start today by doing it via link exten= sions:
> <LINK rel=3D"http://actions.io/action;action-type=3D"sta= rt" ... />
>
> you can document and implement this today w/o any need to get an RFC a= pproved or get even buy-in from others. You can create your own registry an= d open it up to others for adds/edits (similar to the way microformats oper= ates). You can build working implementations, write papers on it, advocate = for use in various forums, etc.
>
I'd prefer to avoid this, i do not have enough resources to publi= cly maintain such registry ;-)

> Over time you can monitor and record adoption, judge the up-take you g= et and determine whether it proves to be a useful pattern. If it works well= and shows adoption, you'll see much less push-back from me (and, i sus= pect others) and will be able to replace: <LINK rel=3D"http://actions.io= /action;action-type=3D"start" ... /> with <LINK rel=3D&= quot;action;action-type=3D"start" ... /> and even allow existi= ng implementations to support both.
>
> IOW, nothing is stopping you from implementing a compliant version of = this approach today and doing it in a way that would be compatible w/ adopt= ing your proposed approach once your approach is proven to be worthy of rec= ording as a standard.
>
> finally, i'll say this:
> <snip>
> Actually as i see it #1 and #2 are of same importance.
> </snip>
> If the _method_ of achieving your results is non-negotiable, I have li= ttle else to offer here
>

All clear.

As a conclusion:

1. Having the generic "action" relation is worthless, at list as = of 00 and 01 proposals. At least i need to find better way to make it accep= table.
2. Action type registry complicates things(and i agree).
3. One possible way is to maintain separate registry(out of IETF) which is = not feasible for me.
4. Most realistic is to register top level action link rels and i've se= veral such relations:

- start: start service or process
- stop: stop service or process
- restart: restart service or process
- suspend: suspend service or process
- reset: reset service or process to its initial state

- publish: change state of the resource to published
- unpublish: change state of the resource to unpublished
- archive: change state of the resource to archived
- unarchive: change state of the resource to unarchived

- enable: change state of the resource to enabled
- disable: change state of the resource to disabled

These are actions i used frequently in various applications. Do you think i= t is reasonable to register all of these as link relations?

Folks? What do you think?

Cheers,
ioseb

> .
>
> Cheers.
>
>
> mamund
> +1.859.757.14= 49
> skype: mca.amundsen
> http://amundse= n.com/blog/
> http://twitter= .com/mamund
> https://github= .com/mamund
> = http://www.linkedin.com/in/mikeamundsen
>
> On Wed, Aug 28, 2013 at 12:41 PM, Ioseb Dzmana= shvili <ioseb.dzmanashvi= li@gmail.com (mailto:io= seb.dzmanashvili@gmail.com)> wrote:
> > Mike,
> >
> > On Wednesday, August 28, 2013 at 6:3= 3 PM, mike amundsen wrote:
> > > Ioseb:
> > >
> > > now that i understand your aim...
> > >
> > > it seems the first item (support a pattern...) is the import= ant one and the other two are just means to that end.
> > Actually as i see it #1 and #2 are of same importance.
> >
> >
> > > so why is this a good approach?
> > #1 and #2 still hold. As i already said #3 makes sense only for m= 2m scenarios and for GUI clients just knowing that a link is an action and = how to treat such action links is enough.
> >
> > What i'm trying to achieve with my proposal is to generalise = meaning of action and make it consistent across different applications. Unf= ortunately i do not see(or know, or was not able to find) better approach y= et but it is generic enough to solve whole class of problems at least on GU= I level + partially for m2m cases with "action-type" attribute ev= en if we throw action type registry idea away. If we simplify definition of= the "action" relation type and say:
> >
> > 1. here is the "action" link
> > 2. it points to a resource which describes the action
> > 3. to perform an action fetch it construct request and send it ba= ck to server.
> > 4. if you want to know what this particular action means:
> > 4.1. look inside the "action-type" attribute if it pres= ents; or
> > 4.2. fetch the document and look inside it.
> >
> > Is not it sufficient enough to cover whole class of problems in a= consistent way which are clearly actions and not just related resources? > >
> > So here is my question: why is it bad?
> >
> > > 1) why use the "action" rel PLUS a param ("st= art")? why not just use the param ("start") as the rel?
> > For several reasons:
> >
> > 1. there is no "start" relation yet.
> > 2. it doesn't have explicit sign that it is an action.
> > 3. there are much more actions which are not registered and also = there is no guarantee that each newly registered relation(which can be qual= ified as action) will state that it is an action in a consistent way.
> > 4. the pattern as you noticed is still important(IMHO)
> >
> > > 2) why not use two values for the rel as in <LINK rel=3D&= quot;action start" />?
> >
> > It was suggested in the initial proposal though approach has draw= backs. if i use more rels? <LINK rel=3D"action foo bar baz" /&= gt; how to distinguish "foo", "bar" and "baz"= from each other? does it mean that my action now has triple meaning?
> >
> > > 3) why not use (as mike kelly suggests) an extension URI for= the rel as in <LINK rel=3D"http://actions.io/start" ... />
> > >
> > > 4) why not use a unique element attribute/property such as &= lt;LINK rel=3D"action" reason=3D"start" .../>?
> >
> > is it different from "action-type" attribute? or maybe = problem is in a registry of action types?
> >
> > > 5) why not use a unique document element/property such as &l= t;action rel=3D"start" href=3D"..."/> or {"acti= on": {"rel":"start", "href":"...&qu= ot;}}?
> > Well, in custom media types i can do anything, though it doesn= 9;t make sense outside of particular format or domain. Otherwise it is ok a= nd i use similar approach in practice.
> >
> > Cheers,
> > ioseb
> >
> > >
> > > mamund
> > > +1.859.757.1449 (tel:%2B1.859.757.1449)
> > > skype: mca.amundsen
> > > http= ://amundsen.com/blog/
> > > http= ://twitter.com/mamund
> > > http= s://github.com/mamund
> > > http://www.linkedin.com/in/mikeamundsen
> > >
> > > On Wed, Aug 28, 2013 at 3:35 AM, Ios= eb Dzmanashvili <ioseb.d= zmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.com)> = wrote:
> > > > Mike,
> > > >
> > > > On Wednesday, August 28, 2013 at 5:26 AM, mike amundsen= wrote:
> > > >
> > > > > OK, from your response i get the following:
> > > > >
> > > > > 1) you want to support a pattern where machine-rea= dable state transition instructions appear at the end of some URL.
> > > > > 2) you want to indicate those instructions are ava= ilable by marking the URL w/ the string literal "action" (via rel= in your illustrations)
> > > > > 3) you want to indicate the reason for using these= instructions w/ an "action-type" string (via a link-rel param in= your illustrations)
> > > > >
> > > > > that's it. nothing else.
> > > > >
> > > > > do i have this correct?
> > > >
> > > > Exactly! That's it and nothing else.
> > > >
> > > > Cheers,
> > > > ioseb
> > > >
> > > > >
> > > > >
> > > > > mamund
> > > > > +1.859.757.1449 (tel:%2B1.859.757.1449) (tel:%2B1.859.757.= 1449)
> > > > > skype: mca.amundsen
> > > > > http://amundsen.com/blog/
> > > > > http://twitter.com/mamund
> > > > > https://github.com/mamund
> > > > > http://www.linkedin.com/in/mikeamundsen
> > > > >
> > > > > On Tue, Aug 27, 2013 = at 7:51 PM, Ioseb Dzmanashvili <ioseb.dzmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.com) (mai= lto:ioseb.dzmanashvili@gmai= l.com) (mailto:ioseb.dz= manashvili@gmail.com)> wrote:
> > > > > > Hi Mike,
> > > > > >
> > > > > > Thanks for the question!
> > > > > >
> > > > > > On Tuesday, August 27, 2013 at 11:57 PM, mike= amundsen wrote:
> > > > > >
> > > > > > > Ioseb:
> > > > > > >
> > > > > > > it is not clear to me why: <link rel= =3D"action;action-type=3D'edit'" href=3D"..." /= >
> > > > > > > is preferable to: <link rel=3D"e= dit" href=3D"..." />
> > > > > > >
> > > > > > > talk me down ;)
> > > > > > let me try ;)
> > > > > >
> > > > > > Question is not about why: Link: <=85>;= rel=3D"action"; action-type=3D"edit" is preferable to:= Link: <=85>; rel=3D"edit".
> > > > > >
> > > > > > Of course i'd choose rel=3D"run-fore= st-run" if there is a registered link relation type, but:
> > > > > >
> > > > > > 1. The "action" link relation is ge= neric enough, has well understood meaning and is useful on its own especial= ly for human oriented agents.
> > > > > > 2. The "action-type" optional attri= bute may be used for specifying exact meaning of actions and this makes act= ion links more useful for m2m scenarios.
> > > > > >
> > > > > > Now consider this link:
> > > > > >
> > > > > > Link: </suspend-action>; rel=3D"ac= tion"; action-type=3D"suspend"; title=3D"Suspend"<= br> > > > > > >
> > > > > > What it says?
> > > > > >
> > > > > > 1. it is an action
> > > > > > 2. target resource represents description of = the action which contains: request method, submit URI, definition of action= , other details etc
> > > > > > 3. agent can look inside "action-type&qu= ot; to determine whether it needs this action type or not
> > > > > > 4. agent can dereference it, construct reques= t and send it to server
> > > > > >
> > > > > >
> > > > > > now if we add more actions:
> > > > > >
> > > > > > Link: </suspend-action>; rel=3D"ac= tion"; action-type=3D"suspend"; title=3D"Suspend"<= br> > > > > > > Link: </restart-action>; rel=3D"ac= tion"; action-type=3D"restart"; title=3D"Restart"<= br> > > > > > >
> > > > > > Link: </stop-action>; rel=3D"actio= n"; action-type=3D"stop"; title=3D"Stop"
> > > > > >
> > > > > >
> > > > > > #1, #2, #3 and #4 will be true for all of the= m without exceptions.
> > > > > >
> > > > > > Now consider that representation containing t= hese links is used by GUI agent, in this case even "action-type" = is not necessary at all and agent can rely on user's choice. Agent only= needs to know that:
> > > > > >
> > > > > > 1. link is an action(and this question is exp= licitly answered)
> > > > > > 2. if user choose one agent needs just to der= eference indicated URI
> > > > > > 3. construct request
> > > > > > 4. send request to server
> > > > > > 5. show results to user
> > > > > >
> > > > > > All of these will remain true for any action = type.
> > > > > >
> > > > > > I'm not sure if i talked you down, but i = believe "action" relation type is useful and not because it is be= tter(or simpler) compared to rel=3D"edit" for example.
> > > > > >
> > > > > > 1. http://tool= s.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-00
> > > > > > 2. http://tool= s.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-01
> > > > > >
> > > > > > P.S.
> > > > > > I was talking about 01 version of spec. 00 is= a different story.
> > > > > >
> > > > > > Cheers,
> > > > > > ioseb
> > > > > > > mamund
> > > > > > > +1.859.757.1449 (tel:%2B1.859.757.1449) (t= el:%2B1.859.757.1449) (tel:%2B1.859.757.1449)
> > > > > > > skype: mca.amundsen > > > > > > > http://amundsen.com/blog/
> > > > > > > http://twitter.com/mamund
> > > > > > > https://github.com/mamund
> > > > > > > http://www.linkedin.com/in/mikeamundsen > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Aug= 27, 2013 at 3:40 PM, Ioseb Dzmanashvili <ioseb.dzmanashvili@gmail.com (mailto:ioseb.dzmanashvili@gmail.com) (mailto:<= a href=3D"mailto:ioseb.dzmanashvili@gmail.com">ioseb.dzmanashvili@gmail.com= ) (mailto:ioseb.dzmanas= hvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.com) (mailto:ioseb.dzmanashvili@gmail.com)> wrote= :
> > > > > > > > Hi Julian,
> > > > > > > >
> > > > > > > > Thanks for response!
> > > > > > > >
> > > > > > > > On Tuesday, August 27, 2013 at 2:15= PM, Julian Reschke wrote:
> > > > > > > >
> > > > > > > > > On 2013-08-27 11:03, Ioseb Dzm= anashvili wrote:
> > > > > > > > > > Hi All,
> > > > > > > > > >
> > > > > > > > > > I've updated the &quo= t;action" link relation type spec[1] based on initial feedback.
> > > > > > > > > >
> > > > > > > > > > As far as initial reactio= ns were very controversial and raised a lot of issues i tried to address al= l of them and entirely changed the spec.
> > > > > > > > > >
> > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > > > > > > > > When included in a respon= se, the "action" link relation indicates a
> > > > > > > > > > target resource that is r= esponsible for performing action which MAY:
> > > > > > > > > >
> > > > > > > > > > - Affect state of the con= text resource; or
> > > > > > > > > > - Initiate process.
> > > > > > > > > >
> > > > > > > > > > The "action" li= nk relation type can be used to indicate the
> > > > > > > > > > availability of actions s= upported by the target resource. Examples
> > > > > > > > > > of such actions include:<= br> > > > > > > > > > >
> > > > > > > > > > - Enable/Disable
> > > > > > > > > > - Publish/Unpublish
> > > > > > > > > > - Start/Stop
> > > > > > > > > >
> > > > > > > > > > The "action" li= nk relation type doesn't convey any semantics other
> > > > > > > > > > than that an indicated re= sources represent machine readable
> > > > > > > > > > description of a particul= ar action and representation SHOULD contain
> > > > > > > > > > all necessary details suc= h as: request method, action URI and other
> > > > > > > > > > related details to enable= agents to be able to construct requests
> > > > > > > > > > without relying on out-of= -band information.
> > > > > > > > > >
> > > > > > > > > > Exact type of action SHOU= LD be indicated through the "action-type"
> > > > > > > > > > link-extension value as p= er [RFC5988] and for maintaining shared
> > > > > > > > > > understanding of action t= ypes current specification introduces the
> > > > > > > > > > registry of actions with = initial values of widely accepted and well
> > > > > > > > > > understood action types.<= br> > > > > > > > > > >
> > > > > > > > > > For example, if a resourc= e represents a service, that same
> > > > > > > > > > representation may includ= e links to resources that represent actions
> > > > > > > > > > supported by the service:=
> > > > > > > > > >
> > > > > > > > > > Link: </restart-action= >; rel=3D"action"; action-type=3D"restart"
> > > > > > > > > > Link: </stop-action>= ;; rel=3D"action"; action-type=3D"stop"
> > > > > > > > > > ...
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > It seems that you are just add= ing an indirection mechanism. Why is that
> > > > > > > > > necessary?
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > With indirection mechanism i'm = trying to solve issues raised around initial version of the spec[1]. There = were several issues:
> > > > > > > >
> > > > > > > > 1. The "action" link rela= tion type doesn't have enough semantics and automated agents can not fo= llow such links if there are several actions included in a representation. = With the "action-type" link extension + registry of predefined ac= tion types agents can distinguish actions from each other.
> > > > > > > >
> > > > > > > > 2. Initial spec stated that if the = "action" link exists in representation, only thing agents should = do is to send empty POST request to the target in order to perform action. = This approach was considered as an anti pattern(RPCish and non RESTful). Wi= th having the "action-type" agents can:
> > > > > > > >
> > > > > > > > a) distinguish action links from ea= ch other;
> > > > > > > > b) if necessary dereference the tar= get to obtain instructions for constructing non empty POST/PUT requests; > > > > > > > > c) send properly constructed reques= t back to the target; and
> > > > > > > > d) it makes possible for servers to= dictate structure of the request according to there own needs.
> > > > > > > >
> > > > > > > > Main purpose of the "action&qu= ot; link relation type is to define semantics of particular class of links = - actions. This eliminates the need to redefine notion of "action"= ; for each link relation type which may be qualified as action link. The &q= uot;action-type" is just for naming actions and is particularly useful= for automated agents not necessarily for human interaction oriented agents= .
> > > > > > > >
> > > > > > > > Having action type registry is impo= rtant for maintaining shared understanding of particular action types. For = example "reset" or "publish" verbs do not need to be re= defined from application to application. I also believe that it is not effi= cient(or feasible) to register all possible actions as link relations.
> > > > > > > >
> > > > > > > > 1. h= ttp://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-00<= /a>
> > > > > > > > 2. h= ttp://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-01<= /a>
> > > > > > > > >
> > > > > > > > > Best regards, Julian
> > > > > > > > Cheers,
> > > > > > > > ioseb
> > > > > > > >
> > > > > > > > ___________________________________= ____________
> > > > > > > > link-relations mailing list
> > > > > > > > link-relations@ietf.org (mailto:link-relations@ietf.org) (mailto:link-relations@ietf.org) (mailto:link-relations@ietf.org) (mailto:link-relations@ietf.org) (mail= to:link-relations@ietf.org) = (mailto:link-relations@ietf.org<= /a>)
> > > > > > > > https://www.ietf.org/mailma= n/listinfo/link-relations
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>




--047d7bb03eb6b782fe04e50778ce-- From jan.algermissen@nordsc.com Wed Aug 28 13:27: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 AAA4511E819B; Wed, 28 Aug 2013 13:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IkFKlI5YQAq; Wed, 28 Aug 2013 13:27:28 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 9F61B11E8159; Wed, 28 Aug 2013 13:27:27 -0700 (PDT) Received: from [192.168.2.107] (p548FAC9C.dip0.t-ipconnect.de [84.143.172.156]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0MW4Sq-1VYW8Y3uFE-00X6NA; Wed, 28 Aug 2013 22:27:23 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jan Algermissen In-Reply-To: Date: Wed, 28 Aug 2013 22:27:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <05573AE3-70B4-4A03-AABA-AC51E8EBC60B@nordsc.com> References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <8410EE3EC8FB4ADA93F4209376AF8183@gmail.com> <30BCEBA7E91E4DDF8D20B3311D362B27@gmail.com> To: mike amundsen X-Mailer: Apple Mail (2.1508) X-Provags-ID: V02:K0:r/68N8fT8kTJjVskNq3WucdMpKE3fuFCLij+Lbb5AqN ypjFwy7M/JPGhl4favwCK4dR09OFEfolsQV4PxrPWX8OkfG/tk ErZ4Fw0QI47SfV3zbta9ij6s1RHvczRXh4BZVjNCJVVEjOH9Vy 60W5URk/MLyPJj5HUVJ4SA0zyXYmKBPbZ+D/iTh3VF69NXVM9m BUJqsF+q5Ib6FSrKMtn3YNW2CRICE+Cd/doyhaljzldXPBimRf wtn868Bef9UoBGRxFQdpt9ZW2bOjn9RLU3ySFuNJV8uEdTJmI8 OcIC2nVgXO5kgh1Ot4V6aNzlbAJk14KH3XarthlSAhS+WjuvaJ yRG0mEDN/j6exAY7uIGv1oqSV5CBOP0hA4O/cQWxYPqn/pjJdU 84/qI7gWRO0HQ== Cc: Julian Reschke , link-relations , IETF Apps Discuss Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 28 Aug 2013 20:27:33 -0000 On 28.08.2013, at 22:02, mike amundsen wrote: > 2) when crafting link rel values, i got good advice (I think it was = from JulianR?) to cast the definitions as "relations" not just "verbs" = or "nouns." for example: > "The link relation {value} identifies a target resource that = represents {a concept}." There are variations, but you'll get the idea. Yes. And do not let AtomPub's 'edit' fool you - it is just a bad choice. = 'Edit' should have been sth like 'source' because what edit identifies = is the one entry you need to direct requests to that intend to change = the entry - (as opposed to the member-entries that represent that = 'edit'-entry in individual collections. IOW, you do not need a 'delete' and an 'edit' entry, just a 'source' = entry and then you go there to PUT or DELETE. Jan From jan.algermissen@nordsc.com Wed Aug 28 13:49: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 19F1121F91BF; Wed, 28 Aug 2013 13:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.595 X-Spam-Level: * X-Spam-Status: No, score=1.595 tagged_above=-999 required=5 tests=[AWL=-2.356, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_32=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_92=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 QQbFk40XyT0l; Wed, 28 Aug 2013 13:49:41 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id D5EF821F8FF5; Wed, 28 Aug 2013 13:49:40 -0700 (PDT) Received: from [192.168.2.107] (p548FAC9C.dip0.t-ipconnect.de [84.143.172.156]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0MfIF8-1VPBis2POs-00Oot3; Wed, 28 Aug 2013 22:49:12 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jan Algermissen In-Reply-To: <30BCEBA7E91E4DDF8D20B3311D362B27@gmail.com> Date: Wed, 28 Aug 2013 22:49:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <8410EE3EC8FB4ADA93F4209376AF8183@gmail.com> <30BCEBA7E91E4DDF8D20B3311D362B27@gmail.com> To: Ioseb Dzmanashvili X-Mailer: Apple Mail (2.1508) X-Provags-ID: V02:K0:LK6tnblBS3p32RXIiWmrDXi5u13bK34mUKwJt4npbG+ 7unHaPN6ZeahlqD9wS7zWWq7Hr3gBc5ghS1amx4GUXyGdDoZM3 bkBzVVUmhD7yH7fTP8ZVbXzIoTiJ40BFeGc0sEVp31MnLyRbd6 qIK89kQt/00jmqws5Lh/WlXrnNmTWopMGKbf9YTh+/JNqgJ0gs Obi2dLPCUYphdIhp0+oKulgCloYpEgW/pv6EwCxo/H0D7RhIXp 0DgmjF48un+vvUQo5cmmRSQbYCiLsJRaxTtlK/QG/EREojG/RS JbwYYPXvYmFw03V/PVf0U/AnyUK60cRgV4bpJ3y0W+gR77QH3W b5vBP4GDTdhu7WlYLttq6TZstZfYHRtJN5D5DrH8w0yGL81YGo 0VgbAzWbLo0yA== Cc: Julian Reschke , IETF Apps Discuss , link-relations Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 28 Aug 2013 20:49:45 -0000 On 28.08.2013, at 21:38, Ioseb Dzmanashvili = wrote: >=20 > As a conclusion: >=20 > 1. Having the generic "action" relation is worthless, at list as of 00 = and 01 proposals. At least i need to find better way to make it = acceptable. Hmm, I recall trying to tell you that in 00 ? > 2. Action type registry complicates things(and i agree). > 3. One possible way is to maintain separate registry(out of IETF) = which is not feasible for me. > 4. Most realistic is to register top level action link rels and i've = several such relations: >=20 > - start: start service or process > - stop: stop service or process > - restart: restart service or process > - suspend: suspend service or process > - reset: reset service or process to its initial state I'd say this is a domain (sending controll messages to control some = 'thing') where REST isn't a particulary good fit. These operations = expose a lot of implementation details - something that REST aims to = hide. Or, IOW, using REST to design a control interface will not make = you and the RESTafarians happy at the same time :-) Suggestions: - Build an unRESTful HTTP interface to avoid now uncool RPC solutions = :-) You know the story .... POST /jobs/start (Quite some things out there have such APIs, e.g. App servers, app = engines,..) - Hide the implementation details and think more in terms of what the = client wants (I mean, who cares whether there is a job and that that can = be suspended? Why would a service let a client start/stop/suspend = anything it controls itself? IOW, talk about your domain, not the = implementation - Use a sort-of-restful solution by changing state of a status resource = : PUT /jobs/67/mode - or create a resource that the service provides for clients to change = it's own internals vi an indirection. Much like you can edit a crontab, = but not send a command to cron to suspend a job POST /suspension-schedules .... nice candidate to re-use iCalender, BTW. >=20 > - publish: change state of the resource to published > - unpublish: change state of the resource to unpublished > - archive: change state of the resource to archived > - unarchive: change state of the resource to unarchived >=20 > - enable: change state of the resource to enabled > - disable: change state of the resource to disabled >=20 Which are all resource-state changes, too as you write yourself :-) = Also, maybe these are not states but memberships in collection (e.g. = move from draft to published queue/collection). > These are actions i used frequently in various applications. If it is an action, it is an implementation detail :-) > Do you think it is reasonable to register all of these as link = relations? >=20 Erm, no .... but you know that already ;-) > Folks? What do you think? >=20 YAGNI... Jan > Cheers, > ioseb >=20 >> . =20 >>=20 >> Cheers. >>=20 >>=20 >> 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/mikeamundsen =20 >>=20 >> On Wed, Aug 28, 2013 at 12:41 PM, Ioseb Dzmanashvili = = wrote: >>> Mike, >>>=20 >>> On Wednesday, August 28, 2013 at 6:33 PM, mike amundsen wrote: >>>> Ioseb: >>>>=20 >>>> now that i understand your aim... >>>>=20 >>>> it seems the first item (support a pattern...) is the important one = and the other two are just means to that end. >>> Actually as i see it #1 and #2 are of same importance. >>>=20 >>>=20 >>>> so why is this a good approach? >>> #1 and #2 still hold. As i already said #3 makes sense only for m2m = scenarios and for GUI clients just knowing that a link is an action and = how to treat such action links is enough. >>>=20 >>> What i'm trying to achieve with my proposal is to generalise meaning = of action and make it consistent across different applications. = Unfortunately i do not see(or know, or was not able to find) better = approach yet but it is generic enough to solve whole class of problems = at least on GUI level + partially for m2m cases with "action-type" = attribute even if we throw action type registry idea away. If we = simplify definition of the "action" relation type and say: >>>=20 >>> 1. here is the "action" link >>> 2. it points to a resource which describes the action >>> 3. to perform an action fetch it construct request and send it back = to server. >>> 4. if you want to know what this particular action means: >>> 4.1. look inside the "action-type" attribute if it presents; or >>> 4.2. fetch the document and look inside it. >>>=20 >>> Is not it sufficient enough to cover whole class of problems in a = consistent way which are clearly actions and not just related resources? >>>=20 >>> So here is my question: why is it bad? >>>=20 >>>> 1) why use the "action" rel PLUS a param ("start")? why not just = use the param ("start") as the rel? >>> For several reasons: >>>=20 >>> 1. there is no "start" relation yet. >>> 2. it doesn't have explicit sign that it is an action. >>> 3. there are much more actions which are not registered and also = there is no guarantee that each newly registered relation(which can be = qualified as action) will state that it is an action in a consistent = way. >>> 4. the pattern as you noticed is still important(IMHO) >>>=20 >>>> 2) why not use two values for the rel as in ? >>>=20 >>> It was suggested in the initial proposal though approach has = drawbacks. if i use more rels? how = to distinguish "foo", "bar" and "baz" from each other? does it mean that = my action now has triple meaning? >>>=20 >>>> 3) why not use (as mike kelly suggests) an extension URI for the = rel as in >>>>=20 >>>> 4) why not use a unique element attribute/property such as ? >>>=20 >>> is it different from "action-type" attribute? or maybe problem is in = a registry of action types? >>>=20 >>>> 5) why not use a unique document element/property such as or {"action": {"rel":"start", = "href":"..."}}? >>> Well, in custom media types i can do anything, though it doesn't = make sense outside of particular format or domain. Otherwise it is ok = and i use similar approach in practice. >>>=20 >>> Cheers, >>> ioseb >>>=20 >>>>=20 >>>> mamund >>>> +1.859.757.1449 (tel:%2B1.859.757.1449) >>>> skype: mca.amundsen >>>> http://amundsen.com/blog/ >>>> http://twitter.com/mamund >>>> https://github.com/mamund >>>> http://www.linkedin.com/in/mikeamundsen >>>>=20 >>>> On Wed, Aug 28, 2013 at 3:35 AM, Ioseb Dzmanashvili = wrote: >>>>> Mike, >>>>>=20 >>>>> On Wednesday, August 28, 2013 at 5:26 AM, mike amundsen wrote: >>>>>=20 >>>>>> OK, from your response i get the following: >>>>>>=20 >>>>>> 1) you want to support a pattern where machine-readable state = transition instructions appear at the end of some URL. >>>>>> 2) you want to indicate those instructions are available by = marking the URL w/ the string literal "action" (via rel in your = illustrations) >>>>>> 3) you want to indicate the reason for using these instructions = w/ an "action-type" string (via a link-rel param in your illustrations) >>>>>>=20 >>>>>> that's it. nothing else. >>>>>>=20 >>>>>> do i have this correct? >>>>>=20 >>>>> Exactly! That's it and nothing else. >>>>>=20 >>>>> Cheers, >>>>> ioseb >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> mamund >>>>>> +1.859.757.1449 (tel:%2B1.859.757.1449) (tel:%2B1.859.757.1449) >>>>>> skype: mca.amundsen >>>>>> http://amundsen.com/blog/ >>>>>> http://twitter.com/mamund >>>>>> https://github.com/mamund >>>>>> http://www.linkedin.com/in/mikeamundsen >>>>>>=20 >>>>>> On Tue, Aug 27, 2013 at 7:51 PM, Ioseb Dzmanashvili = wrote: >>>>>>> Hi Mike, >>>>>>>=20 >>>>>>> Thanks for the question! >>>>>>>=20 >>>>>>> On Tuesday, August 27, 2013 at 11:57 PM, mike amundsen wrote: >>>>>>>=20 >>>>>>>> Ioseb: >>>>>>>>=20 >>>>>>>> it is not clear to me why: >>>>>>>> is preferable to: >>>>>>>>=20 >>>>>>>> talk me down ;) >>>>>>> let me try ;) >>>>>>>=20 >>>>>>> Question is not about why: Link: <=85>; rel=3D"action"; = action-type=3D"edit" is preferable to: Link: <=85>; rel=3D"edit". >>>>>>>=20 >>>>>>> Of course i'd choose rel=3D"run-forest-run" if there is a = registered link relation type, but: >>>>>>>=20 >>>>>>> 1. The "action" link relation is generic enough, has well = understood meaning and is useful on its own especially for human = oriented agents. >>>>>>> 2. The "action-type" optional attribute may be used for = specifying exact meaning of actions and this makes action links more = useful for m2m scenarios. >>>>>>>=20 >>>>>>> Now consider this link: >>>>>>>=20 >>>>>>> Link: ; rel=3D"action"; action-type=3D"suspend"; = title=3D"Suspend" >>>>>>>=20 >>>>>>> What it says? >>>>>>>=20 >>>>>>> 1. it is an action >>>>>>> 2. target resource represents description of the action which = contains: request method, submit URI, definition of action, other = details etc >>>>>>> 3. agent can look inside "action-type" to determine whether it = needs this action type or not >>>>>>> 4. agent can dereference it, construct request and send it to = server >>>>>>>=20 >>>>>>>=20 >>>>>>> now if we add more actions: >>>>>>>=20 >>>>>>> Link: ; rel=3D"action"; action-type=3D"suspend"; = title=3D"Suspend" >>>>>>> Link: ; rel=3D"action"; action-type=3D"restart"; = title=3D"Restart" >>>>>>>=20 >>>>>>> Link: ; rel=3D"action"; action-type=3D"stop"; = title=3D"Stop" >>>>>>>=20 >>>>>>>=20 >>>>>>> #1, #2, #3 and #4 will be true for all of them without = exceptions. >>>>>>>=20 >>>>>>> Now consider that representation containing these links is used = by GUI agent, in this case even "action-type" is not necessary at all = and agent can rely on user's choice. Agent only needs to know that: >>>>>>>=20 >>>>>>> 1. link is an action(and this question is explicitly answered) >>>>>>> 2. if user choose one agent needs just to dereference indicated = URI >>>>>>> 3. construct request >>>>>>> 4. send request to server >>>>>>> 5. show results to user >>>>>>>=20 >>>>>>> All of these will remain true for any action type. >>>>>>>=20 >>>>>>> I'm not sure if i talked you down, but i believe "action" = relation type is useful and not because it is better(or simpler) = compared to rel=3D"edit" for example. >>>>>>>=20 >>>>>>> 1. = http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-0= 0 >>>>>>> 2. = http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-0= 1 >>>>>>>=20 >>>>>>> P.S. >>>>>>> I was talking about 01 version of spec. 00 is a different story. >>>>>>>=20 >>>>>>> Cheers, >>>>>>> ioseb >>>>>>>> mamund >>>>>>>> +1.859.757.1449 (tel:%2B1.859.757.1449) (tel:%2B1.859.757.1449) = (tel:%2B1.859.757.1449) >>>>>>>> skype: mca.amundsen >>>>>>>> http://amundsen.com/blog/ >>>>>>>> http://twitter.com/mamund >>>>>>>> https://github.com/mamund >>>>>>>> http://www.linkedin.com/in/mikeamundsen >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Tue, Aug 27, 2013 at 3:40 PM, Ioseb Dzmanashvili = wrote: >>>>>>>>> Hi Julian, >>>>>>>>>=20 >>>>>>>>> Thanks for response! >>>>>>>>>=20 >>>>>>>>> On Tuesday, August 27, 2013 at 2:15 PM, Julian Reschke wrote: >>>>>>>>>=20 >>>>>>>>>> On 2013-08-27 11:03, Ioseb Dzmanashvili wrote: >>>>>>>>>>> Hi All, >>>>>>>>>>>=20 >>>>>>>>>>> I've updated the "action" link relation type spec[1] based = on initial feedback. >>>>>>>>>>>=20 >>>>>>>>>>> As far as initial reactions were very controversial and = raised a lot of issues i tried to address all of them and entirely = changed the spec. >>>>>>>>>>>=20 >>>>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>>>>>>>>> When included in a response, the "action" link relation = indicates a >>>>>>>>>>> target resource that is responsible for performing action = which MAY: >>>>>>>>>>>=20 >>>>>>>>>>> - Affect state of the context resource; or >>>>>>>>>>> - Initiate process. >>>>>>>>>>>=20 >>>>>>>>>>> The "action" link relation type can be used to indicate the >>>>>>>>>>> availability of actions supported by the target resource. = Examples >>>>>>>>>>> of such actions include: >>>>>>>>>>>=20 >>>>>>>>>>> - Enable/Disable >>>>>>>>>>> - Publish/Unpublish >>>>>>>>>>> - Start/Stop >>>>>>>>>>>=20 >>>>>>>>>>> The "action" link relation type doesn't convey any semantics = other >>>>>>>>>>> than that an indicated resources represent machine readable >>>>>>>>>>> description of a particular action and representation SHOULD = contain >>>>>>>>>>> all necessary details such as: request method, action URI = and other >>>>>>>>>>> related details to enable agents to be able to construct = requests >>>>>>>>>>> without relying on out-of-band information. >>>>>>>>>>>=20 >>>>>>>>>>> Exact type of action SHOULD be indicated through the = "action-type" >>>>>>>>>>> link-extension value as per [RFC5988] and for maintaining = shared >>>>>>>>>>> understanding of action types current specification = introduces the >>>>>>>>>>> registry of actions with initial values of widely accepted = and well >>>>>>>>>>> understood action types. >>>>>>>>>>>=20 >>>>>>>>>>> For example, if a resource represents a service, that same >>>>>>>>>>> representation may include links to resources that represent = actions >>>>>>>>>>> supported by the service: >>>>>>>>>>>=20 >>>>>>>>>>> Link: ; rel=3D"action"; = action-type=3D"restart" >>>>>>>>>>> Link: ; rel=3D"action"; action-type=3D"stop" >>>>>>>>>>> ... >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> It seems that you are just adding an indirection mechanism. = Why is that >>>>>>>>>> necessary? >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> With indirection mechanism i'm trying to solve issues raised = around initial version of the spec[1]. There were several issues: >>>>>>>>>=20 >>>>>>>>> 1. The "action" link relation type doesn't have enough = semantics and automated agents can not follow such links if there are = several actions included in a representation. With the "action-type" = link extension + registry of predefined action types agents can = distinguish actions from each other. >>>>>>>>>=20 >>>>>>>>> 2. Initial spec stated that if the "action" link exists in = representation, only thing agents should do is to send empty POST = request to the target in order to perform action. This approach was = considered as an anti pattern(RPCish and non RESTful). With having the = "action-type" agents can: >>>>>>>>>=20 >>>>>>>>> a) distinguish action links from each other; >>>>>>>>> b) if necessary dereference the target to obtain instructions = for constructing non empty POST/PUT requests; >>>>>>>>> c) send properly constructed request back to the target; and >>>>>>>>> d) it makes possible for servers to dictate structure of the = request according to there own needs. >>>>>>>>>=20 >>>>>>>>> Main purpose of the "action" link relation type is to define = semantics of particular class of links - actions. This eliminates the = need to redefine notion of "action" for each link relation type which = may be qualified as action link. The "action-type" is just for naming = actions and is particularly useful for automated agents not necessarily = for human interaction oriented agents. >>>>>>>>>=20 >>>>>>>>> Having action type registry is important for maintaining = shared understanding of particular action types. For example "reset" or = "publish" verbs do not need to be redefined from application to = application. I also believe that it is not efficient(or feasible) to = register all possible actions as link relations. >>>>>>>>>=20 >>>>>>>>> 1. = http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-0= 0 >>>>>>>>> 2. = http://tools.ietf.org/html/draft-ioseb-dzmanashvili-action-link-relation-0= 1 >>>>>>>>>>=20 >>>>>>>>>> Best regards, Julian >>>>>>>>> Cheers, >>>>>>>>> ioseb >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> link-relations mailing list >>>>>>>>> link-relations@ietf.org (mailto:link-relations@ietf.org) = (mailto:link-relations@ietf.org) (mailto:link-relations@ietf.org) = (mailto:link-relations@ietf.org) (mailto:link-relations@ietf.org) = (mailto:link-relations@ietf.org) >>>>>>>>> https://www.ietf.org/mailman/listinfo/link-relations >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From alexey.melnikov@isode.com Wed Aug 28 13:56: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 1395921F9C0A; Wed, 28 Aug 2013 13:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.829 X-Spam-Level: X-Spam-Status: No, score=-103.829 tagged_above=-999 required=5 tests=[AWL=-1.230, 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 XiAPq4F0E4DB; Wed, 28 Aug 2013 13:56:11 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 6C71F21F9B26; Wed, 28 Aug 2013 13:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1377723370; d=isode.com; s=selector; i=@isode.com; bh=1eXfv6Qjt8SN8/hEpiBSxSrPZwnJFjC2W2getU0ca9A=; 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=ciQsXVQCjXGh8m/ZjXR8wltTweGS8aSxpILYZUNagkf2Ie+MikV9nV3f+7LOQbIdsCUDyz 6MhUyvUjjmUK/HEANDBWSDhEiUQ31ETvNyeG8KGRV1K7SpYjCBm4y/JOe0+/oaobqAGSrG w67f8eq8FS6D2/Z0MIUBNGq3ipMZI9Q=; Received: from [192.168.0.4] (cpc5-nmal20-2-0-cust24.19-2.cable.virginmedia.com [92.234.84.25]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 28 Aug 2013 21:56:09 +0100 Message-ID: <521E63E7.9010002@isode.com> Date: Wed, 28 Aug 2013 21:56:07 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: draft-ietf-repute-email-identifiers.all@tools.ietf.org, apps-discuss@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IESG Subject: [apps-discuss] AppsDir review of draft-ietf-repute-email-identifiers-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, 28 Aug 2013 20:56:17 -0000 Hello all, 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-repute-email-identifiers-08 Title: A Reputation Response Set for Email Identifiers Reviewer: Alexey Melnikov Review Date: 28 August 2013 Summary: The document is ready for publication. Major issues: none Minor Issues: none Nits: none From ioseb.dzmanashvili@gmail.com Wed Aug 28 14:04: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 69FCE21F99D0; Wed, 28 Aug 2013 14:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=1.046, 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 H6hM4YKGYr48; Wed, 28 Aug 2013 14:04:29 -0700 (PDT) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAA521F99A2; Wed, 28 Aug 2013 14:04:28 -0700 (PDT) Received: by mail-ee0-f51.google.com with SMTP id c1so3189245eek.38 for ; Wed, 28 Aug 2013 14:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:content-transfer-encoding :content-disposition; bh=VRGU9nYPL/7NMlKsjpMG0/nYEt+FX9N6E8iwlcQ2f/k=; b=OD3MNe+BXM1MFb1QyNFPuQW9943SJjAyM9moQZR2/STd92QQYhO6yzyuE/RyrraJZH zX8POHxwz8DavBgxcdTuhVaSVVqxfqvXiSymQQTlLlnyfvH8WFlpQvLrdCglLKvzrE8b 5odBdkUrcrpjfssHk7Y2ykpI6AuKs2ZHFYXOIV4wRFGAQ9w85CiOIAdueELRlVO/UgXZ RGHg/9omidsm+dlA7OoQdogU1fDN7xNqMLUzP9Lk+0U8rXq+Iu5z9eSWnQxpJLQWGc5j HtD1Aa7Y2hGM9UpGQaIJy0gskLZ4KHHAJApt6mnlhZIJJJ9TicnPpjtwwJMWJVxqKIX3 PD1w== X-Received: by 10.14.205.9 with SMTP id i9mr5007403eeo.72.1377723867725; Wed, 28 Aug 2013 14:04:27 -0700 (PDT) Received: from [192.168.1.6] ([176.73.174.236]) by mx.google.com with ESMTPSA id r48sm40590001eev.14.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 28 Aug 2013 14:04:27 -0700 (PDT) Date: Thu, 29 Aug 2013 01:04:23 +0400 From: Ioseb Dzmanashvili To: mike amundsen Message-ID: <5CAC7F65268B47BFB1CF37E4C1393382@gmail.com> In-Reply-To: References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <8410EE3EC8FB4ADA93F4209376AF8183@gmail.com> <30BCEBA7E91E4DDF8D20B3311D362B27@gmail.com> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Julian Reschke , IETF Apps Discuss , link-relations Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 28 Aug 2013 21:04:29 -0000 Thank you Mike! On Thursday, August 29, 2013 at 12:02 AM, mike amundsen wrote: > 2) when crafting link rel values, i got good advice (I think it was from JulianR?) to cast the definitions as "relations" not just "verbs" or "nouns." for example: > "The link relation {value} identifies a target resource that represents {a concept}." There are variations, but you'll get the idea. > That is why i didn't start from particular actions and tried to create concept of "action". If i understand whole thing correctly "action" is a concept, though in this particular case it is too generic and has minimal value as far as it doesn't say anything about particular action and if representation includes several action links it is impossible to distinguish one from another. Cheers, ioseb From ioseb.dzmanashvili@gmail.com Wed Aug 28 14: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 9C27321F9F2D; Wed, 28 Aug 2013 14:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.842 X-Spam-Level: X-Spam-Status: No, score=0.842 tagged_above=-999 required=5 tests=[AWL=-1.559, BAYES_50=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_83=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 G+J3F1G7DZc3; Wed, 28 Aug 2013 14:54:40 -0700 (PDT) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id F393B21F9223; Wed, 28 Aug 2013 14:54:34 -0700 (PDT) Received: by mail-ee0-f52.google.com with SMTP id c41so3211809eek.39 for ; Wed, 28 Aug 2013 14:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:content-transfer-encoding :content-disposition; bh=a7a1vNpDFbbKKm7RWM0GHIr7TE31S6RuZA87DcF0yJE=; b=UYWmhJBKpg6I+voZ7CaH/Cg7AsRdveqmt2fsHjlLwB+3LbaJ54Q1hc5WLO6FQ3kiO7 5yK6FaQhrR/fa0uJiXdhVGNPa890mdMNxCmtokwL0GCv0rZHLPL5CW9upEQkzHifv/Ka DWvGG0pDAX0KQjOxek4Qz4z8TbX4VzM8Omx+NBpWe2Disn5QmZvdVbfFvNO/IzaDIgZE Ifgl4iNbJhPstEjQj/xl/2Wk5+alLcXqa+k3l6Fga4xhM7aOXCb0NdVcwXnvryCpB2NC lx1XI8OSwI9ezz0bQHRhekN4a5yUEXRyhGwfNDArfQP2DjBjw9AtF8R+qs6184nWpDOR 7wjg== X-Received: by 10.14.176.8 with SMTP id a8mr80143eem.12.1377726874099; Wed, 28 Aug 2013 14:54:34 -0700 (PDT) Received: from [192.168.1.6] ([176.73.174.236]) by mx.google.com with ESMTPSA id f49sm40875868eec.7.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 28 Aug 2013 14:54:33 -0700 (PDT) Date: Thu, 29 Aug 2013 01:54:28 +0400 From: Ioseb Dzmanashvili To: Jan Algermissen Message-ID: <7F642727A2D74D2A9FB328907D88EC79@gmail.com> In-Reply-To: References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <8410EE3EC8FB4ADA93F4209376AF8183@gmail.com> <30BCEBA7E91E4DDF8D20B3311D362B27@gmail.com> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Julian Reschke , IETF Apps Discuss , link-relations Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 28 Aug 2013 21:55:06 -0000 Hi Jan, Thanks for feedback! On Thursday, August 29, 2013 at 12:49 AM, Jan Algermissen wrote: > > On 28.08.2013, at 21:38, Ioseb Dzmanashvili wrote: > > > > > As a conclusion: > > > > 1. Having the generic "action" relation is worthless, at list as of 00 and 01 proposals. At least i need to find better way to make it acceptable. > > Hmm, I recall trying to tell you that in 00 ? > > > 2. Action type registry complicates things(and i agree). > > 3. One possible way is to maintain separate registry(out of IETF) which is not feasible for me. > > 4. Most realistic is to register top level action link rels and i've several such relations: > > > > - start: start service or process > > - stop: stop service or process > > - restart: restart service or process > > - suspend: suspend service or process > > - reset: reset service or process to its initial state > > > > I'd say this is a domain (sending controll messages to control some 'thing') where REST isn't a particulary good fit. These operations expose a lot of implementation details - something that REST aims to hide. Or, IOW, using REST to design a control interface will not make you and the RESTafarians happy at the same time :-) > > Suggestions: > > - Build an unRESTful HTTP interface to avoid now uncool RPC solutions :-) You know the story .... POST /jobs/start > (Quite some things out there have such APIs, e.g. App servers, app engines,..) > > - Hide the implementation details and think more in terms of what the client wants (I mean, who cares whether there is a job and that that can be suspended? Why would a service let a client start/stop/suspend anything it controls itself? IOW, talk about your domain, not the implementation > > - Use a sort-of-restful solution by changing state of a status resource : > > PUT /jobs/67/mode > > Suppose i've application for managing services and i expose supported actions in following way(i use HTML for this example): - - ... -
-
- - -
-
- - -
-
- ... - Now lets say that i want to move these forms out of the service representation and make them separate resources. Now we need to advertise these resources to let agents know that a) such resources exist; and b) tell them why do they need to follow these links. One example could be: - - - - - - ... - After activating one of the links: - agent can fetch(HTTP GET) action description - construct HTTP POST request based on action description(form in this case or whatever was used for describing action) - send that request back to the server If we define used link relations as: - The link relation "restart-action" identifies a target resource that represents an *action* that can be used to restart running service or process. - The link relation "suspend-action" identifies a target resource that represents an *action* that can be used to suspend running service or process. Would it be RESTful or not? Where implementation details are leaked? How in this case "restart" and "suspend" are different from for example "update" and "delete"? or how "suspend-action" and "restart-action" are different from for example "edit-form" and "create-form"? What is the difference? Cheers, ioseb > > - or create a resource that the service provides for clients to change it's own internals vi an indirection. Much like you can edit a crontab, but not send a command to cron to suspend a job > > POST /suspension-schedules > > > > > > > .... nice candidate to re-use iCalender, BTW. > > > > > - publish: change state of the resource to published > > - unpublish: change state of the resource to unpublished > > - archive: change state of the resource to archived > > - unarchive: change state of the resource to unarchived > > > > > > - enable: change state of the resource to enabled > > - disable: change state of the resource to disabled > > > > > > Which are all resource-state changes, too as you write yourself :-) Also, maybe these are not states but memberships in collection (e.g. move from draft to published queue/collection). > > > > These are actions i used frequently in various applications. > > If it is an action, it is an implementation detail :-) > > > Do you think it is reasonable to register all of these as link relations? > > Erm, no .... but you know that already ;-) > > > Folks? What do you think? > > YAGNI... > > Jan From jonathan.robie@emc.com Wed Aug 28 12:29: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 5FDFB21E8098 for ; Wed, 28 Aug 2013 12:29:11 -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 JKmOISZSxfkT for ; Wed, 28 Aug 2013 12:29:07 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1248421E8096 for ; Wed, 28 Aug 2013 12:29:06 -0700 (PDT) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r7SJSmeX025128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 28 Aug 2013 15:28:48 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com r7SJSmeX025128 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1377718128; bh=dbEOqskd8q058jqwzYexTO0cQLI=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=o75G8viFuBaez7GU/tL0o90c/vyXHVFtlXWm6gLu40Dgn0FF/kfhU1sVAYL3cMr7y opxyssApe10f4qRUP9WOLaOJlYuBiqTgLZ1NKOKPyAwC2SrIIStFG5Ro5QSe5J2cAO LyTvAAXFMcPBet+9ECc/HvCD82cjtat2llBM97Ow= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com r7SJSmeX025128 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd52.lss.emc.com (RSA Interceptor) for ; Wed, 28 Aug 2013 15:28:37 -0400 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r7SJSau7015565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 28 Aug 2013 15:28:36 -0400 Received: from MXHUB103.corp.emc.com (10.253.50.16) by mxhub21.corp.emc.com (128.222.70.133) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 28 Aug 2013 15:28:36 -0400 Received: from MX104CL01.corp.emc.com ([169.254.7.212]) by MXHUB103.corp.emc.com ([::1]) with mapi id 14.02.0342.003; Wed, 28 Aug 2013 15:28:35 -0400 From: "Robie, Jonathan" To: "apps-discuss@ietf.org" Thread-Topic: Relative URIs in Home Documents for HTTP APIs Thread-Index: Ac6kJMNRi0uR+N57TGqbSbi7z0dJgQ== Date: Wed, 28 Aug 2013 19:28:35 +0000 Message-ID: <41539B7FA57A2A4A9FB00AB9F328823339C7291D@MX104CL01.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.41.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-EMM-GWVC: 1 X-EMM-McAfeeVC: 1 X-RSA-Classifications: public X-Mailman-Approved-At: Wed, 28 Aug 2013 15:15:00 -0700 Subject: [apps-discuss] Relative URIs in Home Documents for HTTP APIs 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, 28 Aug 2013 19:29:57 -0000 http://tools.ietf.org/html/draft-nottingham-json-home-03 says: In both forms, the links that "href" and "href-template" refer to are URI-references [RFC3986] whose base URI is that of the JSON Home Document itself. Is this the best approach? In general, I prefer to avoid making clients mess with URIs. XML and HTML b= oth support base URIs, but JSON does not, so allowing relative URIs here re= quires the client to intervene to make a URI resolvable. If a server does use relative URIs, why insist that the location of the JSO= N Home document is the same as the base for all relative URIs? If relative= URIs are allowed here, more flexibility might be desirable. Jonathan From mnot@mnot.net Wed Aug 28 21:03: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 50E2C11E80E6 for ; Wed, 28 Aug 2013 21:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.749 X-Spam-Level: X-Spam-Status: No, score=-104.749 tagged_above=-999 required=5 tests=[AWL=-2.150, 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 5pmWeSuBYcNC for ; Wed, 28 Aug 2013 21:03:26 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 58C8811E80E4 for ; Wed, 28 Aug 2013 21:03:23 -0700 (PDT) Received: from [192.168.1.64] (unknown [118.209.225.40]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 77308509B6; Thu, 29 Aug 2013 00:03:21 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Mark Nottingham Date: Thu, 29 Aug 2013 14:03:17 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <151E2428-3EC4-4F1E-AE6E-3747B06BB62A@mnot.net> References: <20130829040129.13080.29347.idtracker@ietfa.amsl.com> To: Apps Discuss X-Mailer: Apple Mail (2.1508) Cc: Barry Leiba Subject: [apps-discuss] Standardising Structure in URIs 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, 29 Aug 2013 04:03:31 -0000 I started this draft during the Berlin meeting, and since have had a lot = of positive feedback. Would the APPSAWG be interested in taking it on as a WG document? Regards, Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-nottingham-uri-get-off-my-lawn-02.txt > Date: 29 August 2013 2:01:29 PM AEST > To: Mark Nottingham >=20 >=20 > A new version of I-D, draft-nottingham-uri-get-off-my-lawn-02.txt > has been successfully submitted by Mark Nottingham and posted to the > IETF repository. >=20 > Filename: draft-nottingham-uri-get-off-my-lawn > Revision: 02 > Title: Standardising Structure in URIs > Creation date: 2013-08-29 > Group: Individual Submission > Number of pages: 8 > URL: = http://www.ietf.org/internet-drafts/draft-nottingham-uri-get-off-my-lawn-0= 2.txt > Status: = http://datatracker.ietf.org/doc/draft-nottingham-uri-get-off-my-lawn > Htmlized: = http://tools.ietf.org/html/draft-nottingham-uri-get-off-my-lawn-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-nottingham-uri-get-off-my-lawn-02= >=20 > Abstract: > Sometimes, it is attractive to add features to protocols or > applications by specifying a particular structure for URIs (or parts > thereof). This document cautions against this practice in standards > (sometimes called "URI Squatting"). >=20 >=20 >=20 >=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. >=20 > The IETF Secretariat >=20 -- Mark Nottingham http://www.mnot.net/ From stpeter@stpeter.im Wed Aug 28 21:06: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 018B321E8064 for ; Wed, 28 Aug 2013 21:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.457 X-Spam-Level: X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 3C2KTIU7yKG9 for ; Wed, 28 Aug 2013 21:06:10 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4304111E80E4 for ; Wed, 28 Aug 2013 21:06:09 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D7C284156F; Wed, 28 Aug 2013 22:09:53 -0600 (MDT) Message-ID: <521EC8AF.5000307@stpeter.im> Date: Wed, 28 Aug 2013 22:06:07 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mark Nottingham References: <20130829040129.13080.29347.idtracker@ietfa.amsl.com> <151E2428-3EC4-4F1E-AE6E-3747B06BB62A@mnot.net> In-Reply-To: <151E2428-3EC4-4F1E-AE6E-3747B06BB62A@mnot.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Apps Discuss , Barry Leiba Subject: Re: [apps-discuss] Standardising Structure in URIs 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, 29 Aug 2013 04:06:19 -0000 On 8/28/13 10:03 PM, Mark Nottingham wrote: > I started this draft during the Berlin meeting, and since have had a lot of positive feedback. > > Would the APPSAWG be interested in taking it on as a WG document? I'd be in favor; this is helpful. Peter From sm@elandsys.com Thu Aug 29 01:19: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 E502021E8098; Thu, 29 Aug 2013 01:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 cVYs9jUm7zNf; Thu, 29 Aug 2013 01:19:30 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FFE21E8082; Thu, 29 Aug 2013 01:19:26 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.80]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7T8J5eO017219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Aug 2013 01:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377764361; bh=4JAA6N3cHUJ+HmDmGKp16PDKdpml9EDghdfkIKvnH1E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=jDP820dahxeH4zGTnoel2KD3OWbAUU5xGp5Tr/uWSnRr7+FkYtix8/BiCdO4NkSZu e8q7ds/K4OGU7AVZc1EFx8Ham8Bz+GblkejZmTZZxj3hCbaIFwYeNNqlH99Cvt+l1+ 9Chp9gJyAdfMjTnt+VMpTiy8LbF5kpNbANdg8QHo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377764361; i=@elandsys.com; bh=4JAA6N3cHUJ+HmDmGKp16PDKdpml9EDghdfkIKvnH1E=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ySnP2wnz/eUrkS8/R1qvAe88JItE5YZP0EVfwhaKl8mdW4sBgNzHuPUoGDtYNAd84 AoBosmEFXxQcFFHMSYeqkGYjfwifiFlGCeKLsdhtwwQ885lJA9kFcixOrssVjcEdOj xhTh5fpuxGhl2D8eBCshbig2eWmm1M5zhUjJ12ZU= Message-Id: <6.2.5.6.2.20130829005602.0ba8c530@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 29 Aug 2013 01:03:54 -0700 To: Eliot Lear , apps-discuss@ietf.org From: S Moonesamy In-Reply-To: <521E6529.1040106@dcrocker.net> References: <20130827012600.83309.qmail@joyce.lan> <1552915.aJAV4gMSz7@scott-latitude-e6320> <521E1E40.1060505@isdg.net> <3619221.jr7HmlbTDF@scott-latitude-e6320> <521E6529.1040106@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, iesg@ietf.org Subject: Re: [apps-discuss] [spfbis] Applications Directorate Review: ABNF 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, 29 Aug 2013 08:19:33 -0000 Hi Eliot, The following is to address the rest of the=20 review. There was one major issue which I did=20 not comment about in my previous message. At 08:13 25-08-2013, Eliot Lear wrote: >Major issues: > >1. Deprecation of SPF record not properly=20 >justified in text and in the wrong place >Deprecation of the SPF record is given short=20 >shrift in Section 13.1 which is the IANA=20 >considerations section.=C2 A persistent reader=20 >would not understand why the record was in fact=20 >deprecated. Here's what is 13.1 (there are a few=20 >words about 6686 in 3.1 as well, but nobody=20 >would care if this was simply a matter of low implementation/deployment). > >> Studies have shown that RRTYPE 99 has not seen any substantial use, >> and in fact its existence and mechanism defined in [RFC4408] has led >> to some interoperability issues. > >First, this text should be moved out of the IANA=20 >considerations sections and forward to Section=20 >3.1. Second it should explain what those=20 >interoperability issues are or have a normative=20 >(and retrievable) reference. At the very least,=20 >the winning argument(s) should be elucidated,=20 >and not just for posterity: the claim is that=20 >there is an interoperability problem. If so,=20 >then might administrators want to know that? > >The matter of handling garbage in garbage out is=20 >not well enough specified in Section 3. I would=20 >go considerably further and state that (a)=20 >records that do not begin with "v=3Dspf1" MUST NOT=20 >be processed further, and (b) that any record=20 >that does not conform to the stated grammar MUST=20 >be ignored. Also, did the working group=20 >consider a DKIM-like solution? They all but=20 >establish an _spf label in this document (I'll come to that in a moment). > >There is a general issue about when to deprecate=20 >an RR and the ability to add new RRs into the=20 >DNS. That issue has to be addressed in the=20 >longer term, no matter what the IESG and=20 >community decide here. Furthermore, to be=20 >clear, please do not read into the above=20 >comments an opinion about deprecation of the=20 >record itself, which I am withholding until=20 >there is clear text about the interoperability issues that are mentioned. The SPFBIS WG is not deprecating type=20 SPF. RRTYPE 99 has been removed from the (draft)=20 protocol. The working group discussion was=20 something very like MUST NOT publish, MUST NOT=20 query ... The author thinks it might be=20 reasonable to be more verbose in Appendix C, which currently says: o Use of DNS RR type SPF (99) has been removed from the protocol, see [RFC6686] for background. Personally, he thinks it's accurate and succinct=20 and he is not sure what to change that would=20 amount to the same thing in a lot more words. In=20 his opinion, ... has been removed ... . .... MUST=20 NOT query ... . ... MUST NOT publish ... . Is=20 redundant, but he don't strongly object if people think it would be better. There has been some discussion of the _spf label=20 on the SPFBIS mailing list. If I recall=20 correctly I commented about that in one of my responses to the APPSDIR= review. >Section 2.2, 1st para > >> Typically, such checks are done >> by a receiving MTA, but can be performed elsewhere in the mail >> processing chain so long as the required information is available and >> reliable >People may infer a traipse through Received=20 >headers for HELO information.=C2 Is that the=20 >intent, and is that acceptable, given that they=20 >could be forged?=C2 My point: the above is vague. It's, most importantly, the actual connect IP=20 from outside the receiving ADMD. Finding the=20 trust boundary reliably while groveling through=20 the message header is hard, but people do=20 it. Since post-SMTP checks are quite common, it=20 wouldn't be appropriate to try and disallow=20 them. The author thinks the current language is=20 a reasonable compromise and, IIRC, subject to=20 some intense WG debate that he prefers not to revisit. >Section 2.5: title > >>2.5. Location of Checks >I don't think you mean location. I think you mean "When to perform= checks". Location in the sequence of events. Where would=20 work as well. The author thinks Location/When/Where are all equivalent. He=20 prefers not to change it. The SPFBIS did not support a change. >Section 4.7, 2nd para, 2nd sentence. > >> Although the latter >> has a default (specifically "?all"), it aids debugging efforts if it >> is explicitly provided. > >How does it aid in debugging? It makes it clearer to the human eye what's=20 intended. People handle explicit better than implicit. >Section 5.6, ABNF: > >You've gone to some lengths to get ipv4 correct,=20 >but you don't do the same with CIDR prefixes. > >> ip4-cidr-length =3D "/" 1*DIGIT >> ip6-cidr-length =3D "/" 1*DIGIT >Strictly speaking the value range is from 1 to=20 >32, for v4, and 1 to 128 for v6. This isn't=20 >quite all legal, but at least it's bounded: > > ip4-cidr-length =3D "/" 1*2DIGIT ; value must be > 0 and may not= exceed 32 > ip6-cidr-length =3D "/" 1*3DIGIT ; value must be > 0 may not exceed= 128 > >You could do the same as you did with qnum, but perhaps that is overkill. There has been some discussion of the ABNF on the=20 SPFBIS mailing list (=20 http://www.ietf.org/mail-archive/web/spfbis/current/msg04047.html=20 ). This is the suggested ABNF (credits to John Levine): ip4-cidr-length =3D "/" ("0" | %x31-39 0*1DIGIT) ; value range 0-32 ip6-cidr-length =3D "/" ("0" | %x31-39 0*2DIGIT) ; value range 0-128 >Section 6.2, last para: > >The following text is confusing: > >> Note: During recursion into an "include" mechanism, an "exp" modifier >> from the MUST NOT be used.=C2 In contrast, when= executing >> a "redirect" modifier, an "exp" modifier from the original domain >> MUST NOT be used. > >When "MUST NOT be used" do you mean MUST NOT be=20 >evaluated or processed or MUST NOT be present in=20 >the record? e.g., does this MUST apply to operators, implementers, or= both? Recursion into an include or execution of a=20 redirect is part of the evaluation that a=20 verifier does. Must not be processed/evaluated=20 by a verifier. Since record publishers won't=20 always know if others will use point to their=20 records using include/redirect, there's no way a=20 publisher could satisfy this requirement. Given=20 it can only work one way, the author don't understand the confusion. The author is open to improved text, but he does not see the problem. >Appendix A: > >> This section is normative and any discrepancies with the ABNF >> fragments in the preceding text are to be resolved in favor of this >> grammar. >Normally we don't normatively reference=20 >Appendices, and it represents a bit of a=20 >cultural cognitive dissidence for some. One=20 >possible fix: don't make it an Appendix, but the=20 >last section. But also, Section 7.1 is entitled=20 >"Formal Specification". Don't have two of those. The ABNF collection will be moved to a section. >Appendix E: > >There's probably a case not covered here, but=20 >it's close. E.1 describes originating ADMD=20 >behavior. Think of the case of a university or=20 >professional organization that offers=20 >forwarding. The advice given in the first=20 >bullet of E.1 is probably applicable, but=20 >requires that a new whitelist entry be created=20 >for new aliases that contain new hosts on the=20 >RHS. I would go just that bit further to explain. Forwarders are mediators in the terms used here and E.2 is applicable, not= E.1. >Nits: >Please stop creating acronyms. Spam =3D=20 >unsolicited bulk email. UBE is obfuscation in=20 >this case. Similarly, I'd ask the authors to=20 >trying speaking out loud "domain owning ADMDs,",=20 >expanding out the acronym. How about just saying "domain owners"? That's unchanged from RFC 4408. The author does not think we should change= it. RFC 5598 is the mail architecture document the=20 working group used got. The author agrees it's=20 trained, but we tried to stick with terminology=20 from 5598. Ripping out the 5598 terminology=20 would be a bunch of work that he does not think would be worth it. >In general your definitions section is=20 >unnecessarily verbose and could go for a good=20 >"haircut". For example, how about these: > >Imported Definitions: >MAIL FROM: The RFC5321.MailFrom, as defined in [RFC5321] >HELO: The parameter specified in the HELO or=20 >EHLO commands as specified in [RFC5321]. Possibly. The longer definition is largely from RFC 4408. The SPFBIS WG did not suggest any change to this. >Page 7, Section 1.2: > >This forward reference is unnecessary, and I would remove the section. The author agrees but the working group doesn't. >2.1 2nd para, 2nd sentence: > >>If ADMDs >> choose to publish SPF records and want to support receivers making >> negative authorization determinations, it is necessary for them to >> publish records that end in "-all", or redirect to other records that >> do, otherwise, no definitive determination of authorization can be >> made. > >That's grammatically incorrect. Remove=20 >everything after "do," and you are fine. The author is ok with the suggestion. >Same section further down, please clarify "While=20 >offline checks are possible". I think you mean=20 >"deferred" or "checks made after delivery" or some such. The author thinks post-delivery would be=20 better. Obviously literal offline checks aren't possible. >Section 2.2 first para, first sentence: >> A mail receiver can perform a set of SPF checks for each mail message >> it receives. > >What value does this sentence offer the=20 >reader? Personally I say none, and would remove. That's there in response to people complaining=20 4408 was somehow making SPF checks=20 mandatory. The author does not care if it is=20 removed it as long as someone else deals with the=20 crazies convinced it's removal means something sinister. >Section 5.4: "mx" > >>Then it performs an address lookup on each MX name returned. > >To be precise: > >"It then performs an address lookup on of the=20 >name found in the RDATA of each answer." The author is ok with changing this. >Section 8.5, 2nd sentence: > >>The ADMD believes the host is not authorized=20 >>but is not willing to make a strong policy statement > >Which ADMD? The sending one. It's their record. Regards, S. Moonesamy (as document shepherd) =20 From cabo@tzi.org Thu Aug 29 03:37: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 4FE9F21F9DE1 for ; Thu, 29 Aug 2013 03:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[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 OyDHBJ-q+vF1 for ; Thu, 29 Aug 2013 03:37:06 -0700 (PDT) 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 F3C5221F9DD0 for ; Thu, 29 Aug 2013 03:37:05 -0700 (PDT) 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 r7TAb0uI022657; Thu, 29 Aug 2013 12:37:00 +0200 (CEST) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 540986A9; Thu, 29 Aug 2013 12:37:00 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <151E2428-3EC4-4F1E-AE6E-3747B06BB62A@mnot.net> Date: Thu, 29 Aug 2013 12:36:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1B4DD8AA-61B5-475C-B8F4-13CF24A9068C@tzi.org> References: <20130829040129.13080.29347.idtracker@ietfa.amsl.com> <151E2428-3EC4-4F1E-AE6E-3747B06BB62A@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.1508) Cc: Apps Discuss , Barry Leiba Subject: Re: [apps-discuss] Standardising Structure in URIs 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, 29 Aug 2013 10:37:23 -0000 On Aug 29, 2013, at 06:03, Mark Nottingham wrote: > Would the APPSAWG be interested in taking it on as a WG document? With a whole new group of applications and standards developers going on = board of REST in the CoRE space, this is a document that would be highly = useful to be able to point to. So here is my +1 for taking this on as an APPSAWG work item and = document. The difficulty in completing this is probably in section 3; this maybe = needs to be expanded a bit before the document becomes fully convincing = to people not yet entirely skilled in the art. =20 I would be interested to hear how much you think this section can be or = should be filled in. But that can be done in the context of the APPSAWG work on it, it is not = a prerequisite for adopting it. Gr=FC=DFe, Carsten PS.: It's too bad that the "get-off-my-lawn" will no longer be visible = in the RFC... From Peter.Rushforth@NRCan-RNCan.gc.ca Thu Aug 29 07:37: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 F059911E8115 for ; Thu, 29 Aug 2013 07:37:18 -0700 (PDT) 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 q+mI9oK3Yp9w for ; Thu, 29 Aug 2013 07:37:11 -0700 (PDT) Received: from nrcan.gc.ca (s-bsc-edge1.nrcan.gc.ca [132.156.238.13]) by ietfa.amsl.com (Postfix) with ESMTP id 10CAD11E810E for ; Thu, 29 Aug 2013 07:37:05 -0700 (PDT) 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; Thu, 29 Aug 2013 10:37:02 -0400 Received: from S-BSC-MBX1.nrn.nrcan.gc.ca ([169.254.1.190]) by S-BSC-CAS1.nrn.nrcan.gc.ca ([fe80::a1cd:5722:74ed:d1fd%21]) with mapi id 14.02.0342.003; Thu, 29 Aug 2013 10:37:02 -0400 From: "Rushforth, Peter" To: Ioseb Dzmanashvili Thread-Topic: [apps-discuss] NEW RELATION: 'action' version update Thread-Index: AQHOowRCUnFjM5MuwUKJsTXt6Risr5mpGa4AgACdzICAAATxAIAAQS6AgAAapYCAAGb/gIAAdPMAgAAjogCAABA8AIAAIS2AgAD5rWA= Date: Thu, 29 Aug 2013 14:37:01 +0000 Message-ID: <1CD55F04538DEA4F85F3ADF7745464AF24A576EB@S-BSC-MBX1.nrn.nrcan.gc.ca> References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <8410EE3EC8FB4ADA93F4209376AF8183@gmail.com> <30BCEBA7E91E4DDF8D20B3311D362B27@gmail.com> In-Reply-To: <30BCEBA7E91E4DDF8D20B3311D362B27@gmail.com> 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: IETF Apps Discuss Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 29 Aug 2013 14:37:19 -0000 Ioseb, > Folks? What do you think?=20 IMHO registering link relations in the absence of a media type is a bit fra= ught. =20 If you have a specific media type in which the meanings of these link relat= ions can be evaluated that might make it a bit easier to swallow. The mean= ing of words can reasonably be different in different contexts, so reservin= g them at such a high level is not a good idea. Regards, Peter= From tbray@textuality.com Thu Aug 29 09:43: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 7E2E411E8137 for ; Thu, 29 Aug 2013 09:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=-0.595, 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 dfyC0-IsxxrX for ; Thu, 29 Aug 2013 09:43:51 -0700 (PDT) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAF411E812C for ; Thu, 29 Aug 2013 09:43:50 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id m1so517028ves.41 for ; Thu, 29 Aug 2013 09:43:50 -0700 (PDT) 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=PiN9J8gG0zM75r2lbW2T9f5DdAz/iYA/2kJEaibf52M=; b=IVl/VXe6oOqsIEncMWfLPXY4c3GLYtewQH5yQMCNsB6wjiRlPI7ctQHgUYU+ENQH/0 10vDhdN4WmXDrBQWGfRGRoyzw41vtoUUmvmvZXv5L6cvEsFvP++tGYNEW144EvOC53Pb /J8COCxdNEo8iNh3e+BnduLVB/S8U2P0zdbig8dqKuJ7I1rE8H9T//1kB67pynRxeS44 OiserziOVy93sszw6YEqY4fwCfuJCNHWcOBXNqgsKo33vCNAjnpL71Si6Vsr4BPOk3Xk aUpUk2lDUdUaZGYVl/Venes09MHD8gonIU7+gE4l6J+o6tDzuPZXMuNG8rD1Ub6EkQq6 tAZA== X-Gm-Message-State: ALoCoQmAp9yjN344JS74DRsmRFxCNei0052vLIbYvXAhn+HeaTtooKcEWYV5AXsZjPiXkfivLUHl MIME-Version: 1.0 X-Received: by 10.52.92.15 with SMTP id ci15mr1388538vdb.34.1377794628922; Thu, 29 Aug 2013 09:43:48 -0700 (PDT) Received: by 10.221.64.201 with HTTP; Thu, 29 Aug 2013 09:43:48 -0700 (PDT) X-Originating-IP: [96.49.81.176] In-Reply-To: <151E2428-3EC4-4F1E-AE6E-3747B06BB62A@mnot.net> References: <20130829040129.13080.29347.idtracker@ietfa.amsl.com> <151E2428-3EC4-4F1E-AE6E-3747B06BB62A@mnot.net> Date: Thu, 29 Aug 2013 09:43:48 -0700 Message-ID: From: Tim Bray To: Mark Nottingham Content-Type: multipart/alternative; boundary=20cf307f31126e6e3f04e518cfaf Cc: Apps Discuss , Barry Leiba Subject: Re: [apps-discuss] Standardising Structure in URIs 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, 29 Aug 2013 16:43:55 -0000 --20cf307f31126e6e3f04e518cfaf Content-Type: text/plain; charset=UTF-8 I support adoption of this draft. -T On Wed, Aug 28, 2013 at 9:03 PM, Mark Nottingham wrote: > I started this draft during the Berlin meeting, and since have had a lot > of positive feedback. > > Would the APPSAWG be interested in taking it on as a WG document? > > Regards, > > > Begin forwarded message: > > > From: internet-drafts@ietf.org > > Subject: New Version Notification for > draft-nottingham-uri-get-off-my-lawn-02.txt > > Date: 29 August 2013 2:01:29 PM AEST > > To: Mark Nottingham > > > > > > A new version of I-D, draft-nottingham-uri-get-off-my-lawn-02.txt > > has been successfully submitted by Mark Nottingham and posted to the > > IETF repository. > > > > Filename: draft-nottingham-uri-get-off-my-lawn > > Revision: 02 > > Title: Standardising Structure in URIs > > Creation date: 2013-08-29 > > Group: Individual Submission > > Number of pages: 8 > > URL: > http://www.ietf.org/internet-drafts/draft-nottingham-uri-get-off-my-lawn-02.txt > > Status: > http://datatracker.ietf.org/doc/draft-nottingham-uri-get-off-my-lawn > > Htmlized: > http://tools.ietf.org/html/draft-nottingham-uri-get-off-my-lawn-02 > > Diff: > http://www.ietf.org/rfcdiff?url2=draft-nottingham-uri-get-off-my-lawn-02 > > > > Abstract: > > Sometimes, it is attractive to add features to protocols or > > applications by specifying a particular structure for URIs (or parts > > thereof). This document cautions against this practice in standards > > (sometimes called "URI Squatting"). > > > > > > > > > > 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 > > > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --20cf307f31126e6e3f04e518cfaf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I=C2=A0 support adoption of this draft. -T


On Wed, Aug 28, 201= 3 at 9:03 PM, Mark Nottingham <mnot@mnot.net> wrote:
I started this draft during the Berlin meeti= ng, and since have had a lot of positive feedback.

Would the APPSAWG be interested in taking it on as a WG document?

Regards,


Begin forwarded message:

> From: internet-drafts@ietf= .org
> Subject: New Version Notification for draft-nottingham-uri-get-off-my-= lawn-02.txt
> Date: 29 August 2013 2:01:29 PM AEST
> To: Mark Nottingham <mnot@mnot.net= >
>
>
> A new version of I-D, draft-nottingham-uri-get-off-my-lawn-02.txt
> has been successfully submitted by Mark Nottingham and posted to the > IETF repository.
>
> Filename: =C2=A0 =C2=A0 =C2=A0draft-nottingham-uri-get-off-my-lawn
> Revision: =C2=A0 =C2=A0 =C2=A002
> Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Standar= dising Structure in URIs
> Creation date: =C2=A0 =C2=A0 =C2=A0 =C2=A0 2013-08-29
> Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individ= ual Submission
> Number of pages: 8
> URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-nottingham-uri-get-of= f-my-lawn-02.txt
> Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http= ://datatracker.ietf.org/doc/draft-nottingham-uri-get-off-my-lawn
> Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://tool= s.ietf.org/html/draft-nottingham-uri-get-off-my-lawn-02
> Diff: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ietf.org/rfcdiff?url2=3Ddraft-nottingham-uri-get-off-my-l= awn-02
>
> Abstract:
> =C2=A0 Sometimes, it is attractive to add features to protocols or
> =C2=A0 applications by specifying a particular structure for URIs (or = parts
> =C2=A0 thereof). =C2=A0This document cautions against this practice in= standards
> =C2=A0 (sometimes called "URI Squatting").
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>

--
Mark Nottingham =C2=A0 h= ttp://www.mnot.net/



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

--20cf307f31126e6e3f04e518cfaf-- From martin.thomson@gmail.com Thu Aug 29 10:36: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 52FF211E8145 for ; Thu, 29 Aug 2013 10:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 AVp6hPpYQ8vG for ; Thu, 29 Aug 2013 10:36:20 -0700 (PDT) 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 A20CC11E8138 for ; Thu, 29 Aug 2013 10:36:19 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id ex4so5459017wid.11 for ; Thu, 29 Aug 2013 10:36:16 -0700 (PDT) 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=X1NaHUagZx7FR+ux5WSGMly7NqA7tfDPzTJ2zPsGLnQ=; b=HhPcJnQC15aSrfzuh6if1Ue7Lul9tB18ePwgL+PEv+sdn8s81JNi+JpCPLynVMik/3 mItMMuNk7hapl4CkmvpEy8tL3pv5RCNQM7Gl32i2zAx9ARm0Oun/yL4xc91FAxXaw22C fdCk2PEB0XMHRatsKg5T5ksITwnAAk+r5XUj2okbAtvAlt/gfXMSPOJwlhEoOKrK5rfB RS74X77Ng7Bgx64ezQC7Cc0/BzI0Kub7BgNobWHavXaQ5lczn9hRnXn11A+E6zc1f9jc YR21Jd+2RCF6E4vCCbweCCf0KFaAuI8kSbPujNgFZWWyX0i7/N4hfn9p67S1JyUeJfnR 6Iow== MIME-Version: 1.0 X-Received: by 10.180.187.2 with SMTP id fo2mr15791632wic.65.1377797775316; Thu, 29 Aug 2013 10:36:15 -0700 (PDT) Received: by 10.194.28.39 with HTTP; Thu, 29 Aug 2013 10:36:15 -0700 (PDT) In-Reply-To: <151E2428-3EC4-4F1E-AE6E-3747B06BB62A@mnot.net> References: <20130829040129.13080.29347.idtracker@ietfa.amsl.com> <151E2428-3EC4-4F1E-AE6E-3747B06BB62A@mnot.net> Date: Thu, 29 Aug 2013 10:36:15 -0700 Message-ID: From: Martin Thomson To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Cc: Apps Discuss , Barry Leiba Subject: Re: [apps-discuss] Standardising Structure in URIs 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, 29 Aug 2013 17:36:20 -0000 On 28 August 2013 21:03, Mark Nottingham wrote: > Would the APPSAWG be interested in taking it on as a WG document? I think that they should. On 29 August 2013 03:36, Carsten Bormann wrote: > PS.: It's too bad that the "get-off-my-lawn" will no longer be visible in the RFC... Maybe that could become the abbreviated title. From superuser@gmail.com Thu Aug 29 11:40: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 E686A21F9301 for ; Thu, 29 Aug 2013 11:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 yEAPSx-JUnPE for ; Thu, 29 Aug 2013 11:40:24 -0700 (PDT) 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 4A6BB21F918C for ; Thu, 29 Aug 2013 11:40:24 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id k13so909433wgh.13 for ; Thu, 29 Aug 2013 11:40:23 -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=dN0+j4OhA/k1/j+sGjvD3o5oIAOinCw0Kc1e1iW2Iqg=; b=U1cxXg8KNcdVV2V581n91qMtUlt9QYHs3km+jRbnFBBAsxhptN/WJNffLzcLdUDTQy quWFAg1EIt24Vbv7bpvZ2x0U2KJ2n6+3pgClZi2Ps2uSCRYQzftKR7WRgf5qaaY0bIZd n6Do/BMd0U84URBmQIBw3n0LkNytkIz2BxWPc52eQG8RIfDBl5q0+ZjFRBHMOuR2uceC CzSxiA9K9HEE9DMgZdtbF1ZJkMeIGSXNLdIZdQADm906chSyaYHe7uDF46h/qtiT+Gbt 5CS4yfdPTiY4CnweNApa+puz1sQ7ZU1ien6JosrXSiYI/ybWb9beS9l/kiYLQR/K7Q1/ Pang== MIME-Version: 1.0 X-Received: by 10.180.184.107 with SMTP id et11mr16162381wic.60.1377801623436; Thu, 29 Aug 2013 11:40:23 -0700 (PDT) Received: by 10.180.75.144 with HTTP; Thu, 29 Aug 2013 11:40:23 -0700 (PDT) Date: Thu, 29 Aug 2013 11:40:23 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a11c227ee56024804e51a7057 Subject: [apps-discuss] Call for WG Adoption: draft-nottingham-uri-get-off-my-lawn 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, 29 Aug 2013 18:40:25 -0000 --001a11c227ee56024804e51a7057 Content-Type: text/plain; charset=ISO-8859-1 There appears to be some good support for processing this through APPSAWG, so let's make this a formal call for adoption. If there's no sustained objection in the next couple of weeks, we'll make it a work item. Would anyone like to propose a milestone (month/year for IESG handoff)? -MSK, APPSAWG co-chair --001a11c227ee56024804e51a7057 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There appears to be some good support for proces= sing this through APPSAWG, so let's make this a formal call for adoptio= n.=A0 If there's no sustained objection in the next couple of weeks, we= 'll make it a work item.

Would anyone like to propose a milestone (month/year for IESG han= doff)?

-MSK, APPSAWG co-chair
--001a11c227ee56024804e51a7057-- From jasnell@gmail.com Thu Aug 29 12:27: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 D758211E8162 for ; Thu, 29 Aug 2013 12:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_36=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 DhlOE2cQCI8U for ; Thu, 29 Aug 2013 12:27:24 -0700 (PDT) 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 65B4A11E8155 for ; Thu, 29 Aug 2013 12:27:24 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id ta17so952830obb.32 for ; Thu, 29 Aug 2013 12:27:24 -0700 (PDT) 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=h+/EknLEFdR8Y/Tg8u0YVU4GHYkCGSZ65CPF95IaUfI=; b=mYKwgEAIKsoZTZ8KwYj+dFxmK+quyMJZulwPgSWCcmMnm3L4XfYU6rXC83GEwolBrd R0F9i65GSKv4PveRfjb47mfDPe2V0VzdGjxIjFp6Q0wuqMZUp4srHcYYQADQ+aVtDMYh pD/GfOGeNPTYYlzbOKd5+pxPL1uJSjjB2IrYwHysJmgU8sRCfaG7WUzfLJ4TzVZ+/x3Y KOn2tMc8ug/mAfrNqzM14PlloQjsfd59aS42irHLrCIYy4paKe7VOqZmkqV0nT2ftTBa +MtGLGHxHONwaXtWEDB7AbsdCoeZTuIZHtg84jx6A9h2VX6GWTsGfUR4ZxyY7oaENvNj uN0g== X-Received: by 10.182.148.8 with SMTP id to8mr3829651obb.17.1377804443806; Thu, 29 Aug 2013 12:27:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.124.137 with HTTP; Thu, 29 Aug 2013 12:27:03 -0700 (PDT) In-Reply-To: <20130829192557.3316.54379.idtracker@ietfa.amsl.com> References: <20130829192557.3316.54379.idtracker@ietfa.amsl.com> From: James M Snell Date: Thu, 29 Aug 2013 12:27:03 -0700 Message-ID: To: IETF Apps Discuss Content-Type: text/plain; charset=UTF-8 Subject: [apps-discuss] Fwd: New Version Notification for draft-snell-more-link-relations-00.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, 29 Aug 2013 19:27:25 -0000 FYI... definitely a work-in-progress draft... as always, comments/feedback are requested and welcomed. - James ---------- Forwarded message ---------- From: Date: Thu, Aug 29, 2013 at 12:25 PM Subject: New Version Notification for draft-snell-more-link-relations-00.txt To: "James M. Snell" A new version of I-D, draft-snell-more-link-relations-00.txt has been successfully submitted by James M Snell and posted to the IETF repository. Filename: draft-snell-more-link-relations Revision: 00 Title: Additional Link Relations and the urn:social Namespace Creation date: 2013-08-29 Group: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-snell-more-link-relations-00.txt Status: http://datatracker.ietf.org/doc/draft-snell-more-link-relations Htmlized: http://tools.ietf.org/html/draft-snell-more-link-relations-00 Abstract: This specification defines a number of additional Link Relation Types that can used for a variety of purposes.. 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 jasnell@gmail.com Thu Aug 29 12:53: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 E54ED11E8173 for ; Thu, 29 Aug 2013 12:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=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 uW1TGa+2Of6n for ; Thu, 29 Aug 2013 12:53:01 -0700 (PDT) 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 9849F11E8168 for ; Thu, 29 Aug 2013 12:53:00 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wo10so986310obc.13 for ; Thu, 29 Aug 2013 12:52:59 -0700 (PDT) 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=MEi+b/5UjIHlM3dqq01tTq/oH3rJMV7OJVcfg37/wsI=; b=OL76U+dWch0sAK8LT5oYX1+oszqABeGD0uvppxfvoi4yGiZmRYwR0jqKgLP6A3Ii0f VHYhhv5z3QJh+1unjXaf6W22qp1EqlSnCl9H0BQ09v/tgDZU+lGQ3ri7VT1cW03okH2n bJcxArXF8jORGw3PR7OkPz4Hn6C6DZxUAhuZIfOVlxZ52CJRNUDk7m/RjYVZOk9SMnl2 xGYsXz6F1pAIGFmG4yPwnioPDsyAQfa5/ljP4tYdhGSbEpZQKmLxG6qQtAIuadxM9YCc Fe3zO6ifeSmHZXiM/AERqCkiLRrFfnlKBZ+iaod3nhXWtaOug3PePd0J06HNRGM2jzjQ 2wsA== MIME-Version: 1.0 X-Received: by 10.60.62.101 with SMTP id x5mr3854654oer.24.1377805979046; Thu, 29 Aug 2013 12:52:59 -0700 (PDT) Received: by 10.60.124.137 with HTTP; Thu, 29 Aug 2013 12:52:58 -0700 (PDT) Received: by 10.60.124.137 with HTTP; Thu, 29 Aug 2013 12:52:58 -0700 (PDT) In-Reply-To: <521fa3f3.33d4b40a.74fd.ffff8921SMTPIN_ADDED_BROKEN@mx.google.com> References: <20130829192557.3316.54379.idtracker@ietfa.amsl.com> <521fa3f3.33d4b40a.74fd.ffff8921SMTPIN_ADDED_BROKEN@mx.google.com> Date: Thu, 29 Aug 2013 12:52:58 -0700 Message-ID: From: James M Snell To: Markus Lanthaler Content-Type: multipart/alternative; boundary=089e012953acf35d5a04e51b73d5 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-snell-more-link-relations-00.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, 29 Aug 2013 19:53:02 -0000 --089e012953acf35d5a04e51b73d5 Content-Type: text/plain; charset=UTF-8 That would be interesting but it breaks the model that anything in urn:social:* identifies a contextual subset of the social graph. On Aug 29, 2013 12:41 PM, "Markus Lanthaler" wrote: > Just a very quick question: Why do you register all those link relations > instead of using the urn:social namespace for them? So "source" e.g. would > become urn:social:source which would also mean you wouldn't need to > register > them. > > > -- > Markus Lanthaler > @markuslanthaler > > > > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > > bounces@ietf.org] On Behalf Of James M Snell > > Sent: Thursday, August 29, 2013 9:27 PM > > To: IETF Apps Discuss > > Subject: [apps-discuss] Fwd: New Version Notification for draft-snell- > > more-link-relations-00.txt > > > > FYI... definitely a work-in-progress draft... as always, > > comments/feedback are requested and welcomed. > > > > - James > > > > > > ---------- Forwarded message ---------- > > From: > > Date: Thu, Aug 29, 2013 at 12:25 PM > > Subject: New Version Notification for draft-snell-more-link-relations- > > 00.txt > > To: "James M. Snell" > > > > > > > > A new version of I-D, draft-snell-more-link-relations-00.txt > > has been successfully submitted by James M Snell and posted to the > > IETF repository. > > > > Filename: draft-snell-more-link-relations > > Revision: 00 > > Title: Additional Link Relations and the urn:social Namespace > > Creation date: 2013-08-29 > > Group: Individual Submission > > Number of pages: 7 > > URL: > > http://www.ietf.org/internet-drafts/draft-snell-more-link-relations- > > 00.txt > > Status: http://datatracker.ietf.org/doc/draft-snell-more-link- > > relations > > Htmlized: http://tools.ietf.org/html/draft-snell-more-link- > > relations-00 > > > > > > Abstract: > > This specification defines a number of additional Link Relation > > Types > > that can used for a variety of purposes.. > > > > > > > > > > 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 > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > --089e012953acf35d5a04e51b73d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

That would be interesting but it breaks the model that anyth= ing in urn:social:* identifies a contextual subset of the social graph.=C2= =A0

On Aug 29, 2013 12:41 PM, "Markus Lanthaler= " <markus.lanthaler@gmx= .net> wrote:
Just a very quick question: Why do you register all those link relations instead of using the urn:social namespace for them? So "source" e= .g. would
become urn:social:source which would also mean you wouldn't need to reg= ister
them.


--
Markus Lanthaler
@markuslanthaler



> -----Original Message-----
> From: apps-discuss-bo= unces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of= James M Snell
> Sent: Thursday, August 29, 2013 9:27 PM
> To: IETF Apps Discuss
> Subject: [apps-discuss] Fwd: New Version Notification for draft-snell-=
> more-link-relations-00.txt
>
> FYI... definitely a work-in-progress draft... as always,
> comments/feedback are requested and welcomed.
>
> - James
>
>
> ---------- Forwarded message ----------
> From: =C2=A0<internet-d= rafts@ietf.org>
> Date: Thu, Aug 29, 2013 at 12:25 PM
> Subject: New Version Notification for draft-snell-more-link-relations-=
> 00.txt
> To: "James M. Snell" <jasnell@gmail.com>
>
>
>
> A new version of I-D, draft-snell-more-link-relations-00.txt
> has been successfully submitted by James M Snell and posted to the
> IETF repository.
>
> Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-snell-more-link-relations > Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A000
> Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Additional Link Relations an= d the urn:social Namespace
> Creation date: =C2=A0 2013-08-29
> Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
> Number of pages: 7
> URL:
> http://www.ietf.org/internet-drafts/draft-snel= l-more-link-relations-
> 00.txt
> Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://datatracker= .ietf.org/doc/draft-snell-more-link-
> relations
> Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html/d= raft-snell-more-link-
> relations-00
>
>
> Abstract:
> =C2=A0 =C2=A0This specification defines a number of additional Link Re= lation
> Types
> =C2=A0 =C2=A0that can used for a variety of purposes..
>
>
>
>
> 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
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

--089e012953acf35d5a04e51b73d5-- From markus.lanthaler@gmx.net Thu Aug 29 13:05: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 EB38A11E8170 for ; Thu, 29 Aug 2013 13:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[AWL=-4.300, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, 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 aHIQEPCPZfaV for ; Thu, 29 Aug 2013 13:05:00 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id EF9D811E816B for ; Thu, 29 Aug 2013 13:04:59 -0700 (PDT) Received: from Vostro3500 ([188.216.235.198]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LwJFG-1W6OV21qTm-0182fg for ; Thu, 29 Aug 2013 22:04:58 +0200 From: "Markus Lanthaler" To: "'James M Snell'" References: <20130829192557.3316.54379.idtracker@ietfa.amsl.com> <521fa3f3.33d4b40a.74fd.ffff8921SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Thu, 29 Aug 2013 22:04:53 +0200 Message-ID: <005a01cea4f3$07cb1140$176133c0$@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: Ac6k8V1R9eZv7ImVTNaRujCoTvMXmQAAPvzg Content-Language: de X-Provags-ID: V03:K0:/Hd3i8JNV5yR4nz96I4FzWDLd3Y+3PbVnxBurW46QDcS9HHPDqA 3ZS+wz1obCA1U5TyOTEx/TnzqxaY5ULNcK+Vr0fyhs8jB3Wudar862KCC8FUJt6gMIryy6M bpqXqY9ciU0iFmo1hMlHIpDRXcPiUbv+Yb8+ahmyxDZKapbKbHg0puTNQgG3hDEcFwEpXSn miI33LZ+3ZYheMvTiDczQ== Cc: 'IETF Apps Discuss' Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-snell-more-link-relations-00.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, 29 Aug 2013 20:05:05 -0000 On Thursday, August 29, 2013 9:53 PM, James M Snell wrote: > That would be interesting but it breaks the model that anything > in urn:social:* identifies a contextual subset of the social graph.=20 Depends on how you define the context. The source of a message, e.g., = could be seen as a subset of the social graph; just as the nodes = referenced by "to". But perhaps you have something different in mind... -- Markus Lanthaler @markuslanthaler On Aug 29, 2013 12:41 PM, "Markus Lanthaler" = wrote: Just a very quick question: Why do you register all those link relations instead of using the urn:social namespace for them? So "source" e.g. = would become urn:social:source which would also mean you wouldn't need to = register them. -- Markus Lanthaler @markuslanthaler > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of James M Snell > Sent: Thursday, August 29, 2013 9:27 PM > To: IETF Apps Discuss > Subject: [apps-discuss] Fwd: New Version Notification for draft-snell- > more-link-relations-00.txt > > FYI... definitely a work-in-progress draft... as always, > comments/feedback are requested and welcomed. > > - James > > > ---------- Forwarded message ---------- > From: > Date: Thu, Aug 29, 2013 at 12:25 PM > Subject: New Version Notification for draft-snell-more-link-relations- > 00.txt > To: "James M. Snell" > > > > A new version of I-D, draft-snell-more-link-relations-00.txt > has been successfully submitted by James M Snell and posted to the > IETF repository. > > Filename: draft-snell-more-link-relations > Revision: 00 > Title: Additional Link Relations and the urn:social = Namespace > Creation date: 2013-08-29 > Group: Individual Submission > Number of pages: 7 > URL: > http://www.ietf.org/internet-drafts/draft-snell-more-link-relations- > 00.txt > Status: = http://datatracker.ietf.org/doc/draft-snell-more-link- > relations > Htmlized: http://tools.ietf.org/html/draft-snell-more-link- > relations-00 > > > Abstract: > This specification defines a number of additional Link Relation > Types > that can used for a variety of purposes.. > > > > > 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 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From mnot@mnot.net Thu Aug 29 17:31: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 D062121F938E for ; Thu, 29 Aug 2013 17:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.461 X-Spam-Level: X-Spam-Status: No, score=-104.461 tagged_above=-999 required=5 tests=[AWL=-1.862, 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 z8FgpIUyqykI for ; Thu, 29 Aug 2013 17:31:07 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAA221F937E for ; Thu, 29 Aug 2013 17:31:07 -0700 (PDT) Received: from [192.168.1.64] (unknown [118.209.225.40]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D65EA50A88; Thu, 29 Aug 2013 20:31:03 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Mark Nottingham In-Reply-To: Date: Fri, 30 Aug 2013 10:31:01 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <1501FCB6-B39B-4A2E-8C89-B9C96A788E7C@mnot.net> References: To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1508) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for WG Adoption: draft-nottingham-uri-get-off-my-lawn 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, 30 Aug 2013 00:31:11 -0000 I'd hope it can be quick; maybe just after Vancouver? Cheers, On 30/08/2013, at 4:40 AM, Murray S. Kucherawy = wrote: > There appears to be some good support for processing this through = APPSAWG, so let's make this a formal call for adoption. If there's no = sustained objection in the next couple of weeks, we'll make it a work = item. >=20 > Would anyone like to propose a milestone (month/year for IESG = handoff)? >=20 > -MSK, APPSAWG co-chair > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Thu Aug 29 17:32: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 CFA2121F937E for ; Thu, 29 Aug 2013 17:32:11 -0700 (PDT) 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 967mKLINewQX for ; Thu, 29 Aug 2013 17:32:06 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id B008C21F938E for ; Thu, 29 Aug 2013 17:32:06 -0700 (PDT) Received: from [192.168.1.64] (unknown [118.209.225.40]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0BE8A509B5; Thu, 29 Aug 2013 20:32:04 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Mark Nottingham In-Reply-To: <1B4DD8AA-61B5-475C-B8F4-13CF24A9068C@tzi.org> Date: Fri, 30 Aug 2013 10:32:04 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <6E89F982-B6A3-4C74-A881-6CED10DABDE7@mnot.net> References: <20130829040129.13080.29347.idtracker@ietfa.amsl.com> <151E2428-3EC4-4F1E-AE6E-3747B06BB62A@mnot.net> <1B4DD8AA-61B5-475C-B8F4-13CF24A9068C@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.1508) Cc: Apps Discuss , Barry Leiba Subject: Re: [apps-discuss] Standardising Structure in URIs 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, 30 Aug 2013 00:32:12 -0000 On 29/08/2013, at 8:36 PM, Carsten Bormann wrote: > The difficulty in completing this is probably in section 3; this maybe = needs to be expanded a bit before the document becomes fully convincing = to people not yet entirely skilled in the art. =20 > I would be interested to hear how much you think this section can be = or should be filled in. > But that can be done in the context of the APPSAWG work on it, it is = not a prerequisite for adopting it. It's certainly not perfect. However, I don't think this should become a = document about how to compose RESTful APIs; that's likely to be much = more contentious, time-consuming and difficult to complete. That's not = to say such a document shouldn't exist :) Cheers, -- Mark Nottingham http://www.mnot.net/ From dret@berkeley.edu Thu Aug 29 21:55: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 A916821F8F09 for ; Thu, 29 Aug 2013 21:55:28 -0700 (PDT) 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 8XwyPpxIa8XC for ; Thu, 29 Aug 2013 21:55:23 -0700 (PDT) Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id CD89521F8EE6 for ; Thu, 29 Aug 2013 21:55:23 -0700 (PDT) Received: from c-24-6-239-29.hsd1.ca.comcast.net ([24.6.239.29] helo=dretair.local) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1VFGjy-0007p5-Lh; Thu, 29 Aug 2013 21:55:23 -0700 Message-ID: <522025B8.2090901@berkeley.edu> Date: Thu, 29 Aug 2013 21:55:20 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "apps-discuss@ietf.org application-layer protocols" References: <20130830022215.31300.43628.idtracker@ietfa.amsl.com> In-Reply-To: <20130830022215.31300.43628.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130830022215.31300.43628.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: REST Discuss Subject: [apps-discuss] Fwd: New Version Notification for draft-wilde-home-xml-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, 30 Aug 2013 04:55:29 -0000 A new version of I-D, draft-wilde-home-xml-02.txt has been successfully submitted by Erik Wilde and posted to the IETF repository. Filename: draft-wilde-home-xml Revision: 02 Title: Home Documents for HTTP Services: XML Syntax Creation date: 2013-08-29 Group: Individual Submission Number of pages: 12 URL: http://www.ietf.org/internet-drafts/draft-wilde-home-xml-02.txt Status: http://datatracker.ietf.org/doc/draft-wilde-home-xml Htmlized: http://tools.ietf.org/html/draft-wilde-home-xml-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-wilde-home-xml-02 Abstract: The current draft for HTTP Home Documents provides a JSON syntax only. This draft provides an XML syntax for the same underlying data model, so that the concept of HTTP Home Documents can be consistently exposed in both JSON- and XML-based HTTP services. Note to Readers Please discuss this draft on the apps-discuss mailing list [1]. Online access to all versions and files is available on github [2]. From ioseb.dzmanashvili@gmail.com Fri Aug 30 00:12: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 A5DB721E809F; Fri, 30 Aug 2013 00:12:13 -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 ifSBNXgjtefK; Fri, 30 Aug 2013 00:12:13 -0700 (PDT) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0C621E805A; Fri, 30 Aug 2013 00:12:12 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id c13so701382eek.19 for ; Fri, 30 Aug 2013 00:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:content-transfer-encoding :content-disposition; bh=mPy2n5oCl16F8HTLQDiCsFkvOe9M6XNp+z25p6y2bcA=; b=l3j3C7Xx2MQLJyNLkfXxNi5vX2fQvpCBliHRpwEnhl+NyuLS5o8ummWHqvOSmIM9ow 9Ni7Nu3P5jcs38lpkOIB6BzFDJTqGXlVJiu2YPKT1LQZFYSIPGt1lC0Ayqo+BX+AGoSS iImeHIdJNXVOVr2rx9gchk7bMtxKEd70RIyg0k7tR0N7jizW24iRXxLFVu97hiVBdxWA oGQdYACZGjUf5mxr5D38NMxj0UY4Ri9QrxLK5EhY6Z61vvY6QhGrhpt0Y9u3NW+Sq0G8 1WsOIsn0JGHcFTEAj9RSRuN2mCfjFgBBBZUHu7aGfITn+ubjFGDLqRX9O7GBza3WZHEz n9tA== X-Received: by 10.14.115.133 with SMTP id e5mr10432577eeh.27.1377846731619; Fri, 30 Aug 2013 00:12:11 -0700 (PDT) Received: from [10.131.33.142] ([213.131.60.234]) by mx.google.com with ESMTPSA id bn13sm52182377eeb.11.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 30 Aug 2013 00:12:10 -0700 (PDT) Date: Fri, 30 Aug 2013 11:12:08 +0400 From: Ioseb Dzmanashvili To: Mark Nottingham Message-ID: <578924E59872456BA66743C8101F9743@gmail.com> In-Reply-To: <3CC7487C-1157-4F16-ADA3-A246C9EB4B35@mnot.net> References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <3CC7487C-1157-4F16-ADA3-A246C9EB4B35@mnot.net> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Julian Reschke , IETF Apps Discuss , link-relations Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 30 Aug 2013 07:12:13 -0000 Hi Mark, Thanks for response! On Thursday, August 29, 2013 at 7:36 AM, Mark Nottingham wrote: > > On 28/08/2013, at 9:51 AM, Ioseb Dzmanashvili wrote: > > > Now consider this link: > > > > Link: ; rel="action"; action-type="suspend"; title="Suspend" > > > > What it says? > > > > 1. it is an action > > 2. target resource represents description of the action which contains: request method, submit URI, definition of action, other details etc > > 3. agent can look inside "action-type" to determine whether it needs this action type or not > > 4. agent can dereference it, construct request and send it to server > > > > Huh. Why not just use a link hint? E.g., > > Link: ; rel="suspend"; link-kind="action"; title="Suspend" > > or somesuch? I was trying to achieve different thing, but i'm now convinced that it approach is not good enough. At least i can try hints like you suggested. Thanks! Cheers, ioseb > > See: > http://tools.ietf.org/html/draft-nottingham-link-hint > > > -- > Mark Nottingham http://www.mnot.net/ From ioseb.dzmanashvili@gmail.com Fri Aug 30 00:15: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 6649511E80EF for ; Fri, 30 Aug 2013 00:15:05 -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 WLSvQcPp-IrH for ; Fri, 30 Aug 2013 00:15:04 -0700 (PDT) Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9033011E80EC for ; Fri, 30 Aug 2013 00:15:04 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id r16so721328ead.31 for ; Fri, 30 Aug 2013 00:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:content-transfer-encoding :content-disposition; bh=xwkyC2xq+AcyeeiSDYDyxA5Sud/lGe4KmxPv6biZX2w=; b=uBksDV7gO0GcpPDuPjZQyhaoBler2yhGyig34yqsOwfgOwElDowOqKuQqeaQZo7yUJ /ENDJB92ccJ7HHxjeo0j/Xh3TS3KvDvUS0uGVf71c2jcfSa4DaTyI906qJmZRQzJaI32 lQ2Q7GuIfCX7QGraUbMfgal4ouvEDcuEj3kftu8ScAiFqcxMQIlaWtg3DTNXI2QYcuoD RmhZb3RptYH+2f/xipi5cwbfo+cmyltXSA7iMW9MI1RPgJMGuxLasOPJjq1qnvCMEc3M PahIFI8BXf+9jTWBOfkolI33w8Am4nA/BU7QzJiFq7apuAqLPIAmdizHzvCkokaenMr2 af5w== X-Received: by 10.15.35.196 with SMTP id g44mr10427483eev.18.1377846895506; Fri, 30 Aug 2013 00:14:55 -0700 (PDT) Received: from [10.131.33.142] ([213.131.60.234]) by mx.google.com with ESMTPSA id i1sm52195484eeg.0.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 30 Aug 2013 00:14:53 -0700 (PDT) Date: Fri, 30 Aug 2013 11:14:52 +0400 From: Ioseb Dzmanashvili To: =?utf-8?Q?Rushforth=2C_Peter?= Message-ID: In-Reply-To: <1CD55F04538DEA4F85F3ADF7745464AF24A576EB@S-BSC-MBX1.nrn.nrcan.gc.ca> References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <8410EE3EC8FB4ADA93F4209376AF8183@gmail.com> <30BCEBA7E91E4DDF8D20B3311D362B27@gmail.com> <1CD55F04538DEA4F85F3ADF7745464AF24A576EB@S-BSC-MBX1.nrn.nrcan.gc.ca> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: IETF Apps Discuss Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 30 Aug 2013 07:15:05 -0000 Hi Peter, On Thursday, August 29, 2013 at 6:37 PM, Rushforth, Peter wrote: > Ioseb, > > > Folks? What do you think? > > IMHO registering link relations in the absence of a media type is a bit fraught. > > If you have a specific media type in which the meanings of these link relations can be evaluated that might make it a bit easier to swallow. The meaning of words can reasonably be different in different contexts, so reserving them at such a high level is not a good idea. I already mentioned this, but i never tried to register link rels i listed in my email, that is why i choose different approach and qualified these as "actions" not link rels. Thanks anyway! Cheers, ioseb > > Regards, > Peter From mnot@mnot.net Fri Aug 30 00:53: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 7265621E80A3 for ; Fri, 30 Aug 2013 00:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.181 X-Spam-Level: X-Spam-Status: No, score=-104.181 tagged_above=-999 required=5 tests=[AWL=-1.583, 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 NX5t6-T52fBO for ; Fri, 30 Aug 2013 00:52:56 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3626F21E805A for ; Fri, 30 Aug 2013 00:52:56 -0700 (PDT) Received: from [192.168.1.64] (unknown [118.209.133.178]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E281522E25B for ; Fri, 30 Aug 2013 03:52:54 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <41FBD5BB-2FC0-464F-9AB8-0A6F44BFB8E7@mnot.net> Date: Fri, 30 Aug 2013 17:52:51 +1000 To: IETF Apps Discuss Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [apps-discuss] FYI: Proposed W3C WG -- "CSV on the Web" 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, 30 Aug 2013 07:53:01 -0000 (with my liaison hat on) The W3C is considering starting new work around CSV and the Web; http://www.w3.org/2013/05/lcsv-charter.html Since RFC4180 registers CSV (although it's only Informational), they've = contacted us to make sure there isn't a conflict. I don't think there is, but some people here might be interested in = participating over there to some degree. Cheers, -- Mark Nottingham http://www.mnot.net/ From kevinmarks@gmail.com Fri Aug 30 03:37: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 9A34011E80E0 for ; Fri, 30 Aug 2013 03:37:57 -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, 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 OTUeTFU3-4Cd for ; Fri, 30 Aug 2013 03:37:55 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 48CBE11E80DE for ; Fri, 30 Aug 2013 03:37:50 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id f11so1058741qae.16 for ; Fri, 30 Aug 2013 03:37:50 -0700 (PDT) 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=i2gjMNcmPhsCZeJEsiI2H2zl+W8iqCiMmAzG+e2Xdp8=; b=PWapngceXfAgwggfmuZNy+2jWVLiCgfjlkLJ2mOs6n1IEoxTU/Q6bplfO4drQ4f7sP dGS+sBnTrTxwDd0dw02gV1j4BELbFf4DSL/C6aW0VaSkO8aCftAtgjIyKrwD/OB3GnKe zB5ctSM4tDEUShyi8YVfTTRnGKFoqrf/FCO6jXHKMSXtCH8da/aQo6O9+piFY10BNO4r PibUSr5o2Xc/Bmdg2lC6/NxqCd+pZzyKT6aNpanT+cmXhw3W7g0XKNksIJPrv+RyM7Ln +yRqtgYrUfw4gkty3ZhA/UAIjvlUWkm1H7tje1s33GsiInPQQEMy0+uJUXKdWH2com0n cNoA== MIME-Version: 1.0 X-Received: by 10.229.250.5 with SMTP id mm5mr9905163qcb.19.1377859069999; Fri, 30 Aug 2013 03:37:49 -0700 (PDT) Received: by 10.229.242.68 with HTTP; Fri, 30 Aug 2013 03:37:49 -0700 (PDT) Received: by 10.229.242.68 with HTTP; Fri, 30 Aug 2013 03:37:49 -0700 (PDT) In-Reply-To: <41FBD5BB-2FC0-464F-9AB8-0A6F44BFB8E7@mnot.net> References: <41FBD5BB-2FC0-464F-9AB8-0A6F44BFB8E7@mnot.net> Date: Fri, 30 Aug 2013 03:37:49 -0700 Message-ID: From: Kevin Marks To: Mark Nottingham Content-Type: multipart/alternative; boundary=001a113495c46b037304e527d097 Cc: Dan Brickley , Apps Discuss Subject: Re: [apps-discuss] FYI: Proposed W3C WG -- "CSV on the Web" 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, 30 Aug 2013 10:37:57 -0000 --001a113495c46b037304e527d097 Content-Type: text/plain; charset=UTF-8 given that the "join" links are all TBD that could be hard. My position is that csv should be deprecated in favour of the, as csv has non-deterministic escaping rules. On Aug 30, 2013 12:53 AM, "Mark Nottingham" wrote: > (with my liaison hat on) > > The W3C is considering starting new work around CSV and the Web; > http://www.w3.org/2013/05/lcsv-charter.html > > Since RFC4180 registers CSV (although it's only Informational), they've > contacted us to make sure there isn't a conflict. > > I don't think there is, but some people here might be interested in > participating over there to some degree. > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --001a113495c46b037304e527d097 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

given that the "join" links are all TBD that could= be hard.
My position is that csv should be deprecated in favour of the, as csv has n= on-deterministic escaping rules.

On Aug 30, 2013 12:53 AM, "Mark Nottingham&= quot; <mnot@mnot.net> wrote:
(with my liaison hat on)

The W3C is considering starting new work around CSV and the Web;
=C2=A0 http://www.w3.org/2013/05/lcsv-charter.html

Since RFC4180 registers CSV (although it's only Informational), they= 9;ve contacted us to make sure there isn't a conflict.

I don't think there is, but some people here might be interested in par= ticipating over there to some degree.

Cheers,

--
Mark Nottingham =C2=A0 h= ttp://www.mnot.net/



_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
--001a113495c46b037304e527d097-- From mnot@mnot.net Fri Aug 30 04:18: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 4E9DF21F9F13 for ; Fri, 30 Aug 2013 04:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.106 X-Spam-Level: X-Spam-Status: No, score=-104.106 tagged_above=-999 required=5 tests=[AWL=-1.507, 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 4Cko0tKbT0RV for ; Fri, 30 Aug 2013 04:18:47 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id DE1FE21F89C3 for ; Fri, 30 Aug 2013 04:18:46 -0700 (PDT) Received: from syd-mpyvy.mnot.net (unknown [118.209.91.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1ECB650A84; Fri, 30 Aug 2013 07:18:42 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Mark Nottingham In-Reply-To: Date: Fri, 30 Aug 2013 21:18:46 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <41FBD5BB-2FC0-464F-9AB8-0A6F44BFB8E7@mnot.net> To: Kevin Marks X-Mailer: Apple Mail (2.1508) Cc: Dan Brickley , Apps Discuss Subject: Re: [apps-discuss] FYI: Proposed W3C WG -- "CSV on the Web" 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, 30 Aug 2013 11:18:51 -0000 On 30/08/2013, at 8:37 PM, Kevin Marks wrote: > given that the "join" links are all TBD that could be hard.=20 It's a proposed charter; once they've started work, they'll have real, = live links. > My position is that csv should be deprecated in favour of the, as csv = has non-deterministic escaping rules. >=20 > On Aug 30, 2013 12:53 AM, "Mark Nottingham" wrote: > (with my liaison hat on) >=20 > The W3C is considering starting new work around CSV and the Web; > http://www.w3.org/2013/05/lcsv-charter.html >=20 > Since RFC4180 registers CSV (although it's only Informational), = they've contacted us to make sure there isn't a conflict. >=20 > I don't think there is, but some people here might be interested in = participating over there to some degree. >=20 > Cheers, >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From alexey.melnikov@isode.com Fri Aug 30 04:33: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 16E1921F9F88 for ; Fri, 30 Aug 2013 04:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 tfxHUmZYrRmE for ; Fri, 30 Aug 2013 04:33:36 -0700 (PDT) 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 60C3821F9F51 for ; Fri, 30 Aug 2013 04:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1377862414; d=isode.com; s=selector; i=@isode.com; bh=noykhFUIT4zeh97RQGn+FGx7WvP3636nhnWBWrCjDqk=; 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=Hrc2PnrjVIwAc4qFG9pnmRlx6gTizefB86vAvkpyOAJbuo9OMNqOjGmPI6I8u5V2asqbEo oLXxyFNNRFhTvwZMoS6trOljv6OOLeUjTTkfHZA6J1hAY7NQJ8mvC1sTpEP9R1F69N1+93 5Fgccjd1x/95HDRy7BXFGVwdYXXblZQ=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 30 Aug 2013 12:33:33 +0100 Message-ID: <52208311.7030904@isode.com> Date: Fri, 30 Aug 2013 12:33:37 +0100 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: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for WG Adoption: draft-nottingham-uri-get-off-my-lawn 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, 30 Aug 2013 11:33:37 -0000 On 29/08/2013 19:40, Murray S. Kucherawy wrote: > There appears to be some good support for processing this through > APPSAWG, so let's make this a formal call for adoption. If there's no > sustained objection in the next couple of weeks, we'll make it a work > item. I support the WG working on this document. From hallam@gmail.com Fri Aug 30 05:02: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 740F211E8101 for ; Fri, 30 Aug 2013 05:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 NXI05FNcA6fR for ; Fri, 30 Aug 2013 05:02:12 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 762DF21E8089 for ; Fri, 30 Aug 2013 05:02:12 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id u14so1786140lbd.16 for ; Fri, 30 Aug 2013 05:02:11 -0700 (PDT) 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=7hlGJHS4TP9QOS/lFIbtZmoKnEumxbdE6DgSBOOCeDs=; b=sT360ixBTKyXP63nsDmDuiwp4+OdCREY9VZpvidkkQTSdTkZHScGLwXAD6vh7y0Mkd sdqH+zwuinACDdqI2nZOU9sGQ0FxLIRVorgB1C9I8yBr/wO74/FFBkGbY/BPnmNEo82z DzaNbsYhzAksOPCuzHuSlyQPoPdty9AoIh6wU7MoLpLDp0fgvZWky6euqmu8E99eItci dD/8ujD/RxL6wmagF7Grt8vGUedo5F1hfgjye0jcEYhYKrbBEDrNG/9PRSKLVlVSMv5p UmhHfB7+C1t0Usmpi3ErqeiO6B4DvttmXElttj5x6nnstJB5qQJfHysvaPj4OhmKIvNR oLbg== MIME-Version: 1.0 X-Received: by 10.112.74.20 with SMTP id p20mr1563987lbv.36.1377864131348; Fri, 30 Aug 2013 05:02:11 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Fri, 30 Aug 2013 05:02:11 -0700 (PDT) In-Reply-To: References: Date: Fri, 30 Aug 2013 08:02:11 -0400 Message-ID: From: Phillip Hallam-Baker To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=14dae9473c2b1913c504e528fe99 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for WG Adoption: draft-nottingham-uri-get-off-my-lawn 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, 30 Aug 2013 12:02:13 -0000 --14dae9473c2b1913c504e528fe99 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 29, 2013 at 2:40 PM, Murray S. Kucherawy wrote: > There appears to be some good support for processing this through APPSAWG, > so let's make this a formal call for adoption. If there's no sustained > objection in the next couple of weeks, we'll make it a work item. > > Would anyone like to propose a milestone (month/year for IESG handoff)? > > -MSK, APPSAWG co-chair > > I support it but would like to see some more concrete examples of the offending URIs -- Website: http://hallambaker.com/ --14dae9473c2b1913c504e528fe99 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Aug 29, 2013 at 2:40 PM, Murray S. Kucherawy <superuser@= gmail.com> wrote:
There appears to = be some good support for processing this through APPSAWG, so let's make= this a formal call for adoption.=A0 If there's no sustained objection = in the next couple of weeks, we'll make it a work item.

Would anyone like to propose a milestone (month/year for IESG han= doff)?

-MSK, APPSAWG co-chair


I support it but would like to see som= e more concrete examples of the offending URIs

=A0=


--
Website: http://hallambaker.com/
--14dae9473c2b1913c504e528fe99-- From tony@att.com Fri Aug 30 07:47: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 1C78511E8179; Fri, 30 Aug 2013 07:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.34 X-Spam-Level: X-Spam-Status: No, score=-106.34 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 4H3jgeBRkF+Z; Fri, 30 Aug 2013 07:47:30 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id BA07E11E8111; Fri, 30 Aug 2013 07:47:21 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 970b0225.0.3942764.00-368.10858105.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 30 Aug 2013 14:47:23 +0000 (UTC) X-MXL-Hash: 5220b07b0df8664b-98ef9d4eda90721d7ba5dc589117ddfb11a0ae0c Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7UElKFn020732; Fri, 30 Aug 2013 10:47:21 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7UEl8jA020513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Aug 2013 10:47:16 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi132.aldc.att.com (RSA Interceptor); Fri, 30 Aug 2013 14:46:55 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7UEktvQ012523; Fri, 30 Aug 2013 10:46:55 -0400 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7UEkmLl012277; Fri, 30 Aug 2013 10:46:48 -0400 Received: from [135.70.72.203] (vpn-135-70-72-203.vpn.swst.att.com[135.70.72.203]) by maillennium.att.com (mailgw1) with ESMTP id <20130830144646gw1004nhace> (Authid: tony); Fri, 30 Aug 2013 14:46:47 +0000 X-Originating-IP: [135.70.72.203] Message-ID: <5220B055.2000704@att.com> Date: Fri, 30 Aug 2013 10:46:45 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: IETF Discussion , General discussion of application-layer protocols , draft-ietf-repute-model.all@tools.ietf.org X-Enigmail-Version: 1.5.2 Content-Type: multipart/alternative; boundary="------------060402010505070101090409" X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] X-AnalysisOut: [v=2.0 cv=EZl/toaC c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=x8D5cakk9fsA:10 a=sCfsyOEanakA:10 a=409FU5KnOX8A:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=1ndyL1IG] X-AnalysisOut: [x4cA:10 a=48vgC7mUAAAA:8 a=uU-FClygtGCEoXK0zUUA:9 a=wPNLvf] X-AnalysisOut: [GTeEIA:10 a=_W_S_7VecoQA:10 a=lGDGW7yqLC3wcVEe:21] Subject: [apps-discuss] AppsDir review of draft-ietf-repute-model-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: Fri, 30 Aug 2013 14:47:36 -0000 This is a multi-part message in MIME format. --------------060402010505070101090409 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-repute-model-08 Title: A Model for Reputation Reporting Reviewer: Tony Hansen Review Date: 2013-08-29 IESG Telechat Date: 9/12 IETF Last Call Expires: LC for 07 expired on 2013-08-29, but 08 superseded that Summary: The document is ready for publication. Minor notes follow that can be fixed in AUTH48. The document describes a model for reputation services, particularly those being produced by the Repute WG. It follows the recommendations of RFc4101 for describing a protocol model, which requires answers to 1) the problem the protocol is trying to achieve, 2) the meaning of messages transmitted, and 3) important unobvious features of the protocol. This document accomplishes its goals quite well. ==== ORGANIZATIONAL COMMENT ==== Section 3 "High-Level Architecture" starts with an extended example of where a reputation service would fit into an existing service. Finally, more than a page later, it starts describing the architecture that is supposed to be the topic of this section. I suggest that the section be split into two, with the beginning given the heading along the lines of "Example of a Reputation Service Being Used", and the "High-Level Architecture" heading moved right before the paragraph that starts "This document outlines". Alternatively, add subsection titles. ==== MINOR NITS ==== Changes below are marked with >>><<<. ==== Section 1, paragraph 5 starting with "A full trust" I think this sentence would read better as follows, both for readability and to match the style of the surrounding sentences: OLD: Some need only produce a basic rating, while others need to provide OLD: underlying detail. NEW: Some need >>to<< only produce a basic rating, while others need to provide NEW: >>the<< underlying detail. ==== Section 2, paragraph 1 starting with "The basic premise" I think this sentence would read better with the introduction some additional punctuation. OLD: Typically client and service operators enter into OLD: some kind of agreement during which some parameters are exchanged OLD: such as the location at which the reputation service can be reached, OLD: the nature of the reputation data being offered, possibly some client OLD: authentication details, and the like. NEW: Typically client and service operators enter into NEW: some kind of agreement during which some parameters are exchanged>>>,<<< NEW: such as>>>:<<< the location at which the reputation service can be reached, NEW: the nature of the reputation data being offered, possibly some client NEW: authentication details, and the like. ==== Section 3, paragraph 5 starting with "It provides" I think there is a typo in this sentence and the word "one" should be "done". OLD: (Although not typically thought of as a 'transport', the DNS OLD: provides generic capabilities and can be thought of as a mechanism OLD: for transporting queries and responses that have nothing to do with OLD: Internet addresses, such as is one with a DNS BlockList [DNSBL ].) NEW: (Although not typically thought of as a 'transport', the DNS NEW: provides generic capabilities and can be thought of as a mechanism NEW: for transporting queries and responses that have nothing to do with NEW: Internet addresses, such as is >>>done<<< with a DNS BlockList [DNSBL ].) ==== Section 4.1, paragraph 2 starting with "Response Sets have" I think this sentence should be parenthetical: OLD: IANA registries are created in a separate document. NEW: >>>(<<>>)<<< ==== Section 9.3 I think this sentence reads better as follows: OLD: Numerous other topics related to use and management of reputation OLD: systems can be found in [I-D.REPUTE-CONSIDERATIONS]. NEW: Numerous other topics related to >>>the<<< use and management of reputation NEW: systems can be found in [I-D.REPUTE-CONSIDERATIONS]. --------------060402010505070101090409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
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-repute-model-08
Title: A Model for Reputation Reporting

Reviewer: Tony Hansen
Review Date: 2013-08-29
IESG Telechat Date: 9/12
IETF Last Call Expires: LC for 07 expired on 2013-08-29, but 08 superseded that


Summary:
The document is ready for publication. Minor notes follow that can be fixed in AUTH48.

The document describes a model for reputation services, particularly those being produced by the Repute WG. It follows the recommendations of RFc4101 for describing a protocol model, which requires answers to 1) the problem the protocol is trying to achieve, 2) the meaning of messages transmitted, and 3) important unobvious features of the protocol. This document accomplishes its goals quite well.



==== ORGANIZATIONAL COMMENT ====

Section 3 "High-Level Architecture" starts with an extended example of where a reputation service would fit into an existing service. Finally, more than a page later, it starts describing the architecture that is supposed to be the topic of this section. I suggest that the section be split into two, with the beginning given the heading along the lines of "Example of a Reputation Service Being Used", and the "High-Level Architecture" heading moved right before the paragraph that starts "This document outlines". Alternatively, add subsection titles.


 
==== MINOR NITS ====

Changes below are marked with >>><<<.

==== Section 1, paragraph 5 starting with "A full trust"

I think this sentence would read better as follows, both for readability and to match the style of the surrounding sentences:

OLD: Some need only produce a basic rating, while others need to provide
OLD: underlying detail.

NEW: Some need >>to<< only produce a basic rating, while others need to provide
NEW: >>the<< underlying detail.

==== Section 2, paragraph 1 starting with "The basic premise"

I think this sentence would read better with the introduction some additional punctuation.

OLD: Typically client and service operators enter into
OLD: some kind of agreement during which some parameters are exchanged
OLD: such as the location at which the reputation service can be reached,
OLD: the nature of the reputation data being offered, possibly some client
OLD: authentication details, and the like.

NEW: Typically client and service operators enter into
NEW: some kind of agreement during which some parameters are exchanged>>>,<<<
NEW: such as>>>:<<< the location at which the reputation service can be reached,
NEW: the nature of the reputation data being offered, possibly some client
NEW: authentication details, and the like.

==== Section 3, paragraph 5 starting with "It provides"

I think there is a typo in this sentence and the word "one" should be "done".

OLD: (Although not typically thought of as a 'transport', the DNS
OLD: provides generic capabilities and can be thought of as a mechanism
OLD: for transporting queries and responses that have nothing to do with
OLD: Internet addresses, such as is one with a DNS BlockList [DNSBL].)

NEW: (Although not typically thought of as a 'transport', the DNS
NEW: provides generic capabilities and can be thought of as a mechanism
NEW: for transporting queries and responses that have nothing to do with
NEW: Internet addresses, such as is >>>done<<< with a DNS BlockList [DNSBL].)

==== Section 4.1, paragraph 2 starting with "Response Sets have"

I think this sentence should be parenthetical:

OLD: IANA registries are created in a separate document.

NEW: >>>(<<<IANA registries are created in a separate document.>>>)<<<


==== Section 9.3

I think this sentence reads better as follows:

OLD: Numerous other topics related to use and management of reputation
OLD: systems can be found in [I-D.REPUTE-CONSIDERATIONS].

NEW: Numerous other topics related to >>>the<<< use and management of reputation
NEW: systems can be found in [I-D.REPUTE-CONSIDERATIONS].
--------------060402010505070101090409-- From jasnell@gmail.com Fri Aug 30 09:38: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 34E2121E808F for ; Fri, 30 Aug 2013 09:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_36=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 adCGGkgSeOmt for ; Fri, 30 Aug 2013 09:38:50 -0700 (PDT) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7E56B21E805F for ; Fri, 30 Aug 2013 09:38:50 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id g12so2604596oah.34 for ; Fri, 30 Aug 2013 09:38:50 -0700 (PDT) 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=v0qlLm047mvdC1xdemlQw9jZHrbAaCCTqNDYSmFK3wc=; b=l7pxVnHjfsi5o65XcGHilkSffHuP+pkQ2/kpsp7A24NMbDi20EHXHF24nYIyJPF3P/ zS9zaB/ydbURYr6f3GDNOG36r2oHHWEHRhCa+FG5FVC0h+yfdJEYKVPf8ZId75tqm9hx hqR5t249DR1pxlfX5sQxHU+S5xbKi7LJ8+7qFP2Sic4Z3BvwDUI1XYXezQlSLDQZ1Nmy dOq7j2EvbpaQSREqHNa23MufPpItRTQJBUHTyXybWCk1JyJayLyg8PPXL5b/86zTVTQc N/eYp82L398P0MJJch4tsK5RBEnkWfhoZPR+3A7U7BQu3BXnKOSZP0yTOJJcKr1ta2Pe Zj0A== X-Received: by 10.60.44.193 with SMTP id g1mr7581042oem.47.1377880730045; Fri, 30 Aug 2013 09:38:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.124.137 with HTTP; Fri, 30 Aug 2013 09:38:29 -0700 (PDT) In-Reply-To: <521fa96b.09d20e0a.2a0a.ffff9b83SMTPIN_ADDED_BROKEN@mx.google.com> References: <20130829192557.3316.54379.idtracker@ietfa.amsl.com> <521fa3f3.33d4b40a.74fd.ffff8921SMTPIN_ADDED_BROKEN@mx.google.com> <521fa96b.09d20e0a.2a0a.ffff9b83SMTPIN_ADDED_BROKEN@mx.google.com> From: James M Snell Date: Fri, 30 Aug 2013 09:38:29 -0700 Message-ID: To: Markus Lanthaler Content-Type: text/plain; charset=UTF-8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-snell-more-link-relations-00.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, 30 Aug 2013 16:38:51 -0000 On Thu, Aug 29, 2013 at 1:04 PM, Markus Lanthaler wrote: > On Thursday, August 29, 2013 9:53 PM, James M Snell wrote: >> That would be interesting but it breaks the model that anything >> in urn:social:* identifies a contextual subset of the social graph. > > Depends on how you define the context. The source of a message, e.g., could be seen as a subset of the social graph; just as the nodes referenced by "to". But perhaps you have something different in mind... > > In this case, "source" is intended to be a general citation mechanism. It may or may not have anything to do with any particular social graph. - James > > -- > Markus Lanthaler > @markuslanthaler > > > > > On Aug 29, 2013 12:41 PM, "Markus Lanthaler" wrote: > Just a very quick question: Why do you register all those link relations > instead of using the urn:social namespace for them? So "source" e.g. would > become urn:social:source which would also mean you wouldn't need to register > them. > > > -- > Markus Lanthaler > @markuslanthaler > > > >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >> bounces@ietf.org] On Behalf Of James M Snell >> Sent: Thursday, August 29, 2013 9:27 PM >> To: IETF Apps Discuss >> Subject: [apps-discuss] Fwd: New Version Notification for draft-snell- >> more-link-relations-00.txt >> >> FYI... definitely a work-in-progress draft... as always, >> comments/feedback are requested and welcomed. >> >> - James >> >> >> ---------- Forwarded message ---------- >> From: >> Date: Thu, Aug 29, 2013 at 12:25 PM >> Subject: New Version Notification for draft-snell-more-link-relations- >> 00.txt >> To: "James M. Snell" >> >> >> >> A new version of I-D, draft-snell-more-link-relations-00.txt >> has been successfully submitted by James M Snell and posted to the >> IETF repository. >> >> Filename: draft-snell-more-link-relations >> Revision: 00 >> Title: Additional Link Relations and the urn:social Namespace >> Creation date: 2013-08-29 >> Group: Individual Submission >> Number of pages: 7 >> URL: >> http://www.ietf.org/internet-drafts/draft-snell-more-link-relations- >> 00.txt >> Status: http://datatracker.ietf.org/doc/draft-snell-more-link- >> relations >> Htmlized: http://tools.ietf.org/html/draft-snell-more-link- >> relations-00 >> >> >> Abstract: >> This specification defines a number of additional Link Relation >> Types >> that can used for a variety of purposes.. >> >> >> >> >> 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 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > From dret@berkeley.edu Fri Aug 30 11:51: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 A209221F9E00 for ; Fri, 30 Aug 2013 11:51:15 -0700 (PDT) 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 UUXXBbrzp5Ob for ; Fri, 30 Aug 2013 11:51:10 -0700 (PDT) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 637C321E809A for ; Fri, 30 Aug 2013 11:51:10 -0700 (PDT) Received: from c-24-6-239-29.hsd1.ca.comcast.net ([24.6.239.29] 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 1VFTmn-0006x1-Ay; Fri, 30 Aug 2013 11:51:10 -0700 Message-ID: <5220E99A.50906@berkeley.edu> Date: Fri, 30 Aug 2013 11:51:06 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Apps Discuss References: <41FBD5BB-2FC0-464F-9AB8-0A6F44BFB8E7@mnot.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] FYI: Proposed W3C WG -- "CSV on the Web" 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, 30 Aug 2013 18:51:16 -0000 hello kevin. On 2013-08-30 03:37 , Kevin Marks wrote: > My position is that csv should be deprecated in favour of the, as csv > has non-deterministic escaping rules. 1. it seems you forgot to say in favor of what. or is there a format called "the" (maybe "tab something...")? i may just be confused here... 2. if CSV is non-deterministic, shouldn't it be fixed? can it be fixed? i'd be interested to read more about the problems, because having something like it definitely is a good thing in terms of open data. 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 ajs@anvilwalrusden.com Fri Aug 30 12:20: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 1C2E521F9967; Fri, 30 Aug 2013 12:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.833 X-Spam-Level: X-Spam-Status: No, score=-0.833 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 ETJo32aaQ8YN; Fri, 30 Aug 2013 12:20:38 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 44A2A21F9B03; Fri, 30 Aug 2013 12:20:38 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 62DD18A031; Fri, 30 Aug 2013 19:20:36 +0000 (UTC) Date: Fri, 30 Aug 2013 15:20:34 -0400 From: Andrew Sullivan To: ietf@ietf.org, apps-discuss@ietf.org Message-ID: <20130830192034.GP56500@mx1.yitter.info> References: <5220B055.2000704@att.com> <5220E659.1070906@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5220E659.1070906@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] AppsDir review of draft-ietf-repute-model-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: Fri, 30 Aug 2013 19:20:47 -0000 On Fri, Aug 30, 2013 at 02:37:13PM -0400, Hector Santos wrote: > > For example, DKIM-REPUTE product designers would need to consider > SPF reputons product models. Simple text as follows can resolve the > integration consideration with little SPF fanfare the draft > obviously tried to avoid: Why should the framework document contain details of how various particular reputation services interact? If you want a discussion of reputation-service-interaction mechanisms in the draft, that's one thing. If you want to talk about how SPF and DKIM interact, then I think this is probably the wrong draft. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From johnl@iecc.com Fri Aug 30 12:38: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 4525911E8120 for ; Fri, 30 Aug 2013 12:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.612 X-Spam-Level: X-Spam-Status: No, score=-102.612 tagged_above=-999 required=5 tests=[AWL=-0.013, 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 HgjJBIXatEEl for ; Fri, 30 Aug 2013 12:38:05 -0700 (PDT) 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 AE9CF11E8113 for ; Fri, 30 Aug 2013 12:38:04 -0700 (PDT) Received: (qmail 89668 invoked from network); 30 Aug 2013 19:38:03 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 30 Aug 2013 19:38:03 -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=5220f49b.xn--btvx9d.k1308; i=johnl@user.iecc.com; bh=c4XMtJFEWkxZ7h0o9I7xBuVRdDD2mt9ZCz5yE/Tz6uk=; b=NcV3i9gO2HC1887uX/RrR7/OZnEg5Trx/DtuPJ7ERbB/8I4aibchGNi7B8Wff//Inj2y5Z1xTVENKhVPFBDcL7qV0nstqr4GlIuEGjh1K8SLWWB24W+lCzwiclmUzekaI8Pjy64ViuLtRiqBNPG5aPQdu5ugRGQjdpofKwpw4YMOhgYrqcv0eZ8B91r4zErUS46AtExB8j7kox4IYIFj6oB8njdRLuiJAgakZ4stUwtc99PaGOlTM8M3mQH2MQxQ 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=5220f49b.xn--btvx9d.k1308; olt=johnl@user.iecc.com; bh=c4XMtJFEWkxZ7h0o9I7xBuVRdDD2mt9ZCz5yE/Tz6uk=; b=EgDW24nvolIBjnzbNtB2sbzbuKJPvm1dL5n0VQd6nIbB8QShsdsGRfldnYoQ0g7VN7xRGuukrTvxeKZN7IZHhnejCZ7sFLSZq69dANKOfiiPm2S1qe0nGaiPjku4eM4ZF8zKnRLD3ak3l2MIL3ZagL1T/TTl4UYpcFY/PPcxbA2OgDsEt5O36FOM5bsPrR2Ku5ZAa/1Vy2i3xMs8LkLpwEHk6Wd90vI3mk+mfNSGxktTrnx+ucUAx7K3X7xZns8l Date: 30 Aug 2013 19:37:41 -0000 Message-ID: <20130830193741.46703.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <5220E99A.50906@berkeley.edu> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] FYI: Proposed W3C WG -- "CSV on the Web" 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, 30 Aug 2013 19:38:09 -0000 >On 2013-08-30 03:37 , Kevin Marks wrote: >> My position is that csv should be deprecated in favour of the, as csv >> has non-deterministic escaping rules. > >1. it seems you forgot to say in favor of what. or is there a format >called "the" (maybe "tab something...")? i may just be confused here... > >2. if CSV is non-deterministic, shouldn't it be fixed? can it be fixed? >i'd be interested to read more about the problems, because having >something like it definitely is a good thing in terms of open data. The definition in RFC 4180 is fine, but CSV in the field doesn't always agree with it. Some writers quote with double quotes, some with single quotes. Quoted quotes are sometimes doubled "", or sometimes escaped \". There are CSV files where the fields are separated with tabs or other stuff that is not commas. In some CSV files the first line contains the names of the columns, in some it's all data. There are two directions a spec might take: normative to say that only the 4180 flavor qualifies, or descriptive to try to describe all the flavors seen in the wild and perhaps invent a way to identify the flavor as part of the MIME type or something. I entirely agree that anything you can say in CSV you can say better in JSON, but CSV has been around too long and is too well entrenched as a spreadsheet interface to ignore. R's, John From ajs@anvilwalrusden.com Fri Aug 30 13:09: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 6C2B621F9FBA; Fri, 30 Aug 2013 13:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 3IQtKC7t5SNL; Fri, 30 Aug 2013 13:09:23 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 8C35621F9FF2; Fri, 30 Aug 2013 13:09:23 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id EEF988A031; Fri, 30 Aug 2013 20:09:21 +0000 (UTC) Date: Fri, 30 Aug 2013 16:09:20 -0400 From: Andrew Sullivan To: Hector Santos Message-ID: <20130830200920.GS56500@mx1.yitter.info> References: <5220B055.2000704@att.com> <5220E659.1070906@isdg.net> <20130830192034.GP56500@mx1.yitter.info> <5220F4E2.7030005@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5220F4E2.7030005@isdg.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ietf@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] AppsDir review of draft-ietf-repute-model-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: Fri, 30 Aug 2013 20:09:31 -0000 On Fri, Aug 30, 2013 at 03:39:14PM -0400, Hector Santos wrote: > archives of the Repute WG to find or extract these very real and > practical integration considerations. The document should have > these general considerations summarized. But your suggestion was for protocol-specific advice. I don't know how to write that in a generic way. If you have specific text you want, I can evaluate. Your suggestion here, however, is one for which I don't know the response. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From superuser@gmail.com Fri Aug 30 13:18: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 E8EF111E80FA; Fri, 30 Aug 2013 13:18:14 -0700 (PDT) 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.119, 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 LklqU-Q9jUj4; Fri, 30 Aug 2013 13:18:14 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 03DED21F9E91; Fri, 30 Aug 2013 13:18:13 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hi5so2279867wib.16 for ; Fri, 30 Aug 2013 13:18:13 -0700 (PDT) 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=cL2j6x/kydBfMQn/+bTAowui5gMcF6vID4o5oSIxNjk=; b=M8lXpPZWRaPzSu8iJmAnU0fQtObt9jCvk+N3JIHWClvCLOC38M9NTihgjKOwz3m16N 4zXTY1IPX8rf1kRF6CmIiLNM2aAV5DEB6ok+iUh8WWcT11OZhZg96Z+a41Fd4bMU+V7p iZgFEi8YzzIrbVUh44qpCvDmkgD6wGYV1FpA72L48wmLtpUFJraylA2yNmdyGx9SH0BA ekhsHXr2zsKZmKtJSGwowMnM6KTt9+zR34VZJYcuD3fbV55iwTnakm6N5G26T77UYdXq xbx4V6Z7LWRXOI3O3XBCctpb0zqeQHz7HrQk758R0rSyCWPMBegp6KgP1RpgM2XOvCK/ 1Kcg== MIME-Version: 1.0 X-Received: by 10.180.189.9 with SMTP id ge9mr3832624wic.52.1377893893133; Fri, 30 Aug 2013 13:18:13 -0700 (PDT) Received: by 10.180.75.144 with HTTP; Fri, 30 Aug 2013 13:18:12 -0700 (PDT) In-Reply-To: <20130830192034.GP56500@mx1.yitter.info> References: <5220B055.2000704@att.com> <5220E659.1070906@isdg.net> <20130830192034.GP56500@mx1.yitter.info> Date: Fri, 30 Aug 2013 13:18:12 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001a11c3430209de9404e52fec22 Cc: ietf , IETF Apps Discuss Subject: Re: [apps-discuss] AppsDir review of draft-ietf-repute-model-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: Fri, 30 Aug 2013 20:18:15 -0000 --001a11c3430209de9404e52fec22 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 30, 2013 at 12:20 PM, Andrew Sullivan wrote: > On Fri, Aug 30, 2013 at 02:37:13PM -0400, Hector Santos wrote: > > For example, DKIM-REPUTE product designers would need to consider > > SPF reputons product models. Simple text as follows can resolve the > > integration consideration with little SPF fanfare the draft > > obviously tried to avoid: > > Why should the framework document contain details of how various > particular reputation services interact? If you want a discussion of > reputation-service-interaction mechanisms in the draft, that's one > thing. If you want to talk about how SPF and DKIM interact, then I > think this is probably the wrong draft. > > The document we're talking about here only describes a general architecture. DKIM is present in the document for illustration purposes only; it doesn't limit REPUTE to being used by DKIM. The more protocol-specific stuff, which already does include SPF support, is in draft-ietf-repute-email-identifiers. -MSK --001a11c3430209de9404e52fec22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Aug 30, 2013 at 12:20 PM, Andrew Sullivan <a= js@anvilwalrusden.com> wrote:
<= div class=3D"gmail_quote">
On Fri, Aug 30, 2013 at 02= :37:13PM -0400, Hector Santos wrote:
> For example, DKIM-REPUTE product designers would need to consider
> SPF reputons product models. =A0Simple text as follows can resolve the=
> integration consideration with little SPF fanfare the draft
> obviously tried to avoid:

Why should the framework document contain details of how various
particular reputation services interact? =A0If you want a discussion of
reputation-service-interaction mechanisms in the draft, that's one
thing. =A0If you want to talk about how SPF and DKIM interact, then I
think this is probably the wrong draft.


The document we're talking about h= ere only describes a general architecture.=A0 DKIM is present in the docume= nt for illustration purposes only; it doesn't limit REPUTE to being use= d by DKIM.=A0 The more protocol-specific stuff, which already does include = SPF support, is in draft-ietf-repute-email-identifiers.

-MSK
--001a11c3430209de9404e52fec22-- From tony@att.com Fri Aug 30 15:26: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 4162E21F9EC4; Fri, 30 Aug 2013 15:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.738 X-Spam-Level: X-Spam-Status: No, score=-105.738 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 z8E8HxO9N8LA; Fri, 30 Aug 2013 15:26:45 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1756E21F9EBE; Fri, 30 Aug 2013 15:26:45 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 22c11225.0.4226721.00-228.11656772.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 30 Aug 2013 22:26:45 +0000 (UTC) X-MXL-Hash: 52211c250229014d-a4f7a0e8c0cdd78a7ace08e3e3b044596b8bb2d6 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7UMQfbf025343; Fri, 30 Aug 2013 18:26:42 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7UMQPIc025217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Aug 2013 18:26:34 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor); Fri, 30 Aug 2013 22:26:16 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7UMQFqi003498; Fri, 30 Aug 2013 18:26:15 -0400 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r7UMQ7e7003296; Fri, 30 Aug 2013 18:26:10 -0400 Received: from [135.70.221.184] (vpn-135-70-221-184.vpn.east.att.com[135.70.221.184]) by maillennium.att.com (mailgw1) with ESMTP id <20130830222601gw1004nhaee> (Authid: tony); Fri, 30 Aug 2013 22:26:06 +0000 X-Originating-IP: [135.70.221.184] Message-ID: <52211BF8.80907@att.com> Date: Fri, 30 Aug 2013 18:26:00 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 References: <5220B055.2000704@att.com> <5220E659.1070906@isdg.net> In-Reply-To: <5220E659.1070906@isdg.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] X-AnalysisOut: [v=2.0 cv=EZl/toaC c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=GibGvsWJ3EMA:10 a=sCfsyOEanakA:10 a=SRphlgSVIREA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=D1GT84r3OkIA:10 a=RoLo4V4g0zLiQJr0MqQA:9 a=QEXdD] X-AnalysisOut: [O2ut3YA:10] Cc: draft-ietf-repute-model.all@tools.ietf.org, IETF Discussion , General discussion of application-layer protocols Subject: Re: [apps-discuss] AppsDir review of draft-ietf-repute-model-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: Fri, 30 Aug 2013 22:26:52 -0000 On 8/30/2013 2:37 PM, Hector Santos wrote: > On 8/30/2013 10:46 AM, Tony Hansen wrote: >> >> The document describes a model for reputation services, particularly >> those being produced by the Repute WG. It follows the recommendations >> of RFc4101 for describing a protocol model, which requires answers to >> 1) the problem the protocol is trying to achieve, 2) the meaning of >> messages transmitted, and 3) important unobvious features of the >> protocol. This document accomplishes its goals quite well. > > As a high potential implementator of this DKIM-REPUTE framework and > user of any future REPUTE products based on this DKIM-REPUTE > framework, I am somewhat disappointed to find not a single integration > consideration for the highly adopted SPF technology. Not a single > mentioning of the word or the integrated use of this highly adopted > mail transport augmented technology. ... Hector, what you're suggesting would be fine for a document that specifically was written about reputation servers for email services. But draft-ietf-repute-model is not the place for it. While draft-ietf-repute-model does contain an example of how a reputation service could be used to help assess a DKIM identifier, that is not the thrust of this document. RFC 4101 (Writing Protocol Models) contains this advice: 3.2 Abstraction is good ... try to abstract away pieces ... 3.3 A few well-chosen details sometimes help ... it's often a good approach to talk about the material in the abstract and then provide a concrete description of one specific piece to bring it into focus. ... The DKIM example is just that, an example of one way the model could be used. It is strictly illustrative and not exclusionary in any way. Tony Hansen From ajs@anvilwalrusden.com Fri Aug 30 16:39: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 BF3E921E8091; Fri, 30 Aug 2013 16:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 9FV09qDXPfGo; Fri, 30 Aug 2013 16:39:27 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id F10B921E8082; Fri, 30 Aug 2013 16:39:26 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id D24F18A031; Fri, 30 Aug 2013 23:39:25 +0000 (UTC) Date: Fri, 30 Aug 2013 19:39:24 -0400 From: Andrew Sullivan To: ietf@ietf.org, apps-discuss@ietf.org Message-ID: <20130830233923.GY56500@mx1.yitter.info> References: <5220B055.2000704@att.com> <5220E659.1070906@isdg.net> <52211BF8.80907@att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] AppsDir review of draft-ietf-repute-model-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: Fri, 30 Aug 2013 23:39:32 -0000 Hi Doug! On Fri, Aug 30, 2013 at 04:24:17PM -0700, Douglas Otis wrote: > Use of DKIM offers a very poor authentication example Thanks for the feedback. I don't recall you having made this point on the repute mailing list. Did you, & I missed it? Do you have a better example, specifically excluding … > StartTLS would represent a much better example. …this, which strikes me as suffering from a different but related set of issues along the lines you're complaining about? Alternatively, if we recast the description of DKIM to call it something else, but still used it as an example of what REPUTE is trying to do, would that solve your objection? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From sm@elandsys.com Fri Aug 30 17:53: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 F41D411E80A2; Fri, 30 Aug 2013 17:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 qgKFub29KgCa; Fri, 30 Aug 2013 17:53:27 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE03321F9DD5; Fri, 30 Aug 2013 17:53:26 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.235.70]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7V0pUuK001627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Aug 2013 17:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377910304; bh=omB6O6MlRFZaimTEi9YY0KUB3cD91Nimvnx460GkCIY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Pzk2ZRoCH3qL8RDRWw5hhFoN8xvgwbflKOhkuLY5/bqQES1ry7jI3ODidEzETRciv 9tF8a58zQP7YUv0X22J7Ozo+bgH8N+qJwEeHHJkJ89PsI8KxMCYMZTpgryZNA8clRe uhiiyo8Rrm5CPywMb9EA0XGIgP6DqJdECrMRfWRM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377910304; i=@elandsys.com; bh=omB6O6MlRFZaimTEi9YY0KUB3cD91Nimvnx460GkCIY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=j6e9mIZWkIX90QjU4OxJWfry6ZaxVXBS7o+850T7/9EE0RDjcpktD3qAKYxTKq+S3 yz4mpT+nctuBO+z7MzfkKxDiQkt3ORUWbEywbq6Asi9jPq6XB7cIu3BDz8oaoF0DcO ZCO7L7i0O/DXB7ktA3zBKkeP/kh5+8uexGlUlj54= Message-Id: <6.2.5.6.2.20130830172652.06409ab8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 30 Aug 2013 17:46:51 -0700 To: ietf@ietf.org From: S Moonesamy In-Reply-To: <52211BF8.80907@att.com> References: <5220B055.2000704@att.com> <5220E659.1070906@isdg.net> <52211BF8.80907@att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] AppsDir review of draft-ietf-repute-model-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: Sat, 31 Aug 2013 00:53:29 -0000 Hello, After reading the reviews of the Application Area Directorate review it seems to me that there is some misunderstanding of what an Application Area Directorate review is about. The review is to give the Applications Area Directors a sense of how important it is that they pay attention to a draft. If there is a problem with a working group draft that problem should be taken up with the working group instead of the Applications Area Directorate reviewer. If there is a problem with the Applications Area Directorate review it is okay in my opinion to discuss about that with the reviewer. Regards, S. Moonesamy From ajs@anvilwalrusden.com Fri Aug 30 19:51: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 A0AF121F9ADD; Fri, 30 Aug 2013 19:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 g99UGEnrsRpb; Fri, 30 Aug 2013 19:50:58 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id D172D21F9AA7; Fri, 30 Aug 2013 19:50:58 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 379158A031; Sat, 31 Aug 2013 02:50:56 +0000 (UTC) Date: Fri, 30 Aug 2013 22:50:54 -0400 From: Andrew Sullivan To: ietf@ietf.org, apps-discuss@ietf.org Message-ID: <20130831025054.GC58179@mx1.yitter.info> References: <5220B055.2000704@att.com> <5220E659.1070906@isdg.net> <52211BF8.80907@att.com> <20130830233923.GY56500@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20130830233923.GY56500@mx1.yitter.info> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] AppsDir review of draft-ietf-repute-model-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: Sat, 31 Aug 2013 02:51:04 -0000 Colleagues, and Doug especially, The message I sent (below) wasn't intended as a "shut up and go away" message, but a genuine query. I have grave doubts that TLS is the right example (to begin with, I think fitting it into the REPUTE approach, given the existing CA structure, would also be controversial); but I'm genuinely trying to understand how to make the document better, & not trying to tell anyone to go away. Best, A On Fri, Aug 30, 2013 at 07:39:24PM -0400, Andrew Sullivan wrote: > Hi Doug! > > On Fri, Aug 30, 2013 at 04:24:17PM -0700, Douglas Otis wrote: > > > Use of DKIM offers a very poor authentication example > > Thanks for the feedback. I don't recall you having made this point on > the repute mailing list. Did you, & I missed it? > > Do you have a better example, specifically excluding … > > > StartTLS would represent a much better example. > > …this, which strikes me as suffering from a different but related set > of issues along the lines you're complaining about? > > Alternatively, if we recast the description of DKIM to call it > something else, but still used it as an example of what REPUTE is > trying to do, would that solve your objection? > > Best, > > A > -- Andrew Sullivan ajs@anvilwalrusden.com From dret@berkeley.edu Sat Aug 31 09:40: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 3E36E21F8DDD; Sat, 31 Aug 2013 09:40:55 -0700 (PDT) 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 ogdFdQw8f-Dn; Sat, 31 Aug 2013 09:40:50 -0700 (PDT) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 993A121F842B; Sat, 31 Aug 2013 09:40:50 -0700 (PDT) Received: from c-24-6-239-29.hsd1.ca.comcast.net ([24.6.239.29] helo=dretpro.local) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1VFoE6-000087-AA; Sat, 31 Aug 2013 09:40:43 -0700 Message-ID: <52221C87.8030800@berkeley.edu> Date: Sat, 31 Aug 2013 09:40:39 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jan Algermissen References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <8410EE3EC8FB4ADA93F4209376AF8183@gmail.com> <30BCEBA7E91E4DDF8D20B3311D362B27@gmail.com> <05573AE3-70B4-4A03-AABA-AC51E8EBC60B@nordsc.com> In-Reply-To: <05573AE3-70B4-4A03-AABA-AC51E8EBC60B@nordsc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Reschke , IETF Apps Discuss , link-relations Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 31 Aug 2013 16:40:55 -0000 hello. On 2013-08-28 13:27 , Jan Algermissen wrote: > On 28.08.2013, at 22:02, mike amundsen wrote: >> 2) when crafting link rel values, i got good advice (I think it was from JulianR?) to cast the definitions as "relations" not just "verbs" or "nouns." for example: >> "The link relation {value} identifies a target resource that represents {a concept}." There are variations, but you'll get the idea. > Yes. And do not let AtomPub's 'edit' fool you - it is just a bad choice. 'Edit' should have been sth like 'source' because what edit identifies is the one entry you need to direct requests to that intend to change the entry - (as opposed to the member-entries that represent that 'edit'-entry in individual collections. > IOW, you do not need a 'delete' and an 'edit' entry, just a 'source' entry and then you go there to PUT or DELETE. i agree, the link only tells you why you might want to follow it: because you want to engage in edit interactions with the source of the entry. the allowed interactions are defined by the media type of the link target: if the link target is an AtomPub entry, then AtomPub tells you that you can attempt to PUT or DELETE and expect them to work as defined by AtomPub. if a server serving such a link wanted to hint at the fact that a particular link target only supported PUT or DELETE (so that for example a UI could gray out the "delete" button), then it could use link hints to communicate this constraint in the link. this way, it would be possible for a client to avoid requests that are likely to fail. 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 mca@amundsen.com Sat Aug 31 10:00: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 42F4621F85B8 for ; Sat, 31 Aug 2013 10:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.807 X-Spam-Level: * X-Spam-Status: No, score=1.807 tagged_above=-999 required=5 tests=[AWL=1.886, 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 BSXgVnHQEB+d for ; Sat, 31 Aug 2013 10:00:50 -0700 (PDT) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) by ietfa.amsl.com (Postfix) with ESMTP id 465FF21E80C9 for ; Sat, 31 Aug 2013 10:00:46 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id q58so2570786wes.11 for ; Sat, 31 Aug 2013 10:00:44 -0700 (PDT) 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=5Y0xiPmpLhm9+gDesWF1A/Jo6qEZtJ9kcpxQxotoN08=; b=Inlb/KrjFHp3Rqve+aXDJZrbyZ6rF9Jy3PHqzL1EUfVFc31NKQfkN3sgTrOttdf6Vh GiezIcz62e23os+cIE94du6b5G4Jc/UYTZQIM0io8QIDoTm30yYYwNFBIuc9L/oMgTnM jUIAEMSHhswA7+2NMJ+1WPdvNAyYRoOSAsoOiNCfjgnwByTIe3a62HddoC/hpB5+pIa1 KzYkgq0gSwPh7eMA/Nb91PHAp1szibZUyqT3QSDKsKAXRZIscMU4PEe1Z7cRzdCltxqs 2aEgLn4tQWjwE8AtBBY1tFT/ZiDmYaUsiHTTMDU+0CZP5/CtvdxI3xoSl4O0+U/UgNkp svaQ== X-Gm-Message-State: ALoCoQmn2kO2EWHNPD0ay2xiuoiI2tYA0UhREO+/ZMbU9K5E2I+n0EZqln6IK3EYQS/1YdzV/xSW X-Received: by 10.180.77.49 with SMTP id p17mr6930534wiw.36.1377968444005; Sat, 31 Aug 2013 10:00:44 -0700 (PDT) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.151.7 with HTTP; Sat, 31 Aug 2013 10:00:23 -0700 (PDT) In-Reply-To: <52221C87.8030800@berkeley.edu> References: <6F6F01CDC9614FBDA50B270B9840A538@gmail.com> <521C7C36.9000505@gmx.de> <7F2E562DC01C452390F9AB2476D66F8C@gmail.com> <70B4B39BB3F44DC99274739DEB4B4717@gmail.com> <8410EE3EC8FB4ADA93F4209376AF8183@gmail.com> <30BCEBA7E91E4DDF8D20B3311D362B27@gmail.com> <05573AE3-70B4-4A03-AABA-AC51E8EBC60B@nordsc.com> <52221C87.8030800@berkeley.edu> From: mike amundsen Date: Sat, 31 Aug 2013 13:00:23 -0400 X-Google-Sender-Auth: Ulg8SkVDRuMINLOOTB4_xU45hk0 Message-ID: To: Erik Wilde Content-Type: multipart/alternative; boundary=f46d043892139dfbd304e5414730 Cc: Julian Reschke , IETF Apps Discuss , link-relations Subject: Re: [apps-discuss] NEW RELATION: 'action' version update 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, 31 Aug 2013 17:00:50 -0000 --f46d043892139dfbd304e5414730 Content-Type: text/plain; charset=ISO-8859-1 At this point, what we're discussing is affordance design. I will confess that the desire to pack up all the information on how to activate a transition into "hints" on a LINK element creates not just an ugly affordance, but also one needlessly difficult to use/animate. This is esp. true when machines are required to "so-somewhere-else" in order to resolve the details of the affordance (e.g. using OPTIONS, packing all the instructions in a document at the end of a rel-link, etc.). why are we so unwilling to model FORMS? what is it about the FORM-style affordance that is so unappealing to designers/developers? 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/mikeamundsen On Sat, Aug 31, 2013 at 12:40 PM, Erik Wilde wrote: > hello. > > > On 2013-08-28 13:27 , Jan Algermissen wrote: > >> On 28.08.2013, at 22:02, mike amundsen wrote: >> >>> 2) when crafting link rel values, i got good advice (I think it was from >>> JulianR?) to cast the definitions as "relations" not just "verbs" or >>> "nouns." for example: >>> "The link relation {value} identifies a target resource that represents >>> {a concept}." There are variations, but you'll get the idea. >>> >> Yes. And do not let AtomPub's 'edit' fool you - it is just a bad choice. >> 'Edit' should have been sth like 'source' because what edit identifies is >> the one entry you need to direct requests to that intend to change the >> entry - (as opposed to the member-entries that represent that 'edit'-entry >> in individual collections. >> IOW, you do not need a 'delete' and an 'edit' entry, just a 'source' >> entry and then you go there to PUT or DELETE. >> > > i agree, the link only tells you why you might want to follow it: because > you want to engage in edit interactions with the source of the entry. > > the allowed interactions are defined by the media type of the link target: > if the link target is an AtomPub entry, then AtomPub tells you that you can > attempt to PUT or DELETE and expect them to work as defined by AtomPub. > > if a server serving such a link wanted to hint at the fact that a > particular link target only supported PUT or DELETE (so that for example a > UI could gray out the "delete" button), then it could use link hints to > communicate this constraint in the link. this way, it would be possible for > a client to avoid requests that are likely to fail. > > 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 | > --f46d043892139dfbd304e5414730 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
<tangent>
At this point, what we're di= scussing is affordance design.

I will confess that the d= esire to pack up all the information on how to activate a transition into &= quot;hints" on a LINK element creates not just an ugly affordance, but= also one needlessly difficult to use/animate. This is esp. true when machi= nes are required to "so-somewhere-else" in order to resolve the d= etails of the affordance (e.g. using OPTIONS, packing all the instructions = in a document at the end of a rel-link, etc.).

why are we so unwilling to model FORMS? what is it abou= t the FORM-style affordance that is so unappealing to designers/developers?= =A0
</tangent>




On Sat, Aug 31, 2013 at 12:40 PM, Erik W= ilde <dret@berkeley.edu> wrote:
hello.


On 2013-08-28 13:27 , Jan Algermissen wrote:
On 28.08.2013, at 22:02, mike amundsen <mamund@yahoo.com> wrote:
2) when crafting link rel values, i got good advice (I think it was from Ju= lianR?) to cast the definitions as "relations" not just "ver= bs" or "nouns." for example:
"The link relation {value} identifies a target resource that represent= s {a concept}." There are variations, but you'll get the idea.
Yes. And do not let AtomPub's 'edit' fool you - it is just a ba= d choice. 'Edit' should have been sth like 'source' because= what edit identifies is the one entry you need to direct requests to that = intend to change the entry - (as opposed to the member-entries that represe= nt that 'edit'-entry in individual collections.
IOW, you do not need a 'delete' and an 'edit' entry, just a= 'source' entry and then you go there to PUT or DELETE.

i agree, the link only tells you why you might want to follow it: because y= ou want to engage in edit interactions with the source of the entry.

the allowed interactions are defined by the media type of the link target: = if the link target is an AtomPub entry, then AtomPub tells you that you can= attempt to PUT or DELETE and expect them to work as defined by AtomPub.
if a server serving such a link wanted to hint at the fact that a particula= r link target only supported PUT or DELETE (so that for example a UI could = gray out the "delete" button), then it could use link hints to co= mmunicate this constraint in the link. this way, it would be possible for a= client to avoid requests that are likely to fail.

cheers,

dret.

--
erik wilde | mailto:= dret@berkeley.edu =A0- =A0tel:+1-510-2061079 |
=A0 =A0 =A0 =A0 =A0 =A0| UC Berkeley =A0- =A0School of Information (ISchool= ) |
=A0 =A0 =A0 =A0 =A0 =A0| http://dret.net/netdret http://twitter.com/dret |

--f46d043892139dfbd304e5414730--