From duerst@it.aoyama.ac.jp Wed May 1 02:35: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 1FAA821F86B2; Wed, 1 May 2013 02:35:48 -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 nhab4UGzO0gR; Wed, 1 May 2013 02:35:42 -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 63B2121F8689; Wed, 1 May 2013 02:35:41 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r419ZXxw007458; Wed, 1 May 2013 18:35:33 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 6195_59bc_787cefec_b242_11e2_a74f_001e6722eec2; Wed, 01 May 2013 18:35:32 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id D3AC3C022D; Wed, 1 May 2013 18:35:01 +0900 (JST) Message-ID: <5180E1D9.7010006@it.aoyama.ac.jp> Date: Wed, 01 May 2013 18:35:21 +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: Apps Area WG , draft-sparks-genarea-imaparch.all@tools.ietf.org, IESG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [apps-discuss] Apps Area review of draft-sparks-genarea-imaparch-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: Wed, 01 May 2013 09:35:48 -0000 I have been selected as the Applications Area Directorate reviewer for=20 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=20 you may receive. Please wait for direction from your document shepherd=20 or AD before posting a new version of the draft. Document: draft-sparks-genarea-imaparch-06 Title: IMAP Access to IETF Email List Archives Reviewer: Martin D=C3=BCrst Review Date: 2013/05/01 Summary: There is one main issue that's unclear to me. Otherwise, the=20 draft is close to publication, but needs some additional work. Note: I'm not an IMAP expert, not even an IMAP user, and not somebody=20 the Apps Area would call an email expert, although I wrote RFC 5064 and=20 quite a bit of RFC 6068. So the comments here are mostly of general natur= e. Main issue: It is totally unclear to me what the actual consequences of=20 this draft are if approved. I could imagine any one of the following: - It's informational, so it doesn't have any standing, and is just a wishlist, mostly just by the author. - If and when it will be IESG-approved, it documents IETF consensus on how to best implement IMAP-based access to mailing list archives for the IETF should such access be desirable, but it does not represent an IETF consensus to actually implement this (e.g. because that needs money, and money doesn't move by IETF consensus). - If and when it will be IESG-approved, it documents IETF consensus that IMAP-based access to IETF mailing lists is desirable, and should be implemented asap (assuming somebody can come up with the necessary resources). - An informal mixture of the above: Those in the know agree it's a good idea, but somebody said they need a document that can be referenced in an RFP. While I'm personally okay with any of the above (I won't use this kind=20 of access in the near future, but can understand that many people are=20 using IMAP and it would be pretty handy to have such a feature; also I=20 won't have to pay for it), I think the fact that this unclarity exists=20 may make it difficult for others to review the draft. So I suggest that this be clarified. Unless it's just me who's unclear=20 on this issue, it may get close to meriting a new or prolonged last call. Minor issue: The draft should reference RFC 6855 (IMAP Support for=20 UTF-8) and require its support *at least* to the extent that RFC 6778=20 does (see http://tools.ietf.org/html/rfc6778#section-3). Editorial/Nits: o The interface must allow administrators to disable setting read/ unread marks and other annotations, and delete any such marks or annotations on a per user basis. It's unclear how far back "on a per user basis" applies. Also, "the=20 interface" means "an IMAP interface" (first bullet point), but it may=20 not be possible or practical to have administrators use IMAP itself for=20 this function. So I suggest something along the following lines: o It must be possible for administrators, on a per-user basis, to disable setting read/unread marks and other annotations and to delete any such marks or annotations. "and should support multiple simultaneous extensive searches.": Is this=20 simultaneous searches by the same user, or by different users? I suspect=20 the later. If so, the clause should be rewritten so that it is clear=20 that this is a dimensioning requirement, not a functionality requirement. "The server should facilitate the enhanced search capabilities described=20 in [RFC6778].": It is unclear what "facilitate" means here. Technology=20 usually implements something or doesn't; facilitate sounds quite fuzzy.=20 Although RFC 6778 is informational, it uses quite a bit of 'must',... On=20 the other hand, IMAP may or may not support some of the queries listed=20 as a 'must' in RFC 6778. "(But it is acceptable for a user to access such archives while=20 providing credentials).": Don't start a sentence with 'But' (use=20 'However'). Also, please put the final period inside the parentheses. "an LOGIN command" -> "a LOGIN command" "determined by the administrator ." -> "determined by the administrator." "local copies all messages" -> "local copies of all messages" "maliciously crafted searches attempting to consume all available=20 resources" -> "maliciously crafted searches attempting to consume=20 significant available resources" (there is no need to consume all=20 resources to result in significant DOS problems) " maliciously crafted annontations attempting to consume all storage=20 space" -> " maliciously crafted annontations attempting to consume=20 significant storage space" "The implementers should consider making it easy for the administrator=20 to determine which users are consuming exceptional space.": "exceptional=20 space" -> "exceptional amounts of space"; I also think "should consider"=20 is rather too weak, and "easy to determine" seems to imply that=20 administrators will have to actively check this (rather than getting=20 alerts when something fishy starts). This may be just an implementation detail, but it may be a good idea to=20 note that flag implementation (and annotation implementation if an=20 annotation can be applied by the user to more than one message at once)=20 has to be quite clever because otherwise, even benign use might use up=20 lots of space. As an example, if the system allocates 4 bytes for each=20 message in the system for each user that logs into the system even once,=20 that may already create huge storage demands. Regards, Martin. From ht@inf.ed.ac.uk Wed May 1 03:13: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 EFD2C21F8C30 for ; Wed, 1 May 2013 03:13:31 -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 cgdKQ89mum6G for ; Wed, 1 May 2013 03:13:27 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2C85D21F8C08 for ; Wed, 1 May 2013 03:13:26 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id r41ADHfG027375; Wed, 1 May 2013 11:13:17 +0100 (BST) Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r41ADEs0016866; Wed, 1 May 2013 11:13:15 +0100 Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r41ADGRk021029; Wed, 1 May 2013 11:13:16 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id r41ADG8H021018; Wed, 1 May 2013 11:13:16 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: "Rushforth\, Peter" References: <1CD55F04538DEA4F85F3ADF7745464AF249DAECA@S-BSC-MBX1.nrn.nrcan.gc.ca> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Wed, 01 May 2013 11:13:16 +0100 In-Reply-To: <1CD55F04538DEA4F85F3ADF7745464AF249DAECA@S-BSC-MBX1.nrn.nrcan.gc.ca> (Peter Rushforth's message of "Tue\, 30 Apr 2013 19\:20\:53 +0000") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b32 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Getting 3023bis, a.k.a. draft-ietf-appsawg-xml-mediatypes, moving X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 May 2013 10:13:32 -0000 Rushforth, Peter writes: > Section 8. > > Suggest to remove the recommendation to register media types with +xml > suffix. Suggest to add recommendation for a 'profile' parameter for application/xml, > as is being done for atom : http://tools.ietf.org/html/draft-wilde-atom-profile-01 I have to say I'm not inclined to go that way. There is a _very_ large installed base, particularly of application/xhtml+xml and application/rdf+xml. There are around 100 registered application/xxx+xml media types registered _outside_ the vnd... sub-space, and another 200 or so there. We recently spent a lot of time getting both the general approach to registering structured suffixes and their uses [1] and using that approach to clean up / document existing practices [2], including the +xml case. Introducing an alternative profile-based approach at this point would just confuse things, IMO. > Suggest to remove reference to Appendix A. Remove Appendix A, > also. All of that stuff is not the business of this RFC, but is the > responsibility of the registration procedure, in my opinion. What do people think? Appendix A [3] is "Why Use the '+xml' Suffix for XML-Based MIME Types?" and is carried over nearly unchanged from RFC3023 [4]. Maybe it was needed 12 years ago but is no longer relevant/necessary/useful? > Suggest to remove discussion of hypertext linking. XML does not > include hypermedia affordances, so there is a disconnect between > what can be expected in application/xml vs. what is discussed in > this RFC. If an XML vocabulary contains XLinks, let that vocabulary > register its own media type. Also, relative to the discussion of > XLinks in that section, the web is not limited to XML documents > (heck they hardly even exist on the web), so perhaps XLink itself > needs an update to allow linking to non-XML representations. This comment regards a list in section 8 "A Naming Convention for XML-Based Media Types" [5] which is introduced as follows: Some areas where 'generic' processing is useful include: and has among 7 bullet points the following: * Browsing - An XML browser can display any XML document with a provided [CSS] or [XSLT] style sheet, whatever the vocabulary of that document. * Hypertext linking - [XLink] hypertext linking is designed to connect any XML documents, regardless of vocabulary. It seems to me these statements are both true, but the second is indeed weaker, because there are no generic XLink tools as far as I'm aware, and indeed it's not clear what they would be. I'm inclined to replace this with reference to a _different_ link-related standard, namely XInclude, for which generic support _does_ exist. Something along the line of * Transclusion - [XInclude] is designed to support transclusion of XML or text into arbitrary XML documents, regardless of vocabulary. Thanks for your input, ht [1] http://tools.ietf.org/html/rfc6838 [2] http://tools.ietf.org/html/rfc6839 [3] http://tools.ietf.org/html/draft-lilley-xml-mediatypes-00#appendix-A [4] http://tools.ietf.org/html/rfc3023#appendix-A [5] http://tools.ietf.org/html/draft-lilley-xml-mediatypes-00#section-8 [XInclude] http://www.w3.org/TR/xinclude/ -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From duerst@it.aoyama.ac.jp Wed May 1 05:14: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 6569C21F8EEA for ; Wed, 1 May 2013 05:14:02 -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 g9mrqDyUuENh for ; Wed, 1 May 2013 05:13:56 -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 CAFC821F908B for ; Wed, 1 May 2013 05:13: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 r41CDmcA004953; Wed, 1 May 2013 21:13:48 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 6199_d9e0_9428e208_b258_11e2_951f_001e6722eec2; Wed, 01 May 2013 21:13:48 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 23761C022D; Wed, 1 May 2013 21:13:17 +0900 (JST) Message-ID: <518106F0.1090001@it.aoyama.ac.jp> Date: Wed, 01 May 2013 21:13:36 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Henry S. Thompson" References: <1CD55F04538DEA4F85F3ADF7745464AF249DAECA@S-BSC-MBX1.nrn.nrcan.gc.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Getting 3023bis, a.k.a. draft-ietf-appsawg-xml-mediatypes, moving X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 May 2013 12:14:02 -0000 On 2013/05/01 19:13, Henry S. Thompson wrote: > Rushforth, Peter writes: > >> Section 8. >> >> Suggest to remove the recommendation to register media types with +xml >> suffix. Suggest to add recommendation for a 'profile' parameter for application/xml, >> as is being done for atom : http://tools.ietf.org/html/draft-wilde-atom-profile-01 > > I have to say I'm not inclined to go that way. There is a _very_ > large installed base, particularly of application/xhtml+xml and > application/rdf+xml. There are around 100 registered > application/xxx+xml media types registered _outside_ the > vnd... sub-space, and another 200 or so there. We recently spent a > lot of time getting both the general approach to registering > structured suffixes and their uses [1] and using that approach to > clean up / document existing practices [2], including the +xml case. > > Introducing an alternative profile-based approach at this point would > just confuse things, IMO. I fully agree. The proposal comes *extremely* late and without any justification. >> Suggest to remove reference to Appendix A. Remove Appendix A, >> also. All of that stuff is not the business of this RFC, but is the >> responsibility of the registration procedure, in my opinion. > > What do people think? Appendix A [3] is "Why Use the '+xml' Suffix > for XML-Based MIME Types?" and is carried over nearly unchanged from > RFC3023 [4]. Maybe it was needed 12 years ago but is no longer > relevant/necessary/useful? Yes. Please remove Appendix A, then add RFC 3023 as an informational reference and point to its Appendix A as "historical reading". More comments hopefully coming soon. Regards, Martin. From Peter.Rushforth@NRCan-RNCan.gc.ca Wed May 1 07:40: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 8D58C21F9D58 for ; Wed, 1 May 2013 07:40:46 -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 0AJ97AO7-fvb for ; Wed, 1 May 2013 07:40:41 -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 2266421F9D4D for ; Wed, 1 May 2013 07:40:40 -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; Wed, 1 May 2013 10:40:39 -0400 Received: from S-BSC-MBX1.nrn.nrcan.gc.ca ([169.254.1.97]) by S-BSC-CAS2.nrn.nrcan.gc.ca ([fe80::48d4:f168:78ba:d4e8%19]) with mapi id 14.02.0342.003; Wed, 1 May 2013 10:40:38 -0400 From: "Rushforth, Peter" To: "Henry S. Thompson" Thread-Topic: [apps-discuss] Getting 3023bis, a.k.a. draft-ietf-appsawg-xml-mediatypes, moving Thread-Index: AQHORlR+p5lvmsgOhkKRAnibf94qrZjwR3zw Date: Wed, 1 May 2013 14:40:38 +0000 Message-ID: <1CD55F04538DEA4F85F3ADF7745464AF249DD068@S-BSC-MBX1.nrn.nrcan.gc.ca> References: <1CD55F04538DEA4F85F3ADF7745464AF249DAECA@S-BSC-MBX1.nrn.nrcan.gc.ca> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.156.238.22] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Getting 3023bis, a.k.a. draft-ietf-appsawg-xml-mediatypes, moving X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 May 2013 14:40:46 -0000 =20 > -----Original Message----- > From: Henry S. Thompson [mailto:ht@inf.ed.ac.uk]=20 > Sent: May 1, 2013 06:13 > To: Rushforth, Peter > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Getting 3023bis, a.k.a.=20 > draft-ietf-appsawg-xml-mediatypes, moving >=20 > Rushforth, Peter writes: >=20 > > Section 8. > > > > Suggest to remove the recommendation to register media=20 > types with +xml=20 > > suffix. Suggest to add recommendation for a 'profile'=20 > parameter for=20 > > application/xml, as is being done for atom :=20 > > http://tools.ietf.org/html/draft-wilde-atom-profile-01 >=20 > I have to say I'm not inclined to go that way. There is a=20 > _very_ large installed base, particularly of=20 > application/xhtml+xml and application/rdf+xml. There are=20 > around 100 registered application/xxx+xml media types=20 > registered _outside_ the vnd... sub-space, and another 200 or=20 > so there. We recently spent a lot of time getting both the=20 > general approach to registering structured suffixes and their=20 > uses [1] and using that approach to clean up / document=20 > existing practices [2], including the +xml case. >=20 > Introducing an alternative profile-based approach at this=20 > point would just confuse things, IMO. Things are already confused, I think partly because of the +xml convention. The intent of using any parameter (not just the 'profile' parameter)=20 is to expose, without obscuring the type/subtype, while adding additional o= ptional=20 identifying characteristics to the media type. =20 I think that was actually the intent of the initial registration of the +xm= l=20 convention. I have used a content negotiation library [1] which does a nice job of ignoring or recognizing parameters as appropriate, but doesn't support +suffix in any way. Web browsers don't support the +xml convention either, so it seems that although it may be too late for those media types mentioned above, it is not too late for future media types to take advantage of standard facilities. In the end the mime type string is an identifier, so it won't hurt those media types above to continue being known as they are '+xml' and all, but it might be wiser to get future XML media type registrations off on the right track. [1] https://groups.google.com/forum/?fromgroups#!forum/mimeparse-dev >=20 > > Suggest to remove reference to Appendix A. Remove Appendix=20 > A, also.=20 > > All of that stuff is not the business of this RFC, but is the=20 > > responsibility of the registration procedure, in my opinion. >=20 > What do people think? Appendix A [3] is "Why Use the '+xml'=20 > Suffix for XML-Based MIME Types?" and is carried over nearly=20 > unchanged from > RFC3023 [4]. Maybe it was needed 12 years ago but is no=20 > longer relevant/necessary/useful? >=20 > > Suggest to remove discussion of hypertext linking. XML does not=20 > > include hypermedia affordances, so there is a disconnect=20 > between what=20 > > can be expected in application/xml vs. what is discussed in=20 > this RFC. =20 > > If an XML vocabulary contains XLinks, let that vocabulary=20 > register its=20 > > own media type. Also, relative to the discussion of XLinks in that=20 > > section, the web is not limited to XML documents (heck they hardly=20 > > even exist on the web), so perhaps XLink itself needs an update to=20 > > allow linking to non-XML representations. >=20 > This comment regards a list in section 8 "A Naming Convention=20 > for XML-Based Media Types" [5] which is introduced as follows: >=20 > Some areas where 'generic' processing is useful include: >=20 > and has among 7 bullet points the following: >=20 > * Browsing - An XML browser can display any XML document with a > provided [CSS] or [XSLT] style sheet, whatever the vocabulary of > that document. >=20 > * Hypertext linking - [XLink] hypertext linking is designed to > connect any XML documents, regardless of vocabulary. >=20 > It seems to me these statements are both true, but the second=20 > is indeed weaker, because there are no generic XLink tools as=20 > far as I'm aware, and indeed it's not clear what they would=20 > be. I'm inclined to replace this with reference to a=20 > _different_ link-related standard, namely XInclude, for which=20 > generic support _does_ exist. Something along the line of >=20 > * Transclusion - [XInclude] is designed to support transclusion of > XML or text into arbitrary XML documents, regardless of > vocabulary. Actually, my main point is that application/xml does not imply any of this processing, unless the registration for that media type (which is the subject of this draft, right?) explicitly calls out the applicable specifications as being implied. I don't *think* that is the intention of the registration. I *think* that=20 application/xml is intended to imply is what the least common denominator o= f what can be considered to be xml. So, for example, namespaces are not in s= cope. Nor is XLink, XInclude, etc etc etc. What is left? Very very limited application semantics, if I understand the intent of XML i.e. perhaps only what is implied by the proverbial "XML Proc= essor". Regards, Peter Rushforth= From ned.freed@mrochek.com Wed May 1 13:53: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 192EC21F99D8 for ; Wed, 1 May 2013 13:53:51 -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 W1+zPe304r7y for ; Wed, 1 May 2013 13:53:47 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id E904D21F99D6 for ; Wed, 1 May 2013 13:53:46 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OT4UR2EZTC0056F6@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 1 May 2013 13:48:40 -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 <01OT3BOFFH80000054@mauve.mrochek.com>; Wed, 1 May 2013 13:48:32 -0700 (PDT) Message-id: <01OT4UQWYK5M000054@mauve.mrochek.com> Date: Wed, 01 May 2013 13:44:47 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 01 May 2013 11:13:16 +0100" References: <1CD55F04538DEA4F85F3ADF7745464AF249DAECA@S-BSC-MBX1.nrn.nrcan.gc.ca> To: ht@inf.ed.ac.uk Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Getting 3023bis, a.k.a. draft-ietf-appsawg-xml-mediatypes, moving X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 May 2013 20:53:51 -0000 > Rushforth, Peter writes: > > Section 8. > > > > Suggest to remove the recommendation to register media types with +xml > > suffix. Suggest to add recommendation for a 'profile' parameter for application/xml, > > as is being done for atom : http://tools.ietf.org/html/draft-wilde-atom-profile-01 > I have to say I'm not inclined to go that way. There is a _very_ > large installed base, particularly of application/xhtml+xml and > application/rdf+xml. There are around 100 registered > application/xxx+xml media types registered _outside_ the > vnd... sub-space, and another 200 or so there. We recently spent a > lot of time getting both the general approach to registering > structured suffixes and their uses [1] and using that approach to > clean up / document existing practices [2], including the +xml case. > Introducing an alternative profile-based approach at this point would > just confuse things, IMO. I strongly agree. We're currently seeing a large number of registrations coming in and momentum seems to be building. The absolute last thing we should be doing is making changes that break that. We have seen the effect of such changes in the past; it was not good. Ned From rjsparks@nostrum.com Wed May 1 14:25: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 582F221F9B17; Wed, 1 May 2013 14:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-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 IRB0MOvvnSeN; Wed, 1 May 2013 14:25:38 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B888A21F9AF8; Wed, 1 May 2013 14:25:32 -0700 (PDT) Received: from unnumerable.local (mobile-166-147-079-070.mycingular.net [166.147.79.70]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r41LPQDV038848 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Wed, 1 May 2013 16:25:29 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <51818841.40601@nostrum.com> Date: Wed, 01 May 2013 16:25:21 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <5180E1D9.7010006@it.aoyama.ac.jp> In-Reply-To: <5180E1D9.7010006@it.aoyama.ac.jp> Content-Type: multipart/alternative; boundary="------------020701070407070009070109" Received-SPF: pass (shaman.nostrum.com: 166.147.79.70 is authenticated by a trusted mechanism) Cc: draft-sparks-genarea-imaparch.all@tools.ietf.org, IESG , Apps Area WG Subject: Re: [apps-discuss] Apps Area review of draft-sparks-genarea-imaparch-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: Wed, 01 May 2013 21:25:39 -0000 This is a multi-part message in MIME format. --------------020701070407070009070109 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 5/1/13 4:35 AM, "Martin J. Dürst" 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-sparks-genarea-imaparch-06 > Title: IMAP Access to IETF Email List Archives > Reviewer: Martin Dürst > Review Date: 2013/05/01 > > > Summary: There is one main issue that's unclear to me. Otherwise, the > draft is close to publication, but needs some additional work. > > Note: I'm not an IMAP expert, not even an IMAP user, and not somebody > the Apps Area would call an email expert, although I wrote RFC 5064 > and quite a bit of RFC 6068. So the comments here are mostly of > general nature. > > Main issue: It is totally unclear to me what the actual consequences > of this draft are if approved. It will be used as input to the development of a tool providing the capabilities described here. We are capturing input from the IETF participants on what that tool needs to do. We've followed this approach with several other documents - RFC6778 (the web-based email archive) - RFC6730 (for nomcom tools) - RFC6433 (milestones) - RFC6292 (charters) The document already says "This memo captures the requirements for providing a service that would allow such browsing and searching." Would it help to add "and it is intended as input to a later activity for the design and development of such a tool." and would that address your concern? Or is it fine as it was after seeing that other context? Whether this results in an IAOC funded project or is satisfied with volunteer effort is not something this document needs to discuss. > I could imagine any one of the following: > > - It's informational, so it doesn't have any standing, and is just a > wishlist, mostly just by the author. > - If and when it will be IESG-approved, it documents IETF consensus > on how to best implement IMAP-based access to mailing list archives > for the IETF should such access be desirable, but it does not > represent an IETF consensus to actually implement this (e.g. because > that needs money, and money doesn't move by IETF consensus). > - If and when it will be IESG-approved, it documents IETF consensus that > IMAP-based access to IETF mailing lists is desirable, and should be > implemented asap (assuming somebody can come up with the necessary > resources). > - An informal mixture of the above: Those in the know agree it's a good > idea, but somebody said they need a document that can be referenced in > an RFP. > > While I'm personally okay with any of the above (I won't use this kind > of access in the near future, but can understand that many people are > using IMAP and it would be pretty handy to have such a feature; also I > won't have to pay for it), I think the fact that this unclarity exists > may make it difficult for others to review the draft. > > So I suggest that this be clarified. Unless it's just me who's unclear > on this issue, it may get close to meriting a new or prolonged last call. That will be for Jari to judge, but as I point out above, we've followed this pattern, using the language in this draft before. > > > Minor issue: The draft should reference RFC 6855 (IMAP Support for > UTF-8) and require its support *at least* to the extent that RFC 6778 > does (see http://tools.ietf.org/html/rfc6778#section-3). I will work to sew in a reference to 6855 > > > Editorial/Nits: > > o The interface must allow administrators to disable setting read/ > unread marks and other annotations, and delete any such marks or > annotations on a per user basis. > > It's unclear how far back "on a per user basis" applies. > Also, "the interface" means "an IMAP interface" (first bullet point), > but it may not be possible or practical to have administrators use > IMAP itself for this function. So I suggest something along the > following lines: > > o It must be possible for administrators, on a per-user basis, to > disable setting read/unread marks and other annotations and to > delete any such marks or annotations. I'll fold this suggestion in. > > > "and should support multiple simultaneous extensive searches.": Is > this simultaneous searches by the same user, or by different users? I > suspect the later. If so, the clause should be rewritten so that it is > clear that this is a dimensioning requirement, not a functionality > requirement. I think it's _both_, not one or the other. I will attempt to clarify. > > "The server should facilitate the enhanced search capabilities > described in [RFC6778].": It is unclear what "facilitate" means here. > Technology usually implements something or doesn't; facilitate sounds > quite fuzzy. Although RFC 6778 is informational, it uses quite a bit > of 'must',... On the other hand, IMAP may or may not support some of > the queries listed as a 'must' in RFC 6778. Would "provide" work better for you than "facilitate"? > > > "(But it is acceptable for a user to access such archives while > providing credentials).": Don't start a sentence with 'But' (use > 'However'). Also, please put the final period inside the parentheses. I will remove the But, and leave ). vs .) to the RFC Editor. > > "an LOGIN command" -> "a LOGIN command" Thanks - will fix. > > "determined by the administrator ." -> "determined by the administrator." > > "local copies all messages" -> "local copies of all messages" > > "maliciously crafted searches attempting to consume all available > resources" -> "maliciously crafted searches attempting to consume > significant available resources" (there is no need to consume all > resources to result in significant DOS problems) > > " maliciously crafted annontations attempting to consume all storage > space" -> " maliciously crafted annontations attempting to consume > significant storage space" Will fix all those. > > "The implementers should consider making it easy for the administrator > to determine which users are consuming exceptional space.": > "exceptional space" -> "exceptional amounts of space"; I also think > "should consider" is rather too weak, and "easy to determine" seems to > imply that administrators will have to actively check this (rather > than getting alerts when something fishy starts). The language is intended to leave latitude for design. Forcing administrators to poll would not satisfy "making it easy". I will try to make that clearer. > This may be just an implementation detail, but it may be a good idea > to note that flag implementation (and annotation implementation if an > annotation can be applied by the user to more than one message at > once) has to be quite clever because otherwise, even benign use might > use up lots of space. As an example, if the system allocates 4 bytes > for each message in the system for each user that logs into the system > even once, that may already create huge storage demands. I will look at calling this out. However, there are many bad things that an implementation _could_ do, and calling them all out is not needed here. Things like this would get caught at design review or as source comes in. (You can get the source for the running datatracker - see the codesprint pages if you don't already know how). Such bad design will be caught. Good designs are often improved at codesprints. > > Regards, Martin. > > > --------------020701070407070009070109 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 5/1/13 4:35 AM, "Martin J. Dürst" 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-sparks-genarea-imaparch-06
Title: IMAP Access to IETF Email List Archives
Reviewer: Martin Dürst
Review Date: 2013/05/01


Summary: There is one main issue that's unclear to me. Otherwise, the draft is close to publication, but needs some additional work.

Note: I'm not an IMAP expert, not even an IMAP user, and not somebody the Apps Area would call an email expert, although I wrote RFC 5064 and quite a bit of RFC 6068. So the comments here are mostly of general nature.

Main issue: It is totally unclear to me what the actual consequences of this draft are if approved.

It will be used as input to the development of a tool providing the capabilities described here.

We are capturing input from the IETF participants on what that tool needs to do.

We've followed this approach with several other documents
- RFC6778 (the web-based email archive)
- RFC6730 (for nomcom tools)
- RFC6433 (milestones)
- RFC6292 (charters)

The document already says
"This memo captures the
   requirements for providing a service that would allow such browsing
   and searching."

Would it help to add "and it is intended as input to a later activity for the design and development of such a tool." and would that address your concern? Or is it fine as it was after seeing that other context?

Whether this results in an IAOC funded project or is satisfied with volunteer effort is not something this document needs to discuss.


I could imagine any one of the following:

- It's informational, so it doesn't have any standing, and is just a
  wishlist, mostly just by the author.
- If and when it will be IESG-approved, it documents IETF consensus
  on how to best implement IMAP-based access to mailing list archives
  for the IETF should such access be desirable, but it does not
  represent an IETF consensus to actually implement this (e.g. because
  that needs money, and money doesn't move by IETF consensus).
- If and when it will be IESG-approved, it documents IETF consensus that
  IMAP-based access to IETF mailing lists is desirable, and should be
  implemented asap (assuming somebody can come up with the necessary
  resources).
- An informal mixture of the above: Those in the know agree it's a good
  idea, but somebody said they need a document that can be referenced in
  an RFP.

While I'm personally okay with any of the above (I won't use this kind of access in the near future, but can understand that many people are using IMAP and it would be pretty handy to have such a feature; also I won't have to pay for it), I think the fact that this unclarity exists may make it difficult for others to review the draft.

So I suggest that this be clarified. Unless it's just me who's unclear on this issue, it may get close to meriting a new or prolonged last call.
That will be for Jari to judge, but as I point out above, we've followed this pattern, using the language in this draft before.


Minor issue: The draft should reference RFC 6855 (IMAP Support for UTF-8) and require its support *at least* to the extent that RFC 6778 does (see http://tools.ietf.org/html/rfc6778#section-3).
I will work to sew in a reference to 6855


Editorial/Nits:

 o  The interface must allow administrators to disable setting read/
    unread marks and other annotations, and delete any such marks or
    annotations on a per user basis.

It's unclear how far back "on a per user basis" applies.
Also, "the interface" means "an IMAP interface" (first bullet point), but it may not be possible or practical to have administrators use IMAP itself for this function. So I suggest something along the following lines:

 o  It must be possible for administrators, on a per-user basis, to
    disable setting read/unread marks and other annotations and to
    delete any such marks or annotations.
I'll fold this suggestion in.


"and should support multiple simultaneous extensive searches.": Is this simultaneous searches by the same user, or by different users? I suspect the later. If so, the clause should be rewritten so that it is clear that this is a dimensioning requirement, not a functionality requirement.
I think it's _both_, not one or the other. I will attempt to clarify.

"The server should facilitate the enhanced search capabilities described in [RFC6778].": It is unclear what "facilitate" means here. Technology usually implements something or doesn't; facilitate sounds quite fuzzy. Although RFC 6778 is informational, it uses quite a bit of 'must',... On the other hand, IMAP may or may not support some of the queries listed as a 'must' in RFC 6778.
Would "provide" work better for you than "facilitate"?


"(But it is acceptable for a user to access such archives while providing credentials).": Don't start a sentence with 'But' (use 'However'). Also, please put the final period inside the parentheses.
I will remove the But, and leave ). vs .) to the RFC Editor.

"an LOGIN command" -> "a LOGIN command"
Thanks - will fix.

"determined by the administrator ." -> "determined by the administrator."

"local copies all messages" -> "local copies of all messages"

"maliciously crafted searches attempting to consume all available resources" -> "maliciously crafted searches attempting to consume significant available resources" (there is no need to consume all resources to result in significant DOS problems)

" maliciously crafted annontations attempting to consume all storage space" -> " maliciously crafted annontations attempting to consume significant storage space"
Will fix all those.

"The implementers should consider making it easy for the administrator to determine which users are consuming exceptional space.": "exceptional space" -> "exceptional amounts of space"; I also think "should consider" is rather too weak, and "easy to determine" seems to imply that administrators will have to actively check this (rather than getting alerts when something fishy starts).
The language is intended to leave latitude for design. Forcing administrators to poll would not satisfy "making it easy".
I will try to make that clearer.

This may be just an implementation detail, but it may be a good idea to note that flag implementation (and annotation implementation if an annotation can be applied by the user to more than one message at once) has to be quite clever because otherwise, even benign use might use up lots of space. As an example, if the system allocates 4 bytes for each message in the system for each user that logs into the system even once, that may already create huge storage demands.
I will look at calling this out. However, there are many bad things that an implementation _could_ do, and calling them all out is not needed here. Things like this would get caught at design review or as source comes in. (You can get the source for the running datatracker - see the codesprint pages if you don't already know how). Such bad design will be caught. Good designs are often improved at codesprints.

Regards,   Martin.




--------------020701070407070009070109-- From barryleiba@gmail.com Wed May 1 15:05: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 6F13821F9B35; Wed, 1 May 2013 15:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.067 X-Spam-Level: X-Spam-Status: No, score=-103.067 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 GqvhL65jHXqk; Wed, 1 May 2013 15:05:53 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4E06621F9B21; Wed, 1 May 2013 15:05:47 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id v5so1844553lbc.18 for ; Wed, 01 May 2013 15:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=OQHpfltSqCQiTdNZPxq1qVZzZL2636rYu01IXXfL6Kg=; b=YSlH5uf5bROcZHpJQf4/9nhPLetcmzpEmhR9SvajZQUUlroL80pn3onuRDbj/Yy3Z+ s9N2O6aLXKRj2eV6iXRL4MdLPKnm/9nh7VfGNXZObdD0GuNR06D0Uhxq6HYktDbklpaL 7B7CrlXy/KZxN+Adgrk20ZCDdvF/xViGmYPmDDC0owAMOqVEeCKjgm4+thQ0WtWckY7h qE3fxQ2LGVowpBoUXYmeEy8b+eWrJ1sQc3lybIgkI9eUmWwRUB9GpygCePWRZ1V36Zj9 qiaYWDSL/EMBqWOOEdBUZyx1QHkySiaijnph/pE0m3K/BKU+FBL3P+DAjz2+WHWUJFF8 S8rQ== MIME-Version: 1.0 X-Received: by 10.112.138.5 with SMTP id qm5mr1793553lbb.2.1367445946166; Wed, 01 May 2013 15:05:46 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.112.117.225 with HTTP; Wed, 1 May 2013 15:05:46 -0700 (PDT) In-Reply-To: <51818841.40601@nostrum.com> References: <5180E1D9.7010006@it.aoyama.ac.jp> <51818841.40601@nostrum.com> Date: Wed, 1 May 2013 18:05:46 -0400 X-Google-Sender-Auth: LY9NqgfFaNMdUwWOmONq1Enu9OY Message-ID: From: Barry Leiba To: Robert Sparks Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-sparks-genarea-imaparch.all@tools.ietf.org, Apps Area WG , IESG Subject: Re: [apps-discuss] Apps Area review of draft-sparks-genarea-imaparch-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: Wed, 01 May 2013 22:05:57 -0000 Hi, Robert (and Martin). A couple of notes here: > Minor issue: The draft should reference RFC 6855 (IMAP Support for UTF-8) > and require its support *at least* to the extent that RFC 6778 does (see > http://tools.ietf.org/html/rfc6778#section-3). > > I will work to sew in a reference to 6855 It's probably best to note that "support for 6855 is desirable," and not really anything more than that. Let's also remember that there's not really any deployment of 6855 support yet, in clients or servers. > "and should support multiple simultaneous extensive searches.": Is this > simultaneous searches by the same user, or by different users? I suspect the > later. If so, the clause should be rewritten so that it is clear that this > is a dimensioning requirement, not a functionality requirement. > > I think it's _both_, not one or the other. I will attempt to clarify. Be careful here: In IMAP terms, what mostly matters is the session, not the user (but see below). It's theoretically possible for an IMAP server to run multiple searches in the same session in parallel without multimailbox search (RFC 6237), but it's not practical for a number of reasons, and isn't supported by any IMAP servers I'm aware of. And there's already a reference to 6237 later in the paragraph. IMAP servers already do have to deal with multiple sessions for the same user, and it's well know that limits might need to be put on that: how many sessions one user can log in with, and how many resources those sessions can consume. This document shouldn't be trying to deal with standard advice for things all IMAP servers need to consider. I take the sentence in question to address capacity, not function. If anything here needs clarification, it's that. I don't think it makes sense for this bullet to go into details of sessions vs users vs anything else. > "(But it is acceptable for a user to access such archives while providing > credentials).": Don't start a sentence with 'But' (use 'However'). Also, > please put the final period inside the parentheses. > > I will remove the But, and leave ). vs .) to the RFC Editor. Wrong direction, but only a minor point: 1. There's absolutely nothing wrong with beginning a sentence with a conjunction; please don't let yourself be pushed on that point. 2. That said, in this case the conjunction adds nothing. So, yes, just "But" out. 3. On the other hand, when parentheses contain a complete sentence, the period does need to be inside the parentheses. Absolutely. And, yes, the RFC Editor will fix all of that.[1] Barry [1] Yes, I know. I did it earlier in the message also, and I bet you didn't notice. From internet-drafts@ietf.org Wed May 1 20:22: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 1697821F9A72; Wed, 1 May 2013 20:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.041, 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 Vmy7MbAkLo8Y; Wed, 1 May 2013 20:22:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D42E21F9A46; Wed, 1 May 2013 20:22:26 -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.44.p4 Message-ID: <20130502032226.5760.2800.idtracker@ietfa.amsl.com> Date: Wed, 01 May 2013 20:22:26 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 03:22:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : The 'acct' URI Scheme Author(s) : Peter Saint-Andre Filename : draft-ietf-appsawg-acct-uri-04.txt Pages : 9 Date : 2013-05-01 Abstract: This document defines the 'acct' Uniform Resource Identifier (URI) scheme as a way to identify a user's account at a service provider, irrespective of the particular protocols that can be used to interact with the account. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-acct-uri There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-acct-uri-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stpeter@stpeter.im Wed May 1 20:24: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 9700621F85CB for ; Wed, 1 May 2013 20:24:08 -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 IMxCyrZK+Cmt for ; Wed, 1 May 2013 20:24:03 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E2C5321F85BF for ; Wed, 1 May 2013 20:24:03 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 98C3D4001C for ; Wed, 1 May 2013 21:35:21 -0600 (MDT) Message-ID: <5181DC52.6070901@stpeter.im> Date: Wed, 01 May 2013 21:24:02 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20130502032226.5760.2800.idtracker@ietfa.amsl.com> In-Reply-To: <20130502032226.5760.2800.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 03:24:08 -0000 Fixes to address IESG feedback... On 5/1/13 9:22 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Applications Area Working Group Working Group of the IETF. > > Title : The 'acct' URI Scheme > Author(s) : Peter Saint-Andre > Filename : draft-ietf-appsawg-acct-uri-04.txt > Pages : 9 > Date : 2013-05-01 > > Abstract: > This document defines the 'acct' Uniform Resource Identifier (URI) > scheme as a way to identify a user's account at a service provider, > irrespective of the particular protocols that can be used to interact > with the account. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-acct-uri > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-acct-uri-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From rjsparks@nostrum.com Thu May 2 07:56: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 6AEF221F84B2; Thu, 2 May 2013 07:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-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 IsUA5mPT34gS; Thu, 2 May 2013 07:56:17 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4B29A21F86B1; Thu, 2 May 2013 07:56:17 -0700 (PDT) Received: from unnumerable.local (pool-173-57-99-236.dllstx.fios.verizon.net [173.57.99.236]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r42Eu7bo058261 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Thu, 2 May 2013 09:56:07 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <51827E89.6040203@nostrum.com> Date: Thu, 02 May 2013 09:56:09 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Barry Leiba References: <5180E1D9.7010006@it.aoyama.ac.jp> <51818841.40601@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000200030601060503060806" Received-SPF: pass (shaman.nostrum.com: 173.57.99.236 is authenticated by a trusted mechanism) Cc: draft-sparks-genarea-imaparch.all@tools.ietf.org, Apps Area WG , IESG Subject: Re: [apps-discuss] Apps Area review of draft-sparks-genarea-imaparch-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, 02 May 2013 14:56:18 -0000 This is a multi-part message in MIME format. --------------000200030601060503060806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/1/13 5:05 PM, Barry Leiba wrote: > Hi, Robert (and Martin). A couple of notes here: > >> Minor issue: The draft should reference RFC 6855 (IMAP Support for UTF-8) >> and require its support *at least* to the extent that RFC 6778 does (see >> http://tools.ietf.org/html/rfc6778#section-3). >> >> I will work to sew in a reference to 6855 > It's probably best to note that "support for 6855 is desirable," and > not really anything more than that. Let's also remember that there's > not really any deployment of 6855 support yet, in clients or servers. Any reason to not just copy what we put in 6778 with minor tweaks? 3. Internationalized Address Considerations The implementation should anticipate internationalized email addresses as discussed in the following three documents -- [RFC6531], [RFC6532], and [RFC6855]. There is no firm requirement at this time. > >> "and should support multiple simultaneous extensive searches.": Is this >> simultaneous searches by the same user, or by different users? I suspect the >> later. If so, the clause should be rewritten so that it is clear that this >> is a dimensioning requirement, not a functionality requirement. >> >> I think it's _both_, not one or the other. I will attempt to clarify. > Be careful here: > In IMAP terms, what mostly matters is the session, not the user (but > see below). It's theoretically possible for an IMAP server to run > multiple searches in the same session in parallel without multimailbox > search (RFC 6237), but it's not practical for a number of reasons, and > isn't supported by any IMAP servers I'm aware of. And there's already > a reference to 6237 later in the paragraph. > > IMAP servers already do have to deal with multiple sessions for the > same user, and it's well know that limits might need to be put on > that: how many sessions one user can log in with, and how many > resources those sessions can consume. This document shouldn't be > trying to deal with standard advice for things all IMAP servers need > to consider. > > I take the sentence in question to address capacity, not function. If > anything here needs clarification, it's that. I don't think it makes > sense for this bullet to go into details of sessions vs users vs > anything else. I think you're arguing for not changing the text? I've taken a stab at punching up "capacity". There wasn't anything obvious. Does this help (I don't really think it does, but haven't come up with anything better): The interface must have server-side searching enabled, and should scale to support multiple simultaneous extensive searches. The server should provide the enhanced search capabilities described in . The implementation should consider taking advantage of the extensions defined for IMAP SORT and THREAD , multimailbox search , and fuzzy search . --------------000200030601060503060806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 5/1/13 5:05 PM, Barry Leiba wrote:
Hi, Robert (and Martin).  A couple of notes here:


Minor issue: The draft should reference RFC 6855 (IMAP Support for UTF-8)
and require its support *at least* to the extent that RFC 6778 does (see
http://tools.ietf.org/html/rfc6778#section-3).

I will work to sew in a reference to 6855

It's probably best to note that "support for 6855 is desirable," and
not really anything more than that.  Let's also remember that there's
not really any deployment of 6855 support yet, in clients or servers.
Any reason to not just copy what we put in 6778 with minor tweaks?
3.  Internationalized Address Considerations

   The implementation should anticipate internationalized
   email addresses as discussed in the following three documents --
   [RFC6531], [RFC6532], and [RFC6855].  There is no firm requirement
   at this time.



"and should support multiple simultaneous extensive searches.": Is this
simultaneous searches by the same user, or by different users? I suspect the
later. If so, the clause should be rewritten so that it is clear that this
is a dimensioning requirement, not a functionality requirement.

I think it's _both_, not one or the other. I will attempt to clarify.

Be careful here:
In IMAP terms, what mostly matters is the session, not the user (but
see below).  It's theoretically possible for an IMAP server to run
multiple searches in the same session in parallel without multimailbox
search (RFC 6237), but it's not practical for a number of reasons, and
isn't supported by any IMAP servers I'm aware of.  And there's already
a reference to 6237 later in the paragraph.

IMAP servers already do have to deal with multiple sessions for the
same user, and it's well know that limits might need to be put on
that: how many sessions one user can log in with, and how many
resources those sessions can consume.  This document shouldn't be
trying to deal with standard advice for things all IMAP servers need
to consider.

I take the sentence in question to address capacity, not function.  If
anything here needs clarification, it's that.  I don't think it makes
sense for this bullet to go into details of sessions vs users vs
anything else.

I think you're arguing for not changing the text?
I've taken a stab at punching up "capacity". There wasn't anything obvious.
Does this help (I don't really think it does, but haven't come up with anything better):

<t hangText="o">
The interface must have server-side searching enabled, and should scale to support multiple simultaneous extensive searches.  The server should provide the enhanced search capabilities described in <xref target="RFC6778"/>.   The implementation should consider taking advantage of the extensions defined for IMAP SORT and THREAD  <xref target="RFC5256"/>, multimailbox search <xref target="RFC6237"/>, and fuzzy search <xref target="RFC6203"/>.</t>

--------------000200030601060503060806-- From j.schoenwaelder@jacobs-university.de Thu May 2 00:42: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 4E27D21F8501; Thu, 2 May 2013 00:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 AaTLY0QCoFSg; Thu, 2 May 2013 00:42:02 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E192121F84FD; Thu, 2 May 2013 00:42:01 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DEC3720C54; Thu, 2 May 2013 09:42:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id B37oqpB-mZLQ; Thu, 2 May 2013 09:42:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 468F020C4B; Thu, 2 May 2013 09:42:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E440025EE922; Thu, 2 May 2013 09:41:57 +0200 (CEST) Date: Thu, 2 May 2013 09:41:57 +0200 From: Juergen Schoenwaelder To: Martin Thomson Message-ID: <20130502074157.GA4935@elstar.local> Mail-Followup-To: Martin Thomson , IETF Apps Discuss , draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, The IESG , netmod@ietf.org References: <6.2.5.6.2.20130428233426.0b62fed0@elandnews.com> <20130430083206.GD46852@elstar.local> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Thu, 02 May 2013 09:16:32 -0700 Cc: draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, netmod@ietf.org, The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] [appsdir] Fwd: APPSDIR review of draft-ietf-netmod-rfc6021-bis-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 07:42:07 -0000 --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Apr 30, 2013 at 12:29:02PM -0700, Martin Thomson wrote: > One meta-comment. I don't consider the contents of RFC 6021 to have > any bearing on the review of this document. I'm not familiar with > 6021, so I consider all of this to be new. But most of the definitions are not new and I am reluctant to make changes to published RFC text. [...] > > ipv6 pattern > > Note sure what the "official" ABNF definition is but we believe that > > the two pattern are correct. So far nobody was able to find a case > > that was not properly accepted by the pattern. You are welcome to try > > to find something where our two pattern break. ;-) > > Sorry, "official" is my shorthand for saying: there is an RFC out > there that defines this ABNF but I was too lazy to go and look for it > because I know that chances are I will find the wrong one. > > The first pattern is overly restrictive, I think (only double colon at > the start?). The second is definitely overly permissive. > This:sentence:is::actually:valid. (I think). Please give me an example of an IPv6 address that the ipv6-address pattern does not handle so we have something concrete to talk about. I am appending some test cases to make it easier for you to find one. If you mean by "second" the ipv6-address-no-zone typedef, please see my response to Joel. This is a type derived from ipv6-address. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ipv6-gen.py" import libxml2 ip6_pat1 = \ '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' \ + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' \ + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' \ + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' \ + '(%[\p{N}\p{L}]+)?' ip6_pat2 = \ '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' \ + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' \ + '(%.+)?' ip6_re1 = libxml2.regexpCompile(ip6_pat1) ip6_re2 = libxml2.regexpCompile(ip6_pat2) pfx_pat1 = \ '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}' \ + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|' \ + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}' \ + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))' \ + '(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))' pfx_pat2 = \ '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|' \ + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)' \ + '(/.+)' pfx_re1 = libxml2.regexpCompile(pfx_pat1) pfx_re2 = libxml2.regexpCompile(pfx_pat2) ip6_good = ['ABCD:EF01:2345:6789:ABCD:EF01:2345:6789', '2001:DB8:0:0:8:800:200C:417A', 'FF01:0:0:0:0:0:0:101', '0:0:0:0:0:0:0:1', '0:0:0:0:0:0:0:0', '2001:DB8::8:800:200C:417A', 'FF01::101', '::1', '::', '0:0:0:0:0:0:13.1.68.3', '0:0:0:0:0:FFFF:129.144.52.38', '::13.1.68.3', '::FFFF:129.144.52.38', '1:2:3:4:5:6:7::', '::1:2:3:4:5:6:7', '::1%eth0', '::1%42', '::1%en1'] ip6_bad = ['::1::', '::FFFF:1.2.3.4.5', '1:2:3:4:5:6:7:8:9' '::1%', '::1%*', '::1%-1'] pfx_good = ['ABCD:EF01:2345:6789:ABCD:EF01:2345:6789/48', '2001:DB8:0:0:8:800:200C:417A/0', 'FF01:0:0:0:0:0:0:101/128', '0:0:0:0:0:0:0:1/1', '0:0:0:0:0:0:0:0/123', '2001:DB8::8:800:200C:417A/8', 'FF01::101/64', '::1/64', '::/64', '0:0:0:0:0:0:13.1.68.3/64', '0:0:0:0:0:FFFF:129.144.52.38/64', '::13.1.68.3/64', '::FFFF:129.144.52.38/64', '1:2:3:4:5:6:7::/64', '::1:2:3:4:5:6:7/64'] pfx_bad = ['::1::/48', '::FFFF:1.2.3.4.5/48', '1:2:3:4:5:6:7:8:9/48', '::1/-1', '::1/a', '::1/129', '::1/1234', '::1/+12' ] for ip in ip6_good: if ip6_re1.regexpExec(ip) != 1: print "** ipv6 pattern #1 fails on %s" % ip if ip6_re2.regexpExec(ip) != 1: print "** ipv6 pattern #2 fails on %s" % ip for ip in ip6_bad: if ip6_re1.regexpExec(ip) != 1: continue if ip6_re2.regexpExec(ip) != 1: continue print "** ipv6 pattern fail to reject %s" % ip for ip in pfx_good: if pfx_re1.regexpExec(ip) != 1: print "** pfx pattern #1 fails on %s" % ip if pfx_re2.regexpExec(ip) != 1: print "** pfx pattern #2 fails on %s" % ip for ip in pfx_bad: if pfx_re1.regexpExec(ip) != 1: continue if pfx_re2.regexpExec(ip) != 1: continue print "** pfx pattern fail to reject %s" % ip --pWyiEgJYm5f9v55/-- From markus.lanthaler@gmx.net Thu May 2 11:46: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 63C1221F8EF7 for ; Thu, 2 May 2013 11:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfmgjsNw-F1U for ; Thu, 2 May 2013 11:46:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5057D21F8EC2 for ; Thu, 2 May 2013 11:46:35 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.33]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M7WSv-1ULVui3PZH-00xL0Y for ; Thu, 02 May 2013 20:46:31 +0200 Received: (qmail invoked by alias); 02 May 2013 18:46:31 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp033) with SMTP; 02 May 2013 20:46:31 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1/r/ilxUu/r6pOExnnHjkt2f2BsppGpJHq14i8iiQ jdJE9WXD5bo+2y From: "Markus Lanthaler" To: "'Dave Cridland'" , "'Barry Leiba'" , "'Murray S. Kucherawy'" References: <516e8a54.45f7440a.7dcc.1253SMTPIN_ADDED_BROKEN@mx.google.com> <516f06c9.c1c20e0a.46f3.ffffb0bfSMTPIN_ADDED_BROKEN@mx.google.com> <51782a0a.21f2440a.747e.5f13SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Thu, 2 May 2013 20:46:24 +0200 Message-ID: <00c501ce4765$5b28e9c0$117abd40$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5BIphJtMVGw7jgQvmsEeZ7lnBCsgGQm/lg Content-Language: de X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] FW: New Version Notification for draft-lanthaler-profile-registry-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 18:46:41 -0000 On Wednesday, April 24, 2013 9:33 PM, Dave Cridland wrote: > Oh, sorry. > I've no objections. The work seems to be needed, if I understand > the situation correctly, and would appear to be within the working > group's remit. > It's not really my field, but I'm happy to devote a cycle or two > for reviewing. Thanks for your your support Dave. Barry, Murray: How do we proceed? Is there anything I can/should do at this point? Thanks, Markus -- Markus Lanthaler @markuslanthaler From martin.thomson@gmail.com Thu May 2 13:28: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 3200821F8D29; Thu, 2 May 2013 13:28:48 -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 Qha1eId8s4b2; Thu, 2 May 2013 13:28:47 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 35D3721F8D0D; Thu, 2 May 2013 13:28:47 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hq12so100207wib.3 for ; Thu, 02 May 2013 13:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=bYg6sAu59InJ6FBOrFPc2w7FzSdkRnBWrAQtXFUvsY4=; b=V6+NNQy9SZ7upLOp5juKuA0YHSpIubsXeReVJXf0XpGGaHhRcAETjHBtoZtjOIZcNE onui89fqyx3M670OGqv3h15YoL6fhNshgdrEURvfFIyAKKHasZbiIPhpURrkh+BSAV/a i8Oanjm5XkrjvjM5/OUZ1cMiTSDHfKdapj6NzWXpC+DrgxwmX0YHzwfoRE1yo1ItGWPE TIlCsAI/bgGygbAcyj6IIJnnCV52pU0V+Clkaoou1hX955Jdxe/jzb5wFA7FaKWAuO27 Fn1LDqr6jhYD4+pGJL1uBgNf4dVSQEEnC3iJU8yFa4VWkJ+Xv60TEBcfH018+FHqFiWR TiPQ== MIME-Version: 1.0 X-Received: by 10.180.83.199 with SMTP id s7mr9931501wiy.19.1367526526427; Thu, 02 May 2013 13:28:46 -0700 (PDT) Received: by 10.194.33.102 with HTTP; Thu, 2 May 2013 13:28:46 -0700 (PDT) In-Reply-To: <20130502074157.GA4935@elstar.local> References: <6.2.5.6.2.20130428233426.0b62fed0@elandnews.com> <20130430083206.GD46852@elstar.local> <20130502074157.GA4935@elstar.local> Date: Thu, 2 May 2013 13:28:46 -0700 Message-ID: From: Martin Thomson To: Juergen Schoenwaelder , Martin Thomson , IETF Apps Discuss , draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, The IESG , netmod@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [apps-discuss] [appsdir] Fwd: APPSDIR review of draft-ietf-netmod-rfc6021-bis-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2013 20:28:48 -0000 On 2 May 2013 00:41, Juergen Schoenwaelder wrote: > On Tue, Apr 30, 2013 at 12:29:02PM -0700, Martin Thomson wrote: >> One meta-comment. I don't consider the contents of RFC 6021 to have >> any bearing on the review of this document. I'm not familiar with >> 6021, so I consider all of this to be new. > > But most of the definitions are not new and I am reluctant to make > changes to published RFC text. I thought that was the purpose of revising an RFC. If you were just looking to add types, an update might be more appropriate. > If you mean by "second" the ipv6-address-no-zone typedef, please see > my response to Joel. This is a type derived from ipv6-address. Ahh, both patterns apply. My mistake; I had assumed OR (like XML schema), not AND. Interesting approach. From dret@berkeley.edu Thu May 2 13:51: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 4AF4521F8E06 for ; Thu, 2 May 2013 13:51:24 -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 MHpZlH9lh6d4 for ; Thu, 2 May 2013 13:51:20 -0700 (PDT) Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4D221F8CE2 for ; Thu, 2 May 2013 13:51:20 -0700 (PDT) Received: from 24-119-110-161.cpe.cableone.net ([24.119.110.161] helo=dretair.local) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1UY0TG-0005WT-Gw for apps-discuss@ietf.org; Thu, 02 May 2013 13:51:19 -0700 Message-ID: <5182D1C4.3040908@berkeley.edu> Date: Thu, 02 May 2013 13:51:16 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "apps-discuss@ietf.org application-layer protocols" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] procedural question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2013 20:51:24 -0000 hello. i have a question about procedural issues: i have three drafts that i would like to enter into a formal review process. since these drafts are individual submissions, the question (that i have faced before) always is how to make the transition from individually posting and discussing the drafts, to this more formal process. the current drafts i have been working on (and which i believe are ready to enter the formal path to RFCness) are: http://tools.ietf.org/html/draft-wilde-xml-patch-04 http://tools.ietf.org/html/draft-hausenblas-csv-fragment-02 http://tools.ietf.org/html/draft-sinnema-xacml-media-type-02 with my previous drafts i always was lucky to have somebody shepherding them, but it was always a lucky coincidence to find somebody willing to do it. the question i have is how to approach this in a way so that i can make this transition from individual drafts to the formal process more predictable. are there any recommendations or guidance i could turn to? is there a different forum i should ask for this? thanks a lot for your help and kind regards, 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 superuser@gmail.com Thu May 2 15:18: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 0A94F21F8CE2 for ; Thu, 2 May 2013 15:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.409 X-Spam-Level: X-Spam-Status: No, score=-1.409 tagged_above=-999 required=5 tests=[AWL=-0.476, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ek2SLgB2Xodn for ; Thu, 2 May 2013 15:18:07 -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 6C0D521F8B38 for ; Thu, 2 May 2013 15:18:00 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id m6so89425wiv.9 for ; Thu, 02 May 2013 15:17:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3mY+XpEYFf/YWlUZcsaPv6qEbYRT9JtZL/AC9LgaLHQ=; b=uqLbM+UGeGTjHyebBtv+pnub85VOgaTNYO8vpTyA2uK+rKarf3CuvUMYcEBphQ7GEa Xx9UglaG8GG+WYDtW3t1F0Y3sZxoBSZ1r1OIlOXMiPEfBc61vp7WlfDQ05chSg1r7eQy 8m/1A5U/GK7sEWLCnzHssyLeCp1SV1QZBqcrEvo1Myo9ni+dvuFdE7Rpwo5/mza6PpNf 20Lw3CzR5xKdMwOB6XbR3wJe0yooDf436Lx/4MpZ9b0u3EqfAy1bnbybvcJydC85wInl BdTw0s5s8D2VicGAYLywAZLQuHHu+nQXxNDyi/RaGP2f2fPIXeJjdDoJPB2MfFXU5Bd9 xlYg== MIME-Version: 1.0 X-Received: by 10.194.93.68 with SMTP id cs4mr10708845wjb.17.1367533079574; Thu, 02 May 2013 15:17:59 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Thu, 2 May 2013 15:17:59 -0700 (PDT) In-Reply-To: <5182D1C4.3040908@berkeley.edu> References: <5182D1C4.3040908@berkeley.edu> Date: Thu, 2 May 2013 15:17:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: Erik Wilde Content-Type: multipart/alternative; boundary=047d7b5d8cff6d3e1104dbc39b72 Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] procedural question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 May 2013 22:18:08 -0000 --047d7b5d8cff6d3e1104dbc39b72 Content-Type: text/plain; charset=ISO-8859-1 For details, see RFC2026, but put very simply: The typical procedure is to identify one or more working groups whose charters seem to cover your material, and see if they are willing and able to take up your draft as a work item. If you can't, then you can approach an area director to sponsor the draft as an individual submission. The third option is to go through the Independent Submission Editor, for work that is not directly related to any active working groups. So, to the WG: Is there any interest in taking up any of these items in APPSAWG? -MSK, APPSAWG co-chair On Thu, May 2, 2013 at 1:51 PM, Erik Wilde wrote: > hello. > > i have a question about procedural issues: i have three drafts that i > would like to enter into a formal review process. since these drafts are > individual submissions, the question (that i have faced before) always is > how to make the transition from individually posting and discussing the > drafts, to this more formal process. the current drafts i have been working > on (and which i believe are ready to enter the formal path to RFCness) are: > > http://tools.ietf.org/html/**draft-wilde-xml-patch-04 > http://tools.ietf.org/html/**draft-hausenblas-csv-fragment-**02 > http://tools.ietf.org/html/**draft-sinnema-xacml-media-**type-02 > > with my previous drafts i always was lucky to have somebody shepherding > them, but it was always a lucky coincidence to find somebody willing to do > it. the question i have is how to approach this in a way so that i can make > this transition from individual drafts to the formal process more > predictable. are there any recommendations or guidance i could turn to? is > there a different forum i should ask for this? > > thanks a lot for your help and kind regards, > > dret. > > -- > erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | > | UC Berkeley - School of Information (ISchool) | > | http://dret.net/netdret http://twitter.com/dret | > ______________________________**_________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/apps-discuss > --047d7b5d8cff6d3e1104dbc39b72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
For details, see RFC2026, but put very simply:
The typical procedure is to identify one or more working groups whose= charters seem to cover your material, and see if they are willing and able= to take up your draft as a work item.=A0 If you can't, then you can ap= proach an area director to sponsor the draft as an individual submission.= =A0 The third option is to go through the Independent Submission Editor, fo= r work that is not directly related to any active working groups.

So, to the WG: Is there any interest in taking up any of these it= ems in APPSAWG?

-MSK, APPSAWG co-chair



On Thu, May 2, 2013 at = 1:51 PM, Erik Wilde <dret@berkeley.edu> wrote:
hello.

i have a question about procedural issues: i have three drafts that i would= like to enter into a formal review process. since these drafts are individ= ual submissions, the question (that i have faced before) always is how to m= ake the transition from individually posting and discussing the drafts, to = this more formal process. the current drafts i have been working on (and wh= ich i believe are ready to enter the formal path to RFCness) are:

http://tools.ietf.org/html/draft-wilde-xml-patch-04
http://tools.ietf.org/html/draft-hausenblas-csv-fragm= ent-02
http://tools.ietf.org/html/draft-sinnema-xacml-media= -type-02

with my previous drafts i always was lucky to have somebody shepherding the= m, but it was always a lucky coincidence to find somebody willing to do it.= the question i have is how to approach this in a way so that i can make th= is transition from individual drafts to the formal process more predictable= . are there any recommendations or guidance i could turn to? is there a dif= ferent forum i should ask for this?

thanks a lot for your help and kind regards,

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 |
_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--047d7b5d8cff6d3e1104dbc39b72-- From yangkun2005@gmail.com Thu May 2 22:44: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 DFEA421F92CF for ; Thu, 2 May 2013 22:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 cP4TUQtHNvJB for ; Thu, 2 May 2013 22:44:35 -0700 (PDT) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by ietfa.amsl.com (Postfix) with ESMTP id B92DA21F91B1 for ; Thu, 2 May 2013 22:44:35 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id i10so42602oag.1 for ; Thu, 02 May 2013 22:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=PZXJON6CqKW82C+UtE+QMpKZ90I5Q9fgupDfLbf6B1g=; b=sDOPK3wdZo21kQFDLeT040+jQMRgYRMydKhnc9vYMJb9g+zWH4v4uAGqHfu9gzdGDA 9/ajcSHKSkyN6Bg4SRm9WiEb9Cyy2Lrn/m3b4L3bXXY1eW3c097kaCkBsKc9Bc38vJsA OCpBydLqoAiVTW9Ry7ERScWELyJzbVKUtFlNgXa6VFWLa26sDbEhh8Rgl9C1qMf4aYny QU6tuNM7UYdzhYS6owywRUHINjEjcpaTJvHSqn/L+yNqRhtbq0/oFCBcAwsy7bUzZw+7 EyQkymgYza3tehLTdExz3T/0lKeNTGmMi6jj9Mpdm4/IWqzimdKQyCmQadFPXAaQ3g+9 g16Q== MIME-Version: 1.0 X-Received: by 10.60.35.197 with SMTP id k5mr2594603oej.138.1367559864584; Thu, 02 May 2013 22:44:24 -0700 (PDT) Received: by 10.182.213.202 with HTTP; Thu, 2 May 2013 22:44:24 -0700 (PDT) Date: Fri, 3 May 2013 13:44:24 +0800 Message-ID: From: Kun Yang To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=089e011847a6f00f2b04dbc9d737 Subject: Re: [apps-discuss] draft-guo-idoca-with-the-html-file-format-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, 03 May 2013 05:44:41 -0000 --089e011847a6f00f2b04dbc9d737 Content-Type: text/plain; charset=ISO-8859-1 Dear everyone, The I-D draft-guo-idoca-with-the-html-file-format-00 has been submitted to IETF for more than a month, but it is kind of ignored. With more and more people using cloud offices or online offices, the interconnection and the interoperability of different cloud office applications become more and more important. If all cloud office websites could interconnect and interoperate, they would bring their users a huge convenience which would attract more potential users. It not only benefits to cloud office users but also to those cloud office providers. This is really a valuable issue to talk about. To be honest, it is not perfect. Maybe, it has big mistakes. But the idea is new and original. Therefore, we should at least make some comments on it. Your advice and comments are looked forward to. Yours sincerely, Kun Yang --089e011847a6f00f2b04dbc9d737 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear everyone,

The I-D draft-guo-= idoca-with-the-html-file-format-00 has been submitted to IETF for more than= a month, but it is kind of ignored. With more and more people using cloud = offices or online offices, the interconnection and the interoperability of = different cloud office applications become more and more important. If all = cloud office websites could interconnect and interoperate, they would bring= their users a huge convenience which would attract more potential users. I= t not only benefits to cloud office users but also to those cloud office pr= oviders. This is really a valuable issue to talk about. To be honest, it is= not perfect. Maybe, it has big mistakes. But the idea is new and original.= Therefore, we should at least make some comments on it.

Your advice and comments are looked forward= to.

Yours sincerely,
= Kun Yang
--089e011847a6f00f2b04dbc9d737-- From j.schoenwaelder@jacobs-university.de Fri May 3 01:16: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 A36DF21F9418; Fri, 3 May 2013 01:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 YRNLKVWDIC-v; Fri, 3 May 2013 01:16:12 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id EE38F21F949A; Fri, 3 May 2013 01:16:11 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E0B520C27; Fri, 3 May 2013 10:16:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SvNMVkHH-y75; Fri, 3 May 2013 10:16:10 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 498FC20C26; Fri, 3 May 2013 10:16:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E4B1925F2630; Fri, 3 May 2013 10:16:08 +0200 (CEST) Date: Fri, 3 May 2013 10:16:08 +0200 From: Juergen Schoenwaelder To: Martin Thomson Message-ID: <20130503081608.GA4483@elstar.local> Mail-Followup-To: Martin Thomson , IETF Apps Discuss , draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, The IESG , netmod@ietf.org References: <6.2.5.6.2.20130428233426.0b62fed0@elandnews.com> <20130430083206.GD46852@elstar.local> <20130502074157.GA4935@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Fri, 03 May 2013 11:16:24 -0700 Cc: draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, netmod@ietf.org, The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] [appsdir] Fwd: APPSDIR review of draft-ietf-netmod-rfc6021-bis-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 08:16:19 -0000 On Thu, May 02, 2013 at 01:28:46PM -0700, Martin Thomson wrote: > On 2 May 2013 00:41, Juergen Schoenwaelder > wrote: > > On Tue, Apr 30, 2013 at 12:29:02PM -0700, Martin Thomson wrote: > >> One meta-comment. I don't consider the contents of RFC 6021 to have > >> any bearing on the review of this document. I'm not familiar with > >> 6021, so I consider all of this to be new. > > > > But most of the definitions are not new and I am reluctant to make > > changes to published RFC text. > > I thought that was the purpose of revising an RFC. If you were just > looking to add types, an update might be more appropriate. The new types go into existing YANG module and this requires to republish the whole module. This is what we have been doing >20 years for MIB modules - so there is experience with this. > > If you mean by "second" the ipv6-address-no-zone typedef, please see > > my response to Joel. This is a type derived from ipv6-address. > > Ahh, both patterns apply. My mistake; I had assumed OR (like XML > schema), not AND. Interesting approach. In XML schema, you have both: If multiple element information items appear as [children] of a , the [value]s should be combined as if they appeared in a single ·regular expression· as separate ·branch·es. Note: It is a consequence of the schema representation constraint Multiple patterns (§4.3.4.3) and of the rules for ·restriction· that ·pattern· facets specified on the same step in a type derivation are ORed together, while ·pattern· facets specified on different steps of a type derivation are ANDed together. I believe YANG is actually following XML schema here. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From superuser@gmail.com Fri May 3 12:25: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 B274621F8B5F for ; Fri, 3 May 2013 12:25:16 -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 kHtjc03YlqJy for ; Fri, 3 May 2013 12:25:14 -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 A2AC321F8B60 for ; Fri, 3 May 2013 12:25:04 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id x43so1546083wey.11 for ; Fri, 03 May 2013 12:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=PYXlhRsKubJBcsBpwbIoMGn3KPTWgBDL8Hn6xoB1zLo=; b=ykhIR8GJyOIpe8nUciGOsWWhfQ6/5ERrpCiE35xVR3jMA3jcNC4xcHX4J/qCEaYvkS RKqZ/TguqmrAiKPxffvrmpXjwGO1RBGhH3xgFRRg3F6r7kQdhnWGQjl2winYqJRox2Fy 7TVPkZNferZca9m1e0o4rQotAtiBcPljru2eU5PizvwVeWeDhxt0k9ZX4ZNBCP1UfMRe ylDfefl5G4+t47FnZJfHbpsnjf6VXZ4+wIct+MUukhnhQFB+o5Z8jox1qXZ99Z53A7wW ozdfw2QlCIKIW7E149P/X/oZwBKTWzv2vgd9apyTP7WRUz7dg8gprT66v3H4/rjuJBcR H9rw== MIME-Version: 1.0 X-Received: by 10.194.59.208 with SMTP id b16mr15719839wjr.15.1367609103411; Fri, 03 May 2013 12:25:03 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Fri, 3 May 2013 12:25:02 -0700 (PDT) Date: Fri, 3 May 2013 12:25:02 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=047d7b86de32ccf07104dbd54ea0 Subject: [apps-discuss] Call for Adoption: draft-wilde-xml-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 19:25:17 -0000 --047d7b86de32ccf07104dbd54ea0 Content-Type: text/plain; charset=ISO-8859-1 This is a call for adoption for draft-wilde-xml-patch. The document had a thread of discussion in January that showed some interest within this working group, 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. I will act as document shepherd. -MSK, APPSAWG co-chair --047d7b86de32ccf07104dbd54ea0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is a call for adoption for draft-wilde-xml-patch= .=A0 The document had a thread of discussion in January that showed some in= terest within this working group, and it appears to be material that falls = within our charter.=A0 Accordingly, we'll adopt this as a working group= item within the next couple of weeks unless there's objection to such = processing.=A0 I will act as document shepherd.

-MSK, APPSAWG co-chair

--047d7b86de32ccf07104dbd54ea0-- From superuser@gmail.com Fri May 3 14:10: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 BFAD921F8E34 for ; Fri, 3 May 2013 14:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 TDCZvtNEZopU for ; Fri, 3 May 2013 14:10:07 -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 1468C21F90EB for ; Fri, 3 May 2013 14:10:06 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id x43so1583040wey.25 for ; Fri, 03 May 2013 14:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=MDJTco699izXyLBZ1NoAnmeD3u4llZUCP196CAcd2/g=; b=MYhVlHsBpOXQr3g6OjaOWrm8GvbvvdNLr1BGkXjhs6ciSFJGP97MfiVEvxVEGpDLDi c42fx3ehysyWhF2BxtCbwjB6OXSz2LpHrQUZySKAumpk7VOy3wuj/W2+jkKHfzx3zKHh sAa9N5rklArGj1Q6wsEr1lSklLzlJVAYeVHcujQbYiIRSMJPLhc8uQh300QTR7ldMW0g lRCAR4LJAF1X0w+DJMhGoD/0t+quynJvJoR4AeHJ6XIX73yEmyRMy1r/B043xVE+nEXK l2FJJpOcer0PYelTGVg2PiESSzq76aZ/L0Yhtk4PfrZ/e+PmYbTSMNIiazIwmH8xWNYn ynGQ== MIME-Version: 1.0 X-Received: by 10.194.93.68 with SMTP id cs4mr16188206wjb.17.1367615406236; Fri, 03 May 2013 14:10:06 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Fri, 3 May 2013 14:10:06 -0700 (PDT) Date: Fri, 3 May 2013 14:10:06 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=047d7b5d8cff7a6c5a04dbd6c688 Subject: [apps-discuss] Call for Adoption: draft-snell-merge-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 21:10:07 -0000 --047d7b5d8cff7a6c5a04dbd6c688 Content-Type: text/plain; charset=ISO-8859-1 This is a call for adoption for draft-snell-merge-patch. The document had a thread of discussion in January, and some prior, that showed some interest within this working group, 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. I will act as document shepherd. -MSK, APPSAWG co-chair --047d7b5d8cff7a6c5a04dbd6c688 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is a call for adoption for draft-snell-merge-pat= ch.=A0 The=20 document had a thread of discussion in January, and some prior, that showed= some interest within this working group, and it appears to be material that falls=20 within our charter.=A0 Accordingly, we'll adopt this as a working group= =20 item within the next couple of weeks unless there's objection to such= =20 processing.=A0 I will act as document shepherd.

-MSK, APPSAWG co-chair
--047d7b5d8cff7a6c5a04dbd6c688-- From sm@elandsys.com Fri May 3 14:27: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 D907E21F8763 for ; Fri, 3 May 2013 14:27:08 -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 aRFR3BI5qMXK for ; Fri, 3 May 2013 14:27:07 -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 640E821F869C for ; Fri, 3 May 2013 14:27:07 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.131.245]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r43LQpeQ026817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 May 2013 14:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367616423; bh=Wc5TDw1JZvcwm2r39BKGm0+TGKjVP+cflmyhVZQPbtI=; h=Date:To:From:Subject:Cc; b=GP/2loFzQTMai9ccDuIz1XNB7mjVBN5k1Gi2AZV6HYlOhaZeykcyneWL+hx45rkvs 7+ysboUgerMAQKWFPDI5GDf1mMSK2A3vtazDL/4Jlg1Zrp7APHdFw0ECZ5aO3R7IOO u1KOrUIY4UGbMwvnBXYAuDenhwmdqn6hjlFNB7zI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367616423; i=@elandsys.com; bh=Wc5TDw1JZvcwm2r39BKGm0+TGKjVP+cflmyhVZQPbtI=; h=Date:To:From:Subject:Cc; b=IpQLE/OBasZsYmrcJP5dEs5hkKZolNTE/yui1/OHZL1llnaiHdd7n3A9UuuwXq0nN qvX05C0njHM0hrxAEWicjNzytm0Jp/UKHRdsvuxB5A1OBxk4tKIVbVuIGigWHLoV3v 7JvAQRNqOsm711mGto7gFTh+TfKhFulSreNsUPDQ= Message-Id: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 03 May 2013 14:26:14 -0700 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-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, 03 May 2013 21:27:09 -0000 Hi APPSAWG, This message initiates a two weeks WGLC on draft-ietf-appsawg-rfc5451bis-00 ("Message Header Field for Indicating Message Authentication Status") [1]. Please send your comments to the mailing list before the end of Friday May 17. Comments saying that you reviewed the draft and you are happy for it to be sent for IETF Last Call are also valuable. Regards, S. Moonesamy (as document shepherd) 1. http://tools.ietf.org/html/draft-ietf-appsawg-rfc5451bis-00 From dret@berkeley.edu Fri May 3 22:29: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 392C821F9050 for ; Fri, 3 May 2013 22:29:46 -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 ndmDb8mMQG6j for ; Fri, 3 May 2013 22:29:41 -0700 (PDT) Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id DF88521F901D for ; Fri, 3 May 2013 22:29:41 -0700 (PDT) Received: from 24-119-110-161.cpe.cableone.net ([24.119.110.161] helo=dretair.local) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1UYV2S-0006nU-Gp for apps-discuss@ietf.org; Fri, 03 May 2013 22:29:41 -0700 Message-ID: <51849CC0.5010000@berkeley.edu> Date: Fri, 03 May 2013 22:29:36 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "apps-discuss@ietf.org application-layer protocols" References: <20130504052702.27334.30570.idtracker@ietfa.amsl.com> In-Reply-To: <20130504052702.27334.30570.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130504052702.27334.30570.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Fwd: New Version Notification for draft-hausenblas-csv-fragment-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 05:29:46 -0000 A new version of I-D, draft-hausenblas-csv-fragment-03.txt has been successfully submitted by Erik Wilde and posted to the IETF repository. Filename: draft-hausenblas-csv-fragment Revision: 03 Title: URI Fragment Identifiers for the text/csv Media Type Creation date: 2013-05-03 Group: Individual Submission Number of pages: 11 URL: http://www.ietf.org/internet-drafts/draft-hausenblas-csv-fragment-03.txt Status: http://datatracker.ietf.org/doc/draft-hausenblas-csv-fragment Htmlized: http://tools.ietf.org/html/draft-hausenblas-csv-fragment-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-hausenblas-csv-fragment-03 Abstract: This memo defines URI fragment identifiers for text/csv MIME entities. These fragment identifiers make it possible to refer to parts of a text/csv MIME entity, identified by row, column, or cell. Fragment identification can use single items, or ranges. Note to Readers This draft should be discussed on the apps-discuss mailing list [11]. Online access to all versions and files is available on github [12]. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From dret@berkeley.edu Fri May 3 23:20: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 9A0BF21F92FC for ; Fri, 3 May 2013 23:20:22 -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 O99qUZi6ceoQ for ; Fri, 3 May 2013 23:20:15 -0700 (PDT) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 8B35021F8935 for ; Fri, 3 May 2013 23:20:15 -0700 (PDT) Received: from 24-119-110-161.cpe.cableone.net ([24.119.110.161] helo=dretair.local) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1UYVpN-0003zF-Dh for apps-discuss@ietf.org; Fri, 03 May 2013 23:20:14 -0700 Message-ID: <5184A89A.3020607@berkeley.edu> Date: Fri, 03 May 2013 23:20:10 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "apps-discuss@ietf.org application-layer protocols" References: <20130504061827.22818.67823.idtracker@ietfa.amsl.com> In-Reply-To: <20130504061827.22818.67823.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130504061827.22818.67823.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Fwd: New Version Notification for draft-sinnema-xacml-media-type-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 06:20:24 -0000 A new version of I-D, draft-sinnema-xacml-media-type-03.txt has been successfully submitted by Erik Wilde and posted to the IETF repository. Filename: draft-sinnema-xacml-media-type Revision: 03 Title: eXtensible Access Control Markup Language (XACML) Media Type Creation date: 2013-05-03 Group: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-sinnema-xacml-media-type-03.txt Status: http://datatracker.ietf.org/doc/draft-sinnema-xacml-media-type Htmlized: http://tools.ietf.org/html/draft-sinnema-xacml-media-type-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-sinnema-xacml-media-type-03 Abstract: This specification registers an XML-based media type for the eXtensible Access Control Markup Language (XACML). Note to Readers This draft should be discussed on the apps-discuss mailing list [1]. Online access to all versions and files is available on github [2]. -- 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 superuser@gmail.com Sun May 5 23:42: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 69E1A21F856D for ; Sun, 5 May 2013 23:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.973 X-Spam-Level: X-Spam-Status: No, score=-0.973 tagged_above=-999 required=5 tests=[AWL=-1.574, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_83=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 i1KPTU7czN7v for ; Sun, 5 May 2013 23:42:23 -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 6459021F8E5D for ; Sun, 5 May 2013 23:42:17 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hq12so2204722wib.10 for ; Sun, 05 May 2013 23:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=+9uglJA78W0cngvatsGUgZcC5o1SOhmw5y488mNitgE=; b=Q5FlA4/KhpqbGy/e596D12nWBOXRyzT29lq2t5udFUcO9T/LWuJZ284awoqfm+TU/F SFJpNnukwCXXMwuKftOdQoYCGn01ECkr5Iu3wm+Jxy5Y+EkNmooRN7Tzf+LpPc8u8dbY o61QoVYN9/lSMZGcj0vu9eSZm2/njUJ8GPI1rt35a6VXPKNMeCboidiXlji92MTtntN0 LefQiHaaSwWO0njL8uqvcDYfNWwGPQrw7PuHrv9RogLiy4Zic8skXZBb0f0viBMftBqt Iow/ikIqiMDEJgrnIw9DGO+M+z/C5+rhTwsewItFLtq5Ioavi/UGwSfk0LTqp7lA9uNY 3eTQ== MIME-Version: 1.0 X-Received: by 10.194.59.208 with SMTP id b16mr23516940wjr.15.1367822536436; Sun, 05 May 2013 23:42:16 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Sun, 5 May 2013 23:42:16 -0700 (PDT) In-Reply-To: <51657E80.8070208@bbiw.net> References: <51657E80.8070208@bbiw.net> Date: Sun, 5 May 2013 23:42:16 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=047d7b86de326670fd04dc07005f Cc: Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-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: Mon, 06 May 2013 06:42:30 -0000 --047d7b86de326670fd04dc07005f Content-Type: text/plain; charset=ISO-8859-1 Thanks, Dave. I'm waiting for my co-author to get back to me on two points in your review that I can't really answer, and then we'll at long last post a new version for the WG to review. I'll try to solicit a couple more reviews and then suggest Salvatore start WGLC on it. -MSK, hatless this time On Wed, Apr 10, 2013 at 8:00 AM, Dave Crocker wrote: > > Review of: Advice for Safe Handling of Malformed Messages > > I-D: draft-ietf-appsawg-malformed-**mail-03 > > Reviewer: D. Crocker > > Review Date: 10 April 2013 > > > Summary: > > Internet Mail has always been marked by an unfortunate degree of > regular and permitted non-conformance to its formal specifications. The > current draft seeks to categorize and discuss common types of > non-conformance and to provide some guidance for how it should be handled. > The document is explicit in stating that it does not have the goal of > standardizing this guidance. > > The document is reasonably clear and complete. I believe a document > like this can provide very helpful guidance for email developers and > operators. It would be useful in its current form, but could greatly > benefit from some modification. > > One major concern, which is easily remedied, is the draft's use of > normative language. The document is often unusually careful to use > qualifying language that precisely limits the scope of the normative text > to "a module compliant with this memo". However I think this is too subtle > for most readers and that the use of normative language defeats the stated > limitation of not wanting to define a standard. Hence I changing all such > language and, instead, using language that is clearly only modest "advice", > such as with: > > * a common handling is... > * it is best to... > * it will typically be safe and helpful to... > > and so on. > > > > Detailed Comments: > > > Abstract >> >> The email ecosystem has long had a very permissive set of common >> processing rules in place, despite increasingly rigid standards >> governing its components, ostensibly to improve the user experience. >> > > Although Internet mail formats have been precisely defined since the > 1970s, authoring and handling software often show only mild conformance to > the specifications. The distributed and non-interactive nature of email > has often prompted adjustments to receiving software, to handle these > variations, rather than trying to gain better conformance by senders, since > the receiving operator is primarily driven by complaining recipient users > and has no authority over the sending side of the system. > > > The handling of these come at some cost, and various components are >> > > Processing with such flexibility comes at some cost, since mail > software is faced with... > > > faced with decisions about whether or not to permit non-conforming >> messages to continue toward their destinations unaltered, adjust them >> to conform (possibly at the cost of losing some of the original >> message), or outright rejecting them. >> > > A core requirement for interoperability is that both sides to an > exchange work from the same details and semantics. By having receivers be > flexible, beyond the specifications, there can -- and often has been -- a > good chance that a message will not be fully interoperable. Worse, a > well-established pattern of tolerance for variations can sometimes be used > as an attack vector. > > > This document includes a collection of the best advice available >> regarding a variety of common malformed mail situations, to be used >> as implementation guidance. It must be emphasized, however, that the >> intent of this document is not to standardize malformations or >> otherwise encourage their proliferation. The messages are manifestly >> malformed, and the code and culture that generates them needs to be >> fixed. Therefore, these messages should be rejected outright if at >> all possible. Nevertheless, many malformed messages from otherwise >> legitimate senders are in circulation and will be for some time, and, >> unfortunately, commercial reality shows that we cannot always simply >> reject or discard them. Accordingly, this document presents >> alternatives for dealing with them in ways that seem to do the least >> additional harm until the infrastructure is tightened up to match the >> standards. >> > > > >> 1. Introduction >> >> 1.1. The Purpose Of This Work >> >> The history of email standards, going back to [RFC822] and beyond, >> > > { here I actually suggest citing RFC 733, since it managed to establish > the solid foundation, with 822 being a relatively small modification. 733 > was not the first formal standard, but the first had poor adoption. /d} > > > contains a fairly rigid evolution of specifications. But >> implementations within that culture have also long had an >> undercurrent known formally as the robustness principle, but also >> known informally as Postel's Law: "Be conservative in what you do, be >> liberal in what you accept from others." >> > > Jon Postel's directive is often misinterpreted to mean that any > deviance from a specification is acceptable. Rather, it was intended only > to account for legitimate variations in interpretation /within > specifications, as well as basic transit errors, like bit errors. Taken to > its unintended extreme, excessive tolerance would imply that there are no > limits to the liberties that a sender might take, while presuming a burden > on a receiver to "correctly" guess at the meaning of any such variation. > > {BTW, I believe Postel's Law was not the motivating reason for email > format deviations. Rather, I think that receiver's were accountable to > their users -- the recipients -- while having no control over the > misbehaving senders. So they/we hacked receiving code when necessary, to > appease the users. /d } > > > In general, this served the email ecosystem well by allowing a few >> errors in implementations without obstructing participation in the >> game. The proverbial bar was set low. However, as we have evolved >> into the current era, some of these lenient stances have begun to >> expose opportunities that can be exploited by malefactors. Various >> email-based applications rely on strong application of these >> standards for simple security checks, while the very basic building >> blocks of that infrastructure, intending to be robust, fail utterly >> to assert those standards. >> >> This document presents some areas in which the more lenient stances >> can provide vectors for attack, and then presents the collected >> wisdom of numerous applications in and around the email ecosystem for >> dealing with them to mitigate their impact. >> >> 1.2. Not The Purpose Of This Work >> >> It is important to understand that this work is not an effort to >> endorse or standardize certain common malformations. The code and >> culture that introduces such messages into the mail stream needs to >> be repaired, as the security penalty now being paid for this lax >> processing arguably outweighs the reduction in support costs to end >> users who are not expected to understand the standards. However, the >> reality is that this will not be fixed quickly. >> >> Given this, it is beneficial to provide implementers with guidance >> about the safest or most effective way to handle malformed messages >> when they arrive, taking into consideration the tradeoffs of the >> choices available especially with respect to how various actors in >> the email ecosystem respond to such messages in terms of handling, >> parsing, or rendering to end users. >> >> 1.3. General Considerations >> >> Many deviations from message format standards are considered by some >> receivers to be strong indications that the message is undesirable, >> i.e., is spam or contains malware. Such receivers quickly decide >> >> >> >> Kucherawy & Shapiro Expires April 12, 2013 [Page 4] >> >> Internet-Draft Safe Mail Handling October 2012 >> >> >> that the best handling choice is simply to reject or discard the >> message. This means malformations caused by innocent >> misunderstandings or ignorance of proper syntax can cause messages >> with no ill intent also to fail to be delivered. >> >> Senders that want to ensure message delivery are best advised to >> adhere strictly to the relevant standards (including, but not limited >> to, [MAIL], [MIME], and [DKIM]), as well as observe other industry >> best practices such as may be published from time to time either by >> the IETF or independently. >> >> 2. Document Conventions >> >> 2.1. Key Words >> >> 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 described in [KEYWORDS]. However, >> they only have that meaning in this document when they are presented >> entirely in upper case. >> > > > { While the document is clear that its use of normative language is meant > to apply only to those implementations choosing to conform to this > document, the document itself says -- appropriately, IMO -- that it is not > trying to standardize these behaviors. It's therefore confusing and > probably counter-productive to use normative language. I strongly urge > dropping all such language and, instead, only offering modest "advice" with > language like: > > * a common handling is... > * it is best to... > * it will typically be safe and helpful to... > > and so on. /d} > > > 2.2. Examples >> >> Examples of message content include a number within braces at the end >> of each line. These are line numbers for use in subsequent >> discussion, and are not actually part of the message content >> presented in the example. >> >> Blank lines are not numbered in the examples. >> >> 3. Background >> >> The reader would benefit from reading [EMAIL-ARCH] for some general >> background about the overall email architecture. Of particular >> interest is the Internet Message Format, detailed in [MAIL]. >> Throughout this document, the use of the term "messsage" should be >> > > { Freud possibly at work for this missspellling? /d} > > > assumed to mean a block of text conforming to the Internet Message >> Format. >> >> 4. Internal Representations >> >> Any agent handling a message could have one or two (or more) distinct >> > > As an agent parses and processes a message, it might create a number > of distinct representations for the message. > > > representations of a message it is handling. One is an internal >> representation, such as a block of storage used for the header and a >> block for the body. These may be sorted, encoded, decoded, etc., as >> per the needs of that particular module. The other is the >> representation that is output to the next agent in the handling >> chain. This might be identical to the version that is input to the >> >> >> >> Kucherawy & Shapiro Expires April 12, 2013 [Page 5] >> >> Internet-Draft Safe Mail Handling October 2012 >> >> >> module, or it might have some changes such as added or reordered >> header fields, body modifications to remove malicious content, etc. >> >> In some cases, advice is provided only for internal representations. >> However, there is often occasion to mandate changes to the output as >> well. >> > > { What does this last sentence mean? "Mandate"? Perhaps what is meant > is: /d} > > However it is sometimes necessary to make changes between the input > and output versions, as well. > > > >> 5. Invariate Content >> > > Invariant {?} > > > >> Experience has shown that it is beneficial to ensure that, from the >> first analysis agent at ingress into the destination Administrative >> Management Domain (ADMD; see [EMAIL-ARCH]) to the agent that actually >> affects delivery to the end user, the message each agent sees is >> > > { This is an artfully-crafted sentence, but it would be easier to read if > broken into parts. Perhaps: /d} > > An especially interesting handling sequence occurs within the > destination Administrative Management Domain (ADMD; see [EMAIL-ARCH]). From > ingress to the ADMD, through the boundary agent, until delivery to the end > user, it is beneficial to ensure that each agent sees an identical form for > the message. > > > identical. Absent this, it can be impossible for different agents in >> the chain to make assertions about the content that correlate. >> > > > the chain to make consistent assertions about the content. > > > For example, suppose a handling agent records that a message had some >> specific set of properties at ingress to the ADMD, then permitted it >> to continue inbound. Some other agent alters the content for some >> reason. The user, on viewing the delivered content, reports the >> message as abusive. If the report is based on the set of properties >> > > message as abuse. However, report processing often takes place at, > or close to, the original point of ingress and is likely to be based on the > set of properties recorded there, rather than at the user's system. > > > recorded at ingress, then the complaint effectively references a >> message different from what the user saw, which could render the >> complaint inactionable. Similarly, a message with properties that a >> filtering agent might use to reject an abusive message could be >> allowed to reach the user if an intermediate agent altered the >> message in a manner that alters one of those properties, thwarting >> detection of the abuse. >> > > { awkward sentence structure. d/} > > > Therefore, agents comprising an inbound message processing >> > > comprising an inbound -> within an integrated message > > {or should this simply say 'within an ADMD'? /d} > > > environment SHOULD ensure that each agent sees the same content, and >> the message reaches the end user unmodified. An exception to this is >> content that is identitfied as certainly harmful, such as some kind >> of malicious executable software included in the message. >> > > {the 'exception' sentence is far too specific. There are, no doubt, many > reasons for deviating from this recommendation. Simpler, safer and > non-normative wording would be: /d} > > environment will simplify operational concerns by ensuring that each > agent receives the same content -- except for the usual handling agent > trace information additions -- and that this is what reaches the end user, > unmodified. Various policies, such as special handling for detected > message abuse, will make exceptions appropriate. > > > 6. Mail Submission Agents >> >> Within the email context, the single most influential component that >> can reduce the presence of malformed items in the email system is the >> Mail Submission Agent (MSA). This is the component that is >> essentially the interface between end users that create content and >> the mail stream. >> > > the Mail Handling Service (MHS) [EMAIL-ARCH] > > > The lax processing described earlier in the document creates a high >> > > {this first sentence is out of place. the earlier discussion in the > document established the need for better conformance; it doesn't need to be > sold here, again. /d} > > > support and security cost overall. Thus, MSAs MUST evolve to become >> more strict about enforcement of all relevant email standards, >> especially [MAIL] and the [MIME] family of documents. >> >> >> >> >> Kucherawy & Shapiro Expires April 12, 2013 [Page 6] >> >> Internet-Draft Safe Mail Handling October 2012 >> >> >> Relay Mail Transport Agents (MTAs) SHOULD also be more strict; >> > > Relay -> Relaying > > { This pseudo-normative phrasing does nothing helpful, since it isn't > actually specifying anything. Modify to something like: /d} > > More strict conformance by relaying MTAs also will be helpful. > Although > > > although preventing the dissemination of malformed messages is >> desirable, the rejection of such mail already in transit also has a >> support cost, namely the creation of a [DSN] that many end users >> might not understand. >> >> 7. Line Terminaton >> >> The only valid line separation sequence in messaging is ASCII 0x0D >> > > For interoperable Internet Mail messages, the only valid... > > > ("carriage return", or CR) followed by ASCII 0x0A ("line feed", or >> LF), commonly referred to as CRLF. Common UNIX user tools, however, >> typically only use LF for line termination. This means the protocol >> has to convert LF to CRLF before transporting a message. >> > > for internal line termination. This means that a protocol engine, > which converts between Unix and Internet Mail formats, has to convert > between these two end-of-line representations, before transmitting a > message or after receiving it. > > > Naive implementations can cause messages to be transmitted with a mix >> > > { These aren't "naive". They are quite simply broken! d/} > > Implementations that do not conform to Internet Mail standards > sometimes cause messages to be transmitted... > > > of line terminations, such as LF everywhere except CRLF only at the >> end of the message. According to [SMTP], this means the entire >> message actually exists on a single line. >> > > { also RFC 5322! /d} > > > A "naked" CR or LF in a message has no reasonable justification, and >> > > { this is wrong. they have legitimate presentation uses, albeit pretty > archaic at this point. Better: /d } > > Within modern Internet Mail it is highly unlikely that an isolated CR > or LF is valid, in common ASCII text. Furthermore [MIME]... > > > furthermore [MIME] presents mechanisms for encoding content that >> actually does need to contain such an unusual character sequence. >> >> Thus, handling agents MUST treat naked CRs and LFs as CRLFs when >> interpreting the message. >> > > Thus, it will typically be safe and helpful to treat a naked CR or LF > as equivalent to a CRLF, when parsing a message. > > > 8. Header Anomalies >> >> This section covers common syntactical and semantic anomalies found >> in headers of messages, and presents preferred mitigations. >> > > in a message header, and > > > 8.1. Converting Obsolete and Invalid Syntaxes >> >> There are numerous cases of obsolete header syntaxes that can be >> applied to confound agents with variable processing. This section >> > > { The phrasing of the first sentence sounds as if confounding is a goal. > If it's meant that way, say it more clearly. If it isn't, perhaps: /d } > > A message using an obsolete header syntax might confound an agent > that is attempting to be robust in its handling of syntax variations. > > > presents some examples of these. Messages including them SHOULD be >> > > { 'of these'? of which? /d} > > { Why reject this particular set? What about others, outside these > examples? Again, phrase this non-normatively. /d} > > > rejected; where this is not possible, RECOMMENDED internal >> interpretations are provided. >> >> 8.1.1. Host-Address Syntax >> >> The following obsolete syntax: >> > > The following obsolete syntax that attempts to specify source routing: > > { explain, or perhaps even cite the old ABNF rule for it /d} > > > >> To: <@example.net:fran@example.com**> >> >> should be interpreted as: >> > > can safely be interpreted as: > > > To: >> >> >> >> Kucherawy & Shapiro Expires April 12, 2013 [Page 7] >> >> Internet-Draft Safe Mail Handling October 2012 >> >> >> 8.1.2. Excessive Angle Brackets >> >> The following over-use of angle brackets, e.g.: >> >> To: <<>> >> >> should be interpreted as: >> > > can safely be interpreted as: > > > To: >> >> 8.1.3. Unbalanced Angle Brackets >> >> The following use of unbalanced angle brackets: >> >> To: > To: second@example.org> >> >> should be interpreted as: >> > > can usually be treated as: > > > To: >> To: second@example.org >> >> 8.1.4. Unbalanced Parentheses >> >> The following use of unbalanced parentheses: >> >> To: (Testing >> To: Testing) >> >> should be interpreted as: >> >> To: (Testing) >> To: "Testing)" >> >> 8.1.5. Unbalanced Quotes >> >> The following use of unbalanced quotation marks: >> >> To: "Joe >> >> should be interpreted as: >> >> To: "Joe "@example.net >> > > { WTF??? And why is this a good fixup, especially given concerns about > display-name attack vectors? /d} > > > where "example.net" is the domain name or host name of the handling >> agent making the interpretation. >> >> >> >> >> >> Kucherawy & Shapiro Expires April 12, 2013 [Page 8] >> >> Internet-Draft Safe Mail Handling October 2012 >> >> >> 8.2. Non-Header Lines >> >> It has been observed that some messages contain a line of text in the >> > > Some messages contain a line of... > > > header that is not a valid message header field of any kind. For >> example: >> >> From: user@example.com {1} >> To: userpal@example.net {2} >> Subject: This is your reminder {3} >> about the football game tonight {4} >> Date: Wed, 20 Oct 2010 20:53:35 -0400 {5} >> >> Don't forget to meet us for the tailgate party! {7} >> >> The cause of this is typically a bug in a message generator of some >> kind. Line {4} was intended to be a continuation of line {3}; it >> should have been indented by whitespace as set out in Section 2.2.3 >> of [MAIL]. >> >> This anomaly has varying impacts on processing software, depending on >> the implementation: >> >> 1. some agents choose to separate the header of the message from the >> body only at the first empty line (i.e. a CRLF immediately >> followed by another CRLF); >> >> 2. some agents assume this anomaly should be interpreted to mean the >> body starts at line {4}, as the end of the header is assumed by >> encountering something that is not a valid header field or folded >> portion thereof; >> >> 3. some agents assume this should be interpreted as an intended >> header folding as described above and thus simply append a single >> space character (ASCII 0x20) and the content of line {4} to that >> of line {3}; >> >> 4. some agents reject this outright as line {4} is neither a valid >> header field nor a folded continuation of a header field prior to >> an empty line. >> >> This can be exploited if it is known that one message handling agent >> will take one action while the next agent in the handling chain will >> take another. Consider, for example, a message filter that searches >> message headers for properties indicative of abusive of malicious >> content that is attached to a Mail Transfer Agent (MTA) implementing >> option 2 above. An attacker could craft a message that includes this >> malformation at a position above the property of interest, knowing >> the MTA will not consider that content part of the header, and thus >> >> >> >> Kucherawy & Shapiro Expires April 12, 2013 [Page 9] >> >> Internet-Draft Safe Mail Handling October 2012 >> >> >> the MTA will not feed it to the filter, thus avoiding detection. >> Meanwhile, the Mail User Agent (MUA) which presents the content to an >> end user, implements option 1 or 3, which has some undesirable >> effect. >> >> It should be noted that a few implementations choose option 4 above >> since any reputable message generation program will get header >> folding right, and thus anything so blatant as this malformation is >> likely an error caused by a malefactor. >> >> The preferred implementation if option 4 above is not employed is to >> apply the following heuristic when this malformation is detected: >> >> 1. Search forward for an empty line. If one is found, then apply >> option 3 above to the anomalous line, and continue. >> >> 2. Search forward for another line that appears to be a new header >> field, i.e., a name followed by a colon. If one is found, then >> apply option 3 above to the anomalous line, and continue. >> >> 8.3. Unusual Spacing >> >> The following message is valid per [MAIL]: >> >> From: user@example.com {1} >> To: userpal@example.net {2} >> Subject: This is your reminder {3} >> {4} >> about the football game tonight {5} >> Date: Wed, 20 Oct 2010 20:53:35 -0400 {6} >> >> Don't forget to meet us for the tailgate party! {8} >> >> Line {4} contains a single whitespace. The intended result is that >> lines {3}, {4}, and {5} comprise a single continued header field. >> However, some agents are aggressive at stripping trailing whitespace, >> which will cause line {4} to be treated as an empty line, and thus >> the separator line between header and body. This can affect header- >> specific processing algorithms as described in the previous section. >> >> Ideally, this case simply ought not to be generated. >> > > {This sentence is entirely gratuitous. Replace it with: d/ } > > This example was legal in earlier versions of the Internet Mail > format standard. > > >> Message handling agents receiving a message bearing this anomaly MUST >> behave as if line {4} was not present on the message, and SHOULD emit >> a version in which line {4} has been removed. >> > > The best handling of this example is for a message parsing engine to > behave as if line {4} was not present in the message and for a message > creation engine to emit the message with line {4} removed,. > > > >> >> >> >> Kucherawy & Shapiro Expires April 12, 2013 [Page 10] >> >> Internet-Draft Safe Mail Handling October 2012 >> >> >> 8.4. Header Malformations >> >> There are various malformations that exist. A common one is >> > > { The first sentence is pretty obvious: there are always lots of ways to > screw up. I suggest dropping it and beginning with something like: /d} > > Among the many possible malformations, a common one is... > > > insertion of whitespace at unusual locations, such as: >> >> From: user@example.com {1} >> To: userpal@example.net {2} >> Subject: This is your reminder {3} >> MIME-Version : 1.0 {4} >> Content-Type: text/plain {5} >> Date: Wed, 20 Oct 2010 20:53:35 -0400 {6} >> >> Don't forget to meet us for the tailgate party! {8} >> >> Note the addition of whitespace in line {4} after the header field >> name but before the colon that separates the name from the value. >> >> The acceptance grammar of [MAIL] permits that extra whitespace, so it >> cannot be considered invalid. However, a consensus of >> implementations prefers to remove that whitespace. There is no >> perceived change to the semantics of the header field being altered >> as the whitespace is itself semantically meaningless. Thus, a module >> compliant with this memo MUST remove all whitespace after the field >> name but before the colon, and MUST emit that version of that field >> on output. >> > > Therefore, it is best to remove all whitespace after the field name > but before the colon and to emit the field in this modified form. > > > 8.5. Header Field Counts >> >> Section 3.6 of [MAIL] prescribes specific header field counts for a >> valid message. Few agents actually enforce these in the sense that a >> message whose header contents exceed one or more limits set there are >> generally allowed to pass; they may add any required fields that are >> > > ; they typically add any... > > > missing, however. >> >> Also, few agents that use messages as input, including Mail User >> Agents (MUAs) that actually display messages to users, verify that >> the input is valid before proceeding. Two popular open source >> filtering programs and two popular Mailing List Management (MLM) >> > > { I suggest changing 'two' to 'some', since the number might change; > there's no reason to make this document get out of date for such a minor > issue. /d } > > > packages examined at the time this document was written select either >> > > { hence, remove "examined at the time this document was written" /d } > > > the first or last instance of a particular field name, such as From, >> to decide who sent a message. Absent enforcement of [MAIL], an >> > > Absent strict enforcement > > > attacker can craft a message with multiple fields if that attacker >> knows the filter will make a decision based on one but the user will >> be shown the other. >> >> This situation is exacerbated when a claim of message validity is >> inferred by something like a valid [DKIM] signature. Such a >> signature might cover one instance of a constrained field but not >> >> >> >> Kucherawy & Shapiro Expires April 12, 2013 [Page 11] >> >> Internet-Draft Safe Mail Handling October 2012 >> >> >> another, and a naive consumer of DKIM's output, not realizing which >> one was covered by a valid signature, could presume the wrong one was >> the "good" one. An MUA, for example could show the first of two From >> fields as "good" or "safe" while the DKIM signature actually only >> verified the second. >> > > { DKIM signatures do not verify addresses outside d=. While the problem > you are describing is, of course, real, it's far more complicated than > you've described here. Perhaps: /d } > > when message validity is assessed, such as through enhanced > authentication methods. Such methods might cover one instance of a > constrained field but not another, taking the wrong one as "good" or "safe". > > > Thus, an agent compliant with this specification MUST enact one of >> the following: >> > > In attempting to counter this exposure, one of the following can be > enacted: > > > 1. reject outright or refuse to process further any input message >> that does not conform to Section 3.6 of [MAIL]; >> >> 2. remove or, in the case of an MUA, refuse to render any instances >> of a header field whose presence exceeds a limit prescribed in >> Section 3.6 of [MAIL] when generating its output; >> >> 3. alter the name of any header field whose presence exceeds a limit >> prescribed in Section 3.6 of [MAIL] when generating its output so >> that later agents can produce a consistent result. Any >> alteration likely to cause the field to be ignored by downstream >> agents is acceptable. A common approach is to prefix the field >> names with a string such as "BAD-". >> > > { it would help if there were some rationales or analyses of the tradeoffs > amongst these kinds of choices, to help the implementer/operator decide > when to use which. /d } > > > > 8.6. Missing Header Fields >> >> Similar to the previous section, there are messages seen in the wild >> that lack certain required header fields. For example, [MAIL] >> requires that a From and Date field be present in all messages. >> > > { I think these aren't 'examples' but constitute the entire list. If > there are other required fields that can be classed as 'missing', this > section should list them. Also, since Message-ID isn't 'required', the > phrasing here doesn't quite match what's discussed in the section. Might be > worth distinguishing "required but missing" vs. "optional but really useful > and worth synthesizing". Synthesizing the latter probably isn't dangerous. > Synthesizing the former always is... d/} > > > >> When presented with a message lacking these fields, the MTA might >> perform one of the following: >> >> 1. Make no changes >> >> 2. Add an instance of the missing field(s) using synthesized content >> > > 3. Reject the message > > > Option 2 is RECOMMENDED for handling this case. Handling agents >> > > { Wow! Synthesizing a From: field strikes me as especially dangerous, in > all cases. The rationale provided, below, needs to state this and, I > believe, explain how and why it is worth incurring. The explanation that is > provided essentially define this hack as an attack vector... /d} > > > SHOULD add these for internal hanlding if they are missing, but MUST >> NOT add them to the external representation. The reason for this >> requirement is that there are some filter modules that would consider >> the absence of such fields to be a condition warranting special >> treatment (e.g., rejection), and thus the effectiveness of such >> modules would be stymied by an upstream filter adding them. >> >> The synthesized fields SHOULD contain a best guess as to what should >> have been there; for From, the SMTP MAIL command's address can be >> used (if not null) or a placeholder address followed by an address >> literal (e.g., unknown@[192.0.2.1]); for Date, a date extracted from >> >> >> >> Kucherawy & Shapiro Expires April 12, 2013 [Page 12] >> >> Internet-Draft Safe Mail Handling October 2012 >> >> >> a Received field is a reasonable choice. >> >> One other important case to consider is a missing Message-Id field. >> An MTA that encounters a message missing this field SHOULD synthesize >> a valid one using techniques described above and add it to the >> external rpresentation, since many deployed tools use the content of >> that field as a common unique message reference, so its absence >> inhibits correlation of message processing. One possible synthesis >> would be based on based on an encoding of the current date/time and >> an internal MTA ID (e.g., queue ID) followed by @ and the fully >> qualified hostname of the machine synthesizing the header value. For >> example: >> >> tm = gmtime(&now); >> (void) snprintf(buf, sizeof(buf), "%04d%02d%02d%02d%02d.%s@%s", >> tm->tm_year + 1900, tm->tm_mon + 1, tm->tm_mday, >> tm->tm_hour, tm->tm_min, queueID, fqhn); >> >> 8.7. Eight-Bit Data >> >> Standards-compliant mail messages do not contain any non-ASCII data >> without indicating that such content is present by means of published >> [SMTP] extensions. Absent that, [MIME] encodings are typically used >> > > Overall, the document sometimes mixes transfer issues with data > representation (object) issues, in ways that can be confusing. This > paragraph is one of those. It's worth the extra verbosity to label each > clearly and separately. So, for example: > > Standards-compliant mail messages that contain non-ASCII data are > required to self-label this through the use of [MIME]. If the > representation of the non-ASCII data is in an 8-bit mode (rather than > special encoding so that it retains a 7-bit base), then this must be > signaled through the use of [SMTP] extensions. > > > > without indicating that such content is present by means of published > > [SMTP] extensions. > > to convert non-ASCII data to ASCII in a way that can be reversed by >> other handling agents or end users. >> >> Non-ASCII data otherwise found in messages can confound code that is >> used to analyze content. For example, a null (ASCII 0x00) byte >> inside a message can cause typical string processing functions to >> mis-identify the end of a string, which can be exploited to hide >> malicious content from analysis processes. >> >> Handling agents MUST reject messages containing null bytes that are >> not encoded in some standard way, and SHOULD reject other non-ASCII >> bytes that are similarly not encoded. If rejection is not done, an >> ASCII-compatible encoding such as those defined in [MIME] SHOULD be >> used. >> > > { Hmmm. It occurs to me that the document might be helped by an early > discussion about a/the 'philosophy' that guides choosing whether to reject > a message versus repair it. But I don't have any clever text to suggest > for doing this... /d} > > > >> 9. MIME Anomalies >> >> [MIME], et seq, define a mechanism of message extensions for >> > > { perhaps quibbling, but since MIME does a variety of things, including > this one, I suggest: > > define -> includes > > > providing text in character sets other than ASCII, non-text >> attachments to messages, multi-part message bodies, and similar >> facilities. >> >> Some anomalies with MIME-compliant generation are also common. This >> section discusses some of those and presents preferred mitigations. >> >> >> >> >> Kucherawy & Shapiro Expires April 12, 2013 [Page 13] >> >> Internet-Draft Safe Mail Handling October 2012 >> >> >> 9.1. Header Field Names >> >> [MAIL] permits header field names to begin with "--". This means >> that a header field name can look like a [MIME] multipart boundary. >> For example: >> >> --foo:bar >> >> This is a legal header field, whose name is "--foo" and whose value >> is "bar". Thus, consider this header: >> >> From: user@example.com {1} >> To: userpal@example.net {2} >> Subject: This is your reminder {3} >> Date: Wed, 20 Oct 2010 20:53:35 -0400 {4} >> MIME-Version: 1.0 {5} >> Content-Type: multipart/mixed; boundary="foo:bar" {6} >> --foo:bar {7} >> Malicious-Content: muahaha {8} >> >> One implementation could observe that line {7} announces the >> beginning of the first MIME part while another considers it a part of >> the message's header. >> >> If rejection of such messages cannot be done, agents MUST treat line >> {7} as part of the message's header block and not a MIME boundary. >> > > { Under what circumstances can rejection /not/ be done??? And what is > involved in even detecting that it isn't a mime boundary? d/ } > > > >> 9.2. Missing MIME-Version Field >> >> Any message that uses [MIME] constructs is required to have a MIME- >> Version header field. Without them, the Content-Type and associated >> fields have no semantic meaning. >> > > them -> it > > > It is often observed that a message has complete MIME structure, yet >> lacks this header field. >> >> As described at the end of Section 8.2, this is not expected from a >> > > this -> this omission > > > reputable content generator and is often an indication of mass- >> produced spam or other undesirable messages. >> >> Therefore, an agent compliant with this specification MUST internally >> enact one or more of the following in the absence of a MIME-Version >> header field: >> >> 1. Ignore all other MIME-specific fields, even if they are >> syntactically valid, thus treating the entire message as a >> single-part message of type text/plain; >> > > { Offhand, this sounds like a potentially-interesting attack vector. /d} > > > >> Kucherawy & Shapiro Expires April 12, 2013 [Page 14] >> >> Internet-Draft Safe Mail Handling October 2012 >> >> >> 2. Remove all other MIME-specific fields, even if they are >> syntactically valid, both internally and when emitting the output >> version of the message; >> >> 10. Body Anomalies >> >> 10.1. Oversized Lines >> >> A message containing a line of content that exceeds 998 characters >> plus the line terminator (1000 total) violates Section 2.1.1 of >> [MAIL]. Some handling agents may not look at content in a single >> line past the first 998 bytes, providing bad actors an opportunity to >> hide malicious content. >> >> There is no specified way to handle such messages, other than to >> observe that they are non-compliant and reject them, or rewrite the >> oversized line such that the message is compliant. >> >> Handling agents MUST take one of the following actions: >> >> 1. Break such lines into multiple lines at a position that does not >> change the semantics of the text being thus altered. For >> example, breaking an oversized line such that a [URI] then spans >> two lines could inhibit the proper identification of that URI. >> >> 2. Rewrite the MIME part (or the entire message if not MIME) that >> contains the excessively long line using a content encoding that >> breaks the line in the transmission but would still result in the >> line being intact on decoding for presentation to the user. Both >> of the encodings declared in [MIME] can accomplish this. >> >> 11. Security Considerations >> >> The discussions of the anomalies above and their prescribed solutions >> are themselves security considerations. The practises enumerated in >> this memo are generally perceived as attempts to resolve security >> considerations that already exist rather than introducing new ones. >> > > { Hmmm. Whereas I think the document introduces quite a few attack > vectors that probably aren't discussed in other email specifications. /d} > > > >> 12. IANA Considerations >> >> This memo contains no actions for IANA. >> >> [RFC Editor: Please remove this section prior to publication.] >> >> 13. References >> >> >> >> >> >> >> Kucherawy & Shapiro Expires April 12, 2013 [Page 15] >> >> Internet-Draft Safe Mail Handling October 2012 >> >> >> 13.1. Normative References >> >> [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate >> Requirement Levels", BCP 14, RFC 2119, March 1997. >> >> [MAIL] Resnick, P., "Internet Message Format", RFC 5322, >> October 2008. >> >> 13.2. Informative References >> >> [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, >> J., and M. Thomas, "DomainKeys Identified Mail (DKIM) >> Signatures", RFC 4871, May 2007. >> >> [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message >> Format for Delivery Status Notifications", RFC 3464, >> January 2003. >> >> [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, >> July 2009. >> >> [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet >> Mail Extensions (MIME) Part One: Format of Internet >> Message Bodies", RFC 2045, November 1996. >> >> [RFC822] Crocker, D., "Standard for the Format of Internet Text >> Messages", RFC 822, August 1982. >> >> [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, >> October 2008. >> >> [URI] Berners-Lee, T., Fielding, R., and L. Masinter, >> "Uniform Resource Identifier (URI): Generic Syntax", >> RFC 3986, January 2005. >> >> Appendix A. Acknowledgements >> >> The author wishes to acknowledge the following for their review and >> constructive criticism of this proposal: Tony Hansen, and Franck >> Martin >> >> Authors' Addresses >> >> Murray S. Kucherawy >> >> EMail: superuser@gmail.com >> >> >> >> >> >> Kucherawy & Shapiro Expires April 12, 2013 [Page 16] >> >> Internet-Draft Safe Mail Handling October 2012 >> >> >> Gregory N. Shapiro >> >> EMail: gshapiro@sendmail.com >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Kucherawy & Shapiro Expires April 12, 2013 [Page 17] >> >> > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > --047d7b86de326670fd04dc07005f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks, Dave.=A0 I'm waiting for my co-author to get b= ack to me on two points in your review that I can't really answer, and = then we'll at long last post a new version for the WG to review.=A0 I&#= 39;ll try to solicit a couple more reviews and then suggest Salvatore start= WGLC on it.

-MSK, hatless this time


On Wed, Apr 10, 2013 at 8:00 AM, Dave Crocker <dcr= ocker@bbiw.net> wrote:

Review of: =A0 =A0Advice for Safe Handling of Malformed Messages

I-D: =A0 =A0 =A0 =A0 =A0draft-ietf-appsawg-malformed-mail-03

Reviewer: =A0 =A0 D. Crocker

Review Date: =A010 April 2013


Summary:

=A0 =A0 =A0 Internet Mail has always been marked by an unfortunate degree o= f regular and permitted non-conformance to its formal specifications. =A0Th= e current draft seeks to categorize and discuss common types of non-conform= ance and to provide some guidance for how it should be handled. =A0The docu= ment is explicit in stating that it does not have the goal of standardizing= this guidance.

=A0 =A0 =A0The document is reasonably clear and complete. I believe a docum= ent like this can provide very helpful guidance for email developers and op= erators. =A0It would be useful in its current form, but could greatly benef= it from some modification.

=A0 =A0 =A0One major concern, which is easily remedied, is the draft's = use of normative language. =A0The document is often unusually careful to us= e qualifying language that precisely limits the scope of the normative text= to "a module compliant with this memo". =A0However I think this = is too subtle for most readers and that the use of normative language defea= ts the stated limitation of not wanting to define a standard. Hence I chang= ing all such language and, instead, using language that is clearly only mod= est "advice", such as with:

=A0 =A0* =A0a common handling is...
=A0 =A0* =A0it is best to...
=A0 =A0* =A0it will typically be safe and helpful to...

and so on.



Detailed Comments:


Abstract

=A0 =A0The email ecosystem has long had a very permissive set of common
=A0 =A0processing rules in place, despite increasingly rigid standards
=A0 =A0governing its components, ostensibly to improve the user experience.=

=A0 =A0 =A0Although Internet mail formats have been precisely defined since= the 1970s, authoring and handling software often show only mild conformanc= e to the specifications. =A0The distributed and non-interactive nature of e= mail has often prompted adjustments to receiving software, to handle these = variations, rather than trying to gain better conformance by senders, since= the receiving operator is primarily driven by complaining recipient users = and has no authority over the sending side of the system.


=A0 =A0The handling of these come at some cost, and various components are<= br>

=A0 =A0 =A0Processing with such flexibility comes at some cost, since mail = software is faced with...


=A0 =A0faced with decisions about whether or not to permit non-conforming =A0 =A0messages to continue toward their destinations unaltered, adjust the= m
=A0 =A0to conform (possibly at the cost of losing some of the original
=A0 =A0message), or outright rejecting them.

=A0 =A0 =A0A core requirement for interoperability is that both sides to an= exchange work from the same details and semantics. =A0By having receivers = be flexible, beyond the specifications, there can -- and often has been -- = a good chance that a message will not be fully interoperable. =A0Worse, a w= ell-established pattern of tolerance for variations can sometimes be used a= s an attack vector.


=A0 =A0This document includes a collection of the best advice available
=A0 =A0regarding a variety of common malformed mail situations, to be used<= br> =A0 =A0as implementation guidance. =A0It must be emphasized, however, that = the
=A0 =A0intent of this document is not to standardize malformations or
=A0 =A0otherwise encourage their proliferation. =A0The messages are manifes= tly
=A0 =A0malformed, and the code and culture that generates them needs to be<= br> =A0 =A0fixed. =A0Therefore, these messages should be rejected outright if a= t
=A0 =A0all possible. =A0Nevertheless, many malformed messages from otherwis= e
=A0 =A0legitimate senders are in circulation and will be for some time, and= ,
=A0 =A0unfortunately, commercial reality shows that we cannot always simply=
=A0 =A0reject or discard them. =A0Accordingly, this document presents
=A0 =A0alternatives for dealing with them in ways that seem to do the least=
=A0 =A0additional harm until the infrastructure is tightened up to match th= e
=A0 =A0standards.



1. =A0Introduction

1.1. =A0The Purpose Of This Work

=A0 =A0The history of email standards, going back to [RFC822] and beyond,

{ here I actually suggest citing RFC 733, since it managed to establish the= solid foundation, with 822 being a relatively small modification. 733 was = not the first formal standard, but the first had poor adoption. /d}


=A0 =A0contains a fairly rigid evolution of specifications. =A0But
=A0 =A0implementations within that culture have also long had an
=A0 =A0undercurrent known formally as the robustness principle, but also =A0 =A0known informally as Postel's Law: "Be conservative in what = you do, be
=A0 =A0liberal in what you accept from others."

=A0 =A0 Jon Postel's directive is often misinterpreted to mean that any= deviance from a specification is acceptable. =A0Rather, it was intended on= ly to account for legitimate variations in interpretation /within specifica= tions, as well as basic transit errors, like bit errors. =A0Taken to its un= intended extreme, excessive tolerance would imply that there are no limits = to the liberties that a sender might take, while presuming a burden on a re= ceiver to "correctly" guess at the meaning of any such variation.=

{BTW, I believe Postel's Law was not the motivating reason for email fo= rmat deviations. =A0Rather, I think that receiver's were accountable to= their users -- the recipients -- while having no control over the misbehav= ing senders. =A0So they/we hacked receiving code when necessary, to appease= the users. /d }


=A0 =A0In general, this served the email ecosystem well by allowing a few =A0 =A0errors in implementations without obstructing participation in the =A0 =A0game. =A0The proverbial bar was set low. =A0However, as we have evol= ved
=A0 =A0into the current era, some of these lenient stances have begun to =A0 =A0expose opportunities that can be exploited by malefactors. =A0Variou= s
=A0 =A0email-based applications rely on strong application of these
=A0 =A0standards for simple security checks, while the very basic building<= br> =A0 =A0blocks of that infrastructure, intending to be robust, fail utterly<= br> =A0 =A0to assert those standards.

=A0 =A0This document presents some areas in which the more lenient stances<= br> =A0 =A0can provide vectors for attack, and then presents the collected
=A0 =A0wisdom of numerous applications in and around the email ecosystem fo= r
=A0 =A0dealing with them to mitigate their impact.

1.2. =A0Not The Purpose Of This Work

=A0 =A0It is important to understand that this work is not an effort to
=A0 =A0endorse or standardize certain common malformations. =A0The code and=
=A0 =A0culture that introduces such messages into the mail stream needs to<= br> =A0 =A0be repaired, as the security penalty now being paid for this lax
=A0 =A0processing arguably outweighs the reduction in support costs to end<= br> =A0 =A0users who are not expected to understand the standards. =A0However, = the
=A0 =A0reality is that this will not be fixed quickly.

=A0 =A0Given this, it is beneficial to provide implementers with guidance =A0 =A0about the safest or most effective way to handle malformed messages<= br> =A0 =A0when they arrive, taking into consideration the tradeoffs of the
=A0 =A0choices available especially with respect to how various actors in =A0 =A0the email ecosystem respond to such messages in terms of handling, =A0 =A0parsing, or rendering to end users.

1.3. =A0General Considerations

=A0 =A0Many deviations from message format standards are considered by some=
=A0 =A0receivers to be strong indications that the message is undesirable,<= br> =A0 =A0i.e., is spam or contains malware. =A0Such receivers quickly decide<= br>


Kucherawy & Shapiro =A0 =A0 =A0Expires April 12, 2013 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 [Page 4]
=0C
Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 Safe Mail Handling =A0 =A0 =A0 =A0 = =A0 =A0 =A0 October 2012


=A0 =A0that the best handling choice is simply to reject or discard the
=A0 =A0message. =A0This means malformations caused by innocent
=A0 =A0misunderstandings or ignorance of proper syntax can cause messages =A0 =A0with no ill intent also to fail to be delivered.

=A0 =A0Senders that want to ensure message delivery are best advised to
=A0 =A0adhere strictly to the relevant standards (including, but not limite= d
=A0 =A0to, [MAIL], [MIME], and [DKIM]), as well as observe other industry =A0 =A0best practices such as may be published from time to time either by<= br> =A0 =A0the IETF or independently.

2. =A0Document Conventions

2.1. =A0Key Words

=A0 =A0The key words "MUST", "MUST NOT", "REQUIRED= ", "SHALL", "SHALL NOT",
=A0 =A0"SHOULD", "SHOULD NOT", "RECOMMENDED",= "MAY", and "OPTIONAL" in this
=A0 =A0document are to be interpreted as described in [KEYWORDS]. =A0Howeve= r,
=A0 =A0they only have that meaning in this document when they are presented=
=A0 =A0entirely in upper case.


{ While the document is clear that its use of normative language is meant t= o apply only to those implementations choosing to conform to this document,= the document itself says -- appropriately, IMO -- that it is not trying to= standardize these behaviors. =A0It's therefore confusing and probably = counter-productive to use normative language. =A0I strongly urge dropping a= ll such language and, instead, only offering modest "advice" with= language like:

=A0 =A0* =A0a common handling is...
=A0 =A0* =A0it is best to...
=A0 =A0* =A0it will typically be safe and helpful to...

=A0 =A0and so on. =A0 /d}


2.2. =A0Examples

=A0 =A0Examples of message content include a number within braces at the en= d
=A0 =A0of each line. =A0These are line numbers for use in subsequent
=A0 =A0discussion, and are not actually part of the message content
=A0 =A0presented in the example.

=A0 =A0Blank lines are not numbered in the examples.

3. =A0Background

=A0 =A0The reader would benefit from reading [EMAIL-ARCH] for some general<= br> =A0 =A0background about the overall email architecture. =A0Of particular =A0 =A0interest is the Internet Message Format, detailed in [MAIL].
=A0 =A0Throughout this document, the use of the term "messsage" s= hould be

{ Freud possibly at work for this missspellling? /d}


=A0 =A0assumed to mean a block of text conforming to the Internet Message =A0 =A0Format.

4. =A0Internal Representations

=A0 =A0Any agent handling a message could have one or two (or more) distinc= t

=A0 =A0 =A0As an agent parses and processes a message, it might create a nu= mber of distinct representations for the message.


=A0 =A0representations of a message it is handling. =A0One is an internal =A0 =A0representation, such as a block of storage used for the header and a=
=A0 =A0block for the body. =A0These may be sorted, encoded, decoded, etc., = as
=A0 =A0per the needs of that particular module. =A0The other is the
=A0 =A0representation that is output to the next agent in the handling
=A0 =A0chain. =A0This might be identical to the version that is input to th= e



Kucherawy & Shapiro =A0 =A0 =A0Expires April 12, 2013 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 [Page 5]
=0C
Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 Safe Mail Handling =A0 =A0 =A0 =A0 = =A0 =A0 =A0 October 2012


=A0 =A0module, or it might have some changes such as added or reordered
=A0 =A0header fields, body modifications to remove malicious content, etc.<= br>
=A0 =A0In some cases, advice is provided only for internal representations.=
=A0 =A0However, there is often occasion to mandate changes to the output as=
=A0 =A0well.

{ What does this last sentence mean? =A0"Mandate"? =A0Perhaps wha= t is meant is: /d}

=A0 =A0 =A0However it is sometimes necessary to make changes between the in= put and output versions, as well.



5. =A0Invariate Content

=A0 =A0 =A0Invariant {?}



=A0 =A0Experience has shown that it is beneficial to ensure that, from the<= br> =A0 =A0first analysis agent at ingress into the destination Administrative<= br> =A0 =A0Management Domain (ADMD; see [EMAIL-ARCH]) to the agent that actuall= y
=A0 =A0affects delivery to the end user, the message each agent sees is

{ This is an artfully-crafted sentence, but it would be easier to read if b= roken into parts. =A0Perhaps: /d}

=A0 =A0 =A0An especially interesting handling sequence occurs within the de= stination Administrative Management Domain (ADMD; see [EMAIL-ARCH]). From i= ngress to the ADMD, through the boundary agent, until delivery to the end u= ser, it is beneficial to ensure that each agent sees an identical form for = the message.


=A0 =A0identical. =A0Absent this, it can be impossible for different agents= in
=A0 =A0the chain to make assertions about the content that correlate.


=A0 =A0 =A0the chain to make consistent assertions about the content.


=A0 =A0For example, suppose a handling agent records that a message had som= e
=A0 =A0specific set of properties at ingress to the ADMD, then permitted it=
=A0 =A0to continue inbound. =A0Some other agent alters the content for some=
=A0 =A0reason. =A0The user, on viewing the delivered content, reports the =A0 =A0message as abusive. =A0If the report is based on the set of properti= es

=A0 =A0 =A0message as abuse. =A0However, report processing often takes plac= e at, or close to, the original point of ingress and is likely to be based = on the set of properties recorded there, rather than at the user's syst= em.


=A0 =A0recorded at ingress, then the complaint effectively references a
=A0 =A0message different from what the user saw, which could render the
=A0 =A0complaint inactionable. =A0Similarly, a message with properties that= a
=A0 =A0filtering agent might use to reject an abusive message could be
=A0 =A0allowed to reach the user if an intermediate agent altered the
=A0 =A0message in a manner that alters one of those properties, thwarting =A0 =A0detection of the abuse.

{ awkward sentence structure. d/}


=A0 =A0Therefore, agents comprising an inbound message processing

=A0 =A0 =A0comprising an inbound =A0-> within an integrated message

{or should this simply say 'within an ADMD'? /d}


=A0 =A0environment SHOULD ensure that each agent sees the same content, and=
=A0 =A0the message reaches the end user unmodified. =A0An exception to this= is
=A0 =A0content that is identitfied as certainly harmful, such as some kind<= br> =A0 =A0of malicious executable software included in the message.

{the 'exception' sentence is far too specific. =A0There are, no dou= bt, many reasons for deviating from this recommendation. =A0Simpler, safer = and non-normative wording would be: =A0/d}

=A0 =A0 =A0environment will simplify operational concerns by ensuring that = each agent receives the same content -- except for the usual handling agent= trace information additions -- and that this is what reaches the end user,= unmodified. =A0Various policies, such as special handling for detected mes= sage abuse, will make exceptions appropriate.


6. =A0Mail Submission Agents

=A0 =A0Within the email context, the single most influential component that=
=A0 =A0can reduce the presence of malformed items in the email system is th= e
=A0 =A0Mail Submission Agent (MSA). =A0This is the component that is
=A0 =A0essentially the interface between end users that create content and<= br> =A0 =A0the mail stream.

=A0 =A0 =A0the Mail Handling Service (MHS) [EMAIL-ARCH]


=A0 =A0The lax processing described earlier in the document creates a high<= br>

{this first sentence is out of place. =A0the earlier discussion in the docu= ment established the need for better conformance; it doesn't need to be= sold here, again. /d}


=A0 =A0support and security cost overall. =A0Thus, MSAs MUST evolve to beco= me
=A0 =A0more strict about enforcement of all relevant email standards,
=A0 =A0especially [MAIL] and the [MIME] family of documents.




Kucherawy & Shapiro =A0 =A0 =A0Expires April 12, 2013 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 [Page 6]
=0C
Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 Safe Mail Handling =A0 =A0 =A0 =A0 = =A0 =A0 =A0 October 2012


=A0 =A0Relay Mail Transport Agents (MTAs) SHOULD also be more strict;

=A0 =A0 =A0Relay -> Relaying

{ This pseudo-normative phrasing does nothing helpful, since it isn't a= ctually specifying anything. =A0Modify to something like: /d}

=A0 =A0 =A0More strict conformance by relaying MTAs also will be helpful. A= lthough


=A0 =A0although preventing the dissemination of malformed messages is
=A0 =A0desirable, the rejection of such mail already in transit also has a<= br> =A0 =A0support cost, namely the creation of a [DSN] that many end users
=A0 =A0might not understand.

7. =A0Line Terminaton

=A0 =A0The only valid line separation sequence in messaging is ASCII 0x0D

=A0 =A0 =A0For interoperable Internet Mail messages, the only valid...


=A0 =A0("carriage return", or CR) followed by ASCII 0x0A ("l= ine feed", or
=A0 =A0LF), commonly referred to as CRLF. =A0Common UNIX user tools, howeve= r,
=A0 =A0typically only use LF for line termination. =A0This means the protoc= ol
=A0 =A0has to convert LF to CRLF before transporting a message.

=A0 =A0 =A0for internal line termination. =A0This means that a protocol eng= ine, which converts between Unix and Internet Mail formats, has to convert = between these two end-of-line representations, before transmitting a messag= e or after receiving it.


=A0 =A0Naive implementations can cause messages to be transmitted with a mi= x

{ These aren't "naive". =A0They are quite simply broken! =A0d= /}

=A0 =A0 =A0Implementations that do not conform to Internet Mail standards s= ometimes cause messages to be transmitted...


=A0 =A0of line terminations, such as LF everywhere except CRLF only at the<= br> =A0 =A0end of the message. =A0According to [SMTP], this means the entire =A0 =A0message actually exists on a single line.

{ also RFC 5322! /d}


=A0 =A0A "naked" CR or LF in a message has no reasonable justific= ation, and

{ this is wrong. =A0they have legitimate presentation uses, albeit pretty a= rchaic at this point. =A0Better: =A0/d }

=A0 =A0 =A0Within modern Internet Mail it is highly unlikely that an isolat= ed CR or LF is valid, in common ASCII text. =A0Furthermore [MIME]...


=A0 =A0furthermore [MIME] presents mechanisms for encoding content that
=A0 =A0actually does need to contain such an unusual character sequence.
=A0 =A0Thus, handling agents MUST treat naked CRs and LFs as CRLFs when
=A0 =A0interpreting the message.

=A0 =A0 =A0Thus, it will typically be safe and helpful to treat a naked CR = or LF as equivalent to a CRLF, when parsing a message.


8. =A0Header Anomalies

=A0 =A0This section covers common syntactical and semantic anomalies found<= br> =A0 =A0in headers of messages, and presents preferred mitigations.

=A0 =A0 =A0in a message header, and


8.1. =A0Converting Obsolete and Invalid Syntaxes

=A0 =A0There are numerous cases of obsolete header syntaxes that can be
=A0 =A0applied to confound agents with variable processing. =A0This section=

{ The phrasing of the first sentence sounds as if confounding is a goal. = =A0If it's meant that way, say it more clearly. =A0If it isn't, per= haps: =A0/d }

=A0 =A0 =A0A message using an obsolete header syntax might confound an agen= t that is attempting to be robust in its handling of syntax variations.


=A0 =A0presents some examples of these. =A0Messages including them SHOULD b= e

{ 'of these'? =A0of which? /d}

{ Why reject this particular set? =A0What about others, outside these examp= les? =A0Again, phrase this non-normatively. /d}


=A0 =A0rejected; where this is not possible, RECOMMENDED internal
=A0 =A0interpretations are provided.

8.1.1. =A0Host-Address Syntax

=A0 =A0The following obsolete syntax:

=A0 =A0 =A0The following obsolete syntax that attempts to specify source ro= uting:

{ explain, or perhaps even cite the old ABNF rule for it /d}



=A0 =A0 =A0 =A0To: <@example.net:fran@example.com>

=A0 =A0should be interpreted as:

=A0 =A0 =A0can safely be interpreted as:


=A0 =A0 =A0 =A0To: <fran@example.com>



Kucherawy & Shapiro =A0 =A0 =A0Expires April 12, 2013 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 [Page 7]
=0C
Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 Safe Mail Handling =A0 =A0 =A0 =A0 = =A0 =A0 =A0 October 2012


8.1.2. =A0Excessive Angle Brackets

=A0 =A0The following over-use of angle brackets, e.g.:

=A0 =A0 =A0 =A0To: <<<user2@example.org>>>

=A0 =A0should be interpreted as:

=A0 =A0 =A0can safely be interpreted as:


=A0 =A0 =A0 =A0To: <user2@example.org>

8.1.3. =A0Unbalanced Angle Brackets

=A0 =A0The following use of unbalanced angle brackets:

=A0 =A0 =A0 =A0To: <another@example.net
=A0 =A0 =A0 =A0To: = second@example.org>

=A0 =A0should be interpreted as:

=A0 =A0 can usually be treated as:


=A0 =A0 =A0 =A0To: <another@example.net>
=A0 =A0 =A0 =A0To: = second@example.org

8.1.4. =A0Unbalanced Parentheses

=A0 =A0The following use of unbalanced parentheses:

=A0 =A0 =A0 =A0To: (Testing <fran@example.com>
=A0 =A0 =A0 =A0To: Testing) <sam@example.com>

=A0 =A0should be interpreted as:

=A0 =A0 =A0 =A0To: (Testing) <fran@example.com>
=A0 =A0 =A0 =A0To: "Testing)" <sam@example.com>

8.1.5. =A0Unbalanced Quotes

=A0 =A0The following use of unbalanced quotation marks:

=A0 =A0 =A0 =A0To: "Joe <joe@example.com>

=A0 =A0should be interpreted as:

=A0 =A0 =A0 =A0To: "Joe <joe@example.com>"@example.net

{ WTF??? And why is this a good fixup, especially given concerns about disp= lay-name attack vectors? =A0/d}


=A0 =A0where "example= .net" is the domain name or host name of the handling
=A0 =A0agent making the interpretation.





Kucherawy & Shapiro =A0 =A0 =A0Expires April 12, 2013 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 [Page 8]
=0C
Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 Safe Mail Handling =A0 =A0 =A0 =A0 = =A0 =A0 =A0 October 2012


8.2. =A0Non-Header Lines

=A0 =A0It has been observed that some messages contain a line of text in th= e

=A0 =A0 =A0Some messages contain a line of...


=A0 =A0header that is not a valid message header field of any kind. =A0For<= br> =A0 =A0example:

=A0 =A0 =A0 =A0From: = user@example.com {1}
=A0 =A0 =A0 =A0To: userpal@example.net {2}
=A0 =A0 =A0 =A0Subject: This is your reminder {3}
=A0 =A0 =A0 =A0about the football game tonight {4}
=A0 =A0 =A0 =A0Date: Wed, 20 Oct 2010 20:53:35 -0400 {5}

=A0 =A0 =A0 =A0Don't forget to meet us for the tailgate party! {7}

=A0 =A0The cause of this is typically a bug in a message generator of some<= br> =A0 =A0kind. =A0Line {4} was intended to be a continuation of line {3}; it<= br> =A0 =A0should have been indented by whitespace as set out in Section 2.2.3<= br> =A0 =A0of [MAIL].

=A0 =A0This anomaly has varying impacts on processing software, depending o= n
=A0 =A0the implementation:

=A0 =A01. =A0some agents choose to separate the header of the message from = the
=A0 =A0 =A0 =A0body only at the first empty line (i.e. a CRLF immediately =A0 =A0 =A0 =A0followed by another CRLF);

=A0 =A02. =A0some agents assume this anomaly should be interpreted to mean = the
=A0 =A0 =A0 =A0body starts at line {4}, as the end of the header is assumed= by
=A0 =A0 =A0 =A0encountering something that is not a valid header field or f= olded
=A0 =A0 =A0 =A0portion thereof;

=A0 =A03. =A0some agents assume this should be interpreted as an intended =A0 =A0 =A0 =A0header folding as described above and thus simply append a s= ingle
=A0 =A0 =A0 =A0space character (ASCII 0x20) and the content of line {4} to = that
=A0 =A0 =A0 =A0of line {3};

=A0 =A04. =A0some agents reject this outright as line {4} is neither a vali= d
=A0 =A0 =A0 =A0header field nor a folded continuation of a header field pri= or to
=A0 =A0 =A0 =A0an empty line.

=A0 =A0This can be exploited if it is known that one message handling agent=
=A0 =A0will take one action while the next agent in the handling chain will=
=A0 =A0take another. =A0Consider, for example, a message filter that search= es
=A0 =A0message headers for properties indicative of abusive of malicious =A0 =A0content that is attached to a Mail Transfer Agent (MTA) implementing=
=A0 =A0option 2 above. =A0An attacker could craft a message that includes t= his
=A0 =A0malformation at a position above the property of interest, knowing =A0 =A0the MTA will not consider that content part of the header, and thus<= br>


Kucherawy & Shapiro =A0 =A0 =A0Expires April 12, 2013 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 [Page 9]
=0C
Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 Safe Mail Handling =A0 =A0 =A0 =A0 = =A0 =A0 =A0 October 2012


=A0 =A0the MTA will not feed it to the filter, thus avoiding detection.
=A0 =A0Meanwhile, the Mail User Agent (MUA) which presents the content to a= n
=A0 =A0end user, implements option 1 or 3, which has some undesirable
=A0 =A0effect.

=A0 =A0It should be noted that a few implementations choose option 4 above<= br> =A0 =A0since any reputable message generation program will get header
=A0 =A0folding right, and thus anything so blatant as this malformation is<= br> =A0 =A0likely an error caused by a malefactor.

=A0 =A0The preferred implementation if option 4 above is not employed is to=
=A0 =A0apply the following heuristic when this malformation is detected:
=A0 =A01. =A0Search forward for an empty line. =A0If one is found, then app= ly
=A0 =A0 =A0 =A0option 3 above to the anomalous line, and continue.

=A0 =A02. =A0Search forward for another line that appears to be a new heade= r
=A0 =A0 =A0 =A0field, i.e., a name followed by a colon. =A0If one is found,= then
=A0 =A0 =A0 =A0apply option 3 above to the anomalous line, and continue.
8.3. =A0Unusual Spacing

=A0 =A0The following message is valid per [MAIL]:

=A0 =A0 =A0 =A0From: = user@example.com {1}
=A0 =A0 =A0 =A0To: userpal@example.net {2}
=A0 =A0 =A0 =A0Subject: This is your reminder {3}
=A0 =A0 =A0 =A0 {4}
=A0 =A0 =A0 =A0 about the football game tonight {5}
=A0 =A0 =A0 =A0Date: Wed, 20 Oct 2010 20:53:35 -0400 {6}

=A0 =A0 =A0 =A0Don't forget to meet us for the tailgate party! {8}

=A0 =A0Line {4} contains a single whitespace. =A0The intended result is tha= t
=A0 =A0lines {3}, {4}, and {5} comprise a single continued header field. =A0 =A0However, some agents are aggressive at stripping trailing whitespace= ,
=A0 =A0which will cause line {4} to be treated as an empty line, and thus =A0 =A0the separator line between header and body. =A0This can affect heade= r-
=A0 =A0specific processing algorithms as described in the previous section.=

=A0 =A0Ideally, this case simply ought not to be generated.

{This sentence is entirely gratuitous. Replace it with: d/ }

=A0 =A0 =A0This example was legal in earlier versions of the Internet Mail = format standard.


=A0 =A0Message handling agents receiving a message bearing this anomaly MUS= T
=A0 =A0behave as if line {4} was not present on the message, and SHOULD emi= t
=A0 =A0a version in which line {4} has been removed.

=A0 =A0 =A0The best handling of this example is for a message parsing engin= e to behave as if line {4} was not present in the message and for a message= creation engine to emit the message with line {4} removed,.






Kucherawy & Shapiro =A0 =A0 =A0Expires April 12, 2013 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0[Page 10]
=0C
Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 Safe Mail Handling =A0 =A0 =A0 =A0 = =A0 =A0 =A0 October 2012


8.4. =A0Header Malformations

=A0 =A0There are various malformations that exist. =A0A common one is

{ The first sentence is pretty obvious: there are always lots of ways to sc= rew up. I suggest dropping it and beginning with something like: =A0/d}

=A0 =A0Among the many possible malformations, a common one is...


=A0 =A0insertion of whitespace at unusual locations, such as:

=A0 =A0 =A0 =A0From: = user@example.com {1}
=A0 =A0 =A0 =A0To: userpal@example.net {2}
=A0 =A0 =A0 =A0Subject: This is your reminder {3}
=A0 =A0 =A0 =A0MIME-Version : 1.0 {4}
=A0 =A0 =A0 =A0Content-Type: text/plain {5}
=A0 =A0 =A0 =A0Date: Wed, 20 Oct 2010 20:53:35 -0400 {6}

=A0 =A0 =A0 =A0Don't forget to meet us for the tailgate party! {8}

=A0 =A0Note the addition of whitespace in line {4} after the header field =A0 =A0name but before the colon that separates the name from the value.
=A0 =A0The acceptance grammar of [MAIL] permits that extra whitespace, so i= t
=A0 =A0cannot be considered invalid. =A0However, a consensus of
=A0 =A0implementations prefers to remove that whitespace. =A0There is no =A0 =A0perceived change to the semantics of the header field being altered<= br> =A0 =A0as the whitespace is itself semantically meaningless. =A0Thus, a mod= ule
=A0 =A0compliant with this memo MUST remove all whitespace after the field<= br> =A0 =A0name but before the colon, and MUST emit that version of that field<= br> =A0 =A0on output.

=A0 =A0 =A0Therefore, it is best to remove all whitespace after the field n= ame but before the colon and to emit the field in this modified form.


8.5. =A0Header Field Counts

=A0 =A0Section 3.6 of [MAIL] prescribes specific header field counts for a<= br> =A0 =A0valid message. =A0Few agents actually enforce these in the sense tha= t a
=A0 =A0message whose header contents exceed one or more limits set there ar= e
=A0 =A0generally allowed to pass; they may add any required fields that are=

=A0 =A0; they typically add any...


=A0 =A0missing, however.

=A0 =A0Also, few agents that use messages as input, including Mail User
=A0 =A0Agents (MUAs) that actually display messages to users, verify that =A0 =A0the input is valid before proceeding. =A0Two popular open source
=A0 =A0filtering programs and two popular Mailing List Management (MLM)

{ I suggest changing 'two' to 'some', since the number migh= t change; there's no reason to make this document get out of date for s= uch a minor issue. /d }


=A0 =A0packages examined at the time this document was written select eithe= r

{ hence, remove "examined at the time this document was written" = /d }


=A0 =A0the first or last instance of a particular field name, such as From,=
=A0 =A0to decide who sent a message. =A0Absent enforcement of [MAIL], an

=A0 =A0 =A0Absent strict enforcement


=A0 =A0attacker can craft a message with multiple fields if that attacker =A0 =A0knows the filter will make a decision based on one but the user will=
=A0 =A0be shown the other.

=A0 =A0This situation is exacerbated when a claim of message validity is =A0 =A0inferred by something like a valid [DKIM] signature. =A0Such a
=A0 =A0signature might cover one instance of a constrained field but not


Kucherawy & Shapiro =A0 =A0 =A0Expires April 12, 2013 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0[Page 11]
=0C
Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 Safe Mail Handling =A0 =A0 =A0 =A0 = =A0 =A0 =A0 October 2012


=A0 =A0another, and a naive consumer of DKIM's output, not realizing wh= ich
=A0 =A0one was covered by a valid signature, could presume the wrong one wa= s
=A0 =A0the "good" one. =A0An MUA, for example could show the firs= t of two From
=A0 =A0fields as "good" or "safe" while the DKIM signat= ure actually only
=A0 =A0verified the second.

{ DKIM signatures do not verify addresses outside d=3D. =A0While the proble= m you are describing is, of course, real, it's far more complicated tha= n you've described here. =A0Perhaps: =A0/d }

=A0 =A0 =A0when message validity is assessed, such as through enhanced auth= entication methods. =A0Such methods might cover one instance of a constrain= ed field but not another, taking the wrong one as "good" or "= ;safe".


=A0 =A0Thus, an agent compliant with this specification MUST enact one of =A0 =A0the following:

=A0 =A0 =A0In attempting to counter this exposure, one of the following can= be enacted:


=A0 =A01. =A0reject outright or refuse to process further any input message=
=A0 =A0 =A0 =A0that does not conform to Section 3.6 of [MAIL];

=A0 =A02. =A0remove or, in the case of an MUA, refuse to render any instanc= es
=A0 =A0 =A0 =A0of a header field whose presence exceeds a limit prescribed = in
=A0 =A0 =A0 =A0Section 3.6 of [MAIL] when generating its output;

=A0 =A03. =A0alter the name of any header field whose presence exceeds a li= mit
=A0 =A0 =A0 =A0prescribed in Section 3.6 of [MAIL] when generating its outp= ut so
=A0 =A0 =A0 =A0that later agents can produce a consistent result. =A0Any =A0 =A0 =A0 =A0alteration likely to cause the field to be ignored by downst= ream
=A0 =A0 =A0 =A0agents is acceptable. =A0A common approach is to prefix the = field
=A0 =A0 =A0 =A0names with a string such as "BAD-".

{ it would help if there were some rationales or analyses of the tradeoffs = amongst these kinds of choices, to help the implementer/operator decide whe= n to use which. =A0/d }



8.6. =A0Missing Header Fields

=A0 =A0Similar to the previous section, there are messages seen in the wild=
=A0 =A0that lack certain required header fields. =A0For example, [MAIL]
=A0 =A0requires that a From and Date field be present in all messages.

{ I think these aren't 'examples' but constitute the entire lis= t. =A0If there are other required fields that can be classed as 'missin= g', this section should list them. =A0Also, since Message-ID isn't = 'required', the phrasing here doesn't quite match what's di= scussed in the section. Might be worth distinguishing "required but mi= ssing" vs. "optional but really useful and worth synthesizing&quo= t;. =A0Synthesizing the latter probably isn't dangerous. =A0Synthesizin= g the former always is... d/}



=A0 =A0When presented with a message lacking these fields, the MTA might =A0 =A0perform one of the following:

=A0 =A01. =A0Make no changes

=A0 =A02. =A0Add an instance of the missing field(s) using synthesized cont= ent

=A0 =A0 =A03. =A0Reject the message


=A0 =A0Option 2 is RECOMMENDED for handling this case. =A0Handling agents

{ Wow! =A0Synthesizing a From: field strikes me as especially dangerous, in= all cases. =A0The rationale provided, below, needs to state this and, I be= lieve, explain how and why it is worth incurring. The explanation that is p= rovided essentially define this hack as an attack vector... /d}


=A0 =A0SHOULD add these for internal hanlding if they are missing, but MUST=
=A0 =A0NOT add them to the external representation. =A0The reason for this<= br> =A0 =A0requirement is that there are some filter modules that would conside= r
=A0 =A0the absence of such fields to be a condition warranting special
=A0 =A0treatment (e.g., rejection), and thus the effectiveness of such
=A0 =A0modules would be stymied by an upstream filter adding them.

=A0 =A0The synthesized fields SHOULD contain a best guess as to what should=
=A0 =A0have been there; for From, the SMTP MAIL command's address can b= e
=A0 =A0used (if not null) or a placeholder address followed by an address =A0 =A0literal (e.g., unknown@[192.0.2.1]); for Date, a date extracted from=



Kucherawy & Shapiro =A0 =A0 =A0Expires April 12, 2013 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0[Page 12]
=0C
Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 Safe Mail Handling =A0 =A0 =A0 =A0 = =A0 =A0 =A0 October 2012


=A0 =A0a Received field is a reasonable choice.

=A0 =A0One other important case to consider is a missing Message-Id field.<= br> =A0 =A0An MTA that encounters a message missing this field SHOULD synthesiz= e
=A0 =A0a valid one using techniques described above and add it to the
=A0 =A0external rpresentation, since many deployed tools use the content of=
=A0 =A0that field as a common unique message reference, so its absence
=A0 =A0inhibits correlation of message processing. =A0One possible synthesi= s
=A0 =A0would be based on based on an encoding of the current date/time and<= br> =A0 =A0an internal MTA ID (e.g., queue ID) followed by @ and the fully
=A0 =A0qualified hostname of the machine synthesizing the header value. =A0= For
=A0 =A0example:

=A0 =A0 =A0 =A0tm =3D gmtime(&now);
=A0 =A0 =A0 =A0(void) snprintf(buf, sizeof(buf), "%04d%02d%02d%02d%02d= .%s@%s",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tm->tm_year + 1900, tm-&g= t;tm_mon + 1, tm->tm_mday,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tm->tm_hour, tm->tm_mi= n, queueID, fqhn);

8.7. =A0Eight-Bit Data

=A0 =A0Standards-compliant mail messages do not contain any non-ASCII data<= br> =A0 =A0without indicating that such content is present by means of publishe= d
=A0 =A0[SMTP] extensions. =A0Absent that, [MIME] encodings are typically us= ed

Overall, the document sometimes mixes transfer issues with data representat= ion (object) issues, in ways that can be confusing. =A0This paragraph is on= e of those. =A0It's worth the extra verbosity to label each clearly and= separately. =A0So, for example:

=A0 =A0 =A0Standards-compliant mail messages that contain non-ASCII data ar= e required to self-label this through the use of [MIME]. =A0If the represen= tation of the non-ASCII data is in an 8-bit mode (rather than special encod= ing so that it retains a 7-bit base), then this must be signaled through th= e use of [SMTP] extensions.


> =A0 =A0without indicating that such content is present by means of pub= lished
> =A0 =A0[SMTP] extensions.

=A0 =A0to convert non-ASCII data to ASCII in a way that can be reversed by<= br> =A0 =A0other handling agents or end users.

=A0 =A0Non-ASCII data otherwise found in messages can confound code that is=
=A0 =A0used to analyze content. =A0For example, a null (ASCII 0x00) byte =A0 =A0inside a message can cause typical string processing functions to =A0 =A0mis-identify the end of a string, which can be exploited to hide
=A0 =A0malicious content from analysis processes.

=A0 =A0Handling agents MUST reject messages containing null bytes that are<= br> =A0 =A0not encoded in some standard way, and SHOULD reject other non-ASCII<= br> =A0 =A0bytes that are similarly not encoded. =A0If rejection is not done, a= n
=A0 =A0ASCII-compatible encoding such as those defined in [MIME] SHOULD be<= br> =A0 =A0used.

{ Hmmm. =A0It occurs to me that the document might be helped by an early di= scussion about a/the 'philosophy' that guides choosing whether to r= eject a message versus repair it. =A0But I don't have any clever text t= o suggest for doing this... /d}



9. =A0MIME Anomalies

=A0 =A0[MIME], et seq, define a mechanism of message extensions for

{ perhaps quibbling, but since MIME does a variety of things, including thi= s one, I suggest:

=A0 =A0 =A0define -> includes


=A0 =A0providing text in character sets other than ASCII, non-text
=A0 =A0attachments to messages, multi-part message bodies, and similar
=A0 =A0facilities.

=A0 =A0Some anomalies with MIME-compliant generation are also common. =A0Th= is
=A0 =A0section discusses some of those and presents preferred mitigations.<= br>



Kucherawy & Shapiro =A0 =A0 =A0Expires April 12, 2013 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0[Page 13]
=0C
Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 Safe Mail Handling =A0 =A0 =A0 =A0 = =A0 =A0 =A0 October 2012


9.1. =A0Header Field Names

=A0 =A0[MAIL] permits header field names to begin with "--". =A0T= his means
=A0 =A0that a header field name can look like a [MIME] multipart boundary.<= br> =A0 =A0For example:

=A0 =A0 =A0--foo:bar

=A0 =A0This is a legal header field, whose name is "--foo" and wh= ose value
=A0 =A0is "bar". =A0Thus, consider this header:

=A0 =A0 =A0 =A0From: = user@example.com {1}
=A0 =A0 =A0 =A0To: userpal@example.net {2}
=A0 =A0 =A0 =A0Subject: This is your reminder {3}
=A0 =A0 =A0 =A0Date: Wed, 20 Oct 2010 20:53:35 -0400 {4}
=A0 =A0 =A0 =A0MIME-Version: 1.0 {5}
=A0 =A0 =A0 =A0Content-Type: multipart/mixed; boundary=3D"foo:bar"= ; {6}
=A0 =A0 =A0 =A0--foo:bar {7}
=A0 =A0 =A0 =A0Malicious-Content: muahaha {8}

=A0 =A0One implementation could observe that line {7} announces the
=A0 =A0beginning of the first MIME part while another considers it a part o= f
=A0 =A0the message's header.

=A0 =A0If rejection of such messages cannot be done, agents MUST treat line=
=A0 =A0{7} as part of the message's header block and not a MIME boundar= y.

{ Under what circumstances can rejection /not/ be done??? And what is invol= ved in even detecting that it isn't a mime boundary? =A0d/ }



9.2. =A0Missing MIME-Version Field

=A0 =A0Any message that uses [MIME] constructs is required to have a MIME-<= br> =A0 =A0Version header field. =A0Without them, the Content-Type and associat= ed
=A0 =A0fields have no semantic meaning.

=A0 =A0 =A0them -> it


=A0 =A0It is often observed that a message has complete MIME structure, yet=
=A0 =A0lacks this header field.

=A0 =A0As described at the end of Section 8.2, this is not expected from a<= br>

=A0 =A0 =A0this -> this omission


=A0 =A0reputable content generator and is often an indication of mass-
=A0 =A0produced spam or other undesirable messages.

=A0 =A0Therefore, an agent compliant with this specification MUST internall= y
=A0 =A0enact one or more of the following in the absence of a MIME-Version<= br> =A0 =A0header field:

=A0 =A01. =A0Ignore all other MIME-specific fields, even if they are
=A0 =A0 =A0 =A0syntactically valid, thus treating the entire message as a =A0 =A0 =A0 =A0single-part message of type text/plain;

{ Offhand, this sounds like a potentially-interesting attack vector. =A0/d}=



Kucherawy & Shapiro =A0 =A0 =A0Expires April 12, 2013 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0[Page 14]
=0C
Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 Safe Mail Handling =A0 =A0 =A0 =A0 = =A0 =A0 =A0 October 2012


=A0 =A02. =A0Remove all other MIME-specific fields, even if they are
=A0 =A0 =A0 =A0syntactically valid, both internally and when emitting the o= utput
=A0 =A0 =A0 =A0version of the message;

10. =A0Body Anomalies

10.1. =A0Oversized Lines

=A0 =A0A message containing a line of content that exceeds 998 characters =A0 =A0plus the line terminator (1000 total) violates Section 2.1.1 of
=A0 =A0[MAIL]. =A0Some handling agents may not look at content in a single<= br> =A0 =A0line past the first 998 bytes, providing bad actors an opportunity t= o
=A0 =A0hide malicious content.

=A0 =A0There is no specified way to handle such messages, other than to
=A0 =A0observe that they are non-compliant and reject them, or rewrite the<= br> =A0 =A0oversized line such that the message is compliant.

=A0 =A0Handling agents MUST take one of the following actions:

=A0 =A01. =A0Break such lines into multiple lines at a position that does n= ot
=A0 =A0 =A0 =A0change the semantics of the text being thus altered. =A0For<= br> =A0 =A0 =A0 =A0example, breaking an oversized line such that a [URI] then s= pans
=A0 =A0 =A0 =A0two lines could inhibit the proper identification of that UR= I.

=A0 =A02. =A0Rewrite the MIME part (or the entire message if not MIME) that=
=A0 =A0 =A0 =A0contains the excessively long line using a content encoding = that
=A0 =A0 =A0 =A0breaks the line in the transmission but would still result i= n the
=A0 =A0 =A0 =A0line being intact on decoding for presentation to the user. = =A0Both
=A0 =A0 =A0 =A0of the encodings declared in [MIME] can accomplish this.

11. =A0Security Considerations

=A0 =A0The discussions of the anomalies above and their prescribed solution= s
=A0 =A0are themselves security considerations. =A0The practises enumerated = in
=A0 =A0this memo are generally perceived as attempts to resolve security =A0 =A0considerations that already exist rather than introducing new ones.<= br>

{ Hmmm. =A0Whereas I think the document introduces quite a few attack vecto= rs that probably aren't discussed in other email specifications. /d}


12. =A0IANA Considerations

=A0 =A0This memo contains no actions for IANA.

=A0 =A0[RFC Editor: Please remove this section prior to publication.]

13. =A0References






Kucherawy & Shapiro =A0 =A0 =A0Expires April 12, 2013 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0[Page 15]
=0C
Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 Safe Mail Handling =A0 =A0 =A0 =A0 = =A0 =A0 =A0 October 2012


13.1. =A0Normative References

=A0 =A0[KEYWORDS] =A0 =A0Bradner, S., "Key words for use in RFCs to In= dicate
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Requirement Levels", BCP 14, RFC 21= 19, March 1997.

=A0 =A0[MAIL] =A0 =A0 =A0 =A0Resnick, P., "Internet Message Format&quo= t;, RFC 5322,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October 2008.

13.2. =A0Informative References

=A0 =A0[DKIM] =A0 =A0 =A0 =A0Allman, E., Callas, J., Delany, M., Libbey, M.= , Fenton,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0J., and M. Thomas, "DomainKeys Iden= tified Mail (DKIM)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Signatures", RFC 4871, May 2007.
=A0 =A0[DSN] =A0 =A0 =A0 =A0 Moore, K. and G. Vaudreuil, "An Extensibl= e Message
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Format for Delivery Status Notifications= ", RFC 3464,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0January 2003.

=A0 =A0[EMAIL-ARCH] =A0Crocker, D., "Internet Mail Architecture",= RFC 5598,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0July 2009.

=A0 =A0[MIME] =A0 =A0 =A0 =A0Freed, N. and N. Borenstein, "Multipurpos= e Internet
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mail Extensions (MIME) Part One: Format = of Internet
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Message Bodies", RFC 2045, November= 1996.

=A0 =A0[RFC822] =A0 =A0 =A0Crocker, D., "Standard for the Format of In= ternet Text
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Messages", RFC 822, August 1982.
=A0 =A0[SMTP] =A0 =A0 =A0 =A0Klensin, J., "Simple Mail Transfer Protoc= ol", RFC 5321,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0October 2008.

=A0 =A0[URI] =A0 =A0 =A0 =A0 Berners-Lee, T., Fielding, R., and L. Masinter= ,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"Uniform Resource Identifier (URI):= Generic Syntax",
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0RFC 3986, January 2005.

Appendix A. =A0Acknowledgements

=A0 =A0The author wishes to acknowledge the following for their review and<= br> =A0 =A0constructive criticism of this proposal: Tony Hansen, and Franck
=A0 =A0Martin

Authors' Addresses

=A0 =A0Murray S. Kucherawy

=A0 =A0EMail: supe= ruser@gmail.com





Kucherawy & Shapiro =A0 =A0 =A0Expires April 12, 2013 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0[Page 16]
=0C
Internet-Draft =A0 =A0 =A0 =A0 =A0 =A0 Safe Mail Handling =A0 =A0 =A0 =A0 = =A0 =A0 =A0 October 2012


=A0 =A0Gregory N. Shapiro

=A0 =A0EMail: gs= hapiro@sendmail.com
















































Kucherawy & Shapiro =A0 =A0 =A0Expires April 12, 2013 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0[Page 17]
=0C

--
=A0Dave Crocker
=A0Brandenburg InternetWorking
=A0bbiw.net

--047d7b86de326670fd04dc07005f-- From Claudio.Allocchio@garr.it Mon May 6 01:04: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 0773121F8EFD; Mon, 6 May 2013 01:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[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 GQZMChzcCqd4; Mon, 6 May 2013 01:04:46 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id D117D21F8EFC; Mon, 6 May 2013 01:04:45 -0700 (PDT) Received: internal info suppressed Date: Mon, 6 May 2013 10:04:41 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: draft-ietf-dhc-triggered-reconfigure.all@tools.ietf.org, apps-discuss@ietf.org, iesg@ietf.org Message-ID: User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-889524015-1367827483=:12855" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1367827484; bh=NdvjyJwGJNm3E98mGYnIMaUwBroTQZ1atX+orpd63HA=; h=Date:From:To:Subject; b=UqOCF9r0PxVdwPprNorlrOwnyKD2RNaFhFZvJHfLMQj9rOQh0QE1Ogr+M+16PvcdT CgjZLWkJ66EqYNVZHIhgL12KLYHzNHaqcisYTg0ZXX5ka4c569gUQnW7iTOM09oSMy KaaTcNZwpDlnj84HdirSqAFKbsxaMJvs9t+kqg6U= Subject: [apps-discuss] APPSDIR review of draft-ietf-dhc-triggered-reconfigure-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: Mon, 06 May 2013 08:04:50 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-889524015-1367827483=:12855 Content-Type: TEXT/PLAIN; format=flowed; charset=UTF-8 Content-Transfer-Encoding: 8BIT 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-dhc-triggered-reconfigure-05 Title: Reconfigure Triggered by DHCPv6 Relay Agents Reviewer: Claudio Allocchio Review Date: May 06th 2013 IETF Last Call Date: April 4th 2013 IESG Telechat Date: ? Summary: the draft clearly specify the problem and the solution. Cross references to the documents it updates are also clear and complete. I think the document is ready for publication. I just have a very monor issu/suggestion, but the document could go "as is" for approval. Major Issues: none. Minor Issues: 7. Rate Limiting Considerations ... what about just mentioning that this rete limiting is also useful to avoid DoS attacks, too? It is not really an issue, maybe it's so obvious that you do not need to mention it, but... Nits: it's really a matter of taste... but I would rename chapter 3 as 3. Problem Statement ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca --0-889524015-1367827483=:12855-- From prvs=08380a135a=salvatore.loreto@ericsson.com Mon May 6 03:35: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 8C24D21F8556 for ; Mon, 6 May 2013 03:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.248 X-Spam-Level: X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 5+dCsNXk9kki for ; Mon, 6 May 2013 03:35:35 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 11B8C21F89B0 for ; Mon, 6 May 2013 03:35:34 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-dd-518787753e65 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 20.29.32006.57787815; Mon, 6 May 2013 12:35:34 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Mon, 6 May 2013 12:35:33 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id EC99F22F8; Mon, 6 May 2013 13:35:32 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3175654A19; Mon, 6 May 2013 13:35:32 +0300 (EEST) Received: from n94.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E0DD2523A1; Mon, 6 May 2013 13:35:31 +0300 (EEST) Message-ID: <51878774.10607@ericsson.com> Date: Mon, 6 May 2013 13:35:32 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , Peter Saint-Andre Content-Type: multipart/alternative; boundary="------------080800000205090403010906" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUyM+JvrW5Ze3ugQftOXovVL1ewWRzb08/s wOSxZMlPJo+5e14wBzBFcdskJZaUBWem5+nbJXBn9F3hLFgrXzFn1l/mBsZ2yS5GTg4JAROJ 3k1tjBC2mMSFe+vZuhi5OIQETjFKbFp4nBXCWc8osbWjmxnC2c0o8XrxEqjMOkaJtvv3oHqW MUo09p1g72Lk4OAV0JTov5MOMpdFQEVi5oaXTCA2m4CZxPOHW5hBSkQFkiX+7/AGCfMKCEqc nPmEBcQWEYiTmD21jQ3EFhawluj4sQAsziwQJnFw/n4miFPVJK6e28QMYgsJaEn0nu1kmsAo OAvJqFlIWiBsW4kLc65DxeUltr+dwwxh60pc+D8FRXwBI9sqRvbcxMyc9HKjTYzA8D645bfq DsY750QOMUpzsCiJ8yZzNQYKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4AQRXFINjK1NF7TbZLj5 avf4cmYURV+suPxJkf3pNQaLhpuBQYFOfPW6Ke9+G5yd+uErz2PzXq4KqR/cl8Rq1fy45h15 bbZVSzcsi12A+cnF220CTB92WWfl1SrK/V/GcVb4lOjxxWlbJlnscVhkc/obr3v4zVPnL3dI MYY0hHvWLpjE3tDU6febW1xXiaU4I9FQi7moOBEAV2ZUCEICAAA= Subject: [apps-discuss] APPSDIR review: draft-saintandre-impp-call-info-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: Mon, 06 May 2013 10:35:40 -0000 --------------080800000205090403010906 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed 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-saintandre-impp-call-info-02 Title: Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP) Reviewer: Salvatore Loreto Review Date: May-06-2013 IETF Last Call Date: IESG Telechat Date: Summary: This draft is ready for publication as Standards Track. It is short and straightforward, it only registers 'impp' as a new value for the "purpose" header field parameter of the Call-Info SIP header. Major Issues: 0 Minor Issues: 2 Nits: 0 Minor: ----- - maybe it could be useful expand the CUSAX acronym in Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (CUSAX), for the people not familiar with SIP-XMPP interwork terminology - a short example can also help, something like Call-Info:;purpose=impp best regards Salvatore -- Salvatore Loreto, PhD www.sloreto.com --------------080800000205090403010906 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-saintandre-impp-call-info-02
Title: Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP)
Reviewer: Salvatore Loreto
Review Date: May-06-2013
IETF Last Call Date: 
IESG Telechat Date:


Summary: This draft is ready for publication as Standards Track.
It is short and straightforward, it only registers 'impp' as a new value for the "purpose" header field parameter of the Call-Info SIP header.

Major Issues: 0
Minor Issues: 2
Nits: 0

Minor:
-----
- maybe it could be useful expand the CUSAX acronym in
Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (CUSAX),
for the people not familiar with SIP-XMPP interwork terminology

- a short example can also help, something like Call-Info:<XXXXXX>;purpose=impp


best regards
Salvatore 
-- 
Salvatore Loreto, PhD
www.sloreto.com
--------------080800000205090403010906-- From stpeter@stpeter.im Mon May 6 08:31: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 422E121F8F03 for ; Mon, 6 May 2013 08:31:05 -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 KDcosZoBiYjZ for ; Mon, 6 May 2013 08:30:59 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 756D021F9017 for ; Mon, 6 May 2013 08:30:58 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3A4FCE8271; Mon, 6 May 2013 09:42:29 -0600 (MDT) Message-ID: <5187CCAE.90701@stpeter.im> Date: Mon, 06 May 2013 09:30:54 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Salvatore Loreto References: <51878774.10607@ericsson.com> In-Reply-To: <51878774.10607@ericsson.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: yana@jitsi.org, "apps-discuss@ietf.org" , draft-saintandre-impp-call-info@tools.ietf.org Subject: Re: [apps-discuss] APPSDIR review: draft-saintandre-impp-call-info-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: Mon, 06 May 2013 15:31:05 -0000 Hi Sal, thanks for the review. On 5/6/13 4:35 AM, Salvatore Loreto wrote: > Minor: > ----- > - maybe it could be useful expand the CUSAX acronym in > Combined Use of the Session Initiation Protocol (SIP) and the Extensible > Messaging and Presence Protocol (CUSAX), > for the people not familiar with SIP-XMPP interwork terminology The test right before that says: endpoints that support the combined use of the Session Initiation Protocol (SIP) [RFC3261] and the Extensible Messaging and Presence Protocol (XMPP) [RFC6120] (so-called "CUSAX" endpoints But the expansion of the acronym gets lost with the RFC citations and such. :-) > - a short example can also help, something like > Call-Info:;purpose=impp Good idea, I'll add that. Peter From vesely@tana.it Mon May 6 09:29: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 70B6521F86F2 for ; Mon, 6 May 2013 09:29:46 -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 1GOJDeongEOW for ; Mon, 6 May 2013 09:29:42 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5312D21F8717 for ; Mon, 6 May 2013 09:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1367857780; bh=N+2fDMDsFtm1Jm1R5zyrk6Rvvna7JwEvt4SJUUs9khs=; l=3321; h=Date:From:To:References:In-Reply-To; b=GXG7Jx7Fy0uPqTTYDg5qDzLc8Q9IiDIwRFph3GKi5e1ENPWi4HsbxJeKRlAg9hEiD qOps7m1Op3JS0jqjDx9MMtxOxRgri/cYMImUDjjPsOWN8S1fSZZ+wqs9tS4sWe2qFj /23BBJ3VM1VFpQ7YKIAVyE3Bn6b/tzRe+3flwTJ8= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Mon, 06 May 2013 18:29:40 +0200 id 00000000005DC02B.000000005187DA74.00006380 Message-ID: <5187DA74.9020204@tana.it> Date: Mon, 06 May 2013 18:29:40 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> In-Reply-To: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-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, 06 May 2013 16:29:46 -0000 On Fri 03/May/2013 23:26:14 +0200 S Moonesamy wrote: > > This message initiates a two weeks WGLC on > draft-ietf-appsawg-rfc5451bis-00 ("Message Header Field for Indicating > Message Authentication Status") [1]. Please send your comments to the > mailing list before the end of Friday May 17. Comments saying that > you reviewed the draft and you are happy for it to be sent for IETF > Last Call are also valuable. Some comments: The -00 version still says "Individual submission". Shouldn't that be changed to Network Working Group or some such? 1.3. *Processing Scope* The sentence "It is not meant to address the security of [...]" seems to refer to the addition of the field only, not its use by a consumer. For clarity, I'd s/It/The addition of this field/ or similar wording. It may be worth to mention that the field can qualify reported or attached messages if trusted, and that ARF uses it in its machine-readable part. 2.2. *Formal Definition* There is a mismatch "authres-version" != "authserv-version". 2.3. *Authentication Identifier Field* I tend to associate syntax with production rules, so I'm unable to make sense of the sentence: This is similar in syntax to a fully-qualified domain name. In the next paragraph, there is a difficult sentence: The uniqueness of the identifier MUST be guaranteed by the ADMD that generates it and MUST pertain to exactly that one ADMD. What is actually required is not the "uniqueness" of the identifier, but the ability to univocally identify the responsible ADMD using the identifier. I'd suggest to rephrase the sentence accordingly. 2.5.2. *SPF and Sender-ID Results* I propose to delete the list of results: Since they are already defined in the relevant RFCs, it is not clear if the I-D means to update those definitions, redefine them from scratch, or just refer to the existing definitions. I'd propose the following instead: The values "none", "neutral", "pass", "fail", "softfail", "temperror", and "permerror" are the possible results of the check_host() function. One of them can be reported as the corresponding method's result, along with the "ptype.property" of the argument actually used to obtain it. In case multiple checks gave the same result, multiple propspec can be given for it. The definition of "policy" has to given in any case. For a nit, I think it might be a better example to rewrite the last but one paragraph as: The "policy" result would be returned if, for example, [SPF] returned as "pass" result, but the local policy check finds that the sender's policy is unacceptable (e.g. terminates with "+all"). 6.3. *Email Authentication Result Name Registry* OLD All existing registry entries that reference [AR-ORIG] are to be updated to reference this document. NEW All existing registry entries that reference [AR-ORIG] are to be updated to reference this document. Where the meaning refers to section 2.4.* it has to be changed to section 2.5.*, due to the insertion of a new Section 2.4 in this document. 8.1. *Normative References* [AR-ORIG] will be obsolete by the time this I-D is published. How can it be a normative reference? > 1. http://tools.ietf.org/html/draft-ietf-appsawg-rfc5451bis-00 From superuser@gmail.com Mon May 6 13:43:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8855E21F8E6D for ; Mon, 6 May 2013 13:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 MjY0dcrUyAjM for ; Mon, 6 May 2013 13:43:55 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 39FD521F8E49 for ; Mon, 6 May 2013 13:43:55 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id s10so3369244wey.17 for ; Mon, 06 May 2013 13:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=25F8mxXoOFG42Ns5YLF5ajrArZiltCDDgtw5Z35NJKw=; b=BRHQMJRNU0EzmsH+gK2yFF60Fy5c1iEwS3VHkHgZhq0sHmskp/MxnlIkJCEH9189or zFyR1wHZzC+GMfjYZ5pSy0M0QOjO6gVvcMGvgFdObc6YE6LoBYRrd4RSUPmxZB7o/0dg q5tcEo01gBqZ42EQRM/v+FAcJaLa8djeMYGyp+pEs1VO9pyihzwelradsDguaAG5ZL5B bihugk3wlBQvXendZIPo6yYjFHOil6NHJv4YUGURS7c9Np4qHdUbKDy9cPrO0G2en+F/ AdLHy6RpAvJA8nKPB8+Qwbpwxj87hWXwESZguf7S3Cwegwih+nfDz8Ax52bCQsWqCNBD 62zg== MIME-Version: 1.0 X-Received: by 10.195.12.228 with SMTP id et4mr22646523wjd.59.1367873034194; Mon, 06 May 2013 13:43:54 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Mon, 6 May 2013 13:43:54 -0700 (PDT) In-Reply-To: <5187DA74.9020204@tana.it> References: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> <5187DA74.9020204@tana.it> Date: Mon, 6 May 2013 13:43:54 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=047d7bb04ad84d172e04dc12c24d Cc: IETF Apps Discuss Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-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, 06 May 2013 20:43:56 -0000 --047d7bb04ad84d172e04dc12c24d Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 6, 2013 at 9:29 AM, Alessandro Vesely wrote: > The -00 version still says "Individual submission". Shouldn't that be > changed to Network Working Group or some such? > The RFC Editor always changes that to Network Working Group. It's probably only there because I copied the XML from some other draft that had it. Safe to ignore. > > 1.3. *Processing Scope* > > The sentence "It is not meant to address the security of [...]" seems > to refer to the addition of the field only, not its use by a consumer. > For clarity, I'd s/It/The addition of this field/ or similar wording. > It may be worth to mention that the field can qualify reported or > attached messages if trusted, and that ARF uses it in its > machine-readable part. > Although you're right about the intent of the document, the point of this section is to indicate that it covers entire messages only, not encapsulated messages. It doesn't have anything to do with the consumer. > > 2.2. *Formal Definition* > > There is a mismatch "authres-version" != "authserv-version". > Right; fixed. > 2.3. *Authentication Identifier Field* > > I tend to associate syntax with production rules, so I'm unable to > make sense of the sentence: > > This is similar in syntax to a fully-qualified domain name. > You're aware of how this works; what would you suggest? The ABNF is "value" because it is usually an FQDN, but we also say that it doesn't have to be. > In the next paragraph, there is a difficult sentence: > > The uniqueness of the identifier MUST be guaranteed by the ADMD > that generates it and MUST pertain to exactly that one ADMD. > > What is actually required is not the "uniqueness" of the identifier, > but the ability to univocally identify the responsible ADMD using the > identifier. I'd suggest to rephrase the sentence accordingly. > Are those not synonymous? From the perspective of a module consuming this field, it has to be the case that such a module can safely assume that a field bearing the authserv-id it expects (or one of a set, perhaps) can be trusted. > > 2.5.2. *SPF and Sender-ID Results* > > I propose to delete the list of results: Since they are already > defined in the relevant RFCs, it is not clear if the I-D means to > update those definitions, redefine them from scratch, or just refer to > the existing definitions. I'd propose the following instead: > > The values "none", "neutral", "pass", "fail", "softfail", > "temperror", and "permerror" are the possible results of the > check_host() function. One of them can be reported as the > corresponding method's result, along with the "ptype.property" of > the argument actually used to obtain it. In case multiple checks > gave the same result, multiple propspec can be given for it. > Good idea. Done. > > The definition of "policy" has to given in any case. For a nit, I > think it might be a better example to rewrite the last but one > paragraph as: > > The "policy" result would be returned if, for example, [SPF] > returned as "pass" result, but the local policy check finds that > the sender's policy is unacceptable (e.g. terminates with "+all"). > I don't agree with including that specific example, as it encourages a particular local policy debate that I don't think this document should approach. > > 6.3. *Email Authentication Result Name Registry* > > OLD > All existing registry entries that reference [AR-ORIG] are to be > updated to reference this document. > NEW > All existing registry entries that reference [AR-ORIG] are to be > updated to reference this document. Where the meaning refers to > section 2.4.* it has to be changed to section 2.5.*, due to the > insertion of a new Section 2.4 in this document. > Good point, but rather than doing this, I've added a note to the editor to make sure the section numbers line up right before publication, in case they change again. We can deal with that during the IANA Actions phase of publication. > > > 8.1. *Normative References* > > [AR-ORIG] will be obsolete by the time this I-D is published. How can > it be a normative reference? > > > That's a good procedural question. I think it has to be because it involves IANA actions that are being amended, but I think this is something that can be sorted out during IESG Evaluation. Thanks! -MSK --047d7bb04ad84d172e04dc12c24d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, May 6, 2013 at 9:29 AM, Alessandro Vesely <vesely@ta= na.it> wrote:
The -00 version still says "Individual = submission". =A0Shouldn't that be
changed to Network Working Group or some such?

The RFC Editor always changes that to Network Working Group.=A0 It&= #39;s probably only there because I copied the XML from some other draft th= at had it.=A0 Safe to ignore.
=A0

1.3. *Processing Scope*

The sentence "It is not meant to address the security of [...]" s= eems
to refer to the addition of the field only, not its use by a consumer.
=A0For clarity, I'd s/It/The addition of this field/ or similar wording= .
=A0It may be worth to mention that the field can qualify reported or
attached messages if trusted, and that ARF uses it in its
machine-readable part.

Although you'= ;re right about the intent of the document, the point of this section is to= indicate that it covers entire messages only, not encapsulated messages.= =A0 It doesn't have anything to do with the consumer.
=A0

2.2. *Formal Definition*

There is a mismatch "authres-version" !=3D "authserv-version= ".

Right; fixed.


2.3. *Authentication Identifier Field*

I tend to associate syntax with production rules, so I'm unable to
make sense of the sentence:

=A0 =A0This is similar in syntax to a fully-qualified domain name.

You're aware of how this works; what would you s= uggest?=A0 The ABNF is "value" because it is usually an FQDN, but= we also say that it doesn't have to be.


In the next paragraph, there is a difficult sentence:

=A0 =A0The uniqueness of the identifier MUST be guaranteed by the ADMD
=A0 =A0that generates it and MUST pertain to exactly that one ADMD.

What is actually required is not the "uniqueness" of the identifi= er,
but the ability to univocally identify the responsible ADMD using the
identifier. =A0I'd suggest to rephrase the sentence accordingly.

Are those not synonymous?=A0 From the perspec= tive of a module consuming this field, it has to be the case that such a mo= dule can safely assume that a field bearing the authserv-id it expects (or = one of a set, perhaps) can be trusted.
=A0

2.5.2. *SPF and Sender-ID Results*

I propose to delete the list of results: =A0Since they are already
defined in the relevant RFCs, it is not clear if the I-D means to
update those definitions, redefine them from scratch, or just refer to
the existing definitions. =A0I'd propose the following instead:

=A0 =A0The values "none", "neutral", "pass", = "fail", "softfail",
=A0 =A0"temperror", and "permerror" are the possible re= sults of the
=A0 =A0check_host() function. =A0One of them can be reported as the
=A0 =A0corresponding method's result, along with the "ptype.proper= ty" of
=A0 =A0the argument actually used to obtain it. =A0In case multiple checks<= br> =A0 =A0gave the same result, multiple propspec can be given for it.

Good idea.=A0 Done.
=A0

The definition of "policy" has to given in any case. =A0For a nit= , I
think it might be a better example to rewrite the last but one
paragraph as:

=A0 =A0The "policy" result would be returned if, for example, [SP= F]
=A0 =A0returned as "pass" result, but the local policy check find= s that
=A0 =A0the sender's policy is unacceptable (e.g. terminates with "= +all").

I don't agree with inc= luding that specific example, as it encourages a particular local policy de= bate that I don't think this document should approach.
=A0

6.3. *Email Authentication Result Name Registry*

OLD
=A0 =A0All existing registry entries that reference [AR-ORIG] are to be
=A0 =A0updated to reference this document.
NEW
=A0 =A0All existing registry entries that reference [AR-ORIG] are to be
=A0 =A0updated to reference this document. =A0Where the meaning refers to =A0 =A0section 2.4.* it has to be changed to section 2.5.*, due to the
=A0 =A0insertion of a new Section 2.4 in this document.

Good point, but rather than doing this, I've added a n= ote to the editor to make sure the section numbers line up right before pub= lication, in case they change again.=A0 We can deal with that during the IA= NA Actions phase of publication.
=A0


8.1. *Normative References*

[AR-ORIG] will be obsolete by the time this I-D is published. =A0How can it be a normative reference?



That's a good procedural quest= ion.=A0 I think it has to be because it involves IANA actions that are bein= g amended, but I think this is something that can be sorted out during IESG= Evaluation.

Thanks!

-MSK

--047d7bb04ad84d172e04dc12c24d-- From sm@elandsys.com Mon May 6 15:26: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 2060721F9355 for ; Mon, 6 May 2013 15:26: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 RsDtvhU40jBz for ; Mon, 6 May 2013 15:26:49 -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 5FC7D21F9354 for ; Mon, 6 May 2013 15:26:49 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.42]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r46MQX3c017855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 May 2013 15:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367879205; bh=vMA3T/RH01ttQJrGZJ1ZrtKYDpdyk9IcqeSH7u6DHO4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ZL5bRKnP0vVVo/Lv86G3ouwIo8wCsW6Ss0LTy2pE3HEBW48fr7blQcLd3rqPVyNLX Ek5CT4c/Bf3PUAWyO8wr/mmRdiSnRzSx3bepqV53vOkt9KHU14NJDe19tBQdpFY9p7 BbLQYxE5kAIe0EPUfqp1vggS5HuXjVfRoJne+DSI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367879205; i=@elandsys.com; bh=vMA3T/RH01ttQJrGZJ1ZrtKYDpdyk9IcqeSH7u6DHO4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=EhOPwG4dA5qU3WUqh/Qg0r76/3GJJyZBjJGmUz0bS7jtmv8H6P1bg2eItkS84mYem NoxExNZYACg0xqaryg1KQSjJoS01Kh1BK+TfRIC5qW7xamVi9VTas4+4PinTulUMt5 /nUXV5jCy0f/u0x2xiwCvZkzYbWQaQcyk9acM1AM= Message-Id: <6.2.5.6.2.20130506151149.0b9793b8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 06 May 2013 15:25:01 -0700 To: "Murray S. Kucherawy" , Alessandro Vesely From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> <5187DA74.9020204@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-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, 06 May 2013 22:26:50 -0000 At 13:43 06-05-2013, Murray S. Kucherawy wrote: >That's a good procedural question. I think it has to be because it >involves IANA actions that are being amended, but I think this is >something that can be sorted out during IESG Evaluation. I do not have to read RFC 5451 to understand draft-ietf-appsawg-rfc5451bis-00 [1]. I read it though. Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg01365.html From ned.freed@mrochek.com Mon May 6 19:06: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 46B5721F9381 for ; Mon, 6 May 2013 19:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnBKNkutttZp for ; Mon, 6 May 2013 19:06:01 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 20EC721F9377 for ; Mon, 6 May 2013 19:06:01 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OTC5406FDC004II7@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 6 May 2013 19:00:58 -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 <01OT3BOFFH80000054@mauve.mrochek.com>; Mon, 6 May 2013 19:00:55 -0700 (PDT) Message-id: <01OTC53YHHWQ000054@mauve.mrochek.com> Date: Mon, 06 May 2013 14:14:55 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 05 May 2013 23:42:16 -0700" References: <51657E80.8070208@bbiw.net> To: "Murray S. Kucherawy" Cc: Dave Crocker , Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-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: Tue, 07 May 2013 02:06:06 -0000 I reviewed this quite some time ago, and as I recall my assessment was mostly favorable. I just reviewed it again, and surprised myself considerably by finding this document to be quite problematic in its present form. It's now my position that a number of additions and changes need to be made. The overarching problem here isn't what this document does; it's what it doesn't do. It presents a small set of malformation issues, a set which is necessarily only informed by past and present issues encountered in the field. This is fine as far as it goes, but the fact that things have changed in the short time since this document was written - we're not seeing several of the listed malformation nearly as often as we used to and we're starting to see new ones that aren't on the list - is a good indication that the lack of such guidance is a serious omission, especially in what is supposed to be a stable reference for such matters. So what would such guidance look like? I don't pretend to have the final answer here, but these three points strike me a a good starting point: (1) Whenever possible mitigation of syntactic malformations should be guided by an assessment of the most likely semantic intent. For example, it is reasonable to conclude that multiple sets of angle brackets around an address are simply superflous and can simply be dropped. (2) When the intent is unclear, or alternately, when it is clear but is inpractical to change things to express it, mitigation should be limited to cases where not doing anything would clearly lead to a worse outcome. (3) Security issues, when present, need to be addressed and may force mitigation strategies that are otherwise suboptimal. Now let's consider the various recommendations the document currently makes in light of these guidelines. Section 5 really needs to distinguish between semantic and syntactic invariance, especially in light of syntactic variations caused by things like MIME downgrade/update, to say nothing of the explicit advice given in sections 8.3 and 8.4 of this document. Line termination (section 7) is fine. True, the intent of a bare CR might be to overstrike a line, but this is increasingly a minority taste these days and a failure to deal with bare CRs and LFs likely leads to a worse outcome overall. Malformed address fields (section 8.1.*) suffers from a problem separate from consideration of these guidelines: The failure to deal with the possible presence of multiple addresses. Unfotunately such cases are quite common and some thought needs to be given to them in at least some of these sections. For example, in section 8.1.3 it might be good to point out that a comma may reaonably be interpreted as ending an address: To: --> To: third@example.net, fourth@example.net Beyond that, and now considering the guidlines, I find the advice given in 8.1.5 to be incorrect. I'm sorry, but the chances that something like: "Joe "@example.net is going to work are remote in the extreme. All this is going to do is create a situation where a probem occurs in a context that's far removed from the actual cause. The only case where I'd actually consider such a "mitigation" would be where it is essential to pull something out. Otherwise leaving the field alone is the better bet, because that will make it easier to diagnose the actual problem. I'll also note that the failure to consider the fairly common case of a field that just says: To: Joe seems to me to be an omission that should be corrected, especially since this is attempting to cover SUBMIT server fixups. Non-Header Lines (section 8.2) is OK. (I happen to think the advice given in 8.2 is flat-out wrong, but that's a matter of experience coupled with implementation practicalities; it's not something I can justify based on the guidelines.) Unusual spacing (section 8.3) and Header Malformations (section 8.4) are both spot on. Header Field Counts (section 8.5) needs work because it fails to take specific field semantics into account in what it recommends. It is of course true that when performing some sort of validation check on an originator field it's essential to pick one and be consistent about it. But there are many other fields where such checks are rarely if ever applied, e.g., To: and Cc:. Given that there are agents out there that employ a separate field for each address, surely a viable mitigation is to combine all recipient fields of a given type into a single field? Missing header fields (section 8.6) is spot on. Eight-Bit Data (section 8.7) needs a bunch of work, and once again it's a failure to consider the semantics of where the 8bit shows up. 8bit appearing in a header is a very different proposition from 8bit in a body. EAI deserves a shout-out in the former case because it's new, and the latter case is now so much of a ho-hum for many agents that a recommendation to reject 8bit is nothing short of silly. I'm also far from convinced that rejecting messages because of a single null is a good idea. I think a fair assessment of the likely intent in this case is the presence of a null or two is simply a message construction error, and silently dropping them is a much better bet. Header Field Names (section 9.1) is certainly cute, but MIME is actually quite clear that the first place a boundary can occur is in the following body, not the associated header. I'm not really comfortable with this document acting on an assessment of intent of material that is in fact completely valid. My suggestion is therefore to refrain from talking about rejecting such messages. I'm afraid "Missing MIME-Version Field" (section 9.2) is flat-out incorrect. The intent of a message that has a valid content-type and possibly content-transfer-encoding is pretty darned clear, and perhaps more to the point, failing to interpret such a message as MIME, given that many other agents, e.g., metamail, are going to, is exceedingly poor practice from a security standpoint. (If we're up for additions at this late date, it might also be good to add a section on how to handle bogus base64 or quoted-printable.) And finally, Oversized Lines (section 10.1) is spot on. Finally, a couple of comments about Dave's review. I'm not especially fussed about the use or non-use of compliance language. If there's a consensus to remove it that's fine, if not that's fine with me too. As for this: > > {BTW, I believe Postel's Law was not the motivating reason for email > > format deviations. Rather, I think that receiver's were accountable to > > their users -- the recipients -- while having no control over the > > misbehaving senders. So they/we hacked receiving code when necessary, to > > appease the users. /d } This is more or less correct. Not only do receivers rarely have any way to correct sender behavior, in a depressingly large number of cases some of the flagrant violations came from widely deployed software from large companies. In other cases it's the receiving user agent that's busted, and intermediaries get stuck with trying to accomodate their bustedness. And both are especially bad when deployed in hardware with no viable upgrade path. Ned From vesely@tana.it Tue May 7 08:42: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 8C09721F8F53 for ; Tue, 7 May 2013 08:42:15 -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 bz8ek5u-i1Bm for ; Tue, 7 May 2013 08:42:11 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 07A8721F8F26 for ; Tue, 7 May 2013 08:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1367941328; bh=gSq7hXX9OPYS32ohCxP0462PSPId7uXMmZJoiQNTJSk=; l=2616; h=Date:From:To:References:In-Reply-To; b=XCJt9ZREqykiwz1On03WdSLNOS0Smh/f1SYZaQdL1bxVoCjWIAe3oViNxAA7ZyAou nk/VptrRD4O7pOnott42YMnR2qWQKvBMaQEQeuRi6Kj75B/rAV8uNzNodiY/38C8bq pu3UH1K2q9oVNqzp6m8rNbCh0Z58eCFL3UG+JYvk= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Tue, 07 May 2013 17:42:08 +0200 id 00000000005DC04B.00000000518920D0.00001957 Message-ID: <518920D0.1040705@tana.it> Date: Tue, 07 May 2013 17:42:08 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> <5187DA74.9020204@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-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, 07 May 2013 15:42:15 -0000 On Mon 06/May/2013 22:43:54 +0200 Murray S. Kucherawy wrote: > On Mon, May 6, 2013 at 9:29 AM, Alessandro Vesely wrote: >> 2.3. *Authentication Identifier Field* >> >> I tend to associate syntax with production rules, so I'm unable to >> make sense of the sentence: >> >> This is similar in syntax to a fully-qualified domain name. > > You're aware of how this works; what would you suggest? The ABNF is > "value" because it is usually an FQDN, but we also say that it doesn't have > to be. I cannot think of anything but saying that explicitly. How about merging the first two paragraphs? E.g.: Every Authentication-Results header field has an authentication service identifier field ("authserv-id" above). This refers to the authenticating service within a given ADMD. For example, if the identifier is similar in syntax to a fully-qualified domain name, domain delegation semantics can be used to establish whether it belongs to an ADMD's name space. This specification does not mandate how, but the identifier MUST correspond unequivocally to the ADMD that generates it and MUST pertain to exactly that one ADMD. ... >> The uniqueness of the identifier MUST be guaranteed by the ADMD >> that generates it and MUST pertain to exactly that one ADMD. >> >> What is actually required is not the "uniqueness" of the identifier, >> but the ability to univocally identify the responsible ADMD using the >> identifier. I'd suggest to rephrase the sentence accordingly. > > Are those not synonymous? Not quite. For example, a random number would satisfy the uniqueness but can hardly refer to an ADMD. > From the perspective of a module consuming this field, it has to be > the case that such a module can safely assume that a field bearing > the authserv-id it expects (or one of a set, perhaps) can be > trusted. Right. But then associating the field with a specific ADMD becomes interesting only if you happen to mix the message streams from multiple ADMDs (e.g. on a MUA). In that case, /all/ ADMDs have to be compliant, and they have to agree on interoperable naming conventions. >> The "policy" result would be returned if, for example, [SPF] >> returned as "pass" result, but the local policy check finds that >> the sender's policy is unacceptable (e.g. terminates with "+all"). > > I don't agree with including that specific example, as it encourages a > particular local policy debate that I don't think this document should > approach. I thought abhorring +all was uncontroversial. > Thanks! You're welcome :-) From sm@elandsys.com Tue May 7 12:53: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 3462E21F8F28 for ; Tue, 7 May 2013 12:53:09 -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 bq+Vlxqz7xHm for ; Tue, 7 May 2013 12:53:08 -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 5130321F90DF for ; Tue, 7 May 2013 12:53:08 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.138.78]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r47JqrVi025187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 May 2013 12:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367956385; bh=cftvaiFd/9ySN13B8sS9nHqtS9OOOd+zIWXyvoQ5wAM=; h=Date:To:From:Subject; b=M02DcWLb3UFTMxstS8o2/oiFsUbcG0+CGRjMfZEcgXvOMZuVTAV/WG0FUrr6R/PRl atmfZ7e9CkRwEYo97mQVrFjbeJYgh9RjKjExY5DMxW7ik53qHTcP2JX6o7lCnWBDbM +U+ZJjmKISWghsyMjBn4oykw1QaEJqOz698zNudI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367956385; i=@elandsys.com; bh=cftvaiFd/9ySN13B8sS9nHqtS9OOOd+zIWXyvoQ5wAM=; h=Date:To:From:Subject; b=qHIUikdLBVpxvwhPX6/sJQCUOFYcKVd4YD8CxdQWv8F6sDVEqj8SVjpr+fgA/sIY0 Pmu5tR7JplPhk0thI9FQrOQ3ZPp9AfzOTUZ2Vo6hbN9GBavYAQEkgEhwrTKelfNQgz OoTmBQ2GhH3cYLHr/4dAvS4QVk1e6Zn50rZlh66Q= Message-Id: <6.2.5.6.2.20130507122937.075fb058@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 07 May 2013 12:47:42 -0700 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-discuss] Apps Area Directorate report for April 2013 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 May 2013 19:53:09 -0000 The Applications Area Directorate provides semi-formal reviews of Internet-Drafts as a way to improve the quality of IETF specifications. The directorate consists of the Working Group Chairs of the Applications Area and recognized experts in the Applications Area. The following reviews were performed in April 2013: Reviewer I-D Xuan He, draft-ietf-core-coap-14 Alexey Melnikov Vijay Gurbani draft-ietf-pcp-upnp-igd-interworking-07 Yoshiro Yoneya draft-ietf-dnsext-dnssec-algo-signal-10 S. Moonesamy draft-ietf-ipfix-flow-selection-tech-14 Bert Greevenbosch, draft-ietf-tls-multiple-cert-status-extension-05 Peter Saint-Andre Ted Hardie draft-ietf-6renum-gap-analysis-05 Jiankang Yao draft-ietf-nfsv4-rfc3530bis-25 Eliot Lear, draft-ietf-6man-stable-privacy-addresses-06 Xuan He Mark Nottingham draft-ietf-oauth-revocation-07 D. Crocker draft-sheffer-running-code-04 Martin Thomson draft-ietf-netmod-rfc6021-bis-01 Cyrus Daboo draft-ietf-spfbis-4408bis-14 Tim Bray draft-ietf-netmod-interfaces-cfg-10 There were 13 reviews in April 2011, 20 reviews in April 2012 and 13 reviews in April 2013. The directorate has been running a joint review experiment where two reviewers work together on a review. I would like to thank Bert, Xuan He, Alexey, Eliot and Peter for trying out the joint reviews. Regards, S. Moonesamy On behalf of the Applications Area Directorate http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate From superuser@gmail.com Tue May 7 15:24:39 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917CB21F90B3 for ; Tue, 7 May 2013 15:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, 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 Tk6W7q4KSirk for ; Tue, 7 May 2013 15:24:32 -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 AAC8721F9057 for ; Tue, 7 May 2013 15:24:31 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id u54so1161720wes.1 for ; Tue, 07 May 2013 15:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=hyHjjnlWRYW1zOtkXcl0fyrVoaRJSxUU/FqVrb8RVtw=; b=OB1TvKQPQRgMd8KDs4LobonS4wpJAfjdRmpVQY2xqSEPqwF0OEi5TPh3cMUhcp97X2 DnPibYGMrer5I709H72+PwR2mldR7bzQC8LpjkPAP8Gn5ozdcPFSDjdXf3iDoPtPsWEt IeRelFz/DTFwK56lQPlB0oGzBDOk8y2lKla14tyae1XvWuM1mPGidMuALmAKn0cPKiKt wNY7vOjwwif3RkJ2h5TpPDMF/pBdMOAtTJ1hiuatU5NDyhzyZXRXNsJukSd7ScmoAE9n jvuEveiDnWGRG9XZpESJ+++Ca5FApvVnUOHsEECFTQ82JsnmhgpWbbWypSO4qHqQZqBy KNDw== MIME-Version: 1.0 X-Received: by 10.195.12.228 with SMTP id et4mr6257232wjd.59.1367965470866; Tue, 07 May 2013 15:24:30 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Tue, 7 May 2013 15:24:30 -0700 (PDT) Date: Tue, 7 May 2013 15:24:30 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=047d7bb04ad8f4c1aa04dc284783 Subject: [apps-discuss] Processing draft-bosch-sieve-duplicate via APPSAWG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 May 2013 22:24:39 -0000 --047d7bb04ad8f4c1aa04dc284783 Content-Type: text/plain; charset=ISO-8859-1 We have received a request to process the above draft through APPSAWG, since there is no longer a sieve WG. It is a relatively short document and appears to fall within our charter. We haven't processed a sieve extension here yet; rather, they've gone through small, tight WGs so far. Before issuing a formal call for adoption, I'd like to gauge whether we have enough sieve-aware people currently following APPSAWG to be able to contribute reviews and constructive commentary. A virtual show of hands, please? Alternatively, the ADs may wish to spin up another short-lived WG to handle this. Barry or Pete, care to comment? -MSK, co-chairin' --047d7bb04ad8f4c1aa04dc284783 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We have received a request to process the above draft= through APPSAWG, since there is no longer a sieve WG.=A0 It is a relativel= y short document and appears to fall within our charter.

We haven= 9;t processed a sieve extension here yet; rather, they've gone through = small, tight WGs so far.=A0 Before issuing a formal call for adoption, I= 9;d like to gauge whether we have enough sieve-aware people currently follo= wing APPSAWG to be able to contribute reviews and constructive commentary.= =A0 A virtual show of hands, please?

Alternatively, the ADs may wish to spin up another short-liv= ed WG to handle this.=A0 Barry or Pete, care to comment?

=
-MSK, co-chairin'
--047d7bb04ad8f4c1aa04dc284783-- From stpeter@stpeter.im Tue May 7 15:28: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 48B8B21F8F28 for ; Tue, 7 May 2013 15:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.306 X-Spam-Level: X-Spam-Status: No, score=-102.306 tagged_above=-999 required=5 tests=[AWL=0.293, 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 h3KhGlAMRUCA for ; Tue, 7 May 2013 15:28:32 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5B02711E80A3 for ; Tue, 7 May 2013 15:28:32 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 58E91E8275; Tue, 7 May 2013 16:40:09 -0600 (MDT) Message-ID: <51898010.7030801@stpeter.im> Date: Tue, 07 May 2013 16:28:32 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Processing draft-bosch-sieve-duplicate via APPSAWG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 May 2013 22:28:38 -0000 On 5/7/13 4:24 PM, Murray S. Kucherawy wrote: > We have received a request to process the above draft through APPSAWG, > since there is no longer a sieve WG. It is a relatively short document > and appears to fall within our charter. > > We haven't processed a sieve extension here yet; rather, they've gone > through small, tight WGs so far. Before issuing a formal call for > adoption, I'd like to gauge whether we have enough sieve-aware people > currently following APPSAWG to be able to contribute reviews and > constructive commentary. A virtual show of hands, please? Seems reasonable as an APPSAWG item. I'm not a SIEVE expert, but I've worked on it a bit (RFC 5437) and I would be willing to review this document. Peter From superuser@gmail.com Tue May 7 15:35: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 664D521F86E4 for ; Tue, 7 May 2013 15:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, 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 ksTtS4dg5tSF for ; Tue, 7 May 2013 15:35:45 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1FA21F86D5 for ; Tue, 7 May 2013 15:35:45 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id j13so1172010wgh.28 for ; Tue, 07 May 2013 15:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=70d2CjfTp/qMfsN3lB54RBaIUGrXVU00SbRz1z/P0fY=; b=ToGMG4zjzNg3uXW8xLJe8hIGl4JpgB2rWCDNjusYODM4wTZrCc5jyxPSv6mAoCUvFj j9GuoAnoSho2TZUbmNNrtBowczLwGV1S2CQ1+14vIoE8fsqXaYyEhYa8hAk7kUL1iYmP AE2mcVnpGPF7qo+lMmW+PDmBhZM/Fyo1NDngiccCV5B33XOWWPMlOspLIOXg6pgSShuI ABUG1chFuX4oeRwu9MUbYFWR+311ica0yRd3pxnwyfv79v44PVZyieFFf0mKLu1nrZyO hiyI+ggM4y+jHR8IW6PvAJIoL52/te4wMg6j7IMenhO2J+5RUU39yOBgkhbmGPxCtrSJ OVew== MIME-Version: 1.0 X-Received: by 10.180.14.5 with SMTP id l5mr17575834wic.32.1367966144343; Tue, 07 May 2013 15:35:44 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Tue, 7 May 2013 15:35:44 -0700 (PDT) In-Reply-To: <518920D0.1040705@tana.it> References: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> <5187DA74.9020204@tana.it> <518920D0.1040705@tana.it> Date: Tue, 7 May 2013 15:35:44 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=f46d040fa04c19330a04dc287042 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-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, 07 May 2013 22:35:46 -0000 --f46d040fa04c19330a04dc287042 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 7, 2013 at 8:42 AM, Alessandro Vesely wrote: > >> This is similar in syntax to a fully-qualified domain name. > > > > You're aware of how this works; what would you suggest? The ABNF is > > "value" because it is usually an FQDN, but we also say that it doesn't > have > > to be. > > I cannot think of anything but saying that explicitly. How about > merging the first two paragraphs? E.g.: > > Every Authentication-Results header field has an authentication > service identifier field ("authserv-id" above). This refers to > the authenticating service within a given ADMD. For example, if > the identifier is similar in syntax to a fully-qualified domain > name, domain delegation semantics can be used to establish whether > it belongs to an ADMD's name space. This specification does not > mandate how, but the identifier MUST correspond unequivocally to > the ADMD that generates it and MUST pertain to exactly that one > ADMD. ... > I'm about to post a new version with this section reworked a bit. Let me know what you think of it. > >> The uniqueness of the identifier MUST be guaranteed by the ADMD > >> that generates it and MUST pertain to exactly that one ADMD. > >> > >> What is actually required is not the "uniqueness" of the identifier, > >> but the ability to univocally identify the responsible ADMD using the > >> identifier. I'd suggest to rephrase the sentence accordingly. > > > > Are those not synonymous? > > Not quite. For example, a random number would satisfy the uniqueness > but can hardly refer to an ADMD. > Sure it can; NetEase (a Chinese ESP) uses "163.com" as their domain name. An authserv-id of just "163" would be fine. > > From the perspective of a module consuming this field, it has to be > > the case that such a module can safely assume that a field bearing > > the authserv-id it expects (or one of a set, perhaps) can be > > trusted. > > Right. But then associating the field with a specific ADMD becomes > interesting only if you happen to mix the message streams from > multiple ADMDs (e.g. on a MUA). In that case, /all/ ADMDs have to be > compliant, and they have to agree on interoperable naming conventions. > That's actually only true if you plan to trust the A-R fields added by other ADMDs. Most commonly you'll only care about your own. > >> The "policy" result would be returned if, for example, [SPF] > >> returned as "pass" result, but the local policy check finds that > >> the sender's policy is unacceptable (e.g. terminates with "+all"). > > > > I don't agree with including that specific example, as it encourages a > > particular local policy debate that I don't think this document should > > approach. > > I thought abhorring +all was uncontroversial. > Probably, but it's not something this document needs to discuss in order to be effective. -MSK --f46d040fa04c19330a04dc287042 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 7, 2013 at 8:42 AM, Alessandro Vesely <vesely@ta= na.it> wrote:
>> =A0 =A0This is similar in syntax to= a fully-qualified domain name.
>
> You're aware of how this works; what would you suggest? =A0The ABN= F is
> "value" because it is usually an FQDN, but we also say that = it doesn't have
> to be.

I cannot think of anything but saying that explicitly. =A0How about merging the first two paragraphs? =A0E.g.:

=A0 =A0Every Authentication-Results header field has an authentication
=A0 =A0service identifier field ("authserv-id" above). =A0This re= fers to
=A0 =A0the authenticating service within a given ADMD. =A0For example, if =A0 =A0the identifier is similar in syntax to a fully-qualified domain
=A0 =A0name, domain delegation semantics can be used to establish whether =A0 =A0it belongs to an ADMD's name space. =A0This specification does n= ot
=A0 =A0mandate how, but the identifier MUST correspond unequivocally to
=A0 =A0the ADMD that generates it and MUST pertain to exa= ctly that one
=A0 =A0ADMD. ...

I'm about to= post a new version with this section reworked a bit.=A0 Let me know what y= ou think of it.
=A0
>> =A0 =A0The uniqueness of the identifier MUST be = guaranteed by the ADMD
>> =A0 =A0that generates it and MUST pertain to exactly that one ADMD= .
>>
>> What is actually required is not the "uniqueness" of the= identifier,
>> but the ability to univocally identify the responsible ADMD using = the
>> identifier. =A0I'd suggest to rephrase the sentence accordingl= y.
>
> Are those not synonymous?

Not quite. =A0For example, a random number would satisfy the uniquene= ss
but can hardly refer to an ADMD.

Sure i= t can; NetEase (a Chinese ESP) uses "163.co= m" as their domain name.=A0 An authserv-id of just "163"= would be fine.
=A0
> From the perspective of a module consuming this fiel= d, it has to be
> the case that such a module can safely assume that a field bearing
> the authserv-id it expects (or one of a set, perhaps) can be
> trusted.

Right. =A0But then associating the field with a specific ADMD becomes=
interesting only if you happen to mix the message streams from
multiple ADMDs (e.g. on a MUA). =A0In that case, /all/ ADMDs have to be
compliant, and they have to agree on interoperable naming conventions.
<= /blockquote>

That's actually only true if you plan t= o trust the A-R fields added by other ADMDs.=A0 Most commonly you'll on= ly care about your own.
=A0
>> =A0 =A0The "policy" result would be re= turned if, for example, [SPF]
>> =A0 =A0returned as "pass" result, but the local policy c= heck finds that
>> =A0 =A0the sender's policy is unacceptable (e.g. terminates wi= th "+all").
>
> I don't agree with including that specific example, as it encourag= es a
> particular local policy debate that I don't think this document sh= ould
> approach.

I thought abhorring +all was uncontroversial.
Probably, but it's not something this document needs to di= scuss in order to be effective.

-MSK
--f46d040fa04c19330a04dc287042-- From internet-drafts@ietf.org Tue May 7 15:41: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 285D021F8FF1; Tue, 7 May 2013 15:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.369 X-Spam-Level: X-Spam-Status: No, score=-102.369 tagged_above=-999 required=5 tests=[AWL=0.231, 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 sUklEtf5LVdY; Tue, 7 May 2013 15:41:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8262C21F8FF8; Tue, 7 May 2013 15:41:40 -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.44.p7 Message-ID: <20130507224140.5968.99005.idtracker@ietfa.amsl.com> Date: Tue, 07 May 2013 15:41:40 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-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: Tue, 07 May 2013 22:41:41 -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 : Message Header Field for Indicating Message Authenticati= on Status Author(s) : Murray S. Kucherawy Filename : draft-ietf-appsawg-rfc5451bis-01.txt Pages : 42 Date : 2013-05-07 Abstract: This document specifies a header field for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users, or make sorting and filtering decisions. This document is a candidate for Internet Standard status. [RFC Editor: Please delete this notation, as I imagine it will be indicated some other way.] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-rfc5451bis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-rfc5451bis-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From superuser@gmail.com Tue May 7 15:43: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 1EC0021F9057 for ; Tue, 7 May 2013 15:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, 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 9fpxmMtotg00 for ; Tue, 7 May 2013 15:43:37 -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 5514921F9054 for ; Tue, 7 May 2013 15:43:37 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id m15so1238354wgh.29 for ; Tue, 07 May 2013 15:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=iatbrOYHgGOfAW0HSkxTYq3ZRZ9mWr23m5vN4fTubfs=; b=LX80RPBW0PuNZlX79pC2V8An81Px9mBDw63JsyIr32YlWXYfkqNe7rUKwP8kliXsoK AcHw0GKjR4MdZQKkb8YXD7KTyj2DJV04OEmmTbP0FfEZM2kJ+pulsNXqMk8HLLMToo4f C02vwqsRQW7Hh/O0VxjsAInuJ8uqyb5qBT5Hj/ai5igy8yq7l9fI/Vea8Yw1q/8agdm/ O2BL0lNtnY7j6fkm0CBZBl/DmVifd7vFbwpQxp88Y5IxfZCR9zczWGwvBGblWHdjPiq/ 7nmmpRsOLz5s6k1JixrjOl95pCapgd0gp1QOZUSst+lazpNDpXuv0WBSVX7WMj2y+4Ys 65Cg== MIME-Version: 1.0 X-Received: by 10.180.37.109 with SMTP id x13mr15674948wij.20.1367966614310; Tue, 07 May 2013 15:43:34 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Tue, 7 May 2013 15:43:34 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 May 2013 15:43:34 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=e89a8f6473f51c59cd04dc288c24 Subject: Re: [apps-discuss] Processing draft-bosch-sieve-duplicate via APPSAWG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 May 2013 22:43:38 -0000 --e89a8f6473f51c59cd04dc288c24 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 7, 2013 at 3:24 PM, Murray S. Kucherawy wrote: > We have received a request to process the above draft through APPSAWG, > since there is no longer a sieve WG. It is a relatively short document and > appears to fall within our charter. > > We haven't processed a sieve extension here yet; rather, they've gone > through small, tight WGs so far. Before issuing a formal call for > adoption, I'd like to gauge whether we have enough sieve-aware people > currently following APPSAWG to be able to contribute reviews and > constructive commentary. A virtual show of hands, please? > > I should add that the person submitting the request was not the author and has volunteered to shepherd the document, so add one to whatever count comes out of this thread. :-) --e89a8f6473f51c59cd04dc288c24 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 7, 2013 at 3:24 PM, Murray S. Kucherawy <su= peruser@gmail.com> wrote:
We have received a req= uest to process the above draft through APPSAWG, since there is no longer a= sieve WG.=A0 It is a relatively short document and appears to fall within = our charter.

We haven't processed a sieve extension here yet; rather, they'v= e gone through small, tight WGs so far.=A0 Before issuing a formal call for= adoption, I'd like to gauge whether we have enough sieve-aware people = currently following APPSAWG to be able to contribute reviews and constructi= ve commentary.=A0 A virtual show of hands, please?


I should add that the pers= on submitting the request was not the author and has volunteered to shepher= d the document, so add one to whatever count comes out of this thread.=A0 := -)
--e89a8f6473f51c59cd04dc288c24-- From barryleiba.mailing.lists@gmail.com Tue May 7 15:53: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 1EE8121F90DF for ; Tue, 7 May 2013 15:53:33 -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 c5-um4BLsmw6 for ; Tue, 7 May 2013 15:53:32 -0700 (PDT) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9435921F90CC for ; Tue, 7 May 2013 15:53:32 -0700 (PDT) Received: by mail-vb0-f51.google.com with SMTP id x16so1015073vbf.24 for ; Tue, 07 May 2013 15:53:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=SQq5qemhNWdIu1O8OydnzJ3sYQiacVNDKvmm+oh22qA=; b=SqSg3TvhSSNvQbvnmVEw/imU+ToVwYaJBu3EL6Q5ESV8ME8kfd8MQXXMjdBboSCrU8 rnlPBB5Lw4xLhAVo4DxDKw438JCOX+6YKTPDwSTFsQi/Xb8kgCkXD7D4bqTY7rDwXsbK YODHogE14fnP5uQ9cq1Q9cY0CFOkMTtqsd66oNGJUVADymE+p2Gvf7OxD9mq0hr8f1eq JqBXzwfXBY5d1uUnB9lWydrdnpbj+6l5FwTxQ4vV9H8ZxkcFL62o7TQuQzAUwVFU0z8b sbMknxB6y8w6LhFB60L6YNx5JESZJsa3s4NJo2u1j3pKXo2R6RigndcgmLCHkzKaXMLz FGoA== MIME-Version: 1.0 X-Received: by 10.52.233.34 with SMTP id tt2mr2276281vdc.70.1367967212020; Tue, 07 May 2013 15:53:32 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.6.233 with HTTP; Tue, 7 May 2013 15:53:31 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> <5187DA74.9020204@tana.it> Date: Tue, 7 May 2013 18:53:31 -0400 X-Google-Sender-Auth: B7kyBfE7PQDDIgTgrJStFiVFtvU 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] WGLC on draft-ietf-appsawg-rfc5451bis-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, 07 May 2013 22:53:33 -0000 Just on one item: >> 8.1. *Normative References* >> >> [AR-ORIG] will be obsolete by the time this I-D is published. How can >> it be a normative reference? > > That's a good procedural question. I think it has to be because it involves > IANA actions that are being amended, but I think this is something that can > be sorted out during IESG Evaluation. Coupla things: 1. It's usually not necessary for the obsolescent document to be a normative reference, as the obsoleting document has all the necessary information. That's certainly true in this case, and I suggest making the reference informative. 2. Have I told you how unhappy I am with the citation style you use? It's generally not something I'm willing to argue about, preferring to defer to the authors' style of citations, but in this case it seems particularly bad. May I suggest this?: OLD [AR-ORIG] defined a new header field for electronic mail messages that presents the results of a message authentication effort in a machine-readable format. NEW The first edition of this document [RFC5451] defined a new header field for electronic mail messages that presents the results of a message authentication effort in a machine-readable format. ...and replace all other instances of "[AR-ORIG]" with "[RFC5451]" (or even just "RFC 5451"; how many citations to the same document do you need?). Barry From scott@kitterman.com Tue May 7 16:01: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 2793821F8E6D for ; Tue, 7 May 2013 16:01:42 -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_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaJCUPShMW3m for ; Tue, 7 May 2013 16:01:37 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 088CA21F8518 for ; Tue, 7 May 2013 16:01:32 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 20DEE20E411A; Tue, 7 May 2013 19:01:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1367967691; bh=nvuxhOYNiQ8E568SsaQJ9TruvGrBBTSLIsgP/vECnXk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=BkM7Yo1FVs2M6MWZdBzLhsvLWHyCe+0Py/EsE/Gtd5A3G3TgdRPdUXoa8vn8tOTXy aTkMdqIbGX/tNJppMyUYQ4pFtrwXr2otAW62CmWuXANrs8zIZmrBLBztbYXtS37Km/ 0xPntRjjaOGM5euaiW7ijMeu+NmAr9asjMMKHo+I= Received: from scott-latitude-e6320.localnet (10.sub-70-192-200.myvzw.com [70.192.200.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id F336720E40F0; Tue, 7 May 2013 19:01:30 -0400 (EDT) From: Scott Kitterman To: apps-discuss@ietf.org Date: Tue, 07 May 2013 19:01:29 -0400 Message-ID: <3043082.mLUHZvu3uC@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-19-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <518920D0.1040705@tana.it> References: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> <518920D0.1040705@tana.it> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-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, 07 May 2013 23:01:42 -0000 On Tuesday, May 07, 2013 05:42:08 PM Alessandro Vesely wrote: > >> The "policy" result would be returned if, for example, [SPF] > >> returned as "pass" result, but the local policy check finds that > >> the sender's policy is unacceptable (e.g. terminates with "+all"). > > > > > > > > I don't agree with including that specific example, as it encourages a > > particular local policy debate that I don't think this document should > > approach. > > I thought abhorring +all was uncontroversial. Trying to deconstruct an SPF record and make judgments based on it's internal structure is 'bad'. All you can take is the SPF result. If someone publishes v=spf +1, then it's 'pass'. That's all you know. There are enough other ways to make a functionally equivalent record that it's not worth worrying about. Scott K From superuser@gmail.com Tue May 7 16:02: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 ECAF421F9023 for ; Tue, 7 May 2013 16:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 akHNKMk8-LUB for ; Tue, 7 May 2013 16:02:25 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1C34321F8F32 for ; Tue, 7 May 2013 16:02:24 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id c11so1238400wgh.10 for ; Tue, 07 May 2013 16:02:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mbqX8ml6YVjXjs0wN/SMUeN57pqLZI7QJhUgatELT0Y=; b=UJfLtkq9jo3oAYvuoDWpFCKzSRvFEXQL2179IpLgUsqIklibWHA0mhRAqlpLalpT7Y Ya4FYagxCo+qc43pZ5FkN6OhJamBm/zuIxylB5RNrVK0U69/Sn9KDjN6cWWMVAz/gGEv 9aUzYOt3KU69kPBkgYDxpyGXC05WDfxDk72I0sMZ/hpQqkgTGYIufW5zyzppBP8O5pH0 FEKSIw+6Ege2Hhl3sbzfjuFp5xfjbQ9d5pt6pevRH8/+cnZmBenEOTSZhpRKVSPO1Heb Ei2DMElbSc+aWa88amSfaRTGQrC6Rdf3x3o63DZQcgmrEqROTxiCLZtiVp0wALxpEiZg IzOA== MIME-Version: 1.0 X-Received: by 10.194.179.169 with SMTP id dh9mr94732wjc.15.1367967744210; Tue, 07 May 2013 16:02:24 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Tue, 7 May 2013 16:02:24 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> <5187DA74.9020204@tana.it> Date: Tue, 7 May 2013 16:02:24 -0700 Message-ID: From: "Murray S. Kucherawy" To: Barry Leiba Content-Type: multipart/alternative; boundary=089e01419f4a753e4704dc28cf07 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-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, 07 May 2013 23:02:26 -0000 --089e01419f4a753e4704dc28cf07 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 7, 2013 at 3:53 PM, Barry Leiba wrote: > 1. It's usually not necessary for the obsolescent document to be a > normative reference, as the obsoleting document has all the necessary > information. That's certainly true in this case, and I suggest making > the reference informative. > Did that in -01 (just posted). > 2. Have I told you how unhappy I am with the citation style you use? > Not until now! It's generally not something I'm willing to argue about, preferring to > defer to the authors' style of citations, but in this case it seems > particularly bad. May I suggest this?: > > OLD > [AR-ORIG] defined a new header field for electronic mail messages > that presents the results of a message authentication effort in a > machine-readable format. > > NEW > The first edition of this document [RFC5451] defined a new header > field for electronic mail messages that presents the results of a > message authentication effort in a machine-readable format. > > ...and replace all other instances of "[AR-ORIG]" with "[RFC5451]" (or > even just "RFC 5451"; how many citations to the same document do you > need?). > Done for the next version. --089e01419f4a753e4704dc28cf07 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 7, 2013 at 3:53 PM, Barry Leiba <barryl= eiba@computer.org> wrote:
1. It's usually not necessary for the ob= solescent document to be a
normative reference, as the obsoleting document has all the necessary
information. =A0That's certainly true in this case, and I suggest makin= g
the reference informative.

Did that in = -01 (just posted).
=A0
2. Have I told you how unhappy I am with the citation style you use?

Not until now!

It's generally not something I'm willing to argue about, preferring= to
defer to the authors' style of citations, but in this case it seems
particularly bad. =A0May I suggest this?:

OLD
=A0 =A0[AR-ORIG] defined a new header field for electronic mail messages =A0 =A0that presents the results of a message authentication effort in a =A0 =A0machine-readable format.

NEW
=A0 =A0The first edition of this document [RFC5451] defined a new header =A0 =A0field for electronic mail messages that presents the results of a =A0 =A0message authentication effort in a machine-readable format.

...and replace all other instances of "[AR-ORIG]" with "[RFC= 5451]" (or
even just "RFC 5451"; how many citations to the same document do = you
need?).

Done for the next version.
<= br>
--089e01419f4a753e4704dc28cf07-- From superuser@gmail.com Tue May 7 16:03: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 C227B21F905F for ; Tue, 7 May 2013 16:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 gBu6aQYucb9B for ; Tue, 7 May 2013 16:03:52 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0F32F21F9023 for ; Tue, 7 May 2013 16:03:51 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hq12so4608314wib.3 for ; Tue, 07 May 2013 16:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=y07EDQn40kqEJnxU7qa2n/kBrdNXJVP+yFwCjukulBk=; b=tT3g+o63kUTgo00G5vMlTo4q4713R7C7NkE2hgFudvbXraIciuz94zqo9OwI/ormrk 8F6HuTWUlkE/+91tdnCzhheeqXRZJMK0l2yNGX9BUNRzRUM8av9Ho4FoUjlJloj9SL8n 4KQT2adIoOt6SJYj47cm2qTkwgxbgfM9ll4DQcAbb24/AftyDt5Xvt3tQq0dd3Ydl4Zt J4nYqR1iFzOvsGJ/t5OSNfYS+PmyFDZubQk/Uv+2MgvHLvaLhLJaNXaNTp6a4Mc0uAPF fGAahACML/GDcQ5L5nXkd907wjKqU0kBID/OdJMQCW6I2tD2dwebWyYtQsNKjoRaVycU pMkA== MIME-Version: 1.0 X-Received: by 10.180.79.69 with SMTP id h5mr17643338wix.14.1367967831201; Tue, 07 May 2013 16:03:51 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Tue, 7 May 2013 16:03:51 -0700 (PDT) In-Reply-To: <3043082.mLUHZvu3uC@scott-latitude-e6320> References: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> <518920D0.1040705@tana.it> <3043082.mLUHZvu3uC@scott-latitude-e6320> Date: Tue, 7 May 2013 16:03:51 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d043c062ea49f1804dc28d4f7 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-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, 07 May 2013 23:03:52 -0000 --f46d043c062ea49f1804dc28d4f7 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 7, 2013 at 4:01 PM, Scott Kitterman wrote: > Trying to deconstruct an SPF record and make judgments based on it's > internal > structure is 'bad'. All you can take is the SPF result. If someone > publishes > v=spf +1, then it's 'pass'. That's all you know. There are enough other > ways > to make a functionally equivalent record that it's not worth worrying > about. > > > I think the point is that "+all" is a possible example where local policy at the receiver/verifier might be to downgrade an SPF "pass" to something less positive. All of that is true, but I would prefer to be generic in making the facility available and letting receivers figure out what things warrant such treatment. -MSK --f46d043c062ea49f1804dc28d4f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 7, 2013 at 4:01 PM, Scott Kitterman <scott= @kitterman.com> wrote:
Trying to deconstruct an SPF record and make= judgments based on it's internal
structure is 'bad'. =A0All you can take is the SPF result. =A0If so= meone publishes
v=3Dspf +1, then it's 'pass'. =A0That's all you know. =A0Th= ere are enough other ways
to make a functionally equivalent record that it's not worth worrying a= bout.



I think the point is that "+a= ll" is a possible example where local policy at the receiver/verifier = might be to downgrade an SPF "pass" to something less positive.= =A0 All of that is true, but I would prefer to be generic in making the fac= ility available and letting receivers figure out what things warrant such t= reatment.

-MSK

--f46d043c062ea49f1804dc28d4f7-- From barryleiba.mailing.lists@gmail.com Tue May 7 16:14: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 7284E11E80A4 for ; Tue, 7 May 2013 16:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.943 X-Spam-Level: X-Spam-Status: No, score=-102.943 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 7xUttLsQQ4Cj for ; Tue, 7 May 2013 16:14:35 -0700 (PDT) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id 33C8E11E80A6 for ; Tue, 7 May 2013 16:14:35 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id hv10so1101934vcb.39 for ; Tue, 07 May 2013 16:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kw+HXwp+S3cT9bZqIrPKTHV2eDiX4gF4FW83zcFrI3g=; b=qL2iC2MDl+Mz0KWcKTnsifaDv4PBo4WMKZ8wEult5Ju0rbL2N+gDhELXB2iZqKdnhL VeTbUlutVzduLK00GG+LFYPoYRXgznMuTKDfaa7Nva9QQIyKJv26fhHOWdI3N9+4ais7 p5P4bsHrCFrm1EP7DIIHRYf52v7FEUqaNM0zClalRkLzkDAADBOH5YET7WVTPftmVqC5 zrOL47FtEUTT/2v2A7OtEINb8trZIlDJv9I/UN6JEGoeXtSxsgIz2iyxHjo8D5ttogke sgWY6YFXkD1u1xmqAGs8rWbo14bxmH1aLeFNrQqJFzke7VhbSWARYEWrrNdTBxH82KDe Y3Mg== MIME-Version: 1.0 X-Received: by 10.58.155.74 with SMTP id vu10mr2795958veb.27.1367968474499; Tue, 07 May 2013 16:14:34 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.6.233 with HTTP; Tue, 7 May 2013 16:14:34 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> <5187DA74.9020204@tana.it> Date: Tue, 7 May 2013 19:14:34 -0400 X-Google-Sender-Auth: QhQOgOeiHRzimsIvLZlSTAxKWEc 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] WGLC on draft-ietf-appsawg-rfc5451bis-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, 07 May 2013 23:14:40 -0000 >> 2. Have I told you how unhappy I am with the citation style you use? > > Not until now! > >> It's generally not something I'm willing to argue about, preferring to >> defer to the authors' style of citations OK, so let me be clear. Let's please not discuss this further in this thread, though; if we want to pursue it, let's do it in a separate thread, or, even better, on the rfc-interest list. I prefer for citations to be maximally useful, without requiring the reader to go to the bottom of the document and look at the references for everything. That means that the style "[AR-ORIG]" is truly sub-optimal, because it gives *no* useful information until it's been looked up at least once. It also means that "[RFC5451]", by itself, isn't great either, because, while it tells you where to find the cited document, it doesn't tell you what it is. Consider these: 1. "According to [RFC5321], the MAIL FROM command <...etc...>" 2. "According to [SMTP], the MAIL FROM command <...etc...>" 3. "According to SMTP [RFC5321], the MAIL FROM command <...etc...>" 4. "According to Simple Mail Transfer Protocol (SMTP) [RFC5321], the MAIL FROM command <...etc...>" In cases (1) and (2), you're requiring the reader to know what RFC 5321 or "SMTP" are, or forcing them to go look up the reference. In cases 3 and 4, you give more information: you're citing *both* SMTP and RFC 5321, and it's much more likely that a reader will know what's being cited without having to look at the reference. For citations to this document (well, or the original version, for now) from elsewhere, one might say something like this: "The description of the Message Authentication Status header field [RFC5451], specifies that <...etc...>" ... which seems far superior to citations that simply use bare "[RFC5451]" or something like "[AUTH-STAT]". Barry From yaojk@cnnic.cn Tue May 7 23:20: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 935E421F8606 for ; Tue, 7 May 2013 23:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.399 X-Spam-Level: X-Spam-Status: No, score=-91.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, SARE_SUB_ENC_GB2312=1.345, 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 x7xjtfUPhfGK for ; Tue, 7 May 2013 23:20:32 -0700 (PDT) Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id 3B21621F9057 for ; Tue, 7 May 2013 23:20:28 -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; Wed, 08 May 2013 14:20:21 +0800 Date: Wed, 8 May 2013 14:20:21 +0800 From: "Jiankang Yao" To: =?gb2312?B?SGF5bmVzLCBUb20=?= References: <6E0E2EDBD7BF49FF94AD9DBA96C88E07@LENOVO47E041CF>, <3A330EAE-1D6F-439E-9378-D569A9233D5F@netapp.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <2013050814191964838318@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart272565780552_=----" Cc: =?gb2312?B?PGllc2dAaWV0Zi5vcmc+?= , =?gb2312?B?PGFwcHMtZGlzY3Vzc0BpZXRmLm9yZz4=?= Subject: [apps-discuss] =?gb2312?b?u9i4tDogUmU6IEFwcHNEaXIgcmV2aWV3IG9m?= =?gb2312?b?IGRyYWZ0LWlldGYtbmZzdjQtcmZjMzUzMGJpcy0yNQ==?= 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: Wed, 08 May 2013 06:20:36 -0000 This is a multi-part message in MIME format. ------=_001_NextPart272565780552_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQoNCnRoYW5rcyBmb3IgeW91ciBraW5kIHJlcGx5Lg0KWW91ciBzdWdnZXN0ZWQgY2hhbmdlIGlz IG9uZSB3YXkgdG8gaW1wcm92ZSB0aGlzIGRvY3VtZW50Lg0KYnV0IEkgc3VnZ2VzdCB5b3UgdG8g YXNrIG1vcmUgaW50ZXJuYXRpb25hbGl6YXRpb24gZXhwZXJ0cycgY29tbWVudHMgYWJvdXQgdGhp cyBpbnRlcm5hdGlvbmFsaXphdGlvbiBpc3N1ZSBpbiB0aGUgYXBwcy1kaXNjdXNzIGxpc3QuDQoN ClJlZ2FyZHMNCg0KDQoNCkppYW5rYW5nIFlhbw0KDQpGcm9tOiBIYXluZXMsIFRvbQ0KRGF0ZTog MjAxMy0wNS0wOCAxMjoyMw0KVG86IEppYW5rYW5nIFlBTw0KQ0M6IDsgDQpTdWJqZWN0OiBSZTog QXBwc0RpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZnN2NC1yZmMzNTMwYmlzLTI1DQpIaSAgSmlh bmthbmcsDQoNCkkgc3Bva2Ugd2l0aCBvdXIgaW50ZXJuYXRpb25hbGl6YXRpb24gZXhwZXJ0IGFu ZCB0aGV5IGRlc2NyaWJlIHRoYXQgb3VyIHVzZSBvZg0Kc3RyaW5ncHJlcCBpcyBpbmZvcm1hdGl2 ZSBhbmQgYXMgYSBndWlkZWxpbmUuDQoNCkFzIHN1Y2gsIHdlIHdpbGwgbW92ZSB0aGUgcmVmZXJl bmNlIHRvIG5vIGxvbmdlciBiZSBub3JtYXRpdmUgYW5kIHRodXMNCmtlZXAgdGhlIGRvY3VtZW50 IHRvIHJlZmVyIHRvIHRoZSBleGlzdGluZyB2ZXJzaW9uIG9mIFVOSUNPREUuDQoNClRoYW5rcywN ClRvbQ0KDQpPbiBBcHIgMTIsIDIwMTMsIGF0IDEyOjU3IEFNLCBKaWFua2FuZyBZQU8gPHlhb2pr QGNubmljLmNuPiB3cm90ZToNCg0KPiBJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgQXBwbGlj YXRpb25zIEFyZWEgRGlyZWN0b3JhdGUgcmV2aWV3ZXIgDQo+IGZvciB0aGlzIGRyYWZ0IChmb3Ig YmFja2dyb3VuZCBvbiBhcHBzZGlyLCBwbGVhc2UgDQo+IHNlZSANCj4gaHR0cDovL3RyYWMudG9v bHMuaWV0Zi5vcmcvYXJlYS9hcHAvdHJhYy93aWtpL0FwcGxpY2F0aW9uc0FyZWFEaXJlY3RvcmF0 ZSANCj4gKS4gIA0KPiBQbGVhc2UgcmVzb2x2ZSB0aGVzZSBjb21tZW50cyBhbG9uZyB3aXRoIGFu eSBvdGhlciBjb21tZW50cyANCj4geW91IG1heSByZWNlaXZlLiBQbGVhc2Ugd2FpdCBmb3IgZGly ZWN0aW9uIGZyb20geW91ciBkb2N1bWVudCANCj4gc2hlcGhlcmQgb3IgQUQgYmVmb3JlIHBvc3Rp bmcgYSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQuDQo+IA0KPiBEb2N1bWVudDogDQo+IGRyYWZ0 LWlldGYtbmZzdjQtcmZjMzUzMGJpcy0yNSANCj4gVGl0bGU6IA0KPiBOZXR3b3JrIEZpbGUgU3lz dGVtIChORlMpIFZlcnNpb24gNCBQcm90b2NvbA0KPiANCj4gDQo+IFJldmlld2VyOiBKaWFua2Fu ZyBZYW8NCj4gUmV2aWV3IERhdGU6IEFwcmlsIDEyLCAyMDEzDQo+IA0KPiBTdW1tYXJ5Og0KPiAN Cj4gVGhpcyBkcmFmdCBpcyB2ZXJ5IGxvbmcuIEkgbWFpbmx5IGZvY3VzIG9uIHNlY3Rpb24gMTIg b2YgdGhpcyBkb2N1bWVudC5UaGlzIHBhcnQgaXMgYWJvdXQgaW50ZXJuYXRpb25hbGl6YXRpb24u DQo+IA0KPiBNYWpvciBpc3N1ZTpub25lLg0KPiANCj4gTWlub3IgaXNzdWU6DQo+IA0KPiAgVGhp cyBwYXJ0IHJlZmVyIHRvIElTTy4xMDY0Ni0xLjE5OTMsIHdoaWNoIGlzIGFsbW9zdCBzYW1lIHRv IFVOSUNPREUgMy4yLiBUaGUgUkZDMzQ1NCByZWZlcnJlZCBieSB0aGlzIGRvY3VtZW50IGlzIGFs c28gYmFzZWQgb24gSVNPLjEwNjQ2LTEuMTk5My4gVGhlIHByb2JsZW0gaXMgdGhhdCB0aGUgVU5J Q09ERSBoYXMgYmVlbiB1cGRhdGVkIHRvIFZlcnNpb24gNi4yIGZyb20gdmVyc2lvbiAzLjIuIFJG QzM0NTQgbWF5IG5vdCB3b3JrIGZvciBVTklDT0RFIDYuMi4NCj4gIFNob3VsZCB0aGlzIGRvY3Vt ZW50IGJlIHVwZGF0ZWQgdG8gcmVmZXIgdG8gdGhlIG5ldyB2ZXJzaW9uIG9mIFVOSUNPREU/DQo+ IA0KPiANCj4gDQo+IEJlc3QgUmVnYXJkcw0KPiANCj4gSmlhbmthbmcgWWFv ------=_001_NextPart272565780552_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
 
 
thanks for your kind reply.
Your suggested change is one way to im= prove=20 this document.
but I suggest you to ask more=20 internationalization experts' comments about this internationali= zation=20 issue in the apps-discuss list.
 
Regards
Jiankang Yao
 
Date: 2013-05-08 12:23
To: Jiankang YAO
CC: ;
Subject: Re: AppsDir review of=20 draft-ietf-nfsv4-rfc3530bis-25
Hi  Jiankang,
 
I spoke with our internationalization expert=  and they describe that our use of
stringprep is informative and as a guid= eline.
 
As such, we will move the reference&nbs= p;to no longer be normative and thus
keep the document to refer to the = existing version of UNICODE.
 
Thanks,
Tom
 
On Apr 12, 2013, at 12:57 AM, Jian= kang YAO <yaojk@cnnic.cn> wrote:
 
> I have been selected as the A= pplications Area Directorate reviewer 
> for this draft (for background on&= nbsp;appsdir, please 
> see 
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsA= reaDirectorate 
> ).  
> Please resolve these comments along&nbs= p;with any other comments 
> you may receive. Please wait for&n= bsp;direction from your document 
> shepherd or AD before posting a&nb= sp;new version of the draft.
> 
> Document: 
> draft-ietf-nfsv4-rfc3530bis-25 
> Title: 
> Network File System (NFS) Version = 4 Protocol
> 
> 
> Reviewer: Jiankang Yao
> Review Date: April 12, 2013
> 
> Summary:
> 
> This draft is very long. I ma= inly focus on section 12 of this docume= nt.This part is about internationalization.
> 
> Major issue:none.
> 
> Minor issue:
> 
>  This part refer to ISO.10646-1.19= 93, which is almost same to UNICODE 3.2= . The RFC3454 referred by this document = ;is also based on ISO.10646-1.1993. The prob= lem is that the UNICODE has been update= d to Version 6.2 from version 3.2. RFC3= 454 may not work for UNICODE 6.2.
>  Should this document be updated&n= bsp;to refer to the new version of UNIC= ODE?
> 
> 
> 
> Best Regards
> 
> Jiankang Yao
 
------=_001_NextPart272565780552_=------ From sm@resistor.net Wed May 8 01:58: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 6AE3321F87B7 for ; Wed, 8 May 2013 01:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 R2kxeWZUVjBD for ; Wed, 8 May 2013 01:58:02 -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 0A00021F86CA for ; Wed, 8 May 2013 01:58:02 -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 r488vsfY017586; Wed, 8 May 2013 01:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1368003481; bh=5NVSxRpbNdVJh/sDbu7ts3gYykZLGpd7fe4ca2mEB0Q=; h=Date:To:From:Subject:Cc; b=MpxqoXPlZSt40PNK9snxslo78UufC3sdaVahMuUBUwM0609w+56Nw0W+XPQpHvDE8 zT02VmgL0RBqTl8OVQn1ghyol5cS5HD8UQoGxDoJurTxa6wkLPy8ut6/n4TjjHsMmu fVX07Hnt0o0FkXNYfxjxhroIFpLjpOX3u9Ut+kas= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1368003481; i=@resistor.net; bh=5NVSxRpbNdVJh/sDbu7ts3gYykZLGpd7fe4ca2mEB0Q=; h=Date:To:From:Subject:Cc; b=dfa3EIxnX3xch9U7s4WTRJgxzx40HA0g0BqI9CSu4abXPW2Ru/Y/vEDH2Qyb9IInN H896/AyFaNzcVJ81Swv5X0cByKtgkt+bLa6Gae6sIGpfde/tw1MtIq05LqR8+kwLm8 veISQH9+86VyTFoNNmFknTJbFYIgD+G9y0x9KaLo= Message-Id: <6.2.5.6.2.20130507230858.0b98cee8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 08 May 2013 01:02:23 -0700 To: ht@inf.ed.ac.uk (Henry S. Thompson), apps-discuss@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-ietf-appsawg-xml-mediatypes.all@tools.ietf.org Subject: [apps-discuss] Comments on draft-ietf-appsawg-xml-mediatypes-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: Wed, 08 May 2013 08:58:07 -0000 Hi Henry, I have a few comments about draft-ietf-appsawg-xml-mediatypes-00. In the Abstract: "XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring ..." XML is not expanded on first use, WWW is in the expanded form, URI is not expanded. I suggest looking up abbreviation guidelines to see what needs to be expanded and what can be used in abbreviated form. In Section 1: "Similarly, XML has been used as a foundation for other media types, including types in every branch of the IETF media types tree. To facilitate the processing of such types, media types based on XML, but that are not identified using application/xml (or text/xml), SHOULD be named using a suffix of '+xml' as described in Section 8." The RFC 2119 SHOULD is defined after that. I suggest removing the "SHOULD" and leaving it to Section to specify how such media types are named. In Section 3: I suggest rewriting the second paragraph in that section to separate the notes from what is being specified. It took me some time to understand that part of the draft. In Section 3.1: "If users would like to rely on the encoding declaration or BOM and to hide charset information from protocols, they SHOULD determine not to use the parameter." I don't understand the above. What is being recommended? Please update the reference for 8BITMIME to RFC 6152. What is the summary in Section 3.6 for? In Section 5: "When the syntax of a fragment identifier part of any URI or IRI with a retrieved media type governed by this specification conforms to the syntax specified in [XPointerFramework], conformant applications MUST attempt to interpret such fragment identifiers as designating that part of the retrieved representation specified by [XPointerFramework] and whatever other specifications define any XPointer schemes used." I read the "MUST attempt" as "give it a try". I suggest rewriting the sentence to make the RFC 2119 requirement clear. "A registry of XPointer schemes [XPtrReg] is maintained at the W3C. Unregistered schemes SHOULD NOT be used." It would be easier to recommend that the schemes which are used are to be registered. In Section 9.12: 'If sent using a 7-bit transport (e.g., SMTP) or an 8-bit clean transport (e.g., 8BITMIME ESMTP or NNTP), the XML MIME entity MUST be encoded in quoted-printable or base64.' This RFC 2119 requirement is also in Section 3.1 and Section 9.4. There are a lot of normative references in this draft. Why is, [PNG], for example normative? I suggest going through the references to see what is needed and what could be moved to Informative (if the reference is still relevant). I found it difficult to identify the (RFC 2119) recommendations and requirements as they appear in several parts of the draft (re: comment about Section 9.12). I suggest making the text crisp. This could be done by reformatting some parts of the draft (e.g. see comment about second paragraph of Section 3.1). By the way, an "Obsoletes" for RFC 3023 should be added. There is a school of thought about not making any normative statements in examples. It could be said that examples are to be used sparingly as it distracts the reader from what is being specified. From the Abstract I read that the purpose of the draft is: - standardizes three media types - standardizes a convention - alignment of charset handling I suggest having that as the focus for the draft. I understand that it is difficult to make changes for a -bis. I would consider that for this draft for document clarity [1]. Regards, -sm 1. https://www.youtube.com/watch?v=JEpsKnWZrJ8 From barryleiba@gmail.com Wed May 8 02:07: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 3C55621F84F8 for ; Wed, 8 May 2013 02:07:37 -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 i0VMq-D3zn+2 for ; Wed, 8 May 2013 02:07:32 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 310B621F8F0C for ; Wed, 8 May 2013 02:06:08 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id eg20so1490087lab.7 for ; Wed, 08 May 2013 02:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:cc:content-type; bh=blpFfyAmQw2mGxFasbmF8Ge5fm5hztYFkmY3t5EoZas=; b=Uwy/C8A3GdVDGbQth/aUqhKyJQnyi/dZW6eS0QTyYINAIHlBRsNLi3bHmatqajKKvS dPy5C2TWERqePJzdFaG6WnKdRLdbtlBbGDQhqWIDcizJ6SP3LPIOUtFDuKXu8v1hmLzv aYfqzJn43s6ryNQa5PvKkhyct7j2kcxR/DZxyCYxqgX23OtdWRCoK1D+4nM/v0LX0pIW AD+9TOhAc8lu47AELe0rvcLThewOdCUlIl7rZdcl7v8+/emkz2AvWCIAnsqTpwUVp3B/ aSKq1wUgt5vN4i2TMoHJkcCMMd+v/cTjRkrCdhHIGIex5GwTkzLHGVFFQmj1YfjugIUN yHsQ== MIME-Version: 1.0 X-Received: by 10.152.87.39 with SMTP id u7mr2629198laz.48.1368003967833; Wed, 08 May 2013 02:06:07 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.112.34.9 with HTTP; Wed, 8 May 2013 02:06:07 -0700 (PDT) Date: Wed, 8 May 2013 10:06:07 +0100 X-Google-Sender-Auth: cO0oZ4D5OPFTpKzpRTo5Ux4CsSc Message-ID: From: Applications Area Directors To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Cc: SM Subject: [apps-discuss] Applications Area Directorate team leader X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 May 2013 09:07:37 -0000 SM has been the team leader of the Applications Area Directorate [1] (formerly the Applications Area Review Team) for a good long time now. He's been asking us to find a new team leader for a while; we've shuffled our feet and dawdled, because SM's done such a good job at it and we haven't wanted to lose him. We have, however, finally taken action on this. We've asked Claudio Allocchio to work with SM to transition into the role, and he has agreed to do so. Many thanks to Claudio for taking this on, and many more thanks to SM for having done it so well for so long. And thanks to all those who serve on the Directorate: the reviews and other advice are a great help to the Applications ADs, and we very much appreciate the work. Barry and Pete, Applications Area Directors [1] http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate From alexey.melnikov@isode.com Wed May 8 02:26:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9517D21F8E04 for ; Wed, 8 May 2013 02:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.202 X-Spam-Level: X-Spam-Status: No, score=-101.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 fiE6h8Wg7qIM for ; Wed, 8 May 2013 02:26:11 -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 CF49F21F8D2C for ; Wed, 8 May 2013 02:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1368005169; d=isode.com; s=selector; i=@isode.com; bh=CzgGlkc4J3fFQkl4WKfktm2//8oNzXyaoH9q44jAs6k=; 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=BFXuOENBxAWqGMN+NtEXFamx5tWcO03jYi6Go8fATBd/2ifR94NYTylSx/pX+vhmcWnUi/ naKJqp9yBLsB75DTMryhF+hM8Uhpe/TBbaK1L0821PsP9HEN3ypI6e8Y9ckx1W7qPeLgf4 qXzs9+f+av38wnaKwmzy4hUmI4sWPO8=; Received: from [92.41.176.247] (92.41.176.247.threembb.co.uk [92.41.176.247]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 8 May 2013 10:26:06 +0100 References: In-Reply-To: Message-Id: X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Wed, 8 May 2013 10:29:12 +0100 To: "Murray S. Kucherawy" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-907AC180-3DCF-444E-9DB2-481A024F33EE Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Processing draft-bosch-sieve-duplicate via APPSAWG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 May 2013 09:26:11 -0000 --Apple-Mail-907AC180-3DCF-444E-9DB2-481A024F33EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 7 May 2013, at 23:43, "Murray S. Kucherawy" wrote: > On Tue, May 7, 2013 at 3:24 PM, Murray S. Kucherawy w= rote: > We have received a request to process the above draft through APPSAWG, sin= ce there is no longer a sieve WG. It is a relatively short document and app= ears to fall within our charter. >=20 > We haven't processed a sieve extension here yet; rather, they've gone thro= ugh small, tight WGs so far. Before issuing a formal call for adoption, I'd= like to gauge whether we have enough sieve-aware people currently following= APPSAWG to be able to contribute reviews and constructive commentary. A vi= rtual show of hands, please? >=20 >=20 > I should add that the person submitting the request was not the author and= has volunteered to shepherd the document, so add one to whatever count come= s out of this thread. :-)=20 I am interested (and I commented on earlier versions of this draft). --Apple-Mail-907AC180-3DCF-444E-9DB2-481A024F33EE Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
On 7 May 2013, at 23:43, "Murray S. Kucherawy" <superuser@gmail.com> wrote:

On Tue, May 7, 2013 at 3:24 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
We have received a request to process the above draft through APPSAWG, since there is no longer a sieve WG.  It is a relatively short document and appears to fall within our charter.

We haven't processed a sieve extension here yet; rather, they've gone through small, tight WGs so far.  Before issuing a formal call for adoption, I'd like to gauge whether we have enough sieve-aware people currently following APPSAWG to be able to contribute reviews and constructive commentary.  A virtual show of hands, please?


I should add that the person submitting the request was not the author and has volunteered to shepherd the document, so add one to whatever count comes out of this thread.  :-) 

I am interested (and I commented on earlier versions of this draft).

--Apple-Mail-907AC180-3DCF-444E-9DB2-481A024F33EE-- From vesely@tana.it Wed May 8 02:35: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 C442221F9023 for ; Wed, 8 May 2013 02:35:21 -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 vcR3LHioFhLV for ; Wed, 8 May 2013 02:35:16 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3C51321F900C for ; Wed, 8 May 2013 02:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1368005714; bh=B4jeQxvnYjXgerYmKAEp1G+uiry/L+i/T0K+PsMonw8=; l=1071; h=Date:From:To:References:In-Reply-To; b=Wa38LYt0cJfB9moHAFtbVhm99Ise6Tyeol2PrLgUdBSNCEBJwJWQdIabj5JnZsaKW 1JfxkQ3327RDVpmdLdQV5Bwc8FF+O6h70l4bMFb3nHsnO4lq9rpEcwa81qpgmY/033 CDJel6jVAk00jRewGtyjo+9IieLzUwSHTjX5oCEI= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Wed, 08 May 2013 11:35:13 +0200 id 00000000005DC039.00000000518A1C51.00007B3F Message-ID: <518A1C4D.3050506@tana.it> Date: Wed, 08 May 2013 11:35:09 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> <5187DA74.9020204@tana.it> <518920D0.1040705@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-01 (was -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: Wed, 08 May 2013 09:35:21 -0000 On Wed 08/May/2013 00:35:44 +0200 Murray S. Kucherawy wrote: > > I'm about to post a new version with this section reworked a bit. Let me > know what you think of it. A couple of nits: s/contect/context/, and in the sentence: For example, [SPF] can base its inclusion on the RFC5321.Helo parameter or on the RFC5322.From domain; including both of those in the header field makes it impossible for the consumer to determine which mode of SPF was applied s/inclusion/conclusion/, and s/RFC5322.From/RFC5321.MailFrom/. Maybe "which parameter was actually used" is clearer than "which mode of SPF was applied", since SPF lacks a definition of "mode". On Wed 08/May/2013 01:14:34 +0200 Barry Leiba wrote:> > For citations to this document (well, or the original version, for > now) from elsewhere, one might say something like this: > > "The description of the Message Authentication Status header field > [RFC5451], specifies that <...etc...>" Would it make sense to change the title into: *The Authentication-Results Header Field* ? From Claudio.Allocchio@garr.it Wed May 8 03:12: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 3165021F8EF7 for ; Wed, 8 May 2013 03:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[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 g5Zj4hiMDwnC for ; Wed, 8 May 2013 03:11:58 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id F259921F905C for ; Wed, 8 May 2013 03:11:57 -0700 (PDT) Received: internal info suppressed Date: Wed, 8 May 2013 12:11:28 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: Applications Area Directors In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1368007891; bh=GmNjjPqo88vlQiMLOyMOvwKrrI80/WjqofkEQxHf+gw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=R+XDHcaQASMtnKQzEU5eUTId21LcMoeCQraLzILZjxESzxEe8oThP5wMO6dlqCNI+ VMWrylgktxwcFRk7jVgEmyKxciGDe6hHkNF35G7VQO5rI4q9ZGeH3lLOAhtUJvHji1 +IY+nV0+nHEHv3vu3ovIR3bELmyPwZRXoGZnq6ns= Cc: SM , Apps Discuss Subject: Re: [apps-discuss] Applications Area Directorate team leader X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 May 2013 10:12:02 -0000 On Wed, 8 May 2013, Applications Area Directors wrote: > SM has been the team leader of the Applications Area Directorate [1] > (formerly the Applications Area Review Team) for a good long time now. > He's been asking us to find a new team leader for a while; we've > shuffled our feet and dawdled, because SM's done such a good job at it > and we haven't wanted to lose him. > > We have, however, finally taken action on this. We've asked Claudio > Allocchio to work with SM to transition into the role, and he has > agreed to do so. > > Many thanks to Claudio for taking this on, and many more thanks to SM > for having done it so well for so long. And thanks to all those who > serve on the Directorate: the reviews and other advice are a great > help to the Applications ADs, and we very much appreciate the work. thanks Barry and Pete, and of course SM for your wonderful job which makes a serious challenge for me to be able to do "keep the high standard quality" ! :-) As we are transitioning, it is likely that you see messages both from myself and SM coming to you for a while, but it won't be a problem. See you all soon! > > Barry and Pete, Applications Area Directors > > [1] http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate > ------------------------------------------------------------------------------ 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 sm@elandsys.com Wed May 8 03:44: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 A5CCE21F91B8; Wed, 8 May 2013 03:44:09 -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 punltYPdEiEY; Wed, 8 May 2013 03:44:04 -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 0BA8D21F91B0; Wed, 8 May 2013 03:44:03 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.145.230]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r48AhZdI007984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 May 2013 03:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1368009828; bh=EJ7/6l+hV0iuC0kj+EvCPbl9yv/6atyRr3ssDz1Q2ek=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=h0qZxjzGXT8lwrhaVg6+qfv53+hTC/IlyWkeV/usBRB+TH2axG11B4+WEfVeNNRc3 bZriYOFabEgcW4c08huH8YfismUfLXkvgTLejvRCJQwAlc0Giaweq8pkOC3SPACCbb phHIP9q2DruNNsOYqllu/+dt0F95ezdIk2G429EA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1368009828; i=@elandsys.com; bh=EJ7/6l+hV0iuC0kj+EvCPbl9yv/6atyRr3ssDz1Q2ek=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=igqDpcNUaifKjkNZA3EYqgW/criVlKRl7Yk8rcQzNbMRI7qz3XMIwDRKJGEuNbUxl hoFyjH1M2eGmU34oArP418M5u6RCiae4JgqdtnusId2oMVh2urSiXPKjVcJs5vJSJk kFsKYaL+F2BT3LN7Z9ta5YoJYAxsQ/YTPKrcw3Ho= Message-Id: <6.2.5.6.2.20130508021335.0b8a83d0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 08 May 2013 03:42:49 -0700 To: apps-discuss@ietf.org From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [apps-discuss] Applications Area Directorate team leader X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 May 2013 10:44:10 -0000 Hello, I would like to congratulate Claudio Allocchio,=20 the new Applications Area Directorate Team=20 Lead. Claudio has been on the directorate since=20 a few years. He performed the most difficult=20 AppsDir review. In my opinion it is in the=20 interest of the directorate to have a new team=20 lead who can bring in new ideas and ensure continuity. I would like to thank Barry and Pete for their=20 support. I'll add a special thanks to Alexey and=20 Peter who have both been a tremendous help in=20 getting the directorate started and making it work. I got to appreciate the finer qualities of each=20 member of the directorate over the last few=20 years. I am indebted to the following persons=20 for volunteering their time and effort as members of the directorate: Carsten Bormann Tim Bray Eric Burger Dave Cridland Dave Crocker Martin D=FCrst Tobias Gondrom Bert Greevenbosch Vijay Gurbani Ted Hardie John Klensin Murray S. Kucherawy Yves Lafon Eliot Lear Salvatore Loreto Enrico Marocco Larry Masinter Mark Nottingham Ray Polk Julian Reschke Henry S. Thompson Martin Thomson He Xuan Jiankang Yao Joseph Yee Yoshiro Yoneya It has been a pleasure working with you. Regards, S. Moonesamy From Tom.Haynes@netapp.com Tue May 7 21:23: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 DC84921F8BBA; Tue, 7 May 2013 21:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.246 X-Spam-Level: X-Spam-Status: No, score=-8.246 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_54=0.6, MIME_BASE64_TEXT=1.753, 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 D4GYjzdu+ro4; Tue, 7 May 2013 21:23:21 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id C471921F8E04; Tue, 7 May 2013 21:23:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,632,1363158000"; d="scan'208";a="50602248" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 07 May 2013 21:23:19 -0700 Received: from vmwexceht05-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.77.35]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r484NJtS016033; Tue, 7 May 2013 21:23:19 -0700 (PDT) Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.213]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.03.0123.003; Tue, 7 May 2013 21:23:19 -0700 From: "Haynes, Tom" To: Jiankang YAO Thread-Topic: AppsDir review of draft-ietf-nfsv4-rfc3530bis-25 Thread-Index: AQHON1NmG4n4vmHpakGWVyE63IdR7Jj7TjkA Date: Wed, 8 May 2013 04:23:18 +0000 Message-ID: <3A330EAE-1D6F-439E-9378-D569A9233D5F@netapp.com> References: <6E0E2EDBD7BF49FF94AD9DBA96C88E07@LENOVO47E041CF> In-Reply-To: <6E0E2EDBD7BF49FF94AD9DBA96C88E07@LENOVO47E041CF> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="gb2312" Content-ID: <331D85026B1354429A88EEBC06537C1A@hq.netapp.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 08 May 2013 08:01:50 -0700 Cc: "" , "" Subject: Re: [apps-discuss] AppsDir review of draft-ietf-nfsv4-rfc3530bis-25 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 May 2013 04:23:26 -0000 SGkgIEppYW5rYW5nLA0KDQpJIHNwb2tlIHdpdGggb3VyIGludGVybmF0aW9uYWxpemF0aW9uIGV4 cGVydCBhbmQgdGhleSBkZXNjcmliZSB0aGF0IG91ciB1c2Ugb2YNCnN0cmluZ3ByZXAgaXMgaW5m b3JtYXRpdmUgYW5kIGFzIGEgZ3VpZGVsaW5lLg0KDQpBcyBzdWNoLCB3ZSB3aWxsIG1vdmUgdGhl IHJlZmVyZW5jZSB0byBubyBsb25nZXIgYmUgbm9ybWF0aXZlIGFuZCB0aHVzDQprZWVwIHRoZSBk b2N1bWVudCB0byByZWZlciB0byB0aGUgZXhpc3RpbmcgdmVyc2lvbiBvZiBVTklDT0RFLg0KDQpU aGFua3MsDQpUb20NCg0KT24gQXByIDEyLCAyMDEzLCBhdCAxMjo1NyBBTSwgSmlhbmthbmcgWUFP IDx5YW9qa0Bjbm5pYy5jbj4gd3JvdGU6DQoNCj4gSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhl IEFwcGxpY2F0aW9ucyBBcmVhIERpcmVjdG9yYXRlIHJldmlld2VyIA0KPiBmb3IgdGhpcyBkcmFm dCAoZm9yIGJhY2tncm91bmQgb24gYXBwc2RpciwgcGxlYXNlIA0KPiBzZWUgDQo+IGh0dHA6Ly90 cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvYXBwL3RyYWMvd2lraS9BcHBsaWNhdGlvbnNBcmVhRGly ZWN0b3JhdGUgDQo+ICkuICANCj4gUGxlYXNlIHJlc29sdmUgdGhlc2UgY29tbWVudHMgYWxvbmcg d2l0aCBhbnkgb3RoZXIgY29tbWVudHMgDQo+IHlvdSBtYXkgcmVjZWl2ZS4gUGxlYXNlIHdhaXQg Zm9yIGRpcmVjdGlvbiBmcm9tIHlvdXIgZG9jdW1lbnQgDQo+IHNoZXBoZXJkIG9yIEFEIGJlZm9y ZSBwb3N0aW5nIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0Lg0KPiANCj4gRG9jdW1lbnQ6IA0K PiBkcmFmdC1pZXRmLW5mc3Y0LXJmYzM1MzBiaXMtMjUgDQo+IFRpdGxlOiANCj4gTmV0d29yayBG aWxlIFN5c3RlbSAoTkZTKSBWZXJzaW9uIDQgUHJvdG9jb2wNCj4gDQo+IA0KPiBSZXZpZXdlcjog SmlhbmthbmcgWWFvDQo+IFJldmlldyBEYXRlOiBBcHJpbCAxMiwgMjAxMw0KPiANCj4gU3VtbWFy eToNCj4gDQo+IFRoaXMgZHJhZnQgaXMgdmVyeSBsb25nLiBJIG1haW5seSBmb2N1cyBvbiBzZWN0 aW9uIDEyIG9mIHRoaXMgZG9jdW1lbnQuVGhpcyBwYXJ0IGlzIGFib3V0IGludGVybmF0aW9uYWxp emF0aW9uLg0KPiANCj4gTWFqb3IgaXNzdWU6bm9uZS4NCj4gDQo+IE1pbm9yIGlzc3VlOg0KPiAN Cj4gIFRoaXMgcGFydCByZWZlciB0byBJU08uMTA2NDYtMS4xOTkzLCB3aGljaCBpcyBhbG1vc3Qg c2FtZSB0byBVTklDT0RFIDMuMi4gVGhlIFJGQzM0NTQgcmVmZXJyZWQgYnkgdGhpcyBkb2N1bWVu dCBpcyBhbHNvIGJhc2VkIG9uIElTTy4xMDY0Ni0xLjE5OTMuIFRoZSBwcm9ibGVtIGlzIHRoYXQg dGhlIFVOSUNPREUgaGFzIGJlZW4gdXBkYXRlZCB0byBWZXJzaW9uIDYuMiBmcm9tIHZlcnNpb24g My4yLiBSRkMzNDU0IG1heSBub3Qgd29yayBmb3IgVU5JQ09ERSA2LjIuDQo+ICBTaG91bGQgdGhp cyBkb2N1bWVudCBiZSB1cGRhdGVkIHRvIHJlZmVyIHRvIHRoZSBuZXcgdmVyc2lvbiBvZiBVTklD T0RFPw0KPiANCj4gDQo+IA0KPiBCZXN0IFJlZ2FyZHMNCj4gDQo+IEppYW5rYW5nIFlhbw0KDQo= From sm@elandsys.com Wed May 8 10:07: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 966C021F9375; Wed, 8 May 2013 10:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.177 X-Spam-Level: X-Spam-Status: No, score=-100.177 tagged_above=-999 required=5 tests=[AWL=-2.423, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_GB2312=1.345, 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 R01YuYEnJIID; Wed, 8 May 2013 10: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 2585F21F9335; Wed, 8 May 2013 10:07:37 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.145.230]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r48H6gFP011969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 May 2013 10:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1368032816; bh=pHFwVH5WGUFKnlv2m6p/nX73q8qLaZ1gf/ulAo38N24=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=C8h9x2cV5AcBzTXWn+VrcHvUlFzNKbzm0flQdV5fbgoq7gg+MN7J+58cgS/RSWKMp hcP49/P4Zj3xxr5+qBrGn/YsFo2LnJq//nOkbEFgBU0g4P8SOibxxg44igSXKc0QiT 9GuYKcfTE8QcVRvZOybOZgFnvFI6SIS+wJI0+xL4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1368032816; i=@elandsys.com; bh=pHFwVH5WGUFKnlv2m6p/nX73q8qLaZ1gf/ulAo38N24=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QgYQ0ip7PBFfGl0IBTo++xsZt+6wtozqIYWzy+VZYWvoIoUg7GLq+QEm9I/9gFA+W 5KFquYHQbXaBLYUSeF/BbBmIGdiqW2mptU4OiSyZ8y9+LaE5M6VqZizmnaQ+36pBPf yf7zcIIjfzZZWXrdGcO+2p37rWhgIyACCw8bM3vo= Message-Id: <6.2.5.6.2.20130508084636.0c032198@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 08 May 2013 09:18:41 -0700 To: apps-discuss@ietf.org From: S Moonesamy In-Reply-To: <2013050814191964838318@cnnic.cn> References: <6E0E2EDBD7BF49FF94AD9DBA96C88E07@LENOVO47E041CF> <3A330EAE-1D6F-439E-9378-D569A9233D5F@netapp.com> <2013050814191964838318@cnnic.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Tom.Haynes@netapp.com, nfsv4@ietf.org Subject: Re: [apps-discuss] =?gb2312?b?u9i4tDogUmU6IEFwcHNEaXIgcmV2aWV3IG9m?= =?gb2312?b?IGRyYWZ0LWlldGYtbmZzdjQtcmZjMzUzMGJpcy0yNQ==?= X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 May 2013 17:07:37 -0000 At 23:20 07-05-2013, Jiankang Yao wrote: > thanks for your kind reply. >Your suggested change is one way to improve this document. >but I suggest you to ask more internationalization experts' comments >about this [snip] >From: Haynes, Tom >Date: 2013-05-08 12:23 >To: Jiankang YAO >CC: ; >Subject: Re: AppsDir review of draft-ietf-nfsv4-rfc3530bis-25 >Hi Jiankang, > >I spoke with our internationalization expert and they describe that our use of >stringprep is informative and as a guideline. > >As such, we will move the reference to no longer be normative and thus >keep the document to refer to the existing version of UNICODE. This is a comment and not expert advice. RFC 6885 mentions that Stringprep is bound to Version 3.2 of Unicode and that protocols using it are stuck on that version. I don't recall the status of the working group work. From Section 12.1.1: "NFSv4, while it does make normative references to stringprep and uses elements of that framework, it does not, for reasons that are explained below, conform to that framework, for all of the strings that are used within it." It is unclear whether the use of stringprep is informative or normative. Section 12 of the draft is well-written. Some of the issues mentioned in that section have been raised during the IDNA discussions. Section 12 would benefit from more review. Regards, S. Moonesamy From msk@blackops.org Wed May 8 14:58: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 56B6421F8BB7; Wed, 8 May 2013 14:58:58 -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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U2R5HJO66oS; Wed, 8 May 2013 14:58:52 -0700 (PDT) Received: from medusa.blackops.org (medusa.blackops.org [208.69.40.157]) by ietfa.amsl.com (Postfix) with ESMTP id 5A83821F86C1; Wed, 8 May 2013 14:58:52 -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 r48LwlPj051484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 May 2013 14:58:48 -0700 (PDT) (envelope-from msk@medusa.blackops.org) DKIM-Filter: OpenDKIM Filter v2.8.3 medusa.blackops.org r48LwlPj051484 X-SenderID: Sendmail Sender-ID Filter v1.0.0 medusa.blackops.org r48LwlPj051484 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 r48LwkGe051483; Wed, 8 May 2013 14:58:46 -0700 (PDT) (envelope-from msk) Date: Wed, 8 May 2013 14:58:46 -0700 (PDT) Message-Id: <201305082158.r48LwkGe051483@medusa.blackops.org> From: "Murray S. Kucherawy" To: apps-discuss@ietf.org, draft-ietf-6man-impatient-nud.all@tools.ietf.org Cc: iesg@ietf.org Subject: [apps-discuss] AppsDir reivew of draft-ietf-6man-impatient-nud X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 May 2013 21:58:58 -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-6man-impatient-nud Title: Neighbor Unreachability Detection is too impatient Reviewer: Murray S. Kucherawy Review Date: May 8, 2013 IETF Last Call Date: ends May 9, 2013 IESG Telechat Date: May 9, 2013 Summary: This document is almost ready for publication on the Standards Track. The technology described in it seems sound overall. However, the document is in some need of an editorial pass as I found myself tripping over several expressions and such. So, rather than providing a technical review (which doesn't seem to be needed), my comments below are entirely stylistic or grammatical in the hopes that you'll get to AUTH48 a little faster. MAJOR ISSUES: None. MINOR ISSUES: These are all editorial concerns that caused me to stumble while reading. I think they're more important to fix, to help future readers, than the ones I listed under "NITS". Section 1, Introduction: "These short can be appropriate" should be "This short timeout can be appropriate" or some such. The "For example... " sentence is a fragment. Suggest adding to the end: ", then a short timeout functions well." "alternative neighbor;" should be "alternative neighbor," The second and third paragraphs don't need to be separate. I suggest merging them. Add a comma right after "As a result" and "For IPv4". Section 3, Protocol Updates: For the expression MAX_UNICAST_SOLICIT/MAX_MULTICAST_SOLICIT, is that "or" or "division"? I suggest not using the slash but rather using text to say what you mean there. Change "it SHOULD" to "they SHOULD" since you're talking about a plural ("implementations"). Fourth paragraph, add a comma after "above". I suggest a section reference for the conceptual model mentioned in paragraph five, not just a document reference. Change "But in the UNREACHABLE state" to "However, in the UNREACHABLE state," In the sixth paragraph you talk about "we" for the first time. The style should be consistent, so use "implementations" instead of "we". In paragraph 7, add a comma after "Thus". In paragraph 10, change the second sentence to: UNREACHABLE is added to the current list of STALE, PROBE, or DELAY. Change "That needs to be replaced by" to "The following table replaces the State table at Section [xxx] of RFC4861." and remove the original table. Change "clamped at" to "limited to". Change "then it makes sense to stop" to "then implementations MAY discontinue". In the last paragraph, please be more specific than "sooner or later". Section 4, Example Algorithm: Change "that allows it" to "that allow it" (you're talking about multiple configuration values this time). In the second paragraph, please express the equation using a figure or other illustration rather than making it part of the prose. Third paragraph, add a comma after "transmissions". of course. Same in the following two paragraphs. Add a comma after "With the above recommended values". Add a comma after "In the language of the state machine in [RFC4861]", and another after "Thus". In "in a link-layer address i.e., the case when", add a comma after "address". Change "you would get the same behavior as in [RFC4861]" to "the same behavior as in [RFC4861] would be produced". Use a figure or illustration for the equation in the last paragraph as well. Section 7, IANA Considerations: Include an RFC Editor note to remove the section prior to publication. NITS: These are all minor things, pet peeves and the like. The RFC Editor will probably make them too, but I won't complain if you don't fix them. :-) Title should be "Neighbor Unreachability Detection Is Too Impatient" (note capitalization). In the abstract, "3" should be "three". Also, "whether or not" should be just "whether". In paragraph four of Section 1, s/which/that/. In paragraph five of Section 1, s/it means that/it means/ In Section 3, change "A node MAY garbage collect" to "A node MAY perform garbage collection". In Section 4, first sentence, s/which/that/. Also in Section 4, in the fourth paragraph: For numbers lower than ten, use the English word rather than the numeral (e.g. "five attempts", "one second", "three seconds", etc.). You don't need to do this for your configuration settings, however. From barryleiba.mailing.lists@gmail.com Thu May 9 01: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 9C44721F8F07; Thu, 9 May 2013 01:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.963 X-Spam-Level: X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 9xFKDjKjbDV3; Thu, 9 May 2013 01:40:31 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7AB21F84F9; Thu, 9 May 2013 01:40:30 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id 13so2737069lba.8 for ; Thu, 09 May 2013 01:40:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=HUgIwO6yNWvHwSNVcqjk8hfQr//k4yQ841+ALU4iWmQ=; b=I4WlEvUFR1qoPLCEZpwiojDxIMYnSrtmeZNYC7jMOVYRCz6cUUrInGwNzrRd8Sbo3g d1qblD5khI9H/MZp+W4MJgxgOyS07D3kmATdCJWMJr6W+4EdVmk2h3yXUunR6q1Mua+O YSe1B7HpMjouUhRE6l+zI0+/u/GACOdD6QErBZIz+fcgAYj7R6t5BpAJxBFDOtEe6W8d sT5jpKk6ukdCK5y3YOxHLNFPjWqDI6XqJw5KyGj0XS0xCbdpaqssYjx3qzENOSIbVAQF SFQP2Je61hhzbb9dLd4+5qJdVmf2/jwiV8ooXSYOEAvT60Ur17Zb6ZJIxJxFxk7MXTXR 1Z+Q== MIME-Version: 1.0 X-Received: by 10.152.2.73 with SMTP id 9mr4937462las.45.1368088829223; Thu, 09 May 2013 01:40:29 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.61.33 with HTTP; Thu, 9 May 2013 01:40:28 -0700 (PDT) In-Reply-To: <201305082158.r48LwkGe051483@medusa.blackops.org> References: <201305082158.r48LwkGe051483@medusa.blackops.org> Date: Thu, 9 May 2013 04:40:28 -0400 X-Google-Sender-Auth: 9UJjN6TMoaqLF2B3zv4xg2mFJEQ Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-6man-impatient-nud.all@tools.ietf.org, IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] AppsDir reivew of draft-ietf-6man-impatient-nud X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2013 08:40:37 -0000 Thanks for the appsdir review, Murray. > "alternative neighbor;" should be "alternative neighbor," Actually, it should be "alternative neighbor, try" in order to keep the list parallel. Also, "or discard the NCE which will also send using a different router." should probably be rephrased. Is it the NCE that will send? Or is it that discarding the NCE will cause the use of a different router? > Change "But in the UNREACHABLE state" to "However, in the UNREACHABLE state," Why? What's wrong with it as it's written? > Change "then it makes sense to stop" to "then implementations MAY discontinue". Please, no. As it's written, it says that it's a good idea to stop the retransmits. Changing it to "MAY" says that it's entirely optional, losing the sense that this is a recommendation. There's no need for 2119 language here, and "discontinue" isn't better than "stop". I think this one is fine as written. > In the last paragraph, please be more specific than "sooner or later". I agree, but to clarify why: It might be reasonable to say "sooner or later", "eventually", or some such if you weren't saying that it "MUST switch". If there's a reason to switch that involves interoperability of the protocol (and there seems to be, as you explain in the next sentence), then you ought to be able to say something better than this. If I don't switch to multicast until the very last NS I ever send, is that OK? > In the second paragraph, please express the equation using a figure or other > illustration rather than making it part of the prose. Ooh... yes, this is really hard to read this way. > Third paragraph, add a comma after "transmissions". > of course. Same in the following two paragraphs. Kind of a style issue here, really. I would probably put in the comma, yes. More importantly, should the second sentence have this change?: OLD After MAX_UNICAST_SOLICIT the implementation NEW After MAX_UNICAST_SOLICIT transmissions, the implementation > In paragraph four of Section 1, s/which/that/. You mean in, "For IPv4 there is no mandatory time limit on the retransmission behavior for ARP [RFC0826] which allows implementors to pick more robust schemes." ? No, that's the wrong fix (which is the problem with which/that errors). I think the correct fix here is to put a comma before "which" (the following clause is a consequence, not a restriction). Barry, Applications AD From stpeter@stpeter.im Thu May 9 05:38: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 61D9321F8E59 for ; Thu, 9 May 2013 05:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 GqTLg6PbpIWk for ; Thu, 9 May 2013 05:38:33 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B569321F8E04 for ; Thu, 9 May 2013 05:38:33 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B25C440038 for ; Thu, 9 May 2013 06:50:15 -0600 (MDT) Message-ID: <518B98CA.7020100@stpeter.im> Date: Thu, 09 May 2013 06:38:34 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: <20130509035220.2061.846.idtracker@ietfa.amsl.com> In-Reply-To: <20130509035220.2061.846.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <20130509035220.2061.846.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Fwd: I-D Action: draft-saintandre-username-interop-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, 09 May 2013 12:38:38 -0000 Perhaps of interest here, and semi-related to the acct URI I-D... -------- Original Message -------- Subject: I-D Action: draft-saintandre-username-interop-00.txt Date: Wed, 08 May 2013 20:52:20 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Username Interoperability Author(s) : Peter Saint-Andre Filename : draft-saintandre-username-interop-00.txt Pages : 9 Date : 2013-05-08 Abstract: Various Internet protocols have defined constructs for usernames. This document describes a subset of characters to allow in usernames for maximal interoperability across Internet protocols. The subset might prove useful in cases where a provider offers multiple services using the same underlying identifier. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-saintandre-username-interop There's also a htmlized version available at: http://tools.ietf.org/html/draft-saintandre-username-interop-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From paul.hoffman@vpnc.org Thu May 9 07:05: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 3451221F8E8F for ; Thu, 9 May 2013 07:05:38 -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 Z2QB8abPuqL4 for ; Thu, 9 May 2013 07:05:37 -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 BA44121F8956 for ; Thu, 9 May 2013 07:05:37 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r49E5Y4M051664 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 9 May 2013 07:05:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <518B98CA.7020100@stpeter.im> Date: Thu, 9 May 2013 07:05:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130509035220.2061.846.idtracker@ietfa.amsl.com> <518B98CA.7020100@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1503) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-saintandre-username-interop-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, 09 May 2013 14:05:38 -0000 The term "username" might confusing here. For many web sites (not = application protocols), a username is often an email address. Someone = reading this document might wonder why email addresses cannot be = usernames. I propose you add a sentence very early, probably in the = introduction, emphasizing that this is about usernames in protocols, not = in the applications themselves. --Paul Hoffman= From stpeter@stpeter.im Thu May 9 07:41:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDE721F8956 for ; Thu, 9 May 2013 07:41:56 -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 rtMf88HiUW+7 for ; Thu, 9 May 2013 07:41:51 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2977D21F880F for ; Thu, 9 May 2013 07:41:51 -0700 (PDT) Received: from ergon.local (unknown [24.9.168.255]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A87DD40038; Thu, 9 May 2013 08:53:33 -0600 (MDT) Message-ID: <518BB5AF.1070709@stpeter.im> Date: Thu, 09 May 2013 08:41:51 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Paul Hoffman References: <20130509035220.2061.846.idtracker@ietfa.amsl.com> <518B98CA.7020100@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-saintandre-username-interop-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, 09 May 2013 14:41:57 -0000 On 5/9/13 8:05 AM, Paul Hoffman wrote: > The term "username" might confusing here. For many web sites (not > application protocols), a username is often an email address. Someone > reading this document might wonder why email addresses cannot be > usernames. I propose you add a sentence very early, probably in the > introduction, emphasizing that this is about usernames in protocols, > not in the applications themselves. Good point. I almost used "localpart" but that seemed a bit arcane. I'm not sure if this document has a future (if so, I'll want to do more research on various localpart constructs), but it was worth writing up if only to clarify some questions that arose during IESG review of the acct-uri I-D (e.g., "why isn't this a Network Address Identifier?"). Peter From martin.thomson@skype.net Wed May 8 14:06: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 C74F621F8644; Wed, 8 May 2013 14:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=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 Zqp2AeTbdONH; Wed, 8 May 2013 14:06:00 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) by ietfa.amsl.com (Postfix) with ESMTP id 5457721F8607; Wed, 8 May 2013 14:06:00 -0700 (PDT) Received: from BN1BFFO11FD009.protection.gbl (10.58.52.200) by BN1AFFO11HUB005.protection.gbl (10.58.52.115) with Microsoft SMTP Server (TLS) id 15.0.687.1; Wed, 8 May 2013 21:05:53 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD009.mail.protection.outlook.com (10.58.53.69) with Microsoft SMTP Server (TLS) id 15.0.687.1 via Frontend Transport; Wed, 8 May 2013 21:05:52 +0000 Received: from TK5EX14MBXC254.redmond.corp.microsoft.com ([169.254.2.16]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Wed, 8 May 2013 21:05:41 +0000 From: Martin Thomson To: "Henry S. Thompson" , "apps-discuss@ietf.org" , "draft-ietf-geopriv-relative-location.all@tools.ietf.org" Thread-Topic: Appsdir review of draft-ietf-geopriv-relative-location Thread-Index: AQHOO3y3PLzt3OUwWkqUnTDtH/frFZj7sbzw Date: Wed, 8 May 2013 21:05:39 +0000 Message-ID: <88EA7D224AA4F24F9D7628368F7572A911BE62E0@TK5EX14MBXC254.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] 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:(51704005)(51444003)(51914003)(189002)(199002)(74662001)(46406003)(76482001)(53806001)(79102001)(47446002)(65816001)(77982001)(66066001)(81342001)(81542001)(74876001)(80022001)(54356001)(31966008)(59766001)(6806003)(4396001)(47736001)(56776001)(54316002)(63696002)(47776003)(69226001)(20776003)(50986001)(16406001)(47976001)(74502001)(23726002)(49866001)(50466002)(74706001)(55846006)(51856001)(74366001)(56816002)(46102001)(33656001); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB005; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 084080FC15 X-Mailman-Approved-At: Thu, 09 May 2013 08:02:35 -0700 Cc: "appsdir@ietf.org" , "iesg@ietf.org" , Brian Rosen Subject: Re: [apps-discuss] Appsdir review of draft-ietf-geopriv-relative-location X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 May 2013 21:06:06 -0000 Hi Henry, Thanks for the review. I apologize for the delay in responding to your ema= il. I can't update the draft to address your concerns, but I'll work with Brian= to ensure that the changes happen. > From: Henry S. Thompson [mailto:ht@inf.ed.ac.uk] > Minor Issues: >=20 > 3 The use of the phrases '"baseline" location' and '"reference" > location' to mean the same thing (?) is confusing in the extreme > (as is the fact that sometimes the phrase includes scare-quotes, > but sometimes not). >=20 > For example, in the following, what is meant to be the difference > between the two highlighted phrases? >=20 > "In particular, while it is possible to put all location > information into the 'reference' location (leaving an > ^^^^^^^^^ > universally broad 'baseline'), location objects SHOULD NOT have > all location information in the baseline location. Doing this > ^^^^^^^^ > would cause clients that do not understand relative location to > incorrectly interpret the baseline location (i.e., the > reference point) as the actual, precise location of the > client." >=20 > Furthermore wrt this passage, either I'm confused, or there's a > mistake at the second highlighted point. I was expecting > "relative", not "baseline" (or "reference"). After all, if all the > information is in the baseline, then there is no information in the > relative part, and so not processing it misses nothing??? >=20 > Ah, repeated re-readings have uncovered the origin of the problem, > further back: >=20 > "A client that does understand this extension will interpret the > location within the relative element as a refinement of the > baseline location, which gives the reference location for the > relative offset." >=20 > I read that the first five times as if it were bracketed like this: >=20 > [a refinement of [the baseline location, which gives the > reference location for the relative offset]]. >=20 > But you mean it as if it were bracketed like this: >=20 > [a refinement of the baseline location], [which gives the > reference location for the relative offset]. >=20 > So, I suggest you rephrase the whole sentence along the following > lines: >=20 > "A client that does understand this extension will interpret the > location within the relative element as a refinement of the > baseline location. The resulting refined location then gives > the reference location for the relative offset." >=20 > With that change, the paragraph containing the first quote above > (the para beginning "The baseline location SHOULD be general > enough") is comprehensible, but still very dense. I know > illustrations are hard when one is restricted to ASCII-art, but a > pair of examples would be a great help here, where one obeys the > rules, and is not understood wrongly by a non-extension-supporting > app, but the other breaks the rules, and therefore liable to be > interpreted wrongly by such an app. >=20 > And, finally, perhaps just _after_ the example now at the end of > this section, just a brief gloss along the lines of >=20 > The baseline location, given by the first ca:civicAddress element, > the first child of the gp:location-info, is a street address, to > the level of detail of the house number (123). The reference > location is [now the front door, something else if you fix the 5.1 > issue below]. The actual location, which is still within the > baseline building, is a point 100m east and 50m north [?] of the > front door. Oh. That's a bigger issue than you make out. Baseline !=3D reference. Imagine if locations were boxes. A baseline location is a big box. A refe= rence location is a small box inside the big box. A relative location is a= nother small box inside the big box. To people that don't know this refere= nce/relative stuff, they just see the big box. I think that Brian and I will have to sit down and make some edits. Your f= eedback will make that easier. > 4.11.1 >=20 > "An 'http:' or 'https:' URL MUST be used unless . . ." >=20 > Wouldn't it be more in the spirit of 2119 to say "A URI with scheme > other than 'http:' or 'https:' SHOULD NOT be used unless" ? "SHOULD" is a weasel-word that SHOULD be avoided. I like to reserve SHOULD= for cases where I am not providing a clear description of the exception ca= ses. Most times, MUST works perfectly well if properly qualified. As I be= lieve this is. > 5.1 Civic PIDF with Polygon Offset [also at end of section 3] >=20 > This example uses the ca:INT element, which as far as I can tell is > only defined in the expired draft-rosen-geopriv-pidf-interior [1]. Yes, that does need to go. We aren't pursuing that particular solution any= more. Those elements can just be eliminated. > 5.2 Geo PIDF with Circle Offset >=20 > Once the cut-and-paste error identified below in the 'Nits' section > is fixed, the result has 4 schema-validity errors, all of which I > presume should be straightforward to correct[[MT]] ... Brian, please fix these. > Nits: >=20 > 5.1, 5.2 [examples] >=20 > These examples rely on schema documents which require moderately > tedious indirection via the XML registry [2] to find -- it would be > helpful if the references section at least included the relevant > RFCs, at least 3863, 4479 and 5139. Please accept my apologies. These are all indirectly referenced, but we ca= n tighten that up. > 6. Schema Definition >=20 > The repeated pattern used for complex type definition in this schema > doc is[[MT]] ... > This is overly . . . complex and invites confusion, [[MT]] ... > Please simplify all your complex type definitions along these lines. I'm going to hold the line on this point. XML Schema defines two ways to d= o the same thing and this draft consistently uses the form that permits oth= er uses than complex type restrictions of the ur-type. I see no good reaso= n to switch to the syntactic sugar variant. From superuser@gmail.com Thu May 9 10:49: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 0730C21F92F4; Thu, 9 May 2013 10:49:31 -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 hy2m20QMsLXG; Thu, 9 May 2013 10:49:30 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC8121F9227; Thu, 9 May 2013 10:49:30 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id uo1so2150010pbc.20 for ; Thu, 09 May 2013 10:49:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=GDBBRtvHe+oq9E7pmvnQDYl6cPtveCVj9G6z1pW7Iko=; b=0otGXtMUPXVFmzW/URNKOYWhMYijBOdM4Oiq6i0TnXcRRcd/WTKLvUtrA4C9p21FKn NE4eQ2DZvzGZoiCHuwCDhVATrqmtqNPrJg2YJE+4X8btyKkYwhZiCSrzJN1q13JFJR/j 6IsgKr2wf938Js7KnTDQK/HGYKr5OGtFI0u0+92v0Tm/1zb6Z7mxeoorDOS+sY354xfo 6g/NAgWYPBjVyb0MEsTi1mtpB3s6QFx7gReEeOyVuwSv4F8Hps+0x/o/CbcDgWwRJFSa EZQQeDhjX3QCv/YtXYMLKJLQMnsStXeNjwXWQJMkRZcRQQ+7qTmADh2BviJRbwtDG8KE kPpA== MIME-Version: 1.0 X-Received: by 10.68.223.10 with SMTP id qq10mr13618503pbc.57.1368121769860; Thu, 09 May 2013 10:49:29 -0700 (PDT) Received: by 10.66.234.40 with HTTP; Thu, 9 May 2013 10:49:29 -0700 (PDT) In-Reply-To: References: <201305082158.r48LwkGe051483@medusa.blackops.org> Date: Thu, 9 May 2013 10:49:29 -0700 Message-ID: From: "Murray S. Kucherawy" To: Barry Leiba Content-Type: multipart/alternative; boundary=047d7b2e09df1a24d304dc4cacdd Cc: draft-ietf-6man-impatient-nud.all@tools.ietf.org, IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] AppsDir reivew of draft-ietf-6man-impatient-nud X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2013 17:49:31 -0000 --047d7b2e09df1a24d304dc4cacdd Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 9, 2013 at 1:40 AM, Barry Leiba wrote: > > Change "But in the UNREACHABLE state" to "However, in the UNREACHABLE > state," > > Why? What's wrong with it as it's written? > It's technically fine the way it is, but I find the way I suggested to be more palatable. It otherwise seems almost like a run-on sentence. > > Change "then it makes sense to stop" to "then implementations MAY > discontinue". > > Please, no. As it's written, it says that it's a good idea to stop > the retransmits. Changing it to "MAY" says that it's entirely > optional, losing the sense that this is a recommendation. There's no > need for 2119 language here, and "discontinue" isn't better than > "stop". I think this one is fine as written. > I find "it makes sense to do X" to be a little too colloquial. I realize we're not writing the Code of Federal Regulations here, but when the language is also overly informal, I find the effect to be that it's too mushy and provides little real guidance at all. At that point I wonder why it's there in the first place. A different option might be to do something like "then it is best to do X because..." or "then doing X is advisable because..." Could well be personal preference. > > In the last paragraph, please be more specific than "sooner or later". > > I agree, but to clarify why: > It might be reasonable to say "sooner or later", "eventually", or some > such if you weren't saying that it "MUST switch". If there's a reason > to switch that involves interoperability of the protocol (and there > seems to be, as you explain in the next sentence), then you ought to > be able to say something better than this. If I don't switch to > multicast until the very last NS I ever send, is that OK? > Right, that's also my point. In fact the language is so soft that I'm left wondering if I could get away with not doing it at all. Some better guidance about how to decide when to do it, or what the penalties are of doing it too soon or too late, would help to provide better guidance. > > In the second paragraph, please express the equation using a figure or > other > > illustration rather than making it part of the prose. > > Ooh... yes, this is really hard to read this way. > > > Third paragraph, add a comma after "transmissions". > > of course. Same in the following two paragraphs. > > Kind of a style issue here, really. I would probably put in the > comma, yes. More importantly, should the second sentence have this > change?: > OLD > After MAX_UNICAST_SOLICIT the implementation > NEW > After MAX_UNICAST_SOLICIT transmissions, the implementation > Again, technically correct without, but I think it's better with. Same deal (to me) as your "Please, no" objection above, but you went the other way on this one. > > > In paragraph four of Section 1, s/which/that/. > > You mean in, "For IPv4 there is no mandatory time limit on the > retransmission behavior for ARP [RFC0826] which allows implementors to > pick more robust schemes." ? No, that's the wrong fix (which is the > problem with which/that errors). I think the correct fix here is to > put a comma before "which" (the following clause is a consequence, not > a restriction). > I think those are equivalent fixes to the same problem, so fine with me. -MSK --047d7b2e09df1a24d304dc4cacdd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 9, 2013 at 1:40 AM, Barry Leiba <barryl= eiba@computer.org> wrote:
> Change "But in the UNREACHABLE sta= te" to "However, in the UNREACHABLE state,"

Why? =A0What's wrong with it as it's written?

It's technically fine the way it is, but I find th= e way I suggested to be more palatable.=A0 It otherwise seems almost like a= run-on sentence.
=A0
> Change "then it makes sense to stop" to &q= uot;then implementations MAY discontinue".

Please, no. =A0As it's written, it says that it's a good idea= to stop
the retransmits. =A0Changing it to "MAY" says that it's entir= ely
optional, losing the sense that this is a recommendation. =A0There's no=
need for 2119 language here, and "discontinue" isn't better t= han
"stop". =A0I think this one is fine as written.
<= div>
I find "it makes sense to do X" to be a little= too colloquial.=A0 I realize we're not writing the Code of Federal Reg= ulations here, but when the language is also overly informal, I find the ef= fect to be that it's too mushy and provides little real guidance at all= .=A0 At that point I wonder why it's there in the first place.

A different option might be to do something like=A0 "then it is be= st to do X because..." or "then doing X is advisable because...&q= uot;

Could well be personal preference.


> In the last paragraph, please be more specific than "sooner or la= ter".

I agree, but to clarify why:
It might be reasonable to say "sooner or later", "eventually= ", or some
such if you weren't saying that it "MUST switch". =A0If there= 's a reason
to switch that involves interoperability of the protocol (and there
seems to be, as you explain in the next sentence), then you ought to
be able to say something better than this. =A0If I don't switch to
multicast until the very last NS I ever send, is that OK?
<= div>
Right, that's also my point.=A0 In fact the language= is so soft that I'm left wondering if I could get away with not doing = it at all.=A0 Some better guidance about how to decide when to do it, or wh= at the penalties are of doing it too soon or too late, would help to provid= e better guidance.

=A0
> In the second paragraph, please express the equation= using a figure or other
> illustration rather than making it part of the prose.

Ooh... yes, this is really hard to read this way.

> Third paragraph, add a comma after "transmissions".
> of course. =A0Same in the following two paragraphs.

Kind of a style issue here, really. =A0I would probably put in the comma, yes. =A0More importantly, should the second sentence have this
change?:
OLD
After MAX_UNICAST_SOLICIT the implementation
NEW
After MAX_UNICAST_SOLICIT transmissions, the implementation

Again, technically correct without, but I think it'= ;s better with.=A0 Same deal (to me) as your "Please, no" objecti= on above, but you went the other way on this one.
=A0

> In paragraph four of Section 1, s/which/that/.

You mean in, "For IPv4 there is no mandatory time limit on the retransmission behavior for ARP [RFC0826] which allows implementors to
pick more robust schemes." ? =A0No, that's the wrong fix (which is= the
problem with which/that errors). =A0I think the correct fix here is to
put a comma before "which" (the following clause is a consequence= , not
a restriction).

I think those are equiv= alent fixes to the same problem, so fine with me.

-MSK
--047d7b2e09df1a24d304dc4cacdd-- From nick@jigsoft.co.za Thu May 9 10:51: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 142AB21F84D4 for ; Thu, 9 May 2013 10:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.437 X-Spam-Level: X-Spam-Status: No, score=0.437 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2Erf0Bgl4IH for ; Thu, 9 May 2013 10:51:19 -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 E290021F92FC for ; Thu, 9 May 2013 10:51:18 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id 6so3268667oba.32 for ; Thu, 09 May 2013 10:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jigsoft.co.za; s=google; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=Px5GBbyWPLYzPZ7yKgeyzn+j/NQxm9bgWsx1PDz8STU=; b=j4BUV1p9Nn4sOfbqRTm5vcobEwA6Vyouz/RReAWkMlhK0aFM1zt0dxpccbmY5dAHI9 lKdAeb1P+cST7h6lHR2OiG/lnU5ipzlUSsu2eB95KAnt4pRCvPaVBfncL/DeTjIXTy4A alZbte0vWXNDMNi+GxCtACm9TjvhEVZZQWCKo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :x-gm-message-state; bh=Px5GBbyWPLYzPZ7yKgeyzn+j/NQxm9bgWsx1PDz8STU=; b=HNyNtCj6VXsr+DsUl1rZv0ZCOkHvP9Rpg9zCehmCR7OueVKFa6VoUPF+6NiMcSwT52 Gi3Ni5mGOJpKtI/P78kACcpK+ws2707SskSXwcMqI24H9hCAQncvWuNire7bAOC5d/kk FMIrh7N2ZuzLslCku1+WkWkRt9Vvf89qugeZG16HghsiNFXqTUMP5ChPOECxPx4I/zOu 4YdiMBL6y2d5f4ZG52J82cq7/o1FZ0kzDoZjYDcosuvkX254jddatHHvGXyjva/FyUVu HDoJ81/DqpPmhBs/exAAV+p+TPRprkjfxklXUnygmO6SZhO6ZNeBF/HmtllUa3FijGVQ 5I6A== X-Received: by 10.182.32.34 with SMTP id f2mr4923577obi.86.1368121878387; Thu, 09 May 2013 10:51:18 -0700 (PDT) MIME-Version: 1.0 Sender: nick@jigsoft.co.za Received: by 10.182.233.102 with HTTP; Thu, 9 May 2013 10:50:58 -0700 (PDT) In-Reply-To: References: From: Nick Lombard Date: Thu, 9 May 2013 19:50:58 +0200 X-Google-Sender-Auth: CNoui3dhx6Dapk7qolJVY5kgWnk Message-ID: To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=089e013a079492311804dc4cb231 X-Gm-Message-State: ALoCoQmOnk8+XhdnjAP+KVcYwpizWH67fsr50mL5zrbKfO0cfYU6c4eRskrmKhUW73y1ss4+BiDd Subject: Re: [apps-discuss] draft-nottingham-json-home-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: Thu, 09 May 2013 17:51:22 -0000 --089e013a079492311804dc4cb231 Content-Type: text/plain; charset=ISO-8859-1 Hi On 30 April 2013 02:59, Mark Nottingham wrote: > > Oh, it's still active, just a slow burner. Once we get HTTP/1.1 to bed, > i'll be spending some more time on it. > @Mark I can help dust off the cob-webs and keep it simmering on track for you while you are otherwise occupied, if that would help. Besides lining things up with Erik Wilde's XML clone is there anything anyone would like to add at this point? If memory serves I created a project on GitHub at some point for an open source reference implementation, although I can't find it now but that is easily rectified. I know there were requests previously made for this on list. Is it still something of interest, is there anything specific which you would like to see implemented? @Ted M. Young perhaps you have something you can contribute already, would you like to be involved? If anyone else has some spare time to squeeze off with an interest to see a reference implementation materialise, lets hear from you too. Many hands makes lighter load. nickl --089e013a079492311804dc4cb231 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi

On 30 April 2013 02:59, Mark Nottingham <mnot@mnot.net> wr= ote:

Oh, it's still active, just a slow burner. Once we get HTTP/1.1 t= o bed, i'll be spending some more time on it.

=
@Mark I can help dust off the cob-webs and keep it simmeri= ng on track for you while you are otherwise occupied, if that would help.

Besides lining things up with Erik Wilde= 9;s XML clone is there anything anyone would like to add at this point?

If memory serves I created a project on GitHub = at some point for an open source reference implementation, although I can&#= 39;t find it now but that is easily rectified. I know there were requests p= reviously made for this on list. Is it still something of interest, is ther= e anything specific which you would like to see implemented? @Ted M. Young = perhaps you have something you can contribute already, would you like to be= involved? If anyone else has some spare time to squeeze off with an intere= st to see a reference implementation materialise, lets hear from you too.

Many hands makes lighter load.

nickl=A0
--089e013a079492311804dc4cb231-- From jan.algermissen@nordsc.com Thu May 9 11:10: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 69D1F21F8503 for ; Thu, 9 May 2013 11:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 VlwVRSfbtOjt for ; Thu, 9 May 2013 11:10:46 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 5C05121F90F1 for ; Thu, 9 May 2013 11:10:42 -0700 (PDT) Received: from [192.168.2.102] (p548FAE83.dip0.t-ipconnect.de [84.143.174.131]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0Lsupa-1UOihm2dI2-012cCt; Thu, 09 May 2013 20:10:40 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jan Algermissen In-Reply-To: Date: Thu, 9 May 2013 20:10:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Nick Lombard X-Mailer: Apple Mail (2.1499) X-Provags-ID: V02:K0:Yn7Zf+g8/Ov5hYhhLnYx6XucJVUtb8w2O2lYc64DldR r4WpUKTjdHXn7vdT8YKF2ngj/M1GDAMsSRmIhs/a1fjp011H4S T0WgScQjC8YZ7ZpuSYNMlSjR7KYQwMbhG492/8IWVM4Z20nZX9 dhWhDa+qHZ7H1kSxH+1Lk14lKyOa1n0ul21OipaGrY8hQhxvwz 6y3omNN27ldU7Y5bkhVqNTYtXIuKDfhozenkT4QkstTW7mN9EE +d+mOGJDk3hxyjM60mPi2LIKm+12uC6yhpVu4/EO0/CbG6kh26 5p4enT79pzdQGb+KrrjdZYlf8woLJonKlnzGD1fZKaMDICpLDf MGK7KFfwC2sF1aza0Wtft5lfrRBtrgjph11y7LfLdMhLI08Kw8 AbigDGcd87gXg== Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-nottingham-json-home-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: Thu, 09 May 2013 18:10:51 -0000 On 09.05.2013, at 19:50, Nick Lombard wrote: > Hi >=20 > On 30 April 2013 02:59, Mark Nottingham wrote: >=20 > Oh, it's still active, just a slow burner. Once we get HTTP/1.1 to = bed, i'll be spending some more time on it. >=20 > @Mark I can help dust off the cob-webs and keep it simmering on track = for you while you are otherwise occupied, if that would help. >=20 > Besides lining things up with Erik Wilde's XML clone is there anything = anyone would like to add at this point? This is still on my list, because if not addressed it IMHO leads to a = need for specifying unnecessary link relation types: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09238.html Note to implementors: it is something that would be an incompatible = change to the format. Jan >=20 > If memory serves I created a project on GitHub at some point for an = open source reference implementation, although I can't find it now but = that is easily rectified. I know there were requests previously made for = this on list. Is it still something of interest, is there anything = specific which you would like to see implemented? @Ted M. Young perhaps = you have something you can contribute already, would you like to be = involved? If anyone else has some spare time to squeeze off with an = interest to see a reference implementation materialise, lets hear from = you too. >=20 > Many hands makes lighter load. >=20 > nickl=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From sm@elandsys.com Thu May 9 12:49: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 9ED5421F9227 for ; Thu, 9 May 2013 12:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.296 X-Spam-Level: X-Spam-Status: No, score=-102.296 tagged_above=-999 required=5 tests=[AWL=0.303, 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 ceJvm+Ky9Dbs for ; Thu, 9 May 2013 12:49:33 -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 5B21521F9164 for ; Thu, 9 May 2013 12:49:33 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.45]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r49JnDTE005439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 May 2013 12:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1368128965; bh=70k6ju/AUNO+UjpsChUBmjL9hu0Ocex9JpeBlJFMEwg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=4HFVWxrRn5rU2FGU11MUjAnRW5T9bNOnXb5LYJGqHwGHCftHAfRLQ4ZQM3s8EQrKZ 8FvpYcEX3nzElMtVAD72gXx7RYFs8fBquSQvcZ1ItjDP9tXzx8FqvwpC/0q1sWkDAj 2umbyBVANlsw04CTArwVvqWRs2Md7yrNvOVPh3LU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1368128965; i=@elandsys.com; bh=70k6ju/AUNO+UjpsChUBmjL9hu0Ocex9JpeBlJFMEwg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ixSxpv3xfSlT/v7wqZSu1OuPTOhskyoI2eY6X30toYMpojpgF6PjPsAWyPm3kyDQw MoxFmw8ohFjTaSGq8/TNRhO1jgxjUQDwVCCJsaPvUrPJaY70ghxRvvWuRPlbhqyvGh aphCvJWHosHE5PPlnCEmMN51fAxkKHfB9c6hGZ+M= Message-Id: <6.2.5.6.2.20130509113822.0c4a7848@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 09 May 2013 11:44:58 -0700 To: ht@inf.ed.ac.uk (Henry S. Thompson) From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20130507122937.075fb058@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Apps Area Directorate report for April 2013 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2013 19:49:34 -0000 Hi Henry, I missed the following review in the directorate report for April: Henry S. Thompson draft-ietf-geopriv-relative-location-04 I apologize for the mistake. Regards, S. Moonesamy From nick@jigsoft.co.za Thu May 9 13:00: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 7C6A521F86B2 for ; Thu, 9 May 2013 13:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.27 X-Spam-Level: X-Spam-Status: No, score=-1.27 tagged_above=-999 required=5 tests=[AWL=1.706, 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 W8FunkD4xEVR for ; Thu, 9 May 2013 13:00:07 -0700 (PDT) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2392821F86BB for ; Thu, 9 May 2013 13:00:07 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id k14so2378701oag.8 for ; Thu, 09 May 2013 13:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jigsoft.co.za; s=google; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Lb3zddRK08jvvr+RE+9nC0/D3FJjMEx0m7TGYySqzxk=; b=HB4cTZQEh6PGCQUo0NM8rETNkifMbj9wT+QJBWiS5Vqvnvkw+v+9wcxllrPZkSwKmf nSbltX9wSOyA49z6WmjI957foDiET/sA3yK7W73zIUQhvVeNAytioyfqGmfSOEgpBJLW 5zgY+erS+18Bo01VXIWsW7KhGgCnUq+OQkHOQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received: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=Lb3zddRK08jvvr+RE+9nC0/D3FJjMEx0m7TGYySqzxk=; b=K6GIec0sE9v1YcuriwHlHz/h6S4kl6YA4HwCHCmuDDvOpGDfsfiZThDoAhwYBgAelP s5jJPGU1ByB4ppVlon+RCvEQKhcLINlZzO+7ln4BFI0SDIyj1evLcBUT76YtIiJ71SMU 9pi36VvoILXvvFzwdrJNTYDMYyypkDjyhMXwvbF/ooc9Ke6nEVxsRc0Q1YQGUK6ei3xJ fGiFWA2p2R1wIuM7upGEXvHg7t+wtE8QYtAioPe6q00/d4jKMJOBRSTdNQINEovbUyEw cIMwF8SKmi4aO/UdjV4frCP1efpmhxw4U+/5P2Yo/5Mh9O1qmxXakVQpTdRPnnUKJb0B QOTg== X-Received: by 10.60.131.143 with SMTP id om15mr5302577oeb.45.1368129606656; Thu, 09 May 2013 13:00:06 -0700 (PDT) MIME-Version: 1.0 Sender: nick@jigsoft.co.za Received: by 10.182.233.102 with HTTP; Thu, 9 May 2013 12:59:46 -0700 (PDT) In-Reply-To: References: From: Nick Lombard Date: Thu, 9 May 2013 21:59:46 +0200 X-Google-Sender-Auth: kl4QaVYw-ZEMb4YEwwDOjDrAyMQ Message-ID: To: craigmcc@gmail.com Content-Type: multipart/alternative; boundary=047d7b4179b3368c2f04dc4e7f33 X-Gm-Message-State: ALoCoQnPmW++bS57RcCeoMbp1YE+XRfdtflkUQrOaMN0YUA/RgtaKDVFmQUvrL5dzwe9zxBMZCo1 Cc: REST-Discuss Discussion Group , IETF Apps Discuss , hal-discuss@googlegroups.com, "hypermedia@librelist.com" , "api-craft@googlegroups.com" , hypermedia-web@googlegroups.com Subject: Re: [apps-discuss] [rest-discuss] Re: New Internet-Draft: JSON Hypertext Application Language X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 May 2013 20:00:18 -0000 --047d7b4179b3368c2f04dc4e7f33 Content-Type: text/plain; charset=ISO-8859-1 Hi Craig Excuse me piping in here so late after the fact but this is something I come across often. On 13 February 2013 23:42, Craig McClanahan wrote: > On the topic of in band versus out of band, the latter would probably be > more "pure" -- but in band is much easier for client developers to deal > with. Why do we perceive it easier to design and implement a custom wheel instead of the one you already use? > They have to access the JSON or XML or whatever content of the response > body anyway. Requiring them to deal with HTTP headers or whatever as well > is extra work. > > Without a HTTP Request header you cannot request content from a HTTP server. If successful you will receive a HTTP response header which may define a body portion. Dealing with HTTP headers is not optional. At some point you'd expect the realisation to sink in, suggesting we use anything else is unnecessary extra work... but it doesn't. nickl --047d7b4179b3368c2f04dc4e7f33 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Craig

Excuse me piping in here so late after the fact but this = is something I come across often.

On 13 February 2013 23:42, Craig McClanahan <craigmcc@gmail.com>= wrote:
=A0
On the topic of in band versus out of band= , the latter would probably be more "pure" -- but in band is much= easier for client developers to deal with.

Why do we perceive it easier to design and implement a = custom wheel instead of the one you already use?
=A0
=A0They have to access the JSON or XML or whatever content of the response = body anyway. =A0Requiring them to deal with HTTP headers or whatever as wel= l is extra work.

Without a HTTP Request header you cannot request content from a HTTP server= .=A0
If=A0successful=A0you will receive a HTTP response hea= der which may define a body=A0portion.

Dealing with HTTP headers is not optional.

At some point you'd expect the realisat= ion to sink in, suggesting we use anything else is unnecessary extra work..= . but it doesn't.

nickl

--047d7b4179b3368c2f04dc4e7f33-- From tedyoung@gmail.com Thu May 9 13:55:43 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAD121F905F for ; Thu, 9 May 2013 13:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 ryZMOvk1KNN2 for ; Thu, 9 May 2013 13:55:38 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id DC0AD21F905C for ; Thu, 9 May 2013 13:55:37 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id v1so3479761lbd.25 for ; Thu, 09 May 2013 13:55:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=On5aDORJdqCFcQ/bDE3/8520cwJm3hQD9/CsDLl2QPs=; b=vn6zAP+mMVqc7OSE4Mx3GTnZ0JVrVheKQnFN5BCVyA8E5KnAFG+xk3zaKubBgb3oVy AlEClQ/pdx0wH1d9QQnWFVUmzFkhQi5FkKW6+00D9JUq36Sf/vTsBK0Lro1lNeup/65H aj07I53KCdZ8rRcPBakWYj0meZqNR2sQSDxYu9cyXy5F95UNjR4VwCpPNR26yRVwof6m jmQIJsH9AUaGJOU3cObBOvghYG8sC4paoIZ+sA/VPnj7gZyys61fOEj3za4aOEAcHVfV hEK5dUVDQ6pnqGVpk6iTmKzcm4uRoUHmXNPN9DPH8M/7/BqJnewy3gNYbcQEw4C1IyrT Z4wQ== MIME-Version: 1.0 X-Received: by 10.112.135.70 with SMTP id pq6mr6297582lbb.82.1368132936774; Thu, 09 May 2013 13:55:36 -0700 (PDT) Received: by 10.114.175.202 with HTTP; Thu, 9 May 2013 13:55:36 -0700 (PDT) In-Reply-To: References: Date: Thu, 9 May 2013 13:55:36 -0700 Message-ID: From: "Ted M. Young [@jitterted]" To: Nick Lombard Content-Type: multipart/alternative; boundary=089e01229310b3bb3204dc4f45ca Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-nottingham-json-home-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: Thu, 09 May 2013 20:55:43 -0000 --089e01229310b3bb3204dc4f45ca Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 9, 2013 at 10:50 AM, Nick Lombard wrote: > If memory serves I created a project on GitHub at some point for an open > source reference implementation, although I can't find it now but that is > easily rectified. I know there were requests previously made for this on > list. Is it still something of interest, is there anything specific which > you would like to see implemented? @Ted M. Young perhaps you have something > you can contribute already, would you like to be involved? > I don't have much of anything yet, but I did come across this just the other day: https://github.com/otto-de/jsonhome, which looks like a pretty complete implementation. I'm trying to figure out if I can make use of it outside Spring MVC (and if not, whether it's close enough to my needs to fork). ;ted > If anyone else has some spare time to squeeze off with an interest to see > a reference implementation materialise, lets hear from you too. > > Many hands makes lighter load. > > nickl > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --089e01229310b3bb3204dc4f45ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Thu, May 9, 2013 at 10:50 AM, Nick Lombard <ietf@jigsoft.co.za>= wrote:
If memor= y serves I created a project on GitHub at some point for an open source ref= erence implementation, although I can't find it now but that is easily = rectified. I know there were requests previously made for this on list. Is = it still something of interest, is there anything specific which you would = like to see implemented? @Ted M. Young perhaps you have something you can c= ontribute already, would you like to be involved?

I don't have much of anything yet, but= I did come across this just the other day: https://github.com/otto-de/jsonhome, which looks like = a pretty complete implementation. I'm trying to figure out if I can mak= e use of it outside Spring MVC (and if not, whether it's close enough t= o my needs to fork).

;ted
=A0
If anyone else has some spare time= to squeeze off with an interest to see a reference implementation material= ise, lets hear from you too.

Many hands makes lighter load.

nickl=A0

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


--089e01229310b3bb3204dc4f45ca-- From superuser@gmail.com Fri May 10 09:59: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 077EB21F8E5B for ; Fri, 10 May 2013 09:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 xpw2e8EVVu1F for ; Fri, 10 May 2013 09:59: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 265FE21F8B64 for ; Fri, 10 May 2013 09:59:03 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id q55so4091318wes.26 for ; Fri, 10 May 2013 09:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6biA4j0dDkBSUlk4rDNC9bBPMk/p2JSOCi/DVpaNZv0=; b=dPB2uA/un5F5QhbwrmFKLemq4MNgSJLSrbZVlCNRx349Q7noLtq6qiUlmTbDl7aofF oWWpCkFf7Pnya4RZ474DlYshL6eCZ5zuEw6EuxwsvIuR6E/AMLG5I8vN8YuLtKQyO/+E nqhPnm4oUFCOkTqhZCQTkLBSBZPEC6TV2n31SHOsFOZSLh+aIkt7ZHO9EG75N9dLnCv5 RMultYNypPG/MUJXUBBZ9TCfivOmezokX6d/BDI0Lm/sYsxQJIZhOa78S8AMW0xS24Gz 6D37gOmYg+r3Ptkpp8BjGl6CbCvPCh9GrG6+SY8Zl5ti4snhNHX6fli44KS/WBKGV5/E Ovbg== MIME-Version: 1.0 X-Received: by 10.194.179.169 with SMTP id dh9mr19734412wjc.15.1368205143327; Fri, 10 May 2013 09:59:03 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Fri, 10 May 2013 09:59:03 -0700 (PDT) In-Reply-To: <518A1C4D.3050506@tana.it> References: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> <5187DA74.9020204@tana.it> <518920D0.1040705@tana.it> <518A1C4D.3050506@tana.it> Date: Fri, 10 May 2013 09:59:03 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=089e01419f4a8c4c5e04dc60159b Cc: IETF Apps Discuss Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-01 (was -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, 10 May 2013 16:59:05 -0000 --089e01419f4a8c4c5e04dc60159b Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 8, 2013 at 2:35 AM, Alessandro Vesely wrote: > A couple of nits: > > s/contect/context/, and in the sentence: > > For example, [SPF] can base its inclusion on the RFC5321.Helo > parameter or on the RFC5322.From domain; including both of those > in the header field makes it impossible for the consumer to > determine which mode of SPF was applied > > s/inclusion/conclusion/, and s/RFC5322.From/RFC5321.MailFrom/. Maybe > "which parameter was actually used" is clearer than "which mode of SPF > was applied", since SPF lacks a definition of "mode". > Fixed, fixed, and fixed. > > > "The description of the Message Authentication Status header field > > [RFC5451], specifies that <...etc...>" > > Would it make sense to change the title into: > > *The Authentication-Results Header Field* > > I don't think that's necessary. -MSK --089e01419f4a8c4c5e04dc60159b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 8, 2013 at 2:35 AM, Alessandro Vesely <vesely@ta= na.it> wrote:
A couple of nits:

s/contect/context/, and in the sentence:

=A0 =A0For example, [SPF] can base its inclusion on the RFC5321.Helo
=A0 =A0parameter or on the RFC5322.From domain; including both of those
=A0 =A0in the header field makes it impossible for the consumer to
=A0 =A0determine which mode of SPF was applied

s/inclusion/conclusion/, and s/RFC5322.From/RFC5321.MailFrom/. =A0Maybe
"which parameter was actually used" is clearer than "which m= ode of SPF
was applied", since SPF lacks a definition of "mode".

Fixed, fixed, and fixed.
=A0

> "The description of the Message Authentication Status header fiel= d
> [RFC5451], specifies that <...etc...>"

Would it make sense to change the title into:

=A0 =A0*The Authentication-Results Header Field*

<= br>I don't think that's necessary.

-MSK

--089e01419f4a8c4c5e04dc60159b-- From internet-drafts@ietf.org Sun May 12 21:54: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 9C29B21F8EBC; Sun, 12 May 2013 21:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.001 X-Spam-Level: X-Spam-Status: No, score=-100.001 tagged_above=-999 required=5 tests=[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 GM9b9dyacpeP; Sun, 12 May 2013 21:54:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A169621F8EAE; Sun, 12 May 2013 21:53:42 -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.44.p7 Message-ID: <20130513045342.14228.40090.idtracker@ietfa.amsl.com> Date: Sun, 12 May 2013 21:53:42 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-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: Mon, 13 May 2013 04:54:06 -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 : Message Header Field for Indicating Message Authenticati= on Status Author(s) : Murray S. Kucherawy Filename : draft-ietf-appsawg-rfc5451bis-02.txt Pages : 42 Date : 2013-05-12 Abstract: This document specifies a header field for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users, or make sorting and filtering decisions. This document is a candidate for Internet Standard status. [RFC Editor: Please delete this notation, as I imagine it will be indicated some other way.] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-rfc5451bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-rfc5451bis-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From duerst@it.aoyama.ac.jp Sun May 12 22:28: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 C523521F8F4F; Sun, 12 May 2013 22:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.191 X-Spam-Level: X-Spam-Status: No, score=-101.191 tagged_above=-999 required=5 tests=[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 iOB+4KAE+3Fp; Sun, 12 May 2013 22:28:05 -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 0499221F8ECA; Sun, 12 May 2013 22:28:04 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r4D5S1kJ005009; Mon, 13 May 2013 14:28:01 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 5122_e40b_e0dc23ec_bb8d_11e2_9b92_001e6722eec2; Mon, 13 May 2013 14:28:00 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 01A28BF4BA; Mon, 13 May 2013 14:27:18 +0900 (JST) Message-ID: <519079D5.8080708@it.aoyama.ac.jp> Date: Mon, 13 May 2013 14:27:49 +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: Robert Sparks References: <5180E1D9.7010006@it.aoyama.ac.jp> <51818841.40601@nostrum.com> In-Reply-To: <51818841.40601@nostrum.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: draft-sparks-genarea-imaparch.all@tools.ietf.org, IESG , Apps Area WG Subject: Re: [apps-discuss] Apps Area review of draft-sparks-genarea-imaparch-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: Mon, 13 May 2013 05:28:10 -0000 Hello Robert, I have looked at your update, i.e. draft-sparks-genarea-imaparch-07. It=20 seems that all my concerns have been addressed, thanks very much. Thanks also for adding me to the acks section. However, please there=20 change my name from "Martin Durst" to "Martin Duerst". That's how it's=20 spelled if the "=C3=BC" character isn't available (which fortunately is l= ess=20 and less the case). Regards, Martin. On 2013/05/02 6:25, Robert Sparks wrote: > On 5/1/13 4:35 AM, "Martin J. D=C3=BCrst" 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/ApplicationsAreaDirector= ate >> ). >> >> 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-sparks-genarea-imaparch-06 >> Title: IMAP Access to IETF Email List Archives >> Reviewer: Martin D=C3=BCrst >> Review Date: 2013/05/01 >> >> >> Summary: There is one main issue that's unclear to me. Otherwise, the >> draft is close to publication, but needs some additional work. >> >> Note: I'm not an IMAP expert, not even an IMAP user, and not somebody >> the Apps Area would call an email expert, although I wrote RFC 5064 >> and quite a bit of RFC 6068. So the comments here are mostly of >> general nature. >> >> Main issue: It is totally unclear to me what the actual consequences >> of this draft are if approved. > > It will be used as input to the development of a tool providing the > capabilities described here. > > We are capturing input from the IETF participants on what that tool > needs to do. > > We've followed this approach with several other documents > - RFC6778 (the web-based email archive) > - RFC6730 (for nomcom tools) > - RFC6433 (milestones) > - RFC6292 (charters) > > The document already says > "This memo captures the > requirements for providing a service that would allow such browsing > and searching." > > Would it help to add "and it is intended as input to a later activity > for the design and development of such a tool." and would that address > your concern? Or is it fine as it was after seeing that other context? > > Whether this results in an IAOC funded project or is satisfied with > volunteer effort is not something this document needs to discuss. > > >> I could imagine any one of the following: >> >> - It's informational, so it doesn't have any standing, and is just a >> wishlist, mostly just by the author. >> - If and when it will be IESG-approved, it documents IETF consensus >> on how to best implement IMAP-based access to mailing list archives >> for the IETF should such access be desirable, but it does not >> represent an IETF consensus to actually implement this (e.g. because >> that needs money, and money doesn't move by IETF consensus). >> - If and when it will be IESG-approved, it documents IETF consensus th= at >> IMAP-based access to IETF mailing lists is desirable, and should be >> implemented asap (assuming somebody can come up with the necessary >> resources). >> - An informal mixture of the above: Those in the know agree it's a goo= d >> idea, but somebody said they need a document that can be referenced in >> an RFP. >> >> While I'm personally okay with any of the above (I won't use this kind >> of access in the near future, but can understand that many people are >> using IMAP and it would be pretty handy to have such a feature; also I >> won't have to pay for it), I think the fact that this unclarity exists >> may make it difficult for others to review the draft. >> >> So I suggest that this be clarified. Unless it's just me who's unclear >> on this issue, it may get close to meriting a new or prolonged last ca= ll. > That will be for Jari to judge, but as I point out above, we've followe= d > this pattern, using the language in this draft before. >> >> >> Minor issue: The draft should reference RFC 6855 (IMAP Support for >> UTF-8) and require its support *at least* to the extent that RFC 6778 >> does (see http://tools.ietf.org/html/rfc6778#section-3). > I will work to sew in a reference to 6855 >> >> >> Editorial/Nits: >> >> o The interface must allow administrators to disable setting read/ >> unread marks and other annotations, and delete any such marks or >> annotations on a per user basis. >> >> It's unclear how far back "on a per user basis" applies. >> Also, "the interface" means "an IMAP interface" (first bullet point), >> but it may not be possible or practical to have administrators use >> IMAP itself for this function. So I suggest something along the >> following lines: >> >> o It must be possible for administrators, on a per-user basis, to >> disable setting read/unread marks and other annotations and to >> delete any such marks or annotations. > I'll fold this suggestion in. >> >> >> "and should support multiple simultaneous extensive searches.": Is >> this simultaneous searches by the same user, or by different users? I >> suspect the later. If so, the clause should be rewritten so that it is >> clear that this is a dimensioning requirement, not a functionality >> requirement. > I think it's _both_, not one or the other. I will attempt to clarify. >> >> "The server should facilitate the enhanced search capabilities >> described in [RFC6778].": It is unclear what "facilitate" means here. >> Technology usually implements something or doesn't; facilitate sounds >> quite fuzzy. Although RFC 6778 is informational, it uses quite a bit >> of 'must',... On the other hand, IMAP may or may not support some of >> the queries listed as a 'must' in RFC 6778. > Would "provide" work better for you than "facilitate"? >> >> >> "(But it is acceptable for a user to access such archives while >> providing credentials).": Don't start a sentence with 'But' (use >> 'However'). Also, please put the final period inside the parentheses. > I will remove the But, and leave ). vs .) to the RFC Editor. >> >> "an LOGIN command" -> "a LOGIN command" > Thanks - will fix. >> >> "determined by the administrator ." -> "determined by the administrato= r." >> >> "local copies all messages" -> "local copies of all messages" >> >> "maliciously crafted searches attempting to consume all available >> resources" -> "maliciously crafted searches attempting to consume >> significant available resources" (there is no need to consume all >> resources to result in significant DOS problems) >> >> " maliciously crafted annontations attempting to consume all storage >> space" -> " maliciously crafted annontations attempting to consume >> significant storage space" > Will fix all those. >> >> "The implementers should consider making it easy for the administrator >> to determine which users are consuming exceptional space.": >> "exceptional space" -> "exceptional amounts of space"; I also think >> "should consider" is rather too weak, and "easy to determine" seems to >> imply that administrators will have to actively check this (rather >> than getting alerts when something fishy starts). > The language is intended to leave latitude for design. Forcing > administrators to poll would not satisfy "making it easy". > I will try to make that clearer. > >> This may be just an implementation detail, but it may be a good idea >> to note that flag implementation (and annotation implementation if an >> annotation can be applied by the user to more than one message at >> once) has to be quite clever because otherwise, even benign use might >> use up lots of space. As an example, if the system allocates 4 bytes >> for each message in the system for each user that logs into the system >> even once, that may already create huge storage demands. > I will look at calling this out. However, there are many bad things tha= t > an implementation _could_ do, and calling them all out is not needed > here. Things like this would get caught at design review or as source > comes in. (You can get the source for the running datatracker - see the > codesprint pages if you don't already know how). Such bad design will b= e > caught. Good designs are often improved at codesprints. >> >> Regards, Martin. >> >> >> > > From sayrer@gmail.com Sun May 12 22:50: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 08A7A21F8FB3 for ; Sun, 12 May 2013 22:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 Gk7y36RWPBP7 for ; Sun, 12 May 2013 22:50:56 -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 6570C21F8FA9 for ; Sun, 12 May 2013 22:50:54 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hq7so771019wib.12 for ; Sun, 12 May 2013 22:50:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=5fxOnPS9SF5WON7wCnRmGs2zvCh+9hbym3NrlCrijSI=; b=ufBAZrY3af6PDQU4XlpR55XTsTIQwWbjxOaQMfnsbWEbKJurpn2xhfIPLo53sbeHDb apvi8K3K2tQbdtB8IF4HdoNKcmbprqRbU9RQ6QGhaBqwnnl+STs+7yvJv6BcrVEKleTj xq342QuIBhTQ/Lrks9IMTpCQucbjS/9RFsj1iHn6E+6swo32NaX3ahGsbiCij/AV55tT osd2vdMnEkLRjKEfua1WcakqxFmGzrB+hh3bNy8m5/sdhwpHfXIiqqFDx93asuiqDai8 CbDUL3reULjGomhTV8OcYMX0g9lr59IwRpwWjvmWxuLl9NqfWdgS5nBJwtM4eaJpP5KM d00w== MIME-Version: 1.0 X-Received: by 10.180.74.172 with SMTP id u12mr16329311wiv.0.1368424253876; Sun, 12 May 2013 22:50:53 -0700 (PDT) Received: by 10.194.32.4 with HTTP; Sun, 12 May 2013 22:50:53 -0700 (PDT) In-Reply-To: References: Date: Sun, 12 May 2013 22:50:53 -0700 Message-ID: From: R S To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=f46d043890018df0ea04dc93199e Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for Adoption: draft-snell-merge-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 05:50:57 -0000 --f46d043890018df0ea04dc93199e Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 3, 2013 at 2:10 PM, Murray S. Kucherawy wrote: > we'll adopt this as a working group item within the next couple of weeks > unless there's objection to such processing. > Object absent explicit support from WG members. If that support is stated, then no objection. - Rob --f46d043890018df0ea04dc93199e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, May 3, 2013 at 2:10 PM, Murray S. Kucherawy <su= peruser@gmail.com> wrote:
=A0we'll adopt thi= s as a working group=20 item within the next couple of weeks unless there's objection to such= =20 processing.


Object absent explicit support from WG members. If that support is = stated, then no objection.

- Rob=A0
--f46d043890018df0ea04dc93199e-- From James.H.Manger@team.telstra.com Sun May 12 23:02: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 217E821F901F for ; Sun, 12 May 2013 23:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.699 X-Spam-Level: * X-Spam-Status: No, score=1.699 tagged_above=-999 required=5 tests=[HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tM1dpJfasw4Q for ; Sun, 12 May 2013 23:02:54 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 7B76C21F8F62 for ; Sun, 12 May 2013 23:02:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,659,1363093200"; d="scan'208,217";a="135236552" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 13 May 2013 16:02:51 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7073"; a="131536533" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipcdvi.tcif.telstra.com.au with ESMTP; 13 May 2013 16:02:51 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Mon, 13 May 2013 16:02:51 +1000 From: "Manger, James H" To: "Murray S. Kucherawy" , IETF Apps Discuss Date: Mon, 13 May 2013 16:02:50 +1000 Thread-Topic: [apps-discuss] Call for Adoption: draft-snell-merge-patch Thread-Index: Ac5IQpt7f4EPA5rbQ5yqijvm054g7wHW7gcQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1150D5F89CC@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1150D5F89CCWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [apps-discuss] Call for Adoption: draft-snell-merge-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 06:02:59 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1150D5F89CCWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IHByb2dyZXNzaW5nIGRyYWZ0LXNuZWxsLW1lcmdlLXBhdGNoLg0KVGhlIGFsbW9z dC1lc3RhYmxpc2hlZCBKU09OIHdvcmtpbmcgZ3JvdXA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvY2hhcnRlci1pZXRmLWpzb24vPiB3b3VsZCBiZSBhbiBldmVuIGJldHRlciB2ZW51 ZSB0aGFuIGhlcmUgKGFwcHMtZGlzY3VzcykgZm9yIHRoaXMgZHJhZnQg4oCUIG9yIGF0IGxlYXN0 IGl0IHdvdWxkIGhhdmUgYmVlbiBpZiB0aGUgY2hhcnRlciBmb3IgdGhlIEpTT04gV0cgZGlkbuKA mXQgYWRkIHByb2Nlc3MgaW1wZWRpbWVudHMgKOKAnG9ubHkgYWZ0ZXIgaW5pdGlhbCB3b3JrIGlz IGRvbmXigJ0sIOKAnG11c3QgcmVjaGFydGVy4oCdKS4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQpG cm9tOiBhcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmFwcHMtZGlzY3Vzcy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTXVycmF5IFMuIEt1Y2hlcmF3eQ0KU2VudDog U2F0dXJkYXksIDQgTWF5IDIwMTMgNzoxMCBBTQ0KVG86IElFVEYgQXBwcyBEaXNjdXNzDQpTdWJq ZWN0OiBbYXBwcy1kaXNjdXNzXSBDYWxsIGZvciBBZG9wdGlvbjogZHJhZnQtc25lbGwtbWVyZ2Ut cGF0Y2gNCg0KVGhpcyBpcyBhIGNhbGwgZm9yIGFkb3B0aW9uIGZvciBkcmFmdC1zbmVsbC1tZXJn ZS1wYXRjaC4gIFRoZSBkb2N1bWVudCBoYWQgYSB0aHJlYWQgb2YgZGlzY3Vzc2lvbiBpbiBKYW51 YXJ5LCBhbmQgc29tZSBwcmlvciwgdGhhdCBzaG93ZWQgc29tZSBpbnRlcmVzdCB3aXRoaW4gdGhp cyB3b3JraW5nIGdyb3VwLCBhbmQgaXQgYXBwZWFycyB0byBiZSBtYXRlcmlhbCB0aGF0IGZhbGxz IHdpdGhpbiBvdXIgY2hhcnRlci4gIEFjY29yZGluZ2x5LCB3ZSdsbCBhZG9wdCB0aGlzIGFzIGEg d29ya2luZyBncm91cCBpdGVtIHdpdGhpbiB0aGUgbmV4dCBjb3VwbGUgb2Ygd2Vla3MgdW5sZXNz IHRoZXJlJ3Mgb2JqZWN0aW9uIHRvIHN1Y2ggcHJvY2Vzc2luZy4gIEkgd2lsbCBhY3QgYXMgZG9j dW1lbnQgc2hlcGhlcmQuDQotTVNLLCBBUFBTQVdHIGNvLWNoYWlyDQo= --_000_255B9BB34FB7D647A506DC292726F6E1150D5F89CCWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1F Ti1BVSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgc3VwcG9ydCBwcm9ncmVzc2lu ZyBkcmFmdC1zbmVsbC1tZXJnZS1wYXRjaC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlIGFsbW9zdC1lc3RhYmxpc2hlZCA8 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9jaGFydGVyLWlldGYtanNv bi8iPkpTT04gd29ya2luZyBncm91cDwvYT4gd291bGQgYmUgYW4gZXZlbiBiZXR0ZXIgdmVudWUg dGhhbiBoZXJlIChhcHBzLWRpc2N1c3MpIGZvciB0aGlzIGRyYWZ0IOKAlCBvciBhdCBsZWFzdCBp dCB3b3VsZCBoYXZlIGJlZW4gaWYgdGhlIGNoYXJ0ZXIgZm9yIHRoZSBKU09OIFdHIGRpZG7igJl0 IGFkZCBwcm9jZXNzIGltcGVkaW1lbnRzICjigJxvbmx5IGFmdGVyIGluaXRpYWwgd29yayBpcyBk b25l4oCdLCDigJxtdXN0IHJlY2hhcnRlcuKAnSkuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4tLTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5 bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20g MGNtIDBjbSA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNv Tm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiInPiBhcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmFwcHMtZGlzY3Vz cy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPk11cnJheSBTLiBLdWNoZXJh d3k8YnI+PGI+U2VudDo8L2I+IFNhdHVyZGF5LCA0IE1heSAyMDEzIDc6MTAgQU08YnI+PGI+VG86 PC9iPiBJRVRGIEFwcHMgRGlzY3Vzczxicj48Yj5TdWJqZWN0OjwvYj4gW2FwcHMtZGlzY3Vzc10g Q2FsbCBmb3IgQWRvcHRpb246IGRyYWZ0LXNuZWxsLW1lcmdlLXBhdGNoPG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBw dCc+VGhpcyBpcyBhIGNhbGwgZm9yIGFkb3B0aW9uIGZvciBkcmFmdC1zbmVsbC1tZXJnZS1wYXRj aC4mbmJzcDsgVGhlIGRvY3VtZW50IGhhZCBhIHRocmVhZCBvZiBkaXNjdXNzaW9uIGluIEphbnVh cnksIGFuZCBzb21lIHByaW9yLCB0aGF0IHNob3dlZCBzb21lIGludGVyZXN0IHdpdGhpbiB0aGlz IHdvcmtpbmcgZ3JvdXAsIGFuZCBpdCBhcHBlYXJzIHRvIGJlIG1hdGVyaWFsIHRoYXQgZmFsbHMg d2l0aGluIG91ciBjaGFydGVyLiZuYnNwOyBBY2NvcmRpbmdseSwgd2UnbGwgYWRvcHQgdGhpcyBh cyBhIHdvcmtpbmcgZ3JvdXAgaXRlbSB3aXRoaW4gdGhlIG5leHQgY291cGxlIG9mIHdlZWtzIHVu bGVzcyB0aGVyZSdzIG9iamVjdGlvbiB0byBzdWNoIHByb2Nlc3NpbmcuJm5ic3A7IEkgd2lsbCBh Y3QgYXMgZG9jdW1lbnQgc2hlcGhlcmQuPG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPi1NU0ssIEFQUFNBV0cgY28tY2hhaXI8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48 L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_255B9BB34FB7D647A506DC292726F6E1150D5F89CCWSMSG3153Vsrv_-- From mnot@mnot.net Sun May 12 23:34:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB8221F901D for ; Sun, 12 May 2013 23:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[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 yyE9xMp+Xo8X for ; Sun, 12 May 2013 23:34:52 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id F05D921F8F62 for ; Sun, 12 May 2013 23:34:51 -0700 (PDT) Received: from [192.168.1.80] (unknown [118.209.105.214]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3050522E1FA; Mon, 13 May 2013 02:34:44 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Mark Nottingham In-Reply-To: Date: Mon, 13 May 2013 16:34:42 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <2055F6C9-7D10-4F97-B1EE-DB1871C665F0@mnot.net> References: To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1503) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for Adoption: draft-snell-merge-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 06:34:56 -0000 On 04/05/2013, at 7:10 AM, Murray S. Kucherawy = wrote: > This is a call for adoption for draft-snell-merge-patch. The document = had a thread of discussion in January, and some prior, that showed some = interest within this working group, 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. I will act as document shepherd. I'm +1, *if* it aligns with what people seem to be doing out there. See: https://github.com/rails/rails/issues/10439 https://github.com/documentcloud/backbone/issues/2512 -- Mark Nottingham http://www.mnot.net/ From superuser@gmail.com Sun May 12 23:47: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 955BD21F915B for ; Sun, 12 May 2013 23:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 hVeWaAxGFjha for ; Sun, 12 May 2013 23:47:13 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 69E4D21F915A for ; Sun, 12 May 2013 23:47:13 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hn14so198053wib.13 for ; Sun, 12 May 2013 23:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=t5BMqX+Ut91ALpMrobU6dOMYT8b+Y2FQiTQzZz3+gJI=; b=kjOQkfKVW4VHrcEo14ocEMY581ErW3Oc/EThn/L+RZsRwZbYeSCBkE86twSyfwCqjk gqI8TyRf2Ayg+BWU78o1sNgt81uqD9atQdXaodYnl4qX0VAi5mQMidC3TtIGlDwmlB8/ g0Gt8YloxQLracCXIR6iCVKlvMGn0Jl/ULT2xJKA18rR9StQvvM1ldqd4ATupWb0ILI6 xjCzayY8uiJXC8c2nELeawFI1LzG3OIjFQKHmfpV2gzo+J6r48tuvt6GMQlxiOkIspZA 8iCWGd/72XmX5Y9U2bEIF29Rse44ULCBVf1xkG8ZGrGIBUVztLpZbxErduU0oWgl6M6b b9BQ== MIME-Version: 1.0 X-Received: by 10.180.37.109 with SMTP id x13mr16121804wij.20.1368427632589; Sun, 12 May 2013 23:47:12 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Sun, 12 May 2013 23:47:12 -0700 (PDT) In-Reply-To: <01OTC53YHHWQ000054@mauve.mrochek.com> References: <51657E80.8070208@bbiw.net> <01OTC53YHHWQ000054@mauve.mrochek.com> Date: Sun, 12 May 2013 23:47:12 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=e89a8f6473f5f100e404dc93e239 Cc: Dave Crocker , Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-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: Mon, 13 May 2013 06:47:14 -0000 --e89a8f6473f5f100e404dc93e239 Content-Type: text/plain; charset=ISO-8859-1 Hi Ned, thanks for your comments. I've worked in most of your suggestions, but have the following to ask further on some of your points: On Mon, May 6, 2013 at 2:14 PM, Ned Freed wrote: > Eight-Bit Data (section 8.7) needs a bunch of work, and once again it's a > failure to consider the semantics of where the 8bit shows up. 8bit > appearing in > a header is a very different proposition from 8bit in a body. EAI deserves > a > shout-out in the former case because it's new, and the latter case is now > so > much of a ho-hum for many agents that a recommendation to reject 8bit is > nothing short of silly. > > I'm also far from convinced that rejecting messages because of a single > null is > a good idea. I think a fair assessment of the likely intent in this case > is the > presence of a null or two is simply a message construction error, and > silently > dropping them is a much better bet. > Eight bit data is far from something I'm expert on. Could I ask you to write up a paragraph or three to include here, or replace what's here? > > Header Field Names (section 9.1) is certainly cute, but MIME is actually > quite clear that the first place a boundary can occur is in the following > body, not the associated header. I'm not really comfortable with > this document acting on an assessment of intent of material that is in fact > completely valid. My suggestion is therefore to refrain from talking about > rejecting such messages. > It's a real attack seen in the wild. I see your point about MIME and the location of boundaries, however, so I think this section can just go. > > I'm afraid "Missing MIME-Version Field" (section 9.2) is flat-out > incorrect. > The intent of a message that has a valid content-type and possibly > content-transfer-encoding is pretty darned clear, and perhaps more to the > point, failing to interpret such a message as MIME, given that many other > agents, e.g., metamail, are going to, is exceedingly poor practice from a > security standpoint. > This is also something real I dealt with at a previous employer. More often than not it was seen as part of a spam attack that targeted specific MUAs. I'm fine with removing this section however if the advice is controversial; I don't have access to data to back up how important or useful this change was. > > (If we're up for additions at this late date, it might also be good to add > a > section on how to handle bogus base64 or quoted-printable.) > Yup, we are. Do you have anything specific in mind? -MSK --e89a8f6473f5f100e404dc93e239 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ned, thanks for your comments.=A0 I've worked in mo= st of your suggestions, but have the following to ask further on some of yo= ur points:

On Mon, May 6, 2013 at 2:14 PM, Ned Freed <ned.freed@mrochek.com> wrote:
Eight-Bit Data (section 8.7) needs a bunch o= f work, and once again it's a
failure to consider the semantics of where the 8bit shows up. 8bit appearin= g in
a header is a very different proposition from 8bit in a body. EAI deserves = a
shout-out in the former case because it's new, and the latter case is n= ow so
much of a ho-hum for many agents that a recommendation to reject 8bit is nothing short of silly.

I'm also far from convinced that rejecting messages because of a single= null is
a good idea. I think a fair assessment of the likely intent in this case is= the
presence of a null or two is simply a message construction error, and silen= tly
dropping them is a much better bet.

Eig= ht bit data is far from something I'm expert on.=A0 Could I ask you to = write up a paragraph or three to include here, or replace what's here?<= br> =A0

Header Field Names (section 9.1) is certainly cute, but MIME is actually quite clear that the first place a boundary can occur is in the following body, not the associated header. I'm not really comfortable with
this document acting on an assessment of intent of material that is in fact=
completely valid. My suggestion is therefore to refrain from talking about<= br> rejecting such messages.

It's a rea= l attack seen in the wild.=A0 I see your point about MIME and the location = of boundaries, however, so I think this section can just go.

=A0

I'm afraid "Missing MIME-Version Field" (section 9.2) is flat= -out incorrect.
The intent of a message that has a valid content-type and possibly
content-transfer-encoding is pretty darned clear, and perhaps more to the point, failing to interpret such a message as MIME, given that many other agents, e.g., metamail, are going to, is exceedingly poor practice from a security standpoint.

This is also somet= hing real I dealt with at a previous employer.=A0 More often than not it wa= s seen as part of a spam attack that targeted specific MUAs.=A0 I'm fin= e with removing this section however if the advice is controversial; I don&= #39;t have access to data to back up how important or useful this change wa= s.
=A0

(If we're up for additions at this late date, it might also be good to = add a
section on how to handle bogus base64 or quoted-printable.)

Yup, we are.=A0 Do you have anything specific in mind?=
=A0
-MSK
--e89a8f6473f5f100e404dc93e239-- From tss@iki.fi Mon May 13 03: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 C65DF21F9423 for ; Mon, 13 May 2013 03:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNBELp1nm23Y for ; Mon, 13 May 2013 03:03:57 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id AA28321F9418 for ; Mon, 13 May 2013 03:03:56 -0700 (PDT) Received: from [192.168.10.100] (cs27091020.pp.htv.fi [89.27.91.20]) by dovecot.org (Postfix) with ESMTP id 13F8F1AE87A8 for ; Mon, 13 May 2013 13:03:55 +0300 (EEST) From: Timo Sirainen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 13 May 2013 13:04:03 +0300 To: apps-discuss@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [apps-discuss] draft-ietf-appsawg-malformed-mail-03 review X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 May 2013 10:04:02 -0000 A quick review from IMAP server developer's point of view: > 7. Line Terminaton >=20 > Thus, handling agents MUST treat naked CRs and LFs as CRLFs when > interpreting the message. Agreed for LFs, but doing this for CRs would often make the code much = more complex. A simple strchr(str, '\n') to find a line termination = would no longer work. I've also never seen naked CRs intended to be used = as CRLFs, but I've seen them sometimes added due to some bug. I think = naked CRs are a similar problem as NULs, and maybe should be just = deleted or replaced by a space. > 8.2. Non-Header Lines > From: user@example.com {1} > To: userpal@example.net {2} > Subject: This is your reminder {3} > about the football game tonight {4} > Date: Wed, 20 Oct 2010 20:53:35 -0400 {5} My code currently handles this by treating "about the football game = tonight" as header key, which doesn't have a value. > The preferred implementation if option 4 above is not employed is = to > apply the following heuristic when this malformation is detected: >=20 > 1. Search forward for an empty line. If one is found, then apply > option 3 above to the anomalous line, and continue. >=20 > 2. Search forward for another line that appears to be a new header > field, i.e., a name followed by a colon. If one is found, then > apply option 3 above to the anomalous line, and continue. Having to search forward is always a pretty annoying way to deal with = things. The searched text could even be megabytes after from the current = position. My code usually does parsing by only looking up maybe 1 = character forward. > 8.7. Eight-Bit Data >=20 > Handling agents MUST reject messages containing null bytes that are > not encoded in some standard way, and SHOULD reject other non-ASCII > bytes that are similarly not encoded. If rejection is not done, an > ASCII-compatible encoding such as those defined in [MIME] SHOULD be > used. I agree with others that messages shouldn't be rejected because there = are NULs or 8bit data in message body. Even in headers hotmail used to = send 8bit data directly, but hopefully that's not as common anymore. My = code replaces NULs with 0x80 characters (as does UW-IMAP) when sending = them to IMAP clients. > 9.2. Missing MIME-Version Field Agreed with Ned that a missing MIME-Version should be allowed (=3D = treated as if it exists with value 1.0). Dovecot used to strictly = require it, but after enough complaints from users I changed it so it's = no longer required. From jasnell@gmail.com Mon May 13 06:58: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 AC63321F93E5 for ; Mon, 13 May 2013 06:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[AWL=-2.200, 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 ITfncTakpuTr for ; Mon, 13 May 2013 06:58:27 -0700 (PDT) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id DD8C021F931B for ; Mon, 13 May 2013 06:58:26 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id k14so5856241oag.8 for ; Mon, 13 May 2013 06:58:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=XPjb/aYCmWblyQms5G505gC+vlU+UHYRoJbM1y6Jodw=; b=plQof2/uvpHFvnmVST/g7XVhijQ/XtmHhXm9Hr5dg9YN6WVe1j9UGV7gjy+Q/7djIu 0Gqd2Jz1BCEjm/sxrw0qmA03W+EFskyS7MOz+U8jKqGJcmCNwSXzeLLWBHBuVZDMcUat mx3xw48Mc6uvHKjpfUuh6wt69tw8Uqz13UNA58go5gGTbXNQeSYnLVfFoJ6ddMOX3KMR f13YJloyGYz/gTBRrLlH9zhtEGSoSu/7oO3Ll6TbqnydEVCwvuvdfH2jvH+oCF6Tpta8 DnqXlBQ4Uyarc+T7Cn7vqUInDv7bKzRe7+MuZcfHw8A3dagIQkmNAsodhsNuUUw9+ptG tSQA== X-Received: by 10.60.47.81 with SMTP id b17mr5077809oen.63.1368453506477; Mon, 13 May 2013 06:58:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.3.137 with HTTP; Mon, 13 May 2013 06:58:06 -0700 (PDT) In-Reply-To: <2055F6C9-7D10-4F97-B1EE-DB1871C665F0@mnot.net> References: <2055F6C9-7D10-4F97-B1EE-DB1871C665F0@mnot.net> From: James M Snell Date: Mon, 13 May 2013 06:58:06 -0700 Message-ID: To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for Adoption: draft-snell-merge-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 13:58:30 -0000 On Sun, May 12, 2013 at 11:34 PM, Mark Nottingham wrote: > On 04/05/2013, at 7:10 AM, Murray S. Kucherawy wrot= e: > >> This is a call for adoption for draft-snell-merge-patch. The document h= ad a thread of discussion in January, and some prior, that showed some inte= rest within this working group, and it appears to be material that falls wi= thin our charter. Accordingly, we'll adopt this as a working group item wi= thin the next couple of weeks unless there's objection to such processing. = I will act as document shepherd. > > > I'm +1, *if* it aligns with what people seem to be doing out there. > On that note, it ought to be pointed out that merge-patch is a formalization of an existing deployed scheme: https://developers.google.com/blogger/docs/3.0/performance?hl=3Den#patch - James > See: > https://github.com/rails/rails/issues/10439 > https://github.com/documentcloud/backbone/issues/2512 > > -- > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From rjsparks@nostrum.com Mon May 13 07:27: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 ED2DA21F914C; Mon, 13 May 2013 07:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SPF_PASS=-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 QQE-WekK2qtk; Mon, 13 May 2013 07:27:48 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E64BC21F925A; Mon, 13 May 2013 07:27:44 -0700 (PDT) Received: from unnumerable.local (mobile-166-147-071-029.mycingular.net [166.147.71.29]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r4DERe3t061625 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Mon, 13 May 2013 09:27:42 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <5190F856.8040502@nostrum.com> Date: Mon, 13 May 2013 09:27:34 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <5180E1D9.7010006@it.aoyama.ac.jp> <51818841.40601@nostrum.com> <519079D5.8080708@it.aoyama.ac.jp> In-Reply-To: <519079D5.8080708@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (shaman.nostrum.com: 166.147.71.29 is authenticated by a trusted mechanism) Cc: draft-sparks-genarea-imaparch.all@tools.ietf.org, IESG , Apps Area WG Subject: Re: [apps-discuss] Apps Area review of draft-sparks-genarea-imaparch-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: Mon, 13 May 2013 14:27:50 -0000 On 5/13/13 12:27 AM, "Martin J. Dürst" wrote: > Hello Robert, > > I have looked at your update, i.e. draft-sparks-genarea-imaparch-07. > It seems that all my concerns have been addressed, thanks very much. > > Thanks also for adding me to the acks section. However, please there > change my name from "Martin Durst" to "Martin Duerst". That's how it's > spelled if the "ü" character isn't available (which fortunately is > less and less the case). Will do, and apologies for not getting it right the first time. RjS > > Regards, Martin. > > On 2013/05/02 6:25, Robert Sparks wrote: >> On 5/1/13 4:35 AM, "Martin J. Dürst" 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-sparks-genarea-imaparch-06 >>> Title: IMAP Access to IETF Email List Archives >>> Reviewer: Martin Dürst >>> Review Date: 2013/05/01 >>> >>> >>> Summary: There is one main issue that's unclear to me. Otherwise, the >>> draft is close to publication, but needs some additional work. >>> >>> Note: I'm not an IMAP expert, not even an IMAP user, and not somebody >>> the Apps Area would call an email expert, although I wrote RFC 5064 >>> and quite a bit of RFC 6068. So the comments here are mostly of >>> general nature. >>> >>> Main issue: It is totally unclear to me what the actual consequences >>> of this draft are if approved. >> >> It will be used as input to the development of a tool providing the >> capabilities described here. >> >> We are capturing input from the IETF participants on what that tool >> needs to do. >> >> We've followed this approach with several other documents >> - RFC6778 (the web-based email archive) >> - RFC6730 (for nomcom tools) >> - RFC6433 (milestones) >> - RFC6292 (charters) >> >> The document already says >> "This memo captures the >> requirements for providing a service that would allow such browsing >> and searching." >> >> Would it help to add "and it is intended as input to a later activity >> for the design and development of such a tool." and would that address >> your concern? Or is it fine as it was after seeing that other context? >> >> Whether this results in an IAOC funded project or is satisfied with >> volunteer effort is not something this document needs to discuss. >> >> >>> I could imagine any one of the following: >>> >>> - It's informational, so it doesn't have any standing, and is just a >>> wishlist, mostly just by the author. >>> - If and when it will be IESG-approved, it documents IETF consensus >>> on how to best implement IMAP-based access to mailing list archives >>> for the IETF should such access be desirable, but it does not >>> represent an IETF consensus to actually implement this (e.g. because >>> that needs money, and money doesn't move by IETF consensus). >>> - If and when it will be IESG-approved, it documents IETF consensus >>> that >>> IMAP-based access to IETF mailing lists is desirable, and should be >>> implemented asap (assuming somebody can come up with the necessary >>> resources). >>> - An informal mixture of the above: Those in the know agree it's a good >>> idea, but somebody said they need a document that can be referenced in >>> an RFP. >>> >>> While I'm personally okay with any of the above (I won't use this kind >>> of access in the near future, but can understand that many people are >>> using IMAP and it would be pretty handy to have such a feature; also I >>> won't have to pay for it), I think the fact that this unclarity exists >>> may make it difficult for others to review the draft. >>> >>> So I suggest that this be clarified. Unless it's just me who's unclear >>> on this issue, it may get close to meriting a new or prolonged last >>> call. >> That will be for Jari to judge, but as I point out above, we've followed >> this pattern, using the language in this draft before. >>> >>> >>> Minor issue: The draft should reference RFC 6855 (IMAP Support for >>> UTF-8) and require its support *at least* to the extent that RFC 6778 >>> does (see http://tools.ietf.org/html/rfc6778#section-3). >> I will work to sew in a reference to 6855 >>> >>> >>> Editorial/Nits: >>> >>> o The interface must allow administrators to disable setting read/ >>> unread marks and other annotations, and delete any such marks or >>> annotations on a per user basis. >>> >>> It's unclear how far back "on a per user basis" applies. >>> Also, "the interface" means "an IMAP interface" (first bullet point), >>> but it may not be possible or practical to have administrators use >>> IMAP itself for this function. So I suggest something along the >>> following lines: >>> >>> o It must be possible for administrators, on a per-user basis, to >>> disable setting read/unread marks and other annotations and to >>> delete any such marks or annotations. >> I'll fold this suggestion in. >>> >>> >>> "and should support multiple simultaneous extensive searches.": Is >>> this simultaneous searches by the same user, or by different users? I >>> suspect the later. If so, the clause should be rewritten so that it is >>> clear that this is a dimensioning requirement, not a functionality >>> requirement. >> I think it's _both_, not one or the other. I will attempt to clarify. >>> >>> "The server should facilitate the enhanced search capabilities >>> described in [RFC6778].": It is unclear what "facilitate" means here. >>> Technology usually implements something or doesn't; facilitate sounds >>> quite fuzzy. Although RFC 6778 is informational, it uses quite a bit >>> of 'must',... On the other hand, IMAP may or may not support some of >>> the queries listed as a 'must' in RFC 6778. >> Would "provide" work better for you than "facilitate"? >>> >>> >>> "(But it is acceptable for a user to access such archives while >>> providing credentials).": Don't start a sentence with 'But' (use >>> 'However'). Also, please put the final period inside the parentheses. >> I will remove the But, and leave ). vs .) to the RFC Editor. >>> >>> "an LOGIN command" -> "a LOGIN command" >> Thanks - will fix. >>> >>> "determined by the administrator ." -> "determined by the >>> administrator." >>> >>> "local copies all messages" -> "local copies of all messages" >>> >>> "maliciously crafted searches attempting to consume all available >>> resources" -> "maliciously crafted searches attempting to consume >>> significant available resources" (there is no need to consume all >>> resources to result in significant DOS problems) >>> >>> " maliciously crafted annontations attempting to consume all storage >>> space" -> " maliciously crafted annontations attempting to consume >>> significant storage space" >> Will fix all those. >>> >>> "The implementers should consider making it easy for the administrator >>> to determine which users are consuming exceptional space.": >>> "exceptional space" -> "exceptional amounts of space"; I also think >>> "should consider" is rather too weak, and "easy to determine" seems to >>> imply that administrators will have to actively check this (rather >>> than getting alerts when something fishy starts). >> The language is intended to leave latitude for design. Forcing >> administrators to poll would not satisfy "making it easy". >> I will try to make that clearer. >> >>> This may be just an implementation detail, but it may be a good idea >>> to note that flag implementation (and annotation implementation if an >>> annotation can be applied by the user to more than one message at >>> once) has to be quite clever because otherwise, even benign use might >>> use up lots of space. As an example, if the system allocates 4 bytes >>> for each message in the system for each user that logs into the system >>> even once, that may already create huge storage demands. >> I will look at calling this out. However, there are many bad things that >> an implementation _could_ do, and calling them all out is not needed >> here. Things like this would get caught at design review or as source >> comes in. (You can get the source for the running datatracker - see the >> codesprint pages if you don't already know how). Such bad design will be >> caught. Good designs are often improved at codesprints. >>> >>> Regards, Martin. >>> >>> >>> >> >> From johnl@iecc.com Mon May 13 08:40: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 7D06721F939E for ; Mon, 13 May 2013 08:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.34 X-Spam-Level: X-Spam-Status: No, score=-109.34 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 gKjGVCNT-cEo for ; Mon, 13 May 2013 08:40:01 -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 25B7C21F93DE for ; Mon, 13 May 2013 08:40:00 -0700 (PDT) Received: (qmail 39181 invoked from network); 13 May 2013 15:39:54 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 May 2013 15:39:54 -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=5191094a.xn--i8sz2z.k1305; i=johnl@user.iecc.com; bh=lvteO7bxVGH2Sf++M35oI+c6Px2OPZQjqHWh4jllrH4=; b=YdpZ+5zDS56/Vlli6BzMvmiXZ6SPKKojldkH5gASEEX+t/Vm3Jhyf9waLj6nbjcgP6KbmCsK6PQ/W1E8FiVfbXPEnxc1chlI+0Jw3J8qRQvY24AXiSYqm6q49vbcyRotQsMIShNaJlYW/BuxAx9elz6x/3UnZp9rt6E/r3Vyb28= 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=5191094a.xn--i8sz2z.k1305; olt=johnl@user.iecc.com; bh=lvteO7bxVGH2Sf++M35oI+c6Px2OPZQjqHWh4jllrH4=; b=rrC63k5o9WebgGFZm190aVwZZZicQ9k71Eu9+cFwzMOfnCz/T4FYAwIioWg1JhYAzE6ExQWoklSgeyBXfxCxSMXB7fwunOfXECdGVKIWBq19rUtx1RO2DYcu4EBy0nMZUyK78JTEDe4qCgCKjopvgQ1V3zjetq2rkqXzKdxj2GI= Date: 13 May 2013 15:39:32 -0000 Message-ID: <20130513153932.91355.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] Review of: draft-ietf-appsawg-malformed-mail-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: Mon, 13 May 2013 15:40:05 -0000 >Eight bit data is far from something I'm expert on. Could I ask you to >write up a paragraph or three to include here, or replace what's here? These days, eight bit data in the message body is most likely just text. The tricky bit is figuring out what the encoding is. In my mail, the eight-bit characters I see most often are angled single and double quotes and other punctuation, typically in text that has been pasted in from a web browser or word processor. I also see accented characters, either in people's names or just to add élan. I gather that simple heuristics that check 8bit characters against various encodings of stuff likely to appear in text work pretty well, at least in mailstreams that are primarily in roman alphabet languages. In headers, you will see unencoded UTF-8 in mail that leaks from EAI mailstreams into normal mail. It is my impression that it is rare to see unencoded 8bit characters in any other encoding in headers. In both cases, it's much more likely to be a mistake than an attack. In 8.6, is it really a good idea to add missing date headers in an MTA? My impression is that most mail that makes it to your MTA without a date header isn't mail you want to read. R's, John From alexey.melnikov@isode.com Tue May 14 06:32: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 8216521F90C3 for ; Tue, 14 May 2013 06:32: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=[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 pRPCesWrP7rO for ; Tue, 14 May 2013 06:32:44 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id EFC0E21F90B9 for ; Tue, 14 May 2013 06:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1368538362; d=isode.com; s=selector; i=@isode.com; bh=9UFVSBn+WPp/Z6rjGIErWna0U8dgjyjz7N/9G16B63c=; 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=B9Qf49u0CjBwBzcBRsrBE7QlByLHzpGFXEf50Zgy4ROSrlfhM4Wfva8To+YuUA1goMQGGl RT0tabuQBN5awmU+CfG2OIQ3KE7OfzxDPnmpCJaViX/KhHbtuzpfEiUWE3JuUOsGZbQEiO BY2DmZAzPNPNkc3VflB+/kkdTMIxUlQ=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 14 May 2013 14:32:42 +0100 Message-ID: <51923CFB.8090702@isode.com> Date: Tue, 14 May 2013 14:32:43 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: apps-discuss@ietf.org References: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> In-Reply-To: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-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, 14 May 2013 13:32:48 -0000 On 03/05/2013 22:26, S Moonesamy wrote: > Hi APPSAWG, > > This message initiates a two weeks WGLC on > draft-ietf-appsawg-rfc5451bis-00 ("Message Header Field for Indicating > Message Authentication Status") [1]. Please send your comments to the > mailing list before the end of Friday May 17. Comments saying that you > reviewed the draft and you are happy for it to be sent for IETF Last > Call are also valuable. > > Regards, > S. Moonesamy (as document shepherd) > > 1. http://tools.ietf.org/html/draft-ietf-appsawg-rfc5451bis-00 I just reviewed -01. I believe it is a well written document with good and detailed security considerations. Some nits are below: In Section 2.2: Where an SMTP command is being reported as a "property", the MAIL FROM command MUST be represented by "mailfrom" and the RCPT TO command MUST be represented by "rcptto". All other SMTP commands MUST be represented unchanged. This seems to say that the SMTP reference is Normative, because one need to be able to lookup list of SMTP commands in RFC 5321. But RFC 5321 is listed as Informative. In Section 2.5.4: LDAP needs an Informative Reference. 2.5.5. Extension Result Codes Additional result codes (extension results) might be defined in the future by later revisions or extensions to this specification. Result codes MUST be registered with the Internet Assigned Numbers Authority (IANA) and preferably published in an RFC. See Section 6 for further details. Extension results MUST only be used within ADMDs that have explicitly consented to use them. These results and the parameters associated with them are not formally documented. Therefore, they are subject to change at any time and not suitable for production use. Any MTA, MUA or downstream filter intended for production use SHOULD ignore or delete any Authentication-Results header field that includes an extension result. I am mostly curious to see some examples of such extensions. From superuser@gmail.com Tue May 14 09: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 EB02521F93F4 for ; Tue, 14 May 2013 09:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAhHfCYcw6Mr for ; Tue, 14 May 2013 09:11:40 -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 6DC4B21F93E1 for ; Tue, 14 May 2013 09:11:39 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id u54so700659wes.1 for ; Tue, 14 May 2013 09:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=cI4zVvqkllQenXjYkpm1SBq03tuuVAJ7WXvEYAgnCto=; b=o79IJc82CtCocUxNi6cHPE/wFARIowVzti0P9jpPPpa0e9hNeUhuDoji/4UNCCaJLo jW/t6CYflGjER8adiFdigBp75pfMTdbjhCcAqNRXvRANL7iGFfounU54lBugkKLjWGij 6Em1qITSXoGf02QX8mI7VXx3CvAc5kMv4qD8kQw2CXkEpV5qJbTbyISCQpOt0X/F6eev i0yJR33tjLnd4Y6334xPnpR0aidXFqBmBu8ZAdiT+79+oUKy5nFEVH7o/st9cQBxe3xh 9SPxU6rSw4LcKK3JbPQfWt3T8kz7cboXjgPOZVbvECQd00vluP4oYBCo3sfNfTLQO21Z r16g== MIME-Version: 1.0 X-Received: by 10.180.73.228 with SMTP id o4mr7957528wiv.12.1368547892621; Tue, 14 May 2013 09:11:32 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Tue, 14 May 2013 09:11:32 -0700 (PDT) In-Reply-To: <51923CFB.8090702@isode.com> References: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> <51923CFB.8090702@isode.com> Date: Tue, 14 May 2013 09:11:32 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alexey Melnikov Content-Type: multipart/alternative; boundary=f46d043893cd081ba004dcafe32d Cc: IETF Apps Discuss Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-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, 14 May 2013 16:11:41 -0000 --f46d043893cd081ba004dcafe32d Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 14, 2013 at 6:32 AM, Alexey Melnikov wrote: > In Section 2.2: > > Where an SMTP command is being reported as a "property", the MAIL > FROM command MUST be represented by "mailfrom" and the RCPT TO > command MUST be represented by "rcptto". All other SMTP commands > MUST be represented unchanged. > > This seems to say that the SMTP reference is Normative, because one need > to be able to lookup list of SMTP commands in RFC 5321. But RFC 5321 is > listed as Informative. > OK. > In Section 2.5.4: > > LDAP needs an Informative Reference. > Are we sure about that? It's just an example of a related service that might cause a temperror for SMTP AUTH. I could change it to "a directory service" to avoid having to make that reference. LDAP's not important to this specification in any way. I'll do that, actually. > > > 2.5.5. Extension Result Codes > > Additional result codes (extension results) might be defined in the > future by later revisions or extensions to this specification. > Result codes MUST be registered with the Internet Assigned Numbers > Authority (IANA) and preferably published in an RFC. See Section 6 > for further details. > > Extension results MUST only be used within ADMDs that have explicitly > consented to use them. These results and the parameters associated > with them are not formally documented. Therefore, they are subject > to change at any time and not suitable for production use. Any MTA, > MUA or downstream filter intended for production use SHOULD ignore or > delete any Authentication-Results header field that includes an > extension result. > > I am mostly curious to see some examples of such extensions. > You could make one up and imagine using it. Barry likes "banana", so: Authentication-Results: your.example.com; banana=foobar -MSK --f46d043893cd081ba004dcafe32d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 14, 2013 at 6:32 AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
In Section 2.2:

=A0 =A0Where an SMTP command is being reported as a "property", t= he MAIL
=A0 =A0FROM command MUST be represented by "mailfrom" and the RCP= T TO
=A0 =A0command MUST be represented by "rcptto". =A0All other SMTP= commands
=A0 =A0MUST be represented unchanged.

This seems to say that the SMTP reference is Normative, because one need to= be able to lookup list of SMTP commands in RFC 5321. But RFC 5321 is liste= d as Informative.

OK.
=A0
In Section 2.5.4:

=A0LDAP needs an Informative Reference.

Are we sure about that?=A0 It's just an example of a related service t= hat might cause a temperror for SMTP AUTH.=A0 I could change it to "a = directory service" to avoid having to make that reference.=A0 LDAP'= ;s not important to this specification in any way.=A0 I'll do that, act= ually.


2.5.5. =A0Extension Result Codes

=A0 =A0Additional result codes (extension results) might be defined in the<= br> =A0 =A0future by later revisions or extensions to this specification.
=A0 =A0Result codes MUST be registered with the Internet Assigned Numbers =A0 =A0Authority (IANA) and preferably published in an RFC. =A0See Section = 6
=A0 =A0for further details.

=A0 =A0Extension results MUST only be used within ADMDs that have explicitl= y
=A0 =A0consented to use them. =A0These results and the parameters associate= d
=A0 =A0with them are not formally documented. =A0Therefore, they are subjec= t
=A0 =A0to change at any time and not suitable for production use. =A0Any MT= A,
=A0 =A0MUA or downstream filter intended for production use SHOULD ignore o= r
=A0 =A0delete any Authentication-Results header field that includes an
=A0 =A0extension result.

I am mostly curious to see some examples of such extensions.

You could make one up and imagine using it.=A0 Barry = likes "banana", so:

Authentication-Results: your.example.com; banana=3Dfoobar

-MSK
--f46d043893cd081ba004dcafe32d-- From alexey.melnikov@isode.com Tue May 14 09:33: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 872A321F8B90 for ; Tue, 14 May 2013 09:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.601 X-Spam-Level: X-Spam-Status: No, score=-101.601 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, MIME_QP_LONG_LINE=1.396, 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 VP15XM1zziEp for ; Tue, 14 May 2013 09:33:20 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 0300821F84AD for ; Tue, 14 May 2013 09:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1368549199; d=isode.com; s=selector; i=@isode.com; bh=KEP1JMfOcB1dYLPR/3ZqyK7QqQaoQC7TIw6pk/0TgzM=; 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=UY0aLN2MULMjqgHjHV64kBngGtI4bVKyTTCuMgeOp0cKlhQy22Ie6bcEiaL5deQeB2UAa6 OM/f/Y5EXzajCoHGw+LeINQGrH8DszxmL0VMnlgrnsBneFT82w7Bn2mD2tW4jc4BsbUBcx Fsk+CvJYpeWmnCYv9KnEPWUjW1E7iqg=; Received: from [172.17.128.24] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 14 May 2013 17:33:18 +0100 References: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> <51923CFB.8090702@isode.com> In-Reply-To: Message-Id: <67D63FBF-D54E-4C99-9A5C-F74FDD635226@isode.com> X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Tue, 14 May 2013 17:36:46 +0100 To: "Murray S. Kucherawy" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-2B5F06DD-5828-4731-A959-04280162F15B Cc: IETF Apps Discuss Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-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, 14 May 2013 16:33:25 -0000 --Apple-Mail-2B5F06DD-5828-4731-A959-04280162F15B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 14 May 2013, at 17:11, "Murray S. Kucherawy" wrote:= > On Tue, May 14, 2013 at 6:32 AM, Alexey Melnikov wrote: > =20 > In Section 2.5.4: >=20 > LDAP needs an Informative Reference. >=20 > Are we sure about that? It's just an example of a related service that mi= ght cause a temperror for SMTP AUTH. I could change it to "a directory serv= ice" to avoid having to make that reference. LDAP's not important to this s= pecification in any way. I'll do that, actually. I don't particularly care. Any protocol you mention needs a reference though= . > 2.5.5. Extension Result Codes >=20 > Additional result codes (extension results) might be defined in the > future by later revisions or extensions to this specification. > Result codes MUST be registered with the Internet Assigned Numbers > Authority (IANA) and preferably published in an RFC. See Section 6 > for further details. >=20 > Extension results MUST only be used within ADMDs that have explicitly > consented to use them. These results and the parameters associated > with them are not formally documented. Therefore, they are subject > to change at any time and not suitable for production use. Any MTA, > MUA or downstream filter intended for production use SHOULD ignore or > delete any Authentication-Results header field that includes an > extension result. >=20 > I am mostly curious to see some examples of such extensions. >=20 > You could make one up and imagine using it. Barry likes "banana", so: >=20 > Authentication-Results: your.example.com; banana=3Dfoobar Ok. Are there many of these in the wild? --Apple-Mail-2B5F06DD-5828-4731-A959-04280162F15B Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
On 14 May 2013, at 17:11, "Murray S. Kucherawy" <superuser@gmail.com> wrote:

On Tue, May 14, 2013 at 6:32 AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
 
In Section 2.5.4:

 LDAP needs an Informative Reference.

Are we sure about that?  It's just an example of a related service that might cause a temperror for SMTP AUTH.  I could change it to "a directory service" to avoid having to make that reference.  LDAP's not important to this specification in any way.  I'll do that, actually.

I don't particularly care. Any protocol you mention needs a reference though.

2.5.5.  Extension Result Codes

   Additional result codes (extension results) might be defined in the
   future by later revisions or extensions to this specification.
   Result codes MUST be registered with the Internet Assigned Numbers
   Authority (IANA) and preferably published in an RFC.  See Section 6
   for further details.

   Extension results MUST only be used within ADMDs that have explicitly
   consented to use them.  These results and the parameters associated
   with them are not formally documented.  Therefore, they are subject
   to change at any time and not suitable for production use.  Any MTA,
   MUA or downstream filter intended for production use SHOULD ignore or
   delete any Authentication-Results header field that includes an
   extension result.

I am mostly curious to see some examples of such extensions.

You could make one up and imagine using it.  Barry likes "banana", so:

Authentication-Results: your.example.com; banana=foobar

Ok. Are there many of these in the wild?

--Apple-Mail-2B5F06DD-5828-4731-A959-04280162F15B-- From superuser@gmail.com Tue May 14 09:58: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 21F3721F8529 for ; Tue, 14 May 2013 09:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+hvkR0usnhm for ; Tue, 14 May 2013 09:57:59 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 469F421F8506 for ; Tue, 14 May 2013 09:57:59 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hn14so2015102wib.2 for ; Tue, 14 May 2013 09:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=LWuZrgo+mwqSRzwG9230SQslHj5SMPXMMbUc6gbyDSU=; b=NCuPSBGM2jRY62wkzR7Cxc43lAZBFCyiF+VMFLTUkRnNeyiPsKxJPEd4W2SYxydTdZ 3nAXvGR9NGOhuAU4PCZ7ZA684Vjp14151QhqagyDIXdJgMsNjLs61MRnxwKzX+D3XhFX GKSbcNeKHADi+kBv3oqwT/kcULVGFEZDC5jrjVqpvCLlX0iSUJKcWMl/HASuWDhlGW0r sMAkX5iQQYXqD/HHSAZOHAZCi1fT0ArRm+uuFdLCQC5lV3Eb/a5w/8L8mWU6s/z1rrMG sj353djUdrcpHAr99rQfjssYFhPu+EkpP9vAog/ake42q2MZrcbYsDPZgsXFbiujZybE 5rDA== MIME-Version: 1.0 X-Received: by 10.180.189.41 with SMTP id gf9mr8153833wic.32.1368550678395; Tue, 14 May 2013 09:57:58 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Tue, 14 May 2013 09:57:58 -0700 (PDT) In-Reply-To: <67D63FBF-D54E-4C99-9A5C-F74FDD635226@isode.com> References: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> <51923CFB.8090702@isode.com> <67D63FBF-D54E-4C99-9A5C-F74FDD635226@isode.com> Date: Tue, 14 May 2013 09:57:58 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a11c348300b066004dcb08979 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-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, 14 May 2013 16:58:00 -0000 --001a11c348300b066004dcb08979 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 14, 2013 at 9:36 AM, Alexey Melnikov wrote: > 2.5.5. Extension Result Codes >> >> Additional result codes (extension results) might be defined in the >> future by later revisions or extensions to this specification. >> Result codes MUST be registered with the Internet Assigned Numbers >> Authority (IANA) and preferably published in an RFC. See Section 6 >> for further details. >> >> Extension results MUST only be used within ADMDs that have explicitly >> consented to use them. These results and the parameters associated >> with them are not formally documented. Therefore, they are subject >> to change at any time and not suitable for production use. Any MTA, >> MUA or downstream filter intended for production use SHOULD ignore or >> delete any Authentication-Results header field that includes an >> extension result. >> >> I am mostly curious to see some examples of such extensions. >> > > You could make one up and imagine using it. Barry likes "banana", so: > > Authentication-Results: your.example.com; banana=foobar > > > Ok. Are there many of these in the wild? > > There is no way to know for sure, of course. Most of the ones I know that were being tried have since been registered, so I don't personally know of any that fit in the description of 2.5.5 anymore. --001a11c348300b066004dcb08979 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 14, 2013 at 9:36 AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
<= blockquote type=3D"cite">
<= div class=3D"gmail_quote">
2.5.5. =A0Extension Result Codes

=A0 =A0Additional result codes (extension results) might be defined in the<= br> =A0 =A0future by later revisions or extensions to this specification.
=A0 =A0Result codes MUST be registered with the Internet Assigned Numbers =A0 =A0Authority (IANA) and preferably published in an RFC. =A0See Section = 6
=A0 =A0for further details.

=A0 =A0Extension results MUST only be used within ADMDs that have explicitl= y
=A0 =A0consented to use them. =A0These results and the parameters associate= d
=A0 =A0with them are not formally documented. =A0Therefore, they are subjec= t
=A0 =A0to change at any time and not suitable for production use. =A0Any MT= A,
=A0 =A0MUA or downstream filter intended for production use SHOULD ignore o= r
=A0 =A0delete any Authentication-Results header field that includes an
=A0 =A0extension result.

I am mostly curious to see some examples of such extensions.

You could make one up and imagine using it.=A0 Barry = likes "banana", so:

Authentication-Results: your.example.com; banana=3Dfoob= ar

Ok. Are the= re many of these in the wild?

Th= ere is no way to know for sure, of course.=A0 Most of the ones I know that = were being tried have since been registered, so I don't personally know= of any that fit in the description of 2.5.5 anymore.
--001a11c348300b066004dcb08979-- From johnl@iecc.com Tue May 14 10:49: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 12ABA21F853D for ; Tue, 14 May 2013 10:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.225 X-Spam-Level: X-Spam-Status: No, score=-109.225 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_05=-1.11, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_66=0.6, 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 8Sf8-+37pkM0 for ; Tue, 14 May 2013 10:49: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 30BEA21F854E for ; Tue, 14 May 2013 10:49:30 -0700 (PDT) Received: (qmail 22675 invoked from network); 14 May 2013 17:49:25 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 14 May 2013 17:49:25 -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=51927925.xn--yuvv84g.k1305; i=johnl@user.iecc.com; bh=zvu6ygMlwTvH4cu4MyBQmdjJWVcvkmeFRzp1nvakOdI=; b=TeLau3bWzJ8oaIv4zqTx2FZD+hXE2TYKIMq1Aio7y3Fk9kW5lXb5oNF7PxcjaQjOP1ZHN2woUG2kuDFHA5acn4UxvvmD6tIUvJJ6KIbnbXjedheiII+DE+yka4zy+c41Moi/+R0yXKpvTV/PduInCO4JSji9matPaPb4p80+3/A= 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=51927925.xn--yuvv84g.k1305; olt=johnl@user.iecc.com; bh=zvu6ygMlwTvH4cu4MyBQmdjJWVcvkmeFRzp1nvakOdI=; b=Wd63iovF9SLC2sZgdx2+LlXeVyC/ZoWEkLQXiHfs3XPBAJzuD2l5a0kiUfyLDXMNtQ2Fle17Px6RdUWRJtK1PCXhyUA87bKaN8uZil0ZW/IUxJ0ncmXkW6KwdVYIybWMtjvgMoIUNGOssMmNHWBlrnJko3Dglr9rycRK7A550XE= Date: 14 May 2013 17:49:03 -0000 Message-ID: <20130514174903.15656.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <67D63FBF-D54E-4C99-9A5C-F74FDD635226@isode.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-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, 14 May 2013 17:49:39 -0000 >> Authentication-Results: your.example.com; banana=foobar > >Ok. Are there many of these in the wild? There's one for DMARC, but since there's a WG spinning up that will presumably document it in an RFC. I've suggested a few clarifications to Murray, dunno if he's planning another version soon. From sm@elandsys.com Tue May 14 11:19: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 63F3921F8E99 for ; Tue, 14 May 2013 11:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_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 usfYvzGkz8hF for ; Tue, 14 May 2013 11:19:50 -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 E6BA721F8E9D for ; Tue, 14 May 2013 11:19:49 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.151.130]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4EIJUbi007021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 May 2013 11:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1368555583; bh=CLNuAnX6M3i9QFzmX7mNtzXhKUgZaqS744wLeCPHvIo=; h=Date:To:From:Subject:Cc; b=mPtZGL1LSFZD7s+oSbm3bdnpBYqkrrqLVPsreQKDg1tE7gyM6IUug6sRfeONxxQ5L /3+SVSYMKIFVMWHGEPcOSh90snx2F5c0QOY85+kT6yNdPTzq7RYh4QGK1YVoaoEE1f pH1qbS8oQExgJ8T0euTrp6CHvnr7dGFolhzz5hA0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1368555583; i=@elandsys.com; bh=CLNuAnX6M3i9QFzmX7mNtzXhKUgZaqS744wLeCPHvIo=; h=Date:To:From:Subject:Cc; b=o7Rp8oqaQQo/2nVk3mJbInDpPf337a8WzhZ7hKQ7vcFXs059dq/ifpSnUgkVztTdK oNOvM0r1fOif/oS15RuxPo2enpgtF7pR1lHQkKw5pRqIQpbKrfj+4vT67Fn25IPuSf KWxOUHVJuWi498WbSk5ZBuGw0XWcMBM+5GCvbSGk= Message-Id: <6.2.5.6.2.20130514110136.0c220a68@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 14 May 2013 11:18:12 -0700 To: "Murray S. Kucherawy" From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: [apps-discuss] IPR disclosure - draft-ietf-appsawg-rfc5451bis-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: Tue, 14 May 2013 18:19:51 -0000 Hi Murray, As you are the document author for draft-ietf-appsawg-rfc5451bis-02, can you confirm that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed? Please note that the WGLC for draft-ietf-appsawg-rfc5451bis-02 ends of Friday May 17th. Regards, S. Moonesamy (as document shepherd) From superuser@gmail.com Tue May 14 12:26: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 68EBF21F853D for ; Tue, 14 May 2013 12:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.800, 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 GKpbCKBV3QOK for ; Tue, 14 May 2013 12:26:04 -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 7EE8921F8E8E for ; Tue, 14 May 2013 12:25:56 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id c10so858324wiw.3 for ; Tue, 14 May 2013 12:25:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=LxtJMvabUy6nYX4BYxGf9AlDeS6FOBVnXQQVmQnlGTg=; b=0eS0Cp1LzVChfT7U0fL+6SafUfGEAneNozNl7y6LQ93AZTgAV46CxsQ+3sFoLMdtac ek4dLuQO69pusWqU/vGiqdRdnvruinvWLSRdSNuUQmbBZLXXCNCWGO2hj7WnHz5i15fY G7Qle/0khFvEZ/Rd3wmAoIzLSXFo84nVuYufOeCehNbK5VgNMDxqH8Sz7ECQG3B8UPI1 fiO0s6ucjxQPg32syL+O5KEVPqFLKxOovbIpvSEfKURbSNH4p5hwQukcq/S3vDUUgWEU uow3TN2MKvmjn/vQ8tNX1xh0lhXy8ij+Jm6vPSkwJ2y7Hxu2eYmvYkUc6e0pRaZZDvRT DmoQ== MIME-Version: 1.0 X-Received: by 10.180.79.69 with SMTP id h5mr9466094wix.14.1368559555515; Tue, 14 May 2013 12:25:55 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Tue, 14 May 2013 12:25:55 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130514110136.0c220a68@elandnews.com> References: <6.2.5.6.2.20130514110136.0c220a68@elandnews.com> Date: Tue, 14 May 2013 12:25:55 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=f46d043c062e291d3704dcb29a9e Cc: IETF Apps Discuss Subject: Re: [apps-discuss] IPR disclosure - draft-ietf-appsawg-rfc5451bis-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: Tue, 14 May 2013 19:26:04 -0000 --f46d043c062e291d3704dcb29a9e Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 14, 2013 at 11:18 AM, S Moonesamy wrote: > As you are the document author for draft-ietf-appsawg-rfc5451bis-02, can > you confirm that any and all appropriate IPR disclosures required for full > conformance with the provisions of BCP 78 and BCP 79 have already been > filed? > Confirmed; I know of none. -MSK --f46d043c062e291d3704dcb29a9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 14, 2013 at 11:18 AM, S Moonesamy <sm+ietf= @elandsys.com> wrote:
As you are the document author for draft-iet= f-appsawg-rfc5451bis-02, can you confirm that any and all appropriate IPR d= isclosures required for full conformance with the provisions of BCP 78 and = BCP 79 have already been filed?

Confirmed; I know of none.

-MSK
--f46d043c062e291d3704dcb29a9e-- From jasnell@gmail.com Tue May 14 18:35: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 1E67C21F8A74 for ; Tue, 14 May 2013 18:35: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 a-tfi2HyPzOr for ; Tue, 14 May 2013 18:35:08 -0700 (PDT) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5C68521F8A6B for ; Tue, 14 May 2013 18:35:08 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id cz11so1478750veb.20 for ; Tue, 14 May 2013 18:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=0RXVg3LqG/4M4E7/Y7kAHvsEdx1iCUKs68Chy4nmhsU=; b=mnqznbOUtshp+zPdUeTqSNKrsten2lbfkbc/Qu7UUvlw/4lT7NY/RWmRrAu6ED7Qzm sR6QZxkhPu+dk+Cpco6VhO9LF2X6qSFke8CN90daYk40H82A1zgefiCRfC6ioRvzzQfQ tEpIRUJD/j+zDC8m99cGk7TuFJKR1j6vACrIkdNCl1ZUl8q/bPHW25y32HjtDsd81P/P 5bU6FHHokerAMb/afZtKui7zPYnoblP0GTl/OpzxPbIWqfiIx7WFRErCVgerGZVwokl9 o+Yv36xL1E3ehH6zix4Ss4hIJj7eB8PHEALoH70ccCtb1+0RX477XWOHNGSWo6Avz+XB zp+A== X-Received: by 10.220.202.197 with SMTP id ff5mr23254857vcb.3.1368581707767; Tue, 14 May 2013 18:35:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.12.137 with HTTP; Tue, 14 May 2013 18:34:46 -0700 (PDT) In-Reply-To: References: From: James M Snell Date: Tue, 14 May 2013 18:34:46 -0700 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for Adoption: draft-snell-merge-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 01:35:09 -0000 FYI... A ruby implementation by Steve Klabnik... https://github.com/steveklabnik/json-merge_patch - James On Fri, May 3, 2013 at 2:10 PM, Murray S. Kucherawy wrote: > This is a call for adoption for draft-snell-merge-patch. The document had a > thread of discussion in January, and some prior, that showed some interest > within this working group, 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. I > will act as document shepherd. > > -MSK, APPSAWG co-chair > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From ned.freed@mrochek.com Wed May 15 11:09: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 E4F4021F8FD0 for ; Wed, 15 May 2013 11:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHK+IYqt5zvG for ; Wed, 15 May 2013 11:09:43 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0D55521F8FF2 for ; Wed, 15 May 2013 11:09:38 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OTO93I277K005YZ6@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 15 May 2013 11:04:36 -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 <01OTLPL3VY1C000054@mauve.mrochek.com>; Wed, 15 May 2013 11:04:33 -0700 (PDT) Message-id: <01OTO93GD6L2000054@mauve.mrochek.com> Date: Tue, 14 May 2013 10:07:28 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 12 May 2013 23:47:12 -0700" References: <51657E80.8070208@bbiw.net> <01OTC53YHHWQ000054@mauve.mrochek.com> To: "Murray S. Kucherawy" Cc: Ned Freed , Dave Crocker , Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-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, 15 May 2013 18:09:49 -0000 > Hi Ned, thanks for your comments. I've worked in most of your suggestions, > but have the following to ask further on some of your points: Great! > On Mon, May 6, 2013 at 2:14 PM, Ned Freed wrote: > > Eight-Bit Data (section 8.7) needs a bunch of work, and once again it's a > > failure to consider the semantics of where the 8bit shows up. 8bit > > appearing in > > a header is a very different proposition from 8bit in a body. EAI deserves > > a > > shout-out in the former case because it's new, and the latter case is now > > so > > much of a ho-hum for many agents that a recommendation to reject 8bit is > > nothing short of silly. > > > > I'm also far from convinced that rejecting messages because of a single > > null is > > a good idea. I think a fair assessment of the likely intent in this case > > is the > > presence of a null or two is simply a message construction error, and > > silently > > dropping them is a much better bet. > > > Eight bit data is far from something I'm expert on. Could I ask you to > write up a paragraph or three to include here, or replace what's here? This is going to take a lot more than three paragraphs to do properly. I'd suggest something like this (apologies in advance - this is *very* rough, but I'm in the middle of an office move and don't have time right now to wordsmith the text the way I normally would): -- 8.7 Missing or incorrect charset information MIME provides the means to include textual material employing charsets other than US-ASCII. Such material is required to have an identifiable charset. Charset identification is done using a charset parameter in the content-type header field, a charset label within the MIME entity itself, or the charset may be implicitly specified by the content-type [RFC 6657]. It is unfortunately fairly common for required charset information to be missing or incorrect in textual MIME entities. As such, processing agents should perform basic sanity checks, e.g., (1) US-ASCII is 7bit only so 8bit material is necessarily not US-ASCII. (2) UTF-8 has a very specific syntactic structure that other 8bit charsets are unlikely to follow. (3) Nulls (ASCII 0x00) are not allowed in either 7bit or 8bit data. (4) Not all 7bit material is US-ASCII. The presence of the various escape sequences used for character switching may be used as an indication of the various iso-2022-* charsets. When a charset error is detected processing agents should: (a) apply heuristics to determine the most likely charset and if successful proceed using that information, or (b) refuse to process the malformed MIME entity. A null (ASCII 0x00) byte inside a textual MIME entity can cause typical string processing functions to mis-identify the end of a string, which can be exploited to hide malicious content from analysis processes. According, nulls require additional special handling. A few nulls in isolation is likely to be the result of poor message construction practices. Such nulls should be silently dropped. Large numbers of nulls are usually the result of binary material that is improperly encoded, labelled, or both. Such material is likely to be damaged beyond the hope of recovery so the best course of action is to refuse to process it. Finally, the presence of nulls may be used as indication of possible malicious intent. 8.8 8bit data Standards-compliant mail messages do not contain any non-ASCII data without indicating that such content is present by means of published [SMTP] extensions. Absent that, [MIME] encodings are typically used to convert non-ASCII data to ASCII in a way that can be reversed by other handling agents or end users. The best way to handle incompliant 8bit material depends on its location. Incompliant 8bit in MIME entity content should simply be processed as if the necessary SMTP extensions had been used to transfer the message. Note that improperly labeled 8bit material in textual MIME entities may require treatment as described in section 8.7. Incompliant 8bit in message or MIME entity header fields can be handled as follows: (1) Occurrences in unstructured text fields, comments and phrases can be converted into encoded-words [RFC 2047] if a likely charset can be determined. Alternately, 8bit characters can be removed or replaced with some other character. (2) Occurrences in header fields whose syntax is unknown may be handled by dropping the field entirely or by removing/replacing the 8bit character as in (1). (3) Occurrences in addresses are especially problematic. Agents supporting [EAI] may, if the 8bit conforms to 8bit syntax, elect to treat the messages as an EAI message and process it accordingly. Otherwise it is in most cases best to exclude the address from any sort of processing - which may mean dropping it entirely - since any attempt to fix it is unlikely to help. -- One thing I'm strongly inclined to add is the option of presenting material to a user using an interface that lets them select the charset. Like it or not, this is a successful strategy employed by UAs in the field. > > > > Header Field Names (section 9.1) is certainly cute, but MIME is actually > > quite clear that the first place a boundary can occur is in the following > > body, not the associated header. I'm not really comfortable with > > this document acting on an assessment of intent of material that is in fact > > completely valid. My suggestion is therefore to refrain from talking about > > rejecting such messages. > > > It's a real attack seen in the wild. I see your point about MIME and the > location of boundaries, however, so I think this section can just go. It's an attack using a valid message on egregiously broken software. In fact it's likely an indicator that an even more fundamental problem is present: Searching forward into the message for data rather than first picking out the header and processing it separately. Given that the underlying problem may well be exploitable in other ways, the only real solution in such cases is to fix the broken software. Nothing else really suffices. That said, the issue of exploitable errors in software is beyond the scope of this document, so I agree the best thing is to remove this section. > > > > I'm afraid "Missing MIME-Version Field" (section 9.2) is flat-out > > incorrect. > > The intent of a message that has a valid content-type and possibly > > content-transfer-encoding is pretty darned clear, and perhaps more to the > > point, failing to interpret such a message as MIME, given that many other > > agents, e.g., metamail, are going to, is exceedingly poor practice from a > > security standpoint. > > > This is also something real I dealt with at a previous employer. More > often than not it was seen as part of a spam attack that targeted specific > MUAs. I'm fine with removing this section however if the advice is > controversial; I don't have access to data to back up how important or > useful this change was. Not sure what you're talking about here. The section describes no specific attack of any sort; it simply offers the observation that a message with MIME structure and no MIME-Version is more likely to be spam than a message that does contain a MIME-Version:, and then recommends that MIME structure not be processed or be removed when this occurs. It has not been my observation that missing MIME-Version: correlates all that well with spam; plenty of legitimate agents omit it and spam has evolved to include it. (This should be seen as natural and inevitable, after all, spam agents are under more evolutionary pressure than legitimate agents.) But more to the point, lots of software, including metamail, the original MIME software, pays no attention to MIME-Version: at all. And the chances of this changes are, IMO, remote. As such, the direct consequence of this recommendation is to enable a far worse attack: One where malicious content sneaks by agents written to comply with this specification and gets to software that will interpret the MIME structure and process the malicious content. I therefore believe that not only is what the section says incorrect, it's also inappropriate to remove it. The correct thing to do is say that the MIME structure should always be interpreted when present, especially by agents checking for malicious material. You could also add that it may be appropriate to use the lack of a MIME-Version as an indicator that malicious content may be present and to take additional precautions in processing the message. I believe that's the best way to address the concern this section was originally aimed at. > > > > (If we're up for additions at this late date, it might also be good to add > > a > > section on how to handle bogus base64 or quoted-printable.) > > > Yup, we are. Do you have anything specific in mind? It's basically the same "exploit different interpretations by different decoders" issue. For example, the original base64 defined in RFC 1113 -1115 allowed comments inside parentheses. Other implementations will silently ignore parentheses and interpret whatever is inside as data. The possible exploits of such differences are obvious. Ned From johnl@iecc.com Wed May 15 13:26: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 2046611E80E6 for ; Wed, 15 May 2013 13:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.212 X-Spam-Level: X-Spam-Status: No, score=-110.212 tagged_above=-999 required=5 tests=[AWL=0.987, 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 HEzF+Re7jL37 for ; Wed, 15 May 2013 13:26:41 -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 BD50F11E80E3 for ; Wed, 15 May 2013 13:26:37 -0700 (PDT) Received: (qmail 42521 invoked from network); 15 May 2013 20:26:36 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 15 May 2013 20:26:36 -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=5193ef7c.xn--i8sz2z.k1305; i=johnl@user.iecc.com; bh=YDtFZIMEdplun8VYbxJ05CQ9pQU56eVCqdw2EIhWuSE=; b=lermcFXOlbjKg+kFF5tFxk+vt22jz5aC6JPl1HYXnMrNPPVwooRqi9r04A08hpQG/WldU4+dTKT91JpIbndvqUVRCFRKWLB4CUBk7l3OgYbJKPn14+QUKsektWLmJRw05nDSeiUq6HtGOmjfnevXcYhgwGq+5LnyJOnjnQ9uaYs= 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=5193ef7c.xn--i8sz2z.k1305; olt=johnl@user.iecc.com; bh=YDtFZIMEdplun8VYbxJ05CQ9pQU56eVCqdw2EIhWuSE=; b=fMXgfbefRHFwlrvrIDBGx9Q8A2KtMTgMyrcGinWb0ItDm1QRcEWqSd9+V158nO2fmCoMfxXu6Fi9XtUW6WOHuiFpJpJV7hZbdC5l6/FbQQSKzIeUSgpwYrE/FiPJr6AAZlzhAJzI3RGEG1c5Iml4vG9J8GrkKtp+LEQ8se7ptTk= Date: 15 May 2013 20:26:13 -0000 Message-ID: <20130515202613.24981.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <01OTO93GD6L2000054@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] Review of: draft-ietf-appsawg-malformed-mail-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, 15 May 2013 20:26:45 -0000 >This is going to take a lot more than three paragraphs to do properly. I'd >suggest something like this (apologies in advance - this is *very* rough, but >I'm in the middle of an office move and don't have time right now to wordsmith >the text the way I normally would): Way better than what I sent. >But more to the point, lots of software, including metamail, the original MIME >software, pays no attention to MIME-Version: at all. And the chances of this >changes are, IMO, remote. I use Alpine which is one of the very few MUAs that take Murray's advice and ignore MIME headers if the MIME-Version is missing. It is a pain in the patoot, since it is invariably wrong. I ended up using procmail to add the missing header to mail from known screwups like the NY Times so I could read it properly. R's, John From ned.freed@mrochek.com Wed May 15 13:48:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023AA21F869F for ; Wed, 15 May 2013 13:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=0.610, 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 Vvl2Yl6hSLLJ for ; Wed, 15 May 2013 13:48:51 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id D65D421F85D6 for ; Wed, 15 May 2013 13:48:50 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OTOENUSHHC006AIX@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 15 May 2013 13:43:47 -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 <01OTLPL3VY1C000054@mauve.mrochek.com>; Wed, 15 May 2013 13:43:43 -0700 (PDT) Message-id: <01OTOENRSJ6Q000054@mauve.mrochek.com> Date: Wed, 15 May 2013 13:32:59 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 15 May 2013 20:26:13 +0000" <20130515202613.24981.qmail@joyce.lan> References: <01OTO93GD6L2000054@mauve.mrochek.com> <20130515202613.24981.qmail@joyce.lan> To: John Levine Cc: ned.freed@mrochek.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-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, 15 May 2013 20:48:56 -0000 > >This is going to take a lot more than three paragraphs to do properly. I'd > >suggest something like this (apologies in advance - this is *very* rough, but > >I'm in the middle of an office move and don't have time right now to wordsmith > >the text the way I normally would): > Way better than what I sent. FWIW, I agree completely with everything you said, and I hope it's reflected in what I wrote. > >But more to the point, lots of software, including metamail, the original MIME > >software, pays no attention to MIME-Version: at all. And the chances of this > >changes are, IMO, remote. > I use Alpine which is one of the very few MUAs that take Murray's > advice and ignore MIME headers if the MIME-Version is missing. It is > a pain in the patoot, since it is invariably wrong. I ended up using > procmail to add the missing header to mail from known screwups like > the NY Times so I could read it properly. NYT? Wow. I hadn't noticed they were one of the places that does it. The example I usually think of is one of the sources of political spam^H^H^H^H legitimate bulk mail which seems to do it intermittently. But that's nowhere near as good as example as the NYT. Another amusing thing one of these bulk email generators does is put out multiparts marked with a quoted-printable CTE. (The multipart is not, in fact encoded, although there have been other cases in the past where it was.) I don't know if this one is worth calling out in the doc or not. Ned From johnl@taugh.com Wed May 15 18:33: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 F0B5011E80D7 for ; Wed, 15 May 2013 18:33:57 -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 1hwt9DZ42M58 for ; Wed, 15 May 2013 18:33:57 -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 C36FB11E80E6 for ; Wed, 15 May 2013 18:33:56 -0700 (PDT) Received: (qmail 62200 invoked from network); 16 May 2013 01:33:54 -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=f2f6.51943782.k1305; bh=Kch6w1bXir20LLiAknd929GTiyWBJnCeiL2+Y5QPsgw=; b=A+IDe1WHSI7SbyVoHDr5kgQT2nyjn9BC+tWW+16/9VwwTYyNJyarMVAvig5sFPEU2E9NBRJXw5Muk9/QWTgTpsSiviQsAxhSN0ZqQKCBFoZS6rIhPXgXlpfJ9yQL9d0HvyQR6ZNYMitLvSNVvgSkKCZrx0I28SIChz5LATY67mA= 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=f2f6.51943782.k1305; bh=Kch6w1bXir20LLiAknd929GTiyWBJnCeiL2+Y5QPsgw=; b=IMur3MpKm477GsNEnrPBQUJn70PuVeNakUE162QUjRy/HSplCVZ9uRes/i5smnbfadPhfj7EjGFKdFOmp5lS91o58oknxrpjTdEWBZsa6kJZbhQ4gaPlZydjNqtc4lqEqg/wkRle3lN0G8aay2oQ3HkoXjAYuCtGyFx1GQIp2l8= Received: (ofmipd 127.0.0.1); 16 May 2013 01:33:32 -0000 Date: 15 May 2013 21:33:54 -0400 Message-ID: From: "John R Levine" To: "Ned Freed" In-Reply-To: <01OTOENRSJ6Q000054@mauve.mrochek.com> References: <01OTO93GD6L2000054@mauve.mrochek.com> <20130515202613.24981.qmail@joyce.lan> <01OTOENRSJ6Q000054@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: apps-discuss@ietf.org Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-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: Thu, 16 May 2013 01:33:58 -0000 >> procmail to add the missing header to mail from known screwups like >> the NY Times so I could read it properly. > > NYT? Wow. I hadn't noticed they were one of the places that does it. Yup. They may have fixed it by now, haven't checked lately since the procmail rule is harmless either way. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From vesely@tana.it Thu May 16 06:25: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 CDB5721F8F0F for ; Thu, 16 May 2013 06:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.519 X-Spam-Level: X-Spam-Status: No, score=-3.519 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_54=0.6, J_CHICKENPOX_66=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 6aiHYe7XgXgy for ; Thu, 16 May 2013 06:25:00 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1D50821F8930 for ; Thu, 16 May 2013 06:24:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1368710695; bh=g5bWlCqFgkmU33YzlZb8pIPPKuYcaH91p5SbH250dLE=; l=1922; h=Date:From:To:CC:References:In-Reply-To; b=Jk/V1OsKctHtRF+J0AoN1qUpL4LLSz3r9Krc/OYooAmzqe/dPMCGtbfXvTIxTIO2v c8Qs3XeY/jP5bJ2lP/8I4Pe4FQM8P/jI/TIQN005NKcVFJCYBLrEBjydzEd5fLybpa arXW7bQPky8ZoZ01n3emOkRYdZ76YrIJ2yL9pZ5E= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.156] (printer.tana [172.25.197.156]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Thu, 16 May 2013 15:24:55 +0200 id 00000000005DC048.000000005194DE27.00007855 Message-ID: <5194DE26.1000702@tana.it> Date: Thu, 16 May 2013 15:24:54 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: IETF Apps Discuss References: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> <51923CFB.8090702@isode.com> <67D63FBF-D54E-4C99-9A5C-F74FDD635226@isode.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Sam Varshavchik Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-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: Thu, 16 May 2013 13:25:03 -0000 On Tue 14/May/2013 18:57:58 +0200 Murray S. Kucherawy wrote: > On Tue, May 14, 2013 at 9:36 AM, Alexey Melnikov wrote: > >>>> 2.5.5. Extension Result Codes >>>> >>>> Additional result codes (extension results) might be defined in the >>>> future by later revisions or extensions to this specification. >>>> Result codes MUST be registered with the Internet Assigned Numbers >>>> Authority (IANA) and preferably published in an RFC. See Section 6 >>>> for further details. >>>> >>>> Extension results MUST only be used within ADMDs that have explicitly >>>> consented to use them. These results and the parameters associated >>>> with them are not formally documented. Therefore, they are subject >>>> to change at any time and not suitable for production use. Any MTA, >>>> MUA or downstream filter intended for production use SHOULD ignore or >>>> delete any Authentication-Results header field that includes an >>>> extension result. >>>> >>>> I am mostly curious to see some examples of such extensions. >>> >>> You could make one up and imagine using it. Barry likes "banana", so: >>> >>> Authentication-Results: your.example.com; banana=foobar >> >> Ok. Are there many of these in the wild? > > There is no way to know for sure, of course. Most of the ones I know that > were being tried have since been registered, so I don't personally know of > any that fit in the description of 2.5.5 anymore. One is the DNS White List (dnswl) method, used by Courier (mentioned in Appendix E). It writes: Authentication-Results: wmail.tana.it; dnswl=pass dns.zone=list.dnswl.org policy.ip=127.0.9.1 policy.txt="ietf.org http://dnswl.org/s?s=1703" Since it was me who suggested to use Authentication-Results, I think it's up to me to register that. I'm waiting for this I-D to get published so as to avail of Designated Expert rather than IETF review. From superuser@gmail.com Thu May 16 07:27: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 C944221F8F0A for ; Thu, 16 May 2013 07:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=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 8qEuBjjw8xs8 for ; Thu, 16 May 2013 07:27: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 848C121F8EDA for ; Thu, 16 May 2013 07:27:01 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id ey16so4302567wid.17 for ; Thu, 16 May 2013 07:27:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yeW9xrW0UdOaMvAmBvzK1IR/NfGZNtkPO7cxe5syPAM=; b=Ig2kp90IfCLwgEZXOW0GJJg+RDMrwxfMkfna0ShPHFVkd7+ifs3AaosBUTPrUW3rpK xE/0XS70I+SS6f4Q8JjqUNXSgHluW6PqSIhECraeO8GWYwVrIdHzt92yCXv9+Zji4zMt ElwASRjEb6w/e3GbXntIh9UzR/O832T5ZGsZOpbyK4Yj/EnwcD3miFqxZpGiVfCjMVT/ B1l/AVeMLuwEVGsTCcBsiElPsiP8X0sf9Oi+72drrXQl3heggrbu3VA0y7f4x4wHvTsX Kxzijk/BVPPHHMKYekeOcgY/97Xvegt9cuwapS88n87qh1xDOZwCiKEMkfTCsJFsck+Y 6wsg== MIME-Version: 1.0 X-Received: by 10.180.210.242 with SMTP id mx18mr24948062wic.14.1368714420537; Thu, 16 May 2013 07:27:00 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Thu, 16 May 2013 07:27:00 -0700 (PDT) In-Reply-To: <5194DE26.1000702@tana.it> References: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> <51923CFB.8090702@isode.com> <67D63FBF-D54E-4C99-9A5C-F74FDD635226@isode.com> <5194DE26.1000702@tana.it> Date: Thu, 16 May 2013 07:27:00 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=001a11c262e8d5d08604dcd6a824 Cc: Sam Varshavchik , IETF Apps Discuss Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-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: Thu, 16 May 2013 14:27:07 -0000 --001a11c262e8d5d08604dcd6a824 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 16, 2013 at 6:24 AM, Alessandro Vesely wrote: > One is the DNS White List (dnswl) method, used by Courier (mentioned > in Appendix E). It writes: > > Authentication-Results: wmail.tana.it; > dnswl=pass dns.zone=list.dnswl.org > policy.ip=127.0.9.1 > policy.txt="ietf.org http://dnswl.org/s?s=1703" > > Since it was me who suggested to use Authentication-Results, I think > it's up to me to register that. I'm waiting for this I-D to get > published so as to avail of Designated Expert rather than IETF review. > > > To be consistent with the other registered methods, the policy.ip and policy.txt things wouldn't be included. A-R is meant to provide results and return details of what visible parts of a message were evaluated (e.g., header fields, SMTP properties). The client IP isn't one of those, nor is resulting text. --001a11c262e8d5d08604dcd6a824 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 16, 2013 at 6:24 AM, Alessandro Vesely <vesely@t= ana.it> wrote:
One is the DNS White List (dnswl) method, us= ed by Courier (mentioned
in Appendix E). =A0It writes:

=A0 Authentication-Results: wmail.tana.it;
=A0 =A0 =A0 dnswl=3Dpass dns.zone=3Dlist.dnswl.org
=A0 =A0 =A0 policy.ip=3D127.0.9.1
=A0 =A0 =A0 policy.txt=3D"ietf.org ht= tp://dnswl.org/s?s=3D1703"

Since it was me who suggested to use Authentication-Results, I think
it's up to me to register that. =A0I'm waiting for this I-D to get<= br> published so as to avail of Designated Expert rather than IETF review.



To be consistent with the other registered methods, the p= olicy.ip and policy.txt things wouldn't be included.=A0 A-R is meant to= provide results and return details of what visible parts of a message were= evaluated (e.g., header fields, SMTP properties).=A0 The client IP isn'= ;t one of those, nor is resulting text.

--001a11c262e8d5d08604dcd6a824-- From vesely@tana.it Thu May 16 08:22: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 CF5DA21F90B3 for ; Thu, 16 May 2013 08:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.519 X-Spam-Level: X-Spam-Status: No, score=-3.519 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_54=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 lZWPJClH4xuh for ; Thu, 16 May 2013 08:22:22 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3195F21F8FDD for ; Thu, 16 May 2013 08:22:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1368717735; bh=xD+BkjwcDFY3V//maoF7wu0VNDXsLBxNcwr5LbIxyCE=; l=1647; h=Date:From:To:CC:References:In-Reply-To; b=StK4QfGpSCBc50BGXBjpPiQacUy3ks+gyOUs2qBc2nwK4eBSa9erklwt2oAdnjHkk FSFnGzQEuVF2/JmrOH33uezzkfA2Yp0+YCUbMGDLmo5ees2hEeJXkzbmayBCNt3j9G sSwcw9MTKqpEemfsU6qSmpBOEBVYUBR6uomb7xxU= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.156] (printer.tana [172.25.197.156]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Thu, 16 May 2013 17:22:15 +0200 id 00000000005DC02B.000000005194F9A7.00002702 Message-ID: <5194F9A7.8090003@tana.it> Date: Thu, 16 May 2013 17:22:15 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> <51923CFB.8090702@isode.com> <67D63FBF-D54E-4C99-9A5C-F74FDD635226@isode.com> <5194DE26.1000702@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Sam Varshavchik , IETF Apps Discuss Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-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: Thu, 16 May 2013 15:22:36 -0000 On Thu 16/May/2013 16:27:00 +0200 Murray S. Kucherawy wrote: > On Thu, May 16, 2013 at 6:24 AM, Alessandro Vesely wrote: > >> One is the DNS White List (dnswl) method, used by Courier (mentioned >> in Appendix E). It writes: >> >> Authentication-Results: wmail.tana.it; >> dnswl=pass dns.zone=list.dnswl.org >> policy.ip=127.0.9.1 >> policy.txt="ietf.org http://dnswl.org/s?s=1703" >> >> Since it was me who suggested to use Authentication-Results, I think >> it's up to me to register that. I'm waiting for this I-D to get >> published so as to avail of Designated Expert rather than IETF review. > > To be consistent with the other registered methods, the policy.ip and > policy.txt things wouldn't be included. A-R is meant to provide results > and return details of what visible parts of a message were evaluated (e.g., > header fields, SMTP properties). The client IP isn't one of those, nor is > resulting text. That's not a client IP, but the return value of the lookup. Passing that value to downstream filters is the whole point of adding this header field, otherwise it would have to be looked up again. Details such as DKIM's key length, IMHO, are often in a comment because they are of minor importance, not because they are not a visible part of the message.) The policy.txt is important as it contains a domain name. Albeit A-R is not intended to be restricted to domain-based authentication, that's by far the most common case, a granularity that was settled many years ago. By indicating a "somewhat responsible" entity, the method is semantically consistent with that strategy. From tobias.gondrom@gondrom.org Thu May 16 13:56: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 241B721F8F15 for ; Thu, 16 May 2013 13:56:40 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E2 hex): CC: ... draft-housley-rfc2050bis\342\200\213.all@tools.ie[...] X-Spam-Flag: NO X-Spam-Score: -95.361 X-Spam-Level: X-Spam-Status: No, score=-95.361 tagged_above=-999 required=5 tests=[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 XwoDqdCLp35n for ; Thu, 16 May 2013 13:56:39 -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 DD36421F8EFD for ; Thu, 16 May 2013 13:56:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=vBmZbwuugE5gI1e/2gAW0wD86teA31n/pNoq4Dr+BFbtXY/BH4xDhwzT+98xRFonZQKO70r/8fR9n6ik6Q1MwZKtomSr+rBUAynra0jARsu6XoAYBnxtEziUGxbDV8A0; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Enigmail-Version:Content-Type; Received: (qmail 32049 invoked from network); 16 May 2013 22:56:18 +0200 Received: from e181126254.adsl.alicedsl.de (HELO ?192.168.1.227?) (85.181.126.254) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 16 May 2013 22:56:18 +0200 Message-ID: <519547F2.20100@gondrom.org> Date: Thu, 16 May 2013 21:56:18 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: apps-discuss@ietf.org X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------070308040604090302050109" Cc: draft-housley-rfc2050bis​.all@tools.ietf.org, iesg@ietf.org, ietf@ietf.org Subject: [apps-discuss] APPSDIR review of draft-housley-rfc2050bis-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 May 2013 20:56:40 -0000 This is a multi-part message in MIME format. --------------070308040604090302050109 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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-housley-rfc2050bis-01 Title: The Internet Numbers Registry System Reviewer: Tobias Gondrom Review Date: May-16 Status: Informational Summary: I believe the draft is ready for publication. Review: 0. The document is well written and I very much like that the document is short and concise. Comments: 1. One of two key sentences I took from the document is that its self-described scope is "only documenting" the status quo. See Section 1: "does not propose any changes...., but it does provide information about the current... system". When reading this, one question the reader might consider is whether to agree with this scope-self-limitation. For my review, I followed this set scope, so the question is then only does the ID reflect reality and provide sufficient information. My answer to that is "yes". 2. And the second key sentence is from section 5: ... "specified in the IETF/IAB/ICANN MOU [RFC2860], discussions regarding the evolution of the Internet Numbers Registry System structure, policy, and processes are to take place within the ICANN framework and will respect ICANN's core values [ICANNBL]." So basically fully delegating that responsibility to ICANN. Personally IMHO, I would like to encourage the editors and the IETF to actually take a more strategic and pro-active approach and consider also whether any guided changes beyond status quo could improve the situation. Are our assumptions for the current system still true? Can we reflect about why certain aspects are as they are and whether we can learn from the past about any improvements we should actively explore or consider? A pro-active review of the overall situation including #1 and #2 might be useful? Best regards, Tobias --------------070308040604090302050109 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 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-housley-rfc2050bis-01
Title: The Internet Numbers Registry System
Reviewer: Tobias Gondrom
Review Date: May-16

Status: Informational

Summary: I believe the draft is ready for publication.

Review:
0. The document is well written and I very much like that the document is short and concise.

Comments:
1. One of two key sentences I took from the document is that its self-described scope is "only documenting" the status quo. See Section 1: "does not propose any changes...., but it does provide information about the current... system".
When reading this, one question the reader might consider is whether to agree with this scope-self-limitation.
For my review, I followed this set scope, so the question is then only does the ID reflect reality and provide sufficient information. My answer to that is "yes".

2. And the second key sentence is from section 5:
...  "specified in the IETF/IAB/ICANN MOU [RFC2860], discussions regarding the evolution of the Internet Numbers Registry System structure, policy, and processes are to take place within the ICANN framework and will respect ICANN's core values [ICANNBL]." So basically fully delegating that responsibility to ICANN.

Personally IMHO, I would like to encourage the editors and the IETF to actually take a more strategic and pro-active approach and consider also whether any guided changes beyond status quo could improve the situation.
Are our assumptions for the current system still true? Can we reflect about why certain aspects are as they are and whether we can learn from the past about any improvements we should actively explore or consider? A pro-active review of the overall situation including #1 and #2 might be useful?

Best regards, Tobias




 --------------070308040604090302050109-- From housley@vigilsec.com Thu May 16 14:21:37 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F68621F8A4E; Thu, 16 May 2013 14:21:37 -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, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cvmqkSUmiW3; Thu, 16 May 2013 14:21:32 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 7E37F21F8F3E; Thu, 16 May 2013 14:21:31 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 1C9C6F24070; Thu, 16 May 2013 17:21:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 4yallx-XCW1w; Thu, 16 May 2013 17:21:27 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-163-208.washdc.fios.verizon.net [96.241.163.208]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 1F13AF2406E; Thu, 16 May 2013 17:21:33 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-73--409934570 From: Russ Housley In-Reply-To: <519547F2.20100@gondrom.org> Date: Thu, 16 May 2013 17:21:29 -0400 Message-Id: <52506592-DBD1-485F-9EDD-39407B4887A4@vigilsec.com> References: <519547F2.20100@gondrom.org> To: Tobias Gondrom X-Mailer: Apple Mail (2.1085) Cc: ietf@ietf.org, iesg@ietf.org, apps-discuss@ietf.org, =?utf-8?Q?draft-housley-rfc2050bis=E2=80=8B=2Eall?=@tools.ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-housley-rfc2050bis-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 May 2013 21:21:37 -0000 --Apple-Mail-73--409934570 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tobias: Thanks for the review. Really, the delegation id to the RIRs. which in = turn use the ICANN ASO to establish global policy. Thanks again, Russ On May 16, 2013, at 4:56 PM, Tobias Gondrom wrote: > Hi,=20 >=20 > 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 ). 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-housley-rfc2050bis-01 > Title: The Internet Numbers Registry System > Reviewer: Tobias Gondrom > Review Date: May-16 >=20 > Status: Informational >=20 > Summary: I believe the draft is ready for publication.=20 >=20 > Review:=20 > 0. The document is well written and I very much like that the document = is short and concise. >=20 > Comments:=20 > 1. One of two key sentences I took from the document is that its = self-described scope is "only documenting" the status quo. See Section = 1: "does not propose any changes...., but it does provide information = about the current... system".=20 > When reading this, one question the reader might consider is whether = to agree with this scope-self-limitation.=20 > For my review, I followed this set scope, so the question is then only = does the ID reflect reality and provide sufficient information. My = answer to that is "yes".=20 >=20 > 2. And the second key sentence is from section 5: > ... "specified in the IETF/IAB/ICANN MOU [RFC2860], discussions = regarding the evolution of the Internet Numbers Registry System = structure, policy, and processes are to take place within the ICANN = framework and will respect ICANN's core values [ICANNBL]." So basically = fully delegating that responsibility to ICANN. >=20 > Personally IMHO, I would like to encourage the editors and the IETF to = actually take a more strategic and pro-active approach and consider also = whether any guided changes beyond status quo could improve the = situation.=20 > Are our assumptions for the current system still true? Can we reflect = about why certain aspects are as they are and whether we can learn from = the past about any improvements we should actively explore or consider? = A pro-active review of the overall situation including #1 and #2 might = be useful? >=20 > Best regards, Tobias >=20 >=20 >=20 >=20 --Apple-Mail-73--409934570 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
=20 =20
Hi,

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/wi= ki/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-housley-rfc2050bis-01
Title: The Internet Numbers Registry System
Reviewer: Tobias Gondrom
Review Date: May-16

Status: Informational

Summary: I believe the draft is ready for publication.

Review:
0. The document is well written and I very much like that the document is short and concise.

Comments:
1. One of two key sentences I took from the document is that its self-described scope is "only documenting" the status quo. See Section 1: "does not propose any changes...., but it does provide information about the current... system".
When reading this, one question the reader might consider is whether to agree with this scope-self-limitation.
For my review, I followed this set scope, so the question is then only does the ID reflect reality and provide sufficient information. My answer to that is "yes".

2. And the second key sentence is from section 5:
...  "specified in the IETF/IAB/ICANN MOU [RFC2860], = discussions regarding the evolution of the Internet Numbers Registry System structure, policy, and processes are to take place within the ICANN framework and will respect ICANN's core values [ICANNBL]." So basically fully delegating that responsibility to ICANN.

Personally IMHO, I would like to encourage the editors and the IETF to actually take a more strategic and pro-active approach and consider also whether any guided changes beyond status quo could improve the situation.
Are our assumptions for the current system still true? Can we reflect about why certain aspects are as they are and whether we can learn from the past about any improvements we should actively explore or consider? A pro-active review of the overall situation including #1 and #2 might be useful?

Best regards, Tobias

= --Apple-Mail-73--409934570-- From superuser@gmail.com Thu May 16 16:54: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 0E32F11E80A3 for ; Thu, 16 May 2013 16:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.633, 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 BMajmTFIbH5G for ; Thu, 16 May 2013 16:54:23 -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 1D1EC21F8616 for ; Thu, 16 May 2013 16:54:22 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id p57so1788443wes.32 for ; Thu, 16 May 2013 16:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=rMFV0odB9nsrPIm/nQDJNeEveVT9c8AtRVoeHjCgdXw=; b=MbdEHIpnV8d3HPk35k1UbO2p3NIPNALaFHcwqGwGvkuMztmZJKHji0ArUzjq3G+YEk jHLkh/zTIuG4aAPXtlHuKNCbvinjYdgWImZHneJ7hR+7XdIBsEunZbiiJIr3LyiDvzIS 9n6o4M7tQLGv+ZX/wL3cz5Fr0xiFvgUTQv0Rn5KMFKFI80r/BP3Otpr7dDlU4AGUGN8c Jhh0e+6Y4+atRRTCWGidbl7sZsY103JoWvfQYUA7wB55UE6P/GmsFWF/t/mhjNcDCyZl jkKi2XT39gCsn7bIrFeOpReK+dDpGLeXzHxAdxddm+j3hKmLMGMkCg6yePCSQLp/nhh5 d8YA== MIME-Version: 1.0 X-Received: by 10.180.82.74 with SMTP id g10mr29356220wiy.10.1368748461997; Thu, 16 May 2013 16:54:21 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Thu, 16 May 2013 16:54:21 -0700 (PDT) In-Reply-To: <5194F9A7.8090003@tana.it> References: <6.2.5.6.2.20130503141649.0d8252f0@elandnews.com> <51923CFB.8090702@isode.com> <67D63FBF-D54E-4C99-9A5C-F74FDD635226@isode.com> <5194DE26.1000702@tana.it> <5194F9A7.8090003@tana.it> Date: Thu, 16 May 2013 16:54:21 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=f46d04426742dd483b04dcde9575 Cc: Sam Varshavchik , IETF Apps Discuss Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc5451bis-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: Thu, 16 May 2013 23:54:24 -0000 --f46d04426742dd483b04dcde9575 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 16, 2013 at 8:22 AM, Alessandro Vesely wrote: > That's not a client IP, but the return value of the lookup. Passing > that value to downstream filters is the whole point of adding this > header field, otherwise it would have to be looked up again. Details > such as DKIM's key length, IMHO, are often in a comment because they > are of minor importance, not because they are not a visible part of > the message.) > > The policy.txt is important as it contains a domain name. Albeit A-R > is not intended to be restricted to domain-based authentication, > that's by far the most common case, a granularity that was settled > many years ago. By indicating a "somewhat responsible" entity, the > method is semantically consistent with that strategy. > > What does the reply encode that downstream agents need? If I know that, I can suggest something more in line with how A-R was designed to operate. --f46d04426742dd483b04dcde9575 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 16, 2013 at 8:22 AM, Alessandro Vesely <vesely@t= ana.it> wrote:
That's not a client IP, but the return v= alue of the lookup. =A0Passing
that value to downstream filters is the whole point of adding this
header field, otherwise it would have to be looked up again. =A0Details
such as DKIM's key length, IMHO, are often in a comment because they are of minor importance, not because they are not a visible part of
the message.)

The policy.txt is important as it contains a domain name. =A0Albeit A-R
is not intended to be restricted to domain-based authentication,
that's by far the most common case, a granularity that was settled
many years ago. =A0By indicating a "somewhat responsible" entity,= the
method is semantically consistent with that strategy.


What does the reply= encode that downstream agents need?=A0 If I know that, I can suggest somet= hing more in line with how A-R was designed to operate.
--f46d04426742dd483b04dcde9575-- From franck@peachymango.org Thu May 16 18:47: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 D9C3821F8E3C for ; Thu, 16 May 2013 18:47:47 -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 Q4R8Zod8VBDK for ; Thu, 16 May 2013 18:47:37 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id A781021F8D00 for ; Thu, 16 May 2013 18:47:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id F2DDF294149 for ; Thu, 16 May 2013 20:47:36 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySIziMpKeJnq for ; Thu, 16 May 2013 20:47:36 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id D0C83294059 for ; Thu, 16 May 2013 20:47:36 -0500 (CDT) Date: Thu, 16 May 2013 20:47:35 -0500 (CDT) From: Franck Martin To: apps-discuss@ietf.org Message-ID: <566479399.228274.1368755255546.JavaMail.root@peachymango.org> In-Reply-To: References: <01OTO93GD6L2000054@mauve.mrochek.com> <20130515202613.24981.qmail@joyce.lan> <01OTOENRSJ6Q000054@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.29] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - FF20 (Mac)/8.0.3_GA_5664) Thread-Topic: Review of: draft-ietf-appsawg-malformed-mail-03 Thread-Index: zOUS++4Ml4McRucgzukMth1q/b02Pw== Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-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: Fri, 17 May 2013 01:47:48 -0000 8.1.5. Unbalanced Quotes Not sure I agree with that, we should avoid to place a domain name in the display part. should be interpreted as: To: "Joe" 8.5. Header Field Counts I see option 1 at the MTA level option 2 at the MSA for an MUA, it has to deal with an invalid message, I think 3 could apply, but then the MUA only renders the message why should it alter it, especially if the message will be rendered by different MUA. 8.6. Missing Header Fields I see it differently... If the email comes from a MSA then add the fields, if the email comes from another MTA, reject the email. From superuser@gmail.com Thu May 16 19:22: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 AC03711E80E3 for ; Thu, 16 May 2013 19:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.380, 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 Y6P80-U1Ktro for ; Thu, 16 May 2013 19:22:17 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id E6ECA21F8B2B for ; Thu, 16 May 2013 19:22:16 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id t60so3302336wes.27 for ; Thu, 16 May 2013 19:22: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=dDLEwUdH0fZc+E/15A2hLjEl3VUqkYVvlZqQuA9UA7g=; b=CltwY+G2sfjADRb0taJpNHnBJznGiKixIkiAA83HNv3LMbBmIw9KwNj3cKgEC942jG VOKOyT/A+x+Ops0ZQbMLCExKX2/l+sKkjcvon7PzCUucf9TFDDiyeB1HLpj5zQg4a0BD /P2JiXRj4pxRODSd4vH9N49CI/Z1Xk/fVssOY94QCcS17daZljTCX6THOQRri1QKBjbq YhsCse4zxXDkYAQUhE43yg0vyUcJQTZvUNmzUCucse5YOZORnjLDD6J/7RxYjwGKg+cy YYDFr0eZAmWfPcpG3DLnINbCjzlP0zcVUhHqGnWcTBVnXXzV8xqhQOma3pAKYD2QomyY o1Ew== MIME-Version: 1.0 X-Received: by 10.180.74.172 with SMTP id u12mr3610663wiv.0.1368757336071; Thu, 16 May 2013 19:22:16 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Thu, 16 May 2013 19:22:15 -0700 (PDT) In-Reply-To: <566479399.228274.1368755255546.JavaMail.root@peachymango.org> References: <01OTO93GD6L2000054@mauve.mrochek.com> <20130515202613.24981.qmail@joyce.lan> <01OTOENRSJ6Q000054@mauve.mrochek.com> <566479399.228274.1368755255546.JavaMail.root@peachymango.org> Date: Thu, 16 May 2013 19:22:15 -0700 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=f46d04389001cce5be04dce0a6a6 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-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: Fri, 17 May 2013 02:22:17 -0000 --f46d04389001cce5be04dce0a6a6 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 16, 2013 at 6:47 PM, Franck Martin wrote: > 8.1.5. Unbalanced Quotes > > Not sure I agree with that, we should avoid to place a domain name in the > display part. > > should be interpreted as: > To: "Joe" > The document doesn't talk about what end users should be shown. It's all about filters and other handling agents. There's some specific text in there that talks about "internal representations" and such; see Section 4. > 8.5. Header Field Counts > > I see option 1 at the MTA level > option 2 at the MSA > for an MUA, it has to deal with an invalid message, I think 3 could apply, > but then the MUA only renders the message why should it alter it, > especially if the message will be rendered by different MUA. > The MSA is not in scope here, other than the fact that the document mentions that MSAs need to be more strict. This is all about MTAs and filters. > 8.6. Missing Header Fields > I see it differently... > > If the email comes from a MSA then add the fields, if the email comes from > another MTA, reject the email. > See above. -MSK --f46d04389001cce5be04dce0a6a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 16, 2013 at 6:47 PM, Franck Martin <fr= anck@peachymango.org> wrote:
8.1.5. Unbalanced Quotes

Not sure I agree with that, we should avoid to place a domain name in the d= isplay part.

should be interpreted as:
To: "Joe" <joe@example.com<= /a>>

8.5. Header Field Counts

I see option 1 at the MTA level
option 2 at the MSA
for an MUA, it has to deal with an invalid message, I think 3 could apply, = but then the MUA only renders the message why should it alter it, especiall= y if the message will be rendered by different MUA.
8.6. Missing Header Fields
I see it differently...

If the email comes from a MSA then add the fields, if the email comes from = another MTA, reject the email.

--f46d04389001cce5be04dce0a6a6-- From internet-drafts@ietf.org Fri May 17 00:06: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 7349F21F93BA; Fri, 17 May 2013 00:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.066, 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 jInzwESe9EkQ; Fri, 17 May 2013 00:06:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E09EC21F93B9; Fri, 17 May 2013 00:06:33 -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.45 Message-ID: <20130517070633.30274.29986.idtracker@ietfa.amsl.com> Date: Fri, 17 May 2013 00:06:33 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 07:06:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Advice for Safe Handling of Malformed Messages Author(s) : Murray S. Kucherawy Gregory N. Shapiro Filename : draft-ietf-appsawg-malformed-mail-04.txt Pages : 19 Date : 2013-05-17 Abstract: Although Internet mail formats have been precisely defined since the 1970s, authoring and handling software often show only mild conformance to the specifications. The distributed and non- interactive nature of email has often prompted adjustments to receiving software, to handle these variations, rather than trying to gain better conformance by senders, since the receiving operator is primarily driven by complaining recipient users and has no authority over the sending side of the system. Processing with such flexibility comes at some cost, since mail software is faced with decisions about whether or not to permit non-conforming messages to continue toward their destinations unaltered, adjust them to conform (possibly at the cost of losing some of the original message), or outright rejecting them. A core requirement for interoperability is that both sides of an exchange work from the same details and semantics. By having receivers be flexible, beyond the specifications, there can be -- and often has been -- a good chance that a message will not be fully interoperable. Worse, a well-established pattern of tolerance for variations can sometimes be used as an attack vector. This document includes a collection of the best advice available regarding a variety of common malformed mail situations, to be used as implementation guidance. It must be emphasized, however, that the intent of this document is not to standardize malformations or otherwise encourage their proliferation. The messages are manifestly malformed, and the code and culture that generates them needs to be fixed. Therefore, these messages should be rejected outright if at all possible. Nevertheless, many malformed messages from otherwise legitimate senders are in circulation and will be for some time, and, unfortunately, commercial reality shows that we cannot always simply reject or discard them. Accordingly, this document presents alternatives for dealing with them in ways that seem to do the least additional harm until the infrastructure is tightened up to match the standards. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-malformed-mail There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-malformed-mail-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-malformed-mail-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From superuser@gmail.com Fri May 17 00:07: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 EFEB021F93BD for ; Fri, 17 May 2013 00:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[AWL=-0.488, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63DE1usYL5EU for ; Fri, 17 May 2013 00:07:39 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id E55DC21F93B9 for ; Fri, 17 May 2013 00:07:38 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id k13so3081277wgh.31 for ; Fri, 17 May 2013 00:07:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=LQIVy4SehwrzOztwf3k2Mzeo+++jUOHRWtZ33x7gP1Y=; b=JgtKRJirfLcfghoZBmTqcotqVz4yAl/wuv/srRtT9Gx1qm6XChOc2JMjt0Nlye4pIY 9pLpx5Ak269p9iayLvimA2BkJvN+6Xc+oZfqy34OwcT223s4xskKUYazWJ7u669M6vtj kJWckrGXcRmZZdFOJUGyy3RNRlpPyKEgqLpffo9nxAr9fZ7mgYZw3A+FZe1Jpg2Rnm92 Q4dPsPmsVOSiBlIpQPnhP+xjAZdKck+bzGJwsZ3wuB/3M8unsgyZBt/vW6CpgwoFBflE JYofCt7wnLLeecUljR3cReSPlvnraPwVpiagqpaZHoZjfU8ph7NPySYX41fYZN7CkJ/n 064Q== MIME-Version: 1.0 X-Received: by 10.180.37.109 with SMTP id x13mr30889002wij.20.1368774458067; Fri, 17 May 2013 00:07:38 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Fri, 17 May 2013 00:07:37 -0700 (PDT) In-Reply-To: References: <01OTO93GD6L2000054@mauve.mrochek.com> <20130515202613.24981.qmail@joyce.lan> <01OTOENRSJ6Q000054@mauve.mrochek.com> Date: Fri, 17 May 2013 00:07:37 -0700 Message-ID: From: "Murray S. Kucherawy" To: John R Levine Content-Type: multipart/alternative; boundary=e89a8f6473f559d31304dce4a3a1 Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-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: Fri, 17 May 2013 07:07:40 -0000 --e89a8f6473f559d31304dce4a3a1 Content-Type: text/plain; charset=ISO-8859-1 I've posted a new version of the draft based on all the recent feedback. Thanks to those that gave some! With it refreshed and with all the new content, I'd love to have some more reviews of it in its current form. -MSK, hatless On Wed, May 15, 2013 at 6:33 PM, John R Levine wrote: > procmail to add the missing header to mail from known screwups like >>> the NY Times so I could read it properly. >>> >> >> NYT? Wow. I hadn't noticed they were one of the places that does it. >> > > Yup. They may have fixed it by now, haven't checked lately since the > procmail rule is harmless either way. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly. > > ______________________________**_________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/**listinfo/apps-discuss > --e89a8f6473f559d31304dce4a3a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've posted a new version of the draft based= on all the recent feedback.=A0 Thanks to those that gave some!

With it refreshed and with all the new content, I'd love to have some= more reviews of it in its current form.

-MSK, hatless


On Wed, May 15, 2013 at 6:33 PM, John R Levine <johnl@ta= ugh.com> wrote:
procmail to add the missing header to mail from known screwups like
the NY Times so I could read it properly.

NYT? Wow. I hadn't noticed they were one of the places that does it.

Yup. =A0They may have fixed it by now, haven't checked lately since the=
procmail rule is harmless either way.

Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

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

--e89a8f6473f559d31304dce4a3a1-- From duerst@it.aoyama.ac.jp Fri May 17 03:59: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 95E5521F9347 for ; Fri, 17 May 2013 03:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.491 X-Spam-Level: X-Spam-Status: No, score=-100.491 tagged_above=-999 required=5 tests=[AWL=-0.701, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t99gvu1DG117 for ; Fri, 17 May 2013 03:59:40 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id C1E5E21F8756 for ; Fri, 17 May 2013 03:59:39 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r4HAxYT3003007; Fri, 17 May 2013 19:59:34 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 0dc4_f27a_dbe26076_bee0_11e2_b26e_001e6722eec2; Fri, 17 May 2013 19:59:33 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 54F50BF4CE; Fri, 17 May 2013 19:58:47 +0900 (JST) Message-ID: <51960D80.3060507@it.aoyama.ac.jp> Date: Fri, 17 May 2013 19:59:12 +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: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <1CD55F04538DEA4F85F3ADF7745464AF249DAECA@S-BSC-MBX1.nrn.nrcan.gc.ca> <518106F0.1090001@it.aoyama.ac.jp> In-Reply-To: <518106F0.1090001@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] Full review of draft-ietf-appsawg-xml-mediatypes (was: Re: Getting 3023bis, a.k.a. draft-ietf-appsawg-xml-mediatypes, moving) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 May 2013 10:59:46 -0000 I have finally completed a full review of=20 draft-ietf-appsawg-xml-mediatypes-00. Here are my findings: Technically, this document is in good shape. It describes actual=20 practice that's widely established. But I'm sorry to say that this document is pretty much unreadable, in=20 particular for those who we want to read it. The reason for this is that=20 it contains a huge amount of historical ballast and (for most readers)=20 unnecessary justifications. I think it should not be too difficult to remedy this problem, and it=20 will help the average reader, which which I mean somebody who wants to=20 publish or consume an XML document, or define a Mime type with a +xml=20 suffix. I'll try to point out the main changes that I'd start with below; I may=20 be able to give more help, but next week looks busy. On 2013/05/01 21:13, "Martin J. D=C3=BCrst" wrote: > On 2013/05/01 19:13, Henry S. Thompson wrote: >> Rushforth, Peter writes: >>> Suggest to remove reference to Appendix A. Remove Appendix A, >>> also. All of that stuff is not the business of this RFC, but is the >>> responsibility of the registration procedure, in my opinion. >> >> What do people think? Appendix A [3] is "Why Use the '+xml' Suffix >> for XML-Based MIME Types?" and is carried over nearly unchanged from >> RFC3023 [4]. Maybe it was needed 12 years ago but is no longer >> relevant/necessary/useful? > > Yes. Please remove Appendix A, then add RFC 3023 as an informational > reference and point to its Appendix A as "historical reading". > > More comments hopefully coming soon. Removing the current Appendix A and pointing to it in RFC 3023 is the=20 first and biggest step. I didn't realize this, but currently, RFC 3023=20 is listed as normative, which is really strange. Next, let's start from the start. The abstract says: XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains. This sounds like text from 1997 (XML was finalized in 1998). I don't=20 think there is any need in this document to explain how widely XML is use= d. In the Intro, paragraphs can either be shortened or just removed. In=20 particular, the paragraphs starting with "Although XML is a subset of=20 the Standard Generalized Markup Language" and "Since XML is an integral=20 part of the WebDAV Distributed Authoring Protocol" can just be cut.=20 These were important for RFC 3023, in order to convince people who might=20 not have heard about XML, or may not have known that the IETF was=20 already using XML (in WebDAV), or confused it with SGML, but these days,=20 that's not a problem at all. In section 3 (XML Media Types), a lot of work is needed to disentangle=20 what readers need to know (think about readers in 5 or 10 years) on the=20 one hand, and rationale and historical background on the other hand=20 (which becomes less and less important when moving to the future). The=20 paragraph starting with "Within the XML specification", for example,=20 several times switches between actual spec text (MAY/MUST/...) and notes. Section 3.1, application/xml Registration: The text about the optional=20 charset parameter is way too long to stay in this registration, and is=20 referenced from many other places. I'd separate it out into a separate=20 section, and just put a pointer to that section from the template.=20 Again, as elsewhere, sort out the normative stuff from the=20 rationale/history. Section 3.6: A Summary is a good idea in a descriptive text, but putting=20 additional MUSTs there is a bad idea. This probably just shows that the=20 text up to here wasn't able to capture some essentials, which should be=20 fixed at the source, not cleaned up afterwards with a summary. Section 8: Same problems all over again. There is a lot of justification=20 for why "+xml" may be needed. This may have been appropriate when the=20 idea of a +xml suffix was first introduced, but that was 10 or more=20 years ago. 8.1: It would be great if this document provided a template for +xml=20 registrations, with the usual pointers already filled in (and lots of=20 [add/change as appropriate] or so notices). Similar problems in the security section, for example this piece of text: Use of XML is expected to be varied, and widespread. XML is under scrutiny by a wide range of communities for use as a common syntax for community-specific metadata. That was 10 or 15 years ago. Please let's rewrite this. I have more comments on details, but I first wanted to get out this=20 appeal for a general rewrite to move away from a historic/justificatory=20 writing style to a simple and short spec that answers the direct=20 questions of readers and stays readable in the future. I'm happy to=20 contribute if help is needed. Regards, Martin. From scott@kitterman.com Fri May 17 15:22: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 68D1F21F9666 for ; Fri, 17 May 2013 15:22:58 -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 MyKIH6RbedCf for ; Fri, 17 May 2013 15:22:53 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 322C321F95E9 for ; Fri, 17 May 2013 15:22:53 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1810820E40FE; Fri, 17 May 2013 18:22:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1368829372; bh=W8qRPJyTlGBczOAr+x8HJPkNljcSh+5ljdzLasrZwfI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=buwzhMjrNCprYlQE33yKrgrwQNe0NXldBFLVKlMHffwKihGQjPquaKwMWwZp8lb9D 7hmTS2RR6y91NrRaPs+DcL3coAgklzJ5trU82lc4xs1TMlQCX9mMmfIQqy5VQA1N+j nicCmxuZ7tpE1l2Hg/qwwRfLdX2FlOIkAMfigFug= 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 F1C8720E40F6; Fri, 17 May 2013 18:22:51 -0400 (EDT) From: Scott Kitterman To: apps-discuss@ietf.org Date: Fri, 17 May 2013 18:22:47 -0400 Message-ID: <1675160.H9MT8MA6B2@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <20130513045342.14228.40090.idtracker@ietfa.amsl.com> References: <20130513045342.14228.40090.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-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, 17 May 2013 22:22:58 -0000 On Sunday, May 12, 2013 09:53:42 PM internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Applications Area Working > Group Working Group of the IETF. > > Title : Message Header Field for Indicating Message > Authentication Status Author(s) : Murray S. Kucherawy > Filename : draft-ietf-appsawg-rfc5451bis-02.txt > Pages : 42 > Date : 2013-05-12 Comments: > At the time of publication of this document, Author Domain Signing > Practices ([ADSP]), SMTP Service Extension for Authentication > ([AUTH]), DomainKeys Identified Mail Signatures ([DKIM])>, Sender > Policy Framework ([SPF]), and Vouch-By-Reference ([VBR]) are > published DNS domain-level email authentication methods in common > use. DomainKeys ([DOMAINKEYS]) and Sender ID ([SENDERID] are also > referenced here, though they respectively have "Historic" and > "Experimental" status, and are no longer common. I've also seen iprev in the wild and it's supported by the python authres module I helped develop. We've also implemented DMARC based on the latest draft. Iprev is in 5451, so I think it should be mentioned. > Although SPF defined a header field called "Received-SPF" and > DomainKeys defined one called "DomainKey-Status" for this purpose, > those header fields are specific to the conveyance of their > respective results only and thus are insufficient to satisfy the > requirements enumerated below. In addition, many SPF implementations > have adopted the header field specified below, and DomainKeys has > been obsoleted by DKIM. I think this overstates things with respect to SPF. Most implementations have not adopted authres and even in the cases where they have, it's an option, not the default. In the ABNF: I believe the change from: authres-header = "Authentication-Results:" [CFWS] authserv-id [ CFWS version ] to: authres-header = "Authentication-Results:" [CFWS] authserv-id [ [CFWS] "/" [CFWS] authres-version ] is an incompatible change and if you really want to make it, you should bump the version number. I checked and with authres, your example is mis-parsed. Authentication-Results: example.org/1; none In this example, the authserv-id is "example.org", but authres, using the RFC 5451 ABNF parses this and determines the authserv-id is "example.org/1" If you want to make this change, I think it needs to be version 2 because an existing version 1 parser can't parse the header field anymore. Actually, I'm not sure that helps since a version 1 parser would fail to determine the message version. I think you need to specif a minimum of one space between the authserv-id and the "/" for backward compatibility. The first two are editorial. The last one is significant. It's possible we implemented it wrong in authres, but that's how it looks for the moment. Let's discuss. Scott K From ned.freed@mrochek.com Sat May 18 10:45:25 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA5B21F901A for ; Sat, 18 May 2013 10:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.305, 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 JdfmXniTQL-r for ; Sat, 18 May 2013 10:45:20 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0F11F21F8B65 for ; Sat, 18 May 2013 10:45:19 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OTSF4B1E28005ZTY@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 18 May 2013 10:40:13 -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 <01OTLPL3VY1C000054@mauve.mrochek.com>; Sat, 18 May 2013 10:40:09 -0700 (PDT) Message-id: <01OTSF48H616000054@mauve.mrochek.com> Date: Sat, 18 May 2013 10:39:04 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 17 May 2013 00:07:37 -0700" References: <01OTO93GD6L2000054@mauve.mrochek.com> <20130515202613.24981.qmail@joyce.lan> <01OTOENRSJ6Q000054@mauve.mrochek.com> To: "Murray S. Kucherawy" Cc: Ned Freed , John R Levine , IETF Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-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: Sat, 18 May 2013 17:45:25 -0000 > I've posted a new version of the draft based on all the recent feedback. > Thanks to those that gave some! This is looking good IMO, but of course I'd say that given how much of my feedback has been incorporated into the doc. > With it refreshed and with all the new content, I'd love to have some more > reviews of it in its current form. I concur. Additional eyes are really needed on this. Ned From steve@steveklabnik.com Sat May 18 12:58: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 8C4BC21F8BC5 for ; Sat, 18 May 2013 12:58:11 -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 ATOvyRk8a3ov for ; Sat, 18 May 2013 12:58:10 -0700 (PDT) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 75F7621F8551 for ; Sat, 18 May 2013 12:58:10 -0700 (PDT) Received: by mail-ia0-f169.google.com with SMTP id k38so6170209iah.14 for ; Sat, 18 May 2013 12:58:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=lTItvIHrvQlUZhIPmI2V0rVLMV6IeFggXcDIzOGXQB8=; b=fq8Mja2w+nkZWyUJa4rL2t9e0b+O6tiiaYnlLToGmuOA1WusvGxU1gVmKNGR7iSxY0 Mz1vteekG+UdezN0nBhalC1PIMekNXVxywU/o2hID29LzuBrOF1I3fYQ2K/u6/BjIHoF zZB5sHXTuJnZwI2Fmkb7xbC+60nefiYknDuBuubA0HBe/Cm1R81FrHMAtXtaW5DfQ3b8 z0lwuagzddbmD21rlx11IPGQN7KpFJ13ZwVl5FH1W+V+hZuzufScImhCLR/gYcOJmX9T m23M54IdrBzYQ9gYAzgTH7XaH3zcaq5ihvv9XQYuJfkXkRsuMHiSm6nuIV/WArWmilz6 NBoA== MIME-Version: 1.0 X-Received: by 10.42.35.75 with SMTP id p11mr19658912icd.6.1368907089512; Sat, 18 May 2013 12:58:09 -0700 (PDT) Received: by 10.64.53.170 with HTTP; Sat, 18 May 2013 12:58:09 -0700 (PDT) Date: Sat, 18 May 2013 12:58:09 -0700 Message-ID: From: Steve Klabnik To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl4VhRVm2YoNMVwuFcLQa3BwLP4kfqiCzcwbty0em34S86MkExVc+/5zo2mb6iFvefiUIfR Subject: [apps-discuss] draft-snell-merge-patch-08 in Ruby X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 May 2013 19:58:11 -0000 Hey there! James suggested that I post to this list, so here I am. I'm a committer to Ruby on Rails, and Rails 4 is near a release. One of the changes in Rails 4 is the usage of PATCH, which means I'm checking up on various diff media types. Mark Nottingham brought my attention to draft-snell-merge-patch as a simpler variant of json-patch. Anyway, I have a _mostly_ working implementation of the latest draft as a gem, here: https://github.com/steveklabnik/json-merge_patch . It's only missing the "Recursively apply rule 2" portion. Hopefully I'll be finishing it off soon. I'd say that overall this draft was super simple to implement, especially given Ruby's (like many scripting languages) ease of mapping JSON directly to its rich Hash and Array types in the language core. I may have one or two thoughts on the language of the spec, but I need to re-read it and take some notes this time around. - Steve From superuser@gmail.com Sat May 18 16:06: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 90C9021F8C40 for ; Sat, 18 May 2013 16:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.202, 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 OHh5jFLHc14M for ; Sat, 18 May 2013 16:06:54 -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 393F321F8C38 for ; Sat, 18 May 2013 16:06:54 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hr14so1171731wib.16 for ; Sat, 18 May 2013 16:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8/lU/IQ+QWj5MlishLVvDRUJn7e+DiAwS5GPE5mBgBc=; b=PKKmTE+5ss9soGY0mEbtfC2DEgwT4AVXfbs2nEJKiNEYxrjoQ/XpYuXLVGbqf+vPOS L8DT4KB997W/LPiGcl4rqpd76IIzzVFceDgvvg+nsKZKLzPUzc3yYY4OwkXqdHBJPIYt KMBd1v7dq5dtyYmff5Ht0dRGoyt/bqEk/QvgAPydbOd9dak5IL8Dy3sqcJyDK77wLi85 KM/eZlRPmEZpeRJlhL5vX9B0t3q6JQubxhc0T8UPlObTJ9jeExyBaJOEWRRHYYE2SQJo x6vyomA3IbCwEQy4Rh/xqPPAERUKgHqOVZnI3WrCW34JMKw90Br4j8c7U51BzjS+D1Px Ucng== MIME-Version: 1.0 X-Received: by 10.194.123.165 with SMTP id mb5mr7196602wjb.15.1368918413173; Sat, 18 May 2013 16:06:53 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Sat, 18 May 2013 16:06:53 -0700 (PDT) In-Reply-To: <1675160.H9MT8MA6B2@scott-latitude-e6320> References: <20130513045342.14228.40090.idtracker@ietfa.amsl.com> <1675160.H9MT8MA6B2@scott-latitude-e6320> Date: Sat, 18 May 2013 16:06:53 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=089e011831a8be6be704dd0627dd Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-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: Sat, 18 May 2013 23:06:55 -0000 --089e011831a8be6be704dd0627dd Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 17, 2013 at 3:22 PM, Scott Kitterman wrote: > Comments: > > > At the time of publication of this document, Author Domain Signing > > Practices ([ADSP]), SMTP Service Extension for Authentication > > ([AUTH]), DomainKeys Identified Mail Signatures ([DKIM])>, Sender > > Policy Framework ([SPF]), and Vouch-By-Reference ([VBR]) are > > published DNS domain-level email authentication methods in common > > use. DomainKeys ([DOMAINKEYS]) and Sender ID ([SENDERID] are also > > referenced here, though they respectively have "Historic" and > > "Experimental" status, and are no longer common. > > I've also seen iprev in the wild and it's supported by the python authres > module I helped develop. We've also implemented DMARC based on the latest > draft. Iprev is in 5451, so I think it should be mentioned. > > OK. > > Although SPF defined a header field called "Received-SPF" and > > DomainKeys defined one called "DomainKey-Status" for this purpose, > > those header fields are specific to the conveyance of their > > respective results only and thus are insufficient to satisfy the > > requirements enumerated below. In addition, many SPF implementations > > have adopted the header field specified below, and DomainKeys has > > been obsoleted by DKIM. > > I think this overstates things with respect to SPF. Most implementations > have > not adopted authres and even in the cases where they have, it's an option, > not > the default. > Seems to me adding "at least as an option" with respect to the SPF implementations is probably sufficient. > > In the ABNF: > > I believe the change from: > > authres-header = "Authentication-Results:" [CFWS] authserv-id > [ CFWS version ] > > to: > > authres-header = "Authentication-Results:" [CFWS] authserv-id > [ [CFWS] "/" [CFWS] authres-version ] > > is an incompatible change and if you really want to make it, you should > bump > the version number. I checked and with authres, your example is > mis-parsed. > > Authentication-Results: example.org/1; none > > In this example, the authserv-id is "example.org", but authres, using the > RFC > 5451 ABNF parses this and determines the authserv-id is "example.org/1" > > If you want to make this change, I think it needs to be version 2 because > an > existing version 1 parser can't parse the header field anymore. Actually, > I'm > not sure that helps since a version 1 parser would fail to determine the > message version. I think you need to specif a minimum of one space between > the authserv-id and the "/" for backward compatibility. > > The first two are editorial. The last one is significant. It's possible > we > implemented it wrong in authres, but that's how it looks for the moment. > Let's discuss. > > I made that change on two premises: 1) I've yet to see a single implementation that includes a version number in its output, though there are some that do look for it. It seems to me it's a safe change to make on that basis. 2) The way versioning is done at that point in the header field is inconsistent with where it's done adjacent to the methods. It's nicer on the eyes and easier for parsers if they're done the same way. I consider this a bug in RFC5451. I never opened an erratum for this before just fixing it in the -bis draft, but I think I probably should have. I'd hate to see this recycle at PS just for this change, so either I can back it out, or we could call it a bug fixed in this draft and leave the version alone. Although you're correct that strictly speaking it's incompatible, it only affects consumers regarding a currently unused protocol feature. Does anyone else have an opinion here? -MSK --089e011831a8be6be704dd0627dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, May 17, 2013 at 3:22 PM, Scott Kitterman <scott= @kitterman.com> wrote:
Comments:

> =A0 =A0At the time of publication of this document, Author Domain Sign= ing
> =A0 =A0Practices ([ADSP]), SMTP Service Extension for Authentication > =A0 =A0([AUTH]), DomainKeys Identified Mail Signatures ([DKIM])>, S= ender
> =A0 =A0Policy Framework ([SPF]), and Vouch-By-Reference ([VBR]) are > =A0 =A0published DNS domain-level email authentication methods in comm= on
> =A0 =A0use. =A0DomainKeys ([DOMAINKEYS]) and Sender ID ([SENDERID] are= also
> =A0 =A0referenced here, though they respectively have "Historic&q= uot; and
> =A0 =A0"Experimental" status, and are no longer common.

I've also seen iprev in the wild and it's supported by the python a= uthres
module I helped develop. =A0We've also implemented DMARC based on the l= atest
draft. =A0Iprev is in 5451, so I think it should be mentioned.

=A0
OK.
=A0
> =A0 =A0Although SPF defined a header field called "Received-SPF&q= uot; and
> =A0 =A0DomainKeys defined one called "DomainKey-Status" for = this purpose,
> =A0 =A0those header fields are specific to the conveyance of their
> =A0 =A0respective results only and thus are insufficient to satisfy th= e
> =A0 =A0requirements enumerated below. =A0In addition, many SPF impleme= ntations
> =A0 =A0have adopted the header field specified below, and DomainKeys h= as
> =A0 =A0been obsoleted by DKIM.

I think this overstates things with respect to SPF. =A0Most implementations= have
not adopted authres and even in the cases where they have, it's an opti= on, not
the default.

Seems to me adding &= quot;at least as an option" with respect to the SPF implementations is= probably sufficient.
=A0

In the ABNF:

I believe the change from:

authres-header =3D "Authentication-Results:" [CFWS] authserv-id =A0 =A0 =A0 =A0 [ CFWS version ]

to:

authres-header =3D "Authentication-Results:" [CFWS] authserv-id =A0 =A0 =A0 =A0 [ [CFWS] "/" [CFWS] authres-version ]

is an incompatible change and if you really want to make it, you should bum= p
the version number. =A0I checked and with authres, your example is mis-pars= ed.

=A0 =A0 =A0 =A0 Authentication-Results: example.org/1; none

In this example, the authserv-id is "example.org", but authres, using the RFC
5451 ABNF parses this and determines the authserv-id is "example.org/1"

If you want to make this change, I think it needs to be version 2 because a= n
existing version 1 parser can't parse the header field anymore. =A0Actu= ally, I'm
not sure that helps since a version 1 parser would fail to determine the message version. =A0I think you need to specif a minimum of one space betwe= en
the authserv-id and the "/" for backward compatibility.

The first two are editorial. =A0The last one is significant. =A0It's po= ssible we
implemented it wrong in authres, but that's how it looks for the moment= .
Let's discuss.


I made that change on two premis= es:

1) I've yet to see a single implementation that i= ncludes a version number in its output, though there are some that do look = for it.=A0 It seems to me it's a safe change to make on that basis.

2) The way versioning is done at that point in the header fi= eld is inconsistent with where it's done adjacent to the methods.=A0 It= 's nicer on the eyes and easier for parsers if they're done the sam= e way.=A0 I consider this a bug in RFC5451.=A0 I never opened an erratum fo= r this before just fixing it in the -bis draft, but I think I probably shou= ld have.

I'd hate to see this recycle at PS just for this change,= so either I can back it out, or we could call it a bug fixed in this draft= and leave the version alone.=A0 Although you're correct that strictly = speaking it's incompatible, it only affects consumers regarding a curre= ntly unused protocol feature.

Does anyone else have an opinion here?

-MS= K
--089e011831a8be6be704dd0627dd-- From johnl@taugh.com Sat May 18 20:00: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 1BEFC21F8C38 for ; Sat, 18 May 2013 20:00:28 -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 ihmEL9IqO2cF for ; Sat, 18 May 2013 20:00:27 -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 1A78321F86CE for ; Sat, 18 May 2013 20:00:26 -0700 (PDT) Received: (qmail 40618 invoked from network); 19 May 2013 03:00:24 -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=9ea9.51984048.k1305; bh=mNbZDTUIhoJSbo+FwJDz2z1IumNAh8XrHKCX+fFG0fY=; b=AdmrrmKz+V32EuTMn8O87bkXoj8+1cQdZZjbEpK3U79C/absXxYVfb8MZI3bdFaiolxL5T+072o89iYYMU+jKvQn3Y4qQ6E4glXdYpKhUqmBvCniGix5591BQtuK1PN4VpIugyRiau4oPGjjjauffAxTZeYo9lDB6HmGOgqZErc= 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=9ea9.51984048.k1305; bh=mNbZDTUIhoJSbo+FwJDz2z1IumNAh8XrHKCX+fFG0fY=; b=KvM+NLlifA/7hGCYa/dIUFGQoeCr+3g7BJOUhsA87/kZFrShB7YQd+I07hiTNwUv8LB/JZUe/U6oIJmGH1GoN3eQsi+5DgEu+NKTeA2PnI76Wv8YwFr0Ec6lmiU4J9X2ZJ6d33zdfaDJM/F0Uk9uWv5spblXg6V28sir/AFaPmM= Received: (ofmipd 127.0.0.1); 19 May 2013 03:00:02 -0000 Date: 18 May 2013 23:00:24 -0400 Message-ID: From: "John R Levine" To: "Ned Freed" In-Reply-To: <01OTSF48H616000054@mauve.mrochek.com> References: <01OTO93GD6L2000054@mauve.mrochek.com> <20130515202613.24981.qmail@joyce.lan> <01OTOENRSJ6Q000054@mauve.mrochek.com> <01OTSF48H616000054@mauve.mrochek.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-908368308-1368932424=:74365" Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-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: Sun, 19 May 2013 03:00:28 -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-908368308-1368932424=:74365 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> With it refreshed and with all the new content, I'd love to have some more >> reviews of it in its current form. Well, since you asked. I'm looking at the whole thing and I have to say I don't understand the point of sections 4 and 5. I understand that Exchange and Outlook smash messages into an internal format and sort of reconstruct the original, sometimes, but I can't tell whether that's what you're referring to or something else. I think sec 4 is trying to say mail software may have a variety of internal representations, but all we're talking about here are messages interchanged in what purports to be 5322 (or its predecessors) format. Sec 5 appears to say that if you try to parse and unparse a message, you probably won't get back quite the same thing and particularly in the presence of DKIM signatures and the like, details matter, so don't do that. If you need multiple formats, retain the original so if you need to bounce or report something, you can report what you actually received. If that's not what you mean, I'm totally confused. This is more a question for Ned: in section 7, how much legitimate mail do you still see with bare CR or LF? It is my impression that the bugs that caused those things were fixed a long time ago. I think 8.6 has TMI, I'd just say to synthesize a unique Message-ID. MSAs have been doing that for decades, people know how to do it, and your example seems more complicated than enlightening. (Why use gmtime rather than just stick the numeric value of "now" into the ID. Doesn't matter what the encoding is so long as it changes frequently.) 10.1, bottom of p. 17: MUST take? Even after downcasing the rogue 2119ism, I'd make it a lot milder than that. If I am feeding stuff into my webmail system, and I happen to know that my display module handles long lines OK, I'd just leave the long lines alone. It is my impression that long lines are much more likely to be from sloppy composition software than malicious. R's, John --3825401791-908368308-1368932424=:74365 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTE5MDMwMDI0WjAjBgkqhkiG 9w0BCQQxFgQUkXeqgEDEQv+11wdxONEJ4H9nGgkweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAscSjbTA1E7oi c8ICL9DHxonD0Af0OvHgDWKeso7rnA1ZmZZkr3ZjjoiZbONPdvcxBBbUp5jf IzV/Ds7Is94DfDbaXv8TklpABjgixeETdnnv97SuCEEmizHWa9hALNZyEPbv AFDGNqj3dcF156+fxRP/gp2//UwCOasvsgF7HoqWW8q5lJl4DTm0Cylfg4IC TQnZQgFV3f22nHyLrKcc+dq0ct3IxbBkgt1bsVBQX4ltjS0giiZKpDvaVJUF oom5mf7MYgdbCLWz9u1g/VhiA3cdD9qYFYcMi9O4fY057ujT0T93QUeuEfZd rL6v9umAW26zm3cyrWyW8gESpbLUqQ== --3825401791-908368308-1368932424=:74365-- From johnl@iecc.com Sat May 18 22:21: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 BC4EA21F8A0B for ; Sat, 18 May 2013 22:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.917 X-Spam-Level: X-Spam-Status: No, score=-110.917 tagged_above=-999 required=5 tests=[AWL=0.282, 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 2UeAV-ba9Xm9 for ; Sat, 18 May 2013 22:21:53 -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 5458521F89EB for ; Sat, 18 May 2013 22:21:53 -0700 (PDT) Received: (qmail 59722 invoked from network); 19 May 2013 05:21:38 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 19 May 2013 05:21:38 -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=51986162.xn--yuvv84g.k1305; i=johnl@user.iecc.com; bh=XRdyeOdK0sVkv92V8v9q7BThvK3JM86cY5pUEnuqOc8=; b=AAGnifs3XNpK360CayhGgnlRlzxXo3Vz22aduvArUeZ0t98BT2DB+FsEa0jRqjhIya4HE8VgCs6+yS7vzFQfcIhV/PUIxvwZ4qUALuCwAbjGW01jPZ9oKtLHS2nLmCt0ZRLfdl7QB8+9ELS34uPLv/Hrrq/wcUikhzsTBn5g5V4= 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=51986162.xn--yuvv84g.k1305; olt=johnl@user.iecc.com; bh=XRdyeOdK0sVkv92V8v9q7BThvK3JM86cY5pUEnuqOc8=; b=u4JjyGUzGKKqJ2FA81sLTkdC9YjI0V1b4ZUWvPuOirOpvkGHVpPP7oPSZDXkwIvv3kWPw+ESn/3FGgSldBGiNNUgGXm9vkNXhSsfLSLXC3fLwJj1f+4zAki1/h/2NBRl+uCIL+RObmwbl5BrSpeCYkab+HU52EXv7Jp5XcIUpfg= Date: 19 May 2013 05:21:16 -0000 Message-ID: <20130519052116.75996.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-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: Sun, 19 May 2013 05:21:57 -0000 >1) I've yet to see a single implementation that includes a version number >in its output, though there are some that do look for it. It seems to me >it's a safe change to make on that basis. Mine does, but there probably aren't five people in the world other than me using it. >version alone. Although you're correct that strictly speaking it's >incompatible, it only affects consumers regarding a currently unused >protocol feature. Hmmn. Let's say I have a mail server farm generating 5451 A-R headers and the guy down the hall has a filtering/sorting/delivering farm interpreting them. Then someone shows up with 5451bis. I am a good doobie and update my software to comply with 5451bis which, since I am only using authentication schemes described in 5451, merely involves adding /1 after the authserv-id. I hear the sound of screaming from the other end of the hall as the unexpected slash breaks the filtering. Frankly, I'd lose the slash. Whether or not it was a mistake to leave it out in the first place, adding it now only creates a gratuitous incompatibility. From superuser@gmail.com Sun May 19 07:52: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 2E2AC21F889C for ; Sun, 19 May 2013 07:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, 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 HfFlgtgKvkvg for ; Sun, 19 May 2013 07:52:20 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id BD41621F888F for ; Sun, 19 May 2013 07:52:19 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hn14so1442681wib.7 for ; Sun, 19 May 2013 07:52:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=WI3qIgSNOPWSdVAGMQqIQGx+QKT5AIfNJplbcGqsG+0=; b=aNc1RplLsGKr0B/xOjlSTJ0jeGB1kBwTU5fEt7Lai20a4riN4/mdyGdt78ljDkIdVY kazwYskrQG+vl5Vp651kpVQ1JtDMlbf2/T6PFx8o04ZY1gb1/VkOHL0fGfbaWBEgDz06 mJ0mArpyiqDPV4oOBul+WHj6ICXH9TPiputDgbgtcHt7d3rVp18MzO2PxxCc7Aj+DSwK jmnf47V5lNFQt9lHZ4VuNghVYmky/TLWZII60la6ciLAtZQ4ox8OVAbMk6oC2mwOBN3x ph7FE2Fqvcr07ATh9qFF5ytsqIR0S5cITbsxIC8LhT8fbtYl45sesGmm79ZGQG5Gzjtm WvlA== MIME-Version: 1.0 X-Received: by 10.180.210.242 with SMTP id mx18mr6071197wic.14.1368975138777; Sun, 19 May 2013 07:52:18 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Sun, 19 May 2013 07:52:18 -0700 (PDT) In-Reply-To: <20130519052116.75996.qmail@joyce.lan> References: <20130519052116.75996.qmail@joyce.lan> Date: Sun, 19 May 2013 07:52:18 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=001a11c262e8da724b04dd135c0e Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-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: Sun, 19 May 2013 14:52:21 -0000 --001a11c262e8da724b04dd135c0e Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 18, 2013 at 10:21 PM, John Levine wrote: > >version alone. Although you're correct that strictly speaking it's > >incompatible, it only affects consumers regarding a currently unused > >protocol feature. > > Hmmn. Let's say I have a mail server farm generating 5451 A-R headers > and the guy down the hall has a filtering/sorting/delivering farm > interpreting them. Then someone shows up with 5451bis. I am a good > doobie and update my software to comply with 5451bis which, since I am > only using authentication schemes described in 5451, merely involves > adding /1 after the authserv-id. I hear the sound of screaming from > the other end of the hall as the unexpected slash breaks the > filtering. > You don't have to change anything in a generator to remain compliant. The "/1" is optional if the version number isn't actually changing. -MSK --001a11c262e8da724b04dd135c0e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, May 18, 2013 at 10:21 PM, John Levine <johnl@taugh.= com> wrote:
>version alone. =A0Although you're correct that strictly speaking it= 's
>incompatible, it only affects consumers regarding a currently unused >protocol feature.

Hmmn. =A0Let's say I have a mail server farm generating 5451 A-R = headers
and the guy down the hall has a filtering/sorting/delivering farm
interpreting them. =A0Then someone shows up with 5451bis. I am a good
doobie and update my software to comply with 5451bis which, since I am
only using authentication schemes described in 5451, merely involves
adding /1 after the authserv-id. =A0I hear the sound of screaming from
the other end of the hall as the unexpected slash breaks the
filtering.

You don't have to change= anything in a generator to remain compliant.=A0 The "/1" is opti= onal if the version number isn't actually changing.

-MSK

--001a11c262e8da724b04dd135c0e-- From johnl@taugh.com Sun May 19 08:09:28 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C6B21F89D5 for ; Sun, 19 May 2013 08:09:28 -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 CCo87x2MCS7U for ; Sun, 19 May 2013 08:09:27 -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 6D7B121F898B for ; Sun, 19 May 2013 08:09:27 -0700 (PDT) Received: (qmail 73647 invoked from network); 19 May 2013 15:09:26 -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=11fae.5198eb26.k1305; bh=SHRJjTQrgswaPzf9aFKSsz4xUXgffh61cECALrXVOP0=; b=AoppoeBJQVeG8bnoxz6cVOP56FW4hEUqSJKf+sLHLGvrne3ADmraXJXeZeEnxq7kAlLuCSRM7r3++0/K5o38wcdprlF/nbisuNHakpYYd05LHSKrmDVJfP02VX/RlsMp5W/X5T6D7QnHGMbckgFoBMrEpkFvokx59QkmOJBj/0U= 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=11fae.5198eb26.k1305; bh=SHRJjTQrgswaPzf9aFKSsz4xUXgffh61cECALrXVOP0=; b=sKl0Q4TUZWIqKeqHnEG6BK7C5TQ48a8/tdrxvBp31zKlzh8FI+a97U0bi3w7XVwZ+DlZojK42DeH8lrGLSobiKyTgA4D3z9U9jPlM10jkO/ijkOwLFHMvPU5Wz10ZCMR6fYQXnl512E3axTWhX/AzwJairSG757r/C0/zr9292w= Received: (ofmipd 127.0.0.1); 19 May 2013 15:09:04 -0000 Date: 19 May 2013 11:09:26 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20130519052116.75996.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-2084301205-1368976166=:85717" Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-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: Sun, 19 May 2013 15:09:28 -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-2084301205-1368976166=:85717 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII >> adding /1 after the authserv-id. I hear the sound of screaming from >> the other end of the hall as the unexpected slash breaks the >> filtering. > > You don't have to change anything in a generator to remain compliant. The > "/1" is optional if the version number isn't actually changing. Right, but if I do add the /1, consumers that haven't upgraded will break even though nothing substantive has changed. If there were something substantively different between 5451 and bis, so that consumers had to change to consume something other than the version number, I would probably be OK with the slash. But in this case, the slash doesn't solve any problem I can see, and is likely to cause some interop issues. R's, John --3825401791-2084301205-1368976166=:85717 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTE5MTUwOTI2WjAjBgkqhkiG 9w0BCQQxFgQUn+ttj3h33agIznqWU9Sbzs77K0wweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEABBNcZ0UP1Umo QSDKeZPak0WMN6GhLeGf9NJ0YjkPJl+RI/R12p1K6RyN+KPXqJSO3hNjx3Fa K3kD15a7yPsIuFsqpDaVynvs8NAF8S0eQDcDi0tj4b80gnCUPr1+EEvrhRA0 YV3tWkXtmd+5qUMyMcfQHeKuWggJqv1gW9NkAOieETF9/Z6oAC/gXTlSHO69 UxFB4YEtwMtdmHL96R1ynpOGntqXsagMeIssNyRGypx7JRMEPV9E8ab5bUgF tVJxxIs8GXdk9mCbaH3P9GMpHxsqycZQzWcuNjGbYQYpdkcMG0c0gXggISjA HqSnXFQWvtv6gCVUcs3cuNk+7TJCug== --3825401791-2084301205-1368976166=:85717-- From ned.freed@mrochek.com Sun May 19 14:34: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 3207D21F8E6E for ; Sun, 19 May 2013 14:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 xJJeEs0ptUXg for ; Sun, 19 May 2013 14:34:28 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1982921F8E84 for ; Sun, 19 May 2013 14:34:28 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OTU1EPTYZ4006JBH@mauve.mrochek.com> for apps-discuss@ietf.org; Sun, 19 May 2013 14:29: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 <01OTLPL3VY1C000054@mauve.mrochek.com>; Sun, 19 May 2013 14:29:16 -0700 (PDT) Message-id: <01OTU1ENPZX4000054@mauve.mrochek.com> Date: Sun, 19 May 2013 14:24:58 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 18 May 2013 23:00:24 -0400" References: <01OTO93GD6L2000054@mauve.mrochek.com> <20130515202613.24981.qmail@joyce.lan> <01OTOENRSJ6Q000054@mauve.mrochek.com> <01OTSF48H616000054@mauve.mrochek.com> To: John R Levine Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-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: Sun, 19 May 2013 21:34:33 -0000 > This is more a question for Ned: in section 7, how much legitimate mail do > you still see with bare CR or LF? It is my impression that the bugs that > caused those things were fixed a long time ago. Still see bare LFs occasionally. Bare CRs seem to have vanished along with the use of MacOS versions prior to X, which AFAIK is the only platform of any significance at all that ever used bare CR as a line terminator. I considered recommending treating bare CR like null, but I can't see that it matters all that much. Ned From James.H.Manger@team.telstra.com Sun May 19 17:14: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 917F721F8C20 for ; Sun, 19 May 2013 17:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.251 X-Spam-Level: X-Spam-Status: No, score=-0.251 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w97hoQfQvnDZ for ; Sun, 19 May 2013 17:14:54 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8169821F89A6 for ; Sun, 19 May 2013 17:14:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,704,1363093200"; d="scan'208";a="136049148" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 20 May 2013 10:14:50 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7080"; a="132976345" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipccvi.tcif.telstra.com.au with ESMTP; 20 May 2013 10:14:50 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Mon, 20 May 2013 10:14:50 +1000 From: "Manger, James H" To: Steve Klabnik , "apps-discuss@ietf.org" Date: Mon, 20 May 2013 10:14:49 +1000 Thread-Topic: [apps-discuss] draft-snell-merge-patch-08 in Ruby Thread-Index: Ac5UAhFIXJcSYseqTVCf4MFuV19C6wA5j60g Message-ID: <255B9BB34FB7D647A506DC292726F6E1151A34C59E@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [apps-discuss] draft-snell-merge-patch-08 in Ruby X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 May 2013 00:14:59 -0000 U3RldmUsDQoNCkl0IGlzIGdvb2QgdG8gaGVhciBhYm91dCBhIFJ1YnkganNvbi1tZXJnZS1wYXRj aC4gVGhlcmUgYXJlIGEgY291cGxlIG9mIGNhc2VzIHdoZXJlIEkgdGhpbmsgZHJhZnQtc25lbGwt bWVyZ2UtcGF0Y2ggZ2V0cyBpdCB3cm9uZywgZXhhbXBsZSBvZiB3aGljaCBhcmUgdGFidWxhdGVk IGF0IGh0dHA6Ly9pZC5jdG8udGVsc3RyYS5jb20vanNvbi9tZXJnZS5odG1sLiBJIHdvdWxkIGJl IGludGVyZXN0ZWQgdG8ga25vdyB3aGF0IHlvdXIgaW1wbGVtZW50YXRpb24gZG9lcyBpbiB0aGVz ZSBjYXNlcz8NCg0KRG9jdW1lbnQgKyBwYXRjaCA9ID8NCg0KWzEsMl0gICsgIHsiYSI6ImZvbyIs ImIiOm51bGx9DQoNCnsiYSI6ImZvbyJ9ICArICB7ImIiOlszLG51bGwseyJ4IjpudWxsfV19DQoN CnsiYSI6ImZvbyJ9ICArICBudWxsDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0KPiAtLS0tLS0tLS0t DQo+IEZyb206IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXBwcy1kaXNj dXNzLQ0KPiBib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3RldmUgS2xhYm5paw0KPiBT ZW50OiBTdW5kYXksIDE5IE1heSAyMDEzIDU6NTggQU0NCj4gDQo+IEhleSB0aGVyZSENCj4gDQo+ IEphbWVzIHN1Z2dlc3RlZCB0aGF0IEkgcG9zdCB0byB0aGlzIGxpc3QsIHNvIGhlcmUgSSBhbS4N Cj4gDQo+IEknbSBhIGNvbW1pdHRlciB0byBSdWJ5IG9uIFJhaWxzLCBhbmQgUmFpbHMgNCBpcyBu ZWFyIGEgcmVsZWFzZS4gT25lDQo+IG9mIHRoZSBjaGFuZ2VzIGluIFJhaWxzIDQgaXMgdGhlIHVz YWdlIG9mIFBBVENILCB3aGljaCBtZWFucyBJJ20NCj4gY2hlY2tpbmcgdXAgb24gdmFyaW91cyBk aWZmIG1lZGlhIHR5cGVzLiBNYXJrIE5vdHRpbmdoYW0gYnJvdWdodCBteQ0KPiBhdHRlbnRpb24g dG8gZHJhZnQtc25lbGwtbWVyZ2UtcGF0Y2ggYXMgYSBzaW1wbGVyIHZhcmlhbnQgb2YNCj4ganNv bi1wYXRjaC4NCj4gDQo+IEFueXdheSwgSSBoYXZlIGEgX21vc3RseV8gd29ya2luZyBpbXBsZW1l bnRhdGlvbiBvZiB0aGUgbGF0ZXN0IGRyYWZ0DQo+IGFzIGEgZ2VtLCBoZXJlOiBodHRwczovL2dp dGh1Yi5jb20vc3RldmVrbGFibmlrL2pzb24tbWVyZ2VfcGF0Y2ggLg0KPiBJdCdzIG9ubHkgbWlz c2luZyB0aGUgIlJlY3Vyc2l2ZWx5IGFwcGx5IHJ1bGUgMiIgcG9ydGlvbi4gSG9wZWZ1bGx5DQo+ IEknbGwgYmUgZmluaXNoaW5nIGl0IG9mZiBzb29uLg0KPiANCj4gSSdkIHNheSB0aGF0IG92ZXJh bGwgdGhpcyBkcmFmdCB3YXMgc3VwZXIgc2ltcGxlIHRvIGltcGxlbWVudCwNCj4gZXNwZWNpYWxs eSBnaXZlbiBSdWJ5J3MgKGxpa2UgbWFueSBzY3JpcHRpbmcgbGFuZ3VhZ2VzKSBlYXNlIG9mDQo+ IG1hcHBpbmcgSlNPTiBkaXJlY3RseSB0byBpdHMgcmljaCBIYXNoIGFuZCBBcnJheSB0eXBlcyBp biB0aGUgbGFuZ3VhZ2UNCj4gY29yZS4NCj4gDQo+IEkgbWF5IGhhdmUgb25lIG9yIHR3byB0aG91 Z2h0cyBvbiB0aGUgbGFuZ3VhZ2Ugb2YgdGhlIHNwZWMsIGJ1dCBJIG5lZWQNCj4gdG8gcmUtcmVh ZCBpdCBhbmQgdGFrZSBzb21lIG5vdGVzIHRoaXMgdGltZSBhcm91bmQuDQo= From steve@steveklabnik.com Sun May 19 18:34:27 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB3921F8EA6 for ; Sun, 19 May 2013 18:34:27 -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 WP823Tc0EOlk for ; Sun, 19 May 2013 18:34:26 -0700 (PDT) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id F2E5C21F8EA4 for ; Sun, 19 May 2013 18:34:25 -0700 (PDT) Received: by mail-ia0-f169.google.com with SMTP id k38so7033019iah.14 for ; Sun, 19 May 2013 18:34:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=vB4lLm3HdgBOc9Fa+0wss9wWmUvnbiu7j2+I6VKt38E=; b=Lxrd1XwCvO6neYPUlSTUMMXjxrDRJQHpXLN0+PkX5gz/8gfiq0XupCK96EwFEzehtc tGNKH0qq5YdJUKnFKWYLOHV/doFk60inTQAEbbwOjWN5KVzPPSlFc6g85XcC7IZJmJVT k1W1jNlmlPCLxgU5h5+tElj2mg28NeOPE8HnwV+ITiWreeUpPl0FecixE5LzJEwbaxMN AP5rfVXpM0TGrp8pgRCNWwjFjjDbF+75RJHimWd428863VzlDZpbUz39FkadJSprfAgD DymzH9HqNOrIV4L6OSP9tQEYazvM7W+u0cPrUmvkwEAsLbbZL1HmxoWtB0Ch3pjEorlQ V2Ag== MIME-Version: 1.0 X-Received: by 10.50.108.17 with SMTP id hg17mr3950949igb.57.1369013665318; Sun, 19 May 2013 18:34:25 -0700 (PDT) Received: by 10.64.163.3 with HTTP; Sun, 19 May 2013 18:34:25 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151A34C59E@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1151A34C59E@WSMSG3153V.srv.dir.telstra.com> Date: Sun, 19 May 2013 18:34:25 -0700 Message-ID: From: Steve Klabnik To: "Manger, James H" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnVuRRy3fivhiYgjkFJZTlEvjc+dKDmvSEg7ZLM5SZ0IJquDjas+Za6l9WkEEPTwMXpz9jG Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-snell-merge-patch-08 in Ruby X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 May 2013 01:34:27 -0000 As of the 1.1 release I did: irb(main):001:0> require 'json/merge_patch' => true irb(main):002:0> JSON.merge(%q'[1,2]', %q'{"a":"foo","b":null}') => "{\"a\":\"foo\"}" irb(main):003:0> JSON.merge(%q'{"a":"foo"}', %q'{"b":[3,null,{"x":null}]}') => "{\"a\":\"foo\",\"b\":[3,{\"x\":null}]}" irb(main):004:0> JSON.merge(%q'{"a":"foo"}', %q'null') JSON::MergeError: JSON::MergeError from /Users/steve/.gem/ruby/2.0.0/gems/json-merge_patch-1.1.0/lib/json/merge_patch.rb:20:in `rescue in merge' from /Users/steve/.gem/ruby/2.0.0/gems/json-merge_patch-1.1.0/lib/json/merge_patch.rb:16:in `merge' from (irb):4 from /opt/rubies/2.0.0-p0/bin/irb:12:in `
' 'null' isn't valid JSON, right? That'd account for your second discrepancy. You can play around with the 1.1 version here, if you don't want to bother getting Ruby installed: http://json-merge-patch.herokuapp.com/ You can see the translation I did directly to Ruby in this commit: https://github.com/steveklabnik/json-merge_patch/commit/e70f762375b2928ca86c269354563da58af1e005 I've since done some refactoring. The initial direct translation failed some of my unit tests. I think that this was one of the bigger issues: else if (patch instanceof Array) orig = purge_nulls(patch); else if (is_primitive(patch)) orig = patch; Reading the spec: If either the root of the JSON data provided in the payload or the root of the target resource are JSON Arrays, the target resource is to be replaced, in whole, by the provided data. Therefore, I think it should be this: else if (patch instanceof Array || orig instanceof Array) orig = purge_nulls(patch); else if (is_primitive(patch) or is_primitive(orig)) orig = patch; I believe this accounts for your first discrepancy. There's also a few lines that I'm not sure are reachable. Check the git history for more details. From James.H.Manger@team.telstra.com Sun May 19 20:26:43 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B10C21F8F20 for ; Sun, 19 May 2013 20:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.168 X-Spam-Level: X-Spam-Status: No, score=-0.168 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_44=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6fLW1R7fzdc for ; Sun, 19 May 2013 20:26:38 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 5088021F8F1E for ; Sun, 19 May 2013 20:26:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,704,1363093200"; d="scan'208";a="129802207" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 20 May 2013 13:26:37 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7080"; a="134496971" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipcbni.tcif.telstra.com.au with ESMTP; 20 May 2013 13:26:37 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Mon, 20 May 2013 13:26:37 +1000 From: "Manger, James H" To: Steve Klabnik Date: Mon, 20 May 2013 13:26:35 +1000 Thread-Topic: [apps-discuss] draft-snell-merge-patch-08 in Ruby Thread-Index: Ac5U+jC5wL2OOHoLTZS5ZfKURj2hlQACOghg Message-ID: <255B9BB34FB7D647A506DC292726F6E1151A56E41B@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1151A34C59E@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-snell-merge-patch-08 in Ruby X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 May 2013 03:26:43 -0000 PiAnbnVsbCcgaXNuJ3QgdmFsaWQgSlNPTiwgcmlnaHQ/IFRoYXQnZCBhY2NvdW50IGZvciB5b3Vy IHNlY29uZA0KPiBkaXNjcmVwYW5jeS4NCg0KJ251bGwnIGlzIGEgdmFsaWQgSlNPTiB2YWx1ZS4N CkphdmFTY3JpcHQgd2lsbCBoYXBwaWx5IGFjY2VwdCBKU09OLnBhcnNlKCdudWxsJykuDQpSRkM0 NjI3ICJKU09OIiBsaW1pdHMgYXBwbGljYXRpb24vanNvbiBjb250ZW50IHRvIGJlIGFuIG9iamVj dCBvciBhcnJheSwgYnV0IG15IGd1ZXNzIGlzIHRoYXQgdGhhdCB3aWxsIGJlIHJlbGF4ZWQgdG8g YWxsb3cgYW55IEpTT04gdmFsdWUgc2hvcnRseS4NCg0KDQo+IFlvdSBjYW4gcGxheSBhcm91bmQg d2l0aCB0aGUgMS4xIHZlcnNpb24gaGVyZSwgaWYgeW91IGRvbid0IHdhbnQgdG8NCj4gYm90aGVy IGdldHRpbmcgUnVieSBpbnN0YWxsZWQ6IGh0dHA6Ly9qc29uLW1lcmdlLXBhdGNoLmhlcm9rdWFw cC5jb20vDQoNClByZXN1bWFibHkgdGhlIGlkZWEgb2YgdGhpcyBzaXRlIHdhcyB0byByZXR1cm4g dGhlIHJlc3VsdCBvZiB0aGUgbWVyZ2UtcGF0Y2guIEF0IHRoZSBtb21lbnQgaXQgaXMganVzdCBl Y2hvaW5nIHRoZSBwYXRjaC4NCg0KDQo+IGh0dHBzOi8vZ2l0aHViLmNvbS9zdGV2ZWtsYWJuaWsv anNvbi1tZXJnZV9wYXRjaC9ibG9iL21hc3Rlci9saWIvanNvbi9tZXJnZV9wYXRjaC5yYg0KDQpU aGUgbGF0ZXN0IGNoYW5nZXMgdG8gbWVyZ2VfcGF0Y2gucmIgZG9uJ3QgbG9vayByaWdodC4NCg0K V2h5IGJvdGggcmVtb3ZpbmcgYXJyYXkgZWxlbWVudHMgdGhhdCBhcmUgbnVsbCAob2JqLmNvbXBh Y3QpPyBBcnJheXMgaW4gbWVyZ2UtcGF0Y2ggYXJlIGVmZmVjdGl2ZWx5IHByaW1pdGl2ZSAobGlr ZSB0cnVlLCBmYWxzZSwgbnVtYmVyLCBzdHJpbmcpLiBUaGVyZSBpcyBubyByZWFzb24gZm9yIHRo ZSBtZXJnZSBmdW5jdGlvbmFsaXR5IHRvIGxvb2sgaW5zaWRlIGFuIGFycmF5Lg0KDQpBIG5hbWU6 bnVsbCBlbGVtZW50ICppbiBhIHBhdGNoKiBtZWFuIGRlbGV0ZSB0aGUgbmFtZSBmaWVsZCBpbiB0 aGUgZG9jdW1lbnQuIFN1Y2ggYSBmaWVsZCAqaW4gYSBkb2N1bWVudCosIGhvd2V2ZXIsIGlzIGZp bmUuIFlvdSBzaG91bGRuJ3QgZGVsZXRlIGEgZmllbGQgZnJvbSBhIGRvY3VtZW50IHRoYXQgaXNu J3QgbWVudGlvbmVkIGluIHRoZSBwYXRjaCAtLSByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90 IHRoZSBkb2N1bWVudCBmaWVsZCdzIHZhbHVlIGlzIG51bGwuDQoNCg0KLS0NCkphbWVzIE1hbmdl cg0K From steve@steveklabnik.com Sun May 19 21:00: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 4681021F8F62 for ; Sun, 19 May 2013 21:00:15 -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 TbT+Fo0L+NEa for ; Sun, 19 May 2013 21:00:14 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B9D1621F8749 for ; Sun, 19 May 2013 21:00:14 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id k5so12999386iea.18 for ; Sun, 19 May 2013 21:00:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ApMe1KZrubK+pPP37JI7Vxg2TiOWAiqvXvVs8XCpIJ0=; b=ApKUT4//MHUMZZcuH4fqwA5AT9O11WjzlN5lRSqJWun6AbEiyqFV2YB3uf6i6aV08O 3c0nBTDFhOCNIW4NnmqVxnqywYYi/fzGIjs5ym+G4SIxClU0qPeF1Z9qimO39lINCwL4 xcv+MaiUHtwj5QkkLqrpPNOIILeQRUc38/q9shenEgGR5pi86xLUpffxLFfHnnHtkmNF NbT7PA8031VkqeddIVBu2OwHbyKyl0gi2n7vNa+q/HmyFHACKDAkkFXFUT6Tx1BkwNBN LhEgROzVNV9gEiiDF9UCAHbZUegS72ezapddvVRWq4jNOW/AcySUsUfo+zz7FE8Xw0tQ bc5g== MIME-Version: 1.0 X-Received: by 10.50.25.2 with SMTP id y2mr4038835igf.86.1369022414170; Sun, 19 May 2013 21:00:14 -0700 (PDT) Received: by 10.64.163.3 with HTTP; Sun, 19 May 2013 21:00:14 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151A56E41B@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1151A34C59E@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1151A56E41B@WSMSG3153V.srv.dir.telstra.com> Date: Sun, 19 May 2013 21:00:14 -0700 Message-ID: From: Steve Klabnik To: "Manger, James H" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlkL72E0XnJXw3ztGyWhRT5nuAXySeBvITjFbrSmMImZPJRJPKrYEb+w0wx42LmYFnF813K Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-snell-merge-patch-08 in Ruby X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 May 2013 04:00:15 -0000 > 'null' is a valid JSON value. Bummer: (main):001:0> require 'json' => true irb(main):002:0> JSON.parse("null") JSON::ParserError: 757: unexpected token at 'null' from /Users/steve/.gem/ruby/2.0.0/gems/json-1.8.0/lib/json/common.rb:155:in `parse' from /Users/steve/.gem/ruby/2.0.0/gems/json-1.8.0/lib/json/common.rb:155:in `parse' from (irb):2 from /opt/rubies/2.0.0-p0/bin/irb:12:in `
' > JavaScript will happily accept JSON.parse('null'). > RFC4627 "JSON" limits application/json content to be an object or array, but my guess is that that will be relaxed to allow any JSON value shortly. Ahhh, there we go. So it's not a valid JSON value. ;) > Presumably the idea of this site was to return the result of the merge-patch. At the moment it is just echoing the patch. Uh oh, that's a bummer. I'll look into that. > Why both removing array elements that are null (obj.compact)? I took that to be what this meant: Any object member contained in the provided data whose value is explicitly null is to be treated as if the member was undefined. Since 'null' means 'remove' as the value of a key, I just assumed all nulls should be removed. I did find this sentence (which is everywhere) a tad bit confusing. This could be me mis-reading things. From sm@elandsys.com Mon May 20 00:15: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 273F521F8A0C for ; Mon, 20 May 2013 00:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.333 X-Spam-Level: X-Spam-Status: No, score=-102.333 tagged_above=-999 required=5 tests=[AWL=0.266, 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 SXczt4Bmeyyk for ; Mon, 20 May 2013 00:14:56 -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 BC3BD21F90AC for ; Mon, 20 May 2013 00:14:55 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.135.2]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4K7Eamg022930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 May 2013 00:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1369034090; bh=FWZYukQtOHGUr1oj4mj+83nNsUGLxUkAKKd+W5WxRdg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=H+KJz8sfWmG6XkMdM/EFKYH8JAywEB27gsANcH12n8HyWw3w9QUCwi9JClQ46/E+c rYguooxbtlewXdtYqT7AqESSpHVluV7q7QXgDxnpvoE1RFioQXZMv/cvWGdOSxi2Ig XDVgvvxyb1jBhnoNxIs6Lo40rBCijTzgKdNoGGxs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1369034090; i=@elandsys.com; bh=FWZYukQtOHGUr1oj4mj+83nNsUGLxUkAKKd+W5WxRdg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=G3e9/mbLrK/nEKHxvdjVeCKAEx7Z4BxDD8RtREwR9BtpL10mZNYY2ZEm0krYwhVJU RWu7aM8m0dPDA10h3UJ/TXGsIf0F8SJ84f38MLMFCgf34Uao0IUHWhK5BER6xBZsDK gwlFpeXap64Rp02xOMXLIB6WveUzqKfmGyC9OwnM= Message-Id: <6.2.5.6.2.20130519232054.06b2a318@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 20 May 2013 00:14:06 -0700 To: Alexey Melnikov From: S Moonesamy In-Reply-To: References: <20130519052116.75996.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: [apps-discuss] Slash and version number in Authentication-results: header field (was: I-D Action: draft-ietf-appsawg-rfc5451bis-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: Mon, 20 May 2013 07:15:02 -0000 Hi Alexey, Scott Kitterman mentioned [1] that the following: authres-header = "Authentication-Results:" [CFWS] authserv-id [ [CFWS] "/" [CFWS] authres-version ] 'is an incompatible change and if you really want to make it, you should bump the version number. I checked and with authres, your example is mis-parsed. Authentication-Results: example.org/1; none In this example, the authserv-id is "example.org", but authres, using the RFC 5451 ABNF parses this and determines the authserv-id is "example.org/1"' Murray Kucherawy commented that he has "yet to see a single implementation that includes a version number in its output, though there are some that do look for it" [2]. John Levine responded that his implementation does [3]. He also mentioned that the introduction of the slash (see ABNF) creates an incompatibility. There is also the following in Section 5 of draft-ietf-appsawg-rfc5451bis-02: "An MTA SHOULD remove any instance of this header field bearing a version (express or implied) that it does not support." Will the addition of the slash cause an interoperability issue? Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09460.html 2. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09463.html 3. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09465.html From superuser@gmail.com Mon May 20 00:49: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 19D0A21F8521; Mon, 20 May 2013 00:49:04 -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 MtDf+ZAGASyT; Mon, 20 May 2013 00:49:03 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id D358821F8539; Mon, 20 May 2013 00:49:00 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so147608wgg.28 for ; Mon, 20 May 2013 00:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=K1CmhgR3+bvA9Xh/jX/rjRpsv+IkUEroBD+5PtQo/LM=; b=ecwP5Z12luTuTbnkFVcO+PA8EjxpLs7v+lmBb0IEpYk/Du0pEXZxj5coBKgrY89aG3 mOy0m0+/5dvTvSfnkAmDqUUDrxRK2gvKycAXD+yGaus2QEtRxRBw2M3UQ28noixq6jZV AE2ZIpivaV9XM3jfL+FRkCYnjioGIY3liBhXmNzp3T+8/lEJA9esBOabu4yoH4ySMLz5 lqoDhIFQZMxy3p/JG/UVZT+N60vtQTT3nuWlUnEtjVkUhyv9HfXnmcYNt9IKy03CjEzZ vir68mpdFnjprzbotCzqZDUGrqj8CzN6VsBNVP/UzYHFTU1u4fOS5uBAJLmdHZw381FG GrYg== MIME-Version: 1.0 X-Received: by 10.180.210.242 with SMTP id mx18mr11069821wic.14.1369036139666; Mon, 20 May 2013 00:48:59 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Mon, 20 May 2013 00:48:59 -0700 (PDT) In-Reply-To: <9E5D5870D2E1345B7ABA6971@cyrus.local> References: <9E5D5870D2E1345B7ABA6971@cyrus.local> Date: Mon, 20 May 2013 00:48:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: Cyrus Daboo , "spfbis@ietf.org" Content-Type: multipart/alternative; boundary=001a11c262e8ca24bb04dd21909d Cc: The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-spfbis-4408bis-14.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, 20 May 2013 07:49:05 -0000 --001a11c262e8ca24bb04dd21909d Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 29, 2013 at 6:50 AM, Cyrus Daboo wrote: > Nits: > Section 2.6 and Section 8 appear to duplicate a lot of similar > information. Please consider trimming down Section 2.6 and have it refer to > Section 8 for full details. > > > Hi Cyrus, There is a little duplication in there that I'm attempting to help the editor to reduce to a minimum. It's intentional, however, because the WG concluded it was necessary to separate the list of possible SPF results from any kind of normative statements (or even inference) about what an operator should do with one of those results. Thus, 2.6 lists protocol elements, and 8 is basically some operational discussion. I may also say the above in a more condensed form just so it's clear why the apparent duplication exists. Thanks for the review, -MSK --001a11c262e8ca24bb04dd21909d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 29, 2013 at 6:50 AM, Cyrus Daboo <cyrus@daboo.= name> wrote:
Nits:
=A0 =A0 =A0 =A0 Section 2.6 and Section 8 appear to duplicate a lot of simi= lar information. Please consider trimming down Section 2.6 and have it refe= r to Section 8 for full details.



Hi Cyrus,

There is a = little duplication in there that I'm attempting to help the editor to r= educe to a minimum.=A0 It's intentional, however, because the WG conclu= ded it was necessary to separate the list of possible SPF results from any = kind of normative statements (or even inference) about what an operator sho= uld do with one of those results.=A0 Thus, 2.6 lists protocol elements, and= 8 is basically some operational discussion.

I may also say the above in a more con= densed form just so it's clear why the apparent duplication exists.
=
Thanks for the review,

-MSK
--001a11c262e8ca24bb04dd21909d-- From scott@kitterman.com Mon May 20 01:45:23 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9507421F92EC for ; Mon, 20 May 2013 01:45: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 8+SITN3RLCbO for ; Mon, 20 May 2013 01:44:36 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1043221F92BB for ; Mon, 20 May 2013 01:05:20 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 28A4820E40D2; Mon, 20 May 2013 04:04:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1369037077; bh=H77w6Ty+VvbTcoyjeZhEFyr0a9Ue4mIMYwobLo535CI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=GpFRbPIbLaXUtNDMC+cbTe7gR8LjwQQwDZ4t/m1tnr2rcdhbK5PCd8gBzhy7TJt/V 3ycYqDWu4dRZij2YShVdgUGdv0J5TSdeNnBCNiLejGR/4rDgt+NTb4pGb+m8wKmu81 5ftlZEyQIMTfYIlBTN/jale3jfW3w7/GHkORd5wE= 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 0D41E20E40CF; Mon, 20 May 2013 04:04:36 -0400 (EDT) From: Scott Kitterman To: apps-discuss@ietf.org Date: Mon, 20 May 2013 04:04:36 -0400 Message-ID: <1839863.GGbvcjnLQZ@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <6.2.5.6.2.20130519232054.06b2a318@resistor.net> References: <6.2.5.6.2.20130519232054.06b2a318@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [apps-discuss] Slash and version number in Authentication-results: header field (was: I-D Action: draft-ietf-appsawg-rfc5451bis-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: Mon, 20 May 2013 08:45:37 -0000 On Monday, May 20, 2013 12:14:06 AM S Moonesamy wrote: > Hi Alexey, > > Scott Kitterman mentioned [1] that the following: > > authres-header = "Authentication-Results:" [CFWS] authserv-id > [ [CFWS] "/" [CFWS] authres-version ] > > 'is an incompatible change and if you really want to make it, you should > bump the version number. I checked and with authres, your example is > mis-parsed. > > Authentication-Results: example.org/1; none > > In this example, the authserv-id is "example.org", but authres, using the > RFC 5451 ABNF parses this and determines the authserv-id is > "example.org/1"' > > Murray Kucherawy commented that he has "yet to see a single > implementation that includes a version number in its output, though > there are some that do look for it" [2]. John Levine responded that > his implementation does [3]. He also mentioned that the introduction > of the slash (see ABNF) creates an incompatibility. > > There is also the following in Section 5 of > draft-ietf-appsawg-rfc5451bis-02: > > "An MTA SHOULD remove any instance of this header field bearing a > version (express or implied) that it does not support." > > Will the addition of the slash cause an interoperability issue? > > Regards, > S. Moonesamy > > 1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09460.html > 2. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09463.html > 3. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09465.html If an implementation based on 5451 receives a future 5451bis header field with an authserv-id of example.com and a version number of 2, it would read that as an authserv-id of example.com/2 and an implicit version number of 1. Both getting the version number wrong and the authserv-id wrong could have interoperability implications. Scott K From internet-drafts@ietf.org Mon May 20 09:30:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D1F21F9590; Mon, 20 May 2013 09:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.132, 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 c3VK43yAyHY0; Mon, 20 May 2013 09:30:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 173FD21F95C3; Mon, 20 May 2013 09:30:55 -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.45 Message-ID: <20130520163055.10688.24242.idtracker@ietfa.amsl.com> Date: Mon, 20 May 2013 09:30:55 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 16:30:56 -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 : Message Header Field for Indicating Message Authenticati= on Status Author(s) : Murray S. Kucherawy Filename : draft-ietf-appsawg-rfc5451bis-03.txt Pages : 42 Date : 2013-05-20 Abstract: This document specifies a header field for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users, or make sorting and filtering decisions. This document is a candidate for Internet Standard status. [RFC Editor: Please delete this notation, as I imagine it will be indicated some other way.] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-rfc5451bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-rfc5451bis-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From superuser@gmail.com Mon May 20 09:31: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 0E0A321F9590; Mon, 20 May 2013 09:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 KqOMWREWR3W5; Mon, 20 May 2013 09:31:54 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 51BAC21F92FC; Mon, 20 May 2013 09:31:46 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id x12so5099237wgg.33 for ; Mon, 20 May 2013 09:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=QtX7L7bwpvg7rx9DphjdKp8FZciAVcVAwuFSmJNQCbw=; b=Gfp+NJ5Y6Qe4AqFPjEVI2U098r/xhC62ZnrBZDcR5ssFbGfIFvh97DI8S+nuM7Ssr5 S0zcIFXurm+XTCUE0n49zvmEUeeBdRrk1CZX+vSJ6vTCUNaJKKGjugJz/vwDvkQDB670 8ImrU7rTnko2tH49rzfC035HEesPzYtlkPiBLJwln+30jpkhQT2Gh8Ga+C5AFYOTqQhv /NBHFZ5NGGGjPT27bZPMrz9s9UebFBqnTIeSwGDVjAF2QtgGtr2iRwIHzNTfMw2bWlhq VeBTCqkLUv7biB4bOjbvS9OsvUlOe7rYQRxxepZlZumra3u2EP2AnGsFaMl3x8x5gudJ BL2w== MIME-Version: 1.0 X-Received: by 10.180.37.133 with SMTP id y5mr15304687wij.20.1369067505432; Mon, 20 May 2013 09:31:45 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Mon, 20 May 2013 09:31:45 -0700 (PDT) In-Reply-To: <20130520163055.10688.24242.idtracker@ietfa.amsl.com> References: <20130520163055.10688.24242.idtracker@ietfa.amsl.com> Date: Mon, 20 May 2013 09:31:45 -0700 Message-ID: From: "Murray S. Kucherawy" To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=e89a8f50335a55c34104dd28de2a Cc: IETF Apps Discuss , i-d-announce@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 16:31:55 -0000 --e89a8f50335a55c34104dd28de2a Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 20, 2013 at 9:30 AM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Applications Area Working Group Working > Group of the IETF. > > Title : Message Header Field for Indicating Message > Authentication Status > Author(s) : Murray S. Kucherawy > Filename : draft-ietf-appsawg-rfc5451bis-03.txt > Pages : 42 > Date : 2013-05-20 > This incorporates the last of the WGLC feedback, including reverting the ABNF change that introduced a backward compatibility issue. -MSK --e89a8f50335a55c34104dd28de2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, May 20, 2013 at 9:30 AM, <internet-drafts= @ietf.org> wrote:
A New Internet-Draft is available from the o= n-line Internet-Drafts directories.
=A0This draft is a work item of the Applications Area Working Group Working= Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Message Header Field for Indica= ting Message Authentication Status
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Murray S. Kucherawy
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-rfc5451bis-03.= txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 42
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-05-20

This incorporates the last of the WGLC feedback, includin= g reverting the ABNF change that introduced a backward compatibility issue.=

-MSK
--e89a8f50335a55c34104dd28de2a-- From jasnell@gmail.com Mon May 20 09:38: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 014F321F93BC for ; Mon, 20 May 2013 09:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.607 X-Spam-Level: X-Spam-Status: No, score=-6.607 tagged_above=-999 required=5 tests=[AWL=-3.008, 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 OJkA+vw3FRwc for ; Mon, 20 May 2013 09:38:25 -0700 (PDT) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id CDB6521F937E for ; Mon, 20 May 2013 09:38:25 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id i4so7908939oah.21 for ; Mon, 20 May 2013 09:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=GYa0nqxgCYAaB28vKFH3DJTy58DuhbpCFa/J7dfJdrg=; b=B485nnLVH8y/qhYPUnBVm1VBPw1MHtjYqFqqxW5l2mpvyFFeALQ3XCMo0ALmdSizbs ZYn6epd3IMrl+TO0wEBgYksx2zddAmUd07817zWDkoEFifIQJ33y/pVNYdLAchEwMmnG 05YBZ+9gutR1XgDJEod6gx4NkK+07H9mn+nGQjPReRzc5adFnAqZFyOmZUdnVTWYwJJ9 pAUTab7YlICO5zW2jtl33gLFB/MnSsb5/3fgHJh7p3it8O/MzvoyR7af3WWOZpgtgeE4 ouB1vDiW9DJBgxiZDk73bPCCH9pr+KEk0iq+orFNkBr4AoxxiU+IjWCRmGD2o0TOm+hw jZFQ== X-Received: by 10.60.140.166 with SMTP id rh6mr9545213oeb.97.1369067905267; Mon, 20 May 2013 09:38:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.3.137 with HTTP; Mon, 20 May 2013 09:38:05 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1151A34C59E@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1151A56E41B@WSMSG3153V.srv.dir.telstra.com> From: James M Snell Date: Mon, 20 May 2013 09:38:05 -0700 Message-ID: To: Steve Klabnik Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-snell-merge-patch-08 in Ruby X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 May 2013 16:38:30 -0000 I may need to take another pass at explaining this in the draft. Essentially the idea is this: In the PATCH document, a null always means that the key or element must not appear in the final result. Given James M's example cases, the results should be: > Document + patch = ? > [1,2] + {"a":"foo","b":null} Result: {"a":"foo"} > {"a":"foo"} + {"b":[3,null,{"x":null}]} Result: {"a":"foo", "b":[3,{}]} > {"a":"foo"} + null Result: Invalid. The patch document MUST be a valid JSON document, which means the root must be either a JSON object or array. A null patch document is invalid. If there is an error in the javascript impl in the draft, I'll make sure that gets corrected in the next iteration. - James On Sun, May 19, 2013 at 9:00 PM, Steve Klabnik wrote: [snip] > >> Why both removing array elements that are null (obj.compact)? > > I took that to be what this meant: > > Any > object member contained in the provided data whose value is > explicitly null is to be treated as if the member was undefined. > > Since 'null' means 'remove' as the value of a key, I just assumed all > nulls should be removed. I did find this sentence (which is > everywhere) a tad bit confusing. > > This could be me mis-reading things. > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From steve@steveklabnik.com Mon May 20 09:40: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 2336E21F9540 for ; Mon, 20 May 2013 09:40:47 -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 B9wBd0ZYSPt9 for ; Mon, 20 May 2013 09:40:46 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 91A6021F95E4 for ; Mon, 20 May 2013 09:40:46 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id u16so14621670iet.0 for ; Mon, 20 May 2013 09:40:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=OwqX8f50OmwDKQ/i96swIEJw8NhrYbkR+IhmpqK9XjQ=; b=OQ8/7svEgzn42Z5n1j3P+gK3p83ciY6NjDI/98Zi5nM3janx+taMd2kf/cjH6HIa8j jkrqDBCq3LBLXtmQFCoAqJLwhSRjXLpOHpyd0EiksLUBdJdKNVS7f01XRYCDmtJ6p3BN TMPsVs87iACIKdxoC5FVlkLI+GZZexiAafIwDfg6otJ0Z8krzKvyPvc31AZ6bPeowi19 hwHSGQ16pbti4DHoODBiAciJLDuvJ+wvrdONj5yVh7Qb3NcqzuQDhxtSC1q49RjSguFZ oiXyv5tTFKQ5neTcqa0zBcv8D2xw5q5s+ToctMG4YbkaBuERLUsMgRGxUDregD+3MuBe f6tg== MIME-Version: 1.0 X-Received: by 10.50.120.4 with SMTP id ky4mr5492407igb.86.1369068046079; Mon, 20 May 2013 09:40:46 -0700 (PDT) Received: by 10.64.163.3 with HTTP; Mon, 20 May 2013 09:40:45 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1151A34C59E@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1151A56E41B@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 20 May 2013 09:40:45 -0700 Message-ID: From: Steve Klabnik To: James M Snell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnmkr4DVam/BEZeq9Nr011lLIdkHnrIx9z3CQxw6/m8//cuQ1e7xAI/0/2z+YD7MeAH/5Fl Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-snell-merge-patch-08 in Ruby X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 May 2013 16:40:47 -0000 James, it'd be nice if we could come up with something like https://github.com/json-patch/json-patch-tests with lots of examples. What do you think? From jasnell@gmail.com Mon May 20 09:42: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 AEEA121F9540 for ; Mon, 20 May 2013 09:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.392 X-Spam-Level: X-Spam-Status: No, score=-6.392 tagged_above=-999 required=5 tests=[AWL=-2.793, 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 vhpQdbIaffk1 for ; Mon, 20 May 2013 09:42:24 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3211C21F9643 for ; Mon, 20 May 2013 09:42:23 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n12so8012084oag.31 for ; Mon, 20 May 2013 09:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=/GK6midB3n14xJhDisBEEsIyONzG0gtnwR/GE1PsK3Q=; b=iBKdyyKBlhKtEo+CwEWS831FUIX2mqs8z3rNykidxJhXaJ9oHNunUBwKwkefvfsWlg FynTqdZhP01DBIS537HumbIxWxNp5VdkrgT3O5yZWiF1yGXPeIvL+lf4mAkCBUtdWlzm wwnaphBLQGeGAkBED3pRuOJG5d7MN9J01jMoivp4TEC/ELsCOTxL7Ob1/rYixc8IZLlf XyZv5mFlomnDSlDXNjhfPmzHx2sMDGxzCzBBtSu8XML5gpn455hmbKPVseQCDmUPgrzL 2OefTV3S2tIAddiSSrqPXPt2YrGiCySMQRV6KTKpj4RhZUwi6O9dsaRdee8ffj5komMN RLzg== X-Received: by 10.182.227.133 with SMTP id sa5mr19405185obc.96.1369068142132; Mon, 20 May 2013 09:42:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.3.137 with HTTP; Mon, 20 May 2013 09:42:01 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1151A34C59E@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1151A56E41B@WSMSG3153V.srv.dir.telstra.com> From: James M Snell Date: Mon, 20 May 2013 09:42:01 -0700 Message-ID: To: Steve Klabnik Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-snell-merge-patch-08 in Ruby X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 May 2013 16:42:28 -0000 Works for me. On Mon, May 20, 2013 at 9:40 AM, Steve Klabnik wrote: > James, it'd be nice if we could come up with something like > https://github.com/json-patch/json-patch-tests with lots of examples. > What do you think? From scott@kitterman.com Mon May 20 10:10:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D715221F96BA for ; Mon, 20 May 2013 10:10:35 -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 lLi2GqllnR3I for ; Mon, 20 May 2013 10:10:30 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A9B7B21F96B9 for ; Mon, 20 May 2013 10:10:30 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D38D120E40D6; Mon, 20 May 2013 13:10:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1369069829; bh=04urMMox8K1DUVzpDlgqNDLUdrsx9JiDc/ERcvEtsAs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=gspLzlyIvyz0oOsfolAGXFIL/d18y4qWE3Dx/l7KJ8zuNudr81gbrUcLGXz97qNYD QKykEYRhrCF/EklUqyuqDOTgarKr7Nw8EJfczO3jfI/gEZfxcT1zA+afbrVhwwdqho Gn4ItpQEcag4+4YHFIbyIs6XkzdTHBHxNtdPuY5I= Received: from scott-latitude-e6320.localnet (121.sub-70-192-199.myvzw.com [70.192.199.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B013B20E40D4; Mon, 20 May 2013 13:10:29 -0400 (EDT) From: Scott Kitterman To: apps-discuss@ietf.org Date: Mon, 20 May 2013 13:10:28 -0400 Message-ID: <3171424.UGFPbBNyqi@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: References: <20130520163055.10688.24242.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 17:10:36 -0000 On Monday, May 20, 2013 09:31:45 AM Murray S. Kucherawy wrote: > On Mon, May 20, 2013 at 9:30 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > This draft is a work item of the Applications Area Working Group Working > > > > Group of the IETF. > > > > Title : Message Header Field for Indicating Message > > > > Authentication Status > > > > Author(s) : Murray S. Kucherawy > > Filename : draft-ietf-appsawg-rfc5451bis-03.txt > > Pages : 42 > > Date : 2013-05-20 > > This incorporates the last of the WGLC feedback, including reverting the > ABNF change that introduced a backward compatibility issue. Thanks. That does resolve the concern. It does looke like you, however, added a note about adding the ABNF change you just removed on page 41: o ABNF: separate the authserv-id from the spec version with a "/" These two editorial comments against -02 still appear to apply: Comments: > At the time of publication of this document, Author Domain Signing > Practices ([ADSP]), SMTP Service Extension for Authentication > ([AUTH]), DomainKeys Identified Mail Signatures ([DKIM])>, Sender > Policy Framework ([SPF]), and Vouch-By-Reference ([VBR]) are > published DNS domain-level email authentication methods in common > use. DomainKeys ([DOMAINKEYS]) and Sender ID ([SENDERID] are also > referenced here, though they respectively have "Historic" and > "Experimental" status, and are no longer common. I've also seen iprev in the wild and it's supported by the python authres module I helped develop. We've also implemented DMARC based on the latest draft. Iprev is in 5451, so I think it should be mentioned. > Although SPF defined a header field called "Received-SPF" and > DomainKeys defined one called "DomainKey-Status" for this purpose, > those header fields are specific to the conveyance of their > respective results only and thus are insufficient to satisfy the > requirements enumerated below. In addition, many SPF implementations > have adopted the header field specified below, and DomainKeys has > been obsoleted by DKIM. I think this overstates things with respect to SPF. Most implementations have not adopted authres and even in the cases where they have, it's an option, not the default. Scott K From johnl@iecc.com Mon May 20 10:33:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6334A21F9671 for ; Mon, 20 May 2013 10:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.02 X-Spam-Level: X-Spam-Status: No, score=-111.02 tagged_above=-999 required=5 tests=[AWL=0.179, 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 jcHKjuQVG+0l for ; Mon, 20 May 2013 10:33:00 -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 E0A7721F966F for ; Mon, 20 May 2013 10:32:59 -0700 (PDT) Received: (qmail 21876 invoked from network); 20 May 2013 17:32:58 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 May 2013 17:32:58 -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=519a5e4a.xn--9vv.k1305; i=johnl@user.iecc.com; bh=QRiwSOfZ3LwJp+bpj6VsKLM37wmnzi0FCziyzJbx0rI=; b=blOkZzMLFjTPuSvV6M2QY9tBijh4iST7voK1GZ3Nv8wPQIZDMnNYFYm4Dwbiryx/JgZX5Ge8jjTrSTRhc83b5AuA5ITMZhto1VQzY/jz/Li+Pqy4dp8CDIhkyPiZ4FuaoFPXTVSMmNhRjnfTi8TF53MuXqVf5NqLfeU7Rr4i/88= 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=519a5e4a.xn--9vv.k1305; olt=johnl@user.iecc.com; bh=QRiwSOfZ3LwJp+bpj6VsKLM37wmnzi0FCziyzJbx0rI=; b=pim9l08T4OWupS22R8BqQzDtz7U8lhMe9lhPdMAG/GotioB2MyXjs0wFlaJqemF+4MIb4189Vq+Fnq1FVQzEKLWHlWsa/MRQ/voTDnbK0mw09jeE6baoyWsEsUkhcW4zlMJxUznLrGQc6z5C/qAqzZkzDZ2NY0ylSR8eHndFHA4= Date: 20 May 2013 17:32:36 -0000 Message-ID: <20130520173236.69335.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 17:33:04 -0000 >This incorporates the last of the WGLC feedback, including reverting the >ABNF change that introduced a backward compatibility issue. I'm confused. The -04 draft still says: authres-header = "Authentication-Results:" [CFWS] authserv-id [ [CFWS] "/" [CFWS] version ] ( [CFWS] ";" [CFWS] "none" / 1*resinfo ) [CFWS] CRLF The slash is still there and the CFWS before it is still optional. Was there some other compatibility issue? From scott@kitterman.com Mon May 20 10:44: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 40B2E21F8ADF for ; Mon, 20 May 2013 10:44:17 -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 BQ2XUU0rY-9X for ; Mon, 20 May 2013 10:44:12 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 261C021F8B33 for ; Mon, 20 May 2013 10:44:12 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 97FDC20E40D6; Mon, 20 May 2013 13:44:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1369071851; bh=WHBYK2gjxGXz+K+XYrs+Cd29B9MZGDbTM82bDri0XBo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Pgsg3/3MUhNmlIzOBU9pxEv/0IfPszUSyLhztDNKQXPCsZy3nYMZRsP0ZuOihPf1U AHfZx4XaX9J/pB6Hn0EKQ/MTpzZc7201Hio9i6zIV8o2Uv+KDnel50IrCyeVx5oK1y JRF3nSQWkG/E07suyLmju1tNu2zQaBwlom/I94wk= Received: from scott-latitude-e6320.localnet (121.sub-70-192-199.myvzw.com [70.192.199.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6F66120E40D4; Mon, 20 May 2013 13:44:11 -0400 (EDT) From: Scott Kitterman To: apps-discuss@ietf.org Date: Mon, 20 May 2013 13:44:10 -0400 Message-ID: <3292745.WyJaIicSVt@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <20130520173236.69335.qmail@joyce.lan> References: <20130520173236.69335.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 17:44:17 -0000 On Monday, May 20, 2013 05:32:36 PM John Levine wrote: > >This incorporates the last of the WGLC feedback, including reverting the > >ABNF change that introduced a backward compatibility issue. > > I'm confused. The -04 draft still says: > > authres-header = "Authentication-Results:" [CFWS] authserv-id > [ [CFWS] "/" [CFWS] version ] > ( [CFWS] ";" [CFWS] "none" / 1*resinfo ) [CFWS] CRLF > > The slash is still there and the CFWS before it is still optional. > Was there some other compatibility issue? Now I'm confused. I see -03 as that latest and it says: authres-header = "Authentication-Results:" [CFWS] authserv-id [ [CFWS] authres-version ] ( [CFWS] ";" [CFWS] "none" / 1*resinfo ) [CFWS] CRLF ; the special case of "none" is used to indicate that no ; message authentication is performed Scott K From superuser@gmail.com Mon May 20 10:51: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 23D4A21F8F12 for ; Mon, 20 May 2013 10:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 GZrF8WmJJVHc for ; Mon, 20 May 2013 10:50:54 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id DC30021F8FA9 for ; Mon, 20 May 2013 10:50:47 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id x53so5459145wes.5 for ; Mon, 20 May 2013 10:50:46 -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=UqTg6dPgxJBipw8PPYx6j1rORnWhclVt5qOi5ffahnE=; b=jgZUqhiDPekeXszuR8Bm2RBEtR3JWLjDK64KAlrG/64psw4nA1/Z+Tu3COx/KhHkk1 dbIxKBMBAVAMQg0Wv5A+qcUbWbb88sGWZL3GjOkEq49uqYDIZHCY7YBGjfPpLFtA5xhL PF3bceYwP1EMMEEwOGrnvY66X54PWwg4+DhlT3UsRuqhY4UHuwJJTv9EeI0X4OUN03g1 KYXhz4WHUGPMvZB8g0JQXHS4EgmmtpaWHVSH3QsLyZAX86Hxi3IUeuWKCmYdyZVTU/hH fT0qzRU7ViknU7D0+dVvsGY+fsUUAT3ry/V5y7mq/MtIb9niwQPxv1a3uJeJ5zjm6H1J w8TQ== MIME-Version: 1.0 X-Received: by 10.180.79.69 with SMTP id h5mr15966351wix.14.1369072246506; Mon, 20 May 2013 10:50:46 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Mon, 20 May 2013 10:50:46 -0700 (PDT) In-Reply-To: <20130520173236.69335.qmail@joyce.lan> References: <20130520173236.69335.qmail@joyce.lan> Date: Mon, 20 May 2013 10:50:46 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=f46d043c062eeccb2404dd29f86b Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 17:51:04 -0000 --f46d043c062eeccb2404dd29f86b Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 20, 2013 at 10:32 AM, John Levine wrote: > >This incorporates the last of the WGLC feedback, including reverting the > >ABNF change that introduced a backward compatibility issue. > > I'm confused. The -04 draft still says: > > authres-header = "Authentication-Results:" [CFWS] authserv-id > [ [CFWS] "/" [CFWS] version ] > ( [CFWS] ";" [CFWS] "none" / 1*resinfo ) [CFWS] CRLF > > The slash is still there and the CFWS before it is still optional. > Was there some other compatibility issue? > -04? The latest is -03, and it doesn't have the "/" anymore: http://tools.ietf.org/html/draft-ietf-appsawg-rfc5451bis-03 -MSK --f46d043c062eeccb2404dd29f86b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, May 20, 2013 at 10:32 AM, John Levine <johnl@taugh.= com> wrote:
>This incorporates the last of the WGLC feedback, incl= uding reverting the
>ABNF change that introduced a backward compatibility issue.

I'm confused. The -04 draft still says:

authres-header =3D "Authentication-Results:" [CFWS] authserv-id =A0 =A0 =A0 =A0 =A0 =A0 =A0 [ [CFWS] "/" [CFWS] version ]
=A0 =A0 =A0 =A0 =A0 =A0 =A0 ( [CFWS] ";" [CFWS] "none" = / 1*resinfo ) [CFWS] CRLF

The slash is still there and the CFWS before it is still optional.
Was there some other compatibility issue?

-04?=A0 The latest is -03, and it doesn't have the "/" any= more:

http://tools.ietf.org/html/draft-ietf-appsawg-rfc5451bis-03
-MSK
--f46d043c062eeccb2404dd29f86b-- From superuser@gmail.com Mon May 20 10:51:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B0821F8F6E for ; Mon, 20 May 2013 10:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 zOK7pKvj4mAv for ; Mon, 20 May 2013 10:51:30 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 8963D21F8F12 for ; Mon, 20 May 2013 10:51:29 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id p60so1658868wes.20 for ; Mon, 20 May 2013 10:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=87py9J+jECj1oenGDRagd2ZgmDO5Dqrcdnma1suDeLQ=; b=VYk3e6qU/kVAGvuZ6DJGzCFCV45ISBZbWOqOsDOLe20myfnGwBJ+/C8wQN/lGBc9om ZY/moQ2wOtaY3UT2nDVhKdMzGk6OsLbsiZfxozJyxWTmTeu9L1EEoCw+J6oz0AGsSH2q ekT5nBSG8AON04nLpsOOOInOQdhJ91Z0/aFsReYZLKhUGtDdzyxhX9GxoX2T0lrhwAyF 8TBKiSZd0wrfArDs5cInalHHjcpRL4a2CKVX42ZIRoHe9K/14fytbZtDHCNUy5QCg+/t 0GzWcfl/faAUmGTLU0LhsAnTQQMRIea0qAZhNOLLGk8b/jCi5uwahty+vDS7LzRHczDp JUag== MIME-Version: 1.0 X-Received: by 10.180.189.41 with SMTP id gf9mr15991773wic.32.1369072288483; Mon, 20 May 2013 10:51:28 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Mon, 20 May 2013 10:51:28 -0700 (PDT) In-Reply-To: <3171424.UGFPbBNyqi@scott-latitude-e6320> References: <20130520163055.10688.24242.idtracker@ietfa.amsl.com> <3171424.UGFPbBNyqi@scott-latitude-e6320> Date: Mon, 20 May 2013 10:51:28 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=001a11c348306d51c504dd29fb98 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 17:51:35 -0000 --001a11c348306d51c504dd29fb98 Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 20, 2013 at 10:10 AM, Scott Kitterman wrote: > It does looke like you, however, added a note about adding the ABNF change > you > just removed on page 41: > > o ABNF: separate the authserv-id from the spec version with a "/" > > These two editorial comments against -02 still appear to apply: > [...] > Sorry, yes. I was focused on dealing with the ABNF concern and forgot about these two things. I'll put up another revision shortly that takes care of them. Thanks for the followup. -MSK --001a11c348306d51c504dd29fb98 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, May 20, 2013 at 10:10 AM, Scott Kitterman <scot= t@kitterman.com> wrote:
It does looke like you, however, added a not= e about adding the ABNF change you
just removed on page 41:

=A0o ABNF: separate the authserv-id from the spec version with a "/&qu= ot;

These two editorial comments against -02 still appear to apply:
[...]

Sorry, yes.=A0 I was focused on d= ealing with the ABNF concern and forgot about these two things.=A0 I'll= put up another revision shortly that takes care of them.=A0 Thanks for the= followup.

-MSK
--001a11c348306d51c504dd29fb98-- From johnl@taugh.com Mon May 20 11: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 9B64421F95EA for ; Mon, 20 May 2013 11:37:57 -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 VJOMHpvU8UOA for ; Mon, 20 May 2013 11:37:57 -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 BEA2321F881C for ; Mon, 20 May 2013 11:37:56 -0700 (PDT) Received: (qmail 36746 invoked from network); 20 May 2013 18:37: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:references:mime-version:content-type:user-agent:cleverness; s=8f88.519a6d84.k1305; bh=MvHcLu3V7jBrY9ZNrFXbIolx5FrebyaFIpctpg9EFKo=; b=fkvihw8/88sKbc2I0P2Fey9r8mTwi60boVQCdDxFVYU6QtgKuKgnGCeCz8QTamofKe4m/kGE8tg0TEHd5KFlxb8r8L0610DfpGR7d9Dnsbi3nF7FdAN2REsFTjE7GoGhys9OFOKY6RhNw2259oy3UcFGcf+n0/6XhuwLLEVk78A= 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=8f88.519a6d84.k1305; bh=MvHcLu3V7jBrY9ZNrFXbIolx5FrebyaFIpctpg9EFKo=; b=WNTumtuZtfSLdN1KLWYvJJYru6oGLIslYsiXJ+X99DkBEHviw0E1d/oHZ2egP/Qnk9Hfjsh3/ECeYC6uG4daW9Cr510xBvvvjncdW7J5JkaC4ipHp2rSXTDoKOcYh8yHOCE3bmLyN0f/lYyFPh9DqteivojvpEXEx/27FbfRMd8= Received: (ofmipd 127.0.0.1); 20 May 2013 18:37:33 -0000 Date: 20 May 2013 14:37:55 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20130520173236.69335.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 18:37:57 -0000 > -04? The latest is -03, and it doesn't have the "/" anymore: > > http://tools.ietf.org/html/draft-ietf-appsawg-rfc5451bis-03 Oops, bitten by version creep. "Never mind". Now that I have read the actual -03, it looks fine. The changes satisfy the issues I raised. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From internet-drafts@ietf.org Mon May 20 12:19: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 21CD321F8609; Mon, 20 May 2013 12:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.126, 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 q4XOq3DttQvG; Mon, 20 May 2013 12:19:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 330F121F88FB; Mon, 20 May 2013 12:19:39 -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.45 Message-ID: <20130520191939.27112.89315.idtracker@ietfa.amsl.com> Date: Mon, 20 May 2013 12:19:39 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 19:19:40 -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 : Message Header Field for Indicating Message Authenticati= on Status Author(s) : Murray S. Kucherawy Filename : draft-ietf-appsawg-rfc5451bis-04.txt Pages : 42 Date : 2013-05-20 Abstract: This document specifies a header field for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users, or make sorting and filtering decisions. This document is a candidate for Internet Standard status. [RFC Editor: Please delete this notation, as I imagine it will be indicated some other way.] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-rfc5451bis-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-rfc5451bis-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From scott@kitterman.com Mon May 20 12:25: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 9AA5721F9692 for ; Mon, 20 May 2013 12:25: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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9WjJ2T6+XUy for ; Mon, 20 May 2013 12:25:49 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 68FC021F9681 for ; Mon, 20 May 2013 12:25:45 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D297520E40D6; Mon, 20 May 2013 15:25:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1369077943; bh=pV1FYoO67yLu8RCJ70JzNHzuqNtweWBxQN3UcFJdpl4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=UgtTXQA3VP/17zRW/lRBtJh6kRJ8rOrc7GoJ5wjPeH8TmGBn/29Dqpri/HTfH8mQO tpD0Bgnad59Fxqi+Tu9QszeZZAq7jDe2GwtYwH/rfhUqe1npF3H2Pm2Zx0EBB+jyiH m4WaJP6X55x+bPG+erYZEaQOSL70Yyg6+VZFkukQ= Received: from scott-latitude-e6320.localnet (121.sub-70-192-199.myvzw.com [70.192.199.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id A77D320E40D4; Mon, 20 May 2013 15:25:43 -0400 (EDT) From: Scott Kitterman To: apps-discuss@ietf.org Date: Mon, 20 May 2013 15:25:42 -0400 Message-ID: <1859705.PNCrcO2509@scott-latitude-e6320> User-Agent: KMail/4.10.2 (Linux/3.8.0-21-generic; KDE/4.10.2; i686; ; ) In-Reply-To: <20130520191939.27112.89315.idtracker@ietfa.amsl.com> References: <20130520191939.27112.89315.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 19:25:58 -0000 On Monday, May 20, 2013 12:19:39 PM internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Applications Area Working > Group Working Group of the IETF. > > Title : Message Header Field for Indicating Message > Authentication Status Author(s) : Murray S. Kucherawy > Filename : draft-ietf-appsawg-rfc5451bis-04.txt > Pages : 42 > Date : 2013-05-20 Thanks. That addresses my comments. Scott K From superuser@gmail.com Mon May 20 13:20: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 DDE9121F93FC for ; Mon, 20 May 2013 13:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 MQWcAyKDk8lB for ; Mon, 20 May 2013 13:20:42 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE3421F90DF for ; Mon, 20 May 2013 13:20:41 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id w62so745737wes.3 for ; Mon, 20 May 2013 13:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=Q6bZtzsi9H00k19tteaqiWS5CXGApmWqpJpC/fNfyM8=; b=SLP35XwceKYUlKZswSnfsMdTV3w7T4eUXXXlsyEOnbWyJBRzNamYuoKwxnjxbJZ8y3 n5Q1m3b1y9nNVWI7Ihh7AYRsZLLFoAK4mMGp1FcrD6zUOpdFJo1s2GLNyue9XX0sET5r Dgor8CKjhJPbS0pJW1FG+JC2U5DDGuL94DgSlaaj+CZey6vOjwAC91zQk7bHnpI5GhAg IVwxXE7NPvz0gcJkbt8PIYPANJ1+6cIB7GX5LyWk07JkB9ogeDK+BTtVoVha5nezu+kd FYq09UO1lh0nEljk3W+/R2TBXDm6kgn6bRVXZpClLqEqtAaxciOqQc1zIPmMB62D5qeR CgNA== MIME-Version: 1.0 X-Received: by 10.180.37.243 with SMTP id b19mr17341060wik.12.1369081232633; Mon, 20 May 2013 13:20:32 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Mon, 20 May 2013 13:20:32 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 May 2013 13:20:32 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=e89a8f646db58a34db04dd2c1010 Subject: Re: [apps-discuss] Call for Adoption: draft-wilde-xml-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 20:20:43 -0000 --e89a8f646db58a34db04dd2c1010 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 3, 2013 at 12:25 PM, Murray S. Kucherawy wrote: > This is a call for adoption for draft-wilde-xml-patch. The document had a > thread of discussion in January that showed some interest within this > working group, 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. I will > act as document shepherd. > > I've not seen any traffic in support of this in the last couple of weeks. I realize my message was a "default yes" and thus people may not have felt the need to respond. However, in retrospect, there was exactly one person other than the author that participated in that January thread. I'm not certain now whether we have critical mass to justify processing it here. Does anyone (other than Erik and Tom) support processing it through appsawg? -MSK --e89a8f646db58a34db04dd2c1010 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, May 3, 2013 at 12:25 PM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:
This is a call for ado= ption for draft-wilde-xml-patch.=A0 The document had a thread of discussion= in January that showed some interest within this working group, and it app= ears to be material that falls within our charter.=A0 Accordingly, we'l= l adopt this as a working group item within the next couple of weeks unless= there's objection to such processing.=A0 I will act as document shephe= rd.

=A0
I've not seen any = traffic in support of this in the last couple of weeks.=A0 I realize my mes= sage was a "default yes" and thus people may not have felt the ne= ed to respond.=A0 However, in retrospect, there was exactly one person othe= r than the author that participated in that January thread.=A0 I'm not = certain now whether we have critical mass to justify processing it here.
Does anyone (other than Erik and Tom) = support processing it through appsawg?

-MSK
--e89a8f646db58a34db04dd2c1010-- From jasnell@gmail.com Mon May 20 13:27: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 6677321F962D for ; Mon, 20 May 2013 13:27:50 -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 Fr0eKlyu8lBd for ; Mon, 20 May 2013 13:27:49 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 40B3421F9408 for ; Mon, 20 May 2013 13:27:47 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id vb8so7633194obc.0 for ; Mon, 20 May 2013 13:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=NjZCWD250k7F/I58487YcoEIzGtpWYlLxs7ZaMULvGI=; b=Fd5oeN2vXui/f+ny4QG5DByifclW3qP+ClfTYb7Cq/HzFOtRl2jjYTLmDhlSOLPVTn BOFjSbg8GwjCaopTYi5YI7GzN2BIY9ElSvPqIp2BYGvGHyL9vt1TBbfkpYCF19CwlGIT H/annmjw1XKI5Istt4tiv8akXaBomkfKmCDyC04amfK+tuR6mcrIfE2f+Zd2HNulGfXR QzWsmhdMeFKyjjJYhSFM91P0YNWS8JaRKYPDGpLd7bN77gvKYYA6J1m8Upn8V3FlJ90B RzZ2//JshDSuD1irwSLcQUw8IGUGQi8ZLQQC3D9APIrdiMLTqTeIrgblGHzkAXWbEjv9 LpDg== X-Received: by 10.60.80.103 with SMTP id q7mr17077201oex.135.1369081665922; Mon, 20 May 2013 13:27:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.3.137 with HTTP; Mon, 20 May 2013 13:27:25 -0700 (PDT) In-Reply-To: References: From: James M Snell Date: Mon, 20 May 2013 13:27:25 -0700 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for Adoption: draft-wilde-xml-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 20:27:50 -0000 I'm +0.5 on this really. It makes sense to process this through as a WG doc given the how it fits with other related docs, but I'm not convinced yet just how extensively this will be implemented. Perhaps we ought to just let this one sit for a while and see if interest picks up? On Mon, May 20, 2013 at 1:20 PM, Murray S. Kucherawy wrote: > On Fri, May 3, 2013 at 12:25 PM, Murray S. Kucherawy > wrote: >> >> This is a call for adoption for draft-wilde-xml-patch. The document had a >> thread of discussion in January that showed some interest within this >> working group, 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. I will act as >> document shepherd. >> > > I've not seen any traffic in support of this in the last couple of weeks. I > realize my message was a "default yes" and thus people may not have felt the > need to respond. However, in retrospect, there was exactly one person other > than the author that participated in that January thread. I'm not certain > now whether we have critical mass to justify processing it here. > > Does anyone (other than Erik and Tom) support processing it through appsawg? > > -MSK > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From sm@elandsys.com Mon May 20 13:56: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 DF47F21F9678 for ; Mon, 20 May 2013 13:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.366 X-Spam-Level: X-Spam-Status: No, score=-102.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 IfEuOo52lkPM for ; Mon, 20 May 2013 13:56: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 3754821F8F41 for ; Mon, 20 May 2013 13:56:21 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.130.208]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4KKtviB026930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 May 2013 13:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1369083369; bh=eeqmHgKwuE80GiYI3gPeF9QFS4AGQgfsiIgbWDl5jTA=; h=Date:To:From:Subject:Cc; b=N1yxS9y1JHsjLcFEa+l3OjQZKHspg24MAdVg9Nhq3njWV0OD2s5uGrKLS3kesro1d 6zUMwjtEh3MSBwuYB/PdMuulMcNE7RiihvKwRGFbnFwqZ1XzsFcA6YrUWgMwH9hT+Z 9PlAb/jONeNkyCYhe0VXXrRE2JVObLaVzS52Z7kE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1369083369; i=@elandsys.com; bh=eeqmHgKwuE80GiYI3gPeF9QFS4AGQgfsiIgbWDl5jTA=; h=Date:To:From:Subject:Cc; b=D6m6fgIX6zrNf/vq2ALvzUqKjB2/shf3cK0QvaKpfBe+vASqn+iTEChdB95381Ef9 +ZcNH9Z/FhiheFH/aWKZvRRtxZYJmT3yPYgywpsIyo71/wC/hLGmqHoUBtcM3cpMvG sQDQ0egsiRrP8Y/Kk7vtdg/kRt54YwgADrYAajh8= Message-Id: <6.2.5.6.2.20130520131213.0bebc4e8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 20 May 2013 13:44:28 -0700 To: "Murray S. Kucherawy" From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: [apps-discuss] Status of draft-ietf-appsawg-rfc5451bis-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, 20 May 2013 20:56:22 -0000 Hi Murray, I reviewed draft-ietf-appsawg-rfc5451bis-04. The document is ready for publication as an Internet Standard. I'll list nits below. In Section 1: "DomainKeys Identified Mail Signatures ([DKIM])>" There is an errant ">" in there. "This proposal is not intended to be restricted to domain-based" I leave it to you to see whether you prefer to use "document" instead of "proposal". In Appendix C.2: "Authentication-Results: example.org/1; none" There is an errant slash. In Appendix C.7: "Authentication-Results: foo.example.net (foo) / (bar) 1 (baz);" Is that correct? I'll consider all the last WGLC comments as addressed unless someone says otherwise. Regards, S. Moonesamy (as document shepherd) From superuser@gmail.com Mon May 20 13:58: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 45C5621F9678 for ; Mon, 20 May 2013 13:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[AWL=-1.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_SMALL=2.3, 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 X7LiGu7Gw2We for ; Mon, 20 May 2013 13:58:47 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB7521F9676 for ; Mon, 20 May 2013 13:58:47 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hr14so2471943wib.9 for ; Mon, 20 May 2013 13:58:46 -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=M86d6oNA0o4gb03gAmHsAmjfJ4kfLr1AWBHC2nbo390=; b=IIp3HyeCOKZ62QSSSfDJydlwdmz1+QQg1TKx7HViAfXys1g8hXx+t4quSKTmGspfal esRTRA7KoznGf0WELe/PF4e209kQ7jDWiTn5fydA7Waq2FRwudX1okqsCxntBC2tCYxa J+SOLuX62xowwhv/pVcW6XUx18fx7iLCfbnhtBMM8MqLCxMZw2Co8udpUc3viQEvvQn1 h1fk8JsajMn9hkilhB8RfDxF03LiT7tBQ7CX86k5upz72AXC1P630q3DF3tuFWFzKojI 3iLDEXm5D0rlw6v5sd9eDQDg+XEOkpYqaghDlnAQiqJsjTKcS+twcSlLuT1E23DqGK3p NMqw== MIME-Version: 1.0 X-Received: by 10.180.79.69 with SMTP id h5mr17420906wix.14.1369083519118; Mon, 20 May 2013 13:58:39 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Mon, 20 May 2013 13:58:39 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130520131213.0bebc4e8@elandnews.com> References: <6.2.5.6.2.20130520131213.0bebc4e8@elandnews.com> Date: Mon, 20 May 2013 13:58:39 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=f46d043c062ed3360804dd2c9850 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Status of draft-ietf-appsawg-rfc5451bis-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, 20 May 2013 20:58:48 -0000 --f46d043c062ed3360804dd2c9850 Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 20, 2013 at 1:44 PM, S Moonesamy wrote: > Hi Murray, > > I reviewed draft-ietf-appsawg-rfc5451bis-**04. The document is ready for > publication as an Internet Standard. > > I'll list nits below. > [...] > Thanks, SM. All three points fixed in source. I'll hold off posting a revision since I've posted two today already. I'll do another one after IETF LC closes unless there's some reason to do so sooner. -MSK --f46d043c062ed3360804dd2c9850 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, May 20, 2013 at 1:44 PM, S Moonesamy <sm+ietf@= elandsys.com> wrote:
Hi Murray,

I reviewed draft-ietf-appsawg-rfc5451bis-04. =A0The document is read= y for publication as an Internet Standard.

I'll list nits below.
[...]

Thanks, SM.=A0 All three points f= ixed in source.=A0 I'll hold off posting a revision since I've post= ed two today already.=A0 I'll do another one after IETF LC closes unles= s there's some reason to do so sooner.

-MSK
--f46d043c062ed3360804dd2c9850-- From internet-drafts@ietf.org Mon May 20 16:33: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 1E2A421F93B1; Mon, 20 May 2013 16:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.129, 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 GNM+MqTw+c7U; Mon, 20 May 2013 16:33:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E8D21F937E; Mon, 20 May 2013 16:33:53 -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.50 Message-ID: <20130520233353.30961.30740.idtracker@ietfa.amsl.com> Date: Mon, 20 May 2013 16:33:53 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-merge-patch-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: Mon, 20 May 2013 23:33:57 -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 application/json-merge-patch Media Type Author(s) : James M Snell Filename : draft-ietf-appsawg-json-merge-patch-00.txt Pages : 10 Date : 2013-05-20 Abstract: This specification defines the application/json-merge-patch media type and it's intended use with the HTTP PATCH method defined by RFC 5789. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jasnell@gmail.com Mon May 20 16:38: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 24E5021F966F; Mon, 20 May 2013 16:38:28 -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 noCy0gLbyKxh; Mon, 20 May 2013 16:38:27 -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 1940E21F965A; Mon, 20 May 2013 16:38:27 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id eh20so11124obb.32 for ; Mon, 20 May 2013 16:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=r1j0JmQdc8krReaes9iceEIoI+3owdbi93SOCh5PXTk=; b=HNImZva+kCu0LivFgpxGVx8IkHyWm5B2Uiy0G9I+esUYA7B99r4C53Lu/eZLCfjLmb fHYj1t+865kTiEqQtrv2S3V2fNZzfWkI/A2ruhbQO2LgkiFeoB8TDB7tJ2tbgON08CpA oKKRU85aNjQGCTCKGdSgNqn9sulgsLOHpR4alXWSNhX3N/l3Ketuqviu8PIGvHsbjfxL uPDZQGv+rTmYkwGM8stYTtQZZIz7bUCb/69ajwdoAWtRbnel3tddtQ2tlt9F7exQc13e n+ULqpVUnFyPmpoZ3W+qNiQA2lz2z89fG+FCmLHF8YJT1G/sNM6teUSfW+0nCYqZwafV 26Ew== X-Received: by 10.60.92.41 with SMTP id cj9mr29827430oeb.31.1369093106598; Mon, 20 May 2013 16:38:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.3.137 with HTTP; Mon, 20 May 2013 16:38:06 -0700 (PDT) In-Reply-To: <20130520233353.30961.30740.idtracker@ietfa.amsl.com> References: <20130520233353.30961.30740.idtracker@ietfa.amsl.com> From: James M Snell Date: Mon, 20 May 2013 16:38:06 -0700 Message-ID: To: internet-drafts@ietf.org Content-Type: text/plain; charset=UTF-8 Cc: IETF Apps Discuss , i-d-announce@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-merge-patch-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: Mon, 20 May 2013 23:38:28 -0000 A few minor updates here as well as the initial appsawg draft. Includes a fix in the example javascript implementation. Thanks to Steve and James M. for their valuable input. On Mon, May 20, 2013 at 4:33 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Applications Area Working Group Working Group of the IETF. > > Title : The application/json-merge-patch Media Type > Author(s) : James M Snell > Filename : draft-ietf-appsawg-json-merge-patch-00.txt > Pages : 10 > Date : 2013-05-20 > > Abstract: > This specification defines the application/json-merge-patch media > type and it's intended use with the HTTP PATCH method defined by RFC > 5789. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From James.H.Manger@team.telstra.com Mon May 20 16:50: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 4A14721F8E4E for ; Mon, 20 May 2013 16:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.949 X-Spam-Level: X-Spam-Status: No, score=0.949 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_54=0.6, MANGLED_FORM=2.3, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIB9cJtEO90f for ; Mon, 20 May 2013 16:50:05 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 3D39921F90DF for ; Mon, 20 May 2013 16:50:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,711,1363093200"; d="scan'208";a="136688059" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipobvi.tcif.telstra.com.au with ESMTP; 21 May 2013 09:50:04 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7081"; a="133216444" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipccvi.tcif.telstra.com.au with ESMTP; 21 May 2013 09:50:04 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Tue, 21 May 2013 09:50:03 +1000 From: "Manger, James H" To: James M Snell , Steve Klabnik , "apps-discuss@ietf.org" Date: Tue, 21 May 2013 09:50:02 +1000 Thread-Topic: [apps-discuss] draft-snell-merge-patch-08 in Ruby Thread-Index: Ac5VeHk6OsL5Pkx9R22mvwEgQVGKhgAON8zg Message-ID: <255B9BB34FB7D647A506DC292726F6E1151A56EEE3@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1151A34C59E@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1151A56E41B@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [apps-discuss] draft-snell-merge-patch-08 in Ruby X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 May 2013 23:50:13 -0000 PiBHaXZlbiBKYW1lcyBNJ3MgZXhhbXBsZSBjYXNlcywgdGhlIHJlc3VsdHMgc2hvdWxkIGJlOg0K PiANCj4gPiBEb2N1bWVudCArIHBhdGNoID0gPw0KPiANCj4gPiBbMSwyXSAgKyAgeyJhIjoiZm9v IiwiYiI6bnVsbH0NCj4gDQo+ICAgUmVzdWx0OiB7ImEiOiJmb28ifQ0KDQpUaGUgSmF2YVNjcmlw dCBpbiBkcmFmdC1zbmVsbC1tZXJnZS1wYXRjaC0wOCBpbmNvcnJlY3RseSBnaXZlcyB0aGUgcmVz dWx0IGFzIFsxLDJdLg0KDQoNCj4gPiB7ImEiOiJmb28ifSAgKyAgeyJiIjpbMyxudWxsLHsieCI6 bnVsbH1dfQ0KPiANCj4gICBSZXN1bHQ6IHsiYSI6ImZvbyIsICJiIjpbMyx7fV19DQoNCk5PLiBU aGUgcmVzdWx0IHNob3VsZCBiZTogeyJhIjoiZm9vIiwgImIiOlszLG51bGwseyJ4IjpudWxsfV19 Lg0KTWVyZ2UtcGF0Y2ggZG9lcyBOT1QgbWVyZ2UgYXJyYXlzOyBpdCB0cmVhdHMgdGhlbSBsaWtl IG90aGVyIHByaW1pdGl2ZXMgKHN0cmluZ3MsIG51bWJlcnMsIGJvb2xlYW5zKSBzbyBhIG1lcmdl LXBhdGNoIGltcGxlbWVudGF0aW9uIHNob3VsZCBOT1QgYmUgbG9va2luZyBpbnNpZGUgYW4gYXJy YXkgZm9yIG51bGxzLg0KDQpUaGUgSmF2YVNjcmlwdCBpbiBkcmFmdC1zbmVsbC1tZXJnZS1wYXRj aC0wOCBnaXZlcyBuZWl0aGVyIG9mIHRoZXNlIHJlc3VsdHMuIEl0IGluY29ycmVjdGx5IGdpdmVz IHsiYSI6ImZvbyIsICJiIjpbMyx7IngiOm51bGx9XX0NCg0KDQo+ID4geyJhIjoiZm9vIn0gICsg IG51bGwNCj4gDQo+ICAgUmVzdWx0OiBJbnZhbGlkLiBUaGUgcGF0Y2ggZG9jdW1lbnQgTVVTVCBi ZSBhIHZhbGlkIEpTT04gZG9jdW1lbnQsDQo+IHdoaWNoIG1lYW5zIHRoZSByb290IG11c3QgYmUg ZWl0aGVyIGEgSlNPTiBvYmplY3Qgb3IgYXJyYXkuIEEgbnVsbA0KPiBwYXRjaCBkb2N1bWVudCBp cyBpbnZhbGlkLg0KDQpJIHRob3VnaHQgdGhlIG9uZSBub24tY29udHJvdmVyc2lhbCBjaGFuZ2Ug cGxhbm5lZCBmb3IgUkZDNDYyNyAiSlNPTiIgd2FzIHRvIGFsbG93IGFueSBKU09OIHZhbHVlIChu b3QganVzdCBhcnJheXMgYW5kIG9iamVjdHMpIGFzIGEgSlNPTi10ZXh0Lg0KDQpBIHBhdGNoIG9m IG51bGwgY2VydGFpbmx5IHNob3VsZCBub3QgcmV0dXJuIHRoZSBvcmlnaW5hbCB1bmNoYW5nZWQg KGFzIHRoZSBKYXZhU2NyaXB0IGluIGRyYWZ0LXNuZWxsLW1lcmdlLXBhdGNoLTA4IGRvZXMpLiBF aXRoZXIgdGhyb3cgYW4gZXJyb3IsIG9yIHJldHVybiBhbiB1bmRlZmluZWQgdmFsdWUuDQoNCg0K PiBJZiB0aGVyZSBpcyBhbiBlcnJvciBpbiB0aGUgamF2YXNjcmlwdCBpbXBsIGluIHRoZSBkcmFm dCwgSSdsbCBtYWtlDQo+IHN1cmUgdGhhdCBnZXRzIGNvcnJlY3RlZCBpbiB0aGUgbmV4dCBpdGVy YXRpb24uDQoNCk15IHN1Z2dlc3RlZCBKYXZhU2NyaXB0IGltcGxlbWVudGF0aW9uOg0KDQpmdW5j dGlvbiBtZXJnZShvcmlnLCBwYXRjaCkgew0KCXZhciByZXN1bHQ7DQoJaWYgKHBhdGNoID09PSBu dWxsKSB7DQoJCS8vIGxlYXZlIHJlc3VsdCB1bmRlZmluZWQNCgl9DQoJZWxzZSBpZiAodHlwZW9m IHBhdGNoID09PSAnc3RyaW5nJyB8fA0KCQl0eXBlb2YgcGF0Y2ggPT09ICdudW1iZXInIHx8DQoJ CXR5cGVvZiBwYXRjaCA9PT0gJ2Jvb2xlYW4nIHx8DQoJCUFycmF5LmlzQXJyYXkocGF0Y2gpKQ0K CXsNCgkJcmVzdWx0ID0gcGF0Y2g7DQoJfQ0KCWVsc2UgeyAvLyBwYXRjaCBpcyBhbiBvYmplY3QN CgkJcmVzdWx0ID0ge307DQoJCWlmIChvcmlnIGluc3RhbmNlb2YgT2JqZWN0ICYmICFBcnJheS5p c0FycmF5KG9yaWcpKSB7DQoJCQlmb3IgKG0gaW4gb3JpZykNCgkJCQlyZXN1bHRbbV0gPSBvcmln W21dOw0KCQl9DQoJCWZvciAobSBpbiBwYXRjaCkgew0KCQkJcmVzdWx0W21dID0gbWVyZ2UocmVz dWx0W21dLCBwYXRjaFttXSk7DQoJCX0NCgl9DQoJcmV0dXJuIHJlc3VsdDsNCn0NCg0KU2VlIGl0 IGluIGFjdGlvbiBhdCBodHRwOi8vaWQuY3RvLnRlbHN0cmEuY29tL2pzb24vbWVyZ2UuaHRtbA0K DQotLQ0KSmFtZXMgTWFuZ2VyDQo= From jasnell@gmail.com Mon May 20 16:54: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 2B80121F89A5 for ; Mon, 20 May 2013 16:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=-5.462, BAYES_50=0.001, J_CHICKENPOX_54=0.6, MANGLED_FORM=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYSSdK5WRokB for ; Mon, 20 May 2013 16:54:36 -0700 (PDT) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id E30B421F88FB for ; Mon, 20 May 2013 16:54:35 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id j6so28897oag.4 for ; Mon, 20 May 2013 16:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=r4o/qxV3ImO3asx86hxNIh6YR1mgwj5uKlUE6oM9szA=; b=jnoZ3HHp1bRZPlLcPJP2AW57b6vgHA6QTGnr4vYI3Dbe3D0cuOBt0kL2oWKolHOrY2 kIm8UKzYh6XaVaRcA0CnzPdWGFw22ADR7t0y7kisUE9TFZ8jlj9rk7kMnbfSvq1EeZ7P K+OrqBr60E83frFBu9Pq7U9Qt09wXwZH1DOptDtafgbSUosH0vYvRGf8cP7iQOAEhfwl skgLAaFq/fMLB02t+VSXUTlmapwNqhMABymoJTSE+r6Al80Op9VzymNtxHyZr1C5at84 W95qnT0tfxlDa/x206h6iHD8uYX4anWuSPblcxhREPVk59YdMhphtF9EYVmg52iMH0Dz 3rug== X-Received: by 10.182.246.198 with SMTP id xy6mr28372040obc.1.1369094075510; Mon, 20 May 2013 16:54:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.3.137 with HTTP; Mon, 20 May 2013 16:54:14 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151A56EEE3@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1151A34C59E@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1151A56E41B@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1151A56EEE3@WSMSG3153V.srv.dir.telstra.com> From: James M Snell Date: Mon, 20 May 2013 16:54:14 -0700 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] draft-snell-merge-patch-08 in Ruby X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 May 2013 23:54:40 -0000 On Mon, May 20, 2013 at 4:50 PM, Manger, James H wrote: >> Given James M's example cases, the results should be: >> >> > Document + patch = ? >> >> > [1,2] + {"a":"foo","b":null} >> >> Result: {"a":"foo"} > > The JavaScript in draft-snell-merge-patch-08 incorrectly gives the result as [1,2]. > Fixed in the todays updated draft. > >> > {"a":"foo"} + {"b":[3,null,{"x":null}]} >> >> Result: {"a":"foo", "b":[3,{}]} > > NO. The result should be: {"a":"foo", "b":[3,null,{"x":null}]}. > Merge-patch does NOT merge arrays; it treats them like other primitives (strings, numbers, booleans) so a merge-patch implementation should NOT be looking inside an array for nulls. > No, the correct result is that nulls are treated as if they are undefined and not present, They are to be removed from the result. > The JavaScript in draft-snell-merge-patch-08 gives neither of these results. It incorrectly gives {"a":"foo", "b":[3,{"x":null}]} > Fixed in todays updated draft. > >> > {"a":"foo"} + null >> >> Result: Invalid. The patch document MUST be a valid JSON document, >> which means the root must be either a JSON object or array. A null >> patch document is invalid. > > I thought the one non-controversial change planned for RFC4627 "JSON" was to allow any JSON value (not just arrays and objects) as a JSON-text. > The draft is based on the current definition of RFC4627 and not on any "planned" changes that might happen in the future. > A patch of null certainly should not return the original unchanged (as the JavaScript in draft-snell-merge-patch-08 does). Either throw an error, or return an undefined value. > Agree. An error would be the most appropriate outcome. > >> If there is an error in the javascript impl in the draft, I'll make >> sure that gets corrected in the next iteration. > > My suggested JavaScript implementation: > > function merge(orig, patch) { > var result; > if (patch === null) { > // leave result undefined > } > else if (typeof patch === 'string' || > typeof patch === 'number' || > typeof patch === 'boolean' || > Array.isArray(patch)) > { > result = patch; > } > else { // patch is an object > result = {}; > if (orig instanceof Object && !Array.isArray(orig)) { > for (m in orig) > result[m] = orig[m]; > } > for (m in patch) { > result[m] = merge(result[m], patch[m]); > } > } > return result; > } > > See it in action at http://id.cto.telstra.com/json/merge.html > I will take a more in depth look at this a bit later tonight or tomorrow. - James > -- > James Manger From superuser@gmail.com Mon May 20 16:56: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 901FE21F96BE for ; Mon, 20 May 2013 16:56:46 -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 EK4c0kmX27OJ for ; Mon, 20 May 2013 16:56:46 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4C621F96D1 for ; Mon, 20 May 2013 16:56:36 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hr14so2919997wib.5 for ; Mon, 20 May 2013 16:56:36 -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=ZrXOjIDfOCu/i53hNt5q99gloxb6fWXjQDbOZjUxRCo=; b=wM5f1hwTywSz3tLJKxOtH05KTnMmjo2a76zLewPr4kFYQ+kgzG0uGkv1J8u8ZAbpku J7K9VfPaeNGT/cw56vpafw+nEEyOvCvi1SXyMDU9U2znDkWU3+j173xF8Ttre6OsXgnh 3iG9HtT1V8eOxwtV5m1A8O0Y115bx/kJrhB1V898M18m1xHB9lswWZesg0g+gD7kJh/p ufw1DYXQronvf4uCUs720orARAvCqmscRfHa4RoBoc9t83q1sC50EZAU64P7ND2i2Tif f9Sz+YuShttIC8lALsRdbIY6QEhLAACdDPt9tfJKhwqDw89x1qO/p7geyKhSPG0gRwge CNsg== MIME-Version: 1.0 X-Received: by 10.180.81.169 with SMTP id b9mr18619538wiy.12.1369094196101; Mon, 20 May 2013 16:56:36 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Mon, 20 May 2013 16:56:35 -0700 (PDT) Date: Mon, 20 May 2013 16:56:35 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=f46d044401ec3908e404dd2f1518 Subject: [apps-discuss] Call for IETF 87 (Berlin) agenda items X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 May 2013 23:56:46 -0000 --f46d044401ec3908e404dd2f1518 Content-Type: text/plain; charset=ISO-8859-1 Colleagues, As usual, we will be requesting a Monday morning slot. This is a call for agenda items, or suggestions for same. Please submit them before June 3rd, which is the cutoff date for submitting or amending meeting requests. We will request the usual 2.5 hour session, but we'll shrink it if our agenda appears to be thin enough. You can expect the usual general structure: - administrivia - APPSAWG section --- recent activity --- current document status and open document issues [*] --- incoming/proposed new work [*] --- other WG business [*] - APPAREA section --- new WGs of interest --- BoF overview --- area-specific topics / AD theatre [*] --- presentations [*] --- AOB [*] If you have something you'd like to present in any of the [*] slots above, please reply to this post. If you will be chairing a BoF or a new WG and would like to present on that, you are also invited to reply for an agenda slot. -MSK, APPSAWG co-chair --f46d044401ec3908e404dd2f1518 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

As usual, we will be requesting a Monday mor= ning slot.=A0 This is a call for agenda items, or suggestions for same.=A0 = Please submit them before June 3rd, which is the cutoff date for submitting= or amending meeting requests.=A0 We will request the usual 2.5 hour sessio= n, but we'll shrink it if our agenda appears to be thin enough.

You can expect the usual general structure:

- admini= strivia
- APPSAWG section
--- recent activity
--= - current document status and open document issues [*]
--- incomin= g/proposed new work [*]
--- other WG business [*]
- APPAREA section
--- new= WGs of interest
--- BoF overview
--- area-specific topic= s / AD theatre [*]
--- presentations [*]
--- AOB [*]

If you have something you'd like to present in any of the [*] slo= ts above, please reply to this post.=A0 If you will be chairing a BoF or a = new WG and would like to present on that, you are also invited to reply for= an agenda slot.

-MSK, APPSAWG co-chair
--f46d044401ec3908e404dd2f1518-- From steve@steveklabnik.com Mon May 20 20:44: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 3B5C821F971F for ; Mon, 20 May 2013 20:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.513 X-Spam-Level: X-Spam-Status: No, score=-1.513 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5ngXLoZZByZ for ; Mon, 20 May 2013 20:44:16 -0700 (PDT) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) by ietfa.amsl.com (Postfix) with ESMTP id 88AED21F971C for ; Mon, 20 May 2013 20:44:16 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id y11so174162pdj.14 for ; Mon, 20 May 2013 20:44:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=8hAectQO27Vl77Da8IcoxbekUJhLJ7p1WH3J/O0JCn8=; b=GQRJZzx9dSrKJrmqqdMeBKUVY7SU55W7iPtSl/5bbcnmPIh3BmawZQ+M288U0WMISj 9IXWQPZt67+QM4wFdFta2ZJm6qrcrWXZb0baGPGarjHiR50Duk5NcYkc319CANWQyvk7 eFJpPy4Q1RDvIZ5eZY+3bOKVl4EGm8Be20oZ3kCBhLEL3/ClIp8JWzOsz+TV0YwkIRrP W8yeAYs+TXdIrhjo8vxlwtIEez14Ok8SPtfyhcmJq4/Th6iwBfxM8eh2jNYqRWx/oOZI kRprLdw17J//ezktE1w8ELY/ir6hQyxD9RHGI1AMRLTd9qhZhaLPhCGPNObdCShAkQnI YmYQ== X-Received: by 10.66.155.39 with SMTP id vt7mr1097744pab.99.1369107856212; Mon, 20 May 2013 20:44:16 -0700 (PDT) Received: from [10.182.52.231] (144.sub-70-197-70.myvzw.com. [70.197.70.144]) by mx.google.com with ESMTPSA id if5sm802126pbb.31.2013.05.20.20.44.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 May 2013 20:44:15 -0700 (PDT) References: <20130520233353.30961.30740.idtracker@ietfa.amsl.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7E2608DA-A06B-4940-A70C-3616AB102808@steveklabnik.com> X-Mailer: iPhone Mail (10B350) From: Steve Klabnik Date: Mon, 20 May 2013 20:44:11 -0700 To: James M Snell X-Gm-Message-State: ALoCoQmu0RFylafOX0wOlJtbK3ugjNN7T7vqDjRw6qiVTwbQVjDJqa+SY1+H9aIkzpRmUGCSDrRA Cc: "internet-drafts@ietf.org" , IETF Apps Discuss , "i-d-announce@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-merge-patch-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: Tue, 21 May 2013 03:44:23 -0000 Unsure if this is the right place for this, but it should be 'its' in the in= troduction. Ill give it a closer look later this evening.= From jasnell@gmail.com Mon May 20 20: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 AD7AA21F9738; Mon, 20 May 2013 20:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.007 X-Spam-Level: X-Spam-Status: No, score=-6.007 tagged_above=-999 required=5 tests=[AWL=-2.408, 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 NToIsG-LdIel; Mon, 20 May 2013 20:51:25 -0700 (PDT) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id C5B4721F9735; Mon, 20 May 2013 20:51:24 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id h1so215038oag.11 for ; Mon, 20 May 2013 20:51: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 :cc:content-type; bh=dXxOqA9V+soxC6wDD58TUnmEpZhI6iDk3Dbk+WEkt3Y=; b=qSDHql0W9qL2zk1i5caCNZPXEvVtSb8/igVc84XzyQSBt7IB2hCWLiMXNds9wNJLc3 D8kSJ8wBEPFFygN7hrMbys/4GQhZLhhtyzfhS9cCCogi1O7fI+nsF1+hgfq2wJycIlBP EJKgK/7Y4ksI+DCRz22M1fdSplb0lzNPPtl4NWC4YnDBm0+GOZjwWYlyM+L8zTIzkOHA 4O1ic7LkojqxzoMGkU7mobrNhHJwguvA2GVum5+QUPES5KGDE2Kj8a4AQ3D5UwlyUrJP 9S+6Cts6qHvczcMLSXlCQgL+PNGosbwj+DjpaDxCERNf2Jj8aJAjxnagp0C0kKRzHz6D kYEg== X-Received: by 10.182.241.194 with SMTP id wk2mr253228obc.77.1369108284338; Mon, 20 May 2013 20:51:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.3.137 with HTTP; Mon, 20 May 2013 20:51:04 -0700 (PDT) In-Reply-To: <7E2608DA-A06B-4940-A70C-3616AB102808@steveklabnik.com> References: <20130520233353.30961.30740.idtracker@ietfa.amsl.com> <7E2608DA-A06B-4940-A70C-3616AB102808@steveklabnik.com> From: James M Snell Date: Mon, 20 May 2013 20:51:04 -0700 Message-ID: To: Steve Klabnik Content-Type: text/plain; charset=UTF-8 Cc: "internet-drafts@ietf.org" , IETF Apps Discuss , "i-d-announce@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-merge-patch-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: Tue, 21 May 2013 03:51:29 -0000 Feel free to use my github repo to report any and all editorial bugs.. pull requests accepted. All technical changes, however, need to be discussed here first :-) https://github.com/jasnell/specs/tree/master/mature On Mon, May 20, 2013 at 8:44 PM, Steve Klabnik wrote: > Unsure if this is the right place for this, but it should be 'its' in the introduction. > > Ill give it a closer look later this evening. From James.H.Manger@team.telstra.com Tue May 21 01: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 4FCD221F979B for ; Tue, 21 May 2013 01:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.291 X-Spam-Level: X-Spam-Status: No, score=-0.291 tagged_above=-999 required=5 tests=[AWL=0.610, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+OWJQgp5oQW for ; Tue, 21 May 2013 01:13:35 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 24E5721F97AB for ; Tue, 21 May 2013 01:13:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,713,1363093200"; d="scan'208";a="136957823" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 21 May 2013 18:13:31 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7081"; a="133420275" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcbvi.tcif.telstra.com.au with ESMTP; 21 May 2013 18:13:31 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Tue, 21 May 2013 18:11:26 +1000 From: "Manger, James H" To: James M Snell , IETF Apps Discuss Date: Tue, 21 May 2013 18:11:25 +1000 Thread-Topic: merge-patch: nulls in arrays Thread-Index: Ac5VsyWGTnPStqYmSLGn/iDapO5vfwAPmtpw Message-ID: <255B9BB34FB7D647A506DC292726F6E1151A6C84BF@WSMSG3153V.srv.dir.telstra.com> References: <20130520233353.30961.30740.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [apps-discuss] merge-patch: nulls in arrays X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 May 2013 08:13:40 -0000 PiA+ICAgICAgICAgVGl0bGUgICAgICAgICAgIDogVGhlIGFwcGxpY2F0aW9uL2pzb24tbWVyZ2Ut cGF0Y2ggTWVkaWEgVHlwZQ0KPiA+ICAgICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0 Zi1hcHBzYXdnLWpzb24tbWVyZ2UtcGF0Y2gtMDAudHh0DQo+ID4NCj4gPiBBYnN0cmFjdDoNCj4g PiAgICBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyB0aGUgYXBwbGljYXRpb24vanNvbi1tZXJn ZS1wYXRjaCBtZWRpYQ0KPiA+ICAgIHR5cGUgYW5kIGl0J3MgaW50ZW5kZWQgdXNlIHdpdGggdGhl IEhUVFAgUEFUQ0ggbWV0aG9kIGRlZmluZWQgYnkNCj4gPiAgICBSRkMgNTc4OS4NCj4gPg0KPiA+ IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXBwc2F3Zy1qc29uLW1lcmdl LXBhdGNoLTAwDQoNCg0KSSBkb24ndCBhZ3JlZSB3aXRoIHRoZSBydWxlcyB0aGF0IGdpdmUgdGhp cyB0ZXN0IGNhc2UgcmVzdWx0Og0KDQpPcmlnaW5hbCAgICAgICBQYXRjaCAgICAgICAgICAgIFJl c3VsdA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCnsiYSI6ImZvbyJ9 ICAgIHsiYiI6IFsgICAgICAgICB7ImEiOiJmb28iLAkNCiAJICAgICAgICAgICAgMywgICAgICAg ICAgICAiYiI6IFszLCB7fV0JDQogCSAgICAgICAgICAgIG51bGwsICAgICAgICB9CQ0KIAkgICAg ICAgICAgICB7IngiOm51bGx9DQogCSAgICAgICAgICAgXQkNCiAJICAgICAgICAgfQ0KDQpUaGUg cnVsZXMgc2hvdWxkIGdpdmUgdGhlIGZvbGxvd2luZyByZXN1bHQ6DQoNCiAgeyJhIjoiZm9vIiwN CiAgICJiIjogWw0KICAgICAzLA0KICAgICBudWxsLA0KICAgICB7IngiOm51bGx9DQogICAgXQ0K ICB9DQoNCkl0IGlzIHBvaW50bGVzcyBtYWtpbmcgdGhlIHJlY2VpdmVyIG9mIGEgcGF0Y2ggcmVt b3ZlIG51bGxzLXdpdGhpbi1hbi1hcnJheSBqdXN0IHRvIGdldCBhIHJlc3VsdCB0aGF0IGlzIGlk ZW50aWNhbCB0byB0aGUgc2VuZGVyIG9mIHRoZSBwYXRjaCBzaW1wbHkgbm90IGluY2x1ZGluZyB0 aG9zZSBudWxscy13aXRoaW4tYW4tYXJyYXkgaW4gdGhlIGZpcnN0IHBsYWNlLg0KDQpUaGUgc3Bl YyBzYXlzICJKU09OIGFycmF5cyBhcmUgdHJlYXRlZCB0aGUgc2FtZSBhcyBKU09OIHByaW1pdGl2 ZXMiLiBUaGlzIHNob3VsZCBiZSByZWZsZWN0ZWQgaW4gdGhlIHByb2Nlc3NpbmcgcnVsZXMgKGFu ZCB0aGVuIHRoZSB0ZXN0IGNhc2UpLiBJbXBsZW1lbnRhdGlvbnMgc2hvdWxkbid0IG5lZWQgdG8g bG9vayBpbnNpZGUgYXJyYXlzLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From James.H.Manger@team.telstra.com Tue May 21 06:50:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85CC821F93E8 for ; Tue, 21 May 2013 06:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.537 X-Spam-Level: X-Spam-Status: No, score=0.537 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_20=-0.74, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fneXpuzo1Tnu for ; Tue, 21 May 2013 06:50:29 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 889B721F955C for ; Tue, 21 May 2013 06:50:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,714,1363093200"; d="scan'208";a="136995960" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 21 May 2013 23:50:24 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7081"; a="133220127" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcdvi.tcif.telstra.com.au with ESMTP; 21 May 2013 23:50:23 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Tue, 21 May 2013 23:50:23 +1000 From: "Manger, James H" To: IETF Apps Discuss , James M Snell Date: Tue, 21 May 2013 23:50:20 +1000 Thread-Topic: merge-patch: more examples Thread-Index: Ac5WKiKQ77gpB95DRUiTqnNuebnNxw== Message-ID: <255B9BB34FB7D647A506DC292726F6E1151A6C8594@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [apps-discuss] merge-patch: more examples X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 May 2013 13:50:35 -0000 VGhlIGxpc3Qgb2YgdGVzdCBjYXNlcyBpbiBkcmFmdC1pZXRmLWFwcHNhd2ctanNvbi1tZXJnZS1w YXRjaCBpcyBhIGdyZWF0IGFkZGl0aW9uLg0KDQpBIGNvdXBsZSBtb3JlIHdvdWxkIGJlIHdvcnRo d2hpbGUgdG8gaWxsdXN0cmF0ZSBzb21lIGxlc3MgaW50dWl0aXZlIGNhc2VzOg0KDQogICBPUklH SU5BTCAgICAgUEFUQ0ggICAgICAgICAgICAgICAgICAgICAgIFJFU1VMVA0KICAgLS0tLS0tLS0t LSAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gICAtLS0tLS0tLS0tLS0tLS0tDQoNCjEuIHsi ZSI6bnVsbH0gICB7ImEiOjF9ICAgICAgICAgICAgICAgICAgICAgeyJlIjpudWxsLCJhIjoxfQ0K DQoyLiB7fSAgICAgICAgICAgeyJhIjp7ImJiIjp7ImNjYyI6bnVsbH19fSAgIHsiYSI6eyJiYiI6 e319fQ0KDQoxLiBzaG93cyB0aGF0IGEgZmllbGQgbm90IG1lbnRpb25lZCBpbiBhIHBhdGNoIChl ZyAiZSIpIGlzIHVuY2hhbmdlZCwgZXZlbiB3aGVuIGl0IGhhcyBhIG51bGwgdmFsdWUuDQoNCjIu IHNob3dzIHRoYXQgYSBwYXRjaCB0aGF0IHN1cGVyZmljaWFsbHkgYXBwZWFycyBvbmx5IHRvIGJl IHJlbW92aW5nIGEgbmVzdGVkIGZpZWxkIChlZyAiY2NjIikgY2FuIGFjdHVhbGx5IGNyZWF0ZSB0 aGUgcGFyZW50IG9iamVjdHMgb24gdGhlIHdheSB0byB0aGF0IG5lc3RlZCBmaWVsZC4NCg0KDQpQ LlMuIEl0IG1pZ2h0IG1ha2UgdGhlIGV4YW1wbGVzIGEgYml0IG1vcmUgcmVhZGFibGUgaWYgImEi LCAiYiIsICJjIiB3aGVyZSBvbmx5IHVzZWQgYXMgZmllbGQgbmFtZXMsIG5vdCB2YWx1ZXMgKGVn IHsiYSI6MX0gaW5zdGVhZCBvZiB7ImEiOiJiIn0pLiBJdCBtaWdodCBhbHNvIGJlIGEgYml0IG1v cmUgcmVhZGFibGUgaWYgdGhlIHNhbWUgZmllbGQgYWx3YXlzIGhhZCB0aGUgc2FtZSB2YWx1ZSBp biB0aGUgb3JpZ2luYWwgY29sdW1uIChlZyAiYSI6MSwgImIiOjIsICJjIjpbMywxLDRdLCAiZCI6 eyJkZCI6eyJkZGQiOjR9fSwgImUiOm51bGwpLiANCg0KLS0NCkphbWVzIE1hbmdlcg0K From jasnell@gmail.com Tue May 21 08:04: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 9ECD321F8E34 for ; Tue, 21 May 2013 08:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.951 X-Spam-Level: X-Spam-Status: No, score=-4.951 tagged_above=-999 required=5 tests=[AWL=-3.211, BAYES_20=-0.74, 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 hfAL07ZamPko for ; Tue, 21 May 2013 08:04:41 -0700 (PDT) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id 45ACC21F8A00 for ; Tue, 21 May 2013 08:04:35 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id i4so918025oah.7 for ; Tue, 21 May 2013 08:04: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=1e61UgvF8ZC9u7Q1GEwEbp9Oz08gvp7wM1kBdkwqDeM=; b=vtqfH57aZM/EG2v9/5RKbDt5dEUpjkER3JKjNB9MDNDV9Ni0CdDHAycRJFQa8DH7d6 LBlWwkgliTcMPbo7Lz6RUInzZf22OYnKCxuKSHCiqPx2+fFfOAa/vRRjGnZCkQhQzW5w xc8yi6ZjpmOrWOwpXatXxWgj3gMS6W/GbClKdM8Cst8el+UBNdh0cqqNLNj+02Qmm8oE 9xb/d3UcQOKIamKFZtfB/IeVHIkM15D+HQ3C4KpOQabV76dUCXMnM2HVnt3NSN+LYRZ0 /HQI5IayrHtoxDremNbuZeq+ydXz00nRnzyzkUVx+BIw2+MCQ94+hClorDJ69fT9iEy0 m4ug== X-Received: by 10.60.47.81 with SMTP id b17mr1704267oen.63.1369148674699; Tue, 21 May 2013 08:04:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.3.137 with HTTP; Tue, 21 May 2013 08:04:14 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151A6C8594@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1151A6C8594@WSMSG3153V.srv.dir.telstra.com> From: James M Snell Date: Tue, 21 May 2013 08:04:14 -0700 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IETF Apps Discuss Subject: Re: [apps-discuss] merge-patch: more examples X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 May 2013 15:04:45 -0000 Good suggestions. I can make these changes in the next iteration, or, if you're so inclined, feel free to submit a pull request against the github repo [1] [1] https://github.com/jasnell/specs/tree/master/mature - James On Tue, May 21, 2013 at 6:50 AM, Manger, James H wrote: > The list of test cases in draft-ietf-appsawg-json-merge-patch is a great = addition. > > A couple more would be worthwhile to illustrate some less intuitive cases= : > > ORIGINAL PATCH RESULT > ---------- ------------------------- ---------------- > > 1. {"e":null} {"a":1} {"e":null,"a":1} > > 2. {} {"a":{"bb":{"ccc":null}}} {"a":{"bb":{}}} > > 1. shows that a field not mentioned in a patch (eg "e") is unchanged, eve= n when it has a null value. > > 2. shows that a patch that superficially appears only to be removing a ne= sted field (eg "ccc") can actually create the parent objects on the way to = that nested field. > > > P.S. It might make the examples a bit more readable if "a", "b", "c" wher= e only used as field names, not values (eg {"a":1} instead of {"a":"b"}). I= t might also be a bit more readable if the same field always had the same v= alue in the original column (eg "a":1, "b":2, "c":[3,1,4], "d":{"dd":{"ddd"= :4}}, "e":null). > > -- > James Manger From ietf-secretariat-reply@ietf.org Mon May 20 16:41: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 9FE5C21F9698 for ; Mon, 20 May 2013 16:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.066, 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 EM7JqOLe7ipd for ; Mon, 20 May 2013 16:41:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0788E21F96A2 for ; Mon, 20 May 2013 16:41:07 -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.50 Message-ID: <20130520234107.5971.29416.idtracker@ietfa.amsl.com> Date: Mon, 20 May 2013 16:41:07 -0700 From: IETF Secretariat X-Mailman-Approved-At: Tue, 21 May 2013 08:04:51 -0700 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: Mon, 20 May 2013 23:41:07 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-webfinger", set due date to March 2013 from March 2013. Changed milestone "Publication requested for draft-ietf-appsawg-malformed-mail", set due date to September 2013 from January 2013. URL: http://datatracker.ietf.org/wg/appsawg/charter/ From ietf-secretariat-reply@ietf.org Mon May 20 16:42:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7918321F9698 for ; Mon, 20 May 2013 16:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.066, 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 YD-1ajGHrX8Z for ; Mon, 20 May 2013 16:42:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F0021F96B3 for ; Mon, 20 May 2013 16:42:34 -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.50 Message-ID: <20130520234234.29152.4979.idtracker@ietfa.amsl.com> Date: Mon, 20 May 2013 16:42:34 -0700 From: IETF Secretariat X-Mailman-Approved-At: Tue, 21 May 2013 08:05:09 -0700 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: Mon, 20 May 2013 23:42:35 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-json-merge-patch", added draft-ietf-appsawg-json-merge-patch to milestone. URL: http://datatracker.ietf.org/wg/appsawg/charter/ From ietf-secretariat-reply@ietf.org Tue May 21 06:09: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 38FFC21F9768 for ; Tue, 21 May 2013 06:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.066, 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 WIWTf2DUimSA for ; Tue, 21 May 2013 06:09:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED0C21F9769 for ; Tue, 21 May 2013 06:09:22 -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.50 Message-ID: <20130521130922.8711.51393.idtracker@ietfa.amsl.com> Date: Tue, 21 May 2013 06:09:22 -0700 From: IETF Secretariat X-Mailman-Approved-At: Tue, 21 May 2013 08:05:09 -0700 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: Tue, 21 May 2013 13:09:26 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-json-merge-patch", set state to active from review, accepting new milestone. Changed milestone "Publication requested for draft-ietf-appsawg-xml-mediatypes", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/appsawg/charter/ From jasnell@gmail.com Tue May 21 08:08:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F00821F986F for ; Tue, 21 May 2013 08:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.72 X-Spam-Level: X-Spam-Status: No, score=-5.72 tagged_above=-999 required=5 tests=[AWL=-2.121, 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 TzczGzrdKXPe for ; Tue, 21 May 2013 08:08:30 -0700 (PDT) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id C8E5321F9808 for ; Tue, 21 May 2013 08:08:29 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id o17so948224oag.13 for ; Tue, 21 May 2013 08:08:27 -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=/9J+yOxq4DwYauw/oqTelIMyujINhZmB4vHYo5/mFB0=; b=FHZ3/FNK8cxTfkGmvYCrxD82GbdJgV+aRCoW4J+m1ywK9GGmM//gyIG+hTrV1Aosnj 29shTfNvTLkYZVV2PJ7Ocdlyexd+9r8oAk/LThHInMI3Mnt3XICyOsG28aT+BW0i55tP BTDo/cNTmAMmt7z1zg368x4CcU3pwEz89TWgQnsIpK7P/XoL3FzyvDYkF+2ULUx0O7G9 L3oKXQ7x0R911zVv/pQUznjo1kYJ1MLCAb87CF3WEiJoNEbdK/ayPK7Lkq27uCH1AA9/ Q8n+1o2+CxX1N/AFqBQj4GzpDuNbFh0i7fRdoT1z7BqNs6DBvk+qsV5NdeVXyvygj6M5 Ih7g== X-Received: by 10.60.16.69 with SMTP id e5mr1729321oed.46.1369148907018; Tue, 21 May 2013 08:08:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.3.137 with HTTP; Tue, 21 May 2013 08:08:06 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151A6C84BF@WSMSG3153V.srv.dir.telstra.com> References: <20130520233353.30961.30740.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E1151A6C84BF@WSMSG3153V.srv.dir.telstra.com> From: James M Snell Date: Tue, 21 May 2013 08:08:06 -0700 Message-ID: To: "Manger, James H" Content-Type: text/plain; charset=UTF-8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] merge-patch: nulls in arrays X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 May 2013 15:08:35 -0000 On Tue, May 21, 2013 at 1:11 AM, Manger, James H wrote: [snip] > > It is pointless making the receiver of a patch remove nulls-within-an-array just to get a result that is identical to the sender of the patch simply not including those nulls-within-an-array in the first place. > > The spec says "JSON arrays are treated the same as JSON primitives". This should be reflected in the processing rules (and then the test case). Implementations shouldn't need to look inside arrays. > The spec also states that Null specifically that "The JSON null value is given a special meaning to indicate the removal of an existing value". A merge-patch document should not include any null values unless it is specifically intending to remove something from the target document. The fact that nulls in arrays were not appropriately dealt with previously is a spec bug, not a feature ;-) ... - James > -- > James Manger From steve@steveklabnik.com Tue May 21 08:36: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 0391E21F8A0B for ; Tue, 21 May 2013 08:36:01 -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 skd7x+X6zCWD for ; Tue, 21 May 2013 08:35:56 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1940421F87CB for ; Tue, 21 May 2013 08:35:39 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id u16so2075991iet.28 for ; Tue, 21 May 2013 08:35:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=vWaUMZV0Ux5DeTcOZ7AF2SVCkfJKhb5gwn6fjZwvYQg=; b=i/hRmVDsBRHm4Irdc8dWdDNf4mRvmau7ucRkT8OI1KhrTSwRdRuyQJO/aOyFeJ0e4n C7Bi0o5ljHJguAkrnNec/aIEiDEnNQ7++1HWaBMoLObbXI3m3nH2Fnu2ZkfUnGmOyAe1 FevwxFEPye9uwwfbVMQFVY9kxsC8DC2WOcDblnmmw7U97K95/+5HEHlVSTXtnSDBE0T0 9nPjx086UesM/+TMvSxO/ToAQ0TODz8sC57NDQf9QsM4GBZX4ZE52tHNBqPGY3jTFYzO aq09Fz+xo2tGe1EI+GeJIwGT/q1NvJAIv9O86SHT7p6DDuO9desZeRteaNUZ+1YSgUZd lucg== MIME-Version: 1.0 X-Received: by 10.50.120.4 with SMTP id ky4mr1677166igb.86.1369150539588; Tue, 21 May 2013 08:35:39 -0700 (PDT) Received: by 10.64.163.3 with HTTP; Tue, 21 May 2013 08:35:39 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1151A6C8594@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 21 May 2013 08:35:39 -0700 Message-ID: From: Steve Klabnik To: James M Snell Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlinQ1SXJlU+rJv75imPEL/Fz990gjA3qiDqwed/IZKzJ/KhiiyWOTQX3B17Sj+zUtrUH5x Cc: IETF Apps Discuss Subject: Re: [apps-discuss] merge-patch: more examples X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 May 2013 15:36:01 -0000 It might also be nice to make an analogue to https://github.com/json-patch/json-patch-tests From jasnell@gmail.com Tue May 21 09:14: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 C002B21F93B9 for ; Tue, 21 May 2013 09:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.735 X-Spam-Level: X-Spam-Status: No, score=-5.735 tagged_above=-999 required=5 tests=[AWL=-2.136, 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 KDHJvk54agSe for ; Tue, 21 May 2013 09:14:38 -0700 (PDT) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id 00C3121F9545 for ; Tue, 21 May 2013 09:14:34 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id k14so1074467oag.36 for ; Tue, 21 May 2013 09:14: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:from:date:message-id:subject:to :cc:content-type; bh=c0uBQnpp29LY6lxKWznEe4Nvp2aSntQPTVHyIagvLWQ=; b=iK3190TMw0TW5EJgC63Pk5+JWCXI+ua4HOYnYYvh2O0v6cvqFEEfjNWB7xzPkzCpDL SHAtdTnhTH5XUmKAlMLCG8Gm72Pg0OZri0Ka2nVqvVnFo2+E5TRcW65DNLECicFqvldf 9InC1HNEPeA0tufwaX2SskBmIiVjycK5eEvCLxq8CDF7Xu4Hn++FEeetixP/mSH2LCQt Obf+p3ub6UwMbP/vbEyBR6qnYVap9u134j06SGYSgHX2lETC7p8cG77Or1Wx8ng2Xy8T 0b3eld7oKrp8Q9P7U2nrMsV6y33GnLgyHEqgr4sPB3WNcb1QBzIgv+WYrs2wpGlXD33K iHxg== X-Received: by 10.60.102.178 with SMTP id fp18mr1925541oeb.35.1369152874529; Tue, 21 May 2013 09:14:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.3.137 with HTTP; Tue, 21 May 2013 09:14:14 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1151A6C8594@WSMSG3153V.srv.dir.telstra.com> From: James M Snell Date: Tue, 21 May 2013 09:14:14 -0700 Message-ID: To: Steve Klabnik Content-Type: text/plain; charset=UTF-8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] merge-patch: more examples X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 May 2013 16:14:44 -0000 Agreed. The example test cases in the spec are intended to help bootstrap such an effort. If you'd like to get a repo set up, or, perhaps, if Mark would be willing to let us expand the existing repo to deal with merge-patch tests, I'll contribute whatever test casesI can. On Tue, May 21, 2013 at 8:35 AM, Steve Klabnik wrote: > It might also be nice to make an analogue to > https://github.com/json-patch/json-patch-tests From ietf-secretariat-reply@ietf.org Tue May 21 09:14: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 67D8921F95D7 for ; Tue, 21 May 2013 09:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.065, 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 aoJlKPcUDzML for ; Tue, 21 May 2013 09:14:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F0F21F94F5 for ; Tue, 21 May 2013 09:14:45 -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.50 Message-ID: <20130521161444.10234.39705.idtracker@ietfa.amsl.com> Date: Tue, 21 May 2013 09:14:44 -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: Tue, 21 May 2013 16:14:47 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-malformed-mail", added draft-ietf-appsawg-malformed-mail to milestone. URL: http://datatracker.ietf.org/wg/appsawg/charter/ From ietf-secretariat-reply@ietf.org Tue May 21 10:37: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 E323221F9856 for ; Tue, 21 May 2013 10:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.065, 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 2k3AvfbcMy3X for ; Tue, 21 May 2013 10:37:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC1D21F986B for ; Tue, 21 May 2013 10:37:39 -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.50 Message-ID: <20130521173739.2581.97966.idtracker@ietfa.amsl.com> Date: Tue, 21 May 2013 10:37:39 -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: Tue, 21 May 2013 17:37:40 -0000 URL: http://datatracker.ietf.org/wg/appsawg/charter/ From turners@ieca.com Tue May 21 11:34: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 36EA121F85E8 for ; Tue, 21 May 2013 11:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 JzTYAkCA8iJc for ; Tue, 21 May 2013 11:34:49 -0700 (PDT) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [69.41.255.11]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF0521F85DC for ; Tue, 21 May 2013 11:34:48 -0700 (PDT) Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id 800FC62458CE0; Tue, 21 May 2013 13:34:48 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway15.websitewelcome.com (Postfix) with ESMTP id 741F662458CA2 for ; Tue, 21 May 2013 13:34:48 -0500 (CDT) Received: from [173.73.135.101] (port=64583 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UerOa-0000B6-7l; Tue, 21 May 2013 13:34:48 -0500 Message-ID: <519BBE47.9050407@ieca.com> Date: Tue, 21 May 2013 14:34:47 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: saag@ietf.org, apps-discuss@ietf.org References: <20130521183122.29537.74465.idtracker@ietfa.amsl.com> In-Reply-To: <20130521183122.29537.74465.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130521183122.29537.74465.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:64583 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [apps-discuss] Fwd: I-D Action: draft-turner-application-cms-media-type-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: Tue, 21 May 2013 18:34:54 -0000 Comments welcomed. spt -------- Original Message -------- Subject: I-D Action: draft-turner-application-cms-media-type-01.txt Date: Tue, 21 May 2013 11:31:22 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The application/cms media type Author(s) : Sean Turner Russell Housley Jim Schaad Filename : draft-turner-application-cms-media-type-01.txt Pages : 8 Date : 2013-05-21 Abstract: This document registers the application/cms media types for use with the corresponding CMS (Cryptographic Message Syntax) content types. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-turner-application-cms-media-type There's also a htmlized version available at: http://tools.ietf.org/html/draft-turner-application-cms-media-type-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-turner-application-cms-media-type-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From alexey.melnikov@isode.com Tue May 21 14:57: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 B077021F9603 for ; Tue, 21 May 2013 14:57:53 -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 9OO0QYY1-uYj for ; Tue, 21 May 2013 14:57:49 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 147C421F95FD for ; Tue, 21 May 2013 14:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1369173468; d=isode.com; s=selector; i=@isode.com; bh=e3n3OuPmocwcLXgCCW2YAZ2u2UyMArqUiVd1CSq6JmI=; 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=dUWEKjspFvbdt+zUf7iy1pHGz+28ij+dOaYIaICD7CuILX5yx6fro+JN33+qQrCJ2uC55f aArofoUnpz3WIv4/lXvA0OhCJLQOuS4SA5owJPXneQgJiMc/VfC8lSh8EXM4VHEl7LKDms hDdumMpO4stezLRCp94gZAkYj63w76I=; Received: from [172.20.10.2] ((unknown) [212.183.140.62]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 21 May 2013 22:57:45 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <519BE7D4.6070504@isode.com> Date: Tue, 21 May 2013 22:32:04 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: S Moonesamy References: <20130519052116.75996.qmail@joyce.lan> <6.2.5.6.2.20130519232054.06b2a318@resistor.net> In-Reply-To: <6.2.5.6.2.20130519232054.06b2a318@resistor.net> 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] Slash and version number in Authentication-results: 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, 21 May 2013 21:57:53 -0000 On 20/05/2013 08:14, S Moonesamy wrote: > Hi Alexey, > > Scott Kitterman mentioned [1] that the following: > > authres-header = "Authentication-Results:" [CFWS] authserv-id > [ [CFWS] "/" [CFWS] authres-version ] > > 'is an incompatible change and if you really want to make it, you should > bump the version number. I checked and with authres, your example is > mis-parsed. > > Authentication-Results: example.org/1; none > > In this example, the authserv-id is "example.org", but authres, > using the > RFC 5451 ABNF parses this and determines the authserv-id is > "example.org/1"' > > Murray Kucherawy commented that he has "yet to see a single > implementation that includes a version number in its output, though > there are some that do look for it" [2]. John Levine responded that > his implementation does [3]. He also mentioned that the introduction > of the slash (see ABNF) creates an incompatibility. > > There is also the following in Section 5 of > draft-ietf-appsawg-rfc5451bis-02: > > "An MTA SHOULD remove any instance of this header field bearing a > version (express or implied) that it does not support." > > Will the addition of the slash cause an interoperability issue? It looks like it might. I haven't implemented the spec yet (although I intend to), so this would not affect my [yet-to-be-written] implementation. > Regards, > S. Moonesamy > > 1. > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09460.html > 2. > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09463.html > 3. > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09465.html > From superuser@gmail.com Tue May 21 15:58: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 0AF7411E80B8 for ; Tue, 21 May 2013 15:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 wGWIpIeX+OPU for ; Tue, 21 May 2013 15:58:00 -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 354E711E80A6 for ; Tue, 21 May 2013 15:58:00 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id u57so693395wes.40 for ; Tue, 21 May 2013 15: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=cNp2n6Mcel5JVxQ++qmMB8jJvdmZpBAuLNlI497kpMI=; b=qiFzyw9RtcYfP3yQEz7xcz9S2ExE/p7UDF8rHbHcJ+XBwqYMBRwuj6q8NM8nSeMbSM PeHgOkpiJiKf09x7dDUpwyTtOqwAiPqeOkBnoUu1sDuuo+JObvQgpXFFYVF8zSZHv6BY 1IgnCnpa/v8TSz4uYwSWwRROZLpiE1ElhmW2uYlk2oTrsayOLqOnpwVmMmZIn669ar3h jdT084cyAJ7ZTFff1BWCHrD4iAjxz4YhamGzHzzGm5r2VkvoSS6mrU3VZ50ETzfR2zDr RW8ucnG9gGTN74juUhoFJ84qn/whTPJa0hBLl/Gc3V4vTc9JyOoTujDspwqS0ZVHzkPx TghA== MIME-Version: 1.0 X-Received: by 10.180.37.133 with SMTP id y5mr9020627wij.20.1369177079363; Tue, 21 May 2013 15:57:59 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Tue, 21 May 2013 15:57:59 -0700 (PDT) In-Reply-To: <5182b488.c4d60e0a.1ff8.0d8cSMTPIN_ADDED_BROKEN@mx.google.com> References: <516e8a54.45f7440a.7dcc.1253SMTPIN_ADDED_BROKEN@mx.google.com> <516f06c9.c1c20e0a.46f3.ffffb0bfSMTPIN_ADDED_BROKEN@mx.google.com> <51782a0a.21f2440a.747e.5f13SMTPIN_ADDED_BROKEN@mx.google.com> <5182b488.c4d60e0a.1ff8.0d8cSMTPIN_ADDED_BROKEN@mx.google.com> Date: Tue, 21 May 2013 15:57:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: Markus Lanthaler Content-Type: multipart/alternative; boundary=e89a8f50335a733ea404dd4261c9 Cc: Barry Leiba , IETF Apps Discuss Subject: Re: [apps-discuss] FW: New Version Notification for draft-lanthaler-profile-registry-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: Tue, 21 May 2013 22:58:01 -0000 --e89a8f50335a733ea404dd4261c9 Content-Type: text/plain; charset=ISO-8859-1 Hi Markus, sorry for the delayed reply. On Thu, May 2, 2013 at 11:46 AM, Markus Lanthaler wrote: > Thanks for your your support Dave. > > Barry, Murray: How do we proceed? Is there anything I can/should do at this > point? > > There hasn't been much expression of interest in supporting this document in terms of reviews. Only one person other than you committed to doing so, though a couple of people did say they felt this was procedurally the right place to do the work. I'll pose the question again: Does the WG feel that this is something we should process here? Are there people (other than Dave Cridland) willing to commit time to doing reviews and commenting? -MSK, co-chair --e89a8f50335a733ea404dd4261c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --e89a8f50335a733ea404dd4261c9-- From James.H.Manger@team.telstra.com Tue May 21 17:44: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 0068021F9180 for ; Tue, 21 May 2013 17:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[AWL=0.569, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDQd2pwiHXeO for ; Tue, 21 May 2013 17:43:52 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 7F83121F90EB for ; Tue, 21 May 2013 17:43:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,717,1363093200"; d="scan'208";a="130190670" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 22 May 2013 10:43:50 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7082"; a="138151774" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipccni.tcif.telstra.com.au with ESMTP; 22 May 2013 10:43:50 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Wed, 22 May 2013 10:43:50 +1000 From: "Manger, James H" To: James M Snell Date: Wed, 22 May 2013 10:43:48 +1000 Thread-Topic: merge-patch: nulls in arrays Thread-Index: Ac5WNQ2Gz4R4HtEDSUOE5qSey86UagARxvJQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1151A7E2142@WSMSG3153V.srv.dir.telstra.com> References: <20130520233353.30961.30740.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E1151A6C84BF@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] merge-patch: nulls in arrays X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 00:44:02 -0000 PiA8SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbT4gd3JvdGU6DQo+IFtzbmlwXQ0KPiA+ DQo+ID4gSXQgaXMgcG9pbnRsZXNzIG1ha2luZyB0aGUgcmVjZWl2ZXIgb2YgYSBwYXRjaCByZW1v dmUgbnVsbHMtd2l0aGluLQ0KPiBhbi1hcnJheSBqdXN0IHRvIGdldCBhIHJlc3VsdCB0aGF0IGlz IGlkZW50aWNhbCB0byB0aGUgc2VuZGVyIG9mIHRoZQ0KPiBwYXRjaCBzaW1wbHkgbm90IGluY2x1 ZGluZyB0aG9zZSBudWxscy13aXRoaW4tYW4tYXJyYXkgaW4gdGhlIGZpcnN0DQo+IHBsYWNlLg0K PiA+DQo+ID4gVGhlIHNwZWMgc2F5cyAiSlNPTiBhcnJheXMgYXJlIHRyZWF0ZWQgdGhlIHNhbWUg YXMgSlNPTiBwcmltaXRpdmVzIi4NCj4gVGhpcyBzaG91bGQgYmUgcmVmbGVjdGVkIGluIHRoZSBw cm9jZXNzaW5nIHJ1bGVzIChhbmQgdGhlbiB0aGUgdGVzdA0KPiBjYXNlKS4gSW1wbGVtZW50YXRp b25zIHNob3VsZG4ndCBuZWVkIHRvIGxvb2sgaW5zaWRlIGFycmF5cy4NCg0KSmFtZXMgU25lbGwg d3JvdGU6DQo+IFRoZSBzcGVjIGFsc28gc3RhdGVzIHRoYXQgTnVsbCBzcGVjaWZpY2FsbHkgdGhh dCAiVGhlIEpTT04gbnVsbCB2YWx1ZQ0KPiBpcyBnaXZlbiBhIHNwZWNpYWwgbWVhbmluZyB0byBp bmRpY2F0ZSB0aGUgcmVtb3ZhbCBvZiBhbiBleGlzdGluZw0KPiB2YWx1ZSIuIEEgbWVyZ2UtcGF0 Y2ggZG9jdW1lbnQgc2hvdWxkIG5vdCBpbmNsdWRlIGFueSBudWxsIHZhbHVlcw0KPiB1bmxlc3Mg aXQgaXMgc3BlY2lmaWNhbGx5IGludGVuZGluZyB0byByZW1vdmUgc29tZXRoaW5nIGZyb20gdGhl IHRhcmdldA0KPiBkb2N1bWVudC4gVGhlIGZhY3QgdGhhdCBudWxscyBpbiBhcnJheXMgd2VyZSBu b3QgYXBwcm9wcmlhdGVseSBkZWFsdA0KPiB3aXRoIHByZXZpb3VzbHkgaXMgYSBzcGVjIGJ1Zywg bm90IGEgZmVhdHVyZSA7LSkgLi4uDQoNCg0KUmVtb3ZpbmcgbnVsbHMgaW4gYXJyYXlzIG1lYW5z IHRoZSBwYXRjaCBwcm9jZXNzIGNhbiBiZSBkZXNjcmliZWQgaW4gMiBzdGFnZXM6DQoNClN0YWdl IDE6IFdhbGsgdGhyb3VnaCBvYmplY3RzIGFuZCBhcnJheXMgaW4gdGhlIHBhdGNoIHJlbW92aW5n IGFueSBudWxscyBpbnNpZGUgYXJyYXlzLCByZXN1bHRpbmcgaW4gYSBtb2RpZmllZCBwYXRjaC4N Cg0KU3RhZ2UgMjogV2FsayB0aHJvdWdoIG9iamVjdHMgaW4gdGhlIGRvY3VtZW50IGFuZCBtb2Rp ZmllZCBwYXRjaCB0b2dldGhlciAtLSBhZGRpbmcsIHJlcGxhY2luZyBvciBkZWxldGluZyBvYmpl Y3QgZWxlbWVudHMuDQoNClN0YWdlIDEgYWRkcyB6ZXJvIGZ1bmN0aW9uYWxpdHkuIFN0YXJ0aW5n IHdpdGggdGhlIG1vZGlmaWVkIHBhdGNoIGFjaGlldmVzIGFuIGlkZW50aWNhbCByZXN1bHQuIFN0 YWdlIDEgZG9lcyBhZGRzIGV4dHJhIHdvcmsgKGV4dHJhIGNvZGUsIGV4dHJhIHRpbWUpIGZvciB0 aGUgcGF0Y2ggcHJvY2Vzc29yLiBObyAobGVnaXRpbWF0ZSkgcGF0Y2hlcyB3aWxsIGV2ZXIgaW5j bHVkZSBudWxscy1pbi1hcnJheXMgdGhhdCB0aGV5IGhhdmUgemVybyBpbXBhY3Qgb24gdGhlIHJl c3VsdC4gVGhlIGxpa2VseSBjb25zZXF1ZW5jZSBpcyB0aGF0IHRoZSBleHRyYSBjb2RlIHRvIHJl bW92ZSB0aG9zZSBudWxsIHdpbGwgYmUgaW1wbGVtZW50ZWQgcG9vcmx5LCBpZiBhdCBhbGwuDQoN ClN0YWdlIDEgcmVtb3ZlcyBzb21lIGZ1bmN0aW9uYWxpdHkuIEl0IGZ1cnRoZXIgcmVzdHJpY3Rz IHRoZSBKU09OIHZhbHVlcyB0aGF0IGNhbiBiZSBjcmVhdGVkIGJ5IGEgbWVyZ2UtcGF0Y2guDQoN CklmIHRoZSByYXRpb25hbGUgaXMgdGhhdCAiYWxsIG51bGxzIGFyZSBzcGVjaWFsIiwgdGhlbiBz aWxlbnRseSByZW1vdmluZyB0aGVtIGZyb20gcGF0Y2hlcyBpcyBub3QgYXBwcm9wcmlhdGUuIEl0 IHdvdWxkIGJlIG1vcmUgYXBwcm9wcmlhdGUgdG8gY2hhbmdlIHN0YWdlIDEgdG8gdGhyb3cgYW4g ZXJyb3IgaWYgYSBwYXRjaCBpbmNsdWRlcyBhbnkgbnVsbHMgaW4gYW4gYXJyYXkuDQoNCkRyb3Bw aW5nIHN0YWdlIDEgaXMgdGhlIHNlbnNpYmxlIGFwcHJvYWNoLg0KDQotLQ0KSmFtZXMgTWFuZ2Vy DQo= From jasnell@gmail.com Tue May 21 18:06: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 0EE5921F933B for ; Tue, 21 May 2013 18:06: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=[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 62OsilNmBvPR for ; Tue, 21 May 2013 18:06:19 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id A72B021F92F4 for ; Tue, 21 May 2013 18:06:19 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id wp18so1534405obc.7 for ; Tue, 21 May 2013 18:06: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:date:message-id:subject:from:to :cc:content-type; bh=5LmqhnylQ3+TuyIsoMpup46kSM7hhrbmByqruf2F10Y=; b=cC1P2JoX0mhkq2sfTFY/Nu2Gb81VgKMu3vIidq+uA3qqDqtZ9wgeqkaDag4pR2oXgm S+6MbZ/OnFTaYZC27paAJrH72J1B0fAp7vkm13aCItteliOUzWeXvFn9idQjZrMGbuza dh8vPztSx3hsPtcrVtvNsa/2agww9V36JRYtOdbJUszuGBhkmvmASxDA4+dsaOG3eVDB NsM4H2/dQVlwyvgb+zxXbN2SN4goqkvce0YDBi/nJoGdDjJbEC+wgloSMcOL3OlcLDIC /PoALQim5w4S+wgxTvyT2X0fXlA4T2LYHhLufY7E6S8Ju1je7XQbADvzGWzxygFdM1lO r7cw== MIME-Version: 1.0 X-Received: by 10.60.92.41 with SMTP id cj9mr3187233oeb.31.1369184779155; Tue, 21 May 2013 18:06:19 -0700 (PDT) Received: by 10.60.3.137 with HTTP; Tue, 21 May 2013 18:06:19 -0700 (PDT) Received: by 10.60.3.137 with HTTP; Tue, 21 May 2013 18:06:19 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151A7E2142@WSMSG3153V.srv.dir.telstra.com> References: <20130520233353.30961.30740.idtracker@ietfa.amsl.com> <255B9BB34FB7D647A506DC292726F6E1151A6C84BF@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1151A7E2142@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 21 May 2013 18:06:19 -0700 Message-ID: From: James M Snell To: James H Manger Content-Type: multipart/alternative; boundary=047d7b33d31c64bf2304dd442c05 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] merge-patch: nulls in arrays X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 01:06:21 -0000 --047d7b33d31c64bf2304dd442c05 Content-Type: text/plain; charset=UTF-8 Alternatively, one can simply not send a merge patch with null array elements. At this point, however, it's just you and I talking back and forth. Let's let others have a chance to weigh in on it. On May 21, 2013 5:44 PM, "Manger, James H" wrote: > > wrote: > > [snip] > > > > > > It is pointless making the receiver of a patch remove nulls-within- > > an-array just to get a result that is identical to the sender of the > > patch simply not including those nulls-within-an-array in the first > > place. > > > > > > The spec says "JSON arrays are treated the same as JSON primitives". > > This should be reflected in the processing rules (and then the test > > case). Implementations shouldn't need to look inside arrays. > > James Snell wrote: > > The spec also states that Null specifically that "The JSON null value > > is given a special meaning to indicate the removal of an existing > > value". A merge-patch document should not include any null values > > unless it is specifically intending to remove something from the target > > document. The fact that nulls in arrays were not appropriately dealt > > with previously is a spec bug, not a feature ;-) ... > > > Removing nulls in arrays means the patch process can be described in 2 > stages: > > Stage 1: Walk through objects and arrays in the patch removing any nulls > inside arrays, resulting in a modified patch. > > Stage 2: Walk through objects in the document and modified patch together > -- adding, replacing or deleting object elements. > > Stage 1 adds zero functionality. Starting with the modified patch achieves > an identical result. Stage 1 does adds extra work (extra code, extra time) > for the patch processor. No (legitimate) patches will ever include > nulls-in-arrays that they have zero impact on the result. The likely > consequence is that the extra code to remove those null will be implemented > poorly, if at all. > > Stage 1 removes some functionality. It further restricts the JSON values > that can be created by a merge-patch. > > If the rationale is that "all nulls are special", then silently removing > them from patches is not appropriate. It would be more appropriate to > change stage 1 to throw an error if a patch includes any nulls in an array. > > Dropping stage 1 is the sensible approach. > > -- > James Manger > --047d7b33d31c64bf2304dd442c05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Alternatively, one can simply not send a merge patch with nu= ll array elements.

At this point, however, it's just you and I talking back= and forth.=C2=A0 Let's let others have a chance to weigh in on it.

On May 21, 2013 5:44 PM, "Manger, James H&q= uot; <James.H.Manger@= team.telstra.com> wrote:
> <James.H.Manger@= team.telstra.com> wrote:
> [snip]
> >
> > It is pointless making the receiver of a patch remove nulls-withi= n-
> an-array just to get a result that is identical to the sender of the > patch simply not including those nulls-within-an-array in the first > place.
> >
> > The spec says "JSON arrays are treated the same as JSON prim= itives".
> This should be reflected in the processing rules (and then the test > case). Implementations shouldn't need to look inside arrays.

James Snell wrote:
> The spec also states that Null specifically that "The JSON null v= alue
> is given a special meaning to indicate the removal of an existing
> value". A merge-patch document should not include any null values=
> unless it is specifically intending to remove something from the targe= t
> document. The fact that nulls in arrays were not appropriately dealt > with previously is a spec bug, not a feature ;-) ...


Removing nulls in arrays means the patch process can be described in 2 stag= es:

Stage 1: Walk through objects and arrays in the patch removing any nulls in= side arrays, resulting in a modified patch.

Stage 2: Walk through objects in the document and modified patch together -= - adding, replacing or deleting object elements.

Stage 1 adds zero functionality. Starting with the modified patch achieves = an identical result. Stage 1 does adds extra work (extra code, extra time) = for the patch processor. No (legitimate) patches will ever include nulls-in= -arrays that they have zero impact on the result. The likely consequence is= that the extra code to remove those null will be implemented poorly, if at= all.

Stage 1 removes some functionality. It further restricts the JSON values th= at can be created by a merge-patch.

If the rationale is that "all nulls are special", then silently r= emoving them from patches is not appropriate. It would be more appropriate = to change stage 1 to throw an error if a patch includes any nulls in an arr= ay.

Dropping stage 1 is the sensible approach.

--
James Manger
--047d7b33d31c64bf2304dd442c05-- From dave@cridland.net Wed May 22 02:11: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 6759321F92FB for ; Wed, 22 May 2013 02:11:12 -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, 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 Ns5EfNzy86Uq for ; Wed, 22 May 2013 02:11:11 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 806A821F9285 for ; Wed, 22 May 2013 02:11:11 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id fb19so1948219obc.19 for ; Wed, 22 May 2013 02:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rhOmeJQJUn4sQsF/k5hP9FjJiaSnMg7D4dvOaVKtRq4=; b=bsMzwE+w+Jah1R0h7tH9gHEB+8FvIq3e4xzvnkaSGOZwdmuY92WZFa8X/Pa8bnlNvz VCl+dum3tuWNdvBxz17MuaGucgrtZyWjRaCQF3MipE6ecaUzWQI3VUtAgmSy/5JUQbKH aPReoBa0D8Ggx5RkMuqwfuum1xbn2TjtR3O10= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=rhOmeJQJUn4sQsF/k5hP9FjJiaSnMg7D4dvOaVKtRq4=; b=CyzfHP/a3xCO3MMLZU9h+0sETTv5shxznvvdzNhUpnQ9Tt1U8E33D6HJWm1x0D5XLo 4WtQvw2P2QG0/8XpReGjOgmRxOdcXCxk2+maXuMs36gMggRtMnS/3FLN5Cqy/kyq5gwl L7ppqPu8tru58UxQcKPa+UXLnkWeOLqnH26FQ6W/WJL9InHotRruBNDBhpTVIg/uAMbm 26xL2r9yLh+wdDdMGVfq3xNnHfOWBC/yKjTovSwn0md8CEnmwc1rADDo39mq5bqLJEXa cDzOPzx3kEFbORt3p1MyAx8xshT+DEuu9ves7lZszRyHclslx3v3N55Zu6s5zQFlPtTi WV9Q== MIME-Version: 1.0 X-Received: by 10.60.134.204 with SMTP id pm12mr4138925oeb.67.1369213870968; Wed, 22 May 2013 02:11:10 -0700 (PDT) Received: by 10.60.62.146 with HTTP; Wed, 22 May 2013 02:11:10 -0700 (PDT) In-Reply-To: <519BE7D4.6070504@isode.com> References: <20130519052116.75996.qmail@joyce.lan> <6.2.5.6.2.20130519232054.06b2a318@resistor.net> <519BE7D4.6070504@isode.com> Date: Wed, 22 May 2013 10:11:10 +0100 Message-ID: From: Dave Cridland To: Alexey Melnikov Content-Type: multipart/alternative; boundary=047d7b471dc4669eaf04dd4af2a0 X-Gm-Message-State: ALoCoQnsaYNFPnd77nwuG1mH8/g5xXmLjhMnhMfcfoROvl/ilPZi7uKmjIsUK8PmVDPGy8MuropB Cc: S Moonesamy , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Slash and version number in Authentication-results: 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: Wed, 22 May 2013 09:11:12 -0000 --047d7b471dc4669eaf04dd4af2a0 Content-Type: text/plain; charset=ISO-8859-1 You know, as I think about this, my key question is why remove it? If that's not essential, then we can just have future versions use a different header field name, so instead of: Authentication-Results: example.org/2 [...] We have: Authentication-Results-2: example.org [...] A simplistic M*A might be confused by the presence of the first, but surely would simply ignore the presence of the second form? Dave --047d7b471dc4669eaf04dd4af2a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
You know, as I think about this, my key question is why re= move it?

If that's not essential, then we can = just have future versions use a different header field name, so instead of:=

Authentication-Results: example.org/2 [...]

= We have:

Authentication-Results-2: example.org [...]

A simplistic M*A might be confused by the p= resence of the first, but surely would simply ignore the presence of the se= cond form?

Dave
--047d7b471dc4669eaf04dd4af2a0-- From dave@cridland.net Wed May 22 03:57: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 5CA9221F913E for ; Wed, 22 May 2013 03:57:11 -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 iooxjUvMWKlw for ; Wed, 22 May 2013 03:57:07 -0700 (PDT) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id E826821F958A for ; Wed, 22 May 2013 03:57:06 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id g12so2333770oah.12 for ; Wed, 22 May 2013 03:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ESdyO2HrclP16TKq6L+R1UqeAE+HEAkPeVPYIIWC05U=; b=SKuYgcpb1TdOANeo1j3aN6VHlokAglH0KNBjhxxhVDUIrfqF2eriw71sNVkmeFS7ik RwHIgm5HrPQEGsd/69CM1jcQnFhqYvnqA/wcYoUo2n2wt9LhVw0152PlYU4xRHJEMppR SqQEKUhJLvXv+0qD6K27MyuTDbYWF47UvrCA4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ESdyO2HrclP16TKq6L+R1UqeAE+HEAkPeVPYIIWC05U=; b=V9toSWrk8Qs+bUXxWzr6Ah71y0o+36GH5gYW5K/tzNI/Wt7Vm1aAEYLzzwCJLA61zP eC29wHdTxBRE6chLhG2g3l4CWnWACAyMJ+Nz3KZubdXyusJg9RZLfOMBA5owAqo8k9J3 u70uFRIkv+yX2hGfsQKGlSXeoGdn+f9ABNYFbXDYrvYNoX0csIsbDON9TaEeUNGOhxmn 03W4Fee8CtQBZil8MxwlycgyJlUVokRYCzbt2k+vvsCtexUTIURTqmGWcfTOoLtnDICR 0KJAPy7GRG1J2/M1oxKPzJKs+zQYGiHu0eiB5jaql5c4wJae+QjgoasrgSJ2ptI/26QV dH5g== MIME-Version: 1.0 X-Received: by 10.182.240.136 with SMTP id wa8mr4358110obc.2.1369220226404; Wed, 22 May 2013 03:57:06 -0700 (PDT) Received: by 10.60.62.146 with HTTP; Wed, 22 May 2013 03:57:06 -0700 (PDT) In-Reply-To: References: <20130519052116.75996.qmail@joyce.lan> <6.2.5.6.2.20130519232054.06b2a318@resistor.net> <519BE7D4.6070504@isode.com> Date: Wed, 22 May 2013 11:57:06 +0100 Message-ID: From: Dave Cridland To: Alexey Melnikov Content-Type: multipart/alternative; boundary=089e01634f0e3734d804dd4c6dfc X-Gm-Message-State: ALoCoQnJW/+vPKKidD1riH6wLDXulG+aLzMc3ucpaCnxbMp8Qr9QnpCgrKz58dmNAo6eKm1Bhgzp Cc: S Moonesamy , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Slash and version number in Authentication-results: 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: Wed, 22 May 2013 10:57:11 -0000 --089e01634f0e3734d804dd4c6dfc Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 22, 2013 at 10:11 AM, Dave Cridland wrote: > You know, as I think about this, my key question is why remove it? > > Alexey pointed out I was being unclear. I meant removal of the header, as in this paragraph from the draft: "An MTA SHOULD remove any instance of this header field bearing a version (express or implied) that it does not support." > If that's not essential, then we can just have future versions use a > different header field name, so instead of: > > Authentication-Results: example.org/2 [...] > > We have: > > Authentication-Results-2: example.org [...] > > A simplistic M*A might be confused by the presence of the first, but > surely would simply ignore the presence of the second form? > > Dave > --089e01634f0e3734d804dd4c6dfc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, May 22, 2013 at 10:11 AM, Dave Cridland &= lt;dave@cridland.net= > wrote:
You know, as I think about this, my key q= uestion is why remove it?


Alexey pointed out I= was being unclear. I meant removal of the header, as in this paragraph fro= m the draft:

=A0"An MTA SHOU= LD remove any instance of this header field bearing a
=A0 =A0version (express or implied) that it does not support."
=A0
If that's not essential, then we can j= ust have future versions use a different header field name, so instead of:<= /div>

Authentication-Results: example.org/2 [...]

We hav= e:

Authentication-Results-2: example.org [...]

A simplistic M*A might be confused by the presence of t= he first, but surely would simply ignore the presence of the second form?

Dave

--089e01634f0e3734d804dd4c6dfc-- From scott@kitterman.com Wed May 22 05:46: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 5F8A421F8FEC for ; Wed, 22 May 2013 05:46:45 -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 bgECkLI4Ku-A for ; Wed, 22 May 2013 05:46:40 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4C33021F9052 for ; Wed, 22 May 2013 05:46:40 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 8399DD04080; Wed, 22 May 2013 07:46:39 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1369226799; bh=cSYS/DZkFCMQTwXL6g5xjYDlkm0iYvwOjKm4R0UjgQw=; h=In-Reply-To:References:Subject:From:Date:To:From; b=VvACLavRIFUA328HQfp3pqR7X/jW78cxxG8IuxwZoY8N6VBXUWNK40u62gem4CEmw hkh8T8QXmNWDZA2KvnbaVCUC7kF/SCFVO0B+mP8oG5VH8UQq9Im0IRKFznBqmF4FvN G//YX9VlmJUfn8RRFKfZAmpsSKV9sM5bXmADoLA0= Received: from [192.168.111.2] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 4448DD04049; Wed, 22 May 2013 07:46:39 -0500 (CDT) User-Agent: K-9 Mail for Android In-Reply-To: References: <20130519052116.75996.qmail@joyce.lan> <6.2.5.6.2.20130519232054.06b2a318@resistor.net> <519BE7D4.6070504@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 22 May 2013 08:46:37 -0400 To: "apps-discuss@ietf.org" Message-ID: <9426a23f-6832-4d68-a3ad-315d1bbc7c17@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [apps-discuss] Slash and version number in Authentication-results: 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: Wed, 22 May 2013 12:46:45 -0000 Dave Cridland wrote: >You know, as I think about this, my key question is why remove it? > >If that's not essential, then we can just have future versions use a >different header field name, so instead of: > >Authentication-Results: example.org/2 [...] > >We have: > >Authentication-Results-2: example.org [...] > >A simplistic M*A might be confused by the presence of the first, but >surely >would simply ignore the presence of the second form? > Did you mean "why not remove it"? Scott K From dave@cridland.net Wed May 22 06:47: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 B955F21F88FB for ; Wed, 22 May 2013 06:47:46 -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=[AWL=-0.000, 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 KWcD+ltc9cmV for ; Wed, 22 May 2013 06:47:42 -0700 (PDT) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id C0D3921F8607 for ; Wed, 22 May 2013 06:47:34 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id h2so2625774oag.33 for ; Wed, 22 May 2013 06:47:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZGujZfj90T7nlFMDa4bUtZQASnLml4DV80Q2m8dicno=; b=SC8enBMCNTl5UAkNlG/7fQaHc8zjqmFHahJtLkK3KcWXQ/kIAZxqA8ILCF3ag7Qh3J raZOUoqPMs6QS2Pl0giohC9dP+r0+2sWkiUIkXQv9HOfm7TD03h8lQJwSeYJ333KLtaq HHH9dVWB9Vl5W6Y3XJlRj2+6N5hJjYqSYFQvE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ZGujZfj90T7nlFMDa4bUtZQASnLml4DV80Q2m8dicno=; b=HPZLD8JPslzaS+dBvB31Sm+nqqb0TBvUoD/IAL8cVz6d5+rwhs0h6dQBw4kY/i4bfS 080Z4KuYnUhe7DYRU6SI8/VTnyKFmc0xbhBKbL86Wnhf1/lSTR4hrpXwb6tpz0VIsg4N sXGgL1xsSkvZ9kGJMYausJWETm0XREen1Imd8qk3FBhBhgSKyhE76FKG/nkfaGw189nZ ZFTJGdWn73+PobeLwUS0Qbq9GBH93PK+Fd0jK0Hokddf+LJehOxKcM2v+wY5M5LG8t1U LEyI4ExOPAiVHdDAbjJgIMQJnFlFe7sfqg2SSPCvVpz4zCmCOuBG6aOaSGVoXObE3CPt Y8yA== MIME-Version: 1.0 X-Received: by 10.60.37.133 with SMTP id y5mr4799369oej.123.1369230454085; Wed, 22 May 2013 06:47:34 -0700 (PDT) Received: by 10.60.62.146 with HTTP; Wed, 22 May 2013 06:47:34 -0700 (PDT) In-Reply-To: <9426a23f-6832-4d68-a3ad-315d1bbc7c17@email.android.com> References: <20130519052116.75996.qmail@joyce.lan> <6.2.5.6.2.20130519232054.06b2a318@resistor.net> <519BE7D4.6070504@isode.com> <9426a23f-6832-4d68-a3ad-315d1bbc7c17@email.android.com> Date: Wed, 22 May 2013 14:47:34 +0100 Message-ID: From: Dave Cridland To: Scott Kitterman Content-Type: multipart/alternative; boundary=089e013c6e90d4f09304dd4eceb3 X-Gm-Message-State: ALoCoQn4vE97iEf2lWxPEvGTgpQE+h7itXO/VDSYobBKKkZnUHXs+aduOMQcVfaC7VpCKTNNNGSn Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Slash and version number in Authentication-results: 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: Wed, 22 May 2013 13:47:46 -0000 --089e013c6e90d4f09304dd4eceb3 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 22, 2013 at 1:46 PM, Scott Kitterman wrote: > Did you mean "why not remove it"? > I've been overtaken by events, actually - hadn't caught up with all my mail and had missed -04 being published - my comments are probably irrelevant. --089e013c6e90d4f09304dd4eceb3 Content-Type: text/html; charset=ISO-8859-1



On Wed, May 22, 2013 at 1:46 PM, Scott Kitterman <scott@kitterman.com> wrote:
Did you mean "why not remove it"?

I've been overtaken by events, actually - hadn't caught up with all my mail and had missed -04 being published - my comments are probably irrelevant.
--089e013c6e90d4f09304dd4eceb3-- From cyrus@daboo.name Wed May 22 07:14: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 0D97221F9409 for ; Wed, 22 May 2013 07:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 DDd7GFFA0VW7 for ; Wed, 22 May 2013 07:14:06 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2A74021F9227 for ; Wed, 22 May 2013 07:14:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id C22CD43D3DD9; Wed, 22 May 2013 10:14:05 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 055Me878pM1Z; Wed, 22 May 2013 10:14:05 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 998F943D3DCD; Wed, 22 May 2013 10:14:04 -0400 (EDT) Date: Wed, 22 May 2013 10:14:30 -0400 From: Cyrus Daboo To: "Murray S. Kucherawy" , IETF Apps Discuss Message-ID: <33A64D70C0880C037339D8F8@caldav.corp.apple.com> In-Reply-To: References: X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=1094 Subject: Re: [apps-discuss] Processing draft-bosch-sieve-duplicate via APPSAWG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 14:14:12 -0000 Hi Murray, --On May 7, 2013 at 3:24:30 PM -0700 "Murray S. Kucherawy"=20 wrote: > We have received a request to process the above draft through APPSAWG, > since there is no longer a sieve WG.=C2=A0 It is a relatively short = document > and appears to fall within our charter. > > We haven't processed a sieve extension here yet; rather, they've gone > through small, tight WGs so far.=C2=A0 Before issuing a formal call for > adoption, I'd like to gauge whether we have enough sieve-aware people > currently following APPSAWG to be able to contribute reviews and > constructive commentary.=C2=A0 A virtual show of hands, please? > Somewhat late, but I support AppsDiscuss processing this document. It has=20 already had some significant review on the ietf-sieve mailing list and is=20 probably ready to go straight to last call. Most of the key sieve=20 implementors are subscribed to ietf-sieve so any apps-discuss=20 "announcements" should be cc'd there as well. Or would it make sense to use = ietf-sieve as the "primary" mailing list and cc announcements to=20 apps-discuss? --=20 Cyrus Daboo From superuser@gmail.com Wed May 22 07:31: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 17FB021F920E; Wed, 22 May 2013 07:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=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 qXbKPVuNKq-J; Wed, 22 May 2013 07:31:46 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 77DA821F9092; Wed, 22 May 2013 07:31:38 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hr14so3786175wib.3 for ; Wed, 22 May 2013 07:31:37 -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=51mvaAYW4yyYPL6oUSyk6hyC1Anuz8jBCnA4HoCy0Pc=; b=vR9ekGRrXeaAwUeSK06BMjFyMRpZDWAWLgNtqQ0HkXMi4AaEG+HPKPwnGQSkH0b4ab a06CChwPy0eRHbpQkWkyaHundAe3eCnL4J+H+upIJhu+yxT8nQ6IN6KuI3/JEicphn91 TocARKP+ZJCvX+NBJ55Zp10NsFi1gnjvfJLpEVnj3tUWkHPl1cCVbQZXeU0PJFvqtcCV s1oN/mKvW44tzaGWVhuRP24XbEpwnTqtgatOzGf+fKCWvGhWKE8UbV03EXlPmqA0/D4L V4XXaxZoziJ44jdiwodLLvBbaDxMzv6gspF+FnlkSWGUPzm/wDdL0jd54OX1lbDebza5 fY8Q== MIME-Version: 1.0 X-Received: by 10.180.37.243 with SMTP id b19mr15422885wik.12.1369233097602; Wed, 22 May 2013 07:31:37 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Wed, 22 May 2013 07:31:37 -0700 (PDT) In-Reply-To: <33A64D70C0880C037339D8F8@caldav.corp.apple.com> References: <33A64D70C0880C037339D8F8@caldav.corp.apple.com> Date: Wed, 22 May 2013 07:31:37 -0700 Message-ID: From: "Murray S. Kucherawy" To: Cyrus Daboo Content-Type: multipart/alternative; boundary=e89a8f646db565bce104dd4f6c15 Cc: sieve@ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] Processing draft-bosch-sieve-duplicate via APPSAWG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 14:31:47 -0000 --e89a8f646db565bce104dd4f6c15 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 22, 2013 at 7:14 AM, Cyrus Daboo wrote: > > --On May 7, 2013 at 3:24:30 PM -0700 "Murray S. Kucherawy" < > superuser@gmail.com> wrote: > > We have received a request to process the above draft through APPSAWG, >> since there is no longer a sieve WG. It is a relatively short document >> and appears to fall within our charter. >> >> We haven't processed a sieve extension here yet; rather, they've gone >> through small, tight WGs so far. Before issuing a formal call for >> adoption, I'd like to gauge whether we have enough sieve-aware people >> currently following APPSAWG to be able to contribute reviews and >> constructive commentary. A virtual show of hands, please? >> >> > Somewhat late, but I support AppsDiscuss processing this document. It has > already had some significant review on the ietf-sieve mailing list and is > probably ready to go straight to last call. Most of the key sieve > implementors are subscribed to ietf-sieve so any apps-discuss > "announcements" should be cc'd there as well. Or would it make sense to use > ietf-sieve as the "primary" mailing list and cc announcements to > apps-discuss? > > > I'd prefer the discussion happen here, but I don't feel strongly on the matter. However, I'd be happier if there were a few other reviewers/commenters in here that are willing to support the document through the process. Now Cc:ing sieve@ietf.org (when someone over there approves my post), can I get a couple more volunteers? -MSK, APPSAWG co-chair --e89a8f646db565bce104dd4f6c15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 22, 2013 at 7:14 AM, Cyrus Daboo <cyrus@daboo.= name> wrote:

--On May 7, 2013 at 3:24:30 PM -0700 "Murray S. Kucherawy" <superuser@gmail.com<= /a>> wrote:

We have received a request to process the above draft through APPSAWG,
since there is no longer a sieve WG.=A0 It is a relatively short document and appears to fall within our charter.

We haven't processed a sieve extension here yet; rather, they've go= ne
through small, tight WGs so far.=A0 Before issuing a formal call for
adoption, I'd like to gauge whether we have enough sieve-aware people currently following APPSAWG to be able to contribute reviews and
constructive commentary.=A0 A virtual show of hands, please?


Somewhat late, but I support AppsDiscuss processing this document. It has a= lready had some significant review on the ietf-sieve mailing list and is pr= obably ready to go straight to last call. Most of the key sieve implementor= s are subscribed to ietf-sieve so any apps-discuss "announcements"= ; should be cc'd there as well. Or would it make sense to use ietf-siev= e as the "primary" mailing list and cc announcements to apps-disc= uss?



I'd prefer the d= iscussion happen here, but I don't feel strongly on the matter.

=
However, I'd be happier if there were a few other reviewers/= commenters in here that are willing to support the document through the pro= cess.=A0 Now Cc:ing sieve@ietf.org (w= hen someone over there approves my post), can I get a couple more volunteer= s?

-MSK, APPSAWG co-chair

--e89a8f646db565bce104dd4f6c15-- From paul.hoffman@vpnc.org Wed May 22 07:49: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 3805721F9223 for ; Wed, 22 May 2013 07:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.61 X-Spam-Level: X-Spam-Status: No, score=-102.61 tagged_above=-999 required=5 tests=[AWL=-0.011, 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 Wa22H3C9keo7 for ; Wed, 22 May 2013 07:49:37 -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 9E77121F84CD for ; Wed, 22 May 2013 07:49:37 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4MEnaO6041802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 22 May 2013 07:49:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> Date: Wed, 22 May 2013 07:49:36 -0700 To: apps-discuss@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 14:49:38 -0000 Greetings again. Carsten Bormann and I have proposed a new compact = binary format, CBOR: . = The design goals for the format are listed in the introduction; most = notably, code compactness is considered as important as message = compactness, and we think we got a lot of the latter with no sacrifice = of the former. A few appsy folks have already contributed ideas, but we would like to = hear more. Given its applicability to protocols across the Applications = area (and actually across the IETF), we think this would be an = appropriate to be an appsawg work item if others here think so as well. = Please let us know what you think. --Paul Hoffman From jasnell@gmail.com Wed May 22 08:47: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 0B73A21F91A0 for ; Wed, 22 May 2013 08:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=-2.425, 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 TFViCp8IMfKH for ; Wed, 22 May 2013 08:47:31 -0700 (PDT) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB5321F9626 for ; Wed, 22 May 2013 08:47:31 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id h1so2794598oag.25 for ; Wed, 22 May 2013 08:47: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=JDJbSL93PLR2a06IW64N9G2Co+x9QZwiscx9o+j5tmM=; b=nA7qq/g9kHVzaa45oMli2a3Fr4Q1MTYV6gl6ZllsAQ6/KjPrJZRW8PUlt2WrLFVkys P714M3Pn3weW5e0xoXxP6p7tZ9aIYRb0fOJxlu4hnFB6keDwr9IVvURuxFTBUzbHTMoq 16Wy+s9kiRCAd8ScbZ7dLyvQ5/Q4Ob489hNpakt+zkKc2OhiWuU96rKjInnhMI4MSapQ uSpsvD8FDUCNhoCGDNrYCfHIOmkVd8fcBmnGfqYSqCT75GJ6+5PuASwICpmTwn/TFEDM gGqejN3nkv8Tu/zKdag4prldQgPDwFgoi6YynNKoVU8OyMQyYn98geInCiHZJ6I2x2jT heEg== X-Received: by 10.182.241.194 with SMTP id wk2mr5221914obc.77.1369237650804; Wed, 22 May 2013 08:47:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.3.137 with HTTP; Wed, 22 May 2013 08:47:10 -0700 (PDT) In-Reply-To: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> From: James M Snell Date: Wed, 22 May 2013 08:47:10 -0700 Message-ID: To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 15:47:47 -0000 At first read it looks interesting, and can definitely see that a lot of thought was put into the design. There have, however, been a number of previous attempts at alternative compact binary representations (or at least discussions) that did not seem to really go anywhere. What is the current implementation status of this? Are there implementations available or any existing plans to use this new format in a specific app or spec? I'm largely just curious about the context and motivation behind this... On Wed, May 22, 2013 at 7:49 AM, Paul Hoffman wrote= : > Greetings again. Carsten Bormann and I have proposed a new compact binary= format, CBOR: . The design = goals for the format are listed in the introduction; most notably, code com= pactness is considered as important as message compactness, and we think we= got a lot of the latter with no sacrifice of the former. > > A few appsy folks have already contributed ideas, but we would like to he= ar more. Given its applicability to protocols across the Applications area = (and actually across the IETF), we think this would be an appropriate to be= an appsawg work item if others here think so as well. Please let us know w= hat you think. > > --Paul Hoffman > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From paul.hoffman@vpnc.org Wed May 22 09:01: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 527AC21F962C for ; Wed, 22 May 2013 09:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.61 X-Spam-Level: X-Spam-Status: No, score=-102.61 tagged_above=-999 required=5 tests=[AWL=-0.011, 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 niwNO1SPOvOC for ; Wed, 22 May 2013 09:01:18 -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 A8BEB21F9631 for ; Wed, 22 May 2013 09:01:00 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4MG0t7c044276 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 May 2013 09:00:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Wed, 22 May 2013 09:00:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> To: James M Snell X-Mailer: Apple Mail (2.1503) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 16:01:19 -0000 On May 22, 2013, at 8:47 AM, James M Snell wrote: > At first read it looks interesting, and can definitely see that a lot > of thought was put into the design. There have, however, been a number > of previous attempts at alternative compact binary representations (or > at least discussions) that did not seem to really go anywhere. We did ours differently than others: we started with an ordered set of = design goals and stuck to them. That means that our early arguments = about changes / bikeshedcolors had something we could compare against, = and it make coming up with a solution much more tractable. > What is > the current implementation status of this? Are there implementations > available or any existing plans to use this new format in a specific > app or spec? Both Carsten and I did versions (in Ruby and Python) to make sure the = spec made sense and the examples worked. At least one other member of = this list has apparently done a version in JavaScript.=20 > I'm largely just curious about the context and motivation > behind this... There are many contexts. It might be useful in CORE and other = constrained-environment work. It might be useful for the next protocols = that need a compact binary representation and the WG doesn't want to = fight over the specific features. If the design goals fit your needs = (and we actually met them...), then it's useful to have it be widely = available. --Paul Hoffman= From dcrocker@bbiw.net Wed May 22 09:11: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 87DEE21F96C1 for ; Wed, 22 May 2013 09:11:16 -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 46wWs9Xsk25p for ; Wed, 22 May 2013 09:11:11 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 802E021F96BB for ; Wed, 22 May 2013 09:11:11 -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 r4MGB7LC018655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 May 2013 09:11:10 -0700 Message-ID: <519CEE17.2050000@bbiw.net> Date: Wed, 22 May 2013 09:11:03 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: James M Snell References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> 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.67]); Wed, 22 May 2013 09:11:10 -0700 (PDT) Cc: Paul Hoffman , IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 16:11:16 -0000 On 5/22/2013 8:47 AM, James M Snell wrote: > There have, however, been a number > of previous attempts at alternative compact binary representations (or > at least discussions) that did not seem to really go anywhere. Indeed, Jack Haverty, then of MIT, lobbied hard for an especially concise, variable-length encoding form for email, back when RFC 733 was being developed, in 1977 for email. We thought his idea clever but deciding to stay with the existing simple-ASCII practice, for messages that looked pretty much as they do today. Jack's scheme certainly wasn't identical to the CBOR proposal, but it looks like the design approach is related. I've always thought the approach a good one... assuming that it makes the right choices for what data to represent the most concisely. For that, there should be some empirical data cited and possibly some discussion of significant earlier, related encoding schemes. I suspect BER is the major one to consider. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hallam@gmail.com Wed May 22 09:14:27 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2715721F96DE for ; Wed, 22 May 2013 09:14:27 -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 PtuMCjlJ7ktC for ; Wed, 22 May 2013 09:14:26 -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 9D92D21F96DC for ; Wed, 22 May 2013 09:14:25 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id q55so1432306wes.14 for ; Wed, 22 May 2013 09:14: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:date:message-id:subject:from:to :cc:content-type; bh=l1/B431TPv2C2edx1UDCWV9U0KDKVMKKZjtSar4KyeY=; b=S4m2aAoh1hA+6yGE0nQvU/X4Cisjokytt/oZ9kp31eculD6Oue2Mv6RKnT+XvDe/P6 ybmnZzqzTeRNGItAsCYVDPBNixtQsHcu7gyvXcDFXvoL82EGuuDrCkvEpSOdsM3IdHnF /0KlrKBi6m/bit+BZRGfeksMisylG0an0i/m0aYlit86LAlSr9IK9TDMxaOpjLWKsz8S j8+PSOVINsixsn4iVP3UxU8jb8jZrrQ3uPxIMC3kY4eHIGN42hLgX14TM67ilbcpE7jM TpNv95ZFJvmFmisX7O4YRvMMy07I6+K0RqaHYHSwPQxz0NpodN10uQB8aMfEE1NNTmy1 eE3A== MIME-Version: 1.0 X-Received: by 10.180.74.172 with SMTP id u12mr34884664wiv.0.1369239264654; Wed, 22 May 2013 09:14:24 -0700 (PDT) Received: by 10.194.7.138 with HTTP; Wed, 22 May 2013 09:14:24 -0700 (PDT) In-Reply-To: <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> Date: Wed, 22 May 2013 12:14:24 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=f46d04389001fb7f2804dd50db4b Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 16:14:27 -0000 --f46d04389001fb7f2804dd50db4b Content-Type: text/plain; charset=ISO-8859-1 Meh... I think we can all agree that *A* binary format would be useful and that two dozen are not useful. The whole problem is how to convince people to use one particular scheme rather than the alternatives. ASN.1 has a decent binary encoding. The problem is that it also has some terrible ones and the ASN.1 schema language was designed by a committee. Text encodings do have problems. Floating Point values do not round trip from IEEE floating point representations without special handling so the format causes a loss in precision that can cause real trouble in scientific work. And nobody likes base64 encoding binary values. I would like to have available a BER like encoding for JSON. But this proposal seems to be something rather different. There is also the XML binary encoding effort that took place. They had a competition and everything. And at the end the only real use for the work was that it shut up the constant carping from people complaining that Web Services in XML were verbose. On Wed, May 22, 2013 at 12:00 PM, Paul Hoffman wrote: > On May 22, 2013, at 8:47 AM, James M Snell wrote: > > > At first read it looks interesting, and can definitely see that a lot > > of thought was put into the design. There have, however, been a number > > of previous attempts at alternative compact binary representations (or > > at least discussions) that did not seem to really go anywhere. > > We did ours differently than others: we started with an ordered set of > design goals and stuck to them. That means that our early arguments about > changes / bikeshedcolors had something we could compare against, and it > make coming up with a solution much more tractable. > > > What is > > the current implementation status of this? Are there implementations > > available or any existing plans to use this new format in a specific > > app or spec? > > Both Carsten and I did versions (in Ruby and Python) to make sure the spec > made sense and the examples worked. At least one other member of this list > has apparently done a version in JavaScript. > > > I'm largely just curious about the context and motivation > > behind this... > > There are many contexts. It might be useful in CORE and other > constrained-environment work. It might be useful for the next protocols > that need a compact binary representation and the WG doesn't want to fight > over the specific features. If the design goals fit your needs (and we > actually met them...), then it's useful to have it be widely available. > > --Paul Hoffman > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- Website: http://hallambaker.com/ --f46d04389001fb7f2804dd50db4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Meh...

I think we can all agree t= hat *A* binary format would be useful and that two dozen are not useful. Th= e whole problem is how to convince people to use one particular scheme rath= er than the alternatives.

ASN.1 has a decent binary encoding. The pro= blem is that it also has some terrible ones and the ASN.1 schema language w= as designed by a committee.

Text encod= ings do have problems. Floating Point values do not round trip from IEEE fl= oating point representations without special handling so the format causes = a loss in precision that can cause real trouble in scientific work. And nob= ody likes base64 encoding binary values.


I would like to have a= vailable a BER like encoding for JSON. But this proposal seems to be someth= ing rather different.

There is also th= e XML binary encoding effort that took place. They had a competition and ev= erything. And at the end the only real use for the work was that it shut up= the constant carping from people complaining that Web Services in XML were= verbose.



On Wed, May 22, 2013 at 12:00 PM, Paul Hoffman <paul.hof= fman@vpnc.org> wrote:
On May 22, 2013, at 8:47 A= M, James M Snell <jasnell@gmail.com= > wrote:

> At first read it looks interesting, and can definitely see that a lot<= br> > of thought was put into the design. There have, however, been a number=
> of previous attempts at alternative compact binary representations (or=
> at least discussions) that did not seem to really go anywhere.

We did ours differently than others: we started with an ordered set o= f design goals and stuck to them. That means that our early arguments about= changes / bikeshedcolors had something we could compare against, and it ma= ke coming up with a solution much more tractable.

> What is
> the current implementation status of this? Are there implementations > available or any existing plans to use this new format in a specific > app or spec?

Both Carsten and I did versions (in Ruby and Python) to make sure the= spec made sense and the examples worked. At least one other member of this= list has apparently done a version in JavaScript.

> I'm largely just curious about the context and motivation
> behind this...

There are many contexts. It might be useful in CORE and other constra= ined-environment work. It might be useful for the next protocols that need = a compact binary representation and the WG doesn't want to fight over t= he specific features. If the design goals fit your needs (and we actually m= et them...), then it's useful to have it be widely available.

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



--
= Website: http://hallambaker.com/
--f46d04389001fb7f2804dd50db4b-- From paul.hoffman@vpnc.org Wed May 22 09:16: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 EC43221F96A6 for ; Wed, 22 May 2013 09:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 qQc2j+tL8ht1 for ; Wed, 22 May 2013 09:16:36 -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 6BB9721F969F for ; Wed, 22 May 2013 09:16:36 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4MGGX6g045153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 May 2013 09:16:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Wed, 22 May 2013 09:16:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <943F8A67-0282-4869-98F6-2EFB7CD0830A@vpnc.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1503) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 16:16:37 -0000 On May 22, 2013, at 9:14 AM, Phillip Hallam-Baker = wrote: > I think we can all agree that *A* binary format would be useful and = that two dozen are not useful. Nope, that is patently absurd. That would only be true if everyone = agreed on all the design goals and decisions for the one binary format, = and that clearly cannot happen. --Paul Hoffman= From barryleiba.mailing.lists@gmail.com Wed May 22 09:19: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 2BB9B21F8808; Wed, 22 May 2013 09:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9s--U9ohY-it; Wed, 22 May 2013 09:19:36 -0700 (PDT) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by ietfa.amsl.com (Postfix) with ESMTP id DA72821F969F; Wed, 22 May 2013 09:19:35 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id ht10so1438783vcb.32 for ; Wed, 22 May 2013 09:19:35 -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=qt8LaYP9/aS+d76G1ToKgT4p4lKUZ6tVnKatoPBp8d0=; b=qW4dmTmGJBCWFv0JQZbLP9uM0a8Y23RcoTscjjlDStfovU6J2/W4Ek5S0YyMR/ZC+u phWLqTaYM6gCQ/SeTswXTTqm30WAW5ADTBOoUJhYkZxrB05nTaf/mAZ37fcHcu9n7lnD 6K4CWsfOmVtTSjCKpwP4Ub9GN3ePTDY5GGPPXM3QU+rFFkYHrNsTT+vGNSdph5dwspQK kQ2wGC9IcstWNh0NaaJQnKs+uYnRXjM2lypjkrhXo/znXXjWkMzj6Y2HzNdQMyrytNT9 nuWSw6i/oW3yD0hQoz1kgkVLtIpwiqFWwwJm1IS4mANpEKQ+B2MRhx7juQ8ANgBJb7YL HV8A== MIME-Version: 1.0 X-Received: by 10.59.3.9 with SMTP id bs9mr3050037ved.38.1369239575171; Wed, 22 May 2013 09:19:35 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.6.233 with HTTP; Wed, 22 May 2013 09:19:35 -0700 (PDT) In-Reply-To: References: <33A64D70C0880C037339D8F8@caldav.corp.apple.com> Date: Wed, 22 May 2013 12:19:35 -0400 X-Google-Sender-Auth: 6NwujQn1EpLdwMgHCyn9KCaP8lQ Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: Sieve mailing list , IETF Apps Discuss Subject: Re: [apps-discuss] Processing draft-bosch-sieve-duplicate via APPSAWG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 16:19:40 -0000 > I'd prefer the discussion happen here, but I don't feel strongly on the > matter. > > However, I'd be happier if there were a few other reviewers/commenters in > here that are willing to support the document through the process. Now > Cc:ing sieve@ietf.org (when someone over there approves my post), can I get > a couple more volunteers? We always have a tricky situation when something belongs elsewhere as well as on apps-discuss -- this has happened a few times as we've branched off discussions (webfinger, json, dmarc), and will also happen in cases such as imap and sieve stuff, as we try to bring it into appsawg. I think the best approach is to try to cross-post when it's stuff that's relatively low volume (such as this), and to keep apps-discuss periodically updated when it's higher volume (such as webfinger). We've now had reviews of this document https://datatracker.ietf.org/doc/draft-bosch-sieve-duplicate/ ...by Ned Freed, Aaron Stone, and Cyrus Daboo. Alexey, too, as shepherd. And PSA has expressed approval for handling it in appsawg. I've seen no objections, so I think that works for bringing it into appsawg. For review, if we could get a couple of other appsawg folks, even some who are not otherwise involved with sieve, to review it as a sanity check, we should be OK. Claudio can help corral a couple of reviewers through appsdir. We might also specifically ask Arnt Gulbrandsen and Tim Showalter for reviews, as formerly active Sieve folks. Barry From Claudio.Allocchio@garr.it Wed May 22 09:24: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 2857D21F9700; Wed, 22 May 2013 09:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.315 X-Spam-Level: X-Spam-Status: No, score=-0.315 tagged_above=-999 required=5 tests=[AWL=0.404, 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 fQ9Nz9QQNDWE; Wed, 22 May 2013 09:24:00 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id CCFF121F94DF; Wed, 22 May 2013 09:23:59 -0700 (PDT) Received: internal info suppressed Date: Wed, 22 May 2013 18:23:50 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@synx02.dir.garr.it To: Barry Leiba In-Reply-To: Message-ID: References: <33A64D70C0880C037339D8F8@caldav.corp.apple.com> 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=1369239831; bh=ZZJyZOEUhEV3KzCao/oq8wgNjvRMB+GLcBWJF/H40x0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=lk2+HHGX2h+C9ziIJk3FbT3uhzQJtL4acy3Br4DSJoYw2pTgvCB8PtJsvMNxcOTYk kp8ZR1v53L/N6VGKv0cwo69IzjyDSmftKmmF8SiiLnPw0lY8ViX8gWOiNZ9DdS8pre J1TaEPVPz6KF3VYTA0yBkkxJkuTYf33PjxRXrC+k= Cc: Sieve mailing list , IETF Apps Discuss Subject: Re: [apps-discuss] Processing draft-bosch-sieve-duplicate via APPSAWG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 16:24:04 -0000 > appsawg. For review, if we could get a couple of other appsawg folks, > even some who are not otherwise involved with sieve, to review it as a > sanity check, we should be OK. Claudio can help corral a couple of > reviewers through appsdir. yes, we can do that. Just let me know, and it will be included in the next round. > Barry > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > ------------------------------------------------------------------------------ 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 hallam@gmail.com Wed May 22 09:26: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 D21A221F96CE for ; Wed, 22 May 2013 09:26: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 00EJEf2Gdqp9 for ; Wed, 22 May 2013 09:26:05 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id C48C921F96C9 for ; Wed, 22 May 2013 09:26:04 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hn14so4314258wib.2 for ; Wed, 22 May 2013 09:26:04 -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=NXPlcOlH5Dt7iBgGHQeLI+dwZhOBxOLimOI6mA5dFSI=; b=I8UZr1vBaSbKomFnGFhxRxmvosFIwY1QdEGfmohjHJHlG2PbBsivGqrWQ/4yIrH31B bMGnPEs/HXjzSQPvGVYj0xGpRjgB+AOetdu8IpJF8bm5pEWxpJfx4cPlojbVFi1f2mOd /e76gTpBbawOV9vZGLMOhE2d7doInpFoinA6Czafukn9Y37qVKSPShNj1QLCdZq17Fj5 lLkhy9hBuDcjB+80oVHBrdHH3wCQ5tMwX3xeccZuFigjlk5w9Ex/5FgZRzYu7QEkT62m qm7bZ6EnwGMhz3cTB5fyTDQiGdkFwg1UtYysAnMj8tupDIdYjDhRUG0dtTs0PUlv4TEr RNUg== MIME-Version: 1.0 X-Received: by 10.180.89.140 with SMTP id bo12mr35375556wib.22.1369239963924; Wed, 22 May 2013 09:26:03 -0700 (PDT) Received: by 10.194.7.138 with HTTP; Wed, 22 May 2013 09:26:03 -0700 (PDT) In-Reply-To: <943F8A67-0282-4869-98F6-2EFB7CD0830A@vpnc.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <943F8A67-0282-4869-98F6-2EFB7CD0830A@vpnc.org> Date: Wed, 22 May 2013 12:26:03 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=e89a8f3bab85a9827704dd5105b8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 16:26:06 -0000 --e89a8f3bab85a9827704dd5105b8 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 22, 2013 at 12:16 PM, Paul Hoffman wrote: > On May 22, 2013, at 9:14 AM, Phillip Hallam-Baker > wrote: > > > I think we can all agree that *A* binary format would be useful and that > two dozen are not useful. > > Nope, that is patently absurd. That would only be true if everyone agreed > on all the design goals and decisions for the one binary format, and that > clearly cannot happen. > We all use RFC822 header style despite the rather obvious fact it does not meet every need. Most of us used XML when that was fashionable despite the baroque nature. Pretty much everyone is piling into JSON right now. For a binary format to be useful it has to be something that is shared across multiple projects so that we can get code reuse. It might be that there is utility in three formats with different features but I rather doubt that is the case as I have never heard of a project fail because XML or JSON did not have enough expressive capability. The problems with XML come from the complexity and the extensibility being rather badly thought out. We already have a few projects that have defined such schemes already. TLS for example. -- Website: http://hallambaker.com/ --e89a8f3bab85a9827704dd5105b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 22, 2013 at 12:16 PM, Paul Hoffman <pau= l.hoffman@vpnc.org> wrote:
On May 22, 2013, at 9:14 A= M, Phillip Hallam-Baker <hallam@gmai= l.com> wrote:

> I think we can all agree that *A* binary format would be useful and th= at two dozen are not useful.

Nope, that is patently absurd. That would only be true if everyone ag= reed on all the design goals and decisions for the one binary format, and t= hat clearly cannot happen.

We all use RFC822 header style despite the rather obvious fact it does not = meet every need. Most of us used XML when that was fashionable despite the = baroque nature. Pretty much everyone is piling into JSON right now.

For a binary format to be useful it has to = be something that is shared across multiple projects so that we can get cod= e reuse.

It might be that there is uti= lity in three formats with different features but I rather doubt that is th= e case as I have never heard of a project fail because XML or JSON did not = have enough expressive capability. The problems with XML come from the comp= lexity and the extensibility being rather badly thought out.


We already have a few = projects that have defined such schemes already. TLS for example.

--
Website: http:/= /hallambaker.com/
--e89a8f3bab85a9827704dd5105b8-- From jasnell@gmail.com Wed May 22 09:28: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 A88A921F9717 for ; Wed, 22 May 2013 09:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=-2.354, 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 BjK3zfyyGlE7 for ; Wed, 22 May 2013 09:28:23 -0700 (PDT) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id B02D221F9714 for ; Wed, 22 May 2013 09:28:17 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id i4so2885481oah.7 for ; Wed, 22 May 2013 09:28: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=R5neXiI04rHhpBMhlHkm3PeTTO6rMqJuYsI5wf4kXlM=; b=XatGCMDmMJx31uu8TCY0BjV+h3TyJfSkHO/ZRS8CZaMCK1qio2w+9wmbUZmaLGak3o yXJKLPSMhh1UD33CDphoyJKWnMrxg9N8DRWoGXNHcxsQ8ftPzAdJMB3823/BJQly4rWu bzy/7hU64A1MqIg1GRhSMgrvL3F22/3E6GFUtVFq/zCJPm9/2GJceMMVBTwsEUhfXPl7 mOu62nCpsQ1mp641/QB+/zWcv59bDCAVA4aAT51HTIVJ/9bMgGA5/FB1v/xOuLvftD1T UKfEs46k0IiCR+kR1fPKYKEALTfKtl9uL15642UDIfLX3WCbC1T0HdKKjn4R3Wc//rYI U3iw== X-Received: by 10.60.92.41 with SMTP id cj9mr5368737oeb.31.1369240097264; Wed, 22 May 2013 09:28:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.3.137 with HTTP; Wed, 22 May 2013 09:27:57 -0700 (PDT) In-Reply-To: <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> From: James M Snell Date: Wed, 22 May 2013 09:27:57 -0700 Message-ID: To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 16:28:28 -0000 On Wed, May 22, 2013 at 9:00 AM, Paul Hoffman wrote= : [snip] >> What is >> the current implementation status of this? Are there implementations >> available or any existing plans to use this new format in a specific >> app or spec? > > Both Carsten and I did versions (in Ruby and Python) to make sure the spe= c made sense and the examples worked. At least one other member of this lis= t has apparently done a version in JavaScript. > Good to know, thank you. >> I'm largely just curious about the context and motivation >> behind this... > > There are many contexts. It might be useful in CORE and other constrained= -environment work. It might be useful for the next protocols that need a co= mpact binary representation and the WG doesn't want to fight over the speci= fic features. If the design goals fit your needs (and we actually met them.= ..), then it's useful to have it be widely available. > The main point of my question was to find out if this was specifically attached to some other piece of work or if it's a standalone "it's here if you need it and want it" type of effort. There is certainly nothing wrong with either approach, it's just better to have that context. I can see how this would be useful in the general sense, just not sure I can imagine any cases where it's something I would absolutely use. - James From cabo@tzi.org Wed May 22 09:29: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 40E7111E80DE for ; Wed, 22 May 2013 09:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.195 X-Spam-Level: X-Spam-Status: No, score=-106.195 tagged_above=-999 required=5 tests=[AWL=0.054, 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 3REOdQpYCYqi for ; Wed, 22 May 2013 09:29:13 -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 60F1511E80D3 for ; Wed, 22 May 2013 09:29:13 -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 r4MGT7pG010228; Wed, 22 May 2013 18:29:07 +0200 (CEST) Received: from [192.168.217.105] (p54891D40.dip0.t-ipconnect.de [84.137.29.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4EA5638CF; Wed, 22 May 2013 18:29:07 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 22 May 2013 18:29:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <04905D53-5022-4741-A2B6-9EE4593A4C65@tzi.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1503) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 16:29:22 -0000 > I would like to have available a BER like encoding for JSON. What is it that you like about BER? (And, as you mentioned there are a couple, which BER do you like :-)? > But this proposal seems to be something rather different. We try to learn. CBOR can sure do everything a "BER for JSON" could do. And a little = more. Gr=FC=DFe, Carsten From superuser@gmail.com Wed May 22 09: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 3DBD421F8FA5; Wed, 22 May 2013 09:38:01 -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.113, 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 3JBMgP2d2Rns; Wed, 22 May 2013 09:38:00 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id DC86E21F8F1E; Wed, 22 May 2013 09:37:59 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id hi5so3910876wib.6 for ; Wed, 22 May 2013 09:37: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=VTRlYaN+ypmwXcHKsb41rGta3X/z32jHL4ETx6qxACs=; b=iFg6suIwmb2elkgYi2hfTvmq5dOIbByukWBm+OX7eDKtLmql9+8Cdx4rXf3nAN6U1g cydH+sPWsZc9fMFGW4blY+ZpcGAL9BdGKsl3hC3s6trdfUi80BjrbnW5q2TD/2Ruoj/2 c09HV/wxq7P/h3Mq9aHL9q+tVV7UBmsFqKSd4hdgtivvEUURjIUFdA1aJtHr5PDXcEgS jJZUL+ghP5eipkZR51KhOUptJ0bm4FDKupxx08TpQ3xXmB3/rTNKoO13bBpBLZ9SfcIz YxjBtJ0iffs3MgG9MhTqYxb90jOQ2BYOzxiWGIvMPgq2gbGSVDE+dI9zHbRrqHr2n7fi dn9g== MIME-Version: 1.0 X-Received: by 10.180.87.162 with SMTP id az2mr35069028wib.10.1369240677057; Wed, 22 May 2013 09:37:57 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Wed, 22 May 2013 09:37:56 -0700 (PDT) In-Reply-To: References: <33A64D70C0880C037339D8F8@caldav.corp.apple.com> Date: Wed, 22 May 2013 09:37:56 -0700 Message-ID: From: "Murray S. Kucherawy" To: Barry Leiba Content-Type: multipart/alternative; boundary=f46d0444ecaf2b0dff04dd51307b Cc: Sieve mailing list , IETF Apps Discuss Subject: Re: [apps-discuss] Processing draft-bosch-sieve-duplicate via APPSAWG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 16:38:01 -0000 --f46d0444ecaf2b0dff04dd51307b Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 22, 2013 at 9:19 AM, Barry Leiba wrote: > We always have a tricky situation when something belongs elsewhere as > well as on apps-discuss -- this has happened a few times as we've > branched off discussions (webfinger, json, dmarc), and will also > happen in cases such as imap and sieve stuff, as we try to bring it > into appsawg. I think the best approach is to try to cross-post when > it's stuff that's relatively low volume (such as this), and to keep > apps-discuss periodically updated when it's higher volume (such as > webfinger). > > We've now had reviews of this document > > https://datatracker.ietf.org/doc/draft-bosch-sieve-duplicate/ > > ...by Ned Freed, Aaron Stone, and Cyrus Daboo. Alexey, too, as > shepherd. And PSA has expressed approval for handling it in appsawg. > I've seen no objections, so I think that works for bringing it into > appsawg. For review, if we could get a couple of other appsawg folks, > even some who are not otherwise involved with sieve, to review it as a > sanity check, we should be OK. Claudio can help corral a couple of > reviewers through appsdir. > > We might also specifically ask Arnt Gulbrandsen and Tim Showalter for > reviews, as formerly active Sieve folks. > I was hoping for a little more voluntary participation, but if we think we can grab enough people to make the review process smooth then I'm fine with proceeding. I'll contact the authors to submit, and see if Alexey is still keen to shepherd. -MSK --f46d0444ecaf2b0dff04dd51307b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 22, 2013 at 9:19 AM, Barry Leiba <barry= leiba@computer.org> wrote:
We always have a tricky situation when somet= hing belongs elsewhere as
well as on apps-discuss -- this has happened a few times as we've
branched off discussions (webfinger, json, dmarc), and will also
happen in cases such as imap and sieve stuff, as we try to bring it
into appsawg. =A0I think the best approach is to try to cross-post when
it's stuff that's relatively low volume (such as this), and to keep=
apps-discuss periodically updated when it's higher volume (such as
webfinger).

We've now had reviews of this document

=A0 =A0https://datatracker.ietf.org/doc/draft-bosch-sieve-= duplicate/

...by Ned Freed, Aaron Stone, and Cyrus Daboo. =A0Alexey, too, as
shepherd. =A0And PSA has expressed approval for handling it in appsawg.
I've seen no objections, so I think that works for bringing it into
appsawg. =A0For review, if we could get a couple of other appsawg folks, even some who are not otherwise involved with sieve, to review it as a
sanity check, we should be OK. =A0Claudio can help corral a couple of
reviewers through appsdir.

We might also specifically ask Arnt Gulbrandsen and Tim Showalter for
reviews, as formerly active Sieve folks.

I was hop= ing for a little more voluntary participation, but if we think we can grab = enough people to make the review process smooth then I'm fine with proc= eeding.=A0 I'll contact the authors to submit, and see if Alexey is sti= ll keen to shepherd.

-MSK

--f46d0444ecaf2b0dff04dd51307b-- From cabo@tzi.org Wed May 22 09:38:43 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D894D21F8F4D for ; Wed, 22 May 2013 09:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.198 X-Spam-Level: X-Spam-Status: No, score=-106.198 tagged_above=-999 required=5 tests=[AWL=0.051, 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 QDuCg8zMkhnc for ; Wed, 22 May 2013 09:38:37 -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 A704421F8F1E for ; Wed, 22 May 2013 09:38:36 -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 r4MGcWB2028043; Wed, 22 May 2013 18:38:32 +0200 (CEST) Received: from [192.168.217.105] (p54891D40.dip0.t-ipconnect.de [84.137.29.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1505038DE; Wed, 22 May 2013 18:38:32 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 22 May 2013 18:38:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5545E5C2-B759-4F73-A9D5-944BAEEDBE08@tzi.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> To: James M Snell X-Mailer: Apple Mail (2.1503) Cc: Paul Hoffman , IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 16:38:43 -0000 On May 22, 2013, at 18:27, James M Snell wrote: > attached to some other piece of work One motivation is that we need some concise binary form for CoRE work. But we didn't think it was a good idea to define something that is = limited to that, as long as we can keep the simplicity. And it turned out that it wasn't too hard to make it useful for many = applications where JSON comes to mind first and then you start longing = for something binary. Gr=FC=DFe, Carsten From dave@cridland.net Wed May 22 10: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 E979621F95EB for ; Wed, 22 May 2013 10:40:08 -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 e-dV4FzJ6Ga3 for ; Wed, 22 May 2013 10:40:04 -0700 (PDT) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4CE21F9413 for ; Wed, 22 May 2013 10:40:04 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id m1so3044628oag.20 for ; Wed, 22 May 2013 10:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6dExKjt4a5j9KbgMU85QBICHCIPp1EalVXArFnVobFM=; b=TwsAE7OvocbeT3GrMmnNhaN1FuPzb/grVU8rIySxqlkGyOSruDgqfVIt1Dhv5mT+sX Lqo7le1AdKORaKnrBWHdQrrsYKg/zKhPv8Q9bWMzVyDoqAmYasp72CkglysLFNMX+jID H76PYYLzBdSzaiAArfM310lm7wcPGCHg+HmF4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=6dExKjt4a5j9KbgMU85QBICHCIPp1EalVXArFnVobFM=; b=Scfd61sMcTkPRfRsaz4fQTWUOmtkI3L9C0JAJY+jZO9ZWGOpCC+0DlmavvHHY0Tlhn k7Bh11cHOLt6rTGJ9Tlt4Lrd52fWlQP3uGazO3q4J0lVr0qO72JkkPNwTBaY9b8i3+X/ mupn8nnkGVDu6ygTm9ox902usshIR7iWV/xP+oJzN9Lbv52DcUrEdi2vMSJVUqQzZwcX no+CLa2YXqOsPGySN3yzl1ZJDDHx0sW8l6gbI4nDJdXdLYiDSfhxceItIyCmko95Afgl 0l/uGAHCoM6OXoyt1qgaqCG3cslGX+BFz3lUCh83XCh4ZduPEj/8aVxL1zthhlTCKv1V 7QAg== MIME-Version: 1.0 X-Received: by 10.60.85.74 with SMTP id f10mr5777972oez.32.1369244403778; Wed, 22 May 2013 10:40:03 -0700 (PDT) Received: by 10.60.62.146 with HTTP; Wed, 22 May 2013 10:40:03 -0700 (PDT) In-Reply-To: <04905D53-5022-4741-A2B6-9EE4593A4C65@tzi.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <04905D53-5022-4741-A2B6-9EE4593A4C65@tzi.org> Date: Wed, 22 May 2013 18:40:03 +0100 Message-ID: From: Dave Cridland To: Carsten Bormann Content-Type: multipart/alternative; boundary=089e0111b71c4ca94304dd520e2c X-Gm-Message-State: ALoCoQkB74bqW4fiPP0Wx+ijR16rEBwZjlkWApkTyVG5+1ya/GaSrftnyEUpgX1AJYLX58ce61++ Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 17:40:09 -0000 --089e0111b71c4ca94304dd520e2c Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 22, 2013 at 5:29 PM, Carsten Bormann wrote: > > I would like to have available a BER like encoding for JSON. > > What is it that you like about BER? > (And, as you mentioned there are a couple, which BER do you like :-)? > > There's only one BER, but there are also DER, CER, PER, XER, and probably others I can't instantly recall. > > But this proposal seems to be something rather different. > > We try to learn. > > CBOR can sure do everything a "BER for JSON" could do. And a little more. > I think that's the right approach. My only concerns - not hills to die on, but worth discussion, I think - are that: - I'd be keen to see a clean subset defined which always can be translated to JSON. My gut feeling is that this would be useful. - I'm instantly put on guard by the notion that there are multiple representations for the number 7. I would in general much prefer to see only one. I admit this may not be possible, or simple - maps, for instance, have no intrinsic ordering, enforcing an integer use the most compact representation is awkward, and so on. But having a canonical representation might well be missed later. Dave. --089e0111b71c4ca94304dd520e2c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 22, 2013 at 5:29 PM, Carsten Bormann <cabo@tzi.org= > wrote:
> I would like to have available a BER like encoding f= or JSON.

What is it that you like about BER?
(And, as you mentioned there are a couple, which BER do you like :-)?


There= 9;s only one BER, but there are also DER, CER, PER, XER, and probably other= s I can't instantly recall.
=A0
> But this proposal seems to be something rather different.

We try to learn.

CBOR can sure do everything a "BER for JSON" could do. =A0And a l= ittle more.

I think that's th= e right approach.

My only concerns - n= ot hills to die on, but worth discussion, I think - are that:

=A0- I'd be keen to see a clean subset = defined which always can be translated to JSON. My gut feeling is that this= would be useful.

=A0- I'm ins= tantly put on guard by the notion that there are multiple representations f= or the number 7. I would in general much prefer to see only one. I admit th= is may not be possible, or simple - maps, for instance, have no intrinsic o= rdering, enforcing an integer use the most compact representation is awkwar= d, and so on. But having a canonical representation might well be missed la= ter.

Dave.
--089e0111b71c4ca94304dd520e2c-- From fanf2@hermes.cam.ac.uk Wed May 22 10:42: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 7389F11E80FB for ; Wed, 22 May 2013 10:42: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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daaVBbaZw9Rz for ; Wed, 22 May 2013 10:42:03 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f52]) by ietfa.amsl.com (Postfix) with ESMTP id 6068F21F96D9 for ; Wed, 22 May 2013 10:42:03 -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]:47931) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1UfD33-0000yW-Ft (Exim 4.80_167-5a66dd3) (return-path ); Wed, 22 May 2013 18:42:01 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1UfD33-0004Yv-SW (Exim 4.72) (return-path ); Wed, 22 May 2013 18:42:01 +0100 Date: Wed, 22 May 2013 18:42:01 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Carsten Bormann In-Reply-To: <04905D53-5022-4741-A2B6-9EE4593A4C65@tzi.org> Message-ID: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <04905D53-5022-4741-A2B6-9EE4593A4C65@tzi.org> 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 Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 17:42:04 -0000 Why not BSON or BJSON or UBJSON or MsgPack or ... ? 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 dave@cridland.net Wed May 22 10:43: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 DC37821F96AA for ; Wed, 22 May 2013 10:43:17 -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 N5XWFhc+mlnv for ; Wed, 22 May 2013 10:43:13 -0700 (PDT) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 68A0011E8104 for ; Wed, 22 May 2013 10:43:13 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id h1so3120075oag.11 for ; Wed, 22 May 2013 10:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Vfapd0P9qpHzzWkgXzEDK/N3HYBIhEv1WqA3/VMsWeA=; b=ZXiLyClVie3LqA3o/x8bd+doO9vTs7//mVMWxf1Moyn4v9vIBDVqTdjRFYMjQllxtV A9h7SbqtpM1Y/zoB73HGT6ggDP/6eloyMI8thnuLk6M4qy6oI82OCcdQbMO8OkYsCqj6 z0k+5lH+YG8ZNhGplKPoKs3Srr2W1I/kJr/gA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Vfapd0P9qpHzzWkgXzEDK/N3HYBIhEv1WqA3/VMsWeA=; b=naxVt6poOZgCdj+l+Wdbzwn5yrHVk8VYd2ACukNVFST5ZxR9KxX3LhWztfa2/OTTlw LoXJgxGeJ2L0D9MwAILoOX+gNIffeGP2yyo3p7P4+m7cBXPs0YIN2+KI2jBJnHZN1LBf /HKm3Cwt/ZhZfBuLW2cxPNBkuKAOYHjwE5r3Wqk0ItsRmbgW9mwMU/Fb0NSfsRGdUlI4 OeEGDrpSnD2+Gvwz+R8PYh05uuKmszg0RP3GFVBxJX81rKoomabYYk6Trys0r3FiM4pE 2HRU3Q71xjWq6XaemV0xGbEtDZm2QGApOq/XWAdeiBE3Sse0i/lKaN10n6yoJe+buCoB wLYw== MIME-Version: 1.0 X-Received: by 10.182.237.6 with SMTP id uy6mr4111365obc.31.1369244592922; Wed, 22 May 2013 10:43:12 -0700 (PDT) Received: by 10.60.62.146 with HTTP; Wed, 22 May 2013 10:43:12 -0700 (PDT) In-Reply-To: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <04905D53-5022-4741-A2B6-9EE4593A4C65@tzi.org> Date: Wed, 22 May 2013 18:43:12 +0100 Message-ID: From: Dave Cridland To: Tony Finch Content-Type: multipart/alternative; boundary=e89a8ff24eaf92cff104dd521955 X-Gm-Message-State: ALoCoQl+Hz37X9nRCyTWeKewcfFwUknPLPK+8tJgX8lQmCuVDDCHYoOEExxGR13PJEWFByCzEYdl Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 17:43:18 -0000 --e89a8ff24eaf92cff104dd521955 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 22, 2013 at 6:42 PM, Tony Finch wrote: > Why not BSON or BJSON or UBJSON or MsgPack or ... ? > I was wondering whether Paul was going to do a compatible variant called PHOFF, actually. --e89a8ff24eaf92cff104dd521955 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, May 22, 2013 at 6:42 PM, Tony Finch <<= a href=3D"mailto:dot@dotat.at" target=3D"_blank">dot@dotat.at> wrote:
Why not BSON or BJSON or UBJSON or MsgPack o= r ... ?

I was wondering whether P= aul was going to do a compatible variant called PHOFF, actually.=A0
--e89a8ff24eaf92cff104dd521955-- From hallam@gmail.com Wed May 22 10:46: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 5ABCB21F91B0 for ; Wed, 22 May 2013 10:46:01 -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 CFWWz2raHifP for ; Wed, 22 May 2013 10:46:00 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3514F21F9058 for ; Wed, 22 May 2013 10:45:59 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hj6so236256wib.5 for ; Wed, 22 May 2013 10:45: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=4qeNR9qmvjnuIGWD8UmhOppBbzGRKs5JFv/yWhYydS4=; b=ZQK4bkO2f7gMXC4BRxS+zuHMlxDG64claPquInTzW3F9xkVvnPq/1IDUcFBzKLrfV9 oto7y62u5llzBuQ98D1s3kG6DwjcnQD8cLyqit0eX8UveoVbVHmSD4kAAKyfrRmSEu63 ZYD6MRC39wJvmn3yLzSuGHR1nhCjmSfqXjONLnNBwcfd9he2DBXyRfZXPV0T0WbdWQov bpudS0Kc9XukISK0lWgVj8Ywd4Tv2LaH9rYdcnfeY5aNMTiMcjoikiZ1LynBbS3e7SoK tWUfArdul+BeSYbuRS8ZT5GI3Wc5wmOxBe0xDXen9kEYJPbHLOSzjqtohM/6LOSx7tnQ 9e+w== MIME-Version: 1.0 X-Received: by 10.180.88.231 with SMTP id bj7mr35759293wib.5.1369244758491; Wed, 22 May 2013 10:45:58 -0700 (PDT) Received: by 10.194.7.138 with HTTP; Wed, 22 May 2013 10:45:58 -0700 (PDT) In-Reply-To: <04905D53-5022-4741-A2B6-9EE4593A4C65@tzi.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <04905D53-5022-4741-A2B6-9EE4593A4C65@tzi.org> Date: Wed, 22 May 2013 13:45:58 -0400 Message-ID: From: Phillip Hallam-Baker To: Carsten Bormann Content-Type: multipart/alternative; boundary=f46d0443048a70cba004dd5223d2 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 17:46:01 -0000 --f46d0443048a70cba004dd5223d2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 22, 2013 at 12:29 PM, Carsten Bormann wrote: > > I would like to have available a BER like encoding for JSON. > > What is it that you like about BER? > (And, as you mentioned there are a couple, which BER do you like :-)? There is only one BER as far as I know. The problem is they also have DER, XER etc. etc. The worst of these is DER which was a terrible implementation of an idea that was totally unnecessary in the first place. Canonicalization is an unnecessary and broken idea. The idea that people would pull X.509v3 certs apart and reconstitute them to check the signatures was silly. Nobody ever did, nobody ever will. The rationale for XML Dig sig canonicalization is a little better but should have been taken as evidence that SOAP was broken and we needed to do something different. The main advantage of BER is that they are a known quantity and anyone proposing to make changes needs to give reason. But I would still subset to remove features not needed by JSON. > > But this proposal seems to be something rather different. > > We try to learn. > > CBOR can sure do everything a "BER for JSON" could do. And a little more. > I would like no more, no less. -- Website: http://hallambaker.com/ --f46d0443048a70cba004dd5223d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 22, 2013 at 12:29 PM, Carsten Bormann <cabo@tzi.or= g> wrote:
> I would like to have available a BER like encoding for JSON.

What is it that you like about BER?
(And, as you mentioned there are a couple, which BER do you like :-)?

There is only one BER as far as I know. The prob= lem is they also have DER, XER etc. etc.=A0

The worst of these is DER which was a terrible implementation of an id= ea that was totally unnecessary in the first place. Canonicalization is an = unnecessary and broken idea. The idea that people would pull X.509v3 certs = apart and reconstitute them to check the signatures was silly. Nobody ever = did, nobody ever will.

The rationale for XML Dig sig canonicalization is a lit= tle better but should have been taken as evidence that SOAP was broken and = we needed to do something different.


The main advantage of BER is that they are a known quan= tity and anyone proposing to make changes needs to give reason.
<= br>
But I would still subset to remove features not needed by JSO= N.

=A0
> But this proposal seems to be something rather different.

We try to learn.

CBOR can sure do everything a "BER for JSON" could do. =A0And a l= ittle more.

I would like no more, no le= ss.=A0

--
Website: http://hallambaker.com/
--f46d0443048a70cba004dd5223d2-- From paul.hoffman@vpnc.org Wed May 22 10:55: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 1B92321F93D1 for ; Wed, 22 May 2013 10:55:37 -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 IVmG6VW9MY4u for ; Wed, 22 May 2013 10:55:36 -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 6415721F8EA6 for ; Wed, 22 May 2013 10:55:36 -0700 (PDT) Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4MHtRNF048884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 May 2013 10:55:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Wed, 22 May 2013 10:55:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <04905D53-5022-4741-A2B6-9EE4593A4C65@tzi.org> To: Dave Cridland X-Mailer: Apple Mail (2.1503) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 17:55:37 -0000 On May 22, 2013, at 10:40 AM, Dave Cridland wrote: > My only concerns - not hills to die on, but worth discussion, I think = - are that: >=20 > - I'd be keen to see a clean subset defined which always can be = translated to JSON. My gut feeling is that this would be useful. We tried for that in Section 4. If we can make that clearer or more = precise, we'd be happy to. > - I'm instantly put on guard by the notion that there are multiple = representations for the number 7. That was my first reaction as well. > I would in general much prefer to see only one. I admit this may not = be possible, or simple - maps, for instance, have no intrinsic ordering, = enforcing an integer use the most compact representation is awkward, and = so on. But having a canonical representation might well be missed later. We could add that as an option for the protocols that care about it. The = set of rules is small, so it's not a big deal. --Paul Hoffman= From paul.hoffman@vpnc.org Wed May 22 10:58: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 9807621F93D1 for ; Wed, 22 May 2013 10:58:03 -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 HVxYguguVuzM for ; Wed, 22 May 2013 10:58:03 -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 0CC6921F8EA6 for ; Wed, 22 May 2013 10:58:03 -0700 (PDT) Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4MHvYFi048935 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 May 2013 10:57:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Wed, 22 May 2013 10:57:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8F16DE1E-3D5F-4C38-937E-14EAF66D3D94@vpnc.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <04905D53-5022-4741-A2B6-9EE4593A4C65@tzi.org> To: Tony Finch X-Mailer: Apple Mail (2.1503) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 17:58:04 -0000 On May 22, 2013, at 10:42 AM, Tony Finch wrote: > Why not BSON or BJSON or UBJSON or MsgPack or ... ? Because they didn't meet the design objectives that we listed in Section = 1. MessagePack had a lot of what we wanted, which is why we say "CBOR = was inspired by MessagePack" in the acknowledgements. --Paul Hoffman= From dcrocker@bbiw.net Wed May 22 11:04: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 5017E21F8E06 for ; Wed, 22 May 2013 11:04:20 -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 JleeSGU8fqIO for ; Wed, 22 May 2013 11:04:15 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1872B11E8118 for ; Wed, 22 May 2013 11:04: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 r4MI47Ge020704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 May 2013 11:04:10 -0700 Message-ID: <519D0893.8010602@bbiw.net> Date: Wed, 22 May 2013 11:04:03 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <04905D53-5022-4741-A2B6-9EE4593A4C65@tzi.org> <8F16DE1E-3D5F-4C38-937E-14EAF66D3D94@vpnc.org> In-Reply-To: <8F16DE1E-3D5F-4C38-937E-14EAF66D3D94@vpnc.org> 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.67]); Wed, 22 May 2013 11:04:10 -0700 (PDT) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 18:04:20 -0000 On 5/22/2013 10:57 AM, Paul Hoffman wrote: > On May 22, 2013, at 10:42 AM, Tony Finch wrote: > >> Why not BSON or BJSON or UBJSON or MsgPack or ... ? > > Because they didn't meet the design objectives that we listed in Section 1. MessagePack had a lot of what we wanted, which is why we say "CBOR was inspired by MessagePack" in the acknowledgements. A response with the semantics of "because we liked the one we chose better" seems less responsive than what I took the question to be asking. I assume the nature of 'why' was for some discussion of the technical differences that justify the choice. That's certainly what I'd be interested in seeing and am suggesting a summary of it be added to the document. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From fanf2@hermes.cam.ac.uk Wed May 22 11:16: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 8EF5721F96B5 for ; Wed, 22 May 2013 11:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNGcnwp0zSl8 for ; Wed, 22 May 2013 11:16:35 -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 22F8621F96B4 for ; Wed, 22 May 2013 11:16:33 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from [213.205.229.13] (port=54142 helo=[10.49.106.32]) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587) with esmtpsa (PLAIN:fanf2) (TLSv1:AES128-SHA:128) id 1UfDaR-00034n-6Y (Exim 4.80_167-5a66dd3) (return-path ); Wed, 22 May 2013 19:16:31 +0100 References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <04905D53-5022-4741-A2B6-9EE4593A4C65@tzi.org> <8F16DE1E-3D5F-4C38-937E-14EAF66D3D94@vpnc.org> <519D0893.8010602@bbiw.net> Mime-Version: 1.0 (1.0) In-Reply-To: <519D0893.8010602@bbiw.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4BECAAE7-46CD-4C11-BBA8-3453CEC29519@dotat.at> X-Mailer: iPhone Mail (10B144) From: Tony Finch Date: Wed, 22 May 2013 19:16:24 +0100 To: Dave Crocker Sender: Tony Finch Cc: Paul Hoffman , IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 18:16:37 -0000 On 22 May 2013, at 19:04, Dave Crocker wrote: >=20 > I assume the nature of 'why' was for some discussion of the technical diff= erences that justify the choice. Right. This is an over-populated niche, and there need to be compelling reas= ons to disregard existing specs with running code. Tony. -- f.anthony.n.finch http://dotat.at/= From paul.hoffman@vpnc.org Wed May 22 11:25: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 6A40421F93E6 for ; Wed, 22 May 2013 11:25:44 -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 s++sVR2cOqDW for ; Wed, 22 May 2013 11:25:44 -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 DDEFA21F93DA for ; Wed, 22 May 2013 11:25:43 -0700 (PDT) Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4MIPC4Z058452 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 May 2013 11:25:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <4BECAAE7-46CD-4C11-BBA8-3453CEC29519@dotat.at> Date: Wed, 22 May 2013 11:25:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <04905D53-5022-4741-A2B6-9EE4593A4C65@tzi.org> <8F16DE1E-3D5F-4C38-937E-14EAF66D3D94@vpnc.org> <519D0893.8010602@bbiw.net> <4BECAAE7-46CD-4C11-BBA8-3453CEC29519@dotat.at> To: Tony Finch X-Mailer: Apple Mail (2.1503) Cc: Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 18:25:44 -0000 On May 22, 2013, at 11:16 AM, Tony Finch wrote: > On 22 May 2013, at 19:04, Dave Crocker wrote: >>=20 >> I assume the nature of 'why' was for some discussion of the technical = differences that justify the choice. >=20 > Right. This is an over-populated niche, and there need to be = compelling reasons to disregard existing specs with running code. Sure, we can add an analysis of our design goals against existing = formats as an appendix.=20 --Paul Hoffman= From hallam@gmail.com Wed May 22 11:40: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 8657511E8138 for ; Wed, 22 May 2013 11:40:56 -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 JNwooflu5b+G for ; Wed, 22 May 2013 11:40:55 -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 0650E21F9031 for ; Wed, 22 May 2013 11:40:49 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id f12so1136941wgh.27 for ; Wed, 22 May 2013 11:40: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 :cc:content-type; bh=d+IfjSWBlPzDO66S9gn3Sj+7+e8KScxnp4lSYq1GlDU=; b=L7kc57T0Hxj/ZD1YmYU6Mu9clrVTU/E195xKfOchHgv2vV3s4GHw/Ge/IYp0YtjdVX /TvcmEkiljVPUngHXylw9yttEcmwgW0c6R2nAOvnEF/10u5i65D6MW2vqFGNFuz+M2p1 nltqb/poADy+ooIhZ+9g+SAPpzRNKiqWfzerduwPGBGkSp42D+dyn1187UcZIbx4Shan x49yundk5+vxV5y8d88JAqnZe+YLBsmTI8+gmCbbuwYx7//fE4dTqbe8RQNqJBsMaXbS r5WszLnrXcVcs29lkX2fWhZtOVQ8mjKFB5GnTRQ8WLRGyt4ctK9ic4WmHhAj0VCKfE7L nSZg== MIME-Version: 1.0 X-Received: by 10.180.89.140 with SMTP id bo12mr36494476wib.22.1369248043518; Wed, 22 May 2013 11:40:43 -0700 (PDT) Received: by 10.194.7.138 with HTTP; Wed, 22 May 2013 11:40:43 -0700 (PDT) In-Reply-To: <4BECAAE7-46CD-4C11-BBA8-3453CEC29519@dotat.at> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <04905D53-5022-4741-A2B6-9EE4593A4C65@tzi.org> <8F16DE1E-3D5F-4C38-937E-14EAF66D3D94@vpnc.org> <519D0893.8010602@bbiw.net> <4BECAAE7-46CD-4C11-BBA8-3453CEC29519@dotat.at> Date: Wed, 22 May 2013 14:40:43 -0400 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: multipart/alternative; boundary=e89a8f3bab853e507204dd52e7fb Cc: Dave Crocker , IETF Apps Discuss , Paul Hoffman Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 18:40:58 -0000 --e89a8f3bab853e507204dd52e7fb Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 22, 2013 at 2:16 PM, Tony Finch wrote: > On 22 May 2013, at 19:04, Dave Crocker wrote: > > > > I assume the nature of 'why' was for some discussion of the technical > differences that justify the choice. > > Right. This is an over-populated niche, and there need to be compelling > reasons to disregard existing specs with running code. > > Tony. > Emphasis here being 'compelling'... The whole problem with this space is that it is so easy for someone to make a proposal. It doesn't really take much knowledge of the problem either. I have a code generator for protocols. Give it an API signature and it dumps out code to serialize and deserialise JSON. If people can agree on one binary alternative to JSON I will add it to the generator. But I don't plan to offer more than one. https://sourceforge.net/projects/jsonschema/ -- Website: http://hallambaker.com/ --e89a8f3bab853e507204dd52e7fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 22, 2013 at 2:16 PM, Tony Finch <dot@dotat.at&= gt; wrote:
=
On 22 May 2013, at 19:04, Dave Crocker <dcrocker@bbiw.net> wrote:
>
> I assume the nature of 'why' was for some discussion of the te= chnical differences that justify the choice.

Right. This is an over-populated niche, and there need to be compelli= ng reasons to disregard existing specs with running code.

Tony.

Emphasis here being '= compelling'...=A0

The whole proble= m with this space is that it is so easy for someone to make a proposal. It = doesn't really take much knowledge of the problem either.


I have a code generator for protoc= ols. Give it an API signature and it dumps out code to serialize and deseri= alise JSON. If people can agree on one binary alternative to JSON I will ad= d it to the generator. But I don't plan to offer more than one.


= --
Website: http://hallambaker.com/=
--e89a8f3bab853e507204dd52e7fb-- From cabo@tzi.org Wed May 22 11:42: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 A595411E8137 for ; Wed, 22 May 2013 11:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.2 X-Spam-Level: X-Spam-Status: No, score=-106.2 tagged_above=-999 required=5 tests=[AWL=0.049, 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 drCAfXS-pNac for ; Wed, 22 May 2013 11:42:16 -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 3D07F11E8136 for ; Wed, 22 May 2013 11:42:15 -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 r4MIg5EZ008959; Wed, 22 May 2013 20:42:05 +0200 (CEST) Received: from [192.168.217.105] (p54891D40.dip0.t-ipconnect.de [84.137.29.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B43C43954; Wed, 22 May 2013 20:42:04 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <519D0893.8010602@bbiw.net> Date: Wed, 22 May 2013 20:42:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <04905D53-5022-4741-A2B6-9EE4593A4C65@tzi.org> <8F16DE1E-3D5F-4C38-937E-14EAF66D3D94@vpnc.org> <519D0893.8010602@bbiw.net> To: Dave Crocker X-Mailer: Apple Mail (2.1503) Cc: Paul Hoffman , IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 18:42:22 -0000 On May 22, 2013, at 20:04, Dave Crocker wrote: > That's certainly what I'd be interested in seeing and am suggesting a = summary of it be added to the document. The summary of our objectives is in section 1. A summary of all the formats that we looked at would be great for an = encyclopedia, but not for the protocol specification. (And, as I mentioned in prt In 1980, when the specification for a new programming language came out = that most people by now have forgotten, one major innovation was that it = was accompanied by a "rationale" document. This was much bigger than the specification. And, somehow, when I read = it, I had the impression that much of it was used to justify design = decisions that were untenable. Yes, we could document the rationale behind each of the about five = design decisions that went into CBOR. But doesn't the specification of something as simple as this speak for = itself? Gr=FC=DFe, Carsten From jasnell@gmail.com Wed May 22 11:44: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 4A72411E8144 for ; Wed, 22 May 2013 11:44: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=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDa-Wgio5oql for ; Wed, 22 May 2013 11:44:15 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id C1EB711E8136 for ; Wed, 22 May 2013 11:44:15 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id ta14so1662532obb.10 for ; Wed, 22 May 2013 11:44:15 -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=yJta8CLCug8K0aQJJao+LKf5j3Cz407MGxEebCCpzAc=; b=CLZDrbsmqj7VOhlgNe+RsYoF1ET/adgqYfk+y4zj+vV+mLUpGgwWA1vy8iTey/Xr4B ZpolM9mJRg30IDwUjt1dukqLJytLPOpHo/Pl6A/AiKD02am3tn2wDgwMaV1ZqmafdZkT jTKGgxu6rfc1BvpQxfcH6rQxV6AQU1RTfrljuCd9e9pZ+tcyNw2N/t97XI0XCBo8dcyO fdQcqq8U0/M1zQy2P6eU48VIKyIGhEwTMWqrLDtlTWNxNJfA81oriGUxsav2Kbldidko tr+sX3TBQx05JedE07EIgU2pg9uQoHPobwrXyAYYSgGVc/U73D++/heVRLFKtRfuEfWW l3Gg== X-Received: by 10.182.227.133 with SMTP id sa5mr5789154obc.96.1369248255050; Wed, 22 May 2013 11:44:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.3.137 with HTTP; Wed, 22 May 2013 11:43:54 -0700 (PDT) In-Reply-To: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <04905D53-5022-4741-A2B6-9EE4593A4C65@tzi.org> <8F16DE1E-3D5F-4C38-937E-14EAF66D3D94@vpnc.org> <519D0893.8010602@bbiw.net> From: James M Snell Date: Wed, 22 May 2013 11:43:54 -0700 Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Dave Crocker , IETF Apps Discuss , Paul Hoffman Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 18:44:16 -0000 Best bet: define the syntax, provide a couple of great open source implementations, let people know about them.. then time will tell whether it'll be worthwhile to standardize. There shouldn't be any rush on getting an RFC done. On Wed, May 22, 2013 at 11:42 AM, Carsten Bormann wrote: > On May 22, 2013, at 20:04, Dave Crocker wrote: > >> That's certainly what I'd be interested in seeing and am suggesting a su= mmary of it be added to the document. > > The summary of our objectives is in section 1. > > A summary of all the formats that we looked at would be great for an ency= clopedia, but not for the protocol specification. > (And, as I mentioned in prt > > In 1980, when the specification for a new programming language came out t= hat most people by now have forgotten, one major innovation was that it was= accompanied by a "rationale" document. > This was much bigger than the specification. And, somehow, when I read i= t, I had the impression that much of it was used to justify design decision= s that were untenable. > > Yes, we could document the rationale behind each of the about five design= decisions that went into CBOR. > But doesn't the specification of something as simple as this speak for it= self? > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From cabo@tzi.org Wed May 22 11:55: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 46CEC21F96E8 for ; Wed, 22 May 2013 11:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.203 X-Spam-Level: X-Spam-Status: No, score=-106.203 tagged_above=-999 required=5 tests=[AWL=0.046, 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 qukNPYPgj37o for ; Wed, 22 May 2013 11:55:42 -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 3663311E80E3 for ; Wed, 22 May 2013 11:55:42 -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 r4MItdHb002627; Wed, 22 May 2013 20:55:39 +0200 (CEST) Received: from [192.168.217.105] (p54891D40.dip0.t-ipconnect.de [84.137.29.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A51F1395B; Wed, 22 May 2013 20:55:38 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 22 May 2013 20:55:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6F7D44CD-E48E-4E74-9FF4-A29553124D9B@tzi.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <04905D53-5022-4741-A2B6-9EE4593A4C65@tzi.org> To: Dave Cridland X-Mailer: Apple Mail (2.1503) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 18:55:47 -0000 On May 22, 2013, at 19:40, Dave Cridland wrote: > - I'm instantly put on guard by the notion that there are multiple = representations for the number 7. Indeed, the lack of the "unique encoding" property creates heartburn for = at least one author of the specification. (We have gone to considerable length in getting unique encodings in CoAP = options. Even there, we didn't quite succeed.) One good way to ensure unique encoding for unsigned integers is the o256 = encoding documented in Appendix A.4 of = http://tools.ietf.org/html/draft-bormann-coap-misc-25 This is just not the right way for CBOR. > I would in general much prefer to see only one. I admit this may not = be possible, or simple - maps, for instance, have no intrinsic ordering, = enforcing an integer use the most compact representation is awkward, and = so on. But having a canonical representation might well be missed later. There is a tradeoff between the complexity of the serializer and that of = the deserializer. Complete canonicalization puts the onus on the serializer; e.g., you = have to sort the keys of a map before encoding it. On the other hand, the deserializer knows exactly what to expect when -- = if you have seen "b", you know there won't be an "a". (There is also the use of c14n for signature. I don't want to go = there...) I think we have the right balance between serializer and deserializer = here -- if you have a very constrained serializer, it may be expedient = to leave out code for always choosing the shortest representation. The = deserializer already has to have the ability to handle longer = representations, so the net value of this design decision is positive. Gr=FC=DFe, Carsten From cabo@tzi.org Wed May 22 12:18: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 A3EED11E8142 for ; Wed, 22 May 2013 12:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.205 X-Spam-Level: X-Spam-Status: No, score=-106.205 tagged_above=-999 required=5 tests=[AWL=0.044, 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 J4xtU8dhyLlR for ; Wed, 22 May 2013 12:18:34 -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 7937521F96F9 for ; Wed, 22 May 2013 12:18:34 -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 r4MJIQd6013186; Wed, 22 May 2013 21:18:26 +0200 (CEST) Received: from [192.168.217.105] (p54891D40.dip0.t-ipconnect.de [84.137.29.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 157323973; Wed, 22 May 2013 21:18:26 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 22 May 2013 21:18:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <04905D53-5022-4741-A2B6-9EE4593A4C65@tzi.org> <8F16DE1E-3D5F-4C38-937E-14EAF66D3D94@vpnc.org> <519D0893.8010602@bbiw.net> To: James M Snell X-Mailer: Apple Mail (2.1503) Cc: Dave Crocker , IETF Apps Discuss , Paul Hoffman Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 19:18:40 -0000 On May 22, 2013, at 20:43, James M Snell wrote: > Best bet: define the syntax, provide a couple of great open source > implementations, let people know about them.. then time will tell > whether it'll be worthwhile to standardize. There shouldn't be any > rush on getting an RFC done. Of course, the degree of success of a technical specification is = dominated by external effects, such as the highly random process in = which it is picked up by implementers. What I am trying to do here is just provide a very good specification. Good marketing, open-source reference implementations, TED speaking = engagements, articles in Network World, pickup by CPU vendors that put = in useful instructions for generating/parsing it, cloud services, = funding for related research etc. (in other words, mindshare) comes = after that. =20 However, this is a specification that could (and should) be used by = other specifications that the IETF and other organizations will be = creating. So saying "you can have the RFC after the first TED talk" is = not helping those other specifications along. (This is not an argument against running code, just against "let the = market decide on whatever and then standardize".) Gr=FC=DFe, Carsten From dcrocker@bbiw.net Wed May 22 12:37: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 271E711E8156 for ; Wed, 22 May 2013 12:37:05 -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 7Usa5xsLiTIo for ; Wed, 22 May 2013 12:36:59 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 902C311E8155 for ; Wed, 22 May 2013 12:36:51 -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 r4MJakbv022852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 May 2013 12:36:49 -0700 Message-ID: <519D1E4A.1090307@bbiw.net> Date: Wed, 22 May 2013 12:36:42 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Carsten Bormann References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <04905D53-5022-4741-A2B6-9EE4593A4C65@tzi.org> <8F16DE1E-3D5F-4C38-937E-14EAF66D3D94@vpnc.org> <519D0893.8010602@bbiw.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.67]); Wed, 22 May 2013 12:36:49 -0700 (PDT) Cc: Paul Hoffman , IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 19:37:05 -0000 On 5/22/2013 12:18 PM, Carsten Bormann wrote: > Good marketing, open-source reference implementations, TED speaking engagements, articles in Network World, pickup by CPU vendors that put in useful instructions for generating/parsing it, cloud services, funding for related research etc. (in other words, mindshare) comes after that. don't forget to give away CBOR buttons in Berlin, although you might have to explain to folks that it's not your login. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From paul.hoffman@vpnc.org Wed May 22 13:20: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 4093C11E80EE for ; Wed, 22 May 2013 13:20:38 -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 5bI-YoyvwmHq for ; Wed, 22 May 2013 13:20:37 -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 7AFB011E80A2 for ; Wed, 22 May 2013 13:20:37 -0700 (PDT) Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4MKKYhE061949 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 May 2013 13:20:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Wed, 22 May 2013 13:20:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <04905D53-5022-4741-A2B6-9EE4593A4C65@tzi.org> <8F16DE1E-3D5F-4C38-937E-14EAF66D3D94@vpnc.org> <519D0893.8010602@bbiw.net> To: James M Snell X-Mailer: Apple Mail (2.1503) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 20:20:38 -0000 On May 22, 2013, at 11:43 AM, James M Snell wrote: > Best bet: define the syntax, provide a couple of great open source > implementations, let people know about them.. then time will tell > whether it'll be worthwhile to standardize. Fully disagree. As a great recent counter-example, see what is happening = in the MessagePack world which is following exactly what you suggest, = and there is a lot of bad feelings. > There shouldn't be any > rush on getting an RFC done. There is no rush to get it done, but there is no reason to not publish = it once it is stable and has gotten a lot of good input. --Paul Hoffman= From paul.hoffman@vpnc.org Wed May 22 13:23: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 E342621F941F for ; Wed, 22 May 2013 13:23:40 -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 jydKODmFlcfk for ; Wed, 22 May 2013 13:23:40 -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 AD79821F8F61 for ; Wed, 22 May 2013 13:23:39 -0700 (PDT) Received: from [165.227.249.247] (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4MKNcMk062019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 22 May 2013 13:23:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <6F7D44CD-E48E-4E74-9FF4-A29553124D9B@tzi.org> Date: Wed, 22 May 2013 13:23:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <04905D53-5022-4741-A2B6-9EE4593A4C65@tzi.org> <6F7D44CD-E48E-4E74-9FF4-A29553124D9B@tzi.org> To: IETF Apps Discuss X-Mailer: Apple Mail (2.1503) Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 20:23:41 -0000 On May 22, 2013, at 11:55 AM, Carsten Bormann wrote: > There is a tradeoff between the complexity of the serializer and that = of the deserializer. > Complete canonicalization puts the onus on the serializer; e.g., you = have to sort the keys of a map before encoding it. > On the other hand, the deserializer knows exactly what to expect when = -- if you have seen "b", you know there won't be an "a". >=20 > (There is also the use of c14n for signature. I don't want to go = there...) And here y'all get to see the two authors disagree. (Don't worry, there = has been plenty of that in the past few months.) The -01 will have a = section on canonicalization that will say the same thing as much of = Section 3: if a protocol wants to take on canonicalization it can, but = it is not required by the format spec. --Paul Hoffman= From internet-drafts@ietf.org Wed May 22 13:39: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 A421311E8119; Wed, 22 May 2013 13:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.096, 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 gCfgxxDX+F88; Wed, 22 May 2013 13:39:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AA311E80A2; Wed, 22 May 2013 13:39:18 -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.50 Message-ID: <20130522203918.23617.23684.idtracker@ietfa.amsl.com> Date: Wed, 22 May 2013 13:39:18 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-sieve-duplicate-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: Wed, 22 May 2013 20:39:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Sieve Email Filtering: Detecting Duplicate Deliveries Author(s) : Stephan Bosch Filename : draft-ietf-appsawg-sieve-duplicate-00.txt Pages : 10 Date : 2013-05-22 Abstract: This document defines a new test command "duplicate" for the "Sieve" email filtering language. This test adds the ability to detect duplicate message deliveries. The main application for this new test is handling duplicate deliveries commonly caused by mailing list subscriptions or redirected mail addresses. The detection is normally performed by matching the message ID to an internal list of message IDs from previously delivered messages. For more complex applications, the "duplicate" test can also use the content of a specific header or other parts of the message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-sieve-duplicate-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cabo@tzi.org Wed May 22 13:40: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 5B2E121F94F9 for ; Wed, 22 May 2013 13:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.209 X-Spam-Level: X-Spam-Status: No, score=-106.209 tagged_above=-999 required=5 tests=[AWL=0.040, 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 v3bleoMVYe+B for ; Wed, 22 May 2013 13:40:26 -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 8C9AF21F960B for ; Wed, 22 May 2013 13:40: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 r4MKd3hC005632; Wed, 22 May 2013 22:39:03 +0200 (CEST) Received: from [192.168.217.105] (p54891D40.dip0.t-ipconnect.de [84.137.29.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D78E539BB; Wed, 22 May 2013 22:39:02 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Wed, 22 May 2013 22:39:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <04905D53-5022-4741-A2B6-9EE4593A4C65@tzi.org> To: Tony Finch X-Mailer: Apple Mail (2.1503) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 May 2013 20:40:32 -0000 On May 22, 2013, at 19:42, Tony Finch wrote: > Why not BSON or BJSON or UBJSON or MsgPack or ... ? Good question, and one that deserves to be answered (maybe not in a = formal document). =20 But, as Dave has alluded to, any such discussion MUST start with RFC = 713. I urge you to read it if you are interested in this space. What have we learned in the 37 years since RFC 713? Less than one might think. I think the most important observation was that it is not the character = that is the fundamental data type, but the text string. We also have a pretty good and well accepted encoding for it: UTF-8. So = that is one centerpiece of CBOR. The other sea change that has happened is that a number of S-expression = based formats have come and gone, but JSON seems to be here to stay. So JSON has been a strong inspiration, including the map (dictionary, = hash, table, ...) type called "object" in JSON. In contrast to RFC 713's well thought-out variable-size scheme, we did a = fixed partitioning of the type byte (3 + 5 bits) because that is easier = to handle both in high-speed and in very constrained implementations (of = course, what is very constrained today might have been quite comfortable = in 1976, except that we have to cram in so much more functionality = today). We are also using an item count and not a byte count for structured = (non-atomic in RFC 713 terms) items. There is no equivalent in CBOR to RFC 713's b-REPEAT -- we entirely left = out compression mechanisms. Gr=FC=DFe, Carsten From stephan@rename-it.nl Wed May 22 15:19:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B745111E814D; Wed, 22 May 2013 15:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39djoRUaR3Qs; Wed, 22 May 2013 15:19:52 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id BE1E611E814C; Wed, 22 May 2013 15:19:50 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:51049 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UfHNg-0002rI-Nn; Thu, 23 May 2013 00:19:48 +0200 Message-ID: <519D4466.1030701@rename-it.nl> Date: Thu, 23 May 2013 00:19:18 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: apps-discuss@ietf.org, Sieve mailing list References: <20130522203918.23617.23684.idtracker@ietfa.amsl.com> In-Reply-To: <20130522203918.23617.23684.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-sieve-duplicate-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: Wed, 22 May 2013 22:19:56 -0000 Hello, This draft describes an extension to the Sieve mail filtering language (RFC 5228) called "duplicate". It adds the ability to detect duplicate message deliveries. The main application for this new extension is handling duplicate deliveries commonly caused by mailing list subscriptions or redirected mail addresses. Using this extension, the user can for example decide to move duplicate messages to a special folder, mark them as 'seen', or discard them altogether. I first implemented this extension a little more than a year ago as a vendor-defined extension for my own Sieve implementation (Dovecot Pigeonhole). I did this upon repeated requests from users. They were looking for a Sieve-equivalent of what could be achieved with Procmail using `formail -D`. Since then, I extended it a bit and eventually I made it more generic. In January of this year I decided that it may be suitable for proper standardization, so I posted the specification on the Sieve mailing list (https://www.ietf.org/mail-archive/web/sieve/current/msg05292.html). There, it was first picked up and reviewed by Ned Freed and Alexey Melnikov and I turned it into a first I-D submission. The next versions -01 and -02 were discussed in these threads: https://www.ietf.org/mail-archive/web/sieve/current/msg05300.html https://www.ietf.org/mail-archive/web/sieve/current/msg05310.html At this point it was decided that the document was sufficiently mature to start the process of becoming a proposed standard. Since the Sieve WG is no longer the obvious place to do this, it was moved to APPSAWG. Apart from its name, the new submission draft-ietf-appsawg-sieve-duplicate-00 is identical to draft-bosch-sieve-duplicate-02. The following are known issues we haven't addressed in the latest version so far and I think these should be discussed a bit more: - Do we measure the expiry time of entries in the duplicate tracking list relative to the initial message or relative to the last duplicate (https://www.ietf.org/mail-archive/web/sieve/current/msg05310.html). Should we make this configurable? - Is the "duplicate" extension supposed to be active in IMAPSieve (RFC 6785) context (https://www.ietf.org/mail-archive/web/sieve/current/msg05314.html)? Currently, consensus is to mark this as NOT RECOMMENDED. I'd like to finish this document some time in July or August. For that, it would be nice to get it thoroughly reviewed, so your reviews and comments are very welcome! Regards, Stephan Bosch. On 5/22/2013 10:39 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Applications Area Working Group Working Group of the IETF. > > Title : Sieve Email Filtering: Detecting Duplicate Deliveries > Author(s) : Stephan Bosch > Filename : draft-ietf-appsawg-sieve-duplicate-00.txt > Pages : 10 > Date : 2013-05-22 > > Abstract: > This document defines a new test command "duplicate" for the "Sieve" > email filtering language. This test adds the ability to detect > duplicate message deliveries. The main application for this new test > is handling duplicate deliveries commonly caused by mailing list > subscriptions or redirected mail addresses. The detection is > normally performed by matching the message ID to an internal list of > message IDs from previously delivered messages. For more complex > applications, the "duplicate" test can also use the content of a > specific header or other parts of the message. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-appsawg-sieve-duplicate-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From sm@elandsys.com Wed May 22 16:19:36 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A0911E8158 for ; Wed, 22 May 2013 16:19:36 -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 dZHNSBl-nz1P for ; Wed, 22 May 2013 16:19: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 5DE7811E8151 for ; Wed, 22 May 2013 16:19:34 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.233.124]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4MNGduH002965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 May 2013 16:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1369264611; bh=EchCBJvxhgQx3hZhYoEX5b2S75SrSQvqS0yLAALNSts=; h=Date:To:From:Subject:Cc; b=108v9uEebXfUVNCXdDbkpdIWbTxT6IkD4R8bJXOTC0ScYcQefidOY1vV/Nly4DAgV Ak7srDrMwAxekHXvzV6VgofvICsT2u6UEJPLC06xnNT3o9yOGHZRMQc7rQPAzO+oQz n8VqI+OXCdoQkLbof3h59na4u7RybQl38DAuQaic= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1369264611; i=@elandsys.com; bh=EchCBJvxhgQx3hZhYoEX5b2S75SrSQvqS0yLAALNSts=; h=Date:To:From:Subject:Cc; b=gBiHoVc+cOKVZGuWOsFCaxiglemffS7IsY4XtpqL7JddufAaElxVG51vui1iEZ5qV BtL3RZEVGtAkij9/wkGJkssr2biigRE5s3eGg+r8zoCPfuyzsvnMudsCdT+6iRC2Yv 76h7c5CD2F8iLPI8FO9Q5quCOfVLmCgVEXYDxc6U= Message-Id: <6.2.5.6.2.20130522160748.0b973f18@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 22 May 2013 16:15:49 -0700 To: Barry Leiba From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: [apps-discuss] Publication request for draft-ietf-appsawg-rfc5451bis-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, 22 May 2013 23:19:36 -0000 Hi Barry, The Appsawg requests publication of draft-ietf-appsawg-rfc5451bis-04. The Document Shepherd Write-Up is below. 1. Summary The document shepherd is S. Moonesamy. The Responsible Area Director is Barry Leiba. draft-ietf-appsawg-rfc5451bis specifies a header field (Authentication-Results) for use with electronic mail messages to indicate the results of message authentication efforts. RFC 5451 was published as a Proposed Standard in April 2009. draft-ietf-appsawg-rfc5451bis incorporates RFC 5451 and its errata and RFC 6577 (Authentication-Results Registration Update). The intended status is Internet Standard as there are seven implementations of the specification and it has gained significant deployment. 2. Review and Consensus The document was discussed by five participants within the Applications Area Working Group and it has the consensus of the working group. The issues raised during the WGLC were resolved quickly. 3. Intellectual Property There isn't any IPR disclosure referencing this document. The author has confirmed that the document is in full conformance with BCP 78 and BCP 79. 4. Other points The document obsoletes RFC 5451 and RFC 6577. The "CFWS" mentioned in idnits is not a missing reference. The informational reference to RFC 4870 is intentional. RFC 2045 and RFC 5321 are downward references. RFC 5322 is already listed in the DOWNREF registry. A designated expert will have to be appointed by the IESG for the "Email Authentication Method Name" and "Email Authentication Result Name" registries. The allocation procedures and polices are clearly mentioned in Section 6.2 and Section 6.3. Regards, S. Moonesamy (as document shepherd) From superuser@gmail.com Wed May 22 16: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 7213F21F8EEC for ; Wed, 22 May 2013 16:30: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 BwKXYcNCZZKS for ; Wed, 22 May 2013 16:30:03 -0700 (PDT) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id BB0F521F8EBB for ; Wed, 22 May 2013 16:30:03 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id xb12so2261101pbc.28 for ; Wed, 22 May 2013 16:30: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=5x5UnJGOAVvibsbnO72dCNIqBvGB/I05Q7ifSs2hOt8=; b=Ok3uw0egUzbAODK0b/yI7LN/iZ+ErmmSYr5AhycAt5q4v77HdSAkWxMWZFO4mYi+U1 1dl+bi8uoWZ1p/xKaDEqg/xUkHuav7oRpdf3IqKw6FBldrbe3L5dHkSpMkQjujmCpC3F H1mU3icGSjmEaRXHhibeBOwM5hJDq20370Cy8B2sI/4e5ZMUO7aMoZ80tBvqClX0UmsD DK0UZBOMoktOt6+faiAEogB6JdTuxrVm3iUsMsk5AjViDM7LomLFK0OqxBjhtUSdw7d5 KfAFvW4ABBg2MfpiVZpGgArgCv89H4RoNA5d/Tenchu9K75DYzhXQuCNSPCKCSIRkq/L wsOg== MIME-Version: 1.0 X-Received: by 10.68.201.5 with SMTP id jw5mr10152745pbc.40.1369265403433; Wed, 22 May 2013 16:30:03 -0700 (PDT) Received: by 10.66.234.40 with HTTP; Wed, 22 May 2013 16:30:03 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130522160748.0b973f18@elandnews.com> References: <6.2.5.6.2.20130522160748.0b973f18@elandnews.com> Date: Wed, 22 May 2013 16:30:03 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=047d7b15a96df9993f04dd56f11f Cc: Barry Leiba , IETF Apps Discuss Subject: Re: [apps-discuss] Publication request for draft-ietf-appsawg-rfc5451bis-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, 22 May 2013 23:30:04 -0000 --047d7b15a96df9993f04dd56f11f Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 22, 2013 at 4:15 PM, S Moonesamy wrote: > Hi Barry, > > The Appsawg requests publication of draft-ietf-appsawg-rfc5451bis-**04. > The Document Shepherd Write-Up is below. > Datatracker updated. Thanks for shepherding, SM. > 4. Other points > > The document obsoletes RFC 5451 and RFC 6577. > This isn't explicitly called out in the Introduction or Abstract. In previous conversations here about another document, a few people opined that having it stated there as well as in the first page header was a silly practice, and I don't remember anyone insisting on it, so I've left it out here. We can add it in during IETF LC or such if there's strong objection to its omission. Clearly though, RFC5451 is obsoleted because it is the previous version of this document, and RFC6577 is obsoleted because it was effectively an erratum against RFC5451 that required an IANA action to fix. This latter thing is called out in the "Changes Since" section at the end. > > RFC 2045 and RFC 5321 are downward references. RFC 5322 is already > listed in > the DOWNREF registry. > A question about this: If this document is going for Internet Standard status, is a normative reference to a Proposed Standard considered a downward reference even though both are standards track documents? The RFC that talks about downward references seems to talk a lot about standards track documents referencing Informational, Experimental or HIstoric documents, but not to references within the standards track. -MSK --047d7b15a96df9993f04dd56f11f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 22, 2013 at 4:15 PM, S Moonesamy <sm+ietf@= elandsys.com> wrote:
Hi Barry,

The Appsawg requests publication of draft-ietf-appsawg-rfc5451bis-04= . =A0The Document Shepherd Write-Up is below.

Datatracker updated.=A0 Thanks for shepherding, SM.
=A0
=
4. Other points

=A0 =A0The document obsoletes RFC 5451 and RFC 6577.
<= br>
This isn't explicitly called out in the Introduction or A= bstract.=A0 In previous conversations here about another document, a few pe= ople opined that having it stated there as well as in the first page header= was a silly practice, and I don't remember anyone insisting on it, so = I've left it out here.=A0 We can add it in during IETF LC or such if th= ere's strong objection to its omission.=A0 Clearly though, RFC5451 is o= bsoleted because it is the previous version of this document, and RFC6577 i= s obsoleted because it was effectively an erratum against RFC5451 that requ= ired an IANA action to fix.=A0 This latter thing is called out in the "= ;Changes Since" section at the end.
=A0

=A0=A0 RFC 2045 and RFC 5321 are downward references. =A0RFC 5322 is alread= y listed in
=A0 =A0the DOWNREF registry.

A question= about this: If this document is going for Internet Standard status, is a n= ormative reference to a Proposed Standard considered a downward reference e= ven though both are standards track documents?=A0 The RFC that talks about = downward references seems to talk a lot about standards track documents ref= erencing Informational, Experimental or HIstoric documents, but not to refe= rences within the standards track.

-MSK
--047d7b15a96df9993f04dd56f11f-- From ietf-secretariat-reply@ietf.org Wed May 22 16:35: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 F1ADF21F915C for ; Wed, 22 May 2013 16:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, 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 92sWbFWw39I1 for ; Wed, 22 May 2013 16:35:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C7A21F9180 for ; Wed, 22 May 2013 16:35: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.50 Message-ID: <20130522233528.17492.35456.idtracker@ietfa.amsl.com> Date: Wed, 22 May 2013 16:35: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: Wed, 22 May 2013 23:35:29 -0000 URL: http://datatracker.ietf.org/wg/appsawg/charter/ From James.H.Manger@team.telstra.com Wed May 22 18:49: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 CC70611E8181 for ; Wed, 22 May 2013 18:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.325 X-Spam-Level: X-Spam-Status: No, score=-0.325 tagged_above=-999 required=5 tests=[AWL=0.576, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uSF1Fmo6b+0 for ; Wed, 22 May 2013 18:49:26 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id F17A911E815B for ; Wed, 22 May 2013 18:49:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,725,1363093200"; d="scan'208";a="138769329" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 23 May 2013 11:49:20 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7083"; a="138776811" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipccni.tcif.telstra.com.au with ESMTP; 23 May 2013 11:49:20 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Thu, 23 May 2013 11:49:20 +1000 From: "Manger, James H" To: "apps-discuss@ietf.org" Date: Thu, 23 May 2013 11:49:19 +1000 Thread-Topic: [apps-discuss] Concise Binary Object Representation (CBOR) -- support streaming Thread-Index: Ac5W+5nrcSLuagvXSgiAuBQgwxS2KQAVVUVQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1151A8ACB34@WSMSG3153V.srv.dir.telstra.com> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> In-Reply-To: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) -- support streaming X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 01:49:33 -0000 Q0JPUiBbZHJhZnQtYm9ybWFubi1jYm9yXSBsb29rcyBncmVhdC4NCg0KVGhlIG9ubHkgYmlnIHBy b2JsZW0gSSBzZWUgaXMgdGhhdCBzaXplcyBoYXZlIHRvIGJlIGtub3duIHVwZnJvbnQuIFlvdSBu ZWVkIHRvIGtub3cgaG93IG1hbnkgYnl0ZXMsIGFycmF5IGVsZW1lbnRzLCBvciBtYXAgcGFpcnMg eW91IGhhdmUgQkVGT1JFIHlvdSBzdGFydCBlbmNvZGluZyB0aGVtLiBUaGlzIHJlYWxseSBoaW5k ZXJzIHN0cmVhbWluZyBjb250ZW50LiBKU09OIGRvZXMgbm90IGhhdmUgdGhpcyBsaW1pdGF0aW9u IHNvIENCT1Igc2hvdWxkIG5vdCBpbnRyb2R1Y2UgaXQuIFJlbW92aW5nIHRoaXMgbGltaXRhdGlv biB3b3VsZCBiZXR0ZXIgbWVldCBvYmplY3RpdmUgNTogImJlIGFwcGxpY2FibGUgdG8gYm90aCBj b25zdHJhaW5lZCBub2RlcyBhbmQgaGlnaC12b2x1bWUgYXBwbGljYXRpb25zIi4NCg0KVGhpcyBz aG91bGQgbm90IGJlIGhhcmQgdG8gc29sdmUsIG5vciB0byBpbXBsZW1lbnQuDQpGb3IgaW5zdGFu Y2UgZGVmaW5lIGluaXRpYWwgYnl0ZXMgZm9yICJBcnJheSIsICJNYXAiLCAiQnl0ZSBhcnJheSBp biBwYXJ0cyIsIGFuZCAiRW5kIi4gQW4gYXJyYXkgaXMgdGhlIGl0ZW1zIGJldHdlZW4gIkFycmF5 IiBhbmQgIkVuZCIuIEEgbWFwIGlzIGFuIGV2ZW4gbnVtYmVyIG9mIGl0ZW1zIGJldHdlZW4gIk1h cCIgYW5kICJFbmQiLiBUaGVyZSB3b3VsZCBiZSBubyBuZWVkIGZvciB0aGUgNjQgaW5pdGlhbCBi eXRlcyBhc3NpZ25lZCB0byBrbm93bi1zaXplIHZlcnNpb25zIG9mIGFycmF5cyBhbmQgbWFwcy4N Cg0KVGhlIDMyIGluaXRpYWwgYnl0ZXMgZm9yIGtub3duLWxlbmd0aCBieXRlIGFycmF5cyB3b3Vs ZCByZW1haW4uIFRoZSAiQnl0ZSBhcnJheSBpbiBwYXJ0cyIgaW5pdGlhbCBieXRlIHdvdWxkIGJl IGFuIGFkZGl0aW9uYWwgb3B0aW9uLiBCZXR3ZWVuICJCeXRlIGFycmF5IGluIHBhcnRzIiBhbmQg IkVuZCIgY2FuIGJlIGFueSBudW1iZXIgb2Yga25vd24tbGVuZ3RoIGJ5dGUgYXJyYXkgaXRlbXMu DQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From hallam@gmail.com Wed May 22 19:04: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 6E2C511E812A for ; Wed, 22 May 2013 19:04: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 LnGgjokq9AZn for ; Wed, 22 May 2013 19:04:56 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id BF1FA21F826B for ; Wed, 22 May 2013 19:04:49 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id eg20so2686881lab.27 for ; Wed, 22 May 2013 19:04: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=u7pUK676CuSvCHA/G6CAh4WM63Tzi7Y3ZzMNfaYIQiU=; b=lP2rXlFqZxTXLkOvZt2BlDggENoioErEBMld0Xpc+3ljK6GZ/6nO8slAsB2Ak73VTh +M2IKUOTN2P2gbDw/1HdQhvapNeQV5xMRY7k/UTLJM7nuo7kzehthYTQGJIlSZAe1mY0 yWJ/iXvH2VJydmIrCnjPuRdX8GnIc2Gr8VUWg97gVSW+iP4dKdzcbb/CXrdV/EDhLXNr G94htGceMoAcASjcwuNJhjwnbRhf3VY+PsT+RFp6PZnYCjdGunMyjjw/moj5LQxVcLX1 tOei//pcUHCIn4x7KplCpqw1yIoJo8l8GhEiBIQnwuqboogEf/HGzQXMa6XFQ9x1vVUO /Ajg== MIME-Version: 1.0 X-Received: by 10.112.73.135 with SMTP id l7mr5371250lbv.42.1369274681606; Wed, 22 May 2013 19:04:41 -0700 (PDT) Received: by 10.112.200.169 with HTTP; Wed, 22 May 2013 19:04:41 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151A8ACB34@WSMSG3153V.srv.dir.telstra.com> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <255B9BB34FB7D647A506DC292726F6E1151A8ACB34@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 22 May 2013 22:04:41 -0400 Message-ID: From: Phillip Hallam-Baker To: "Manger, James H" Content-Type: multipart/alternative; boundary=14dae93d8eacff4bfb04dd591a20 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) -- support streaming X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 02:04:57 -0000 --14dae93d8eacff4bfb04dd591a20 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 22, 2013 at 9:49 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > CBOR [draft-bormann-cbor] looks great. > > The only big problem I see is that sizes have to be known upfront. You > need to know how many bytes, array elements, or map pairs you have BEFORE > you start encoding them. This really hinders streaming content. JSON does > not have this limitation so CBOR should not introduce it. Removing this > limitation would better meet objective 5: "be applicable to both > constrained nodes and high-volume applications". > > This should not be hard to solve, nor to implement. > For instance define initial bytes for "Array", "Map", "Byte array in > parts", and "End". An array is the items between "Array" and "End". A map > is an even number of items between "Map" and "End". There would be no need > for the 64 initial bytes assigned to known-size versions of arrays and maps. > > The 32 initial bytes for known-length byte arrays would remain. The "Byte > array in parts" initial byte would be an additional option. Between "Byte > array in parts" and "End" can be any number of known-length byte array > items. > That is the reason that DER encoding is such a major pain. Only DER makes it even harder as the internal sizes are indeterminate... It has to be possible to serialize and deserialize without any additional state or pre-computation other than maintaining the position in the tree walk. Having to know the number of objects in a list would make transcoding from JSON to binary form a real pig. It would be necessary to buffer objects before you can push out the first byte. This is the type of issue that is critical for me for an on the wire format. Being able to index into specific content is the sort of thing I might care about in a storage format. I might care about things like byte alignment as well. Or maybe not. -- Website: http://hallambaker.com/ --14dae93d8eacff4bfb04dd591a20 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 22, 2013 at 9:49 PM, Manger, James H <James.H.Manger@team.telstra.com> wrote:
CBOR [draft-borma= nn-cbor] looks great.

The only big problem I see is that sizes have to be known upfront. You need= to know how many bytes, array elements, or map pairs you have BEFORE you s= tart encoding them. This really hinders streaming content. JSON does not ha= ve this limitation so CBOR should not introduce it. Removing this limitatio= n would better meet objective 5: "be applicable to both constrained no= des and high-volume applications".

This should not be hard to solve, nor to implement.
For instance define initial bytes for "Array", "Map", &= quot;Byte array in parts", and "End". An array is the items = between "Array" and "End". A map is an even number of i= tems between "Map" and "End". There would be no need fo= r the 64 initial bytes assigned to known-size versions of arrays and maps.<= br>
The 32 initial bytes for known-length byte arrays would remain. The "B= yte array in parts" initial byte would be an additional option. Betwee= n "Byte array in parts" and "End" can be any number of = known-length byte array items.

That is the reason that DER encoding= is such a major pain. Only DER makes it even harder as the internal sizes = are indeterminate...

It has to be poss= ible to serialize and deserialize without any additional state or pre-compu= tation other than maintaining the position in the tree walk.=A0

Having to know the number of objects in a l= ist would make transcoding from JSON to binary form a real pig. It would be= necessary to buffer objects before you can push out the first byte.


This is the type of issue that is = critical for me for an on the wire format. Being able to index into specifi= c content is the sort of thing I might care about in a storage format. I mi= ght care about things like byte alignment as well. Or maybe not.

--
Website: ht= tp://hallambaker.com/
--14dae93d8eacff4bfb04dd591a20-- From nico@cryptonector.com Wed May 22 22:27: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 7FED821F9608 for ; Wed, 22 May 2013 22:27:36 -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=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxVG-7W4v-xo for ; Wed, 22 May 2013 22:27:31 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 2A74321F9601 for ; Wed, 22 May 2013 22:27:30 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id AD477438079 for ; Wed, 22 May 2013 22:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ASGgZxOcNQoiGuHjc92z Wp8APAM=; b=FldD8yqhp8eILpB/ZW7IHp8spMgXUvmeejTwCYzcMgXOVVdALzU7 /bhFiFkO5euZ5xaGfaiRBrePitFOiJu1CVZTGPc2xn/+8wICxPLbE1AIiGsiJjIO zRv/7dTkKaMb98Am24bZJeon6MIUZoM42EraTy6BJpw0l7yYfmtRCHE= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 53D4543806C for ; Wed, 22 May 2013 22:27:29 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id k13so1773993wgh.17 for ; Wed, 22 May 2013 22:27:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SeB1igs/rpb4FksxE2xhXfXt2+aqzIFaClrRuHwJpKM=; b=id7rOsQiW6P2Lmka15TF8MPygYnzaBxS//saxQSnu2L5vW2w26vuTcg2y81z6ZSknt pl2yNBj3yfhRaMf+rtSpcszAloUjj0LMFg53gDm8SaYF+PLGdKcaRwUAa9FziCCWwqeu XAHue8+rmQWtCjcIkNoWUoJj/Fo7DRUQ1sfAx0cOWhUPNYd84+0mTrqjioPtlkqvL0gE CZ8fLtynzzLQTEH309moKly704HzYJXhQMZrQxmUl8IrNrtdgcqHltgxROF+JQ5fkXz+ ZrgyaDoQj9+vET6BbIiljifEhPpnV3Vwbd7PWw05Y/RtELcmoPSEvscvB3SJiYb19FMl YBWQ== MIME-Version: 1.0 X-Received: by 10.180.189.68 with SMTP id gg4mr20751828wic.27.1369286847896; Wed, 22 May 2013 22:27:27 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Wed, 22 May 2013 22:27:27 -0700 (PDT) In-Reply-To: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> Date: Thu, 23 May 2013 00:27:27 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 05:27:36 -0000 Thoughts: - if we're going to have an RFC on JSON, might as well have one on some binary encoding of JSON - yet another encoding. yay. - this encoding does suffice for encoding JSON - this encoding can go beyond JSON -- this is good, but a strict JSON-equivalent subset should be specified - yeah, multiple ways of encoding a given value suck; in particular, for the JSON-equivalent subset, there should be only doubles, no floats, no integers - might as well have a type for "octet string" -- no base64 encoding please Nico -- From paulej@packetizer.com Wed May 22 23:47: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 CFF2211E8155 for ; Wed, 22 May 2013 23: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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2beNnA4WuZK for ; Wed, 22 May 2013 23:47:17 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 39F4121F96D2 for ; Wed, 22 May 2013 23:47:17 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r4N6lFV5008071 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 May 2013 02:47:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1369291635; bh=wQr3HZ4fsuvb51C0BxVUimLpAsnT5ex4HUyQVhxMyYI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=isUefg7KTcc9R7cdyyiRZhTJrDkqt8G4o/XemkZ4HpHjV4AfoF3Gk31+SGLTosh7g RC8080eRrBE4J7rPzD1O7Xf+K9mimPYFTEoJYzlgvDfaF1Mo6pE2+859ee6VfsHErS HvUkee8IA0eXCBgXHkQWGqq4ZmIkT4+S9QzQxbdA= From: "Paul E. Jones" To: "'Phillip Hallam-Baker'" , "'Paul Hoffman'" References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> In-Reply-To: Date: Thu, 23 May 2013 02:47:18 -0400 Message-ID: <002201ce5781$5ee92b20$1cbb8160$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0023_01CE575F.D7D89C90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK0gG+l38l//+1OzBi59iKBnwt7hwFzkLZUAoEBjIMBloxR9pcZpZdg Content-Language: en-us Cc: 'IETF Apps Discuss' Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 06:47:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0023_01CE575F.D7D89C90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit There are actually several XML binary encodings defined today. But I assume the one to which you refer is the one in the W3C called Efficient XML Interchange (EXI). I looked into that and compared the various compression results against a vanilla compression algorithm (namely, zlib). I recorded the results here: http://www.packetizer.com/xml/papers/xml_compression_results.pdf Basically, using EXI would reduce the size of messages and the more the encoder knew about the schema, the better it would do... for small messages. What was interesting is that the results I got rather consistently showed that zlib would outperform most other binary encodings for messages of about 1K or larger. However, l don't really want an encoding that requires the encoder to be aware of a specific schema. It might change tomorrow or next year. Zlib worked well since much of the data being compressed was, of course, text. And text compresses pretty well. It just has a fairly large footprint that is visible with smaller messages. The "no schema" variant of EXI did pretty well on small messages, so I think if COBR can achieve compression at a comparable rate or better, that would be great. Now, it was mentioned elsewhere in the thread (and I'll admit I've not read the draft) that streaming might be an issue. Steaming is not an issue with EXI (at least not with the "no schema" variant), as new tags are encoded into the binary output as they are first seen. ASN.1 PER did an really good job at compressing data. Some of the ASN.1 syntax can be a bit hairy, but the encoding was small. And it worked well since the data it was encoding was binary data, too. With most of the newer protocols, binary optimization is a challenge because the protocols use so much text (media types, URLs, etc.) So, if COBR will exist mainly to compress text data, it will not compress too well. I assume it is being introduced to produce a tight wire encoding of (largely) binary data. Paul From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Phillip Hallam-Baker Sent: Wednesday, May 22, 2013 12:14 PM To: Paul Hoffman Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) Meh... I think we can all agree that *A* binary format would be useful and that two dozen are not useful. The whole problem is how to convince people to use one particular scheme rather than the alternatives. ASN.1 has a decent binary encoding. The problem is that it also has some terrible ones and the ASN.1 schema language was designed by a committee. Text encodings do have problems. Floating Point values do not round trip from IEEE floating point representations without special handling so the format causes a loss in precision that can cause real trouble in scientific work. And nobody likes base64 encoding binary values. I would like to have available a BER like encoding for JSON. But this proposal seems to be something rather different. There is also the XML binary encoding effort that took place. They had a competition and everything. And at the end the only real use for the work was that it shut up the constant carping from people complaining that Web Services in XML were verbose. On Wed, May 22, 2013 at 12:00 PM, Paul Hoffman wrote: On May 22, 2013, at 8:47 AM, James M Snell wrote: > At first read it looks interesting, and can definitely see that a lot > of thought was put into the design. There have, however, been a number > of previous attempts at alternative compact binary representations (or > at least discussions) that did not seem to really go anywhere. We did ours differently than others: we started with an ordered set of design goals and stuck to them. That means that our early arguments about changes / bikeshedcolors had something we could compare against, and it make coming up with a solution much more tractable. > What is > the current implementation status of this? Are there implementations > available or any existing plans to use this new format in a specific > app or spec? Both Carsten and I did versions (in Ruby and Python) to make sure the spec made sense and the examples worked. At least one other member of this list has apparently done a version in JavaScript. > I'm largely just curious about the context and motivation > behind this... There are many contexts. It might be useful in CORE and other constrained-environment work. It might be useful for the next protocols that need a compact binary representation and the WG doesn't want to fight over the specific features. If the design goals fit your needs (and we actually met them...), then it's useful to have it be widely available. --Paul Hoffman _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss -- Website: http://hallambaker.com/ ------=_NextPart_000_0023_01CE575F.D7D89C90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There are actually several XML binary encodings defined today.  = But I assume the one to which you refer is the one in the W3C called = Efficient XML Interchange (EXI).  I looked into that and compared = the various compression results against a vanilla compression algorithm = (namely, zlib).  I recorded the results = here:

http://www.packetizer.com/xml/papers/xml_compression_results.pdf

 

Basically, using EXI would reduce the size of messages and the more = the encoder knew about the schema, the better it would do... for small = messages.  What was interesting is that the results I got rather = consistently showed that zlib would outperform most other binary = encodings for messages of about 1K or larger.  However, l = don’t really want an encoding that requires the encoder to be = aware of a specific schema.  It might change tomorrow or next = year.

 

Zlib worked well since much of the data being compressed was, of = course, text.  And text compresses pretty well.  It just has a = fairly large footprint that is visible with smaller = messages.

 

The “no schema” variant of EXI did pretty well on small = messages, so I think if COBR can achieve compression at a comparable = rate or better, that would be great.  Now, it was mentioned = elsewhere in the thread (and I’ll admit I’ve not read the = draft) that streaming might be an issue.  Steaming is not an issue = with EXI (at least not with the “no schema” variant), as new = tags are encoded into the binary output as they are first = seen.

 

ASN.1 PER did an really good job at compressing data.  Some of = the ASN.1 syntax can be a bit hairy, but the encoding was small.  = And it worked well since the data it was encoding was binary data, = too.  With most of the newer protocols, binary optimization is a = challenge because the protocols use so much text (media types, URLs, = etc.)  So, if COBR will exist mainly to compress text data, it will = not compress too well.  I assume it is being introduced to produce = a tight wire encoding of (largely) binary data.

 

Paul

 

From:= = apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Phillip Hallam-Baker
Sent: Wednesday, May = 22, 2013 12:14 PM
To: Paul Hoffman
Cc: IETF Apps = Discuss
Subject: Re: [apps-discuss] Concise Binary Object = Representation (CBOR)

 

Meh...

 

I = think we can all agree that *A* binary format would be useful and that = two dozen are not useful. The whole problem is how to convince people to = use one particular scheme rather than the = alternatives.

 

ASN.1 has a decent binary encoding. The problem is = that it also has some terrible ones and the ASN.1 schema language was = designed by a committee.

 

Text encodings do have problems. Floating Point values = do not round trip from IEEE floating point representations without = special handling so the format causes a loss in precision that can cause = real trouble in scientific work. And nobody likes base64 encoding binary = values.

 

 

I = would like to have available a BER like encoding for JSON. But this = proposal seems to be something rather = different.

 

There is also the XML binary encoding effort that took = place. They had a competition and everything. And at the end the only = real use for the work was that it shut up the constant carping from = people complaining that Web Services in XML were = verbose.

 

 

On Wed, May 22, 2013 at 12:00 PM, Paul Hoffman <paul.hoffman@vpnc.org> = wrote:

On May 22, 2013, at 8:47 AM, James M = Snell <jasnell@gmail.com> = wrote:

> At first read it looks interesting, and can = definitely see that a lot
> of thought was put into the design. = There have, however, been a number
> of previous attempts at = alternative compact binary representations (or
> at least = discussions) that did not seem to really go = anywhere.

We did ours = differently than others: we started with an ordered set of design goals = and stuck to them. That means that our early arguments about changes / = bikeshedcolors had something we could compare against, and it make = coming up with a solution much more tractable.


> What = is
> the current implementation status of this? Are there = implementations
> available or any existing plans to use this new = format in a specific
> app or spec?

Both Carsten and I did versions (in Ruby and Python) = to make sure the spec made sense and the examples worked. At least one = other member of this list has apparently done a version in = JavaScript.


> I'm largely just curious about = the context and motivation
> behind this...

There are many contexts. It might be useful in CORE = and other constrained-environment work. It might be useful for the next = protocols that need a compact binary representation and the WG doesn't = want to fight over the specific features. If the design goals fit your = needs (and we actually met them...), then it's useful to have it be = widely available.


--Paul = Hoffman
_______________________________________________
apps-discus= s mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= o:p>



 

-- =
Website: http://hallambaker.com/

------=_NextPart_000_0023_01CE575F.D7D89C90-- From cabo@tzi.org Thu May 23 00:40: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 7032121F8CA0 for ; Thu, 23 May 2013 00:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.21 X-Spam-Level: X-Spam-Status: No, score=-106.21 tagged_above=-999 required=5 tests=[AWL=0.039, 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 lS5Qw7XmwQjV for ; Thu, 23 May 2013 00:39:56 -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 15A4921F8C98 for ; Thu, 23 May 2013 00:39:55 -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 r4N7dioD001920; Thu, 23 May 2013 09:39:44 +0200 (CEST) Received: from [192.168.217.105] (p54891D40.dip0.t-ipconnect.de [84.137.29.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4EA343B16; Thu, 23 May 2013 09:39:44 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Thu, 23 May 2013 09:15:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <142483A4-2E80-43F1-B3BE-B5B01650BB8F@tzi.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> To: Nico Williams X-Mailer: Apple Mail (2.1503) Cc: Paul Hoffman , apps-discuss@ietf.org Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 07:40:02 -0000 On May 23, 2013, at 07:27, Nico Williams wrote: > - yeah, multiple ways of encoding a given value suck; in particular, > for the JSON-equivalent subset, there should be only doubles, no > floats, no integers This is about like saying there should only ever be 64-bit integers (or = 128-bit, while we are at it). The serializer can choose one of multiple representations (or, if it is = expedient, it can stick with one). Like with different size of integers, there is little effort in a = deserializer to support different sizes of floats. > - might as well have a type for "octet string" -- no base64 encoding = please Yes, we are just not using the liturgical name "octet string" :-) Gr=FC=DFe, Carsten From cabo@tzi.org Thu May 23 00:50: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 598BD21F96DD for ; Thu, 23 May 2013 00:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.212 X-Spam-Level: X-Spam-Status: No, score=-106.212 tagged_above=-999 required=5 tests=[AWL=0.037, 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 3-wLYZDsIJ7c for ; Thu, 23 May 2013 00:50:46 -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 21AAB21F96F5 for ; Thu, 23 May 2013 00:50:45 -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 r4N7ocfr023005; Thu, 23 May 2013 09:50:38 +0200 (CEST) Received: from [192.168.217.105] (p54891D40.dip0.t-ipconnect.de [84.137.29.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 656EC3B29; Thu, 23 May 2013 09:50:38 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151A8ACB34@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 23 May 2013 09:50:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <964FB690-4904-4BC4-99A8-AAB57B21FB52@tzi.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <255B9BB34FB7D647A506DC292726F6E1151A8ACB34@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1503) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) -- support streaming X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 07:50:52 -0000 On May 23, 2013, at 03:49, "Manger, James H" = wrote: > sizes have to be known upfront Indeed. The old "counted vs. delimited" debate. JSON is delimited because is HAS TO BE -- counted is a non-starter for = text formats (as amply demonstrated by FORTAN Hollerith data). CBOR is counted because that is the best fit for a binary format. Fast deserializers really benefit from knowing counts upfront (and that = also helps with constrained deserializers). (The number of things they will have to create, e.g., the number of data = items; not the byte size of their representation -- counting bytes here = was a mistake RFC 731 and ASN.1 BER shared and that creates much pain in = BER.) With a byte-oriented encoding, counting also happens to require fewer = bytes than delimiting for small counts. So if the serializer is in a position to provide count information in = time, we should use it. CBOR supports streaming by having self-delimited data items -- you can = send many of these in sequence for a stream (as in, say, an XMPP-like = protocol). So streaming *of* data items is not a problem with CBOR. Now let's look at "streaming" *within* a data item. The actual need for this is a fringe case, but one that is worth looking = at. The only significant use case I know is a state-limited (on-the-fly) = converter from a delimited format (such as JSON) to CBOR. (Unfortunately, that is not just a use case in gateways; using CBOR as a = plug-in replacement for JSON may saddle one with an API that makes the = CBOR serializer such a converter.) Putting together an aquarium when being handed fish sticks. Anything that addresses this specific use case needs to be a hybrid. (Purely delimited is possible for binary, but tends to be more taxing on = the deserializer; it also often requires additional work at the = serializer to enable data transparency.) I tried to avoid designing a hybrid. Counted is the way things have been moving to in much of CS for the last = 10, 15 years. As you say, delimiters (push/pop, or maybe some form of continuation = scheme) can be easily hacked into CBOR, the only victim being its = architecture. Should we? Gr=FC=DFe, Carsten From vesely@tana.it Thu May 23 00:51: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 2C84521F9702 for ; Thu, 23 May 2013 00:51:03 -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, 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 79eNFzct6vxp for ; Thu, 23 May 2013 00:50:58 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 01A3621F9700 for ; Thu, 23 May 2013 00:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1369295455; bh=SYoyCxFg5tSC89qdvcaKEs5hdUnbUS2LvtkpPqTPZGg=; l=1440; h=Date:From:To:References:In-Reply-To; b=TvOtgTClvF0GaXCUI0Wf1jsw9voGCXNER7T5jPbtuHmTq6NzMnlS/tR5zD3SaQr3d mjQsqHqNwtPELTRO9c7lrX6JKbATNkTtr6Qvdgx3EVR/Qxi4E7lwBeAiz80/haD3y2 MIrY6QWAtAyS8qRZHmMKxxY+jeO+BOx4mQAb/Ngk= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.156] (pcale.tana [172.25.197.156]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Thu, 23 May 2013 09:50:55 +0200 id 00000000005DC039.00000000519DCA5F.0000143F Message-ID: <519DCA5F.30207@tana.it> Date: Thu, 23 May 2013 09:50:55 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20130513045342.14228.40090.idtracker@ietfa.amsl.com> <1675160.H9MT8MA6B2@scott-latitude-e6320> In-Reply-To: <1675160.H9MT8MA6B2@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 07:51:03 -0000 On Sat 18/May/2013 00:22:47 +0200 Scott Kitterman wrote: > > I believe the change from: > > authres-header = "Authentication-Results:" [CFWS] authserv-id > [ CFWS version ] Note that in bis-04 it is: authres-header = "Authentication-Results:" [CFWS] authserv-id [ [CFWS] authres-version ] The optional space allows: Authentication-Results: example.org1; none > to: > > authres-header = "Authentication-Results:" [CFWS] authserv-id > [ [CFWS] "/" [CFWS] authres-version ] > > is an incompatible change and if you really want to make it, you should bump > the version number. I checked and with authres, your example is mis-parsed. > > Authentication-Results: example.org/1; none > > In this example, the authserv-id is "example.org", but authres, using the RFC > 5451 ABNF parses this and determines the authserv-id is "example.org/1" > > If you want to make this change, I think it needs to be version 2 because an > existing version 1 parser can't parse the header field anymore. STD 68 specifies how to define a formal syntax, but that doesn't have to be a first-order syntax, so its parseability can depend on the semantics. The ABNF rules defined in the I-D don't lend themselves to automated generation of lexical analyzers: In order to parse the identifier and understand which ADMD it refers to, it is necessary to adhere to some naming convention, which is purposely left unspecified. From cabo@tzi.org Thu May 23 01:11: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 AC78711E8155 for ; Thu, 23 May 2013 01:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.213 X-Spam-Level: X-Spam-Status: No, score=-106.213 tagged_above=-999 required=5 tests=[AWL=0.036, 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 zykFp0P8gst8 for ; Thu, 23 May 2013 01:11:43 -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 67F7A21F9709 for ; Thu, 23 May 2013 01:11:43 -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 r4N8BcWH001010; Thu, 23 May 2013 10:11:38 +0200 (CEST) Received: from [192.168.217.105] (p54891D40.dip0.t-ipconnect.de [84.137.29.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id ACD813B58; Thu, 23 May 2013 10:11:37 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <002201ce5781$5ee92b20$1cbb8160$@packetizer.com> Date: Thu, 23 May 2013 10:11:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <25F67EB3-B70E-4A19-AD08-7B4ADC6ECC63@tzi.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <002201ce5781$5ee92b20$1cbb8160$@packetizer.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.1503) Cc: 'Paul Hoffman' , 'IETF Apps Discuss' Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 08:11:49 -0000 On May 23, 2013, at 08:47, "Paul E. Jones" = wrote: > compression CBOR is not about compression. It is about compact encoding, achieving reasonable message sizes with = reasonable effort. In many cases, compression is premature optimization. CBOR only avoids premature pessimization. Compressed (e.g., via deflate/gzip) JSON works very well for a large = number of applications. CBOR is about generating and consuming data streams with much less = complexity. Complexity -- eats CPU and thus energy, -- creates interoperability problems and other bugs, -- may not fit into constrained systems. But these considerations may simply not be the overriding ones for many = applications, and LZ77 can achieve efficiencies that a simple serializer = can't, so absolutely go ahead and deflate JSON for these. EXI is not a bad serializer. =20 There are a number of weird design decisions in there that I would = prefer to avoid. More importantly, EXI is based on an XML data model; the JSON model is = what I'm interested in. EXI also has to be servant to two masters: schema-informed and = schema-less. Finally, it has a medium (but not severe) case of design by committee. All this creates a bit more complexity than I like, but, again, it is = not nearly as bad as it could be. Gr=FC=DFe, Carsten From fanf2@hermes.cam.ac.uk Thu May 23 02:17: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 BDBA121F95EB for ; Thu, 23 May 2013 02:17: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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kA4NALXAKgOa for ; Thu, 23 May 2013 02:17:09 -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 173BF21F95EA for ; Thu, 23 May 2013 02:17:08 -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]:43093) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1UfRdz-0001SE-6S (Exim 4.80_167-5a66dd3) (return-path ); Thu, 23 May 2013 10:17:07 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1UfRdy-0000X8-Un (Exim 4.72) (return-path ); Thu, 23 May 2013 10:17:06 +0100 Date: Thu, 23 May 2013 10:17:06 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Paul Hoffman In-Reply-To: Message-ID: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <04905D53-5022-4741-A2B6-9EE4593A4C65@tzi.org> <8F16DE1E-3D5F-4C38-937E-14EAF66D3D94@vpnc.org> <519D0893.8010602@bbiw.net> 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 Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 09:17:11 -0000 Paul Hoffman wrote: > On May 22, 2013, at 11:43 AM, James M Snell wrote: > > > Best bet: define the syntax, provide a couple of great open source > > implementations, let people know about them.. then time will tell > > whether it'll be worthwhile to standardize. > > Fully disagree. As a great recent counter-example, see what is happening > in the MessagePack world which is following exactly what you suggest, > and there is a lot of bad feelings. Do you have a link we can look at to find out more? 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 Peter.Rushforth@NRCan-RNCan.gc.ca Thu May 23 05:23: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 34AA021F8CB4 for ; Thu, 23 May 2013 05:23:46 -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 qMrz+jokccsZ for ; Thu, 23 May 2013 05:23:41 -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 BA07621F9104 for ; Thu, 23 May 2013 05:23:40 -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, 23 May 2013 08:23:38 -0400 Received: from S-BSC-MBX1.nrn.nrcan.gc.ca ([169.254.1.214]) by S-BSC-CAS2.nrn.nrcan.gc.ca ([fe80::48d4:f168:78ba:d4e8%19]) with mapi id 14.02.0342.003; Thu, 23 May 2013 08:23:38 -0400 From: "Rushforth, Peter" To: Ned Freed Thread-Topic: [apps-discuss] Getting 3023bis, a.k.a. draft-ietf-appsawg-xml-mediatypes, moving Thread-Index: AQHORq37wnKMK4dMa02l80ivIFgl7ZkSzZzA Date: Thu, 23 May 2013 12:23:37 +0000 Message-ID: <1CD55F04538DEA4F85F3ADF7745464AF249FFE9E@S-BSC-MBX1.nrn.nrcan.gc.ca> References: <1CD55F04538DEA4F85F3ADF7745464AF249DAECA@S-BSC-MBX1.nrn.nrcan.gc.ca> <01OT4UQWYK5M000054@mauve.mrochek.com> In-Reply-To: <01OT4UQWYK5M000054@mauve.mrochek.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Getting 3023bis, a.k.a. draft-ietf-appsawg-xml-mediatypes, moving X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 12:23:46 -0000 Ned, Leaving registration considerations aside for a moment, if I want to=20 create a media type which is more specific than application/xml=20 for my application, is it better to use=20 application/xml;profile=3D"urn:my.app"=20 or=20 application/vnd.my.app+xml ? Because this library https://code.google.com/p/mimeparse/, available in 8 programming languages, supports parsing the former as XML, but not the latter. I haven't really looked at other libraries, but I think I may have landed on that one because the implementation of MIME in java did=20 not manage negotiation concerns (I don't remember). Also, browsers (that I have used anyway) will parse the former as XML,=20 but not the latter. Same for html, which is potentially quite useful, IMHO= . Are there libraries available which support parsing application/vnd.my.app+= xml as XML? I don't think there's anything wrong with this notation, since it = does identify the media type semantics, but it doesn't give me fallback behaviou= r at least in any running code I've seen. Thanks Peter Rushforth > -----Original Message----- > From: Ned Freed [mailto:ned.freed@mrochek.com]=20 > Sent: May 1, 2013 16:45 > To: ht@inf.ed.ac.uk > Cc: Rushforth, Peter; apps-discuss@ietf.org > Subject: Re: [apps-discuss] Getting 3023bis, a.k.a.=20 > draft-ietf-appsawg-xml-mediatypes, moving >=20 > > Rushforth, Peter writes: >=20 > > > Section 8. > > > > > > Suggest to remove the recommendation to register media types with=20 > > > +xml suffix. Suggest to add recommendation for a 'profile'=20 > > > parameter for application/xml, as is being done for atom :=20 > > > http://tools.ietf.org/html/draft-wilde-atom-profile-01 >=20 > > I have to say I'm not inclined to go that way. There is a _very_=20 > > large installed base, particularly of application/xhtml+xml and=20 > > application/rdf+xml. There are around 100 registered=20 > > application/xxx+xml media types registered _outside_ the vnd...=20 > > sub-space, and another 200 or so there. We recently spent a lot of=20 > > time getting both the general approach to registering structured=20 > > suffixes and their uses [1] and using that approach to clean up /=20 > > document existing practices [2], including the +xml case. >=20 > > Introducing an alternative profile-based approach at this=20 > point would=20 > > just confuse things, IMO. >=20 > I strongly agree. We're currently seeing a large number of=20 > registrations coming in and momentum seems to be building.=20 > The absolute last thing we should be doing is making changes=20 > that break that. We have seen the effect of such changes in=20 > the past; it was not good. >=20 > Ned > = From James.H.Manger@team.telstra.com Thu May 23 06:15: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 94DCD21F9128 for ; Thu, 23 May 2013 06:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.469 X-Spam-Level: X-Spam-Status: No, score=-0.469 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qY+gEpV2yw6V for ; Thu, 23 May 2013 06:15:27 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id E13B821F90CC for ; Thu, 23 May 2013 06:15:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,728,1363093200"; d="scan'208";a="130555113" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 23 May 2013 23:15:23 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7083"; a="138919679" Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipccni.tcif.telstra.com.au with ESMTP; 23 May 2013 23:15:23 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Thu, 23 May 2013 23:15:23 +1000 From: "Manger, James H" To: Carsten Bormann Date: Thu, 23 May 2013 23:15:21 +1000 Thread-Topic: [apps-discuss] Concise Binary Object Representation (CBOR) -- support streaming Thread-Index: Ac5XikCVrFpuveo0R0GP57EvNz4omAAH/Z1g Message-ID: <255B9BB34FB7D647A506DC292726F6E1151A8AD4C1@WSMSG3153V.srv.dir.telstra.com> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <255B9BB34FB7D647A506DC292726F6E1151A8ACB34@WSMSG3153V.srv.dir.telstra.com> <964FB690-4904-4BC4-99A8-AAB57B21FB52@tzi.org> In-Reply-To: <964FB690-4904-4BC4-99A8-AAB57B21FB52@tzi.org> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) -- support streaming X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 13:15:33 -0000 PiA+IHNpemVzIGhhdmUgdG8gYmUga25vd24gdXBmcm9udA0KPiANCj4gSW5kZWVkLiAgVGhlIG9s ZCAiY291bnRlZCB2cy4gZGVsaW1pdGVkIiBkZWJhdGUuDQo+IA0KPiBKU09OIGlzIGRlbGltaXRl ZCBiZWNhdXNlIGlzIEhBUyBUTyBCRSAtLSBjb3VudGVkIGlzIGEgbm9uLXN0YXJ0ZXIgZm9yDQo+ IHRleHQgZm9ybWF0cyAoYXMgYW1wbHkgZGVtb25zdHJhdGVkIGJ5IEZPUlRBTiBIb2xsZXJpdGgg ZGF0YSkuDQo+IA0KPiBDQk9SIGlzIGNvdW50ZWQgYmVjYXVzZSB0aGF0IGlzIHRoZSBiZXN0IGZp dCBmb3IgYSBiaW5hcnkgZm9ybWF0Lg0KPiBGYXN0IGRlc2VyaWFsaXplcnMgcmVhbGx5IGJlbmVm aXQgZnJvbSBrbm93aW5nIGNvdW50cyB1cGZyb250IChhbmQgdGhhdA0KPiBhbHNvIGhlbHBzIHdp dGggY29uc3RyYWluZWQgZGVzZXJpYWxpemVycykuDQoNCklzIHRoaXMgYmVjYXVzZSB0aGUgZGVz ZXJpYWxpemVyIGNhbiBhbGxvY2F0ZSBleGFjdGx5IHRoZSByaWdodCBtZW1vcnkgZm9yIGFuIGFy cmF5IChvZiBwb2ludGVycyB0byBlbGVtZW50cyksIGluc3RlYWQgb2YgaGF2aW5nIHRvIGd1ZXNz IHRoZW4gcmVzaXplIGFzIG5lY2Vzc2FyeT8NCg0KPiAoVGhlIG51bWJlciBvZiB0aGluZ3MgdGhl eSB3aWxsIGhhdmUgdG8gY3JlYXRlLCBlLmcuLCB0aGUgbnVtYmVyIG9mDQo+IGRhdGEgaXRlbXM7 IG5vdCB0aGUgYnl0ZSBzaXplIG9mIHRoZWlyIHJlcHJlc2VudGF0aW9uIC0tIGNvdW50aW5nIGJ5 dGVzDQo+IGhlcmUgd2FzIGEgbWlzdGFrZSBSRkMgNzMxIGFuZCBBU04uMSBCRVIgc2hhcmVkIGFu ZCB0aGF0IGNyZWF0ZXMgbXVjaA0KPiBwYWluIGluIEJFUi4pDQoNCk9rLiBJIGNhbiBzZWUgdGhh biBhbiBpdGVtIGNvdW50IGNhbiBhdm9pZCAqc29tZSogb2YgdGhlIGRpZmZpY3VsdGllcyB3aXRo IGEgY291bnQgb2YgZW5jb2RlZCBieXRlcy4NCg0KPiBXaXRoIGEgYnl0ZS1vcmllbnRlZCBlbmNv ZGluZywgY291bnRpbmcgYWxzbyBoYXBwZW5zIHRvIHJlcXVpcmUgZmV3ZXINCj4gYnl0ZXMgdGhh biBkZWxpbWl0aW5nIGZvciBzbWFsbCBjb3VudHMuDQoNClNhdmUgMSBieXRlIHBlciBtYXAgYW5k IGFycmF5IHRoYXQgaGFzIGZld2VyIHRoYW4gMjggaXRlbXMuIFNvdW5kcyBuaWNlLCBidXQgbm90 IHRoYXQgY29tcGVsbGluZy4NCg0KPiBTbyBpZiB0aGUgc2VyaWFsaXplciBpcyBpbiBhIHBvc2l0 aW9uIHRvIHByb3ZpZGUgY291bnQgaW5mb3JtYXRpb24gaW4NCj4gdGltZSwgd2Ugc2hvdWxkIHVz ZSBpdC4NCj4gDQo+IENCT1Igc3VwcG9ydHMgc3RyZWFtaW5nIGJ5IGhhdmluZyBzZWxmLWRlbGlt aXRlZCBkYXRhIGl0ZW1zIC0tIHlvdSBjYW4NCj4gc2VuZCBtYW55IG9mIHRoZXNlIGluIHNlcXVl bmNlIGZvciBhIHN0cmVhbSAoYXMgaW4sIHNheSwgYW4gWE1QUC1saWtlDQo+IHByb3RvY29sKS4N Cj4gDQo+IFNvIHN0cmVhbWluZyAqb2YqIGRhdGEgaXRlbXMgaXMgbm90IGEgcHJvYmxlbSB3aXRo IENCT1IuDQoNClN1cHBvcnRpbmcgc3RyZWFtaW5nIC0tIGJ1dCBvbmx5IGF0IHRoZSB0b3AgbGF5 ZXIgb2YgYSBwcm90b2NvbCAtLSBkb2Vzbid0IHNvdW5kIGdvb2QuIElmIGl0IGlzIHVzZWZ1bCBh dCBhICJ0b3AtbGF5ZXIiIHN1cmVseSBpdCBpcyB1c2VmdWwgYXQgb3RoZXIgbGF5ZXJzIGFzIHdl bGwuIFByb3RvY29scyBhcmUgb2Z0ZW4gZW1iZWRkZWQgaW4gb3RoZXIgcHJvdG9jb2xzLiBPbmNl IHlvdSBoYXZlIHNvbWV0aGluZyB0aGF0IHJlbGllcyBvbiBhIHN0cmVhbSAqb2YqIGRhdGEgaXRl bXMsIGFuZCB5b3Ugd2FudCB0byBlbWJlZCBpdCBpbiBhbm90aGVyIGxheWVyIHlvdSBoYXZlIHRv IHN0b3AgdXNpbmcgQ0JPUi4gVGhhdCdzIGJhZC4NCg0KPiBOb3cgbGV0J3MgbG9vayBhdCAic3Ry ZWFtaW5nIiAqd2l0aGluKiBhIGRhdGEgaXRlbS4NCj4gDQo+IFRoZSBhY3R1YWwgbmVlZCBmb3Ig dGhpcyBpcyBhIGZyaW5nZSBjYXNlLCBidXQgb25lIHRoYXQgaXMgd29ydGgNCj4gbG9va2luZyBh dC4NCj4gVGhlIG9ubHkgc2lnbmlmaWNhbnQgdXNlIGNhc2UgSSBrbm93IGlzIGEgc3RhdGUtbGlt aXRlZCAob24tdGhlLWZseSkNCj4gY29udmVydGVyIGZyb20gYSBkZWxpbWl0ZWQgZm9ybWF0IChz dWNoIGFzIEpTT04pIHRvIENCT1IuDQo+IChVbmZvcnR1bmF0ZWx5LCB0aGF0IGlzIG5vdCBqdXN0 IGEgdXNlIGNhc2UgaW4gZ2F0ZXdheXM7IHVzaW5nIENCT1IgYXMNCj4gYSBwbHVnLWluIHJlcGxh Y2VtZW50IGZvciBKU09OIG1heSBzYWRkbGUgb25lIHdpdGggYW4gQVBJIHRoYXQgbWFrZXMNCj4g dGhlIENCT1Igc2VyaWFsaXplciBzdWNoIGEgY29udmVydGVyLikNCj4gUHV0dGluZyB0b2dldGhl ciBhbiBhcXVhcml1bSB3aGVuIGJlaW5nIGhhbmRlZCBmaXNoIHN0aWNrcy4NCg0KVGhpcyBkb2Vz bid0IGZlZWwgbGlrZSBhICJmcmluZ2UgY2FzZSIuIENvbnZlcnRpbmcgZnJvbSBKU09OIGlzIG9u ZSBvZiB0aGUgbGlzdGVkIG9iamVjdGl2ZXMgKCM2KS4gVGhlIGRyYWZ0IGhhcyBhIHNlY3Rpb24g b24gaG93IHRvIGRvIGl0Lg0KDQpJdCBpcyBnZW5lcmFsbHkgb25seSBmb3IgcG90ZW50aWFsbHkg bGFyZ2UgdGhpbmdzIHRoYXQgeW91IG5lZWQgdG8gYm90aGVyIHdpdGggc29tZXRoaW5nIGxpa2Ug Q0JPUiBmb3IgZWZmaWNpZW5jeSwgaW5zdGVhZCBvZiBzdGF5aW5nIHdpdGggSlNPTi4gSXQgaXMg dGhlc2UgbGFyZ2UgdGhpbmdzIHRoYXQgYXJlIGdvaW5nIHRvIGhhdmUgdW5rbm93biBzaXplcyBh dCB0aGUgc3RhcnQuDQoNClBsZW50eSBvZiBsYW5ndWFnZXMgcGFzcyBhcm91bmQgaXRlcmF0b3Jz LCBpbnN0ZWFkIG9mIGFycmF5cyBvciBtYXBzLCBiZWNhdXNlIHRoZXkgYXJlIGEgdXNlZnVsIGFi c3RyYWN0aW9uIHRoYXQgY292ZXJzIG1vcmUgc2l0dWF0aW9ucyAtLSBidXQgdGhleSBkb24ndCBn aXZlIHlvdSBhIHNpemUgdXAgZnJvbnQuDQoNCj4gQW55dGhpbmcgdGhhdCBhZGRyZXNzZXMgdGhp cyBzcGVjaWZpYyB1c2UgY2FzZSBuZWVkcyB0byBiZSBhIGh5YnJpZC4NCj4gKFB1cmVseSBkZWxp bWl0ZWQgaXMgcG9zc2libGUgZm9yIGJpbmFyeSwgYnV0IHRlbmRzIHRvIGJlIG1vcmUgdGF4aW5n DQo+IG9uIHRoZSBkZXNlcmlhbGl6ZXI7IGl0IGFsc28gb2Z0ZW4gcmVxdWlyZXMgYWRkaXRpb25h bCB3b3JrIGF0IHRoZQ0KPiBzZXJpYWxpemVyIHRvIGVuYWJsZSBkYXRhIHRyYW5zcGFyZW5jeS4p DQoNCldoYXQgZG9lcyAiZW5hYmxlIGRhdGEgdHJhbnNwYXJlbmN5IiBtZWFuPw0KDQo+IEkgdHJp ZWQgdG8gYXZvaWQgZGVzaWduaW5nIGEgaHlicmlkLg0KPiBDb3VudGVkIGlzIHRoZSB3YXkgdGhp bmdzIGhhdmUgYmVlbiBtb3ZpbmcgdG8gaW4gbXVjaCBvZiBDUyBmb3IgdGhlDQo+IGxhc3QgMTAs IDE1IHllYXJzLg0KPiANCj4gQXMgeW91IHNheSwgZGVsaW1pdGVycyAocHVzaC9wb3AsIG9yIG1h eWJlIHNvbWUgZm9ybSBvZiBjb250aW51YXRpb24NCj4gc2NoZW1lKSBjYW4gYmUgZWFzaWx5IGhh Y2tlZCBpbnRvIENCT1IsIHRoZSBvbmx5IHZpY3RpbSBiZWluZyBpdHMNCj4gYXJjaGl0ZWN0dXJl Lg0KPiBTaG91bGQgd2U/DQoNClllcy4NCg0KSSdtIG5vdCBjb252aW5jZWQgdGhhdCBzaXR1YXRp b25zIHdoZXJlIHlvdSBkb24ndCBrbm93IHRoZSBzaXplIG9mIGEgYnl0ZSBhcnJheSwgdGV4dCwg YXJyYXksIG9yIG1hcCB1cCBmcm9udCBhcmUgc28gcmFyZSB0aGF0IENCT1IgY2FuIGlnbm9yZSB0 aGVtLg0KDQpJIGFtIG5vdCBmYW1pbGlhciBlbm91Z2ggd2l0aCBzcXVlZXppbmcgcGVyZm9ybWFu Y2UgZnJvbSBhIGRlc2VyaWFsaXplciB0byBqdWRnZSB3aGV0aGVyIGEgaHlicmlkIGlzIHdvcnRo IHRoZSBjb21wbGV4aXR5IGNvc3Qgb3ZlciBqdXN0IGRlbGltaXRlcnMgZm9yIG1hcHMgJiBhcnJh eXMuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From dcrocker@bbiw.net Thu May 23 06:53: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 F017021F89BA for ; Thu, 23 May 2013 06:53:23 -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 Lbrzwg7kQErk for ; Thu, 23 May 2013 06:53:19 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7CD21F90EB for ; Thu, 23 May 2013 06:52:54 -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 r4NDqos8018832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 May 2013 06:52:54 -0700 Message-ID: <519E1F2F.9060008@bbiw.net> Date: Thu, 23 May 2013 06:52:47 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Carsten Bormann References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <002201ce5781$5ee92b20$1cbb8160$@packetizer.com> <25F67EB3-B70E-4A19-AD08-7B4ADC6ECC63@tzi.org> In-Reply-To: <25F67EB3-B70E-4A19-AD08-7B4ADC6ECC63@tzi.org> 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.67]); Thu, 23 May 2013 06:52:54 -0700 (PDT) Cc: 'Paul Hoffman' , 'IETF Apps Discuss' Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 13:53:24 -0000 On 5/23/2013 1:11 AM, Carsten Bormann wrote: > More importantly, EXI is based on an XML data model; the JSON model is what I'm interested in. Beginner's question: How does/should the differences in data model affect the choices in encoding scheme? I'm looking for the (relatively) short answer. Tnx. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dave@cridland.net Thu May 23 07:21: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 A831D21E804D for ; Thu, 23 May 2013 07:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hu2XVLE6WsoW for ; Thu, 23 May 2013 07:21:36 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id CBF2621E804C for ; Thu, 23 May 2013 07:21:35 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id xn12so722599obc.34 for ; Thu, 23 May 2013 07:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hYEm7IuJlwftsIvqv8Ducm/X/AECCUQtMBUX+Xw4ulk=; b=EHtJOwO72fEVgrNpfEKZm0s92dV45kB1sHTllJ8mEy85x2lqpCp7B7s5uUDxneUK0I 9Zi933FakmM1rDEy4Q/ElT8fbIZeoe4G6r0VaCCVt0iLrZ/tuZSB0etk8TpeGi7oXKFX qD6vUbaSw2wmZd8qbihtbv0jFwZx/EqypUF30= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=hYEm7IuJlwftsIvqv8Ducm/X/AECCUQtMBUX+Xw4ulk=; b=GfhHJhBRjrT5FRnoznt/O7VyJ1qGajB9OVFmQQ62Oy0dBISj4MU6vWlaCWITTZI1TS OihN7lQpIBZfPE/RNR4S8hiwJScmS7TcsGgSdLWu/UZKBxbA70iUDJm3wjvI3SvCzlTY z1OoeLYbIS0l2B85df7+NWYNlr0OYaWHgJq97/NCU1nZO7qgUbCgJ5XZwt//XPpmrmiR BAmLTep7Qkx22S5qrePZ/ge45XAZ59O+Q3cMbuUTjJO4xl4DzQ/j2cEaTdoBYHWSkpHz qcJHJpKRLs1fidfx+Pk4Ig0UU8LlIEhhE41wLz5knEpwyd5AuoxM7EKCqNl+r2YLCXq+ H9zA== MIME-Version: 1.0 X-Received: by 10.60.85.74 with SMTP id f10mr8560331oez.32.1369318895153; Thu, 23 May 2013 07:21:35 -0700 (PDT) Received: by 10.60.62.146 with HTTP; Thu, 23 May 2013 07:21:34 -0700 (PDT) In-Reply-To: <519E1F2F.9060008@bbiw.net> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <002201ce5781$5ee92b20$1cbb8160$@packetizer.com> <25F67EB3-B70E-4A19-AD08-7B4ADC6ECC63@tzi.org> <519E1F2F.9060008@bbiw.net> Date: Thu, 23 May 2013 15:21:34 +0100 Message-ID: From: Dave Cridland To: Dave Crocker Content-Type: multipart/alternative; boundary=089e0111b71c54d87404dd6366b7 X-Gm-Message-State: ALoCoQmBBkHkglSNvC58uFVIMhfJ1bHMmv6Px6OtfGHDYXeLwrJN9OSKzAmfVT1Ef1P4BoOxKUdd Cc: Paul Hoffman , IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 14:21:36 -0000 --089e0111b71c54d87404dd6366b7 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 23, 2013 at 2:52 PM, Dave Crocker wrote: > How does/should the differences in data model affect the choices in > encoding scheme? I'm looking for the (relatively) short answer. > EXI makes certain assumptions about the data model in order to achieve the most efficient encoding. EXI specifically can take into account not only the generalized DOM, but also the schema of the XML encoded. Any encoding scheme with domain knowledge embedded in it, as it were, can get more efficient encoding (since it's effectively encoding that domain information implicitly in its mere use rather than transmitting the model explicitly). Of course, it doesn't mean that any domain-specific encoding will automatically be better than a generalized one... Another example, and one that you may be familiar with, is the way that IMAP set syntax uses its knowledge of the data domain to make very compact representations, which can be seen clearly in the difference between a standard RFC 3501 SEARCH response and the RFC 4731 ESEARCH response, which (can) carry the same information in different representations - the latter using considerably fewer octets on the wire in all but degenerate cases. In any case, this means that given a particular data model, selecting a suitably apt encoding scheme will yield better results. (This all said, you could pick an XML representation of the JSON model, and then EXI encode that one, since the DOM is a superset of the JSON model - I think. Not saying that's even remotely sensible...) Dave. --089e0111b71c54d87404dd6366b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 23, 2013 at 2:52 PM, Dave Crocker <dcrocker@b= biw.net> wrote:
=A0 =A0 =A0How does/should the differences in data model affect t= he choices in encoding scheme? =A0I'm looking for the (relatively) shor= t answer.

EXI makes cer= tain assumptions about the data model in order to achieve the most efficien= t encoding. EXI specifically can take into account not only the generalized= DOM, but also the schema of the XML encoded. Any encoding scheme with doma= in knowledge embedded in it, as it were, can get more efficient encoding (s= ince it's effectively encoding that domain information implicitly in it= s mere use rather than transmitting the model explicitly). Of course, it do= esn't mean that any domain-specific encoding will automatically be bett= er than a generalized one...

Another example, and one that you may be familiar with, is the way that IM= AP set syntax uses its knowledge of the data domain to make very compact re= presentations, which can be seen clearly in the difference between a standa= rd RFC 3501 SEARCH response and the RFC 4731 ESEARCH response, which (can) = carry the same information in different representations - the latter using = considerably fewer octets on the wire in all but degenerate cases.

In any case, this means that given a particular data model, selecting a su= itably apt encoding scheme will yield better results.

(This all said, you could pick a= n XML representation of the JSON model, and then EXI encode that one, since= the DOM is a superset of the JSON model - I think. Not saying that's e= ven remotely sensible...)

Dave.
--089e0111b71c54d87404dd6366b7-- From dcrocker@bbiw.net Thu May 23 07:49:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52BE21F9318 for ; Thu, 23 May 2013 07:49:56 -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 4uFbzmMInD1I for ; Thu, 23 May 2013 07:49:50 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id D333321F9234 for ; Thu, 23 May 2013 07:49:50 -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 r4NEnkvD020217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 May 2013 07:49:49 -0700 Message-ID: <519E2C86.4080707@bbiw.net> Date: Thu, 23 May 2013 07:49:42 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Dave Cridland References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <002201ce5781$5ee92b20$1cbb8160$@packetizer.com> <25F67EB3-B70E-4A19-AD08-7B4ADC6ECC63@tzi.org> <519E1F2F.9060008@bbiw.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.67]); Thu, 23 May 2013 07:49:49 -0700 (PDT) Cc: Paul Hoffman , IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 14:49:56 -0000 On 5/23/2013 7:21 AM, Dave Cridland wrote: > EXI makes certain assumptions about the data model in order to achieve > the most efficient encoding. EXI specifically can take into account not > only the generalized DOM, but also the schema of the XML encoded. What does that mean in terms of specifics? For example, what kind of assumptions? The above is such a general statement, there's no way to know what it translates into, in terms of encoding style choices. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dave@cridland.net Thu May 23 08:00: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 443D221F8FB3 for ; Thu, 23 May 2013 08:00:01 -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 4c04S7Gt2w-F for ; Thu, 23 May 2013 07:59:57 -0700 (PDT) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id F322E21F8F83 for ; Thu, 23 May 2013 07:59:56 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id h2so4532066oag.19 for ; Thu, 23 May 2013 07:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/AbDQEiV7X8915kX4xzVEfneW2V0qVbCvgU0Ve3HCqU=; b=HfbjjYvdT0egYCAsWySX90fwdbxjhO7bZUElOu9Jg7Z0aKKrsIQbF14Qb8i1Icit+G L0WC1D5s4KTMA2JbwlZs+CEleOIRy2/WzHm1UMXyFSXBEYVEomuhaYwuw7Uh+/f4lVqm +GnRN4i6YKnY9hfUpsW/qlKHvA98u7CS6E9hE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=/AbDQEiV7X8915kX4xzVEfneW2V0qVbCvgU0Ve3HCqU=; b=Tht0VbP761yGaq4LjubZLsg0uLybOPKhADsNrzyAINPIqxtyb/QJIh4rGUY/ScsM+L 3Pm479DvZCrgF3vHTFFLdgN2Tv+vCU4n6K0Fz6zl7v5Zf/9s+GXU1kU3rZjOJK/wb8OB lrIaGQQjA2Sn6MbNGXXgWcnAKQCwm07SzD4q/uIw4Td0GliU9kqLy2JIjvsva6YgIch0 HDN+Op+JNSIZI46QhI38vnZn+coAycnBlHXjBhjI6/tlNCjncaYaAHiBT9SaqpkPfhx4 Xt83NBAYMeFB4CTlnFLliwiI2NOWrEmIfqT+63ZMwmbkg7EI1hy0cee0v2Ztrq3h41TD UeKA== MIME-Version: 1.0 X-Received: by 10.182.237.6 with SMTP id uy6mr6979179obc.31.1369321196368; Thu, 23 May 2013 07:59:56 -0700 (PDT) Received: by 10.60.62.146 with HTTP; Thu, 23 May 2013 07:59:56 -0700 (PDT) In-Reply-To: <519E2C86.4080707@bbiw.net> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <002201ce5781$5ee92b20$1cbb8160$@packetizer.com> <25F67EB3-B70E-4A19-AD08-7B4ADC6ECC63@tzi.org> <519E1F2F.9060008@bbiw.net> <519E2C86.4080707@bbiw.net> Date: Thu, 23 May 2013 15:59:56 +0100 Message-ID: From: Dave Cridland To: Dave Crocker Content-Type: multipart/alternative; boundary=e89a8ff24eaf7e98a304dd63ef5f X-Gm-Message-State: ALoCoQkl8YSGgK90V/Hx9OETeMS8MEeiG+iTyXLnuxcHorNFaCC8DkWA5CB24e8NxwQSmBa1tPgn Cc: Paul Hoffman , IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 15:00:01 -0000 --e89a8ff24eaf7e98a304dd63ef5f Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 23, 2013 at 3:49 PM, Dave Crocker wrote: > On 5/23/2013 7:21 AM, Dave Cridland wrote: > >> EXI makes certain assumptions about the data model in order to achieve >> the most efficient encoding. EXI specifically can take into account not >> only the generalized DOM, but also the schema of the XML encoded. >> > > What does that mean in terms of specifics? For example, what kind of > assumptions? The above is such a general statement, there's no way to know > what it translates into, in terms of encoding style choices. > > To switch example, JSON has no encoding for sets, or binary data, because neither exist in the model it's encoding. Because they don't exist, there's no need to encode them - if you wanted to encode them (because your source model differs from that assumed), you'd need to do something else (like base64 encoding). This naturally reduces efficiency. CBOR clearly has a superset of this model - so it does have binary data, but still does not have sets, for instance. Dave. --e89a8ff24eaf7e98a304dd63ef5f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 23, 2013 at 3:49 PM, Dave Crocker <dcrocker@b= biw.net> wrote:
On 5/23/2013 7:21 AM, Dave= Cridland wrote:
EXI makes certain assumptions about the data model in order to achieve
the most efficient encoding. EXI specifically can take into account not
only the generalized DOM, but also the schema of the XML encoded.

What does that mean in terms of specifics? =A0For example, what kind of ass= umptions? =A0The above is such a general statement, there's no way to k= now what it translates into, in terms of encoding style choices.


To= switch example, JSON has no encoding for sets, or binary data, because nei= ther exist in the model it's encoding. Because they don't exist, th= ere's no need to encode them - if you wanted to encode them (because yo= ur source model differs from that assumed), you'd need to do something = else (like base64 encoding). This naturally reduces efficiency.

CBOR clearly has a superset of this model -= so it does have binary data, but still does not have sets, for instance.

Dave.
--e89a8ff24eaf7e98a304dd63ef5f-- From dcrocker@bbiw.net Thu May 23 08:01: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 CDF0121F962E for ; Thu, 23 May 2013 08:01:14 -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 ndHXGwOCEM7B for ; Thu, 23 May 2013 08:01:09 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6754321F972E for ; Thu, 23 May 2013 08:01:08 -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 r4NF14v2020806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 May 2013 08:01:07 -0700 Message-ID: <519E2F2C.3030809@bbiw.net> Date: Thu, 23 May 2013 08:01:00 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Dave Cridland References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <3638B63C-0E75-4E99-BF65-28F83DB856A6@vpnc.org> <002201ce5781$5ee92b20$1cbb8160$@packetizer.com> <25F67EB3-B70E-4A19-AD08-7B4ADC6ECC63@tzi.org> <519E1F2F.9060008@bbiw.net> <519E2C86.4080707@bbiw.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.67]); Thu, 23 May 2013 08:01:07 -0700 (PDT) Cc: Paul Hoffman , IETF Apps Discuss Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 15:01:14 -0000 On 5/23/2013 7:59 AM, Dave Cridland wrote: > To switch example, JSON has no encoding for sets, or binary data, > because neither exist in the model it's encoding. Because they don't > exist, there's no need to encode them - if you wanted to encode them > (because your source model differs from that assumed), you'd need to do > something else (like base64 encoding). This naturally reduces efficiency. that's pretty specific. thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ietf-secretariat-reply@ietf.org Thu May 23 08:05: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 6F5FF21F8FE8 for ; Thu, 23 May 2013 08:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, 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 pgrkyqd0A8Rt for ; Thu, 23 May 2013 08:05:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB7E21F9260 for ; Thu, 23 May 2013 08:05:49 -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.50 Message-ID: <20130523150549.7924.51142.idtracker@ietfa.amsl.com> Date: Thu, 23 May 2013 08:05:49 -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: Thu, 23 May 2013 15:05:50 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-rfc5451bis", set state to active from review, accepting new milestone. Changed milestone "Publication requested for draft-ietf-appsawg-sieve-duplicate", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/appsawg/charter/ From nico@cryptonector.com Thu May 23 08:35: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 EA18C21F96C9 for ; Thu, 23 May 2013 08:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=0.200, 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 p6uilspb+d8D for ; Thu, 23 May 2013 08:35:35 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 2166A21F96C1 for ; Thu, 23 May 2013 08:35:35 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id E76BF9405E for ; Thu, 23 May 2013 08:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=QLnmfFYnXmEh8PwYiRFj UngU+rM=; b=fc1CB+M/wJma1S+tjUVI3dCojTqFsIfTHx531i+63lwyoe246m4I o1/lgXHrKnsIb+NQGR2y9G5w8tmzzl8PCFiqmE17cpAq7ywOo0JojMTYt3PbGJUX B8MuYgS7SWdMD7kDZjvXKI+tTtose0BsHj0d1lVhiVDvgtKKQ1lFBQA= Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 96E299405C for ; Thu, 23 May 2013 08:35:34 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id hn14so4651564wib.2 for ; Thu, 23 May 2013 08:35:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=86IXu4QU4uvJE0QRCZl5KZ6g2/xZrQD6gCzdttdif/4=; b=Fi/RiJhJlR3ZIyiOg7YuiHRu7wn1s15DKUep238PU2Da+BhrpPlR1NQazGrQLJCODF I8vPiqIYdxIFeVMusjrQt3FrDbo9z+A0+UIDf4ejuhBtQ0slt0HyHrvliQ6HDR81txp8 KI3ZvYo0O/O6Lhm1Jwi1olPUCTAvIhkB0F9VKwWtaW9CT0PaC3frX/xKX4kqxLQf1EzA 4CmvmlPxeOAntF4mRDA94FhZYNHORqum9LpPcfRPAw+PxE1ih1cp4Sy+i9MYE1y53aJJ ue3gABnnmu56hpWuWDx0DvkZHay8eTo0mXD5DzvuR1Or3j4D/Y1Wy8HBuXOYrZgM8qic q7LA== MIME-Version: 1.0 X-Received: by 10.180.72.195 with SMTP id f3mr44006549wiv.32.1369323333391; Thu, 23 May 2013 08:35:33 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Thu, 23 May 2013 08:35:33 -0700 (PDT) In-Reply-To: <142483A4-2E80-43F1-B3BE-B5B01650BB8F@tzi.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <142483A4-2E80-43F1-B3BE-B5B01650BB8F@tzi.org> Date: Thu, 23 May 2013 10:35:33 -0500 Message-ID: From: Nico Williams To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , apps-discuss@ietf.org Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 15:35:41 -0000 On Thu, May 23, 2013 at 2:15 AM, Carsten Bormann wrote: > On May 23, 2013, at 07:27, Nico Williams wrote: > >> - yeah, multiple ways of encoding a given value suck; in particular, >> for the JSON-equivalent subset, there should be only doubles, no >> floats, no integers > > This is about like saying there should only ever be 64-bit integers (or 128-bit, while we are at it). ECMAScript specifically only allows that. That's where the restriction comes from. Many a ECMAScript and/or JSON implementation use NaN coding, which is probably why this restriction is there in the first place (though that's just a guess; I'm sure there's a list archive somewhere with a lengthy discussion I could check; I don't care). > The serializer can choose one of multiple representations (or, if it is expedient, it can stick with one). > Like with different size of integers, there is little effort in a deserializer to support different sizes of floats. I wouldn't insist on having a canonical representation. I would prefer to have a canonical representation if possible. The biggest issue would be the need to sort object keys, which I'd not insist on (but it's nice to have the option to, and many a JSON encoder provides this). >> - might as well have a type for "octet string" -- no base64 encoding please > > Yes, we are just not using the liturgical name "octet string" :-) Yes it's there and I missed it? Nico -- From hallam@gmail.com Thu May 23 08:41: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 A521B21F9787 for ; Thu, 23 May 2013 08:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=-0.536, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 Hliu5tbc5L1p for ; Thu, 23 May 2013 08:41:34 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by ietfa.amsl.com (Postfix) with ESMTP id 562B621F9780 for ; Thu, 23 May 2013 08:41:30 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id u10so3589470lbi.33 for ; Thu, 23 May 2013 08:41:26 -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=EadpByTrLQM7ElCt62nwkhPbggwcUQnKjUxGHMhNmXw=; b=a3boFOy+ySO9DVHZIZ5KkIAM+X2UF5dvwLKSxZ31iGklA1qel1fegIGGQdlr6J8IHL snQPG8A+3bNIbCO48+znY/gIwwnsnVi4xaKcWFbbz1ep8ulL7ROmLko+keB22bjIIHzm nXrafQaINHYf0bJKtm2kzoDuGERh0X7SfIQbDFfeODyHsOfmkOwaBpHQSJQgEERV3asA S+GvlU+IvkZeXkItBGPK79GMoL0dhfUa2CqigOu6gSt7r3UaVG82EvV5TZYsTKoA5qel uhcopyj2N3yiAbju1ibnl0xSNnoztLI6gW+X0Ug9MeVCGXgvOi6bX3J/klmr2v18Q1xV 3hkQ== MIME-Version: 1.0 X-Received: by 10.112.89.8 with SMTP id bk8mr703362lbb.73.1369323686703; Thu, 23 May 2013 08:41:26 -0700 (PDT) Received: by 10.112.200.169 with HTTP; Thu, 23 May 2013 08:41:26 -0700 (PDT) In-Reply-To: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> Date: Thu, 23 May 2013 11:41:26 -0400 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c37a0aedb72204dd6483fa Cc: Paul Hoffman , General discussion of application-layer protocols Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 15:41:38 -0000 --001a11c37a0aedb72204dd6483fa Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 23, 2013 at 1:27 AM, Nico Williams wrote: > Thoughts: > > - if we're going to have an RFC on JSON, might as well have one on > some binary encoding of JSON > > - yet another encoding. yay. > > - this encoding does suffice for encoding JSON > > - this encoding can go beyond JSON -- this is good, but a strict > JSON-equivalent subset should be specified > > - yeah, multiple ways of encoding a given value suck; in particular, > for the JSON-equivalent subset, there should be only doubles, no > floats, no integers > > - might as well have a type for "octet string" -- no base64 encoding > please > +1 to Nico. The only types I have found a need for in my JSON schema are: Integer Float String (UTF8) DateTime (As RFC 3339 format string) Binary (as base64 encoded string) List (X) - JSON List I do think that it is worth calling out DateTime and Binary for special treatment because they both appear very frequently in code. I have not found a need for any other special format. For Integers, I only use double for representation but that is a design choice that does not affect bits on the wire. For a binary format I would prefer that like JSON, the wire format be neutral with respect to the code representation. Since most of the proposals are of the form where and we only have 7 fundamental types it is quite easy to make the type octet combine the type and length information. So if the integer fits in 2 bytes then just use 2 bytes and mark the length in the type octet, the number 256 could be represented as: X2 01 00 I would use twos compliment for all values and so a 64 bit unsigned integer could potentially have 9 octets but that would be a rare event. A side benefit to this approach is that big numbers are easily supported. Representing floats is a lot harder than the specs I have written seem to understand. In particular the main reason I would want a binary format for JSON is that it is NOT possible to round trip floats from decimal format to binary without special care. So the main reason for using a binary JSON is going to be not introducing the errors, possibly cumulative errors that round tripping from decimal to binary introduces. So we do need to have 32 bit and 64 it floats. -- Website: http://hallambaker.com/ --001a11c37a0aedb72204dd6483fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 23, 2013 at 1:27 AM, Nico Williams <nic= o@cryptonector.com> wrote:
Thoughts:

=A0- if we're going to have an RFC on JSON, might as well have one on some binary encoding of JSON

=A0- yet another encoding. =A0yay.

=A0- this encoding does suffice for encoding JSON

=A0- this encoding can go beyond JSON -- this is good, but a strict
JSON-equivalent subset should be specified

=A0- yeah, multiple ways of encoding a given value suck; in particular,
for the JSON-equivalent subset, there should be only doubles, no
floats, no integers

=A0- might as well have a type for "octet string" -- no base64 en= coding please

+1 to Nico.

The only types I have found a need for in my = JSON schema are:

Integer
Float=A0
String (UTF8)
DateTime =A0 (As RFC 3339 format string= )
Binary (as base64 encoded string)
List (X= ) =A0- JSON List

I do think that it is worth calling out Dat= eTime and Binary for special treatment because they both appear very freque= ntly in code. I have not found a need for any other special format.


For Integers, I only u= se double for representation but that is a design choice that does not affe= ct bits on the wire. For a binary format I would prefer that like JSON, the= wire format be neutral with respect to the code representation.

Since most of the proposals are of the form= <type> <data> where <type> and we only have 7 fundamenta= l types it is quite easy to make the type octet combine the type and length= information. So if the integer fits in 2 bytes then just use 2 bytes and m= ark the length in the type octet, the number 256 could be represented as:

X2 01 00

I would use twos compliment for all values and so a 64 bit unsigned inte= ger could potentially have 9 octets but that would be a rare event.

A side benefit to this approach is that big= numbers are easily supported.


Representing floats is a lot harder than the specs I have wri= tten seem to understand. In particular the main reason I would want a binar= y format for JSON is that it is NOT possible to round trip floats from deci= mal format to binary without special care.

So the main reason for using a binary JSON = is going to be not introducing the errors, possibly cumulative errors that = round tripping from decimal to binary introduces.

So we do need to have 32 bit and 64 it floats.

--
Website: http://hallambak= er.com/
--001a11c37a0aedb72204dd6483fa-- From johnl@iecc.com Thu May 23 08:41:52 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1714021F9780 for ; Thu, 23 May 2013 08:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.047 X-Spam-Level: X-Spam-Status: No, score=-111.047 tagged_above=-999 required=5 tests=[AWL=0.152, 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 cR-p26TKYZFu for ; Thu, 23 May 2013 08:41:48 -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 34B1121F978C for ; Thu, 23 May 2013 08:41:46 -0700 (PDT) Received: (qmail 39874 invoked from network); 23 May 2013 15:41:46 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 23 May 2013 15:41:46 -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=519e38ba.xn--30v786c.k1305; i=johnl@user.iecc.com; bh=DgG04UWGjfCx/G5GlmmcnyI/edteo8TYdvII7h+PHKM=; b=Pje+VC3kIWtjQ48KkQqaNQfDUKzC74GT2o+NKrE4qB3p4zW4bsIYpF0N/JHF/zfsT/qGYJyEOdWY/CNYGNz2W8QCilcYaVzPy0i8jJ7dh9iOwp4Fu9/8NzJhp7mhUcgnQh4vZH/uHUuIMKWVHiSI5tskGw6i36S795OZMQkh3bE= 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=519e38ba.xn--30v786c.k1305; olt=johnl@user.iecc.com; bh=DgG04UWGjfCx/G5GlmmcnyI/edteo8TYdvII7h+PHKM=; b=nEb2CkJ8ZCxSK3z72rNkyeWrLfc1p7b6eeIZ6v/cjRcUNsJ3Ope4sTkvTfODnHdK6TqsEyzvPWIgwBQKzqJv1KznAJYSbXeqVtJnEICQ5+ERdPtUEDy3c9wM0obElxyOzTPp5lR9nffGJrPRzjlVb0WhdXNS+UMhhllluYQN4qU= Date: 23 May 2013 15:41:24 -0000 Message-ID: <20130523154124.25978.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <519DCA5F.30207@tana.it> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: vesely@tana.it Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 15:41:52 -0000 >> I believe the change from: >> >> authres-header = "Authentication-Results:" [CFWS] authserv-id >> [ CFWS version ] > >Note that in bis-04 it is: > > authres-header = "Authentication-Results:" [CFWS] authserv-id > [ [CFWS] authres-version ] You're right. Adding the brackets is clearly a mistake since it makes it impossible to tell where the authserv-id ends and the authres-version starts. R's, John From dcrocker@bbiw.net Thu May 23 08:48: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 ED0C621F97E9 for ; Thu, 23 May 2013 08:48:00 -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 ssEURBxGVHIf for ; Thu, 23 May 2013 08:47:56 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C48B421F97FC for ; Thu, 23 May 2013 08:47:55 -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 r4NFlq0T021913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 May 2013 08:47:55 -0700 Message-ID: <519E3A24.3090502@bbiw.net> Date: Thu, 23 May 2013 08:47:48 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: John Levine References: <20130523154124.25978.qmail@joyce.lan> In-Reply-To: <20130523154124.25978.qmail@joyce.lan> 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.67]); Thu, 23 May 2013 08:47:55 -0700 (PDT) Cc: apps-discuss@ietf.org, vesely@tana.it Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 15:48:01 -0000 On 5/23/2013 8:41 AM, John Levine wrote: >>> I believe the change from: >>> >>> authres-header = "Authentication-Results:" [CFWS] authserv-id >>> [ CFWS version ] >> >> Note that in bis-04 it is: >> >> authres-header = "Authentication-Results:" [CFWS] authserv-id >> [ [CFWS] authres-version ] > > You're right. Adding the brackets is clearly a mistake since it makes > it impossible to tell where the authserv-id ends and the > authres-version starts. huh? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nico@cryptonector.com Thu May 23 09:14: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 15FF221F9588 for ; Thu, 23 May 2013 09:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[AWL=0.180, 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 4qTcxRegLqsp for ; Thu, 23 May 2013 09:13:49 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id D6D3E21F9742 for ; Thu, 23 May 2013 09:13:49 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 4B8F23B8069 for ; Thu, 23 May 2013 09:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=O9xSwCSEJkzoCZ2/iu6h eXzeR3s=; b=mcd379FJTydb/BdEt+QeYVsvv7BtiVoTPxFUaBYmrE2+hc3kPsss zN0vc37Pu7iDa1cIRATVFh5bctcHV3nMyp2EHYmTnJkNOXRDz8buJrccnmntYBgt NQhXkxUwkVo1BvQU2e0CWkTeJsKYaVjembFyCnSIBrgRGowdw++9tko= Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id E7D473B8062 for ; Thu, 23 May 2013 09:13:48 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hn14so5122924wib.0 for ; Thu, 23 May 2013 09:13:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XmTQ5UdM2FgcDs7ImDmlCBEDH6UGcfBOTB12oMRPOok=; b=PkU9Zx/yC3YKSfZLwGaWXMrvUPl4Q5srhuhnQoETQnpvy7FCvVm418cFiwqJ0mdPQU pzpaGQs14v4029x2wO1Ra24e8837/jy4b9jrgckySskWeE6Fj7NxP/Z/KihFhw97jfDi BecuGKsb12GZUm/WoDVsBYtYaj1379B2jTZMuE42l0b1mxIi4ILKLfq0Dguj+bDZ3eOU cYPyK450g7SvEYWbFyKpntE9paliGgP7XudQV1Kpw9TX1kNB48kO1ze/PdNpOplQ7mJR +89zUB1Rpv7FuyuNWQrVjBYSVj7FOHUf3WFULttOwaVGqNcD50L9Qe24HH0vUDj91YAJ c00A== MIME-Version: 1.0 X-Received: by 10.180.189.41 with SMTP id gf9mr25845288wic.32.1369325626674; Thu, 23 May 2013 09:13:46 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Thu, 23 May 2013 09:13:46 -0700 (PDT) In-Reply-To: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> Date: Thu, 23 May 2013 11:13:46 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 16:14:00 -0000 Also, I believe this is the fifth binary encoding of JSON proposed thus far. Can we list the ones that have been proposed thus far? Here's a [no-doubt partial] list: - BSON - MsgPack - Smile - UBJSON - CBOR That's just the ones I recall seeing before or which I found in 30 seconds of searching. Some of these are used in actual protocols right now. An analysis of these might be nice. (While you're at that, and considering variable length encodings of things... SQLite4 has some really neat variable length encodings of all its data types, specifically designed to make sorting via memcmp() possible. I'm not sure what relevance that might have here, but it should be of interest to anyone designing variable length encodings of anything.) I do agree that we need a schema-less encoding (which means we can't get as good as PER and friends). We probably don't need a schema-capable encoding for JSON (though that might be nice). We do need schema-aware encodings for some protocols, but we have plenty already, and none are nor need to be JSONish. (I've wanted to define a JSON Encoding Rules for ASN.1, primarily to make debugging apps that use ASN.1-based protocols easier (dump PDUs as ASN.1).) Nico -- From cabo@tzi.org Thu May 23 09:23:27 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D093511E812F for ; Thu, 23 May 2013 09:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.565 X-Spam-Level: X-Spam-Status: No, score=-106.565 tagged_above=-999 required=5 tests=[AWL=-0.316, 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 84CyD8m6G1bC for ; Thu, 23 May 2013 09:23:20 -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 8FF1211E80EC for ; Thu, 23 May 2013 09:23:19 -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 r4NGNDCF026195; Thu, 23 May 2013 18:23:13 +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 48DF83050; Thu, 23 May 2013 18:23:13 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=utf-8 From: Carsten Bormann In-Reply-To: Date: Thu, 23 May 2013 18:23:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <84317001-DB56-4DBE-9D1E-A4E605BC07A0@tzi.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <142483A4-2E80-43F1-B3BE-B5B01650BB8F@tzi.org> To: Nico Williams X-Mailer: Apple Mail (2.1503) Cc: Paul Hoffman , apps-discuss@ietf.org Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 16:23:27 -0000 On May 23, 2013, at 17:35, Nico Williams wrote: > On Thu, May 23, 2013 at 2:15 AM, Carsten Bormann wrote: >> On May 23, 2013, at 07:27, Nico Williams = wrote: >>=20 >>> - yeah, multiple ways of encoding a given value suck; in particular, >>> for the JSON-equivalent subset, there should be only doubles, no >>> floats, no integers >>=20 >> This is about like saying there should only ever be 64-bit integers = (or 128-bit, while we are at it). >=20 > ECMAScript specifically only allows that. That's where the > restriction comes from. JSON =E2=89=A0 JavaScript. =20 JavaScript's numbers are IEEE 754 double precision. That is not at all a property of JSON. =20 (It *is* something you care about if one or two of the peers speaking = JSON actually are written in JavaScript and you are using JavaScript = primitives to operate on the JSON.) > Many a ECMAScript and/or JSON implementation use NaN coding, which is > probably why this restriction is there in the first place (though > that's just a guess; I'm sure there's a list archive somewhere with a > lengthy discussion I could check; I don't care). Now you lost me -- JSON doesn't have NaNs. (Another thing that CBOR has that you can't use in a JSON subset.) >> The serializer can choose one of multiple representations (or, if it = is expedient, it can stick with one). >> Like with different size of integers, there is little effort in a = deserializer to support different sizes of floats. >=20 > I wouldn't insist on having a canonical representation. I would > prefer to have a canonical representation if possible. The biggest > issue would be the need to sort object keys, which I'd not insist on > (but it's nice to have the option to, and many a JSON encoder provides > this). I think Paul is working on c14n for CBOR. As I said, I don't want to go there... (If you think you need c14n, you probably have a bug in your = architecture.) >>> - might as well have a type for "octet string" -- no base64 encoding = please >>=20 >> Yes, we are just not using the liturgical name "octet string" :-) >=20 > Yes it's there and I missed it? Yes, we call them "byte strings" (major type 2). (They are actually the main reason I started work on CBOR.) Gr=C3=BC=C3=9Fe, Carsten From paul.hoffman@vpnc.org Thu May 23 09:28: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 0CC4D21F968F for ; Thu, 23 May 2013 09:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 8uDKNmeYat17 for ; Thu, 23 May 2013 09:28:54 -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 8B02F21F968E for ; Thu, 23 May 2013 09:28:54 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4NGSq9w099531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 May 2013 09:28:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Thu, 23 May 2013 09:28:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> To: Nico Williams X-Mailer: Apple Mail (2.1503) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 16:28:55 -0000 On May 23, 2013, at 9:13 AM, Nico Williams = wrote: > Also, I believe this is the fifth binary encoding of JSON proposed > thus far. =20 A note on terminology: CBOR is not a "binary encoding of JSON". It has a = design goal of supporting all JSON data types for conversion to and from = JSON. That design goal (which we think we have met) is far down the list = of design goals. > Can we list the ones that have been proposed thus far? >=20 > Here's a [no-doubt partial] list: >=20 > - BSON > - MsgPack > - Smile > - UBJSON > - CBOR >=20 > That's just the ones I recall seeing before or which I found in 30 > seconds of searching. >=20 > Some of these are used in actual protocols right now. >=20 > An analysis of these might be nice. As we said yesterday, we will have an appendix of other binary formats, = saying how they do and don't meet the design goals for CBOR. That should = help people decide whether reusing one of the existing formats is more = worthwhile than CBOR. --Paul Hoffman= From cabo@tzi.org Thu May 23 09: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 F409C21F969E for ; Thu, 23 May 2013 09:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.486 X-Spam-Level: X-Spam-Status: No, score=-106.486 tagged_above=-999 required=5 tests=[AWL=-0.237, 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 0RoRW7raMsmO for ; Thu, 23 May 2013 09:40:04 -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 D5F6321F9783 for ; Thu, 23 May 2013 09:38:19 -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 r4NGcA6l022904; Thu, 23 May 2013 18:38:10 +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 ED7783067; Thu, 23 May 2013 18:38:09 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Thu, 23 May 2013 18:38:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> To: Nico Williams X-Mailer: Apple Mail (2.1503) Cc: Paul Hoffman , apps-discuss@ietf.org Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 16:40:20 -0000 On May 23, 2013, at 18:13, Nico Williams wrote: > Also, I believe this is the fifth binary encoding of JSON proposed > thus far. =20 1) CBOR is not a "binary encoding of JSON". (It can be used as one, though.) 2) There are many more proposals in this space, and it is hard to draw a = line. E.g. Google protocol buffers is a prominent example. Bencode is a great one, too. > An analysis of these might be nice. Yes. Find a grad student :-) Of course, I did my own analysis, but I didn't see a need to write it = up. (More specifically, I didn't see a funding agency interested in this = part of reality. But I'm willing to be surprised :-) > (While you're at that, and considering variable length encodings of > things... SQLite4 has some really neat variable length encodings of > all its data types, specifically designed to make sorting via memcmp() > possible. I'm not sure what relevance that might have here, but it > should be of interest to anyone designing variable length encodings of > anything.) If you are looking for a neat variable length encoding of integers = designed to sort well, look no further than Appendix A.4 of = draft-bormann-coap-misc. But CBOR wasn't trying to be neat, it is trying to be practical. > I do agree that we need a schema-less encoding (which means we can't > get as good as PER and friends). We probably don't need a > schema-capable encoding for JSON (though that might be nice). We do > need schema-aware encodings for some protocols, but we have plenty > already, and none are nor need to be JSONish. I think we are in good agreement here. Gr=FC=DFe, Carsten From cabo@tzi.org Thu May 23 10:00: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 E2EF721F9783 for ; Thu, 23 May 2013 10:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.356 X-Spam-Level: X-Spam-Status: No, score=-105.356 tagged_above=-999 required=5 tests=[AWL=-1.272, 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 6WK-mNGmbFWC for ; Thu, 23 May 2013 10:00:25 -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 BD4B821F96E7 for ; Thu, 23 May 2013 09:54:03 -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 r4NGrv5x021482; Thu, 23 May 2013 18:53:57 +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 DC83C3085; Thu, 23 May 2013 18:53:56 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Thu, 23 May 2013 18:53:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1503) Cc: Paul Hoffman , General discussion of application-layer protocols Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 17:00:41 -0000 > The only types I have found a need for in my JSON schema are: >=20 > Integer > Float=20 > String (UTF8) > DateTime (As RFC 3339 format string) > Binary (as base64 encoded string) > List (X) - JSON List CBOR is a pretty good match then (we also have a = map/dictionary/table/JSON object). (There is never a need to base-64 encode anything in CBOR.) > Since most of the proposals are of the form where = and we only have 7 fundamental types it is quite easy to make the type = octet combine the type and length information. So if the integer fits in = 2 bytes then just use 2 bytes and mark the length in the type octet, the = number 256 could be represented as: >=20 > X2 01 00 Yep. (CBOR has a slightly different encoding of the first byte to be able to = encode the number right there if it fits). > I would use twos compliment for all values and so a 64 bit unsigned = integer could potentially have 9 octets but that would be a rare event. CBOR uses two different encoding types for unsigned and negative = numbers. See Figure 2 for an easy way to convert signed integers to = that. > A side benefit to this approach is that big numbers are easily = supported. CBOR also has a representation for big (> 64-bit) numbers (based on the = byte string). > Representing floats is a lot harder than the specs I have written seem = to understand. In particular the main reason I would want a binary = format for JSON is that it is NOT possible to round trip floats from = decimal format to binary without special care. Representing floats is rather easy -- IEEE 754 is well-documented. So = CBOR uses the three main binary floating point formats from that (Half, = Single, Double). If you do need (negative) base-10 exponents, we have a special Decimal = fraction (inspired by YANG and EXI), trying not to use decimal = mantissae. > So the main reason for using a binary JSON is going to be not = introducing the errors, possibly cumulative errors that round tripping = from decimal to binary introduces. That is one good reason (not the main one I'm interested in). > So we do need to have 32 bit and 64 it floats. Strictly, that is not needed, as every 32-bit float can be easily = converted into a 64-bit float. But the inverse (going down from 64 to 32 to 16, and checking whether = that is lossless) is also easy. Gr=FC=DFe, Carsten From barryleiba.mailing.lists@gmail.com Thu May 23 10:04: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 E165E21F9008 for ; Thu, 23 May 2013 10:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.967 X-Spam-Level: X-Spam-Status: No, score=-101.967 tagged_above=-999 required=5 tests=[AWL=0.011, 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 cIZikXIb570q for ; Thu, 23 May 2013 10:04:14 -0700 (PDT) Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1D04F21F90C3 for ; Thu, 23 May 2013 09:56:51 -0700 (PDT) Received: by mail-vb0-f52.google.com with SMTP id p12so1432637vbe.25 for ; Thu, 23 May 2013 09:56:48 -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=oHzafDBCL7gsy+XlTs2rKXyWsIBD+Oqix0u7nOVVbRs=; b=0l1tF46DclxBM9MBp7yTIGXrLWJRWOeqjHR3dRRFmronLwa2/7sVIjSLcTocMwtUTd g/QQ7jpJ8IDBLQE9Jdy6exM0IZgGKjg5o+Cl1HD8MiJnLbkBTL2MYjGaS5xjaNlMrFxp GGrgVfSElVOMIYPu+jtiMqsHbjfgWOUGXWyUw3um/91f0PtHcXH5cSNhIjZ04fwCppKm 04NevAdbjXQm/j56BBwSJPSHKA9nK8Sce9WJfhFvCXtRy1f+N4P+KcuDDBl5AVPgGSJe v0Cao+iuSfeBsbLQPNvr5IulRsOFZmI/1u9Y7aM6VQ8yn4YAqFmRYgJKqzpK6oquFspN n4FQ== MIME-Version: 1.0 X-Received: by 10.221.9.70 with SMTP id ov6mr5927393vcb.72.1369328208405; Thu, 23 May 2013 09:56:48 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.6.233 with HTTP; Thu, 23 May 2013 09:56:48 -0700 (PDT) In-Reply-To: <519E3A24.3090502@bbiw.net> References: <20130523154124.25978.qmail@joyce.lan> <519E3A24.3090502@bbiw.net> Date: Thu, 23 May 2013 12:56:48 -0400 X-Google-Sender-Auth: dSd-chXgtY3uo32BCMK5uwcFxuA Message-ID: From: Barry Leiba To: Dave Crocker Content-Type: text/plain; charset=ISO-8859-1 Cc: John Levine , "apps-discuss@ietf.org" , Alessandro Vesely Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 17:04:25 -0000 On Thu, May 23, 2013 at 11:47 AM, Dave Crocker wrote: > On 5/23/2013 8:41 AM, John Levine wrote: >>>> >>>> I believe the change from: >>>> >>>> authres-header = "Authentication-Results:" [CFWS] authserv-id >>>> [ CFWS version ] >>> >>> >>> Note that in bis-04 it is: >>> >>> authres-header = "Authentication-Results:" [CFWS] authserv-id >>> [ [CFWS] authres-version ] >> >> >> You're right. Adding the brackets is clearly a mistake since it makes >> it impossible to tell where the authserv-id ends and the >> authres-version starts. > > > huh? I think John means that the change makes the second CFWS optional, and that can't be. Barry From ned.freed@mrochek.com Thu May 23 10:07: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 BEA5221F95FD for ; Thu, 23 May 2013 10:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[AWL=-1.298, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, MANGLED_YOUR=2.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 1N-EFIMj68Xq for ; Thu, 23 May 2013 10:06:50 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id E3D3221F95E1 for ; Thu, 23 May 2013 09:59:54 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OTZCZRIQ0G006IJ3@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 23 May 2013 09:54:50 -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 <01OTX2OVE9TS000054@mauve.mrochek.com>; Thu, 23 May 2013 09:54:45 -0700 (PDT) Message-id: <01OTZCZOGPKC000054@mauve.mrochek.com> Date: Thu, 23 May 2013 09:41:03 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 23 May 2013 12:23:37 +0000" <1CD55F04538DEA4F85F3ADF7745464AF249FFE9E@S-BSC-MBX1.nrn.nrcan.gc.ca> References: <1CD55F04538DEA4F85F3ADF7745464AF249DAECA@S-BSC-MBX1.nrn.nrcan.gc.ca> <01OT4UQWYK5M000054@mauve.mrochek.com> <1CD55F04538DEA4F85F3ADF7745464AF249FFE9E@S-BSC-MBX1.nrn.nrcan.gc.ca> To: "Rushforth, Peter" Cc: Ned Freed , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Getting 3023bis, a.k.a. draft-ietf-appsawg-xml-mediatypes, moving X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 17:07:05 -0000 > Ned, > Leaving registration considerations aside for a moment, if I want to > create a media type which is more specific than application/xml > for my application, is it better to use > application/xml;profile="urn:my.app" > or > application/vnd.my.app+xml ? The latter, unquestionably. > Because this library https://code.google.com/p/mimeparse/, available in > 8 programming languages, supports parsing the former as XML, but not the > latter. Sorry, one library demonstates diddley-sqaut. And while it's nice to support default handling of entities as XML, it's hardly a requirement. What is a requirement is the ability to have different handling for different types of entities. And MIME dispatch capabilities are invariably capable of operating on the conent type. This is the case in hundreds if not thousands of different pieces of code. So having a proper type label gives you the ability to process different sorts of entities differently. It's also true that a some of them support dispatching on parameter values. But definitely not all. In fact I'd go so far as to say that most do not. And yes, most don't support default handling of media type suffixes either. But that's hardly surprising given they were properly standardized less than a year ago. > I haven't really looked at other libraries, but I think I may > have landed on that one because the implementation of MIME in java did > not manage negotiation concerns (I don't remember). > Also, browsers (that I have used anyway) will parse the former as XML, > but not the latter. Same for html, which is potentially quite useful, IMHO. Again, the ability to be able to default to parsing XML is a nice to have feature. Nothing more. I'll also note that the rules for content type definitiions are very clear that the type and subtype are what you register as specifying the sort of entity you'r dealing with. As such, absent a willingness to reopen the recently revised rules for how type registration work, which I very much doubt is on the table, your proposal here is a total nonstarter. Ned From fgaliegue@gmail.com Thu May 23 10:12: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 2551921F9128 for ; Thu, 23 May 2013 10:12:10 -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 vLUJjocfxN40 for ; Thu, 23 May 2013 10:11:52 -0700 (PDT) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by ietfa.amsl.com (Postfix) with ESMTP id BB6C321F97DA for ; Thu, 23 May 2013 10:02:53 -0700 (PDT) Received: by mail-ee0-f41.google.com with SMTP id d4so2056464eek.0 for ; Thu, 23 May 2013 10:02:53 -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=vgRQR9klgaZXQz5FIkVd43GY/wQEVM/XLBI3MlxH5QY=; b=dR9AbkUdcOgJ15fRPp6E53MQIlNQsmNUOC19h7fV8dDTjrwOSobrfL3mf3EthoMlNH BSz6zJCb8QciTFO2ohmMyyu6nag4OsKqfAQZGYz3nyLo3Z+UHRkdh6BnDpbV5Pxb9pRS Y90b2Wo9tgdhpdo8tTamrwVN2VSh8AT60u3qh0TT4MJFbBUKW05HMKR/BPUEciE99vt3 e4803YujuaDHTIslIFzGnLUxw4kUvPBLBRUIbEhDCBeQ2khBvqWhi89v8Hw+vYsHFr80 KbyE9HvTk74KGGK2epVj+ltZlUHrqqr3eHXZ48r/iFCbAuVsPSV7K80KbBLaQ0wfLgNL iHPQ== MIME-Version: 1.0 X-Received: by 10.15.34.206 with SMTP id e54mr23634983eev.24.1369328389023; Thu, 23 May 2013 09:59:49 -0700 (PDT) Received: by 10.15.55.136 with HTTP; Thu, 23 May 2013 09:59:48 -0700 (PDT) Date: Thu, 23 May 2013 18:59:48 +0200 Message-ID: From: Francis Galiegue To: apps-discuss@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [apps-discuss] URI Template: how is the erratum progressing? And another question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 17:12:10 -0000 Hello, So, the first question, as to the erratum, is related to the points I raised some times ago about how to handle empty arrays/associative arrays. I'd like to know the progress on that front. Another question is about handling empty _keys_ in an associative array. Is this legal at all? Empty values are allowed, they obviously have a use (a query parameter can be empty for instance), but what about (written as a JSON Object): { "foo": "", "": "bar" } ? -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From nico@cryptonector.com Thu May 23 10:12:27 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D224921F95EB for ; Thu, 23 May 2013 10:12:27 -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 y7myl+wXxdsz for ; Thu, 23 May 2013 10:12:10 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8768E21F9730 for ; Thu, 23 May 2013 10:02:56 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 4BAF0350072 for ; Thu, 23 May 2013 10:02:56 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id F27A6350058 for ; Thu, 23 May 2013 10:02:55 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id n12so3108496wgh.1 for ; Thu, 23 May 2013 10:02:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=WuJcc26o5A9FzqMKfw3Gm9fd1LrTugAbmMd3tyKI6Mo=; b=fdZBkNIwaYNieSGdZ84KUWzXK3kqFtr25raVI4HOrGHFIEGXmBi5JlGkRfdJ1gj/rC lM1ZcMeTes+K/hL+MTmpCfHrtz4jSBhBWzHPPCxsyhzSeV5E+pNVDWVL9YDrPL7w2hjI 2/A+pbcE6v2u17QLNd3lur3VgdT/pIfb72jwqerx47TEPB3BiLwbM6j9vBySrJt1GPth aswYLEkYQodFs2k3lbUq/vbRJIshtEsG9X9nOvC6Bl+q/93p06BLW0NCSYqlbYGlZQUW dIT6AHNUqSuYAfU55w9xXyPyPBLUdPfLr5rd/L4nsgWtbGSvzRjZL1uTNs6YKwxSVflc eLMQ== MIME-Version: 1.0 X-Received: by 10.180.210.225 with SMTP id mx1mr45740058wic.15.1369328543651; Thu, 23 May 2013 10:02:23 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Thu, 23 May 2013 10:02:23 -0700 (PDT) In-Reply-To: <84317001-DB56-4DBE-9D1E-A4E605BC07A0@tzi.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <142483A4-2E80-43F1-B3BE-B5B01650BB8F@tzi.org> <84317001-DB56-4DBE-9D1E-A4E605BC07A0@tzi.org> Date: Thu, 23 May 2013 12:02:23 -0500 Message-ID: From: Nico Williams To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , apps-discuss@ietf.org Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 17:12:28 -0000 On Thu, May 23, 2013 at 11:23 AM, Carsten Bormann wrote: > On May 23, 2013, at 17:35, Nico Williams wrote: >> ECMAScript specifically only allows that. That's where the >> restriction comes from. > > JSON =E2=89=A0 JavaScript. I'm aware. But defining protocols that can't be implemented in JS because they use numbers that JS can't represent seems problematic. >> Many a ECMAScript and/or JSON implementation use NaN coding, which is >> probably why this restriction is there in the first place (though >> that's just a guess; I'm sure there's a list archive somewhere with a >> lengthy discussion I could check; I don't care). > > Now you lost me -- JSON doesn't have NaNs. > (Another thing that CBOR has that you can't use in a JSON subset.) NaN coding is an implementation technique where all values are internally represented as doubles, with signal bits of NaNs used to store pointers (for strings, arrays, objects) and representations of null, true, and false. >>>> - might as well have a type for "octet string" -- no base64 encoding p= lease >>> >>> Yes, we are just not using the liturgical name "octet string" :-) >> >> Yes it's there and I missed it? > > Yes, we call them "byte strings" (major type 2). > (They are actually the main reason I started work on CBOR.) OK, thanks. From dcrocker@bbiw.net Thu May 23 10:23: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 BCB6621F8ADF for ; Thu, 23 May 2013 10:23: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 aqg5MQRYDRSn for ; Thu, 23 May 2013 10:22:57 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB2A21F9501 for ; Thu, 23 May 2013 10:12:25 -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 r4NHBYiO023569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 May 2013 10:11:38 -0700 Message-ID: <519E4DC0.2030008@bbiw.net> Date: Thu, 23 May 2013 10:11:28 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Barry Leiba References: <20130523154124.25978.qmail@joyce.lan> <519E3A24.3090502@bbiw.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.67]); Thu, 23 May 2013 10:11:38 -0700 (PDT) Cc: John Levine , "apps-discuss@ietf.org" , Alessandro Vesely Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 17:23:19 -0000 On 5/23/2013 9:56 AM, Barry Leiba wrote: > On Thu, May 23, 2013 at 11:47 AM, Dave Crocker wrote: >> On 5/23/2013 8:41 AM, John Levine wrote: >>> You're right. Adding the brackets is clearly a mistake since it makes >>> it impossible to tell where the authserv-id ends and the >>> authres-version starts. >> >> >> huh? > > I think John means that the change makes the second CFWS optional, and > that can't be. Barry, while your explanation does nicely restate the syntactic utility of the brackets, the semantics of your explanation are completely different from what John wrote. So forgive me if press for John to confirm that he merely mistyped or elaborate on his meaning something else. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@taugh.com Thu May 23 10:25: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 BEFDC21F8EEC for ; Thu, 23 May 2013 10:25:37 -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 l71Y6x-OeT-B for ; Thu, 23 May 2013 10:25:18 -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 1764521F92FC for ; Thu, 23 May 2013 10:15:25 -0700 (PDT) Received: (qmail 62285 invoked from network); 23 May 2013 17:15:25 -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=f34c.519e4ead.k1305; bh=DZl9DMxpXJANDdToqAHAh0KugCHJBmKexasW8K7ZZs0=; b=U4aC8OqjkHBeeLgCnhVegYfg5imUFOR331SpN4owcWNgG6ba51gycg+4KsU5Qg07DOjTy1SVMVGb+ElHCw4T6odToxVJAhtqAXSk+6b1QZe+cBLjoQskWkqZmlqSHEmjW934xEQ//v2IEgRDY0qquOCm0u7nzTl8yClYvaeWr/s= 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=f34c.519e4ead.k1305; bh=DZl9DMxpXJANDdToqAHAh0KugCHJBmKexasW8K7ZZs0=; b=klv16DI7Ygbz5qrPp0hHHddrtCRW3EH/bagc19NG2GQpv9tzeqUcneb3lpb+MHSOig02weM84i+sjRDBb0yntwSWlnnZnwh2ugv6a2wY/0qPm8HMQ2IgEezld+4LDyBjCHgv9WnE1ySZbSRTTCSLtNWh5HPLMDW1v3jN3+pTDjg= Received: (ofmipd 127.0.0.1); 23 May 2013 17:15:03 -0000 Date: 23 May 2013 13:15:25 -0400 Message-ID: From: "John R Levine" To: "Dave Crocker" In-Reply-To: <519E3A24.3090502@bbiw.net> References: <20130523154124.25978.qmail@joyce.lan> <519E3A24.3090502@bbiw.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-819509172-1369329325=:25439" Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 17:25:38 -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-819509172-1369329325=:25439 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >>> authres-header = "Authentication-Results:" [CFWS] authserv-id >>> [ [CFWS] authres-version ] >> >> You're right. Adding the brackets is clearly a mistake since it makes >> it impossible to tell where the authserv-id ends and the >> authres-version starts. Authentication-Results: foobar1 ; ... Is that authserv-id foobar1, or authserv-id foobar and authres-version 1 ? R's, John --3825401791-819509172-1369329325=:25439 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNTIzMTcxNTI1WjAjBgkqhkiG 9w0BCQQxFgQUAvi6aCeP/kNGQJQ5MX0X+dmfXioweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAcef/Ww6hlCoP OGug/hJpl4vriXKRrTnmuYm67eFn8fj4eQfbn+thHtjgeD0PGA6nW7KpDRJx uYKHfMFx8Ths0/nKMqucK1LOEbCyXSBsN+PKbQr2GMOSro5yBvIOQvyWiib+ kuspCw6v5CJEUUHdU4J9dS+mYTb8iYpaRpASRwzhbWrvf8dtB2Mq16msAy9/ Qi6VcwFAPIRh+NH62+o/AdYeFVsYfsmAB+g71Y1J9AMN1SVB2YfkcDFFhkeS tOuASLoZDM+NJ3HWnGwzfCw9srF1yiJRHhQHmpnPHmqL5RCpTQP01QfGAvUO S6xjMJXAMQjyGJXOU/FleYHzl5XJcQ== --3825401791-819509172-1369329325=:25439-- From fanf2@hermes.cam.ac.uk Thu May 23 10:26:43 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172A221F92FB for ; Thu, 23 May 2013 10:26:43 -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 ymFGx8kxuTs4 for ; Thu, 23 May 2013 10:26:32 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f32]) by ietfa.amsl.com (Postfix) with ESMTP id D600721F93B1 for ; Thu, 23 May 2013 10:16:37 -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]:41094) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1UfZ7x-0006ta-2M (Exim 4.80_167-5a66dd3) (return-path ); Thu, 23 May 2013 18:16:33 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1UfZ7x-0004P9-M8 (Exim 4.72) (return-path ); Thu, 23 May 2013 18:16:33 +0100 Date: Thu, 23 May 2013 18:16:33 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Carsten Bormann In-Reply-To: <84317001-DB56-4DBE-9D1E-A4E605BC07A0@tzi.org> Message-ID: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <142483A4-2E80-43F1-B3BE-B5B01650BB8F@tzi.org> <84317001-DB56-4DBE-9D1E-A4E605BC07A0@tzi.org> 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: Paul Hoffman , apps-discuss@ietf.org Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 17:26:43 -0000 Carsten Bormann wrote: > On May 23, 2013, at 17:35, Nico Williams wrote: > > > Many a ECMAScript and/or JSON implementation use NaN coding, which is > > probably why this restriction is there in the first place (though > > that's just a guess; I'm sure there's a list archive somewhere with a > > lengthy discussion I could check; I don't care). > > Now you lost me -- JSON doesn't have NaNs. > (Another thing that CBOR has that you can't use in a JSON subset.) It is probably worth putting something in the security considerations about NaNs. See for instance http://article.gmane.org/gmane.comp.lang.lua.general/70705 and http://trac.webkit.org/changeset/64706 Also, the multiple forms of encoding for integers mean that applications have to be careful how they handle range and equality checks - there's an analogous problem to the loose UTF-8 parser security bugs. 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 nico@cryptonector.com Thu May 23 10:30: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 F12ED21F87B7 for ; Thu, 23 May 2013 10:30:38 -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 QRR77TuLjDme for ; Thu, 23 May 2013 10:30:23 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0F221F8793 for ; Thu, 23 May 2013 10:20:35 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id D55062AC06A for ; Thu, 23 May 2013 10:20:34 -0700 (PDT) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 8860A2AC059 for ; Thu, 23 May 2013 10:20:34 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id m46so2292458wev.10 for ; Thu, 23 May 2013 10:20:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nMtNIqBJOaZVpq9ZWihLTnumzd0s3BilcK7Ny31VJCs=; b=BdbXl/N+paWd7Aym6HpBGOId4MIWWn1wWwESTfTqQ1UsqsNoGGsvmro9+K4mp7l8YV N9nXUyV5/uE0V0w7K6uVMg2EiF+QV1/IUD0BPAZ5qrmX2wagt6iYUnM/kTF/b5v+lw29 kOFqD4YBI+T9w1/oznJe8vyyV+3YL1ryXyFxf5eSvj8LuSKUAyZnt9ziXcFweD96skiY LcQdz+Kms9+52Nl0FZVO/Xl4dQhWqwg++NKxz48x7jg/Zs7hE/iHcClU8R0vebpKuIe7 E0j7TBsTEnJgdML7X3q+p8yrqlD2wdHWg0PDnVvl74tNZhy43WnOF/1dMAqfHZl1EqER DSdQ== MIME-Version: 1.0 X-Received: by 10.180.205.206 with SMTP id li14mr45011676wic.33.1369329594443; Thu, 23 May 2013 10:19:54 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Thu, 23 May 2013 10:19:54 -0700 (PDT) In-Reply-To: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> Date: Thu, 23 May 2013 12:19:54 -0500 Message-ID: From: Nico Williams To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , apps-discuss@ietf.org Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 17:30:39 -0000 On Thu, May 23, 2013 at 11:38 AM, Carsten Bormann wrote: > On May 23, 2013, at 18:13, Nico Williams wrote: > >> Also, I believe this is the fifth binary encoding of JSON proposed >> thus far. > > 1) CBOR is not a "binary encoding of JSON". > (It can be used as one, though.) The superset of JSON in CBOR is not in itself appealing enough, I think. We already have a *lot* of binary encodings. It's only the connection to JSON that makes this appealing. You might disagree, but you're probably biased :) You're asking that we standardize this though, so you should do something to justify one more encoding in a sea of encodings. > 2) There are many more proposals in this space, and it is hard to draw a line. > E.g. Google protocol buffers is a prominent example. But it requires a schema. (And what the heck was so wrong with PER? But whatever.) >> An analysis of these might be nice. > > Yes. Find a grad student :-) I think it falls on you to provide some justification for this. It wouldn't be hard, but you might find that an existing, *deployed* encoding is good enough (or maybe you wouldn't but we would). I think I'd rather standardize a good-enough encoding that's been deployed than create a new one, but maybe the improvements CBOR brings are compelling enough. Either way you should definitely provide some analysis. > Of course, I did my own analysis, but I didn't see a need to write it up. That's... odd. You need consensus. Why wouldn't your analysis help you get it? > (More specifically, I didn't see a funding agency interested in this part of reality. > But I'm willing to be surprised :-) Do you intend to use CBOR for any protocols you want standardized at the IETF? Or are you just hoping others will? Nico -- From paul.hoffman@vpnc.org Thu May 23 11:27:44 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA4521F960C for ; Thu, 23 May 2013 11:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.607 X-Spam-Level: X-Spam-Status: No, score=-102.607 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 xtar-4eOUkak for ; Thu, 23 May 2013 11:27:34 -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 DAD8221F9008 for ; Thu, 23 May 2013 11:06:40 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4NI6dJQ003216 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 May 2013 11:06:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Thu, 23 May 2013 11:06:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3367FDBE-8268-4F3A-85CF-94D64BF60FCC@vpnc.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <142483A4-2E80-43F1-B3BE-B5B01650BB8F@tzi.org> <84317001-DB56-4DBE-9D1E-A4E605BC07A0@tzi.org> To: Nico Williams X-Mailer: Apple Mail (2.1503) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 18:27:45 -0000 On May 23, 2013, at 10:02 AM, Nico Williams = wrote: > On Thu, May 23, 2013 at 11:23 AM, Carsten Bormann = wrote: >> JSON =E2=89=A0 JavaScript. >=20 > I'm aware. But defining protocols that can't be implemented in JS > because they use numbers that JS can't represent seems problematic. As I said earlier on this thread, there is already an implementation in = JavaScript. --Paul Hoffman= From jasnell@gmail.com Thu May 23 12:01: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 7779321F9814 for ; Thu, 23 May 2013 12:01:29 -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=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9RTTh5bW9AO for ; Thu, 23 May 2013 12:01:18 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 79BE121F93A3 for ; Thu, 23 May 2013 11:36:01 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id 16so4002938obc.0 for ; Thu, 23 May 2013 11:36: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=VeW877LjCMfkeSDjk2xh4mTUApQ/5BFYmKzbCVJ3d5M=; b=qmHMEjsdITK6fwT4RI3JWnY6WOCMrfKN6Irc4E2j2jwNyidJ3XFGf+MplX1lS8n9yp jQ+Cuce5DN2QiLJzX06RFPptOBBaa7wF1si/udc2EyKnw2ZhcybcMxq+3K0ym3GjZfjw fr6aqdZLliHfgSItvtOY3bPsBL8XQUUuJYCQcXtsht+RENoO5HvMC+OmM+3DZT0GNeUQ KWzEZA4Hjo7E5lKDh+Vlf/kTf8YNskWw31l/wJkfYaNm9iYVlwAaAzOGAeX0QC3YazpM 737Y3ZzauaYpvJjtq2g6tp0nW1Vm3hrq9JplgY5zHlsfyRjIkzOnHt3XeFh9TbYPwKcE GfnQ== X-Received: by 10.60.16.69 with SMTP id e5mr9319798oed.46.1369334161008; Thu, 23 May 2013 11:36:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.3.137 with HTTP; Thu, 23 May 2013 11:35:40 -0700 (PDT) In-Reply-To: <3367FDBE-8268-4F3A-85CF-94D64BF60FCC@vpnc.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <142483A4-2E80-43F1-B3BE-B5B01650BB8F@tzi.org> <84317001-DB56-4DBE-9D1E-A4E605BC07A0@tzi.org> <3367FDBE-8268-4F3A-85CF-94D64BF60FCC@vpnc.org> From: James M Snell Date: Thu, 23 May 2013 11:35:40 -0700 Message-ID: To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 19:01:29 -0000 That's well and good, from everything I've seen so far in this thread, the collective majority opinion can be summarized as "Ugh... Groan.. Another one? Really?" ... That being said, there's really nothing *technically* wrong with CBOR that I can spot and there are a number of very nice features included. Posting the I-D is good, and having implementations available is good, but having a running debate of the technical merits of CBOR vs. Everything Else is pointless. It would be great to see a comparison of CBOR to other previous attempts in this space added to the next iteration of the draft. As far as the I-D being an apps area wg work item... I'm not sure I personally see the value in that yet. There's nothing wrong with handling it as an individual, independent submission for a few iterations and just seeing how support shapes up around it (if it does). If the value of this particular binary encoding becomes readily apparent to everyone later on, then we can go on from there. (just my opinion of course). On Thu, May 23, 2013 at 11:06 AM, Paul Hoffman wrot= e: > On May 23, 2013, at 10:02 AM, Nico Williams wrote= : > >> On Thu, May 23, 2013 at 11:23 AM, Carsten Bormann wrote: >>> JSON =E2=89=A0 JavaScript. >> >> I'm aware. But defining protocols that can't be implemented in JS >> because they use numbers that JS can't represent seems problematic. > > As I said earlier on this thread, there is already an implementation in J= avaScript. > > --Paul Hoffman > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From paul.hoffman@vpnc.org Thu May 23 13:07: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 9BAD021F8F12 for ; Thu, 23 May 2013 13:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.607 X-Spam-Level: X-Spam-Status: No, score=-102.607 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 u2aAr-HXzGil for ; Thu, 23 May 2013 13:06: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 65B9121F9330 for ; Thu, 23 May 2013 12:24:33 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4NJOU9D005745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 May 2013 12:24:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Thu, 23 May 2013 12:24:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6C80DF35-E465-4107-B2B5-34D8D1C2F2CF@vpnc.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <142483A4-2E80-43F1-B3BE-B5B01650BB8F@tzi.org> <84317001-DB56-4DBE-9D1E-A4E605BC07A0@tzi.org> <3367FDBE-8268-4F3A-85CF-94D64BF60FCC@vpnc.org> To: James M Snell X-Mailer: Apple Mail (2.1503) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 20:07:00 -0000 On May 23, 2013, at 11:35 AM, James M Snell wrote: > That's well and good, from everything I've seen so far in this thread, > the collective majority opinion can be summarized as "Ugh... Groan.. > Another one? Really?" =20 Just a note that this is one of the only ones that people are groaning = about that has an Internet Draft and might go through the IETF consensus = process. Carsten and I (maybe naively) thought that doing this in this = environment, instead of say posting ephemeral specs on a web page and = not having it be clear where the community fit it, was a good thing. > ... That being said, there's really nothing > *technically* wrong with CBOR that I can spot and there are a number > of very nice features included. So far, the one technical change that falls within our design goals that = we have heard in the past two days is the possible addition of, or = changing to, streaming for arrays and maps. Like Carsten, I'm still = unsure of the tradeoff of "can also do streaming" versus "having two = ways of doing the same thing has lots of downsides". FWIW, I disagree = about needing it for converting from JSON to CBOR, since holding a = counter of items from the JSON object that is prepended to the eventual = CBOR item is trivial. > Posting the I-D is good, and having > implementations available is good, but having a running debate of the > technical merits of CBOR vs. Everything Else is pointless. It would be > great to see a comparison of CBOR to other previous attempts in this > space added to the next iteration of the draft. Am doing so. And of course, everyone will agree with the criteria for = the comparisons! :-) > As far as the I-D being an apps area wg work item... I'm not sure I > personally see the value in that yet. There's nothing wrong with > handling it as an individual, independent submission for a few > iterations and just seeing how support shapes up around it (if it > does). That would work too. Some ADs prefer things like this to come from WGs, = some are fine with individual submission; thus our question in the first = message in the thread. --Paul Hoffman= From hallam@gmail.com Thu May 23 13:13:43 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E83F21F9713 for ; Thu, 23 May 2013 13:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.984 X-Spam-Level: X-Spam-Status: No, score=-2.984 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599, 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 O2Bi7hruD-YS for ; Thu, 23 May 2013 13:13:29 -0700 (PDT) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6B96121F9294 for ; Thu, 23 May 2013 12:31:54 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id r11so3860237lbv.10 for ; Thu, 23 May 2013 12:31:48 -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=ts6FS2KLi9FNBn1q/aRf8YS0ulFV5nnMnt/0HQ0mGwU=; b=LnpnAz73t3BxwmewlK9AD6rcaT69K5J+6w0yb68SYdSAaQwN/kUGVEkH5tAfm9xLeH 52kWHc8BXV6WZck6V9UjpFMpKuTHPw/G1KHmjlF/9hVzx1lA8eIpc1Tjyv4yqo7U0j9V ACW0V/yobUIMHUuZE4HTH1mOSlbMBjZM0hndox/1cY7M9oEuGsMkCBA6Ht2t4vWsiKVE u40dDgUO/3Lh08rgbbKHdY13RF83VQSH5u+1HM3fyVaHIAvOngdSAvNH5011CJMArGmw SkKjUyThve0HlwevXhXH1FUa1UWGm3ZVxNe0EBS5JTkkEvGyVvK05Vrjs95uzEQsUNox 9JhA== MIME-Version: 1.0 X-Received: by 10.112.89.8 with SMTP id bk8mr1148134lbb.73.1369337508329; Thu, 23 May 2013 12:31:48 -0700 (PDT) Received: by 10.112.200.169 with HTTP; Thu, 23 May 2013 12:31:48 -0700 (PDT) In-Reply-To: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <142483A4-2E80-43F1-B3BE-B5B01650BB8F@tzi.org> <84317001-DB56-4DBE-9D1E-A4E605BC07A0@tzi.org> Date: Thu, 23 May 2013 15:31:48 -0400 Message-ID: From: Phillip Hallam-Baker To: Tony Finch Content-Type: multipart/alternative; boundary=001a11c37a0ac2ff0104dd67bb61 Cc: Paul Hoffman , General discussion of application-layer protocols Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 20:13:43 -0000 --001a11c37a0ac2ff0104dd67bb61 Content-Type: text/plain; charset=ISO-8859-1 Completely off topic here but raised by the discussion. JSON needs to address NaN encoding. NaN is essential for exchange of numeric data in scientific applications. JSON is going to be used in those applications. It would be better to have one way to use JSON in scientific applications rather than have different work arounds emerge. There is an ongoing effort to document JSON, this should be included in those efforts. --001a11c37a0ac2ff0104dd67bb61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Completely off topic here but raised by the discussion. JS= ON needs to address NaN encoding.

NaN is essential= for exchange of numeric data in scientific applications. JSON is going to = be used in those applications. It would be better to have one way to use JS= ON in scientific applications rather than have different work arounds emerg= e.

There is an ongoing effort to document JSON= , this should be included in those efforts.
--001a11c37a0ac2ff0104dd67bb61-- From hallam@gmail.com Thu May 23 13:23: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 E3F6A21F97EA for ; Thu, 23 May 2013 13:23: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=[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 hz7BUYby2Le8 for ; Thu, 23 May 2013 13:22:59 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4923221F9731 for ; Thu, 23 May 2013 12:42:19 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ez20so3688690lab.30 for ; Thu, 23 May 2013 12:42:18 -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=dfThcFuMJul61GJGy2StEX4LUHVPfz+BrzO+FGiiafI=; b=UvXJJWtdtMsrtRCXwZ/zem2lEcQCyOPblEin2IGOb0f+K+2+H09cnJGKsyTmt6FNgh g09poi6AQhg1N1C3vlEgm7IDHmyeuwjLke9XI5Bq50LdQYRBb/DXqg+0YBAU8OfZQaDp XMohMed8eOBWB/APkPmcr8WLD7WH2Ur1+zwBGZk7shfFNQaesO3J2uZJ7pwjhuyJI1v3 i9rJBmP2ebo2ipzwWfPmOWvbqxY0Ar2tDAaX1+QRXhkeM78z5DW83Cc7rdhggCGq1rJC BoFX2pX8g97UV/WU8GI9YBo1Cj28ZxRi3ong5w640XJvxFgGJJ+6rZ6EO0xBCX4g1MMP SIaQ== MIME-Version: 1.0 X-Received: by 10.112.201.131 with SMTP id ka3mr7076748lbc.113.1369338138027; Thu, 23 May 2013 12:42:18 -0700 (PDT) Received: by 10.112.200.169 with HTTP; Thu, 23 May 2013 12:42:17 -0700 (PDT) In-Reply-To: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> Date: Thu, 23 May 2013 15:42:17 -0400 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c32a064b6d1504dd67e1fa Cc: Paul Hoffman , General discussion of application-layer protocols Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 20:23:11 -0000 --001a11c32a064b6d1504dd67e1fa Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 23, 2013 at 12:13 PM, Nico Williams wrote: > Also, I believe this is the fifth binary encoding of JSON proposed > thus far. Can we list the ones that have been proposed thus far? > > Here's a [no-doubt partial] list: > > - BSON > - MsgPack > - Smile > - UBJSON > - CBOR > > That's just the ones I recall seeing before or which I found in 30 > seconds of searching. > > Some of these are used in actual protocols right now. > +1 I don't see any particular reason to favor this new proposal. > I do agree that we need a schema-less encoding (which means we can't > get as good as PER and friends). We probably don't need a > schema-capable encoding for JSON (though that might be nice). We do > need schema-aware encodings for some protocols, but we have plenty > already, and none are nor need to be JSONish. > What I think you intend here is that the encoding should not be schema-aware. Whether or not you have a formal schema is not the issue here, the issue is whether it is necessary to know the schema to make sense of the wire format. One of the main reasons that JSON and XML encodings are attractive is that you can look at the wire format and make sense of them. ASN.1 BER encoding can also be read with an appropriate dump tool. It has to be possible to do the same with Binary JSON. Some of the compact XML representations used knowledge of the schema to improve packing density and some could be read using a dump tool but required knowledge of the mapping from the text representation to the binary to be able to convert from one to the other. I think it is clear that any JSON binary coding has to be readable without knowledge of a schema and that a non-schema aware tool must be able to convert between the two formats. Insisting on a single representation for a number seems much less important to me. Whether 7 is represented in one, two, four or eight bytes seems to me to be something that can be left to the implementations. -- Website: http://hallambaker.com/ --001a11c32a064b6d1504dd67e1fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 23, 2013 at 12:13 PM, Nico Williams <nic= o@cryptonector.com> wrote:
Also, I believe this is the fifth binary enc= oding of JSON proposed
thus far. =A0Can we list the ones that have been proposed thus far?

Here's a [no-doubt partial] list:

=A0- BSON
=A0- MsgPack
=A0- Smile
=A0- UBJSON
=A0- CBOR

That's just the ones I recall seeing before or which I found in 30
seconds of searching.

Some of these are used in actual protocols right now.
=
+1=A0

I don't see any par= ticular reason to favor this new proposal.=A0

=A0<= /div>
I do agree that we need a schema-less encoding (which means we can't get as good as PER and friends). =A0We probably don't need a
schema-capable encoding for JSON (though that might be nice). =A0We do
need schema-aware encodings for some protocols, but we have plenty
already, and none are nor need to be JSONish.

What I think= you intend here is that the encoding should not be schema-aware. Whether o= r not you have a formal schema is not the issue here, the issue is whether = it is necessary to know the schema to make sense of the wire format.

One of the main reasons that JSON and XML encodings are attractive is that= you can look at the wire format and make sense of them. ASN.1 BER encoding= can also be read with an appropriate dump tool. It has to be possible to d= o the same with Binary JSON.


Some of the compact XML represe= ntations used knowledge of the schema to improve packing density and some c= ould be read using a dump tool but required knowledge of the mapping from t= he text representation to the binary to be able to convert from one to the = other.

I think it is clear that any JSON binary co= ding has to be readable without knowledge of a schema and that a non-schema= aware tool must be able to convert between the two formats.


Insisting on a single representat= ion for a number seems much less important to me. Whether 7 is represented = in one, two, four or eight bytes seems to me to be something that can be le= ft to the implementations.

--
Website: http://h= allambaker.com/
--001a11c32a064b6d1504dd67e1fa-- From tony@att.com Thu May 23 13:32: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 7B10021F977D for ; Thu, 23 May 2013 13:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 VGN+bz8CutY9 for ; Thu, 23 May 2013 13:32:38 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 1104221F977E for ; Thu, 23 May 2013 12:51:58 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id d537e915.0.353747.00-296.991995.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 23 May 2013 19:51:58 +0000 (UTC) X-MXL-Hash: 519e735e0081eee5-64672da4b0a76fe484b205b604499a97685dea1f Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4NJpvpa014770 for ; Thu, 23 May 2013 15:51:57 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4NJppm4014725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 May 2013 15:51:52 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi132.aldc.att.com (RSA Interceptor) for ; Thu, 23 May 2013 19:51:38 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 r4NJpcQi006350 for ; Thu, 23 May 2013 15:51:38 -0400 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r4NJpZlJ006287 for ; Thu, 23 May 2013 15:51:35 -0400 Received: from [135.70.84.245] (vpn-135-70-84-245.vpn.swst.att.com[135.70.84.245]) by maillennium.att.com (mailgw1) with ESMTP id <20130523195134gw1008e016e> (Authid: tony); Thu, 23 May 2013 19:51:35 +0000 X-Originating-IP: [135.70.84.245] Message-ID: <519E7346.6060909@att.com> Date: Thu, 23 May 2013 15:51:34 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: apps-discuss@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 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.20.145] X-AnalysisOut: [v=2.0 cv=QO3fsH3L c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=CcG6VjeJWIQA:10 a=bfzWQn4VrGAA:10 a=SMb7TJcE3iUA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=c1igK0EI_n8A:10 a=W3zItJJVKYmmaqm_DUoA:9 a=wPNLv] X-AnalysisOut: [fGTeEIA:10] Subject: Re: [apps-discuss] And another question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 20:32:54 -0000 On 5/23/2013 12:59 PM, Francis Galiegue wrote: > Another question is about handling empty _keys_ in an associative > array. Is this legal at all? Empty values are allowed, they obviously > have a use (a query parameter can be empty for instance), but what > about (written as a JSON Object): > > { > "foo": "", > "": "bar" > } > > ? This looks perfectly legal to me. Tony Hansen From cabo@tzi.org Thu May 23 13:35: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 EE22F21F9638 for ; Thu, 23 May 2013 13:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.214 X-Spam-Level: X-Spam-Status: No, score=-106.214 tagged_above=-999 required=5 tests=[AWL=0.035, 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 lhsDUy+UtbW2 for ; Thu, 23 May 2013 13:35:25 -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 D4F1E21F949A for ; Thu, 23 May 2013 12:56: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 r4NJtvhr019917; Thu, 23 May 2013 21:55:57 +0200 (CEST) Received: from [192.168.217.105] (p54891C3A.dip0.t-ipconnect.de [84.137.28.58]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1D3F23161; Thu, 23 May 2013 21:55:57 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Thu, 23 May 2013 21:55:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0A6FC529-F95D-4F2D-9BCF-F0C7ED24CD54@tzi.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <142483A4-2E80-43F1-B3BE-B5B01650BB8F@tzi.org> <84317001-DB56-4DBE-9D1E-A4E605BC07A0@tzi.org> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1503) Cc: Paul Hoffman , General discussion of application-layer protocols Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 20:35:41 -0000 On May 23, 2013, at 21:31, Phillip Hallam-Baker = wrote: > Completely off topic here but raised by the discussion. JSON needs to = address NaN encoding. >=20 > NaN is essential for exchange of numeric data in scientific = applications. JSON is going to be used in those applications. It would = be better to have one way to use JSON in scientific applications rather = than have different work arounds emerge. The applications I have seen trying to address the problem have simply = used null to encode NaN. There is rarely a case when you need to be able to express both null and = NaN in one place (use CBOR, then :-). A bigger problem is -Infinity/Infinity, but similar hacks can be used = there, too (say, use false/true, or stringify). > There is an ongoing effort to document JSON, this should be included = in those efforts. JSON MUST NOT change, so I don't think I agree with that (neither does = the proposed charter of the WG). Gr=FC=DFe, Carsten From hallam@gmail.com Thu May 23 13:49: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 654A821F983C for ; Thu, 23 May 2013 13:49: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=[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 4QbawWqSXBGF for ; Thu, 23 May 2013 13:49:00 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id B3DB321F9375 for ; Thu, 23 May 2013 13:08:33 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id ed20so3702769lab.37 for ; Thu, 23 May 2013 13:08:32 -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=Fh4d3M/nx+NpMKUS9/lrkJBNnw685MNNLkWEgqGYrNM=; b=i09vJJ7Ym63VLjEGgTavLEvEBrykCj8MJFKPQzXaYN46gqBr7F/iQqjjQb2pVsK+cc EGiABAdWzlLSg5EZhQtT0zd+cQx6BYQBxWBHx9g22kdA4EUa0rpZHTm4c0l0PjRRIW/Q NOPJIikUoFawaXRfnzhdB4gnD+4YwvstKCvnKLorN/HeoUjEnatFD1DcjID1Fwlc0Sed t5/U9P2uxBEYP/ZhaA+Xd/qnqpaNWVjXGhAAuUfP5lu4sA316oP2Wep1DrcvJNgUDxDP SwjNRZQ935tYpl1bsiK2AVHjeG4H5Ql/XFVIjmy/nYE4RS58XemI6oNX3BbxfV/mxQ5J VO8w== MIME-Version: 1.0 X-Received: by 10.112.89.8 with SMTP id bk8mr1209634lbb.73.1369339712324; Thu, 23 May 2013 13:08:32 -0700 (PDT) Received: by 10.112.200.169 with HTTP; Thu, 23 May 2013 13:08:31 -0700 (PDT) In-Reply-To: <0A6FC529-F95D-4F2D-9BCF-F0C7ED24CD54@tzi.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <142483A4-2E80-43F1-B3BE-B5B01650BB8F@tzi.org> <84317001-DB56-4DBE-9D1E-A4E605BC07A0@tzi.org> <0A6FC529-F95D-4F2D-9BCF-F0C7ED24CD54@tzi.org> Date: Thu, 23 May 2013 16:08:31 -0400 Message-ID: From: Phillip Hallam-Baker To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11c37a0a214a8304dd683fc7 Cc: Paul Hoffman , General discussion of application-layer protocols Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 20:49:10 -0000 --001a11c37a0a214a8304dd683fc7 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 23, 2013 at 3:55 PM, Carsten Bormann wrote: > On May 23, 2013, at 21:31, Phillip Hallam-Baker wrote: > > > Completely off topic here but raised by the discussion. JSON needs to > address NaN encoding. > > > > NaN is essential for exchange of numeric data in scientific > applications. JSON is going to be used in those applications. It would be > better to have one way to use JSON in scientific applications rather than > have different work arounds emerge. > > The applications I have seen trying to address the problem have simply > used null to encode NaN. > There is rarely a case when you need to be able to express both null and > NaN in one place (use CBOR, then :-). > There are many work-arounds possible. A standard should only have one. > A bigger problem is -Infinity/Infinity, but similar hacks can be used > there, too (say, use false/true, or stringify). > > > There is an ongoing effort to document JSON, this should be included in > those efforts. > > JSON MUST NOT change, so I don't think I agree with that (neither does the > proposed charter of the WG). > I don't think we have ever accepted a standard that declares it can't be changed. We have certainly changed all the ones we started with. Even ASCII was changed. There are several ways that NaN and +/- infinity can be introduced without changing JSON syntax. The point is there should only be one way that code does so. -- Website: http://hallambaker.com/ --001a11c37a0a214a8304dd683fc7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 23, 2013 at 3:55 PM, Carsten Bormann <cabo@tzi.org= > wrote:
On May 23, 2013, at 21:31, Phillip Hallam-Baker <hallam@gmail.com> wrote:

> Completely off topic here but raised by the discussion. JSON needs to = address NaN encoding.
>
> NaN is essential for exchange of numeric data in scientific applicatio= ns. JSON is going to be used in those applications. It would be better to h= ave one way to use JSON in scientific applications rather than have differe= nt work arounds emerge.

The applications I have seen trying to address the problem have simpl= y used null to encode NaN.
There is rarely a case when you need to be able to express both null and Na= N in one place (use CBOR, then :-).

There are many work-arounds possible. A standard should only have one.

=A0
A bigger problem is -Infinity/Infinity, but similar hacks can be used there= , too (say, use false/true, or stringify).

> There is an ongoing effort to document JSON, this should be included i= n those efforts.

JSON MUST NOT change, so I don't think I agree with that (neither= does the proposed charter of the WG).

I don't think w= e have ever accepted a standard that declares it can't be changed. We h= ave certainly changed all the ones we started with. Even ASCII was changed.=

There are several ways that NaN and +/- infinity can be introduced without= changing JSON syntax. The point is there should only be one way that code = does so.


--
Website: <= a href=3D"http://hallambaker.com/">http://hallambaker.com/
--001a11c37a0a214a8304dd683fc7-- From nico@cryptonector.com Thu May 23 13:49: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 55CF921F8ECB for ; Thu, 23 May 2013 13:49:38 -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=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxh8A2YI5jM9 for ; Thu, 23 May 2013 13:49:24 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id AFF2821F98CE for ; Thu, 23 May 2013 13:08:41 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id E5C1A350084 for ; Thu, 23 May 2013 13:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=7r6/fvC/f2VWYQLT3kSi ANeylOQ=; b=HeqYbXt5N6ju12oDUBN4emkJeBj0NHHIBn6XiW0w3V3VOgLVcQ0Y fiVgBzugATohT5F1ewXsjassfUj1BZWs6ynpafuo5pB8xfCzA6YptCJEyUG+m47m E5/vybx+ZwVH/d1ePSQFxbVILmmJ+scaoDWtvmYtnf0kH+70b7w/y3U= Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 23A0335001C for ; Thu, 23 May 2013 13:08:15 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id t60so1351461wes.11 for ; Thu, 23 May 2013 13:08:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=epwgZglg5GJMQCozfoAriXb/hGMJpvNLq42g5aLJ9qc=; b=LormnldXBdNCrWM4IOivN22bhTp2w+7mRZQUqBmkx+MKdNxD6xl8xNlRiYZKrczM+H EE1H++4fC6dzddDPG8fyjwSfPau3NXG4mkpbx8Bs7ycrH5TLDBDYxaYwTXfDjTkZfyk1 B5izqJD7x1QVik0M9Wt3WHqQ/s/vLkxDK3cOkTF3UzkUESqFbdBmafiq6kt3FUACMX10 Ml2/Hn1sldcTS/Wj46DiIAVHZqnBAPie++O/yVr5lRQh9CoiO13GEKEvC7UQ/pDrLxJW ZybsYgurZv7qnDCZa+5sSWJQ4+5RDEIN6xE123myrau82/q5VABv81Ysly5+qDoSKS34 M3Tg== MIME-Version: 1.0 X-Received: by 10.180.39.137 with SMTP id p9mr46322422wik.27.1369339660926; Thu, 23 May 2013 13:07:40 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Thu, 23 May 2013 13:07:40 -0700 (PDT) In-Reply-To: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> Date: Thu, 23 May 2013 15:07:40 -0500 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , General discussion of application-layer protocols Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 20:49:38 -0000 On Thu, May 23, 2013 at 2:42 PM, Phillip Hallam-Baker wrote: > On Thu, May 23, 2013 at 12:13 PM, Nico Williams > wrote: >> I do agree that we need a schema-less encoding (which means we can't >> get as good as PER and friends). We probably don't need a >> schema-capable encoding for JSON (though that might be nice). We do >> need schema-aware encodings for some protocols, but we have plenty >> already, and none are nor need to be JSONish. > > What I think you intend here is that the encoding should not be > schema-aware. Whether or not you have a formal schema is not the issue here, > the issue is whether it is necessary to know the schema to make sense of the > wire format. Indeed, I meant that the encoding doesn't require a schema. A schema may still be used by the app, of course, but the codec has no knowledge of if, and in particular the decoder cannot be required to have knowledge of the schema. > One of the main reasons that JSON and XML encodings are attractive is that > you can look at the wire format and make sense of them. ASN.1 BER encoding > can also be read with an appropriate dump tool. It has to be possible to do > the same with Binary JSON. Well, they make some sense. Documentation really helps though :) (And BER... can be dumped, but when implicit tagging is used you lose plenty of type metadata and have to resort to heuristics.) > Some of the compact XML representations used knowledge of the schema to > improve packing density and some could be read using a dump tool but > required knowledge of the mapping from the text representation to the binary > to be able to convert from one to the other. Right, like FastInfoSet (which uses PER). > I think it is clear that any JSON binary coding has to be readable without > knowledge of a schema and that a non-schema aware tool must be able to > convert between the two formats. Yes. If we need further compression then use zlib or similar. > Insisting on a single representation for a number seems much less important > to me. Whether 7 is represented in one, two, four or eight bytes seems to me > to be something that can be left to the implementations. I agree that it's less important, and I won't insist on it. It's just a mild irritant to not have c14n, but maybe it's just me and I should get over it for good. Nico -- From hallam@gmail.com Thu May 23 13:57: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 396BD21F97B3 for ; Thu, 23 May 2013 13:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.052 X-Spam-Level: X-Spam-Status: No, score=-3.052 tagged_above=-999 required=5 tests=[AWL=0.546, BAYES_00=-2.599, 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 yg3GI4LaPe2K for ; Thu, 23 May 2013 13:56:47 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id AEE2021F9021 for ; Thu, 23 May 2013 13:14:19 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id o10so3830985lbi.22 for ; Thu, 23 May 2013 13:14:18 -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=j3ToIS1uyN+GKBH/PF5RoW9zMGugizNtF5M+3pTJ/QA=; b=jooh8xy9Hf8uObSt6pCvNZf4cKzJ1i3M+gB3vFbPUI/+7GjjBVZcXuveBJ/APvncyX FIcSmqg/uehCH9UxQU+6sGWtpbZHbxZQy31FzPK+aJD5/sJVU1nOFYnyFKBR9TipseKz rh81z4ojYRsDY1SuACfhhx9toQ2lSvJfo2CCo27wk3lASBdRBkUsEerzcAWrKkfqKaY+ +aNy1guFS79wf0rTzai9OTeU2wz4cFiJrXWIbZGp9hokgVEbOy63CjUmeIwFtmYzI7Se BEoGls0uUmeM2Bk1EXXc9gya805MZhnjAyrB0YkyWTDr9TXHkusVDHHU5SKFL3HRGFBy aPLQ== MIME-Version: 1.0 X-Received: by 10.112.73.135 with SMTP id l7mr7371560lbv.42.1369340058338; Thu, 23 May 2013 13:14:18 -0700 (PDT) Received: by 10.112.200.169 with HTTP; Thu, 23 May 2013 13:14:18 -0700 (PDT) In-Reply-To: <6C80DF35-E465-4107-B2B5-34D8D1C2F2CF@vpnc.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <142483A4-2E80-43F1-B3BE-B5B01650BB8F@tzi.org> <84317001-DB56-4DBE-9D1E-A4E605BC07A0@tzi.org> <3367FDBE-8268-4F3A-85CF-94D64BF60FCC@vpnc.org> <6C80DF35-E465-4107-B2B5-34D8D1C2F2CF@vpnc.org> Date: Thu, 23 May 2013 16:14:18 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=14dae93d8eacc10d8804dd6853a9 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 20:57:01 -0000 --14dae93d8eacc10d8804dd6853a9 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 23, 2013 at 3:24 PM, Paul Hoffman wrote: > On May 23, 2013, at 11:35 AM, James M Snell wrote: > > > That's well and good, from everything I've seen so far in this thread, > > the collective majority opinion can be summarized as "Ugh... Groan.. > > Another one? Really?" > > Just a note that this is one of the only ones that people are groaning > about that has an Internet Draft and might go through the IETF consensus > process. Carsten and I (maybe naively) thought that doing this in this > environment, instead of say posting ephemeral specs on a web page and not > having it be clear where the community fit it, was a good thing. I don't remember you being appointed to address the issue. Since almost all the response to your proposal has been that people don't like your design choices, and since you make it abundantly clear that you are not interested in our input, I can't quite see where a consensus is going to come. Unless that is the consensus is that your proposal sucks. I would certainly object to a format that was counted being granted any degree of IETF recognition lest someone try to force me to use it in the future. My experience of coding ASN.1 DER (in C and javascript) leads me to reject any counted scheme as a non starter. -- Website: http://hallambaker.com/ --14dae93d8eacc10d8804dd6853a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, May 23, 2013 at 3:24 PM, Paul Hoffman <= ;paul.hoffman@vp= nc.org> wrote:
On May 23, 2013, at 11:35 = AM, James M Snell <jasnell@gmail.co= m> wrote:

> That's well and good, from everything I've seen so far in this= thread,
> the collective majority opinion can be summarized as "Ugh... Groa= n..
> Another one? Really?"

Just a note that this is one of the only ones that people are groanin= g about that has an Internet Draft and might go through the IETF consensus = process. Carsten and I (maybe naively) thought that doing this in this envi= ronment, instead of say posting ephemeral specs on a web page and not havin= g it be clear where the community fit it, was a good thing.

I don't remember you being appointed to addre= ss the issue.=A0

Since almost all the = response to your proposal has been that people don't like your design c= hoices, and since you make it abundantly clear that you are not interested = in our input, I can't quite see where a consensus is going to come. Unl= ess that is the consensus is that your proposal sucks.

I would certainly object to a format that was cou= nted being granted any degree of IETF recognition lest someone try to force= me to use it in the future.

My experi= ence of coding ASN.1 DER (in C and javascript) leads me to reject any count= ed scheme as a non starter.=A0


--
Website: http://hallambaker.com/
--14dae93d8eacc10d8804dd6853a9-- From nico@cryptonector.com Thu May 23 13:57: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 C285821F86BB for ; Thu, 23 May 2013 13:57:33 -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=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOJ-ksOKEVL7 for ; Thu, 23 May 2013 13:57:19 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 47BA921F86D3 for ; Thu, 23 May 2013 13:15:12 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 102A5BC042 for ; Thu, 23 May 2013 13:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=YEfsA5kbVo8FeJfz6nKJUyPy56s=; b=AGd5j/MjR/6 2U97TlaLjtzVvbATFLpyOzCwSNmmPm4b3FKfdZc6G8OKnev2GNWECEt415TWp3i5 /fvCZEJmNGrzAWkZo7DYmmkg+kpVV587Dd6bFVyMeyx3XeTUk7vS0HFdkWFAd/P4 C+O8mIJGfrekinm4tXt+xf0zj0PsGUMU= Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPSA id A2BBCBC040 for ; Thu, 23 May 2013 13:15:11 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id a12so2414089wgh.35 for ; Thu, 23 May 2013 13:15:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Zuj06p86ev+tHmV5D3KGFrVwHPOr+6RbQkoXvn+Sb8g=; b=JdUjAilnDMdhpvQY6wP/9Zy1Yt0k0jiXOzXuwBIxOVPjTzfpYVKCSqzoK36Xg7fJWs JlGSyJq1EcHWfd0RqQ5wsW1u2z24L8MtkY36Qb9nrlGKxApcz9vLIVThv7YupbThUPRL bxvxbHW1vPzXvXft7JbODrcyD16af7TiQe7jTFf2GI2JmXpEd8uCxB4g7j+dHu1xuuDd fdaRPxWo7Bcq19g45rIPB/Ib6YanAPJ7nVo4dc6hKiuBvK+xxoIlQN1+k6uihLiyiOKf iopMwWMRw39S6a0dR4qorlF533kGvNfSHpLZtkj6ke9liSJsDccnb5Hpxwe5sMN/3nrW 1SrQ== MIME-Version: 1.0 X-Received: by 10.181.13.229 with SMTP id fb5mr28175361wid.16.1369340013405; Thu, 23 May 2013 13:13:33 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Thu, 23 May 2013 13:13:33 -0700 (PDT) In-Reply-To: <6C80DF35-E465-4107-B2B5-34D8D1C2F2CF@vpnc.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <142483A4-2E80-43F1-B3BE-B5B01650BB8F@tzi.org> <84317001-DB56-4DBE-9D1E-A4E605BC07A0@tzi.org> <3367FDBE-8268-4F3A-85CF-94D64BF60FCC@vpnc.org> <6C80DF35-E465-4107-B2B5-34D8D1C2F2CF@vpnc.org> Date: Thu, 23 May 2013 15:13:33 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 20:57:33 -0000 On Thu, May 23, 2013 at 2:24 PM, Paul Hoffman wrote= : > On May 23, 2013, at 11:35 AM, James M Snell wrote: > >> That's well and good, from everything I've seen so far in this thread, >> the collective majority opinion can be summarized as "Ugh... Groan.. >> Another one? Really?" > > Just a note that this is one of the only ones that people are groaning ab= out that has an Internet Draft and might go through the IETF consensus proc= ess. Carsten and I (maybe naively) thought that doing this in this environm= ent, instead of say posting ephemeral specs on a web page and not having it= be clear where the community fit it, was a good thing. There's a huge world outside the IETF. The folks working on Simple and BSON, to take two examples, may not care about bringing their work to us, but then, they may also be annoyed by our blindsiding them with a standards-track binary JSON (I know, CBOR's a superset) encoding that's not interoperable with theirs. In particular, if there's wide deployment of one of them, why shouldn't we pick one of them? Should we not invite the wider JSON community to this discussion? Nico -- From hallam@gmail.com Thu May 23 14: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 37D4D21F8539 for ; Thu, 23 May 2013 14:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.107 X-Spam-Level: X-Spam-Status: No, score=-3.107 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599, 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 sqlKb7I+DpWf for ; Thu, 23 May 2013 14:29:48 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0D48B21F9619 for ; Thu, 23 May 2013 13:45:42 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id z5so3943858lbh.13 for ; Thu, 23 May 2013 13:45:42 -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=sMWLedqkKgOcHdUzEn8/0t406i1nkhbB9SRuNF4uM1g=; b=PtIOIsLRUKCBkPmcQOG/Rc4UYZ3jRpYGmbRQJScEBSRmPp9wdG3fu9whjGa6ArvB6P YKd8kMM28bHsP1daZSFhMfq3+vkIS/FK9CajAJNbR5Aek+lVa9K/hyKZ1lCs0kDcGoEK gs0dZwBQ9gYgr3rl3shu5cDWxJItUyz2OWHV3jBcrteGwbG19tF7cov969StjDYIVmHl r8WuAlMD2y42HUA2RQmXM1JWmJFu5jecc9tE/RC8+lQdS1CkKBVMGTjCitLQDmHZ+wmS G9v7rERaLi7KNLVfTq+7bdd1xv9//OZZgmmPTPtF/fWOgI4lCJIEoRneKV4FRQuQ/x2d 4ySw== MIME-Version: 1.0 X-Received: by 10.152.87.116 with SMTP id w20mr7426476laz.0.1369341941915; Thu, 23 May 2013 13:45:41 -0700 (PDT) Received: by 10.112.200.169 with HTTP; Thu, 23 May 2013 13:45:41 -0700 (PDT) In-Reply-To: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> Date: Thu, 23 May 2013 16:45:41 -0400 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c237c40627ed04dd68c452 Cc: Paul Hoffman , General discussion of application-layer protocols Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 21:30:04 -0000 --001a11c237c40627ed04dd68c452 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 23, 2013 at 4:07 PM, Nico Williams wrote: > On Thu, May 23, 2013 at 2:42 PM, Phillip Hallam-Baker > wrote: > > One of the main reasons that JSON and XML encodings are attractive is > that > > you can look at the wire format and make sense of them. ASN.1 BER > encoding > > can also be read with an appropriate dump tool. It has to be possible to > do > > the same with Binary JSON. > > Well, they make some sense. Documentation really helps though :) > > (And BER... can be dumped, but when implicit tagging is used you lose > plenty of type metadata and have to resort to heuristics.) I forgot about implicit tagging but that is of course the reason that implicit tagging in ASN.1 is evil. > Insisting on a single representation for a number seems much less > important > > to me. Whether 7 is represented in one, two, four or eight bytes seems > to me > > to be something that can be left to the implementations. > > I agree that it's less important, and I won't insist on it. It's just > a mild irritant to not have c14n, but maybe it's just me and I should > get over it for good. > I think we really have to get over the C14n fetish. It forces us to do things like sort tags into order before serialization. I have been doing digital signatures and network security for 20 years now and I have never once come across a situation where canonicalization would add value except for situations like DKIM where (1) it is necessary to work round legacy infrastructure with obnoxious behavior and (2) the ability to verify a signature is not absolutely critical. There are only really two cases of interest for authenticating data. The first is when data is in motion and is passing through gateways and other intermediaries that might change it. While it is in theory possible that a gateway might change the data in a way that modifies the bits on the wire without making semantic changes I have yet to see such a gateway in practice and what would be the point? Email gateways that perform line wrapping of text should have been strangled at birth and so should their XML and JSON equivalents. The second case is where data is at rest. That is not really the IETF mandate but the same arguments apply. If you want to authenticate data at rest then you had better keep the original serialization of the data. Chunked encoding One requirement that I have not seen addressed yet is the need to support chunked encodings so that data can be streamed with a finite buffer space. If I had a binary coding of JSON available, the number one use case for me right now would be to package a JSON Signature with the signed data. Or to use it to create PKCS#7 like structures round an arbitrary MIME content type. So I would like to have the ability to specify the length of a text string or a binary object as a series of chunks, each chunk being preceded by a length field. It would also be convenient to be able to change the chunk type from Binary to String in mid stream so as to allow a transcoder that guessed that the data type was 'base64' based on the first 1000 bytes to revise that guess when byte 1001 contains a non base64 character. Null type Allowing data nulls in a binary format is also very useful. This allows for padding to align on byte boundaries and can be used to reserve space in a binary file for pointers and indexes to be added later on. -- Website: http://hallambaker.com/ --001a11c237c40627ed04dd68c452 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 23, 2013 at 4:07 PM, Nico Williams <nic= o@cryptonector.com> wrote:
On Thu, May 23, 2013 at 2:= 42 PM, Phillip Hallam-Baker <hallam@= gmail.com> wrote:
> One of the main reasons that JSON and XML encodings are attractive is = that
> you can look at the wire format and make sense of them. ASN.1 BER enco= ding
> can also be read with an appropriate dump tool. It has to be possible = to do
> the same with Binary JSON.

Well, they make some sense. =A0Documentation really helps though :)
(And BER... can be dumped, but when implicit tagging is used you lose
plenty of type metadata and have to resort to heuristics.)

I forgot about implicit tagging but that is of course= the reason that implicit tagging in ASN.1 is evil.

> Insisting on a = single representation for a number seems much less important
> to me. Whether 7 is represented in one, two, four or eight bytes seems= to me
> to be something that can be left to the implementations.

I agree that it's less important, and I won't insist on it. = =A0It's just
a mild irritant to not have c14n, but maybe it's just me and I should get over it for good.

I think we = really have to get over the C14n fetish. It forces us to do things like sor= t tags into order before serialization. I have been doing digital signature= s and network security for 20 years now and I have never once come across a= situation where canonicalization would add value except for situations lik= e DKIM where (1) it is necessary to work round legacy infrastructure with o= bnoxious behavior and (2) the ability to verify a signature is not absolute= ly critical.

There are only really two cases of interest= for authenticating data. The first is when data is in motion and is passin= g through gateways and other intermediaries that might change it. While it = is in theory possible that a gateway might change the data in a way that mo= difies the bits on the wire without making semantic changes I have yet to s= ee such a gateway in practice and what would be the point? Email gateways t= hat perform line wrapping of text should have been strangled at birth and s= o should their XML and JSON equivalents.

The second case is where data is at rest. T= hat is not really the IETF mandate but the same arguments apply. If you wan= t to authenticate data at rest then you had better keep the original serial= ization of the data.


Chunked encoding

One requirement that I have not seen addressed yet is the nee= d to support chunked encodings so that data can be streamed with a finite b= uffer space.

If I had a binary coding of JSON available,= the number one use case for me right now would be to package a JSON Signat= ure with the signed data. Or to use it to create PKCS#7 like structures rou= nd an arbitrary MIME content type.

So I would like to have the ability to spec= ify the length of a text string or a binary object as a series of chunks, e= ach chunk being preceded by a length field. It would also be convenient to = be able to change the chunk type from Binary to String in mid stream so as = to allow a transcoder that guessed that the data type was 'base64' = based on the first 1000 bytes to revise that guess when byte 1001 contains = a non base64 character.


Null type
Allowing data nulls in a binary format is also very usef= ul. This allows for padding to align on byte boundaries and can be used to = reserve space in a binary file for pointers and indexes to be added later o= n.

--
Website: http://h= allambaker.com/
--001a11c237c40627ed04dd68c452-- From hallam@gmail.com Thu May 23 15:13: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 3DE8521F905F for ; Thu, 23 May 2013 15:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.151 X-Spam-Level: X-Spam-Status: No, score=-3.151 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, 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 BmsyXRtJtKwv for ; Thu, 23 May 2013 15:13:08 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id B9C2A21F9838 for ; Thu, 23 May 2013 14:28:53 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id x10so3898095lbi.7 for ; Thu, 23 May 2013 14:28:52 -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=6lcT0ps18CFlT1XduxiZPNDzD36oSFV9s8bAboe00Ew=; b=H3HR+MN3nW1pzDwlANsb/GEz4skd5ZfdqLqi0EpKoctjpIKQqTIUJs22HQHBFrtPEh qYRekehqfGJXG9Egm6VJ3BK+xeAgLbNq2f+h5zTuvyEDA1GP8Jnq34YQpgoWeJ+qy+ON 25uNqGVuOooDsSPryF2CHgRcdiOwwWpoxJTBhOii4I97p5ee0xwApOXSQN7fCKwCVcJZ krRJBhRiZVEVHxmXgsr/T92+grCYh970yOMc5c6RHLP2cFvNfD1oQOX3JHotI6HDgSKP HSrjeeIKIDwNuP5wjyUkvIB87AbBTSnzALgrbDIBheimFgcNgPScCSNOcX6fkaUCosYz H6ew== MIME-Version: 1.0 X-Received: by 10.152.121.73 with SMTP id li9mr7083791lab.18.1369344532668; Thu, 23 May 2013 14:28:52 -0700 (PDT) Received: by 10.112.200.169 with HTTP; Thu, 23 May 2013 14:28:52 -0700 (PDT) In-Reply-To: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <142483A4-2E80-43F1-B3BE-B5B01650BB8F@tzi.org> <84317001-DB56-4DBE-9D1E-A4E605BC07A0@tzi.org> <3367FDBE-8268-4F3A-85CF-94D64BF60FCC@vpnc.org> <6C80DF35-E465-4107-B2B5-34D8D1C2F2CF@vpnc.org> Date: Thu, 23 May 2013 17:28:52 -0400 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: multipart/alternative; boundary=089e0117744d71e54504dd695e28 Cc: Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 22:13:23 -0000 --089e0117744d71e54504dd695e28 Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 23, 2013 at 4:13 PM, Nico Williams wrote: > On Thu, May 23, 2013 at 2:24 PM, Paul Hoffman > wrote: > > On May 23, 2013, at 11:35 AM, James M Snell wrote: > > > >> That's well and good, from everything I've seen so far in this thread, > >> the collective majority opinion can be summarized as "Ugh... Groan.. > >> Another one? Really?" > > > > Just a note that this is one of the only ones that people are groaning > about that has an Internet Draft and might go through the IETF consensus > process. Carsten and I (maybe naively) thought that doing this in this > environment, instead of say posting ephemeral specs on a web page and not > having it be clear where the community fit it, was a good thing. > > There's a huge world outside the IETF. The folks working on Simple > and BSON, to take two examples, may not care about bringing their work > to us, but then, they may also be annoyed by our blindsiding them with > a standards-track binary JSON (I know, CBOR's a superset) encoding > that's not interoperable with theirs. > > In particular, if there's wide deployment of one of them, why > shouldn't we pick one of them? > > Should we not invite the wider JSON community to this discussion? > BSON is the binary format used by MongoDB which is widely used in network projects and especially Web-ish, JSON projects. I don't particularly like their design choices but I don't find any of them terrible. -- Website: http://hallambaker.com/ --089e0117744d71e54504dd695e28 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 23, 2013 at 4:13 PM, Nico Williams <nic= o@cryptonector.com> wrote:
On Thu, May 23, 2013 at 2:= 24 PM, Paul Hoffman <paul.hoffm= an@vpnc.org> wrote:
> On May 23, 2013, at 11:35 AM, James M Snell &l= t;jasnell@gmail.com> wrote:
>
>> That's well and good, from everything I've seen so far in = this thread,
>> the collective majority opinion can be summarized as "Ugh... = Groan..
>> Another one? Really?"
>
> Just a note that this is one of the only ones that people are groaning= about that has an Internet Draft and might go through the IETF consensus p= rocess. Carsten and I (maybe naively) thought that doing this in this envir= onment, instead of say posting ephemeral specs on a web page and not having= it be clear where the community fit it, was a good thing.

There's a huge world outside the IETF. =A0The folks working on Si= mple
and BSON, to take two examples, may not care about bringing their work
to us, but then, they may also be annoyed by our blindsiding them with
a standards-track binary JSON (I know, CBOR's a superset) encoding
that's not interoperable with theirs.

In particular, if there's wide deployment of one of them, why
shouldn't we pick one of them?

Should we not invite the wider JSON community to this discussion?

BSON is the binary format used by MongoDB = which is widely used in network projects and especially Web-ish, JSON proje= cts.=A0

I don't particularly like their design = choices but I don't find any of them terrible.=A0

<= /div>--
Website: http://hallambaker= .com/
--089e0117744d71e54504dd695e28-- From sm@elandsys.com Thu May 23 15:14: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 6242221F983A; Thu, 23 May 2013 15:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 KxkYBpRtD8s6; Thu, 23 May 2013 15:13:55 -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 3363C21F983F; Thu, 23 May 2013 14:29:26 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.155.5]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r4NLT3sq023426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 May 2013 14:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1369344557; bh=As6zUMYor+zZ+QsTkoyPdRn0q9Mxwl/6xDreWazDfxs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1lpVVjwEEkAuyz9dQqe0/bGGLykFYMdtfLCQO6MinKJ9HifKgjjTSqnYHBbwAYxhI IbLhSnELESL1RKe2Ls2/43Yq7OEWsGpMOUO/zfOpWvu39eiO7PaxX2nqyOv2Gqk5Ft WPlEOegQotWcd0QM9xWVYzmutg502dL/4ZF4n4qc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1369344557; i=@elandsys.com; bh=As6zUMYor+zZ+QsTkoyPdRn0q9Mxwl/6xDreWazDfxs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ilUG9Cee+Flp6pMGrsWke0E/U909+4+H+95eR5g9UA/weQND+S7h1oZWLV99qFa2x KhXsCcj71AsG70Hg4RvzKQ6494v9KnDAwIy4r1kNhNRuvgclrZYXLUa5UI8GPV7Aj9 5tuaNLfWIz41mZn6//T3NIEUzMY5ZkAKJIDDp7bk= Message-Id: <6.2.5.6.2.20130523142426.0daf25c8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 23 May 2013 14:28:31 -0700 To: Cyrus Daboo From: S Moonesamy In-Reply-To: <1778285.8glKQALeLt@scott-latitude-e6320> References: <6.2.5.6.2.20130429065657.0d392368@elandnews.com> <1778285.8glKQALeLt@scott-latitude-e6320> 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, apps-discuss@ietf.org Subject: Re: [apps-discuss] [spfbis] APPSDIR review of draft-ietf-spfbis-4408bis-14.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, 23 May 2013 22:14:06 -0000 Hi Cyrus, At 13:22 23-05-2013, Scott Kitterman wrote: >On Monday, April 29, 2013 07:05:57 AM S Moonesamy wrote: > > >Document: draft-ietf-spfbis-4408bis-14.txt > > >Title: Sender Policy Framework (SPF) for > > >Authorizing Use of Domains in Email, Version 1 > > >Reviewer: Cyrus Daboo > > >Review Date: 2013-04-29 > > > > > >Summary: This draft is almost ready for > > >publication as an RFC, subject to some minor issues that should be > > >resolved. > > > > > >Overview: This document is an update to RFC4408 > > >that seeks to upgrade the specification from > > >experimental status, clarifying a number of > > >issues in the original specification, providing > > >in depth detail of actual deployment experience, > > >and documenting various extensions now in common > > >use. The new draft achieves these aims and > > >provides a good reference for implementors. > > > > > >Major Issues: None > > > > > >Minor Issues: > > > Section 4.6.1 ABNF terms "A / MX / PTR > > > / IP4 / IP6" are upper case but terminal terms > > > are lower case in Section 5 (but uppercase in > > > Appendix A). Looks like these need fixing in Section 5. > >I think we should lower case them all and I've done that for the >next revision >in both 4.6.1 and Appendix A. It makes things more consistent overall. > > > > Section 6.2 Paragraph 6 There is a > > > > > > reference to Section 2.6.4 but that section > > > does not contain anything relevant. Either > > > remove the reference or point to a relevant section. > >Corrected to point to 8.4. This was a casualty of a reorganizing the >document. > > > > Section 7.1 Paragraph 2 States "subject > > > > > > to LDH rule" - that needs a reference to > > > RFC3696 Section 2 (reference was in RFC 4408). > >Is this not sufficient: > > The "toplabel" construction is subject to the LDH rule plus > additional top-level domain (TLD) restrictions. See Section 2 of > [RFC3696] for background. > > > >Section 11.3 Why no mention of DNSSEC as a way > > >to alleviate this issue? Has anyone been using > > >DNSSEC with SPF? If not, why not? > >I think this is covered by the reference to RFC 3833, but if someone has a >suggestion for more explicit text, please provide it. > > > >Nits: > > > Section 2.4 (argument list) and Section > > > > > > 4.1 appear to duplicate similar information - > > > consider removing the list of args in Section 2.4 and add a reference to > > > $4.1.> > >Done. > > > > Section 2.5 Paragraph 2 First part of > > > > > > sentence hard to read - break it up with commas. > >I agree with the comment, but I'm not sure where to put them without changing >the meaning. > > > > Section 2.6 and Section 8 appear to > > > > > > duplicate a lot of similar information. Please > > > consider trimming down Section 2.6 and have it > > > refer to Section 8 for full details. > >Done. > > > > Section 3.5 Paragraph 1 Has the word > > > > > > "discouraged". Shouldn't this use a 2119 term, e.g.: "NOT RECOMMENDED"? > >Probably, but it is discouraged in RFC 4408 and we're trying to be careful >about introducing new 2119 requirements. > > > > Section 6.1 Paragraph 1 Remove second > > > sentence - pretty much the same as the first one. > >Done. > > > > Section 6.2 Paragraph 4 Put exp in double-quotes. > >Done. > > > > Section 10 Paragraph 1 SHOULD - in this > > > context it is not really appropriate to use a 2119 term. Please rephrase. > >Changed. > > > > Various places: permerror is sometimes > > > used without double-quotes around it - I think > > > all uses should have double-quotes. > >Changed. Do the above comments address your AppsDir review ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09353.html )? Thanks, S. Moonesamy (as document shepherd) From paul.hoffman@vpnc.org Thu May 23 15:36:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0FA21F9633 for ; Thu, 23 May 2013 15:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 18wgt4wvnMWR for ; Thu, 23 May 2013 15:36:21 -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 26AF621F9820 for ; Thu, 23 May 2013 15:12:55 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4NMCr3Q011182 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 May 2013 15:12:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Thu, 23 May 2013 15:12:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <142483A4-2E80-43F1-B3BE-B5B01650BB8F@tzi.org> <84317001-DB56-4DBE-9D1E-A4E605BC07A0@tzi.org> <3367FDBE-8268-4F3A-85CF-94D64BF60FCC@vpnc.org> <6C80DF35-E465-4107-B2B5-34D8D1C2F2CF@vpnc.org> To: Nico Williams X-Mailer: Apple Mail (2.1503) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 May 2013 22:36:22 -0000 On May 23, 2013, at 1:13 PM, Nico Williams = wrote: > On Thu, May 23, 2013 at 2:24 PM, Paul Hoffman = wrote: >> On May 23, 2013, at 11:35 AM, James M Snell = wrote: >>=20 >>> That's well and good, from everything I've seen so far in this = thread, >>> the collective majority opinion can be summarized as "Ugh... Groan.. >>> Another one? Really?" >>=20 >> Just a note that this is one of the only ones that people are = groaning about that has an Internet Draft and might go through the IETF = consensus process. Carsten and I (maybe naively) thought that doing this = in this environment, instead of say posting ephemeral specs on a web = page and not having it be clear where the community fit it, was a good = thing. >=20 > There's a huge world outside the IETF. The folks working on Simple > and BSON, to take two examples, may not care about bringing their work > to us, but then, they may also be annoyed by our blindsiding them with > a standards-track binary JSON (I know, CBOR's a superset) encoding > that's not interoperable with theirs. Sure. The many communities don't seem to be talking to each other. > In particular, if there's wide deployment of one of them, why > shouldn't we pick one of them? If the design goals of any of them don't align with the others, why = should we pick just one? As a specific example, some of the many formats = are optimized for message size at the expense of extensibility, while = others are optimized for extensibility at the expense of message size. = Why should only one of those be forced on everyone else? > Should we not invite the wider JSON community to this discussion? We should indeed. That's why Carsten and I did this as an Internet Draft = and brought it here instead of grabbing some domain name and getting = just our friends involved. --Paul Hoffman= From superuser@gmail.com Thu May 23 15:44: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 0ECE021F9403 for ; Thu, 23 May 2013 15:44:16 -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 HxnY+qYklL5G for ; Thu, 23 May 2013 15:44:13 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECBF21F89D5 for ; Thu, 23 May 2013 15:40:42 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id n12so2541915wgh.24 for ; Thu, 23 May 2013 15:40:42 -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=/ZaAj6Lt2TUi7p+MWOCpsih3HVtKhAWZtnzJdUBJZqY=; b=P6wffXx98lzQ6YVFxkY1AQ+d7O9TFV6e7irmB+DNaCFjNquuNvNfduw14cIVsCdpJU TlWnGUCMp1AIX7G+UqZdCy6rGdL91vDmjKiFKKwtB5OGxvXqqZJICUTuNh5UFpTICvo7 aLaREBmJIVnkDIns+Xwy/WNlPx/ULGSK61kWhcJfP3hTjCsfRCVTJyCjM9TWOz0m5r5J X7ZtXbiH67DxaI6aHOJCLltazhiF8yxoxtA1zrlUfBQMP9q7s0+XJoZB4BYwBh1O6C6a Gv/1eGaJUJUH8KzPuEX5oTuZ8/CnlGPFNa8DS8/yKdtETZZbb+2YXQmTm2ddRT2LHJvg w0vg== MIME-Version: 1.0 X-Received: by 10.180.37.243 with SMTP id b19mr28780519wik.12.1369348842093; Thu, 23 May 2013 15:40:42 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Thu, 23 May 2013 15:40:41 -0700 (PDT) In-Reply-To: References: <20130523154124.25978.qmail@joyce.lan> <519E3A24.3090502@bbiw.net> Date: Thu, 23 May 2013 15:40:41 -0700 Message-ID: From: "Murray S. Kucherawy" To: John R Levine Content-Type: multipart/alternative; boundary=e89a8f646db54e826204dd6a5f46 Cc: Dave Crocker , IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 22:44:21 -0000 --e89a8f646db54e826204dd6a5f46 Content-Type: text/plain; charset=ISO-8859-1 Yep, oversight from when I removed the "/". I'll fix it now in source and post a new version since my shepherd also found a few nits during his review. On Thu, May 23, 2013 at 10:15 AM, John R Levine wrote: > authres-header = "Authentication-Results:" [CFWS] authserv-id >>>> [ [CFWS] authres-version ] >>>> >>> >>> You're right. Adding the brackets is clearly a mistake since it makes >>> it impossible to tell where the authserv-id ends and the >>> authres-version starts. >>> >> > Authentication-Results: foobar1 ; ... > > Is that authserv-id foobar1, or authserv-id foobar and authres-version 1 ? > > R's, > John > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --e89a8f646db54e826204dd6a5f46 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yep, oversight from when I removed the "/".=A0 I= 'll fix it now in source and post a new version since my shepherd also = found a few nits during his review.

On Thu, May 23, 2013 at 10:15 AM, John R Levine = <= johnl@taugh.com> wrote:
authres-header =3D "Authentication-Results:" [CFWS] authserv-id =A0 =A0 =A0 =A0 [ [CFWS] authres-version ]

You're right. Adding the brackets is clearly a mistake since it makes it impossible to tell where the authserv-id ends and the
authres-version starts.

Authentication-Results: foobar1 ; ...

Is that authserv-id foobar1, or authserv-id foobar and authres-version 1 ?<= br>
R's,
John
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--e89a8f646db54e826204dd6a5f46-- From internet-drafts@ietf.org Thu May 23 15:46: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 767BB21F8746; Thu, 23 May 2013 15:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.130, 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 cCYjWPzgDPp4; Thu, 23 May 2013 15:46:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8238721F9616; Thu, 23 May 2013 15:45:04 -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.50 Message-ID: <20130523224504.30938.6668.idtracker@ietfa.amsl.com> Date: Thu, 23 May 2013 15:45:04 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 22:46:42 -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 : Message Header Field for Indicating Message Authenticati= on Status Author(s) : Murray S. Kucherawy Filename : draft-ietf-appsawg-rfc5451bis-05.txt Pages : 42 Date : 2013-05-23 Abstract: This document specifies a header field for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users, or make sorting and filtering decisions. This document is a candidate for Internet Standard status. [RFC Editor: Please delete this notation, as I imagine it will be indicated some other way.] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-rfc5451bis-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-rfc5451bis-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu May 23 15:46: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 4E29E21F87D1 for ; Thu, 23 May 2013 15:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.368 X-Spam-Level: X-Spam-Status: No, score=-101.368 tagged_above=-999 required=5 tests=[AWL=-0.987, BAYES_00=-2.599, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219, 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 8io7038YBBJ4; Thu, 23 May 2013 15:46:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D49D421F962C; Thu, 23 May 2013 15:45:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-rfc5451bis@tools.ietf.org, apps-discuss@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130523224504.30938.89811.idtracker@ietfa.amsl.com> Date: Thu, 23 May 2013 15:45:04 -0700 Subject: [apps-discuss] New Version Notification - draft-ietf-appsawg-rfc5451bis-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 22:46:46 -0000 A new version (-05) has been submitted for draft-ietf-appsawg-rfc5451bis: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-rfc5451bis-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-rfc5451bis-05 IETF Secretariat. From James.H.Manger@team.telstra.com Thu May 23 17:33: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 9F9A921F9017 for ; Thu, 23 May 2013 17:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.531 X-Spam-Level: X-Spam-Status: No, score=-0.531 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUtsBkw9hxOR for ; Thu, 23 May 2013 17:33:18 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6A821F9019 for ; Thu, 23 May 2013 17:33:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,730,1363093200"; d="scan'208";a="131840555" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipocni.tcif.telstra.com.au with ESMTP; 24 May 2013 10:33:15 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7084"; a="139007974" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipccni.tcif.telstra.com.au with ESMTP; 24 May 2013 10:33:15 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Fri, 24 May 2013 10:33:14 +1000 From: "Manger, James H" To: Paul Hoffman , Carsten Bormann Date: Fri, 24 May 2013 10:33:13 +1000 Thread-Topic: CBOR: convert CBOR bignum to base64url JSON string Thread-Index: Ac5YFkaG6fHGfOprStm77b2/e5M1FQ== Message-ID: <255B9BB34FB7D647A506DC292726F6E1151A9721A1@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "apps-discuss@ietf.org Discuss" Subject: [apps-discuss] CBOR: convert CBOR bignum to base64url JSON string X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2013 00:33:24 -0000 QSBtaW5vciAobm9uLWNvbnRyb3ZlcnNpYWw/KSBzdWdnZXN0ZWQgY2hhbmdlIGZvciBkcmFmdC1i b3JtYW5uLWNib3I6DQoNClNlY3Rpb24gNC4xLiAiQ29udmVydGluZyBGcm9tIENCT1IgdG8gSlNP TiIgMTF0aCBkb3QgcG9pbnQgc2F5czoNCg0KICBvICBBIGJpZ251bSAobWFqb3IgdHlwZSA3LCB0 YWcgdmFsdWUgOCBvciA5KSBiZWNvbWVzIGEgSlNPTiBudW1iZXIuDQoNClRoaXMgbWlnaHQgYmUg cmlnaHQgaW4gdGhlb3J5LCBidXQgSSBkb24ndCB0aGluayBpdCBpcyBpbiBwcmFjdGljZS4NClBy ZXN1bWFibHkgYSBiaWdudW0gd2FzIHVzZWQgYmVjYXVzZSB0aGUgdmFsdWUgKG9yIG90aGVyIGV4 cGVjdGVkIHZhbHVlIGZvciB0aGUgc2FtZSBmaWVsZCkgaXMgdG9vIGxhcmdlIGZvciBub3JtYWwg KDMyLWJpdCwgNjQtYml0KSBudW1iZXIgdHlwZXMsIHdoaWNoIGFyZSB0aGUgdHlwZXMgbWFueSBp bXBsZW1lbnRhdGlvbnMgdXNlIHJlcHJlc2VudCBhIEpTT04gbnVtYmVyLiBIZW5jZSB0aGV5IHdp bGwgZmFpbCB3aXRoIGEgYmlnbnVtLg0KDQpJIHN1Z2dlc3QgY29udmVydGluZyBhIGJpZ251bSB0 byBhIGJhc2U2NHVybCBlbmNvZGluZyAod2l0aG91dCBwYWRkaW5nKSBpbiBhIEpTT04gc3RyaW5n LiBUaGlzIGlzIHdoYXQgeW91IGdldCBpZiB0aGUgcG9zaXRpdmUgYmlnbnVtIHRhZyB3YXMgaWdu b3JlZCBhbmQgeW91IGp1c3QgcHJvY2Vzc2VkIHRoZSBieXRlIHN0cmluZyB0aGF0IGZvbGxvd2Vk LiBGb3IgYSBuZWdhdGl2ZSBiaWdudW0gc3RpY2sgIi0iIGJlZm9yZSB0aGUgYmFzZTY0dXJsIGVu Y29kaW5nLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQo= From markus.lanthaler@gmx.net Thu May 23 19:15: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 0A1D321F9434 for ; Thu, 23 May 2013 19:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgDlUdiAyJFY for ; Thu, 23 May 2013 19:15:38 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id EBDD921F90D2 for ; Thu, 23 May 2013 19:15:37 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.20]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MgaEb-1UrTEl26kh-00Nzve for ; Fri, 24 May 2013 04:15:36 +0200 Received: (qmail invoked by alias); 24 May 2013 02:15:36 -0000 Received: from 67.23.197.94.freewirebroadband.com (EHLO Vostro3500) [67.23.197.94] by mail.gmx.net (mp020) with SMTP; 24 May 2013 04:15:36 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX180L5QNxys0NxzHXr+2hz+DvLuOgn0qxfqIYXwacO IniwSwUrr8s4DO From: "Markus Lanthaler" To: "'Murray S. Kucherawy'" References: <516e8a54.45f7440a.7dcc.1253SMTPIN_ADDED_BROKEN@mx.google.com> <516f06c9.c1c20e0a.46f3.ffffb0bfSMTPIN_ADDED_BROKEN@mx.google.com> <51782a0a.21f2440a.747e.5f13SMTPIN_ADDED_BROKEN@mx.google.com> <5182b488.c4d60e0a.1ff8.0d8cSMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Thu, 23 May 2013 19:15:33 -0700 Message-ID: <003b01ce5824$94973ed0$bdc5bc70$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5WdqOHFEprQlH8Qd+ci+IJhWdpdgBrPjrw Content-Language: de X-Y-GMX-Trusted: 0 Cc: 'Barry Leiba' , 'IETF Apps Discuss' Subject: Re: [apps-discuss] FW: New Version Notification for draft-lanthaler-profile-registry-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 02:15:44 -0000 On Tuesday, May 21, 2013 3:58 PM, Murray S. Kucherawy wrote: > Hi Markus, sorry for the delayed reply. No problem. I have been quite busy with other things myself as well. > On Thu, May 2, 2013 at 11:46 AM, Markus Lanthaler > > Thanks for your your support Dave. > > > > Barry, Murray: How do we proceed? Is there anything I can/should > > do at this point? > > There hasn't been much expression of interest in supporting this > document in terms of reviews. Only one person other than you > committed to doing so, though a couple of people did say they felt > this was procedurally the right place to do the work. Yes. Unfortunately that's true. If I understood Barry correctly, the alternative would be to take the URN sub-namespace out and just request the creation of the registry which could be done without the WG adopting it, right? > I'll pose the question again: Does the WG feel that this is something > we should process here? Are there people (other than Dave Cridland) > willing to commit time to doing reviews and commenting? Maybe it helps if I quickly sum up what this I-D is about. First of all, this I-D establishes a registry for profile URIs as defined in RFC6906. Since profile IRIs don't have to be dereferenceable I think it makes sense to establish a registry which can be used to locate the specification defining a specific profile URI. The second thing this I-D does (and that's the reason why it needs to be adopted by the WG) is to reserve a IETF URN sub-namespace (urn:ietf:params:profile) that can be used in the future to define profile URIs in RFCs. Those URIs would look as follows: urn:ietf:params:profile:example Thanks, Markus -- Markus Lanthaler @markuslanthaler From fgaliegue@gmail.com Thu May 23 21:33: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 50E4E21F9732 for ; Thu, 23 May 2013 21:33:48 -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 I1+jcUfS1S4q for ; Thu, 23 May 2013 21:33:44 -0700 (PDT) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by ietfa.amsl.com (Postfix) with ESMTP id AA91521F972F for ; Thu, 23 May 2013 21:33:43 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id e49so2233559eek.19 for ; Thu, 23 May 2013 21:33:42 -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=GIWd6r+0NYaDg6nYGN2/W0Ogr/JT61KyHAFSmAptrs0=; b=S1HWaSzlm9Kf0vHVlPDW+f3aAxCFOWyIEJ6QZgFeos8j53kXV5faTrqXFGGq+r3JTz NmkPmY+SWmnPsu4q+m9gGk/AHvmOtjERhrCM1rCmp+wXj1iExSF/ZPm7WMQVyckgKAiU vx1joigy/kHtDKS/wF1hB536b1ZoI2xlsJH9KBHuhxwiV+qihMoeFwJoXIPTrxGgto3M 45DECN8HlJfEJQDcmDfoWJgkJ6JEKKly4Xd74hZjzXoUL5RgBO0QXyG9Mn9ZzHM3tJuw phjJPcV/9m//9uBj1EGxmmjPHHFpXknCEaz9OkrV3jx3LO1RmDJuqmSrohQUNSfThTXk pmTw== MIME-Version: 1.0 X-Received: by 10.14.172.195 with SMTP id t43mr38609400eel.34.1369370022598; Thu, 23 May 2013 21:33:42 -0700 (PDT) Received: by 10.15.55.136 with HTTP; Thu, 23 May 2013 21:33:42 -0700 (PDT) In-Reply-To: <519E7346.6060909@att.com> References: <519E7346.6060909@att.com> Date: Fri, 24 May 2013 06:33:42 +0200 Message-ID: From: Francis Galiegue To: Tony Hansen Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] And another question X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2013 04:33:48 -0000 On Thu, May 23, 2013 at 9:51 PM, Tony Hansen wrote: > On 5/23/2013 12:59 PM, Francis Galiegue wrote: >> Another question is about handling empty _keys_ in an associative >> array. Is this legal at all? Empty values are allowed, they obviously >> have a use (a query parameter can be empty for instance), but what >> about (written as a JSON Object): >> >> { >> "foo": "", >> "": "bar" >> } >> >> ? > > This looks perfectly legal to me. > Yes, it is legal JSON. However, it is hardly of any use in a URI template at all. Query parameter names cannot be empty, domain name components ditto, others. Bah. -- Francis Galiegue, fgaliegue@gmail.com JSON Schema in Java: http://json-schema-validator.herokuapp.com From cabo@tzi.org Thu May 23 23:15: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 2A8B021F8F1E for ; Thu, 23 May 2013 23:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.217 X-Spam-Level: X-Spam-Status: No, score=-106.217 tagged_above=-999 required=5 tests=[AWL=0.032, 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 B42HtlQLlXmc for ; Thu, 23 May 2013 23:15:20 -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 02B6021F85F4 for ; Thu, 23 May 2013 23:15:19 -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 r4O6FBGR017668; Fri, 24 May 2013 08:15:11 +0200 (CEST) Received: from [192.168.217.105] (p54891C3A.dip0.t-ipconnect.de [84.137.28.58]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 289353248; Fri, 24 May 2013 08:15:11 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151A9721A1@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 24 May 2013 08:15:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <255B9BB34FB7D647A506DC292726F6E1151A9721A1@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1503) Cc: Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] CBOR: convert CBOR bignum to base64url JSON string X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2013 06:15:26 -0000 On May 24, 2013, at 02:33, "Manger, James H" = wrote: > A minor (non-controversial?) suggested change for draft-bormann-cbor: >=20 > Section 4.1. "Converting =46rom CBOR to JSON" 11th dot point says: >=20 > o A bignum (major type 7, tag value 8 or 9) becomes a JSON number. >=20 > This might be right in theory, but I don't think it is in practice. > Presumably a bignum was used because the value (or other expected = value for the same field) is too large for normal (32-bit, 64-bit) = number types, which are the types many implementations use represent a = JSON number. Hence they will fail with a bignum. That is a very good point. I haven't done a survey of JSON implementations how they handle large = numbers that look like integers. Of those for platforms that don't have bignums, I would expect many of = them to create a double-precision float for large numbers. =20 This doesn't fail, but loses precision. > I suggest converting a bignum to a base64url encoding (without = padding) in a JSON string. This is what you get if the positive bignum = tag was ignored and you just processed the byte string that followed. = For a negative bignum stick "-" before the base64url encoding. That is certainly good advice if the bignum was, say, a value from an = ECDSA signature, where losing precision destroys the utility. Less so if it was the US national debt (well, for a few more weeks, that = will still fit in a 64-bit number :-). Right now we have limited experience what people would be using bignums = for in a JSON-interfacing application. The conversion rules we set up will shape that usage, so for me the = question really is what usage of bignums do we want to encourage. (E.g., I think it would have been a mistake to put that ECDSA signature = value in a bignum in the first place. =20 But X9.62 did exactly this, in ASN.1, which doesn't even have unsigned = numbers.) Outside of JSON-interfacing applications, the area of application of = bignums is much clearer. BTW, the "-" convention you propose doesn't work very well with = base64url. (This is the first example I've seen in a long while where base64 would = actually work better than base64url.) But given the semantics of the byte string in CBOR, it should be a "~" = anyway, and that is free in base64url. So how would you plan to use bignums in JSON-interfacing CBOR = applications? For crypto material like ECDSA values? Gr=FC=DFe, Carsten From James.H.Manger@team.telstra.com Thu May 23 23:55: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 3B30021F93F0 for ; Thu, 23 May 2013 23:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.555 X-Spam-Level: X-Spam-Status: No, score=-0.555 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkaZCVGpv8zU for ; Thu, 23 May 2013 23:55:38 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id C836F21F93BA for ; Thu, 23 May 2013 23:55:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,732,1363093200"; d="scan'208";a="131908729" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipocni.tcif.telstra.com.au with ESMTP; 24 May 2013 16:55:36 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7084"; a="135571065" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcbni.tcif.telstra.com.au with ESMTP; 24 May 2013 16:55:36 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Fri, 24 May 2013 16:55:36 +1000 From: "Manger, James H" To: Carsten Bormann Date: Fri, 24 May 2013 16:55:35 +1000 Thread-Topic: CBOR: convert CBOR bignum to base64url JSON string Thread-Index: Ac5YRhS00ewFni5RQceZ1EZhuOxiUwAArjeQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1151A972B55@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1151A9721A1@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] CBOR: convert CBOR bignum to base64url JSON string X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2013 06:55:44 -0000 PiBTbyBob3cgd291bGQgeW91IHBsYW4gdG8gdXNlIGJpZ251bXMgaW4gSlNPTi1pbnRlcmZhY2lu ZyBDQk9SDQo+IGFwcGxpY2F0aW9ucz8gIEZvciBjcnlwdG8gbWF0ZXJpYWwgbGlrZSBFQ0RTQSB2 YWx1ZXM/DQoNClllcywgcHVibGljIGtleSBjcnlwdG8gcXVhbnRpdGllcy4NCg== From hallam@gmail.com Fri May 24 04:59:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C077521F940B for ; Fri, 24 May 2013 04:59:35 -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 O4kbT9yCpUeP for ; Fri, 24 May 2013 04:59:34 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0239121F938E for ; Fri, 24 May 2013 04:59:33 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id lx15so4385277lab.38 for ; Fri, 24 May 2013 04:59:32 -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=tdl/hLFWc7ZGJHNj6YxBfz7f1STWrcp0SzD/nesSZuo=; b=EjyR15tsnpeT7n8YgKqHvSijCkifJam+WlctqU5NhPp5aVy2Ekm25tq+O09+k8xt7A ErTBt+GtnxfescgrB4h0oYnBF1nb5u+csyNLQ/lduX0cAu405hOh1whOqH5LC8lpjkwu JIjBFAwOb7tQBJCpwXkcZhvL7UT9IgmtROo13DCQmmvjVK0NpKMMzzD4vXVznwXeC0BP Lu0C1ItpGmkodPXNWDJRjPM8EqxVP9Kzw+9tdJxhD7Bt66nZZpGkqMAXtiTEYVLnoo6Y rs9/chlsUsc6i1Q/SpLCDay7C6NpzoLZPvrpOtMKf3G7nvmtjHiTzwLk9jOeSktFmWXy 5FZQ== MIME-Version: 1.0 X-Received: by 10.112.73.135 with SMTP id l7mr8804451lbv.42.1369396772862; Fri, 24 May 2013 04:59:32 -0700 (PDT) Received: by 10.112.200.169 with HTTP; Fri, 24 May 2013 04:59:32 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1151A9721A1@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 24 May 2013 07:59:32 -0400 Message-ID: From: Phillip Hallam-Baker To: Carsten Bormann Content-Type: multipart/alternative; boundary=14dae93d8eac3402c704dd75889d Cc: Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] CBOR: convert CBOR bignum to base64url JSON string X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2013 11:59:35 -0000 --14dae93d8eac3402c704dd75889d Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 24, 2013 at 2:15 AM, Carsten Bormann wrote: > On May 24, 2013, at 02:33, "Manger, James H" < > James.H.Manger@team.telstra.com> wrote: > > > A minor (non-controversial?) suggested change for draft-bormann-cbor: > > > > Section 4.1. "Converting From CBOR to JSON" 11th dot point says: > > > > o A bignum (major type 7, tag value 8 or 9) becomes a JSON number. > > > > This might be right in theory, but I don't think it is in practice. > > Presumably a bignum was used because the value (or other expected value > for the same field) is too large for normal (32-bit, 64-bit) number types, > which are the types many implementations use represent a JSON number. Hence > they will fail with a bignum. > > That is a very good point. > I haven't done a survey of JSON implementations how they handle large > numbers that look like integers. > Of those for platforms that don't have bignums, I would expect many of > them to create a double-precision float for large numbers. > This doesn't fail, but loses precision. Trying to do public key crypt afterwards is not going to work very well. Other than Mathematica, I really cant think of any platform I would expect to be able to start reading an integer and realize that it needs to be treated as a bignum when it goes over 64 bits. Like many parts of the JSON syntax that is something that the specification demands but implementations are likely to vary on. The idea that JSON can never change by an iota seems rather silly. The specification is not really complete. Where difficult parts come up they are ignored and so we don't know how implementations are expected to behave for overflow or for NaN values. Addressing such concerns is precisely what is expected when a spec enters IETF process. What are JSON parsers expected to do when they come across a token litteral they don't understand? > > I suggest converting a bignum to a base64url encoding (without padding) > in a JSON string. This is what you get if the positive bignum tag was > ignored and you just processed the byte string that followed. For a > negative bignum stick "-" before the base64url encoding. > > That is certainly good advice if the bignum was, say, a value from an > ECDSA signature, where losing precision destroys the utility. > Less so if it was the US national debt (well, for a few more weeks, that > will still fit in a 64-bit number :-). > If you then try to maintain the result by adding a hundred dollars every X milliseconds then the count is never going to increase and you will #fail. Hey, we have just found the way to fix the national debt... -- Website: http://hallambaker.com/ --14dae93d8eac3402c704dd75889d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, May 24, 2013 at 2:15 AM, Carsten Bormann = <cabo@tzi.org><= /span> wrote:
On May 24, 2013, at 02:33,= "Manger, James H" <James.H.Manger@team.telstra.com> wrote:

> A minor (non-controversial?) suggested change for draft-bormann-cbor:<= br> >
> Section 4.1. "Converting From CBOR to JSON" 11th dot point s= ays:
>
> =A0o =A0A bignum (major type 7, tag value 8 or 9) becomes a JSON numbe= r.
>
> This might be right in theory, but I don't think it is in practice= .
> Presumably a bignum was used because the value (or other expected valu= e for the same field) is too large for normal (32-bit, 64-bit) number types= , which are the types many implementations use represent a JSON number. Hen= ce they will fail with a bignum.

That is a very good point.
I haven't done a survey of JSON implementations how they handle large n= umbers that look like integers.
Of those for platforms that don't have bignums, I would expect many of = them to create a double-precision float for large numbers.
This doesn't fail, but loses precision.

Trying to do public key crypt afterwards is not going to work very w= ell.

Other than Mathematica, I really = cant think of any platform I would expect to be able to start reading an in= teger and realize that it needs to be treated as a bignum when it goes over= 64 bits.

Like many parts of the JSON syntax that is = something that the specification demands but implementations are likely to = vary on.


The idea= that JSON can never change by an iota seems rather silly. The specificatio= n is not really complete. Where difficult parts come up they are ignored an= d so we don't know how implementations are expected to behave for overf= low or for NaN values.

Addressing such concerns is precisely what = is expected when a spec enters IETF process.


What are JSON parsers expected to do when they = come across a token litteral they don't understand?


=A0
=
> I suggest converting a bignum to a base64url encoding (without padding= ) in a JSON string. This is what you get if the positive bignum tag was ign= ored and you just processed the byte string that followed. For a negative b= ignum stick "-" before the base64url encoding.

That is certainly good advice if the bignum was, say, a value from an= ECDSA signature, where losing precision destroys the utility.
Less so if it was the US national debt (well, for a few more weeks, that wi= ll still fit in a 64-bit number :-).

If you then try to maintain the result by adding a hundred dollars ever= y X milliseconds then the count is never going to increase and you will #fa= il.

Hey, we have just found the way to fix the = national debt...

=A0

-- =
Website: http://hallambaker.com/
--14dae93d8eac3402c704dd75889d-- From jhildebr@cisco.com Fri May 24 10:02: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 3387F21F8E8F for ; Fri, 24 May 2013 10:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 qorhpjc86TTN for ; Fri, 24 May 2013 10:02:20 -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 AED4E21F8EB1 for ; Fri, 24 May 2013 10:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2709; q=dns/txt; s=iport; t=1369414938; x=1370624538; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Fr1QXt8IHpvPjyHfHQ1U1G8HG1fYBLogH6z0l8EE1wI=; b=DuqSxZ42mAj/I5d79bbg8xPi5jG7ZNx3raBD8WMBjKykyZSzv3BmyHLQ blDbI9uEaAc6+O7gHo6uTxgi0HuSsDnkgfLO9N7bIqR3jehqgiAQO6PfU XfhW5uXsRzfZ+WU5T0aiEgnWlY6laNKFNSl2xtW8b0KqihhvoGxe6CJik Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAecn1GtJV2a/2dsb2JhbABagwjCWoEGFnSCJQEEOjECDBIBCCIUQiUCBAENDQyHeboXjmwxB4JzYQOoe4MPgiY X-IronPort-AV: E=Sophos;i="4.87,736,1363132800"; d="scan'208";a="214700506" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 24 May 2013 17:02:18 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4OH2IfB007781 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 May 2013 17:02:18 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Fri, 24 May 2013 12:02:17 -0500 From: "Joe Hildebrand (jhildebr)" To: Phillip Hallam-Baker , Paul Hoffman Thread-Topic: [apps-discuss] Concise Binary Object Representation (CBOR) Thread-Index: AQHOVvuXjViEyQFpgUacoTb2ksDBA5kSkkeAgAAeFgCAAIvQgIAADVEAgAAK8oCAABH0AIAACBwAgAANpQCAAA3qAIAA+BeA Date: Fri, 24 May 2013 17:02:16 +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.4.130416 x-originating-ip: [10.129.24.242] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2013 17:02:26 -0000 Paul said: >Just a note that this is one of the only ones that people are groaning >about that has an Internet Draft and might go through the IETF consensus >process. Carsten and I (maybe naively) thought that doing this in this >environment, instead of say posting ephemeral > specs on a web page and not having it be clear where the community fit >it, was a good thing. PHB said: >I don't remember you being appointed to address the issue. Who appoints people to do anything at the IETF? MsgPack is one of the best of the formats in this space. When that group was approached with an opportunity to have help standardizing their format, they reacted completely rationally: - What value would having a standard add? We already interop in practice. - Doing anything at the IETF is incredibly painful and slow. See this conversation for an example. - The IETF doesn't have any interesting expertise in this space. - We want to maintain change control in our community. - Why would we want our spec to be ugly like an RFC? (I added that on their behalf, but they would have come to it eventually) I would expect anyone doing work above layer 4 to have similar issues. >Since almost all the response to your proposal has been that people don't >like your design choices, and since you make it abundantly clear that you >are not interested in our input, I can't quite see where a consensus is >going to come. Unless that > is the consensus is that your proposal sucks. I haven't seen that much reaction to the proposal that says it sucks. I've seen a couple of people say "that looks like it would work". I've seen people wonder if it's needed. I've seen proposed changes that were greeted with thoughtful responses. Your assertion that the authors aren't interested in our input seems hyperbolic at best. At worst, it's somewhat hurtful for no apparent reason. There are some things I don't like about it, but it solves one of my biggest problem with JSON, which is sending unformatted octet strings. I'm the mystery person that wrote a JavaScript implementation. Granted, it's in node.js, not for browsers, but I didn't see anything that was un-implementable in a browser that has typed arrays. The biggest PITA was learning enough about half-floats to get them to work. Appendix D now has the information needed so that a later implementer won't have as much of a problem. >My experience of coding ASN.1 DER (in C and javascript) leads me to >reject any counted scheme as a non starter. I've read the whole thread, and didn't see adequate justification for that worldview. Could you reiterate it, please? --=20 Joe Hildebrand From hallam@gmail.com Fri May 24 10:14: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 99B0621F967D for ; Fri, 24 May 2013 10:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, 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 M-Z65Hxp4aPP for ; Fri, 24 May 2013 10:14:30 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id A34E421F961C for ; Fri, 24 May 2013 10:14:29 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id x10so4948864lbi.35 for ; Fri, 24 May 2013 10:14:28 -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=UqRt78CS8vrwVux8oDKsQAcc6+t6rJDPazWyHU8ERDA=; b=AEzXnsFG09FsoN8hTh845Mw03q4l0O6dsqcIrR2iNjYcakFv1G4mBNcpq1JMFP1Nsr heQKgjeCZi3CbWyFFKsAqSVtc1EiZIueVVSdPLu3kOi4ZOMIOkgqKCeQpBFnDfZEc4AI UULyxOYnjx6ugPZOoZPRjJ0hZjZo+EIevRhhhOdrcqd9NyeTAqqfKsPXFNpF1G+gg2fN fcaP1Das/tyaSG6YySaTRLblqaOK+eBL3i5MwZsejlwOWDDH7z2HLjTRJozbUtfI4w74 cpLIAHHdCwdnDJoNGdTGXUs+73+qomHUDgs434ejfGeTNJT/J2yjXLRGlLZY0tmxB76x bQAA== MIME-Version: 1.0 X-Received: by 10.152.116.36 with SMTP id jt4mr4857844lab.57.1369415668532; Fri, 24 May 2013 10:14:28 -0700 (PDT) Received: by 10.112.200.169 with HTTP; Fri, 24 May 2013 10:14:28 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 May 2013 13:14:28 -0400 Message-ID: From: Phillip Hallam-Baker To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=001a11c35372790cd104dd79eec1 Cc: Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2013 17:14:34 -0000 --001a11c35372790cd104dd79eec1 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 24, 2013 at 1:02 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > > >My experience of coding ASN.1 DER (in C and javascript) leads me to > >reject any counted scheme as a non starter. > > I've read the whole thread, and didn't see adequate justification for that > worldview. Could you reiterate it, please? > If you have a counter scheme it is necessary to have the whole data structure in memory to serialize it. Many network applications require the use of an intermediary with a fixed buffer length. Now ASN.1 BER definite length encoding makes matters even worse by specifying lengths in octets rather than the number of entries in an object but the same objection applies. And DER encoding is just plain insane as the lengths of the lengths also varies. A very frequent use case for an encoding format is to take a stream of data of unknown size and package it in real time. For example I would like to be able to take a video stream and encrypt it using JSON encryption and then put a digital signature at the end. BSON does not do that quite like I would like but I can fake the same effect by using an array of Binary rather than one Binary chunk and the same for strings. With a counted representation I can't even fake it. So I won't be able to use CBOR for my applications which all involve cryptography. I can do what I need to do in JSON though. I see no evidence that counts help in the slightest for efficiency. Even DER encoding does not really help. Trying to use a packed encoding as an in-memory encoding is just a bad idea. -- Website: http://hallambaker.com/ --001a11c35372790cd104dd79eec1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, May 24, 2013 at 1:02 PM, Joe Hildebrand (jhildebr)= <jhildebr@cisco.com> wrote:
=

>My experience of coding ASN.1 DER (in C and javascript) leads me to
>reject any counted scheme as a non starter.

I've read the whole thread, and didn't see adequate justifica= tion for that
worldview. =A0Could you reiterate it, please?

If you have a counter scheme it is nec= essary to have the whole data structure in memory to serialize it. Many net= work applications require the use of an intermediary with a fixed buffer le= ngth.

Now ASN.1 BER definite length encoding makes matt= ers even worse by specifying lengths in octets rather than the number of en= tries in an object but the same objection applies. And DER encoding is just= plain insane as the lengths of the lengths also varies.


A very frequent use ca= se for an encoding format is to take a stream of data of unknown size and p= ackage it in real time. For example I would like to be able to take a video= stream and encrypt it using JSON encryption and then put a digital signatu= re at the end.

BSON does not do that quite like I would li= ke but I can fake the same effect by using an array of Binary rather than o= ne Binary chunk and the same for strings.

With a counted representation I can't even fake it. So I won't be a= ble to use CBOR for my applications which all involve cryptography. I can d= o what I need to do in JSON though.


I see no evidence that counts help in the slightest fo= r efficiency. Even DER encoding does not really help.

<= /div>
Trying to use a packed encoding as an in-memory encoding is= just a bad idea.




--
We= bsite: http://hallambaker.com/
--001a11c35372790cd104dd79eec1-- From nico@cryptonector.com Fri May 24 11:05: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 89B9011E80BA for ; Fri, 24 May 2013 11:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.129, 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 EKgv+vTj7Q-f for ; Fri, 24 May 2013 11:05:49 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id AC43311E80A2 for ; Fri, 24 May 2013 11:05:49 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id B60B31DE0C4 for ; Fri, 24 May 2013 11:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=CGgT+Ni8Sr4fPlJzaUv1 ofJ09CY=; b=vbDtOQcvmV4/OxBMe5QsLG3++/q0aHNxefXsC8cjpWQC0Je+sfxJ USmO7NwiRrVF07DIAzLMueVqFjnkIeaQmUk7TNGSr4TndifiY+QoMO07fN/Z06bT mSLYreYUcf7uFQFeSiEAZciePn6hlLQhmo3cE8gdNpLfT3iw/xz5QU0= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id BCBB91DE0CD for ; Fri, 24 May 2013 10:53:58 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hr14so49649wib.9 for ; Fri, 24 May 2013 10:53:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gbCJd4pU3KZIuNHX0zwVVrIB75ImkCxpMRRudbKLn/U=; b=Qd62zwZ6OUZ3B6dro907Uoy3u6GqTXc7FghqhiVOvZcTD3en9YhI+YOvZsQJgMVcFe Eaze8rvbfBWT0QMAJ292LlsmBr3XuhHNfKZ2fClaegY9dlqK9iWqio0N4OTJuj8y/peg CI4Jmf1wjvCMBYwQyNZZCGq32wfIY41VX2/ZFIcLHL/Y2Qm4TZIJ8QBNiw083Wx8A4nf OvKa2ci0UzBfN3/qr+IDR4PUDmjH1X103/z9R6o4LJ0ipRWS214uAHdMeb3lAgc9NlCe g1qCP2ulzgo7jNyzQmXcFjfn93b65WK+26XWR6rBVYWdVAyeWe/uM3B8r45/2jaq+mKe 1B5w== MIME-Version: 1.0 X-Received: by 10.180.9.35 with SMTP id w3mr142924wia.51.1369418037121; Fri, 24 May 2013 10:53:57 -0700 (PDT) Received: by 10.217.133.83 with HTTP; Fri, 24 May 2013 10:53:56 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 May 2013 12:53:56 -0500 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org Discuss" , Paul Hoffman Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2013 18:05:54 -0000 On Fri, May 24, 2013 at 12:14 PM, Phillip Hallam-Baker wrote: > On Fri, May 24, 2013 at 1:02 PM, Joe Hildebrand (jhildebr) > wrote: >> >My experience of coding ASN.1 DER (in C and javascript) leads me to >> >reject any counted scheme as a non starter. >> >> I've read the whole thread, and didn't see adequate justification for that >> worldview. Could you reiterate it, please? > > > If you have a counter scheme it is necessary to have the whole data > structure in memory to serialize it. Many network applications require the > use of an intermediary with a fixed buffer length. > > Now ASN.1 BER definite length encoding makes matters even worse by > specifying lengths in octets rather than the number of entries in an object > but the same objection applies. And DER encoding is just plain insane as the > lengths of the lengths also varies. Yes, but note that CBOR does much better than DER: it counts elements (of arrays, of objects), not bytes (except for strings, which are byte-counted). It might be nice to have an array/object of indefinite length encoding where the end is indicated by a special type whose only purpose is to mark the end of the array/object (CER has this). But don't try to use this for strings: you end up having to escape the end-of-string marker -- ugh! > A very frequent use case for an encoding format is to take a stream of data > of unknown size and package it in real time. For example I would like to be > able to take a video stream and encrypt it using JSON encryption and then > put a digital signature at the end. Note BTW that JSON *is* amenable to online encoding (and decoding). Binary encodings should keep this feature. > BSON does not do that quite like I would like but I can fake the same effect > by using an array of Binary rather than one Binary chunk and the same for > strings. I think that's as well as you can expect to do without having to resort to escaping binary/string characters. Anyways, +1. Nico -- From hallam@gmail.com Fri May 24 11:08: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 CCA3C21F9673 for ; Fri, 24 May 2013 11:08: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, 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 uatxNVnL4wlp for ; Fri, 24 May 2013 11:08:25 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5047721F93C4 for ; Fri, 24 May 2013 11:08:25 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id ee20so4782957lab.14 for ; Fri, 24 May 2013 11:08: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:date:message-id:subject:from:to :cc:content-type; bh=Ga+o3Y1iKjf82YqKrgCxWkMrjBkC//TBk6i5R21eudI=; b=IQXiAQeGDcwyfUR98OgCtz9CpuhHBe7vfAOvLvvs7aJK7oFQhlVrmto27k3TaW28FB dI6IP7lQB9LyJqDlrp6uLQfc2DSfqkE47n8vvtESrSvVIhUkerBJa28zYDkIP4RQaKDP Lj/4xDJ4qlwvrlYdeyg482IlVTKH/20Py1g7mFqaxxrYDHerc3XyB1gRRLf8AOlktjE8 uwj2WA6/ar4XhhaGRz0hLcCVMsI6MbGpumGxf7XX+KOaJ7cfn9uwbX0fA7m2MGBuuORM F6XnmvxM2PPpRXEJAEcV4h67yh5lgOvOApGKC/4Mk9rR8csJIwAM32D/gFry/oHGvruv SP6w== MIME-Version: 1.0 X-Received: by 10.152.21.40 with SMTP id s8mr6662537lae.6.1369418904096; Fri, 24 May 2013 11:08:24 -0700 (PDT) Received: by 10.112.200.169 with HTTP; Fri, 24 May 2013 11:08:23 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 May 2013 14:08:23 -0400 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: multipart/alternative; boundary=089e0141a4a453d7f204dd7aafa9 Cc: "apps-discuss@ietf.org Discuss" , Paul Hoffman Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2013 18:08:26 -0000 --089e0141a4a453d7f204dd7aafa9 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 24, 2013 at 1:53 PM, Nico Williams wrote: > > BSON does not do that quite like I would like but I can fake the same > effect > > by using an array of Binary rather than one Binary chunk and the same for > > strings. > > I think that's as well as you can expect to do without having to > resort to escaping binary/string characters. > The alternative would be to declare new data types for chunked strings and chunked binary which would be closed by an end marker. The advantage to that approach is that it can be used by a transcoder that has a fixed buffer size converting from JSON to the binary encoding. It would be fairly easy to add to BSON as they have plenty of unused code points. The existing scheme is not very satisfactory as they represent lengths as fixed 32 bit integers!! Kind of disappointing when a single video file can easily be over 4Gb. Or at least would be if most equipment didn't have to dance around brain dead file systems with the same limitation. Sure counts of items are better than ASN.1's counts of bytes. But I can't see any utility in the counts of objects either. If you are trying to navigate to a particular point in the structure you are going to have to parse the whole stream regardless. The only way you could skip over a whole object to go onto the next would be with something like the ASN.1 definite length scheme. -- Website: http://hallambaker.com/ --089e0141a4a453d7f204dd7aafa9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, May 24, 2013 at 1:53 PM, Nico Williams <nic= o@cryptonector.com> wrote:
> BSON does not do that quite like I would like but I can fake the same = effect
> by using an array of Binary rather than one Binary chunk and the same = for
> strings.

I think that's as well as you can expect to do without having to<= br> resort to escaping binary/string characters.

The alternative would be to declare new data types for chunked = strings and chunked binary which would be closed by an end marker.

The advantage to that approach is that it c= an be used by a transcoder that has a fixed buffer size converting from JSO= N to the binary encoding.


It would be fairly easy to add to BSON as they have plenty of un= used code points. The existing scheme is not very satisfactory as they repr= esent lengths as fixed 32 bit integers!! Kind of disappointing when a singl= e video file can easily be over 4Gb. Or at least would be if most equipment= didn't have to dance around brain dead file systems with the same limi= tation.


Sure counts of items a= re better than ASN.1's counts of bytes. But I can't see any utility= in the counts of objects either. If you are trying to navigate to a partic= ular point in the structure you are going to have to parse the whole stream= regardless. The only way you could skip over a whole object to go onto the= next would be with something like the ASN.1 definite length scheme.

--
Website: ht= tp://hallambaker.com/
--089e0141a4a453d7f204dd7aafa9-- From nico@cryptonector.com Fri May 24 11:43: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 2966F11E80EE for ; Fri, 24 May 2013 11:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.857 X-Spam-Level: X-Spam-Status: No, score=-1.857 tagged_above=-999 required=5 tests=[AWL=0.120, 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 WEM9w8+36Pcv for ; Fri, 24 May 2013 11:43:47 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1D511E80EC for ; Fri, 24 May 2013 11:43:47 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 0919B2AC075 for ; Fri, 24 May 2013 11:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=pnq6Flc6D223+WltFSjK HdnXWN4=; b=XL1wAn4cVyVAFXLaCoyfYA605bNBfKZB2PoXr/7mPDPpb6e+fZqr pRaGkHChiloT8VQazGXJIc8qULRiZB/XzX5/rP+kBmrc31nh4phVsSpcKufiQUEO Uspz89u/1iIiGIu77C4CRlNJ1w2WbcR0m06fpySBvNagyeglToG748g= Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id C3B0A2AC085 for ; Fri, 24 May 2013 11:43:12 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hq7so74032wib.4 for ; Fri, 24 May 2013 11:43:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i2QU+jGNSmDSgCOQq/Bc8OHEzxL4g/9jTmmMhK5QTSw=; b=ioAoRbgUC2uJHMGW+A2kQvu2i4dcxfWSlpHawgB7lyI+YDS4hoEdtpUNE5nRLncP7Q TOjBV+4KAyPNpezNjAJr/wUjeGJG+JO8msRDM61zsbCfd6pbzzV6/9DUSbHUTcIlBhwE ncvGH3EOCX1S0bCcWgOA2gDuyyUR0+8E0J+YTooZNbmLviIAv6ONBos83mzZx6qHaXPC pDphvH3/re9ERPR2CcNCIrgQULDrQoSe3A38MRBIZjJxu/U/jlZhca0TLDVUM/t8zyle Eb04MrqPb6JjYROIRSwW5OoJozhcT78gVKVWQkmkzjEsGpAFyEUC2VDZo0XJ91oRg4PV C7YA== MIME-Version: 1.0 X-Received: by 10.180.184.83 with SMTP id es19mr278076wic.54.1369420991149; Fri, 24 May 2013 11:43:11 -0700 (PDT) Received: by 10.217.133.83 with HTTP; Fri, 24 May 2013 11:43:10 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 May 2013 13:43:10 -0500 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org Discuss" , Paul Hoffman Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2013 18:43:52 -0000 On Fri, May 24, 2013 at 1:08 PM, Phillip Hallam-Baker wrote: > On Fri, May 24, 2013 at 1:53 PM, Nico Williams > wrote: >> >> > BSON does not do that quite like I would like but I can fake the same >> > effect >> > by using an array of Binary rather than one Binary chunk and the same >> > for >> > strings. >> >> I think that's as well as you can expect to do without having to >> resort to escaping binary/string characters. > > > The alternative would be to declare new data types for chunked strings and > chunked binary which would be closed by an end marker. Ah, sure, turn strings (bytes or Unicode) into arrays of chunks. > Sure counts of items are better than ASN.1's counts of bytes. But I can't > see any utility in the counts of objects either. If you are trying to > navigate to a particular point in the structure you are going to have to > parse the whole stream regardless. The only way you could skip over a whole > object to go onto the next would be with something like the ASN.1 definite > length scheme. Sure, that's nice, but it sucks for the encoder. From nico@cryptonector.com Fri May 24 12:35: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 43A4A21E8090 for ; Fri, 24 May 2013 12:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.864 X-Spam-Level: X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5 tests=[AWL=0.113, 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 MUpYgyQfKySn for ; Fri, 24 May 2013 12:35:23 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 5367921E8086 for ; Fri, 24 May 2013 12:35:21 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 9ECE531805D for ; Fri, 24 May 2013 12:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=O7+es5wXGo0FSHN284Bj wS9a1uY=; b=wY1o8eMIVYFT06lEu4AuuQIHO4wZJoTKSswd96M/rnq8Kn1v1wmC pHCHPQ9PhYQsutRKTKI8RvMBCgAIM/9uLKqg7X/GbL6iIdB+NkeRLxptnem7BJ1H fKyuDBgN6T4wSL9mcioy+f7NRKe1MWP3Afpw93pYyNyoaK4PvbIsoYU= Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id F3AAE31805C for ; Fri, 24 May 2013 12:35:18 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id m6so94758wiv.11 for ; Fri, 24 May 2013 12:35:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6MHaBCtOhCbkUojeSvRKSyKkIDUAmoSihrSsckDJcU0=; b=jE80z50RRtoM6nygcAq3ZCYpf4mwezJT1JZDHkGEAMcgxYhQ0KbWq/JEwLiqQSrMu6 8GGE0EqgU1qwe8w45hbAwo2eJ1CGHUaRpj+m5i4RkMTo92IQkcO6/8SnbCV+Ptte9gYJ DWIcmLitBt+PqbVVf/agNmqAlV7ckNp4lpEEzvkK63t4I/fo99PNCCnPvX9vmp6uolZf EkMmQTbzcmXgpprbL6BZ6PBWpdwTyv0sUYEgM92aYhJLbzHF+6kEFYymhU1XpSIAZAxo jyPnM5273bNlgbxOP2VzZcYMPn/mdPjh5K3DxuET4ZEnO05k04VG2ZMpcYhh8C968I9D Nzaw== MIME-Version: 1.0 X-Received: by 10.194.134.73 with SMTP id pi9mr774281wjb.38.1369424117700; Fri, 24 May 2013 12:35:17 -0700 (PDT) Received: by 10.217.133.83 with HTTP; Fri, 24 May 2013 12:35:17 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1151A9721A1@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 24 May 2013 14:35:17 -0500 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] CBOR: convert CBOR bignum to base64url JSON string X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2013 19:35:28 -0000 On Fri, May 24, 2013 at 6:59 AM, Phillip Hallam-Baker wrote: > The idea that JSON can never change by an iota seems rather silly. The > specification is not really complete. Where difficult parts come up they are > ignored and so we don't know how implementations are expected to behave for > overflow or for NaN values. What can't change is what existing consumers expect. With care JSON can be extended just fine. At worst we might need a new MIME type. Anyways, being able to represent more things would be nice. It might also be nice to be able to degrade for decoder implementations that use NaN coding and that don't want to box things like bignums. From hallam@gmail.com Fri May 24 13:09: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 2119811E80F8 for ; Fri, 24 May 2013 13:09:18 -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 kRIBq2ktyYDU for ; Fri, 24 May 2013 13:09:17 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 21CA411E80F5 for ; Fri, 24 May 2013 13:09:03 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id fg20so4896372lab.1 for ; Fri, 24 May 2013 13:09: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=soGHaCCxfM/LGYNT997Tm452vaLl69j0LuGMzxIQW2E=; b=PaK+i4VwmEBzUBcxXenFA3G61XQG9qNEcV8MmUWcJGecuV3BjG1Bsstl7feaMfwbWp 9drRUeqDc+P3L/zK5hfG/H/dtsw4Mu/LRaNA9Eg76uH/SEzWSgLrITuZ5AntaaIgWDcl n9YD2FrimwfZEpgdzdveNcv83zQdNt/ir15s/jCO4OYMhVMqrIHT99/tQkMHt9zDR419 gafSr80P0x5R+A4w7E2CkhR91D1+8/2UtzwH5V4QpzwfrTl2nmOYXsawJ8XTMbJkVuuw mQ0U6Bp/sBXufG0Om3KHVRHO3hst5ThLH+ZwpMNFo79FwddpnpUtaD9MwXmbiv2V0KuA L/YA== MIME-Version: 1.0 X-Received: by 10.112.157.102 with SMTP id wl6mr9603914lbb.65.1369426143005; Fri, 24 May 2013 13:09:03 -0700 (PDT) Received: by 10.112.200.169 with HTTP; Fri, 24 May 2013 13:09:02 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1151A9721A1@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 24 May 2013 16:09:02 -0400 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c34ae6ccd0df04dd7c5e3b Cc: Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] CBOR: convert CBOR bignum to base64url JSON string X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2013 20:09:18 -0000 --001a11c34ae6ccd0df04dd7c5e3b Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 24, 2013 at 3:35 PM, Nico Williams wrote: > On Fri, May 24, 2013 at 6:59 AM, Phillip Hallam-Baker > wrote: > > The idea that JSON can never change by an iota seems rather silly. The > > specification is not really complete. Where difficult parts come up they > are > > ignored and so we don't know how implementations are expected to behave > for > > overflow or for NaN values. > > What can't change is what existing consumers expect. With care JSON > can be extended just fine. At worst we might need a new MIME type. > Anyways, being able to represent more things would be nice. It might > also be nice to be able to degrade for decoder implementations that > use NaN coding and that don't want to box things like bignums. > I think that in general we can't break anything with an update that isn't already broken. If you have a scientific application that is exchanging data without the ability to recognize NaN then it is likely going to break in horrid ways if one came up. Same is almost certainly true of excessively big numbers. Yes they should work. But I am almost certain they won't. -- Website: http://hallambaker.com/ --001a11c34ae6ccd0df04dd7c5e3b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, May 24, 2013 at 3:35 PM, Nico Williams <nic= o@cryptonector.com> wrote:
On Fri, May 24, 2013 at 6:= 59 AM, Phillip Hallam-Baker <hallam@= gmail.com> wrote:
> The idea that JSON can never change by an iota seems rather silly. The=
> specification is not really complete. Where difficult parts come up th= ey are
> ignored and so we don't know how implementations are expected to b= ehave for
> overflow or for NaN values.

What can't change is what existing consumers expect. =A0With care= JSON
can be extended just fine. =A0At worst we might need a new MIME type.
Anyways, being able to represent more things would be nice. =A0It might
also be nice to be able to degrade for decoder implementations that
use NaN coding and that don't want to box things like bignums.

I think that in general we can't break anything = with an update that isn't already broken.

If you have a scientific applicatio= n that is exchanging data without the ability to recognize NaN =A0then it i= s likely going to break in horrid ways if one came up.

Same is alm= ost certainly true of excessively big numbers. Yes they should work. But I = am almost certain they won't.=A0

-- Website: http://hallambaker.com/
--001a11c34ae6ccd0df04dd7c5e3b-- From fluffy@cisco.com Fri May 24 16:12: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 E715121F944F for ; Fri, 24 May 2013 16:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.566 X-Spam-Level: X-Spam-Status: No, score=-110.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 qXvVEe+dQ8Kp for ; Fri, 24 May 2013 16:12:05 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 211AB21F9408 for ; Fri, 24 May 2013 16:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2280; q=dns/txt; s=iport; t=1369437125; x=1370646725; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XU+MS5rUhNMsPrWvO7mQYHfKqD/tc9Yv4eRrnId45cg=; b=JSM2NjGCfqgi/RtyOD6oCmM4h4qKoPBezHRpdSVlvbTfBNI6ENuhFhHP yIRo8xE/oDcrZ6TKpx/JNxgIkZU8o+JNpLrogHMZ1x7KD9pTqj2YQGyU0 ReyxYndK4zphh6CbDeUr5k1mGSYPueaZRvcKXAvBd1Oco48Wxy5BrFkLz w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHvyn1GtJV2Y/2dsb2JhbABagwjCZ4EHFnSCIwEBAQMBeRACAQgYCiQhESUCBA4FCAyHZwMJBrB5DYhqjEaBFYEPAjEHgnNhA5VVjgOFI4MPgXE1 X-IronPort-AV: E=Sophos;i="4.87,738,1363132800"; d="scan'208";a="214899523" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 24 May 2013 23:12:04 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4ONC4Fa001178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 May 2013 23:12:04 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Fri, 24 May 2013 18:12:03 -0500 From: "Cullen Jennings (fluffy)" To: Phillip Hallam-Baker Thread-Topic: [apps-discuss] Concise Binary Object Representation (CBOR) Thread-Index: AQHOWNQZiTw2u1cw4kycF0Qz96eKPA== Date: Fri, 24 May 2013 23:11:33 +0000 Message-ID: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <142483A4-2E80-43F1-B3BE-B5B01650BB8F@tzi.org> <84317001-DB56-4DBE-9D1E-A4E605BC07A0@tzi.org> <3367FDBE-8268-4F3A-85CF-94D64BF60FCC@vpnc.org> <6C80DF35-E465-4107-B2B5-34D8D1C2F2CF@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 24 May 2013 23:12:11 -0000 Phil,=20 I think your email is out of line and that behavior like this is the larges= t threat to the IETF begin relevant in the future. If we treat people like = this, they are going to take their work elsewhere. I've talked to people ab= out why they don't bring standards work to the IETF and the list of reasons= why is surpassingly short and pretty well illustrated by this thread.=20 Cullen =20 More inline =85 On May 23, 2013, at 2:14 PM, Phillip Hallam-Baker wrote: >=20 >=20 >=20 > On Thu, May 23, 2013 at 3:24 PM, Paul Hoffman wro= te: > On May 23, 2013, at 11:35 AM, James M Snell wrote: >=20 > > That's well and good, from everything I've seen so far in this thread, > > the collective majority opinion can be summarized as "Ugh... Groan.. > > Another one? Really?" >=20 > Just a note that this is one of the only ones that people are groaning ab= out that has an Internet Draft and might go through the IETF consensus proc= ess. Carsten and I (maybe naively) thought that doing this in this environm= ent, instead of say posting ephemeral specs on a web page and not having it= be clear where the community fit it, was a good thing. >=20 > I don't remember you being appointed to address the issue.=20 Actually, I think you, and the rest of the IETF did appoint them. We encour= age people to bring good technical work and discuss it. Clearly binary enco= dings is an important topic for IETF protocols - This seems like a perfectl= y reasonable list to bring the email discussion to.=20 >=20 > Since almost all the response to your proposal has been that people don't= like your design choices, and since you make it abundantly clear that you = are not interested in our input, I can't quite see where a consensus is goi= ng to come. Unless that is the consensus is that your proposal sucks. That was not my read of the thread so far.=20 >=20 > I would certainly object to a format that was counted being granted any d= egree of IETF recognition lest someone try to force me to use it in the fut= ure. This is not BCP that must be used by all future IETF protocols. It's an opt= ion for work that gets consensus to use it.=20 >=20 From hallam@gmail.com Fri May 24 19:23: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 5A1EF21E8050 for ; Fri, 24 May 2013 19:23:15 -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 4FrMRj+mxyVh for ; Fri, 24 May 2013 19:23:13 -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 6E3B921F9452 for ; Fri, 24 May 2013 19:23:13 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id q55so3164760wes.0 for ; Fri, 24 May 2013 19:23:12 -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=r+zuZMnGGenZELH+1zLuMI/KumSkKhNCkWEZ5VYmVCQ=; b=u15qJTQmI38OJfBKdzU52XE4JTudY14W4JDP8EkyW/+GdOCYcpDWlZUItMJC/a1wUj PwTXVD1RR7hhJmT0i4aitiWI5p6CpeV6HOqpxv69tHjG5kzm4WroHmn69Dkr7NSKaZIG knJkF0Rg8u5f2mTERY2lfkqfBlYOk2kM/L6SM59NZxZ4TemH19IejdUkMo5lXp/J1fPN qN52OmvjjnT74HJLA1kVFksmdDjKgCu8h0rKLoavTw09XxNQz+amhouhCHBAtDJrSyde 7B56y7ERHM/2O7b/hMBsVIWhPfaja4E+CkqKclzy6xyNWsPcHqM36juMwWkV/A4lx9RY LzkA== MIME-Version: 1.0 X-Received: by 10.180.9.80 with SMTP id x16mr1013018wia.63.1369448592539; Fri, 24 May 2013 19:23:12 -0700 (PDT) Received: by 10.194.123.225 with HTTP; Fri, 24 May 2013 19:23:12 -0700 (PDT) In-Reply-To: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <142483A4-2E80-43F1-B3BE-B5B01650BB8F@tzi.org> <84317001-DB56-4DBE-9D1E-A4E605BC07A0@tzi.org> <3367FDBE-8268-4F3A-85CF-94D64BF60FCC@vpnc.org> <6C80DF35-E465-4107-B2B5-34D8D1C2F2CF@vpnc.org> Date: Fri, 24 May 2013 22:23:12 -0400 Message-ID: From: Phillip Hallam-Baker To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=001a11c21f84e585bd04dd819800 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2013 02:23:15 -0000 --001a11c21f84e585bd04dd819800 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 24, 2013 at 7:11 PM, Cullen Jennings (fluffy) wrote: > > Phil, > > I think your email is out of line and that behavior like this is the > largest threat to the IETF begin relevant in the future. If we treat people > like this, they are going to take their work elsewhere. I've talked to > people about why they don't bring standards work to the IETF and the list > of reasons why is surpassingly short and pretty well illustrated by this > thread. > > Cullen > I was responding to Paul Hoffman. I hardly think he is quite the shrinking violet you suggest or a novice likely to be deterred from IETF involvement. He certainly isn't going to be deterred by anything I say. In particular I was responding to his rather premature claim that the difference between his proposal and the others was IETF 'consensus'. We have had all of two days discussion of this proposal while the MongoDB folk have a whole community built around theirs. More generally, one of the reasons I see people not wanting to bring work to IETF is the not invented here attitude. I was more than a little annoyed when the IETF response to SOAP was to quick march BEEP to proposed standard in an attempt to trump W3C and OASIS and so were many others. On May 23, 2013, at 2:14 PM, Phillip Hallam-Baker wrote: > > > On Thu, May 23, 2013 at 3:24 PM, Paul Hoffman > wrote: > > On May 23, 2013, at 11:35 AM, James M Snell wrote: > > > > > That's well and good, from everything I've seen so far in this thread, > > > the collective majority opinion can be summarized as "Ugh... Groan.. > > > Another one? Really?" > > > > Just a note that this is one of the only ones that people are groaning > about that has an Internet Draft and might go through the IETF consensus > process. Carsten and I (maybe naively) thought that doing this in this > environment, instead of say posting ephemeral specs on a web page and not > having it be clear where the community fit it, was a good thing. > > > > I don't remember you being appointed to address the issue. > > Actually, I think you, and the rest of the IETF did appoint them. We > encourage people to bring good technical work and discuss it. Clearly > binary encodings is an important topic for IETF protocols - This seems like > a perfectly reasonable list to bring the email discussion to. I did not object to it being brought to the list. What I objected to was the claim of IETF consensus as the distinctive advantage for the protocol. The IETF does have a body that is officially tasked with such things although it doesn't actually do that work. It is called the IAB. Paul's argument would make sense if it was being made by a member of the IAB tasked with driving us towards consensus on a binary encoding. Absent an explicit appointment to address the issue Paul's proposal is just another Internet Draft. What I interpreted the majority of the comments preceding it to be saying was 'why not document one of the existing specs' which is of course what was done with JSON itself. Instead we have a completely new proposal with no deployed base being proposed and the only advantage to this proposal is that it has an Internet Draft. If the only problem with BSON etc is that they are ephemeral then making them concrete might be a good start. If there are other problems then a description would be useful. > > Since almost all the response to your proposal has been that people > don't like your design choices, and since you make it abundantly clear that > you are not interested in our input, I can't quite see where a consensus is > going to come. Unless that is the consensus is that your proposal sucks. > > That was not my read of the thread so far. I saw several people raise requirements, all I saw was pushback of the form 'we have decided to do it our way'. I have not seen any of the design choices being justified against requirements. I have not seen a technical argument being made for any of the choices other than for the counted vs delimited issue whare the answer was 'because'. "Use an existing scheme" would be a perfectly reasonable proposal. "Develop a new scheme based on requirements proposed by IETF community and those in the BSON etc community" would also be a reasonable proposal. "Use our scheme, it has an Internet Draft" does not seem to be a reasonable proposal. > > I would certainly object to a format that was counted being granted any > degree of IETF recognition lest someone try to force me to use it in the > future. > > This is not BCP that must be used by all future IETF protocols. It's an > option for work that gets consensus to use it. > I don't believe that for two reasons. First I have heard that exact statement used before about many similar projects and then I have sat in rooms where the people who said that use would not be mandated are telling another group that they are expected to use it. Remember when people were being told that they had to use BEEP for their Web service? I do. Second, this particular spec is like JSON in that it only has value if everyone uses the same thing. There really is not room for more than one binary encoding of JSON in IETF. JSON was originally an informational RFC. If we are going to have a binary encoding then we should probably follow the same approach and that candidates should be published as informational and we should let the community make a consensus choice from amongst them. I see now that my real objection is to CBOR being initially standards track. What we should do is to begin with Informational descriptions for existing standards that are widely used (MongoDB's BSON for example) and Experimental proposals for anything new. Then we should see if there is the possibility of convergence on one of the proposals. I dropped a note into the BSON mailing list to see what their response might be but with no reply so far. -- Website: http://hallambaker.com/ --001a11c21f84e585bd04dd819800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, May 24, 2013 at 7:11 PM, Cullen Jennings (fluffy) = <fluffy@cisco.com> wrote:

Phil,

I think your email is out of line and that behavior like this is the larges= t threat to the IETF begin relevant in the future. If we treat people like = this, they are going to take their work elsewhere. I've talked to peopl= e about why they don't bring standards work to the IETF and the list of= reasons why is surpassingly short and pretty well illustrated by this thre= ad.

Cullen

I was responding to Paul H= offman. I hardly think he is quite the shrinking violet you suggest or a no= vice likely to be deterred from IETF involvement. He certainly isn't go= ing to be deterred by anything I say.=A0

In particular I was responding to his rather prem= ature claim that the difference between his proposal and the others was IET= F 'consensus'. We have had all of two days discussion of this propo= sal while the MongoDB folk have a whole community built around theirs.=A0


More generally, one of the reasons= I see people not wanting to bring work to IETF is the not invented here at= titude. I was more than a little annoyed when the IETF response to SOAP was= to quick march BEEP to proposed standard in an attempt to trump W3C and OA= SIS and so were many others.=A0


On May 23, 2013, at 2:14 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:

> On Thu, May 23, 2013 at 3:24 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> On May 23, 2013, at 11:35 AM, James M Snell <jasnell@gmail.com> wrote:
>
> > That's well and good, from everything I've seen so far in= this thread,
> > the collective majority opinion can be summarized as "Ugh...= Groan..
> > Another one? Really?"
>
> Just a note that this is one of the only ones that people are groaning= about that has an Internet Draft and might go through the IETF consensus p= rocess. Carsten and I (maybe naively) thought that doing this in this envir= onment, instead of say posting ephemeral specs on a web page and not having= it be clear where the community fit it, was a good thing.
>
> I don't remember you being appointed to address the issue.

Actually, I think you, and the rest of the IETF did appoint them. We = encourage people to bring good technical work and discuss it. Clearly binar= y encodings is an important topic for IETF protocols - This seems like a pe= rfectly reasonable list to bring the email discussion to.

I did not object to it being brought to the list.= What I objected to was the claim of IETF consensus as the distinctive adva= ntage for the protocol.

The IETF does = have a body that is officially tasked with such things although it doesn= 9;t actually do that work. It is called the IAB. Paul's argument would = make sense if it was being made by a member of the IAB tasked with driving = us towards consensus on a binary encoding. Absent an explicit appointment t= o address the issue Paul's proposal is just another Internet Draft.


What I interpreted the= majority of the comments preceding it to be saying was 'why not docume= nt one of the existing specs' which is of course what was done with JSO= N itself. Instead we have a completely new proposal with no deployed base b= eing proposed and the only advantage to this proposal is that it has an Int= ernet Draft.

If the only problem with BSON etc is that t= hey are ephemeral then making them concrete might be a good start. If there= are other problems then a description would be useful.

=A0
> Since almost all the response to your proposal has been that people do= n't like your design choices, and since you make it abundantly clear th= at you are not interested in our input, I can't quite see where a conse= nsus is going to come. Unless that is the consensus is that your proposal s= ucks.

That was not my read of the thread so far.

I saw several people raise requirements, all I saw was pushback= of the form 'we have decided to do it our way'. I have not seen an= y of the design choices being justified against requirements. I have not se= en a technical argument being made for any of the choices other than for th= e counted vs delimited issue whare the answer was 'because'.


"Use an existing = scheme" would be a perfectly reasonable proposal.=A0
<= br>
"Develop a new scheme based on requirements propos= ed by IETF community and those in the BSON etc community" would also b= e a reasonable proposal.

"Use our scheme, it has an Internet Dr= aft" does not seem to be a reasonable proposal.=A0
=A0
> I would certainly object to a format that was counted being granted an= y degree of IETF recognition lest someone try to force me to use it in the = future.

This is not BCP that must be used by all future IETF protocols. It= 9;s an option for work that gets consensus to use it.
=
I don't believe that for two reasons.

First I have heard that exact statement used before ab= out many similar projects and then I have sat in rooms where the people who= said that use would not be mandated are telling another group that they ar= e expected to use it. Remember when people were being told that they had to= use BEEP for their Web service? I do.

Second, this particular spec is like JSON i= n that it only has value if everyone uses the same thing. There really is n= ot room for more than one binary encoding of JSON in IETF.=A0


JSON was originally an informatio= nal RFC. If we are going to have a binary encoding then we should probably = follow the same approach and that candidates should be published as informa= tional and we should let the community make a consensus choice from amongst= them.

I see now that my real objection is to CBOR= being initially standards track. What we should do is to begin with Inform= ational descriptions for existing standards that are widely used (MongoDB&#= 39;s BSON for example) and Experimental proposals for anything new. Then we= should see if there is the possibility of convergence on one of the propos= als.


I dropped a note into the BS= ON mailing list to see what their response might be but with no reply so fa= r.


--
Website: http://hallambaker.com/
--001a11c21f84e585bd04dd819800-- From nico@cryptonector.com Fri May 24 20:29: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 D409521F944F for ; Fri, 24 May 2013 20:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.371 X-Spam-Level: X-Spam-Status: No, score=-1.371 tagged_above=-999 required=5 tests=[AWL=-0.394, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_BACKHAIR_33=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 PXoT8bFB-Gv5 for ; Fri, 24 May 2013 20:28:58 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id DB4A921F9339 for ; Fri, 24 May 2013 20:28:58 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 6B4DF438079 for ; Fri, 24 May 2013 20:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=YEBFX4lHvSHP+qktLDI2 Pl5dR8E=; b=Y1BlM6jpxVvjY7sTUrv2xVNnzw+XKaKVYRMnN9tkhlFK8eWLWTzT gOWf3AdtARhRduzUgidxkh6CI+M3Eh6wFT2rkcxslmBVZLhY2l++DH5MqY3CEd2/ gqP9rqvb2uCC421SnuKgVseuNle7xaWnal4fExkza3PB6ndgr6Gtldo= Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 1ACF643806C for ; Fri, 24 May 2013 20:28:57 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id m6so228359wiv.17 for ; Fri, 24 May 2013 20:28:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iWiQaXgtQigqBfIS1ljAkbU0AuTGJ4+3MpxeVVm+AZU=; b=ZcGPO3s394YhBpWV6C4yE+Gt6SugUCwMmFv3kFckbGpQaz9f63OSIJSTAKI9CTNbkd bq6+nojyW5D1Nk0xdi6Pm4SSDeifTO9oollxk+iSBQeMX58fX8ydevUgXL/MpqHI06GU qJFslWgLFUTZ3iNnNmFU91WAGkO0aBAandyQCll5BNZakEzm1MoUft04DIx9yow7CuMK PBHWMf2lAEkLpPqYlXl11Ez+r/E8Q4wMicbruxQV+tsrZdt5BvGTAUyfCk3t28xoplvO iJiRw8SsLCP93dCcWO0vbOyz1ajjOTJp9k0offoyU/UH/u08ejgib2ykqgCKLDpn6Nlw WZqg== MIME-Version: 1.0 X-Received: by 10.194.77.66 with SMTP id q2mr1535092wjw.34.1369452536497; Fri, 24 May 2013 20:28:56 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Fri, 24 May 2013 20:28:56 -0700 (PDT) In-Reply-To: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> Date: Fri, 24 May 2013 22:28:56 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2013 03:29:03 -0000 Thinking about what *I* want in a binary JSON encoding, and taking into account PHB's points about online encoding and decoding, all I really want, the one thing I badly want, is counted-bytes and chunked Unicode and octet strings. That's it. So picture JSON, complete with square and curly brackets, but no commas nor colons, just strings (byte-counted or chunked), some encoding for numbers, booleans, and null. It's the handing of scalars that sucks about JSON: string escaping, number printing and parsing. Something like this: {foobarbaznum} as an encoding of { "foo": "barbaz", "num": 5 }, with "barbaz" chunked. One of the nice things about such an encoding is that it should be possible to implement as a fairly small variation on existing code: it's almost only a different way of encoding scalar types -- the only other difference being that commas and colons are not needed. With a variable-length encoding of integers and IEEE 754 64-bit doubles for reals... that's compact enough. Not nearly as compact as we could get with schemas and PER-like encodings, but good enough for a schema-less encoding. Nico -- From fluffy@cisco.com Sat May 25 06:42:58 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3287B21F87FB for ; Sat, 25 May 2013 06:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.437 X-Spam-Level: X-Spam-Status: No, score=-110.437 tagged_above=-999 required=5 tests=[AWL=0.163, 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 GYPt0Akb8ZnT for ; Sat, 25 May 2013 06:42:52 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0C78E21F8825 for ; Sat, 25 May 2013 06:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8110; q=dns/txt; s=iport; t=1369489371; x=1370698971; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IBfBqcPC6HA3S6t1hnKzs2d+D64TRV4GsZotOvRe1E4=; b=QgrbyRwA5hlfGWZHQ4p3AsmTGvaGlQDFz4NsssTpDwWG1D5ydTQyXHDY IeRejJ1cvUz6w1Po9qf8fLtsoLQdamNRVTJjjXtDsUSVOHbZRw7UVUQ1k gTqb1APUzS2jp/YWUsDpo9nyvaHpn6B9st2cf9X/asfdNC1XihDpAIHSU E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYGABq/oFGtJXHB/2dsb2JhbABagwgwwjeBBhZ0giMBAQEDAW4LBQsCAQgYCiQhESUCBA4FCAwHh2ADCQazLg2IaoxGgRWBDwIxB4JzYQOIZ4xugw+KdIUjgw+BcTU X-IronPort-AV: E=Sophos;i="4.87,741,1363132800"; d="scan'208";a="214721307" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 25 May 2013 13:42:50 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4PDgohM021499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 25 May 2013 13:42:50 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Sat, 25 May 2013 08:42:49 -0500 From: "Cullen Jennings (fluffy)" To: Phillip Hallam-Baker Thread-Topic: [apps-discuss] Concise Binary Object Representation (CBOR) Thread-Index: AQHOWO7VZGCTaQTm/UaYRaIjVWjDvpkWPXGA Date: Sat, 25 May 2013 13:42:17 +0000 Message-ID: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> <142483A4-2E80-43F1-B3BE-B5B01650BB8F@tzi.org> <84317001-DB56-4DBE-9D1E-A4E605BC07A0@tzi.org> <3367FDBE-8268-4F3A-85CF-94D64BF60FCC@vpnc.org> <6C80DF35-E465-4107-B2B5-34D8D1C2F2CF@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <00EDA3310B48354EB19A61168C43BA62@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2013 13:42:58 -0000 On May 24, 2013, at 8:23 PM, Phillip Hallam-Baker wrote: > On Fri, May 24, 2013 at 7:11 PM, Cullen Jennings (fluffy) wrote: >=20 > Phil, >=20 > I think your email is out of line and that behavior like this is the larg= est threat to the IETF begin relevant in the future. If we treat people lik= e this, they are going to take their work elsewhere. I've talked to people = about why they don't bring standards work to the IETF and the list of reaso= ns why is surpassingly short and pretty well illustrated by this thread. >=20 > Cullen >=20 > I was responding to Paul Hoffman. I hardly think he is quite the shrinkin= g violet you suggest or a novice likely to be deterred from IETF involvemen= t. He certainly isn't going to be deterred by anything I say.=20 Agree and Carsten also is certainly capable of knocking me into line when I= am wrong so I realize they are both experienced and not likely to be scare= d away from the IETF by anything one person says. But it can still be frus= trating, demotivating, and suck all the energy away from getting the techni= cal work done.=20 >=20 > In particular I was responding to his rather premature claim that the dif= ference between his proposal and the others was IETF 'consensus'. We have h= ad all of two days discussion of this proposal while the MongoDB folk have = a whole community built around theirs.=20 >=20 Ok - I don't think I saw them saying this had IETF consensus - clearly they= don't. I do think that it makes sense for them to try and develop consensu= s around a solution that meets a broader sets of needs than what Mongo does= . That does not make what mongo is doing wrong for mongo but it is one of = the reasons why there are a variety of ways of doing binary encoding of dat= a that have evolved over time as the requirements, constraints, and target = deployment environments have changed.=20 >=20 > More generally, one of the reasons I see people not wanting to bring work= to IETF is the not invented here attitude. I was more than a little annoye= d when the IETF response to SOAP was to quick march BEEP to proposed standa= rd in an attempt to trump W3C and OASIS and so were many others.=20 I generally agree that the IETF does better when it takes more than one com= munity of interest and helps bridge them to create a more general and wides= pread solution that works for both. And sure I see lots of people proposing= , lets have the IETF reinvent X - we are going to have some of both of thes= e behaviors and at times it is a good thing.=20 Some times I am happy when the IETF effectively rubber stamps a Cisco or Mi= crosoft or some open source projects technology. Other times I am very happ= y when they do not rubber stamp it but instead look at the underlying needs= and take a more multiparty collaborative approach. Both have their time an= d place to achieve the real goal of making the internet work. =20 >=20 >=20 > On May 23, 2013, at 2:14 PM, Phillip Hallam-Baker wrot= e: >=20 > > On Thu, May 23, 2013 at 3:24 PM, Paul Hoffman w= rote: > > On May 23, 2013, at 11:35 AM, James M Snell wrote: > > > > > That's well and good, from everything I've seen so far in this thread= , > > > the collective majority opinion can be summarized as "Ugh... Groan.. > > > Another one? Really?" > > > > Just a note that this is one of the only ones that people are groaning = about that has an Internet Draft and might go through the IETF consensus pr= ocess. Carsten and I (maybe naively) thought that doing this in this enviro= nment, instead of say posting ephemeral specs on a web page and not having = it be clear where the community fit it, was a good thing. > > > > I don't remember you being appointed to address the issue. >=20 > Actually, I think you, and the rest of the IETF did appoint them. We enco= urage people to bring good technical work and discuss it. Clearly binary en= codings is an important topic for IETF protocols - This seems like a perfec= tly reasonable list to bring the email discussion to. >=20 > I did not object to it being brought to the list. What I objected to was = the claim of IETF consensus as the distinctive advantage for the protocol. >=20 > The IETF does have a body that is officially tasked with such things alth= ough it doesn't actually do that work. It is called the IAB. Paul's argumen= t would make sense if it was being made by a member of the IAB tasked with = driving us towards consensus on a binary encoding. Absent an explicit appoi= ntment to address the issue Paul's proposal is just another Internet Draft. >=20 >=20 > What I interpreted the majority of the comments preceding it to be saying= was 'why not document one of the existing specs' which is of course what w= as done with JSON itself. Instead we have a completely new proposal with no= deployed base being proposed and the only advantage to this proposal is th= at it has an Internet Draft. >=20 > If the only problem with BSON etc is that they are ephemeral then making = them concrete might be a good start. If there are other problems then a des= cription would be useful. >=20 > =20 > > Since almost all the response to your proposal has been that people don= 't like your design choices, and since you make it abundantly clear that yo= u are not interested in our input, I can't quite see where a consensus is g= oing to come. Unless that is the consensus is that your proposal sucks. >=20 > That was not my read of the thread so far. >=20 > I saw several people raise requirements, all I saw was pushback of the fo= rm 'we have decided to do it our way'. I have not seen any of the design ch= oices being justified against requirements. I have not seen a technical arg= ument being made for any of the choices other than for the counted vs delim= ited issue whare the answer was 'because'. >=20 >=20 > "Use an existing scheme" would be a perfectly reasonable proposal.=20 >=20 > "Develop a new scheme based on requirements proposed by IETF community an= d those in the BSON etc community" would also be a reasonable proposal. >=20 > "Use our scheme, it has an Internet Draft" does not seem to be a reasonab= le proposal.=20 >=20 > =20 > > I would certainly object to a format that was counted being granted any= degree of IETF recognition lest someone try to force me to use it in the f= uture. >=20 > This is not BCP that must be used by all future IETF protocols. It's an o= ption for work that gets consensus to use it. >=20 > I don't believe that for two reasons. >=20 > First I have heard that exact statement used before about many similar pr= ojects and then I have sat in rooms where the people who said that use woul= d not be mandated are telling another group that they are expected to use i= t. Remember when people were being told that they had to use BEEP for their= Web service? I do. >=20 > Second, this particular spec is like JSON in that it only has value if ev= eryone uses the same thing. There really is not room for more than one bina= ry encoding of JSON in IETF.=20 >=20 >=20 > JSON was originally an informational RFC. If we are going to have a binar= y encoding then we should probably follow the same approach and that candid= ates should be published as informational and we should let the community m= ake a consensus choice from amongst them. >=20 > I see now that my real objection is to CBOR being initially standards tra= ck. What we should do is to begin with Informational descriptions for exist= ing standards that are widely used (MongoDB's BSON for example) and Experim= ental proposals for anything new. Then we should see if there is the possib= ility of convergence on one of the proposals. >=20 >=20 > I dropped a note into the BSON mailing list to see what their response mi= ght be but with no reply so far. >=20 >=20 > --=20 > Website: http://hallambaker.com/ From hallam@gmail.com Sat May 25 09:13: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 6EE7A21F8B60 for ; Sat, 25 May 2013 09:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.016 X-Spam-Level: X-Spam-Status: No, score=-1.016 tagged_above=-999 required=5 tests=[AWL=-1.583, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, J_BACKHAIR_33=1, 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 2DSHxuY+idvq for ; Sat, 25 May 2013 09:13:16 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6300A21F8A6B for ; Sat, 25 May 2013 09:13:15 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id q57so3123796wes.13 for ; Sat, 25 May 2013 09:13:14 -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=5DtW2hArUQDqHB7rMmTxqYnFcjJyGA9DFbhRtT1l08c=; b=Mx4O1RGgk2+c1myI9j5w0UxXOsxmwHRjWO0OupyRlnJOLWhtNSPGSzoJkgxoeXSjq3 9aIQsN66o6MdKcijPZyD9eLwqPhAIVmL2a4xp22nF2qXRM/uklxV9Dfdx8xtomZ9QWKV un29feAyoIFjD0ett17gVj58kx0CZLQlgUqL6u4kJ+KzaujnCO6hlFLS/mz3zvUY9xPx YNvZxiKwtpqzC9OdGJK8W2mb20Pi9edL73byUSMPqCmUhzq1bQz4cGu2XRn4HiydId4A rMb79mWkZ2GhqUhK+XxZtB4g69WFkf7h/3G3zmmXL3PuGRe1Tj6656nOn/RTmtLm1/l0 U1dQ== MIME-Version: 1.0 X-Received: by 10.180.205.200 with SMTP id li8mr2745939wic.15.1369498394453; Sat, 25 May 2013 09:13:14 -0700 (PDT) Received: by 10.194.123.225 with HTTP; Sat, 25 May 2013 09:13:14 -0700 (PDT) In-Reply-To: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> Date: Sat, 25 May 2013 12:13:14 -0400 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: multipart/alternative; boundary=001a11c382c6526d9904dd8d31cc Cc: Paul Hoffman , General discussion of application-layer protocols Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2013 16:13:17 -0000 --001a11c382c6526d9904dd8d31cc Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 24, 2013 at 11:28 PM, Nico Williams wrote: > Thinking about what *I* want in a binary JSON encoding, and taking > into account PHB's points about online encoding and decoding, all I > really want, the one thing I badly want, is counted-bytes and chunked > Unicode and octet strings. That's it. So picture JSON, complete with > square and curly brackets, but no commas nor colons, just strings > (byte-counted or chunked), some encoding for numbers, booleans, and > null. It's the handing of scalars that sucks about JSON: string > escaping, number printing and parsing. > > Something like this: > > {foobar to preceding string, length 3>baz 3>num} > > as an encoding of { "foo": "barbaz", "num": 5 }, with "barbaz" chunked. > > One of the nice things about such an encoding is that it should be > possible to implement as a fairly small variation on existing code: > it's almost only a different way of encoding scalar types -- the only > other difference being that commas and colons are not needed. > > With a variable-length encoding of integers and IEEE 754 64-bit > doubles for reals... that's compact enough. Not nearly as compact as > we could get with schemas and PER-like encodings, but good enough for > a schema-less encoding. > I like this proposal, more a sort of JSON-B as in JSON Encoding B The only Con I can think of is that it will still be backwards incompatible so why not be more compact? And people might worry about JSON-B getting confused with JSON. For my requirements, I think I would still like to be able to binary encode floating point numbers. The issue there is the precision loss from round tripping and the ability to encode NaN and +/- infinity But we do have the entire ASCII code set above 128 to play with (actually we have more but above 128 is plenty) The result would be slightly less efficient than a true binary JSON but not by very much. The tags will still be there. JSON taged items have an overhead of 4 bytes per entry: "":, (You can add in spaces but they aren't necessary.) It would not be difficult to reduce those 4 bytes to one. But it isn't a big win either. The win comes from not having to Base64 the binary chunks. For purposes of planning tags and making sure there is enough space it is probably best to start off expansively and considering all the possible types we might recognize x80 Terminal String 8 bit length x81 Terminal String 16 bit length x82 Terminal String 32 bit length x83 Terminal String 64 bit length x84 Non Terminal String Chunk 8 bit length x85 Non Terminal String Chunk 16 bit length x86 Non Terminal String Chunk 32 bit length x87 Non Terminal String Chunk 64 bit length x88 Terminal Binary 8 bit length x87 Terminal Binary 16 bit length x8A Terminal Binary 32 bit length x8B Terminal Binary 64 bit length x8C Non Terminal Binary Chunk 8 bit length x8D Non Terminal Binary Chunk 16 bit length x8E Non Terminal Binary Chunk 32 bit length x8F Non Terminal Binary Chunk 64 bit length x90 IEEE 754 Floating Point binary16 (1) x91 IEEE 754 Floating Point binary32 x92 IEEE 754 Floating Point binary64 x94 IEEE 754 Floating Point binary128 (1) x96 IEEE 754 Floating Point decimal32 (1) x97 IEEE 754 Floating Point decimal64 (1) x98 IEEE 754 Floating Point decimal128 (1) xA0 Unsigned Integer 8 (1) xA1 Unsigned Integer 16 (1) xA2 Unsigned Integer 32 (1) xA3 Unsigned Integer 64 (1) xA4 Unsigned Integer 128 (1) xA5 Signed Integer 8 (1) xA6 Signed Integer 16 (1) xA7 Signed Integer 32 (1) xA8 Signed Integer 64 (1) xA9 Signed Integer 128 (1) xAA True xAB False xAC Null (1) The need to implement these codes is debatable. But the tag asignment scheme should not foreclose the possibility. That still leaves a block of 72 codes unused. So if people wanted to go back and do binary tagging at a later date (JSON-C) that would be possible. I did try to work out some sort of clever bit mask trick so that the lower bits of the code would specify the number of additional bytes to follow but that does not work so well as there are 128 bit values to consider. And at the end of the day there are only going to be 60 odd code maximum so an array works fine. I considered Nico's proposal of a 'continuation block' but that would require a reader to read in the start of the next block before it can know what to do with the previous data. The writer should know when it is starting to write out a chunk that more chunks might follow or not. If no more data follows the writer just puts out x80 x00 or x88 x00 to close the stream. {To follow the rest it might help to look at the diagrams in http://www.json.org/] There are a few tricks that could be used here to further reduce space. consider the production "":, The initial " is not really needed since the only valid productions following an object open brace are the close brace or an element entry. So " is only needed if you desperately want to have the possibility of a tag '}drop tables'. OK now I get it, leave the initial " in for Randall Munroe http://xkcd.com/327/ If the reader sees a code above 7F it can only be binary data so the ": separator between the tag and the data are superfluous and could be elided The binary data descriptions are all defined length and so the terminal , is not needed. So if people wanted to, we could adjust the FSR to allow these abbreviations in JSON-B and save the four bytes per object entry overhead. But that would still leave the tags there and those can't be eliminated without some sort of dictionary, either being passed on the wire (which is what compressors are really doing) or out of band (which is what schema aware is really about). So for JSON-C we would need ways to define a binding of a tag to a code and ways of specifying those codes in object productions. Keeping the initial " helps us here because it means that the only currently valid characters after the initial { are ", } and whitespace. We might just conceivably need more than 64K codes, so the code value is potentially a 32 bit space. So the codes I would define are: C0 8 bit tag code follows C1 16 bit tag code follows C2 32 bit tag code follows C4 8 bit definition follows C5 16 bit definition follows C6 32 bit definition follows C7 8 bit tag with definition follows C8 16 bit tag with definition follows C9 32 bit tag with definition follows the codes c4-c9 would be followed with a string definition. So the first occurrence of { "foo" : "data" } would become: x7B { xC7 x01 x80 x03 x66 x6f x6f "foo": [Code 1] x80 x04 x64 x61 x74 x61 "data" x7D } On the second occurrence the definition is already there: x7B { xC0 x01 [Code 1] x80 x04 x64 x61 x74 x61 "data" x7D } An implementation could simply dump the dictionary out at the start of the message using the C4-C6 codes. -- Website: http://hallambaker.com/ --001a11c382c6526d9904dd8d31cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, May 24, 2013 at 11:28 PM, Nico Williams <nic= o@cryptonector.com> wrote:
Thinking about what *I* want in a binary JSON encoding, an= d taking
into account PHB's points about online encoding and decoding, all I
really want, the one thing I badly want, is counted-bytes and chunked
Unicode and octet strings. =A0That's it. =A0So picture JSON, complete w= ith
square and curly brackets, but no commas nor colons, just strings
(byte-counted or chunked), some encoding for numbers, booleans, and
null. =A0It's the handing of scalars that sucks about JSON: string
escaping, number printing and parsing.

Something like this:

{<Unicode string of length 3>foo<Unicode string of length 3>bar= <join
to preceding string, length 3>baz<Unicode string of length
3>num<integer value 5>}

as an encoding of { "foo": "barbaz", "num": 5= }, with "barbaz" chunked.

One of the nice things about such an encoding is that it should be
possible to implement as a fairly small variation on existing code:
it's almost only a different way of encoding scalar types -- the only other difference being that commas and colons are not needed.

With a variable-length encoding of integers and IEEE 754 64-bit
doubles for reals... that's compact enough. =A0Not nearly as compact as=
we could get with schemas and PER-like encodings, but good enough for
a schema-less encoding.


= I like this proposal, more a sort of JSON-B as in JSON Encoding B=A0
<= /div>

The only Con I can think of is that it will still = be backwards incompatible so why not be more compact? And people might worr= y about JSON-B getting confused with JSON.


For my requirements, I think I would sti= ll like to be able to binary encode floating point numbers. The issue there= is the precision loss from round tripping and the ability to encode NaN an= d +/- infinity

But we do have the entire ASCII code set above 128 to p= lay with (actually we have more but above 128 is plenty)


The result would be slightly less efficient than a tr= ue binary JSON but not by very much. The tags will still be there.

JSON taged items have an overhead of 4 bytes per entry:= =A0"<tag>":<data>, =A0=A0

(= You can add in spaces but they aren't necessary.)

It would not be difficult to reduce those 4 bytes to on= e. But it isn't a big win either. The win comes from not having to Base= 64 the binary chunks.


For purposes of planning tags and making sure there is enough space it is p= robably best to start off expansively and considering all the possible type= s we might recognize

x80 =A0 =A0Terminal String 8 = bit length
x81 =A0 =A0Terminal String 16 bit length
x82 =A0 =A0Term= inal String 32 bit length
x83 =A0 =A0Terminal String 64 bit l= ength

x84 =A0 =A0Non Terminal String Chun= k 8 bit length
x85 =A0 =A0Non Terminal String Chunk 16 bit length
x86 = =A0 =A0Non Terminal String Chunk 32 bit length
x87 =A0 =A0Non= Terminal String Chunk 64 bit length

x88 =A0 = =A0Terminal=A0Binary=A08 bit length
x87 =A0 =A0Terminal=A0Binary=A016 bit length
x8A =A0 =A0= Terminal=A0Binary=A032 bit length
x8B =A0 =A0Terminal=A0Binar= y=A064 bit length

x8C =A0 =A0Non Terminal= =A0Binary=A0Chunk 8 bit length
x8D =A0 =A0Non Terminal=A0Binary=A0Chunk 16 bit length
x= 8E =A0 =A0Non Terminal=A0Binary=A0Chunk 32 bit length
x8F =A0= =A0Non Terminal=A0Binary=A0Chunk 64 bit length

<= /div>
x90 =A0 =A0IEEE 754 Floating Point binary16 =A0(1)
x91 =A0 = =A0IEEE 754 Floating Point binary32
x92 =A0 =A0IEEE 754 Float= ing Point binary64
x94 =A0 =A0IEEE 754 Floating Point binary1= 28 =A0(1)

x96 =A0 =A0IEEE 754 Floating Point decimal32 (1)
x97 =A0 =A0IEEE 754 Floating Point decimal64 (1)
x98 = =A0 =A0IEEE 754 Floating Point decimal128 =A0(1)

=
xA0 =A0 =A0Unsigned Integer 8 (1)
xA1 =A0 =A0Unsigned Integer 16 = (1)
xA2 =A0 =A0Unsigned Integer 32 (1)
xA3 =A0 = =A0Unsigned Integer 64 (1)
xA4 =A0 =A0Unsigned Integer 128 (1= )

xA5 =A0 =A0Signed Integer 8 (1)
xA6 =A0 =A0Si= gned Integer 16 (1)
xA7 =A0 =A0Signed Integer 32 (1)
xA8 =A0 =A0Signed Integer 64 (1)
xA9 =A0 =A0Signed Inte= ger 128 (1)

xAA =A0 =A0True
xAB =A0 =A0False
<= div>xAC =A0 =A0Null


(1) The need to= implement these codes is debatable. But the tag asignment scheme should no= t foreclose the possibility.

That still leaves a block of 72 codes unused. So if peo= ple wanted to go back and do binary tagging at a later date (JSON-C) that w= ould be possible.

I did try to work out some sort = of clever bit mask trick so that the lower bits of the code would specify t= he number of additional bytes to follow but that does not work so well as t= here are 128 bit values to consider. And at the end of the day there are on= ly going to be 60 odd code maximum so an array works fine.


I considered Nico's proposal of a &#= 39;continuation block' but that would require a reader to read in the s= tart of the next block before it can know what to do with the previous data= . The writer should know when it is starting to write out a chunk that more= chunks might follow or not. If no more data follows the writer just puts o= ut x80 x00 or x88 x00 to close the stream.



{To follow the rest it mi= ght help to look at the diagrams in=A0http://www.json.org/]

There are a few tricks that could be used here to further reduce space. con= sider the production "<tag>":<data>,

The initial " is not really needed since the only valid produ= ctions following an object open brace are the close brace or an element ent= ry. So " is only needed if you desperately want to have the possibilit= y of a tag '}drop tables'. OK now I get it, leave the initial "= ; in for Randall Munroe=A0http://xkcd.com/327/

If the reader sees a code above 7F it can only be= binary data so the ": separator between the tag and the data are supe= rfluous and could be elided

The binary data descriptions are all defined length and so the terminal , i= s not needed.


So if people wanted t= o, we could adjust the FSR to allow these abbreviations in JSON-B and save = the four bytes per object entry overhead. But that would still leave the ta= gs there and those can't be eliminated without some sort of dictionary,= either being passed on the wire (which is what compressors are really doin= g) or out of band (which is what schema aware is really about).


So for JSON-C we would need ways to defi= ne a binding of a tag to a code and ways of specifying those codes in objec= t productions.

Keeping the initial " helps us= here because it means that the only currently valid characters after the i= nitial { are ", } and whitespace.


We might just conceivably need more than= 64K codes, so the code value is potentially a 32 bit space.=A0
<= br>

So the codes I would define are:

C0 =A0 8 bit tag code follows
C1 =A0 16 bit t= ag code follows
C2 =A0 32 bit tag code follows

=
C4 =A0 =A08 bit definition follows =A0 =A0
C5 =A0 =A016 bit definition follows =A0
C6 =A0 =A032 bit= definition follows =A0

C7 =A0 =A08 bit t= ag with definition follows =A0 =A0
C8 =A0 =A016 bit tag with defi= nition follows =A0
C9 =A0 =A032 bit tag with definition follows=A0
=

the codes c4-c9 would be followed with a stri= ng definition. So the first occurrence of { "foo" : "data&qu= ot; } would become:

x7B =A0 =A0 =A0 =A0 =A0 =A0 =A0 {
xC7 x01 x80 x03 x66 x6f x6f =A0 =A0"foo": =A0 =A0 [Code 1]
=
x80 x04 x64 x61 x74 x61 =A0 =A0 =A0 =A0 =A0"data"
x7D =A0 =A0 =A0 =A0 =A0 =A0 =A0 }


On the second occurren= ce the definition is already there:

x7B =A0 =A0 =A0 =A0 =A0 =A0 =A0 {
xC0 x01 =A0[Code 1]
x80 x04 x64 x61 x74 x61 =A0 =A0 =A0 =A0 =A0"data"
x7D =A0 =A0 =A0 =A0 =A0 =A0 =A0 }

An implementation could simply dump the dictionary out at the start of the= message using the C4-C6 codes.


--
W= ebsite: http://hallam= baker.com/
--001a11c382c6526d9904dd8d31cc-- From cabo@tzi.org Sat May 25 13:08: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 6F88121F8763 for ; Sat, 25 May 2013 13:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.219 X-Spam-Level: X-Spam-Status: No, score=-106.219 tagged_above=-999 required=5 tests=[AWL=0.030, 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 m2FQOKG9uuR2 for ; Sat, 25 May 2013 13:07:55 -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 46DAC21F88FB for ; Sat, 25 May 2013 13:07:54 -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 r4PK7j50016835; Sat, 25 May 2013 22:07:45 +0200 (CEST) Received: from [192.168.217.105] (p548914E3.dip0.t-ipconnect.de [84.137.20.227]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C8B8239B6; Sat, 25 May 2013 22:07:44 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Sat, 25 May 2013 22:07:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <693D28F5-262E-46B6-B0EE-8FFEB6F2F276@tzi.org> References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> To: Nico Williams X-Mailer: Apple Mail (2.1503) Cc: Paul Hoffman , apps-discuss@ietf.org Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 25 May 2013 20:08:01 -0000 On May 23, 2013, at 19:19, Nico Williams wrote: > what the heck was so wrong with PER? That is actually an interesting story waiting to be analyzed. PER was enough of a problem that it became one of the major forces = killing H.323. Of course, that was at a time when we didn't yet all understand that = relying on closed-source implementations was creating tons of technical = debt. Also, this was before sourceforge, stackexchange, github, and all the = other things that help us manage complex collaborations much better = today. So I'm not sure the same level of complexity (or even PER itself) would = die such a horrible death today. (Actually, EXI might qualify as a nice demo that it can work quite well = today.) But I'm trying to work on the other end of the complexity scale, so = somebody else has to write that story down... Gr=FC=DFe, Carsten From hallam@gmail.com Sat May 25 17:40: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 6F87B21F8C38 for ; Sat, 25 May 2013 17:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.884 X-Spam-Level: X-Spam-Status: No, score=-0.884 tagged_above=-999 required=5 tests=[AWL=-1.451, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, J_BACKHAIR_33=1, 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 SyIE5D7amaRo for ; Sat, 25 May 2013 17:40:33 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7EC21F8B98 for ; Sat, 25 May 2013 17:40:32 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id a12so3427713wgh.11 for ; Sat, 25 May 2013 17:40:31 -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=/grb1Ly56Ratz9sPvg9BdVTmpT+0lTQ+2PE+eb/z3QE=; b=KkREuVmAdVaBFezkCGdgfBP4l/X3JItpWt0+AnLX3MDsyMY412+B/HAYNuXu6i0l9T ICnr8Fcru3S5Jc/tskTZaPJTD2EHk0OI87VBklOdVZZMOvLzAtSA/VxdjwZXv+OxvQpz 6WBatr6J+8TekXPIQAnFXY98iSI8OPFqyAo52v3RQq5mqCFIUXFlEUML0ZdVtg9phc0D ST/xKOiN3ZpQjAxCH2ec5jVkUcFbUIaK2Dml+E2gTGvKwJpSHf8a1Z/JusvtT38tFhMo scSzQ3lxdzkADA9MBAUtMmj+zgOsRppjvQPGd2VB+MAnUXFYc4rgH06L2TNqaPPhdp7y +VYQ== MIME-Version: 1.0 X-Received: by 10.180.79.200 with SMTP id l8mr3430600wix.60.1369528831442; Sat, 25 May 2013 17:40:31 -0700 (PDT) Received: by 10.194.44.100 with HTTP; Sat, 25 May 2013 17:40:31 -0700 (PDT) In-Reply-To: References: <61CB1D18-BABC-4C77-93E6-A9E8CDA8326B@vpnc.org> Date: Sat, 25 May 2013 20:40:31 -0400 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: multipart/alternative; boundary=f46d043bd77682078e04dd94477d Cc: Paul Hoffman , General discussion of application-layer protocols Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 May 2013 00:40:34 -0000 --f46d043bd77682078e04dd94477d Content-Type: text/plain; charset=ISO-8859-1 Just a thought. JSON-C would meet most if not all the requirements for HTTP/2.0 encoding. It is easy to parse/emit, it is easy to adapt an existing JSON stack to emit JSON-C. It is efficient in coding and in space and a Web service can use the same stack for HTTP framing and for the payload. On Sat, May 25, 2013 at 12:13 PM, Phillip Hallam-Baker wrote: > On Fri, May 24, 2013 at 11:28 PM, Nico Williams wrote: > >> Thinking about what *I* want in a binary JSON encoding, and taking >> into account PHB's points about online encoding and decoding, all I >> really want, the one thing I badly want, is counted-bytes and chunked >> Unicode and octet strings. That's it. So picture JSON, complete with >> square and curly brackets, but no commas nor colons, just strings >> (byte-counted or chunked), some encoding for numbers, booleans, and >> null. It's the handing of scalars that sucks about JSON: string >> escaping, number printing and parsing. >> >> Something like this: >> >> {foobar> to preceding string, length 3>baz> 3>num} >> >> as an encoding of { "foo": "barbaz", "num": 5 }, with "barbaz" chunked. >> >> One of the nice things about such an encoding is that it should be >> possible to implement as a fairly small variation on existing code: >> it's almost only a different way of encoding scalar types -- the only >> other difference being that commas and colons are not needed. >> >> With a variable-length encoding of integers and IEEE 754 64-bit >> doubles for reals... that's compact enough. Not nearly as compact as >> we could get with schemas and PER-like encodings, but good enough for >> a schema-less encoding. >> > > > I like this proposal, more a sort of JSON-B as in JSON Encoding B > > The only Con I can think of is that it will still be backwards > incompatible so why not be more compact? And people might worry about > JSON-B getting confused with JSON. > > > For my requirements, I think I would still like to be able to binary > encode floating point numbers. The issue there is the precision loss from > round tripping and the ability to encode NaN and +/- infinity > > But we do have the entire ASCII code set above 128 to play with (actually > we have more but above 128 is plenty) > > > The result would be slightly less efficient than a true binary JSON but > not by very much. The tags will still be there. > > JSON taged items have an overhead of 4 bytes per entry: "":, > > (You can add in spaces but they aren't necessary.) > > It would not be difficult to reduce those 4 bytes to one. But it isn't a > big win either. The win comes from not having to Base64 the binary chunks. > > > For purposes of planning tags and making sure there is enough space it is > probably best to start off expansively and considering all the possible > types we might recognize > > x80 Terminal String 8 bit length > x81 Terminal String 16 bit length > x82 Terminal String 32 bit length > x83 Terminal String 64 bit length > > x84 Non Terminal String Chunk 8 bit length > x85 Non Terminal String Chunk 16 bit length > x86 Non Terminal String Chunk 32 bit length > x87 Non Terminal String Chunk 64 bit length > > x88 Terminal Binary 8 bit length > x87 Terminal Binary 16 bit length > x8A Terminal Binary 32 bit length > x8B Terminal Binary 64 bit length > > x8C Non Terminal Binary Chunk 8 bit length > x8D Non Terminal Binary Chunk 16 bit length > x8E Non Terminal Binary Chunk 32 bit length > x8F Non Terminal Binary Chunk 64 bit length > > x90 IEEE 754 Floating Point binary16 (1) > x91 IEEE 754 Floating Point binary32 > x92 IEEE 754 Floating Point binary64 > x94 IEEE 754 Floating Point binary128 (1) > > x96 IEEE 754 Floating Point decimal32 (1) > x97 IEEE 754 Floating Point decimal64 (1) > x98 IEEE 754 Floating Point decimal128 (1) > > xA0 Unsigned Integer 8 (1) > xA1 Unsigned Integer 16 (1) > xA2 Unsigned Integer 32 (1) > xA3 Unsigned Integer 64 (1) > xA4 Unsigned Integer 128 (1) > > xA5 Signed Integer 8 (1) > xA6 Signed Integer 16 (1) > xA7 Signed Integer 32 (1) > xA8 Signed Integer 64 (1) > xA9 Signed Integer 128 (1) > > xAA True > xAB False > xAC Null > > > (1) The need to implement these codes is debatable. But the tag asignment > scheme should not foreclose the possibility. > > That still leaves a block of 72 codes unused. So if people wanted to go > back and do binary tagging at a later date (JSON-C) that would be possible. > > I did try to work out some sort of clever bit mask trick so that the lower > bits of the code would specify the number of additional bytes to follow but > that does not work so well as there are 128 bit values to consider. And at > the end of the day there are only going to be 60 odd code maximum so an > array works fine. > > > I considered Nico's proposal of a 'continuation block' but that would > require a reader to read in the start of the next block before it can know > what to do with the previous data. The writer should know when it is > starting to write out a chunk that more chunks might follow or not. If no > more data follows the writer just puts out x80 x00 or x88 x00 to close the > stream. > > > > {To follow the rest it might help to look at the diagrams in > http://www.json.org/] > > There are a few tricks that could be used here to further reduce space. > consider the production "":, > > The initial " is not really needed since the only valid productions > following an object open brace are the close brace or an element entry. So > " is only needed if you desperately want to have the possibility of a tag > '}drop tables'. OK now I get it, leave the initial " in for Randall Munroe > http://xkcd.com/327/ > > If the reader sees a code above 7F it can only be binary data so the ": > separator between the tag and the data are superfluous and could be elided > > The binary data descriptions are all defined length and so the terminal , > is not needed. > > > So if people wanted to, we could adjust the FSR to allow these > abbreviations in JSON-B and save the four bytes per object entry overhead. > But that would still leave the tags there and those can't be eliminated > without some sort of dictionary, either being passed on the wire (which is > what compressors are really doing) or out of band (which is what schema > aware is really about). > > > So for JSON-C we would need ways to define a binding of a tag to a code > and ways of specifying those codes in object productions. > > Keeping the initial " helps us here because it means that the only > currently valid characters after the initial { are ", } and whitespace. > > > We might just conceivably need more than 64K codes, so the code value is > potentially a 32 bit space. > > > So the codes I would define are: > > C0 8 bit tag code follows > C1 16 bit tag code follows > C2 32 bit tag code follows > > C4 8 bit definition follows > C5 16 bit definition follows > C6 32 bit definition follows > > C7 8 bit tag with definition follows > C8 16 bit tag with definition follows > C9 32 bit tag with definition follows > > > the codes c4-c9 would be followed with a string definition. So the first > occurrence of { "foo" : "data" } would become: > > x7B { > xC7 x01 x80 x03 x66 x6f x6f "foo": [Code 1] > x80 x04 x64 x61 x74 x61 "data" > x7D } > > > On the second occurrence the definition is already there: > > x7B { > xC0 x01 [Code 1] > x80 x04 x64 x61 x74 x61 "data" > x7D } > > An implementation could simply dump the dictionary out at the start of the > message using the C4-C6 codes. > > > -- > Website: http://hallambaker.com/ > -- Website: http://hallambaker.com/ --f46d043bd77682078e04dd94477d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Just a thought.

JSON-C would meet= most if not all the requirements for HTTP/2.0 encoding.
It is easy to parse/emit, it is easy to adapt an existin= g JSON stack to emit JSON-C. It is efficient in coding and in space and a W= eb service can use the same stack for HTTP framing and for the payload.


On Sat,= May 25, 2013 at 12:13 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
On Fri, M= ay 24, 2013 at 11:28 PM, Nico Williams <nico@cryptonector.com><= /span> wrote:
Thinking about what *I* want in a binary JSON encoding, an= d taking
into account PHB's points about online encoding and decoding, all I
really want, the one thing I badly want, is counted-bytes and chunked
Unicode and octet strings. =A0That's it. =A0So picture JSON, complete w= ith
square and curly brackets, but no commas nor colons, just strings
(byte-counted or chunked), some encoding for numbers, booleans, and
null. =A0It's the handing of scalars that sucks about JSON: string
escaping, number printing and parsing.

Something like this:

{<Unicode string of length 3>foo<Unicode string of length 3>bar= <join
to preceding string, length 3>baz<Unicode string of length
3>num<integer value 5>}

as an encoding of { "foo": "barbaz", "num": 5= }, with "barbaz" chunked.

One of the nice things about such an encoding is that it should be
possible to implement as a fairly small variation on existing code:
it's almost only a different way of encoding scalar types -- the only other difference being that commas and colons are not needed.

With a variable-length encoding of integers and IEEE 754 64-bit
doubles for reals... that's compact enough. =A0Not nearly as compact as=
we could get with schemas and PER-like encodings, but good enough for
a schema-less encoding.


I like this proposal, more a sort of JSON-B as in JSON Encoding B=A0<= /div>

The only Con I can think of is that it will = still be backwards incompatible so why not be more compact? And people migh= t worry about JSON-B getting confused with JSON.


For my requirements, I think I would sti= ll like to be able to binary encode floating point numbers. The issue there= is the precision loss from round tripping and the ability to encode NaN an= d +/- infinity

But we do have the entire ASCII code set above 128 to p= lay with (actually we have more but above 128 is plenty)


The result would be slightly less efficient than a tr= ue binary JSON but not by very much. The tags will still be there.

JSON taged items have an overhead of 4 bytes per entry:= =A0"<tag>":<data>, =A0=A0

(= You can add in spaces but they aren't necessary.)

It would not be difficult to reduce those 4 bytes to on= e. But it isn't a big win either. The win comes from not having to Base= 64 the binary chunks.


For purposes of planning tags and making sure there is enough space it is p= robably best to start off expansively and considering all the possible type= s we might recognize

x80 =A0 =A0Terminal String 8 = bit length
x81 =A0 =A0Terminal String 16 bit length
x82 =A0 =A0Term= inal String 32 bit length
x83 =A0 =A0Terminal String 64 bit l= ength

x84 =A0 =A0Non Terminal String Chun= k 8 bit length
x85 =A0 =A0Non Terminal String Chunk 16 bit length
x86 = =A0 =A0Non Terminal String Chunk 32 bit length
x87 =A0 =A0Non= Terminal String Chunk 64 bit length

x88 =A0 = =A0Terminal=A0Binary=A08 bit length
x87 =A0 =A0Terminal=A0Binary=A016 bit length
x8A =A0 =A0= Terminal=A0Binary=A032 bit length
x8B =A0 =A0Terminal=A0Binar= y=A064 bit length

x8C =A0 =A0Non Terminal= =A0Binary=A0Chunk 8 bit length
x8D =A0 =A0Non Terminal=A0Binary=A0Chunk 16 bit length
x= 8E =A0 =A0Non Terminal=A0Binary=A0Chunk 32 bit length
x8F =A0= =A0Non Terminal=A0Binary=A0Chunk 64 bit length

<= /div>
x90 =A0 =A0IEEE 754 Floating Point binary16 =A0(1)
x91 =A0 = =A0IEEE 754 Floating Point binary32
x92 =A0 =A0IEEE 754 Float= ing Point binary64
x94 =A0 =A0IEEE 754 Floating Point binary1= 28 =A0(1)

x96 =A0 =A0IEEE 754 Floating Point decimal32 (1)
x97 =A0 =A0IEEE 754 Floating Point decimal64 (1)
x98 = =A0 =A0IEEE 754 Floating Point decimal128 =A0(1)

=
xA0 =A0 =A0Unsigned Integer 8 (1)
xA1 =A0 =A0Unsigned Integer 16 = (1)
xA2 =A0 =A0Unsigned Integer 32 (1)
xA3 =A0 = =A0Unsigned Integer 64 (1)
xA4 =A0 =A0Unsigned Integer 128 (1= )

xA5 =A0 =A0Signed Integer 8 (1)
xA6 =A0 =A0Si= gned Integer 16 (1)
xA7 =A0 =A0Signed Integer 32 (1)
xA8 =A0 =A0Signed Integer 64 (1)
xA9 =A0 =A0Signed Inte= ger 128 (1)

xAA =A0 =A0True
xAB =A0 =A0False
<= div>xAC =A0 =A0Null


(1) The need to= implement these codes is debatable. But the tag asignment scheme should no= t foreclose the possibility.

That still leaves a block of 72 codes unused. So if peo= ple wanted to go back and do binary tagging at a later date (JSON-C) that w= ould be possible.

I did try to work out some sort = of clever bit mask trick so that the lower bits of the code would specify t= he number of additional bytes to follow but that does not work so well as t= here are 128 bit values to consider. And at the end of the day there are on= ly going to be 60 odd code maximum so an array works fine.


I considered Nico's proposal of a &#= 39;continuation block' but that would require a reader to read in the s= tart of the next block before it can know what to do with the previous data= . The writer should know when it is starting to write out a chunk that more= chunks might follow or not. If no more data follows the writer just puts o= ut x80 x00 or x88 x00 to close the stream.



{To follow the rest it mi= ght help to look at the diagrams in=A0http://www.json.org/]

There are a few tricks that could be used here to further reduce space. con= sider the production "<tag>":<data>,

The initial " is not really needed since the only valid produ= ctions following an object open brace are the close brace or an element ent= ry. So " is only needed if you desperately want to have the possibilit= y of a tag '}drop tables'. OK now I get it, leave the initial "= ; in for Randall Munroe=A0http://xkcd.com/327/

If the reader sees a code above 7F it can only be= binary data so the ": separator between the tag and the data are supe= rfluous and could be elided

The binary data descriptions are all defined length and so the terminal , i= s not needed.


So if people wanted t= o, we could adjust the FSR to allow these abbreviations in JSON-B and save = the four bytes per object entry overhead. But that would still leave the ta= gs there and those can't be eliminated without some sort of dictionary,= either being passed on the wire (which is what compressors are really doin= g) or out of band (which is what schema aware is really about).


So for JSON-C we would need ways to defi= ne a binding of a tag to a code and ways of specifying those codes in objec= t productions.

Keeping the initial " helps us= here because it means that the only currently valid characters after the i= nitial { are ", } and whitespace.


We might just conceivably need more than= 64K codes, so the code value is potentially a 32 bit space.=A0
<= br>

So the codes I would define are:

C0 =A0 8 bit tag code follows
C1 =A0 16 bit t= ag code follows
C2 =A0 32 bit tag code follows

=
C4 =A0 =A08 bit definition follows =A0 =A0
C5 =A0 =A016 bit definition follows =A0
C6 =A0 =A032 bit= definition follows =A0

C7 =A0 =A08 bit t= ag with definition follows =A0 =A0
C8 =A0 =A016 bit tag with defi= nition follows =A0
C9 =A0 =A032 bit tag with definition follows=A0
=

the codes c4-c9 would be followed with a stri= ng definition. So the first occurrence of { "foo" : "data&qu= ot; } would become:

x7B =A0 =A0 =A0 =A0 =A0 =A0 =A0 {
xC7 x01 x80= x03 x66 x6f x6f =A0 =A0"foo": =A0 =A0 [Code 1]
x80 x04= x64 x61 x74 x61 =A0 =A0 =A0 =A0 =A0"data"
x7D =A0 =A0 = =A0 =A0 =A0 =A0 =A0 }


On the second occurrence the definition = is already there:

x7B =A0 =A0 =A0 =A0 =A0 =A0= =A0 {
xC0 x01 =A0[Code 1]
x80 x04 x64 x61 x74 x61 =A0 = =A0 =A0 =A0 =A0"data"
x7D =A0 =A0 =A0 =A0 =A0 =A0 =A0 }

An im= plementation could simply dump the dictionary out at the start of the messa= ge using the C4-C6 codes.


--
Website: http://hallambaker.com/



--
Website: http://hallambaker.com/
--f46d043bd77682078e04dd94477d-- From ioseb.dzmanashvili@gmail.com Sun May 26 04:21: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 05BEB21F8FBA for ; Sun, 26 May 2013 04:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3c6ZOSrd8ft0 for ; Sun, 26 May 2013 04:21:56 -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 CD44B21F9008 for ; Sun, 26 May 2013 04:21:55 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id p58so3589154wes.7 for ; Sun, 26 May 2013 04:21: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:subject:x-mailer:mime-version :content-type; bh=W4Y+RMGSINsTpqXiXSI/S2WiP60d9Vy9CY4Fj1+OpL8=; b=tWyrVKq6aODmBCkA2TUeeCQ2fi7ozWySruFsstvTbGGr3svF1d0DZz3At45nDSxYwj u8QRaYm6opWg9dwj8nwNpgis48mbT5mjX3wyuRQipuZ7eg5pdUQaLQtuWI12ePQVhIRx /vOofoM4veQaAvvfWMyuENFWbx4Jes05If0CP8Ne55C8dO56kaZS0wrhR96/pXimL1MZ yan9hw7rQCkUHmJqMz5ThRQ5WVn4GBJECljydU/jcVBIasU8D9QTsY8xUpvL6bmK1UCZ J9dau9pYul7lCk5J/qKqBkkm3PrFlV3sizFVfod7IMGWGMHfRZI9MvuWK4cnuWrFpXje aPjQ== X-Received: by 10.180.184.2 with SMTP id eq2mr4760726wic.50.1369567314974; Sun, 26 May 2013 04:21:54 -0700 (PDT) Received: from [192.168.1.7] ([176.73.174.236]) by mx.google.com with ESMTPSA id c5sm19372482eeu.8.2013.05.26.04.21.53 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 26 May 2013 04:21:54 -0700 (PDT) Date: Sun, 26 May 2013 15:21:46 +0400 From: Ioseb Dzmanashvili To: link-relations@ieft.org Message-ID: <4038B5FE76874C54A819A07FE192AEF8@gmail.com> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="51a1f04a_333ab105_1b1" Cc: apps-discuss@ietf.org Subject: [apps-discuss] NEW RELATION: property and context X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 May 2013 11:21:57 -0000 --51a1f04a_333ab105_1b1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear All, I've submitted new draft for the "property" and "context" link relation types: http://tools.ietf.org/html/draft-property-and-context-link-relations-00 Description: - This specification defines link relation types that may be used to express the relationships between a resource and associated properties or between a resource and it's context. - The "property" and "context" link relations are intentionally generic, and they can be used with multiple media types in a wide variety of use cases - The "property" Link Relation Type: When included in a response, the "property" link relation identifies a target resource that represents a property of the context resource. - The "context" Link Relation Type: When included in a response, the "context" link relation identifies a target resource that represents a context document of which the context resource is a member. Could you please review? Thanks in advance! Best regards, ioseb -- Ioseb Dzmanashvili AzRy LLC Software Architect #8, Chachava str. Tbilisi, 0159, Georgia Mobile: +(995) 99753388 github.com/ioseb twitter.com/iosebi --51a1f04a_333ab105_1b1 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Dear All,

I've submitted new draft for th= e =22property=22 and =22context=22 link relation types: http://tools.ietf.org/html/draft-property-and-context-link-relations-00<= /a>


=
- The =22context=22 Link Relation Type: When included in a= response, the =22context=22 link relation identifies a target resource t= hat represents a context document of which the context resource is a memb= er.

Could you please review=3F<= /div>
Thanks in advance=21

Best regard= s,
ioseb
-- 
Ioseb Dzmanashvili
AzRy LLC
Software Architect
=238, Chach= ava str.
Tbilisi, 0159, Georgia
Mobile: +(995) = 99753388
github.com/ioseb
twitter.com/iosebi
--51a1f04a_333ab105_1b1-- From mca@amundsen.com Sun May 26 04:45: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 59EEE21F86C3 for ; Sun, 26 May 2013 04:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.92 X-Spam-Level: X-Spam-Status: No, score=0.92 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, 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 TDicqvwCA9LA for ; Sun, 26 May 2013 04:45:29 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAE821F8651 for ; Sun, 26 May 2013 04:45:28 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id j13so2264851wgh.21 for ; Sun, 26 May 2013 04:45:28 -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=OaNBt2eduinclQucIuX15fILuuShNZ7CTIkSJE3pR34=; b=KaT2h/k2PEhOnF6fuJp0qO9ZUeA+42dYDZRwIOQmjKetkjPVgq7iRXQ4WIlRwYbkP2 /vjPWIawjRYdxzIkdg0zKH1/9MRHpDZiQib8RBX2TW02ilR3IY3WkDF9nfS9us6mv187 fTzvEN8V7NSoNxVKYLnCdegDtIvfgy9BBwdpXJvLzHvyIRCi7KPcCGo0jgyFUkpqQW0t TMQkFKr74MWx622KvxDRTMwYydw7t+scibpaUK0xe+m/xEANM/7EtECk7A3qdLydN46k /DC2Np4pFcma3AgyR/bx10J47gZ1R5uW6bcwCieZbBPAli6+4IW5hw9dPP72KiSDrBXv HNRw== X-Received: by 10.194.61.140 with SMTP id p12mr5325321wjr.51.1369568728225; Sun, 26 May 2013 04:45:28 -0700 (PDT) MIME-Version: 1.0 Sender: mca@amundsen.com Received: by 10.194.239.138 with HTTP; Sun, 26 May 2013 04:45:08 -0700 (PDT) In-Reply-To: <4038B5FE76874C54A819A07FE192AEF8@gmail.com> References: <4038B5FE76874C54A819A07FE192AEF8@gmail.com> From: mike amundsen Date: Sun, 26 May 2013 07:45:08 -0400 X-Google-Sender-Auth: _L7pWZCr4FZ_NbdW854Nymnth30 Message-ID: To: Ioseb Dzmanashvili Content-Type: multipart/alternative; boundary=047d7b86de7c8aad4304dd9d9160 X-Gm-Message-State: ALoCoQl+Qr5lGdw6L0/ctIEHicUMMF/IT1yWsxvrHdzAf+OqUtc7xRryU07nidnj5KKtiJolhmeR Cc: link-relations@ieft.org, IETF Apps Discuss Subject: Re: [apps-discuss] NEW RELATION: property and context X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 May 2013 11:45:30 -0000 --047d7b86de7c8aad4304dd9d9160 Content-Type: text/plain; charset=ISO-8859-1 How are these different from the "collection" and "item" link relations? IOW, what can be described by "context" and "property" that cannot be described by "collection" and "item"? 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 Sun, May 26, 2013 at 7:21 AM, Ioseb Dzmanashvili < ioseb.dzmanashvili@gmail.com> wrote: > Dear All, > > I've submitted new draft for the "property" and "context" link relation > types: > http://tools.ietf.org/html/draft-property-and-context-link-relations-00 > > Description: > > - This specification defines link relation types that may be used to > express the relationships between a resource and associated properties or > between a resource and it's context. > - The "property" and "context" link relations are intentionally generic, > and they can be used with multiple media types in a wide variety of use > cases > - The "property" Link Relation Type: When included in a response, the > "property" link relation identifies a target resource that represents a > property of the context resource. > - The "context" Link Relation Type: When included in a response, the > "context" link relation identifies a target resource that represents a > context document of which the context resource is a member. > > Could you please review? > Thanks in advance! > > Best regards, > ioseb > -- > Ioseb Dzmanashvili > AzRy LLC > Software Architect > #8, Chachava str. > Tbilisi, 0159, Georgia > Mobile: +(995) 99753388 > github.com/ioseb > twitter.com/iosebi > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > --047d7b86de7c8aad4304dd9d9160 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

How are these different from= the "collection" and "item" link relations?

IOW, what can be described by=A0"context" and=A0= "property" =A0that cannot be=A0described by= "collection" and "item"?

On Sun, May 26, 2013 at 7:21 AM, Ioseb D= zmanashvili <ioseb.dzmanashvili@gmail.com> wrote:=
Dear All,

I've submitted new draft for = the "property" and "context" link relation types:=A0http://tools.ietf.org/html/draft-property-and-conte= xt-link-relations-00

Description:=A0

- This sp= ecification defines link relation types that may be used=A0to express the r= elationships between a resource and associated=A0properties or between a re= source and it's context.
- The "property" and "context" link relations are = intentionally=A0generic, and they can be used with multiple media types in = a wide=A0variety of use cases
- The "property" Li= nk Relation Type:=A0When included in a response, the "property" l= ink relation identifies a target resource that represents a property of the= context resource.
- The "context" Link Relation Type:=A0When included in = a response, the "context" link relation identifies a target resou= rce that represents a context document of which the context resource is a m= ember.

Could you please review?
Thanks in advance!

Best regards,
=
ioseb
--=A0
Ioseb Dzmanashvili
AzRy LLC
Software Architec= t
#8, Chachava str.
Tbilisi, 0159, Georgia
Mobile: +(995) 99753388

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


--047d7b86de7c8aad4304dd9d9160-- From ioseb.dzmanashvili@gmail.com Sun May 26 04:51: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 F1D5121F9003; Sun, 26 May 2013 04:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_102=0.6, J_CHICKENPOX_52=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 mYU7OHI1Xbnu; Sun, 26 May 2013 04:51:20 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 83B0A21F9017; Sun, 26 May 2013 04:51:18 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id k13so1476769wgh.2 for ; Sun, 26 May 2013 04:51:17 -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:x-mailer :mime-version:content-type; bh=SUSWvmG777bylWLCgbWiXKIVDHpz5fI3fa+1PPHch2c=; b=KaTCQfSA6E8ELHxiBlgjPw1G4S46OKoCvPeuMPvFN7eUBxOFhDX0xhdukUp8eR8wxw 2vbNuHD7QZDEoKi0RTzWQs8l5bQNXLBIBrH9o7XQnM3Lq5BnmWjrM1oZQiydqmb8KEn2 6NiKpDoC15/T16Tji2AWL592VvYRGkf7aOIQsXlscfl22v6R8+i8uGTfTGud3BdxFmFp wTzya961qv6rqSv3+HAvLIF7388aSkTghnS4+6wWuO7WhmWOObqhZXhPTGsBu7TVWjXB kbiySVfFmqaUYTxX0MvjmKXP3sAWfYduvHnNZdCx4aBxIfWJgEpmrVxePjNqlrHxw6mL 96NQ== X-Received: by 10.194.216.39 with SMTP id on7mr5367429wjc.4.1369569077676; Sun, 26 May 2013 04:51:17 -0700 (PDT) Received: from [192.168.1.7] ([176.73.174.236]) by mx.google.com with ESMTPSA id f1sm6661949eem.17.2013.05.26.04.51.15 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 26 May 2013 04:51:16 -0700 (PDT) Date: Sun, 26 May 2013 15:51:14 +0400 From: Ioseb Dzmanashvili To: mca Message-ID: <87B38357AED34BF89465EC5111A090EA@gmail.com> In-Reply-To: References: <4038B5FE76874C54A819A07FE192AEF8@gmail.com> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="51a1f732_22221a70_1b1" Cc: IETF Apps Discuss , "=?utf-8?Q?link-relations=40ietf.org?=" Subject: Re: [apps-discuss] NEW RELATION: property and context X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 May 2013 11:51:21 -0000 --51a1f732_22221a70_1b1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Mike, Thanks for response! > How are these different from the "collection" and "item" link relations? > IOW, what can be described by "property" and "context" that cannot be described by "collection" and "item"? It depends how we look at things. For example if if we've a resource that is a photo(or video etc...) we can not describe it as a collection. If we've resource which is a property of that photo we can indicate the context resource of this photo with the "context" link relation, as i understand and see it the "collection" link relation doesn't properly describe photo which definitely is not a collection of items itself. Another example is a file which has various attributes(or properties), if for example i want to express these properties of the file as links i think the "property" link relation will be more correct rather than the "item" link relation IMHO. ioseb On Sunday, May 26, 2013 at 3:38 PM, mca wrote: > How are these different from the "collection" and "item" link relations? > IOW, what can be described by "property" and "context" that cannot be described by "collection" and "item"? > On May 26, 2013 1:22 PM, "Ioseb Dzmanashvili" wrote: > > Dear All, > > > > I've submitted new draft for the "property" and "context" link relation types: http://tools.ietf.org/html/draft-property-and-context-link-relations-00 > > > > Description: > > > > - This specification defines link relation types that may be used to express the relationships between a resource and associated properties or between a resource and it's context. > > - The "property" and "context" link relations are intentionally generic, and they can be used with multiple media types in a wide variety of use cases > > > > - The "property" Link Relation Type: When included in a response, the "property" link relation identifies a target resource that represents a property of the context resource. > > - The "context" Link Relation Type: When included in a response, the "context" link relation identifies a target resource that represents a context document of which the context resource is a member. > > > > > > Could you please review? > > Thanks in advance! > > > > > > Best regards, > > ioseb > > -- > > Ioseb Dzmanashvili > > AzRy LLC > > Software Architect > > #8, Chachava str. > > Tbilisi, 0159, Georgia > > > > Mobile: +(995) 99753388 > > github.com/ioseb (http://github.com/ioseb) > > twitter.com/iosebi (http://twitter.com/iosebi) > > > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org (mailto:apps-discuss@ietf.org) > > https://www.ietf.org/mailman/listinfo/apps-discuss > > --51a1f732_22221a70_1b1 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Mike,

Thanks for respons= e=21

> How are these different from the = =22collection=22 and =22item=22 link relations=3F
> IOW, wha= t can be described by =22property=22 and =22context=22 that cannot be des= cribed by =22collection=22 and =22item=22=3F

It = depends how we look at things. =46or example if if we've a resource that = is a photo(or video etc...) we can not describe it as a collection. If we= 've resource which is a property of that photo we can indicate the contex= t resource of this photo with the =22context=22 link relation, as i under= stand and see it the =22collection=22 link relation doesn't properly desc= ribe photo which definitely is not a collection of items itself.

Another example is a file which has various attributes(o= r properties), if for example i want to express these properties of the f= ile as links i think the =22property=22 link relation will be more correc= t rather than the =22item=22 link relation IMHO.

ioseb
=20

On Sunday, May 26, 201= 3 at 3:38 PM, mca wrote:

How are these diff= erent from the =22collection=22 and =22item=22 link relations=3F

IOW, what can be described by =22property=22 and =22co= ntext=22 that cannot be described by =22collection=22 and =22item=22=3F

On May 26, 2013 1:22 PM, =22Ioseb Dzmanashvili=22 <ioseb.dzmanashvili=40gmail.com> wrote:
Dear All,


Description: 

- Th= is specification defines link relation types that may be used to exp= ress the relationships between a resource and associated properties = or between a resource and it's context.
- The =22property=22 and =22context=22 link relations are intentiona= lly generic, and they can be used with multiple media types in a wid= e variety of use cases
- The =22property=22 Link Rel= ation Type: When included in a response, the =22property=22 link rel= ation identifies a target resource that represents a property of the cont= ext resource.
- The =22context=22 Link Relation Type: When included in a= response, the =22context=22 link relation identifies a target resource t= hat represents a context document of which the context resource is a memb= er.

Could you please review=3F<= /div>
Thanks in advance=21

Best regard= s,
ioseb
-- 
Ioseb Dzmanashvili
AzRy LLC
Software Architect
=238, Chachava str.
Tbil= isi, 0159, Georgia
Mobile: +(995) 99753388

=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
https://www.ietf.org/mailman/listinfo/apps-discuss<= br>
=20 =20 =20 =20
=20

--51a1f732_22221a70_1b1-- From ioseb.dzmanashvili@gmail.com Sun May 26 05:00:27 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82CD321F8551; Sun, 26 May 2013 05:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_102=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_52=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 iqZVJFTtAo+T; Sun, 26 May 2013 05:00:26 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id EBEBC21F85D1; Sun, 26 May 2013 05:00:25 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hi5so853713wib.2 for ; Sun, 26 May 2013 05:00:25 -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:x-mailer :mime-version:content-type; bh=8H0vG9ZKp32W7E/BlQfnFmURAOnP25eduORAP8U9YSw=; b=ESJYeky+21zkl3g12RqyoAJ0yv0R5e/DG264v2t7WLkjLPey9wlNJPOs7lS6H/ZnX+ hNF3Ewt2KPCcC2yGl3Mb7sVRYE4S1zJPkhI7xnIfLfa0vrfUYzGYCJNZ1GntD7BBUJfT PDtF5si7i8Fts4tafZbQa2+fqos32Ypge7qcXNEts6WXmQecCMi/NKPEmwP6yIUUpPBb ANyC+9mCSiNLhCI7t/ZQuDuISfoOkhUDBy34WCk9/35nztbl7UYcuR1lopH7cCd3SQWw c6cRhYY2bZ3QmziFWo+Fy6N+Oxf3dtLsqGsKGYJeT/dF781xzamw2HyRYjHAmlmrC28y WIGA== X-Received: by 10.194.134.161 with SMTP id pl1mr5364601wjb.31.1369569625004; Sun, 26 May 2013 05:00:25 -0700 (PDT) Received: from [192.168.1.7] ([176.73.174.236]) by mx.google.com with ESMTPSA id bo9sm21325251eeb.9.2013.05.26.05.00.22 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 26 May 2013 05:00:24 -0700 (PDT) Date: Sun, 26 May 2013 16:00:21 +0400 From: Ioseb Dzmanashvili To: mca Message-ID: <12C4054A6F864F9B8A7E6058ADC14687@gmail.com> In-Reply-To: References: <4038B5FE76874C54A819A07FE192AEF8@gmail.com> <87B38357AED34BF89465EC5111A090EA@gmail.com> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="51a1f955_5577f8e1_1b1" Cc: IETF Apps Discuss , "=?utf-8?Q?link-relations=40ietf.org?=" Subject: Re: [apps-discuss] NEW RELATION: property and context X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 May 2013 12:00:27 -0000 --51a1f955_5577f8e1_1b1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Mike, > so your thinking is that the attributes of a file is not a "collection"? No, i think that attributes of a file is a collection, but i do not think that a file is a collection of attributes. Another example: If i have an article with a photo(or whatever else), does it makes that article collection of photos(or other properties which are part of that article)? If i'm viewing photo can i say that hey here is the collection which this photo belongs to? or wouldn't it be more precise if i say hey here is the context to which this photo belongs to? ioseb On Sunday, May 26, 2013 at 3:52 PM, mca wrote: > Ioseb: > > so your thinking is that the attributes of a file is not a "collection"? > > mca > +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 Sun, May 26, 2013 at 7:51 AM, Ioseb Dzmanashvili wrote: > > Hi Mike, > > > > Thanks for response! > > > > > How are these different from the "collection" and "item" link relations? > > > IOW, what can be described by "property" and "context" that cannot be described by "collection" and "item"? > > > > It depends how we look at things. For example if if we've a resource that is a photo(or video etc...) we can not describe it as a collection. If we've resource which is a property of that photo we can indicate the context resource of this photo with the "context" link relation, as i understand and see it the "collection" link relation doesn't properly describe photo which definitely is not a collection of items itself. > > > > Another example is a file which has various attributes(or properties), if for example i want to express these properties of the file as links i think the "property" link relation will be more correct rather than the "item" link relation IMHO. > > > > ioseb > > > > On Sunday, May 26, 2013 at 3:38 PM, mca wrote: > > > > > How are these different from the "collection" and "item" link relations? > > > IOW, what can be described by "property" and "context" that cannot be described by "collection" and "item"? > > > On May 26, 2013 1:22 PM, "Ioseb Dzmanashvili" wrote: > > > > Dear All, > > > > > > > > I've submitted new draft for the "property" and "context" link relation types: http://tools.ietf.org/html/draft-property-and-context-link-relations-00 > > > > > > > > Description: > > > > > > > > - This specification defines link relation types that may be used to express the relationships between a resource and associated properties or between a resource and it's context. > > > > - The "property" and "context" link relations are intentionally generic, and they can be used with multiple media types in a wide variety of use cases > > > > > > > > - The "property" Link Relation Type: When included in a response, the "property" link relation identifies a target resource that represents a property of the context resource. > > > > - The "context" Link Relation Type: When included in a response, the "context" link relation identifies a target resource that represents a context document of which the context resource is a member. > > > > > > > > > > > > Could you please review? > > > > Thanks in advance! > > > > > > > > > > > > Best regards, > > > > ioseb > > > > -- > > > > Ioseb Dzmanashvili > > > > AzRy LLC > > > > Software Architect > > > > #8, Chachava str. > > > > Tbilisi, 0159, Georgia > > > > > > > > Mobile: +(995) 99753388 > > > > github.com/ioseb (http://github.com/ioseb) > > > > twitter.com/iosebi (http://twitter.com/iosebi) > > > > > > > > > > > > > > > > _______________________________________________ > > > > apps-discuss mailing list > > > > apps-discuss@ietf.org (mailto:apps-discuss@ietf.org) > > > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > > --51a1f955_5577f8e1_1b1 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Mike,

> so your thi= nking is that the attributes of a file is not a =22collection=22=3F
=

No, i think that attributes of a file is a collection= , but i do not think that a file is a collection of attributes. 

Another example:

If i have= an article with a photo(or whatever else), does it makes that article co= llection of photos(or other properties which are part of that article)=3F= If i'm viewing photo can i say that hey here is the collection which thi= s photo belongs to=3F or wouldn't it be more precise if i say hey here is= the context to which this photo belongs to=3F

i= oseb
=20

On Sunday, May 26, 201= 3 at 3:52 PM, mca wrote:

Ioseb:

<= /div>
so your thinking is that the attributes of a fil= e is not a =22collection=22=3F


On Sun, May 26, 2013 at 7:51 AM, Ioseb Dzmanashvili <ioseb.dzmanashvili=40gmail.com> wrot= e:
Hi Mike,

Thanks for respons= e=21

> How are these different from= the =22collection=22 and =22item=22 link relations=3F
> IOW, what can be described by =22property=22 and =22context=22 = that cannot be described by =22collection=22 and =22item=22=3F
=
It depends how we look at things. =46or example if i= f we've a resource that is a photo(or video etc...) we can not describe i= t as a collection. If we've resource which is a property of that photo we= can indicate the context resource of this photo with the =22context=22 l= ink relation, as i understand and see it the =22collection=22 link relati= on doesn't properly describe photo which definitely is not a collection o= f items itself.

Another example is a file which has various attribute= s(or properties), if for example i want to express these properties of th= e file as links i think the =22property=22 link relation will be more cor= rect rather than the =22item=22 link relation IMHO.

ioseb
=
=20

On Sunday, May 26, 2013 = at 3:38 PM, mca wrote:

How are these diff= erent from the =22collection=22 and =22item=22 link relations=3F

IOW, what can be described by =22property=22 and =22co= ntext=22 that cannot be described by =22collection=22 and =22item=22=3F

On May 26, 2013 1:22 PM, =22Ioseb Dzmanashvili=22 <ioseb.dzm= anashvili=40gmail.com> wrote:
Dear All,

I've submitted new draft for th= e =22property=22 and =22context=22 link relation types: http://tools.ietf.org/html/draft-property-and-co= ntext-link-relations-00

Description: 

- Th= is specification defines link relation types that may be used to exp= ress the relationships between a resource and associated properties = or between a resource and it's context.
- The =22property=22 and =22context=22 link relations are intentiona= lly generic, and they can be used with multiple media types in a wid= e variety of use cases
- The =22property=22 Link Rel= ation Type: When included in a response, the =22property=22 link rel= ation identifies a target resource that represents a property of the cont= ext resource.
- The =22context=22 Link Relation Type: When included in a= response, the =22context=22 link relation identifies a target resource t= hat represents a context document of which the context resource is a memb= er.

Could you please review=3F<= /div>
Thanks in advance=21

Best regard= s,
ioseb
-- 
Ioseb Dzmanashvili
AzRy LLC
Software Architect
=238, Chachava str.
Tbil= isi, 0159, Georgia
Mobile: +(995) 99753388

=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
ap= ps-discuss=40ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= br>
=20 =20 =20 =20


=20 =20 =20 =20 =20

--51a1f955_5577f8e1_1b1-- From jan.algermissen@nordsc.com Sun May 26 10:01: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 546E821F8A74 for ; Sun, 26 May 2013 10:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 NcbULwGZlLud for ; Sun, 26 May 2013 10:00:57 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 982C021F8D90 for ; Sun, 26 May 2013 10:00:52 -0700 (PDT) Received: from [192.168.2.102] (p548FD831.dip0.t-ipconnect.de [84.143.216.49]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0Luahc-1UGQEL2uKu-00zrR2; Sun, 26 May 2013 19:00:49 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jan Algermissen In-Reply-To: <4038B5FE76874C54A819A07FE192AEF8@gmail.com> Date: Sun, 26 May 2013 19:00:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6E466260-0DDC-4B7F-8FB1-9DAF59BD1BB7@nordsc.com> References: <4038B5FE76874C54A819A07FE192AEF8@gmail.com> To: Ioseb Dzmanashvili X-Mailer: Apple Mail (2.1503) X-Provags-ID: V02:K0:ef7TSsx7UXOoLSg68S4B1KfaMKj8lIjWsnEFkHE6hW8 TRjNfQkRg2bJ7pMegw4Pzlej+pc0RRWz0Hrp+1WmA80uxcscsE kEr3Om+/FHIlNo0+1PL2EMDrYcPzhUib7bm9H1JV4ZRQg6Kb5I AGYjD/JkxTo2BdEw2aIBW2Rp2oIxs0R+IuhNumLK4byr5Xbufd BbpDP8l+nMuYTE5AgO4Cv1Ztcrg+1EMEoYNx96u9Rh5pLYLo1i TwfPiFNsK5PNXmGBtPKae/QBjisHwyI3GoeByywuUBbWJlpxt9 y85AatpcDXd18uJrfd7iD2QP3hDb5tERNEtbQ+fzGOxP/AHelY RhfawN6VIVUQKPUZ+qUOwWOb/4F3fusfaGDUSrC7/zeMW/kp8u /B1+7+NPv3Kcw== Cc: link-relations@ieft.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] NEW RELATION: property and context X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 May 2013 17:01:01 -0000 Ioseb, On 26.05.2013, at 13:21, Ioseb Dzmanashvili = wrote: > Dear All, >=20 > I've submitted new draft for the "property" and "context" link = relation types: = http://tools.ietf.org/html/draft-property-and-context-link-relations-00 It feels a bit like reinventing RDF. What is the difference exactly between a property and a link? Jan >=20 > Description:=20 >=20 > - This specification defines link relation types that may be used to = express the relationships between a resource and associated properties = or between a resource and it's context. > - The "property" and "context" link relations are intentionally = generic, and they can be used with multiple media types in a wide = variety of use cases > - The "property" Link Relation Type: When included in a response, the = "property" link relation identifies a target resource that represents a = property of the context resource. > - The "context" Link Relation Type: When included in a response, the = "context" link relation identifies a target resource that represents a = context document of which the context resource is a member. >=20 > Could you please review? > Thanks in advance! >=20 > Best regards, > ioseb > --=20 > Ioseb Dzmanashvili > AzRy LLC > Software Architect > #8, Chachava str. > Tbilisi, 0159, Georgia > Mobile: +(995) 99753388 > github.com/ioseb > twitter.com/iosebi > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From mca@amundsen.com Sun May 26 04:52:43 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9886921F9003 for ; Sun, 26 May 2013 04:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.627 X-Spam-Level: X-Spam-Status: No, score=-0.627 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_102=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_52=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 W4OQxmYWBOcy for ; Sun, 26 May 2013 04:52:42 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAEF21F9019 for ; Sun, 26 May 2013 04:52:39 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id z11so3820620wgg.7 for ; Sun, 26 May 2013 04:52:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=+lO86Ko2/I8+4Ae9yT0+wsZFDk+708jxqS7xTN2QQ3k=; b=W9mKJn0ckpYRBPP9ER8A8G8GUHfxdaTT9Ylu6IfnpDb2DVYE8+7TDRw9S/EiKSnjZS NGTAWOIHNK3rdY8YzDZmtp2MLrkp2qbKBggF77qBm2HYluVQPaPbVXm6tczdzDVHF6gS 6pW3+pT09UYuP+PRP43WJrcoNX1E7uKsSEI0HLIzAzH5NZJl3I+YeDsc06MRXdRHxiyE qUzUSbG04LUOKXzaTSd6HJPpjhPFFAqARHWtzitrSK671UOG/fzpxns1JIcScVuZVnmP Dab/k40z0ASNExX1x5/b56fbU4R3jCS21IhV3SJdlrZVXkEdQR4JGXfbEee7MUjeWX4V tQvw== X-Received: by 10.180.86.38 with SMTP id m6mr4999663wiz.25.1369569158337; Sun, 26 May 2013 04:52:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.239.138 with HTTP; Sun, 26 May 2013 04:52:18 -0700 (PDT) In-Reply-To: <87B38357AED34BF89465EC5111A090EA@gmail.com> References: <4038B5FE76874C54A819A07FE192AEF8@gmail.com> <87B38357AED34BF89465EC5111A090EA@gmail.com> From: mca Date: Sun, 26 May 2013 07:52:18 -0400 Message-ID: To: Ioseb Dzmanashvili Content-Type: multipart/alternative; boundary=f46d044306422da9aa04dd9dab73 X-Gm-Message-State: ALoCoQmVy5pkEXCbgXei7jDXMyH84BFya5JmyCT1ulqk9vkOAOUEqVpObWkYu0y5Yx8M0ZQ46OjZ X-Mailman-Approved-At: Sun, 26 May 2013 12:07:43 -0700 Cc: IETF Apps Discuss , "link-relations@ietf.org" Subject: Re: [apps-discuss] NEW RELATION: property and context X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 May 2013 11:52:43 -0000 --f46d044306422da9aa04dd9dab73 Content-Type: text/plain; charset=ISO-8859-1 Ioseb: so your thinking is that the attributes of a file is not a "collection"? mca +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 Sun, May 26, 2013 at 7:51 AM, Ioseb Dzmanashvili < ioseb.dzmanashvili@gmail.com> wrote: > Hi Mike, > > Thanks for response! > > > How are these different from the "collection" and "item" link relations? > > IOW, what can be described by "property" and "context" that cannot be > described by "collection" and "item"? > > It depends how we look at things. For example if if we've a resource that > is a photo(or video etc...) we can not describe it as a collection. If > we've resource which is a property of that photo we can indicate the > context resource of this photo with the "context" link relation, as i > understand and see it the "collection" link relation doesn't properly > describe photo which definitely is not a collection of items itself. > > Another example is a file which has various attributes(or properties), if > for example i want to express these properties of the file as links i think > the "property" link relation will be more correct rather than the "item" > link relation IMHO. > > ioseb > > On Sunday, May 26, 2013 at 3:38 PM, mca wrote: > > How are these different from the "collection" and "item" link relations? > > IOW, what can be described by "property" and "context" that cannot be > described by "collection" and "item"? > On May 26, 2013 1:22 PM, "Ioseb Dzmanashvili" < > ioseb.dzmanashvili@gmail.com> wrote: > > Dear All, > > I've submitted new draft for the "property" and "context" link relation > types: > http://tools.ietf.org/html/draft-property-and-context-link-relations-00 > > Description: > > - This specification defines link relation types that may be used to > express the relationships between a resource and associated properties or > between a resource and it's context. > - The "property" and "context" link relations are intentionally generic, > and they can be used with multiple media types in a wide variety of use > cases > - The "property" Link Relation Type: When included in a response, the > "property" link relation identifies a target resource that represents a > property of the context resource. > - The "context" Link Relation Type: When included in a response, the > "context" link relation identifies a target resource that represents a > context document of which the context resource is a member. > > Could you please review? > Thanks in advance! > > Best regards, > ioseb > -- > Ioseb Dzmanashvili > AzRy LLC > Software Architect > #8, Chachava str. > Tbilisi, 0159, Georgia > Mobile: +(995) 99753388 > github.com/ioseb > twitter.com/iosebi > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > > --f46d044306422da9aa04dd9dab73 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ioseb:

so your thinking is that t= he attributes of a file is not a "collection"?



On Sun, May 26, 2013 at 7:51 AM, Ioseb D= zmanashvili <ioseb.dzmanashvili@gmail.com> wrote:=
Hi Mike,

Thanks for response!=

> How are these differe= nt from the "collection" and "item" link relations?
> IOW, what can be described by "property" and "cont= ext" that cannot be described by "collection" and "item= "?

It depends how we look at things. Fo= r example if if we've a resource that is a photo(or video etc...) we ca= n not describe it as a collection. If we've resource which is a propert= y of that photo we can indicate the context resource of this photo with the= "context" link relation, as i understand and see it the "co= llection" link relation doesn't properly describe photo which defi= nitely is not a collection of items itself.

Another example is a file which has various attributes(= or properties), if for example i want to express these properties of the fi= le as links i think the "property" link relation will be more cor= rect rather than the "item" link relation IMHO.

io= seb
=20

On Sunday, May 26, 2013 at 3:38 = PM, mca wrote:

How are these different = from the "collection" and "item" link relations?

IOW, what can be described by "property" and "= ;context" that cannot be described by "collection" and "= ;item"?

On May 26, 2013 1:22 PM, "Ioseb Dzmanashvili" <ioseb.dzmanashvili@= gmail.com> wrote:
=
Dear All,

I've submitted new draft for = the "property" and "context" link relation types:=A0http://tools.ietf.org/html/draft-property-and-conte= xt-link-relations-00

Description:=A0

- This sp= ecification defines link relation types that may be used=A0to express the r= elationships between a resource and associated=A0properties or between a re= source and it's context.
- The "property" and "context" link relations are = intentionally=A0generic, and they can be used with multiple media types in = a wide=A0variety of use cases
- The "property" Li= nk Relation Type:=A0When included in a response, the "property" l= ink relation identifies a target resource that represents a property of the= context resource.
- The "context" Link Relation Type:=A0When included in = a response, the "context" link relation identifies a target resou= rce that represents a context document of which the context resource is a m= ember.

Could you please review?
Thanks in advance!

Best regards,
=
ioseb
--=A0
Ioseb Dzmanashvili
AzRy= LLC
Software Architect
#8, Chachava str.
Tbilisi,= 0159, Georgia
Mobile: +(995) 99753388

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

 =20 =20 =20 =20
=20


--f46d044306422da9aa04dd9dab73-- From markus.lanthaler@gmx.net Sun May 26 14:59: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 92FAF21F88AC for ; Sun, 26 May 2013 14:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.043 X-Spam-Level: X-Spam-Status: No, score=0.043 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, SARE_RECV_VIRTUACOMBR=1.193] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+gHIu-2Xnjw for ; Sun, 26 May 2013 14:59:55 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id B3C9A21F8A14 for ; Sun, 26 May 2013 14:59:54 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.31]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MaGJS-1V0bHF1Kvo-00JtbX for ; Sun, 26 May 2013 23:59:53 +0200 Received: (qmail invoked by alias); 26 May 2013 21:59:52 -0000 Received: from c935b69f.virtua.com.br (EHLO Vostro3500) [201.53.182.159] by mail.gmx.net (mp031) with SMTP; 26 May 2013 23:59:52 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1+v46pAl2mvEx9zI3ywCkctj9DAWPckhHTFOUun6i ceZTcM2LMY/utP From: "Markus Lanthaler" To: "'Ioseb Dzmanashvili'" References: <5289AF00-A443-4FAD-BFA5-D62E0D2FE0BC@gmail.com> In-Reply-To: <5289AF00-A443-4FAD-BFA5-D62E0D2FE0BC@gmail.com> Date: Sun, 26 May 2013 18:59:49 -0300 Message-ID: <009201ce5a5c$5b591960$120b4c20$@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: Ac5aLJjccG0/i1XHQHGI6DNwy2SUcQALtfGA Content-Language: de X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org, link-relations@ietf.org Subject: Re: [apps-discuss] NEW RELATION: property and context X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 May 2013 21:59:59 -0000 Ioseb, > I've submitted new draft for the "property" and "context" link > relation types:=20 > = http://tools.ietf.org/html/draft-property-and-context-link-relations-00 I have a hard time understanding what your are trying to achieve. Just as Jan mentioned in another thread, the name of the link rels = implies to me that you are kind of reinventing RDF. JSON-LD [1], e.g., = also has the notion of a context and allows JSON documents to be linked = to JSON-LD contexts - although using a full URL as link rel instead of a = token. On Sunday, May 26, 2013 8:22 AM, Ioseb Dzmanashvili wrote: > > Is the desire to create individual links for properties to > > facilitate updating those properties? > > Yes, this is one of the reasons i used this rel in several > apps - to allow selectively retrieve and modify properties. How do you know which link to follow in your apps? Do you do that based = on the title attribute? Cheers, Markus [1] http://www.w3.org/TR/json-ld/ -- Markus Lanthaler @markuslanthaler From internet-drafts@ietf.org Sun May 26 16:35: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 3439821F9452; Sun, 26 May 2013 16:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.072, 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 4mso22qD8lD1; Sun, 26 May 2013 16:35:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9730321F9195; Sun, 26 May 2013 16:35:21 -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.50 Message-ID: <20130526233521.6482.87690.idtracker@ietfa.amsl.com> Date: Sun, 26 May 2013 16:35:21 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-14.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, 26 May 2013 23:35:45 -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-14.txt Pages : 23 Date : 2013-05-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-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ioseb.dzmanashvili@gmail.com Mon May 27 00:28: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 0087C21F9195; Mon, 27 May 2013 00:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 BcxxcFK2gXCM; Mon, 27 May 2013 00:28:15 -0700 (PDT) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by ietfa.amsl.com (Postfix) with ESMTP id EC27D21F8619; Mon, 27 May 2013 00:28:14 -0700 (PDT) Received: by mail-ee0-f52.google.com with SMTP id c13so3538508eek.25 for ; Mon, 27 May 2013 00:28: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:x-mailer :mime-version:content-type; bh=Qaa90gPnA/RgvlcxZcE09fGTpsYU6WeYZ0oI7Cb6uVE=; b=NlsfBbXaD4eeByQimJ/Ynx1clpvnGFyVhxyLlEkNORauD9909/bUUhNudeqAOrp+06 5xdBvL1tAe/sAnrTofhflozW47HpB2cquA8F94fYvct9JiiVri6RYDpv4it8RvdMnZr8 k9ipaI2g/yLkmTh/iiaBaGmrgD1WpLz/epNJmxx7znRcSy5u2MA6IiwYl3+dcnxrxZ2W 8YxinG1/AUEYPy8uXrLIGIsprt8++ulbWls0SUqsEEJRceW6jY8zCaYp0uAXbPZyQEyx i5ZASfOCaG4IQdWbtzbHdL3U4RIRt01ZNM5z10a1CN1lNDpDsLd+SXd1vXNZzBBfpNAO 6/pw== X-Received: by 10.14.194.130 with SMTP id m2mr8853278een.96.1369639694127; Mon, 27 May 2013 00:28:14 -0700 (PDT) Received: from [10.131.33.114] ([213.131.60.234]) by mx.google.com with ESMTPSA id t9sm39755539eeo.11.2013.05.27.00.28.12 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 27 May 2013 00:28:13 -0700 (PDT) Date: Mon, 27 May 2013 11:28:11 +0400 From: Ioseb Dzmanashvili To: Markus Lanthaler Message-ID: In-Reply-To: <51a285da.48ac0e0a.7995.ffffdc06SMTPIN_ADDED_BROKEN@mx.google.com> References: <5289AF00-A443-4FAD-BFA5-D62E0D2FE0BC@gmail.com> <51a285da.48ac0e0a.7995.ffffdc06SMTPIN_ADDED_BROKEN@mx.google.com> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="51a30b0b_1d4ed43b_1b1" Cc: apps-discuss@ietf.org, link-relations@ietf.org Subject: Re: [apps-discuss] NEW RELATION: property and context X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 May 2013 07:28:20 -0000 --51a30b0b_1d4ed43b_1b1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Markus, > I have a hard time understanding what your are trying to achieve. > Just as Jan mentioned in another thread, the name of the link rels implies to me that you are kind of reinventing RDF. JSON-LD [1], e.g., also has the notion of a context and allows JSON documents to be linked to JSON-LD contexts - although using a full URL as link rel instead of a token. My RDF knowledge is rudimentary, but what i can say for sure the "context" link relation and "@context" from JSON-LD are different things. Here is what JSON-LD[1] documentation says: "The secret lies in the @context, which instructs Linked Data-aware processors on how to interpret the JSON object." which is not the case for the "context" link relation... it's much simpler and must be used to indicate that a resource is a member of another resource and only in cases when we do not have collection/item relationships. For example if i share resource URI which is a member of another resource i can use the "context" link rel to inform processing agent that shared resource is a member of another resource. > How do you know which link to follow in your apps? Do you do that based on the title attribute? No, title attribute is only used for user interfaces i do not think anyone uses it for other purposes. In my apps i only use rel attribute values to decide which link to follow. [1]. http://json-ld.org/ Cheers, isoeb On Monday, May 27, 2013 at 1:59 AM, Markus Lanthaler wrote: > Ioseb, > > > I've submitted new draft for the "property" and "context" link > > relation types: > > http://tools.ietf.org/html/draft-property-and-context-link-relations-00 > > > > > I have a hard time understanding what your are trying to achieve. > > Just as Jan mentioned in another thread, the name of the link rels implies to me that you are kind of reinventing RDF. JSON-LD [1], e.g., also has the notion of a context and allows JSON documents to be linked to JSON-LD contexts - although using a full URL as link rel instead of a token. > > > On Sunday, May 26, 2013 8:22 AM, Ioseb Dzmanashvili wrote: > > > Is the desire to create individual links for properties to > > > facilitate updating those properties? > > > > > > > > > Yes, this is one of the reasons i used this rel in several > > apps - to allow selectively retrieve and modify properties. > > > > > How do you know which link to follow in your apps? Do you do that based on the title attribute? > > > Cheers, > Markus > > > [1] http://www.w3.org/TR/json-ld/ > > > -- > Markus Lanthaler > @markuslanthaler > > --51a30b0b_1d4ed43b_1b1 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Markus,

> I have= a hard time understanding what your are trying to achieve.
>= ; Just as Jan mentioned in another thread, the name of the link rels impl= ies to me that you are kind of reinventing RD=46. JSON-LD =5B1=5D, e.g., = also has the notion of a context and allows JSON documents to be linked t= o JSON-LD contexts - although using a full URL as link rel instead of a t= oken.

My RD=46 knowledge is rudimentary, but wha= t i can say for sure the =22context=22 link relation and =22=40context=22= from JSON-LD are different things. Here is what JSON-LD=5B1=5D documenta= tion says: =22The secret lies in the =40context, which instructs Linked D= ata-aware processors on how to interpret the JSON object.=22 which is not= the case for the =22context=22 link relation... it's much simpler and mu= st be used to indicate that a resource is a member of another resource an= d only in cases when we do not have collection/item relationships. =46or = example if i share resource URI which is a member of another resource i c= an use the =22context=22 link rel to inform processing agent that shared = resource is a member of another resource.

> H= ow do you know which link to follow in your apps=3F Do you do that based = on the title attribute=3F

No, title attribute is= only used for user interfaces i do not think anyone uses it for other pu= rposes. In my apps i only use rel attribute values to decide which link t= o follow.  

=5B1=5D. http://json-ld.org/&nb= sp;

Cheers,
isoeb
=20

On Monday, May 27, 201= 3 at 1:59 AM, Markus Lanthaler wrote:

Ioseb,

I've submitted new draft for the =22pr= operty=22 and =22context=22 link
relation types:

I have a hard = time understanding what your are trying to achieve.

<= div>Just as Jan mentioned in another thread, the name of the link rels im= plies to me that you are kind of reinventing RD=46. JSON-LD =5B1=5D, e.g.= , also has the notion of a context and allows JSON documents to be linked= to JSON-LD contexts - although using a full URL as link rel instead of a= token.


On Sunday, May 26, 2013 8= :22 AM, Ioseb Dzmanashvili wrote:
Is the desire to create individu= al links for properties to
facilitate updating those properties= =3F

Yes, this is one of the r= easons i used this rel in several
apps - to allow selectively r= etrieve and modify properties.

How do you know which link to follow in your apps=3F Do you do that bas= ed on the title attribute=3F


Chee= rs,
Markus




=20 =20 =20 =20 =20

--51a30b0b_1d4ed43b_1b1-- From ioseb.dzmanashvili@gmail.com Mon May 27 00:37: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 A02B821F9377 for ; Mon, 27 May 2013 00:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEqblwiOtVeA for ; Mon, 27 May 2013 00:37:01 -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 2079921F922A for ; Mon, 27 May 2013 00:37:00 -0700 (PDT) Received: by mail-ea0-f170.google.com with SMTP id f15so3614501eak.1 for ; Mon, 27 May 2013 00:37:00 -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:x-mailer :mime-version:content-type; bh=4v6XufxAxPVFAK0qGpl5DzrJsKi+W49PcZCz8dM23AM=; b=TFcJwX3ECASAfczNwWNuVyVVpjyFkoafK2Or1n/wlPUS3htqLisejqmEG4vbaGrGLg Nf08CgdvKWSzFG74csPjd5MNXUcAaN17CDrMS9F9AOokIIdqRjzvLAsBuCAXxuqZ1fXe ZvrRgOyFdHLQsRNx5kl5FNfZTpVSaRYf61IOQn8Qi2mv+kDHF7rqNjUy8ZcLQ22QxP2F 0vw5lsFAYpaKjVHwFhap+YKHVX41R+AZNs2tzDKoiTTRkgbf+yqauJX9BB5zV/3xixzC UpCc4S524j+cvf2Pz0Ea8OenUna/v/oIFpkn+eto1xPb+wkfncdXWZRQQdSNv0nEHnGc Q/Xw== X-Received: by 10.14.4.3 with SMTP id 3mr9046638eei.59.1369640220248; Mon, 27 May 2013 00:37:00 -0700 (PDT) Received: from [10.131.33.114] ([213.131.60.234]) by mx.google.com with ESMTPSA id f1sm11325778eem.17.2013.05.27.00.36.58 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 27 May 2013 00:36:59 -0700 (PDT) Date: Mon, 27 May 2013 11:36:57 +0400 From: Ioseb Dzmanashvili To: Jan Algermissen Message-ID: <2F22027CD7A04FFBA2B5A8442B7927E5@gmail.com> In-Reply-To: <6E466260-0DDC-4B7F-8FB1-9DAF59BD1BB7@nordsc.com> References: <4038B5FE76874C54A819A07FE192AEF8@gmail.com> <6E466260-0DDC-4B7F-8FB1-9DAF59BD1BB7@nordsc.com> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="51a30d19_12e685fb_1b1" Cc: link-relations@ieft.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] NEW RELATION: property and context X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 May 2013 07:37:08 -0000 --51a30d19_12e685fb_1b1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Jan, > It feels a bit like reinventing RDF. If you mean the "context" thing as i explained in another thread it's not same as JSON-LD's "@context". Quote from another email: > My RDF knowledge is rudimentary, but what i can say for sure the "context" link relation and "@context" from JSON-LD are different things. Here is what JSON-LD[1] documentation says: "The secret lies in the @context, which instructs Linked Data-aware processors on how to interpret the JSON object." which is not the case for the "context" link relation... it's much simpler and must be used to indicate that a resource is a member of another resource and only in cases when we do not have collection/item relationships. For example if i share resource URI which is a member of another resource i can use the "context" link rel to inform processing agent that shared resource is a member of another resource. > What is the difference exactly between a property and a link? Sorry, i do not get this question? Cheers, ioseb On Sunday, May 26, 2013 at 9:00 PM, Jan Algermissen wrote: > Ioseb, > > On 26.05.2013, at 13:21, Ioseb Dzmanashvili wrote: > > > Dear All, > > > > I've submitted new draft for the "property" and "context" link relation types: http://tools.ietf.org/html/draft-property-and-context-link-relations-00 > > It feels a bit like reinventing RDF. > > What is the difference exactly between a property and a link? > > Jan > > > > > > Description: > > > > - This specification defines link relation types that may be used to express the relationships between a resource and associated properties or between a resource and it's context. > > - The "property" and "context" link relations are intentionally generic, and they can be used with multiple media types in a wide variety of use cases > > - The "property" Link Relation Type: When included in a response, the "property" link relation identifies a target resource that represents a property of the context resource. > > - The "context" Link Relation Type: When included in a response, the "context" link relation identifies a target resource that represents a context document of which the context resource is a member. > > > > Could you please review? > > Thanks in advance! > > > > Best regards, > > ioseb > > -- > > Ioseb Dzmanashvili > > AzRy LLC > > Software Architect > > #8, Chachava str. > > Tbilisi, 0159, Georgia > > Mobile: +(995) 99753388 > > github.com/ioseb (http://github.com/ioseb) > > twitter.com/iosebi (http://twitter.com/iosebi) > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org (mailto:apps-discuss@ietf.org) > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > --51a30d19_12e685fb_1b1 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Jan,

> It feels = a bit like reinventing RD=46.

If you mean the =22= context=22 thing as i explained in another thread it's not same as JSON-L= D's =22=40context=22. Quote from another email:
My RD=46 knowledge is rudimentary, but what i can say for = sure the =22context=22 link relation and =22=40context=22 from JSON-LD ar= e different things. Here is what JSON-LD=5B1=5D documentation says: =22Th= e secret lies in the =40context, which instructs Linked Data-aware proces= sors on how to interpret the JSON object.=22 which is not the case for th= e =22context=22 link relation... it's much simpler and must be used to in= dicate that a resource is a member of another resource and only in cases = when we do not have collection/item relationships. =46or example if i sha= re resource URI which is a member of another resource i can use the =22co= ntext=22 link rel to inform processing agent that shared resource is a me= mber of another resource.

> What= is the difference exactly between a property and a link=3F
Sorry, i do not get this question=3F 

Cheers,
ioseb 
=20

On Sunday, May 26, 201= 3 at 9:00 PM, Jan Algermissen wrote:

Ioseb,


Dear All,

I've submitted new draft for the =22property=22 a= nd =22context=22 link relation types: http://tools.ietf.or= g/html/draft-property-and-context-link-relations-00

It feels a bit like reinventing RD=46.

What is the difference exactly between a property and a= link=3F

Jan


=

Description:

- This specification defines link relation types tha= t may be used to express the relationships between a resource and associa= ted properties or between a resource and it's context.
- The =22= property=22 and =22context=22 link relations are intentionally generic, a= nd they can be used with multiple media types in a wide variety of use ca= ses
- The =22property=22 Link Relation Type: When included in a= response, the =22property=22 link relation identifies a target resource = that represents a property of the context resource.
- The =22co= ntext=22 Link Relation Type: When included in a response, the =22context=22= link relation identifies a target resource that represents a context doc= ument of which the context resource is a member.

Could you please review=3F
Thanks in advance=21

=
Best regards,
ioseb
--
Ioseb Dz= manashvili
AzRy LLC
Software Architect
=238= , Chachava str.
Tbilisi, 0159, Georgia
Mobile: +(995)= 99753388
=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
https://= www.ietf.org/mailman/listinfo/apps-discuss
=20 =20 =20 =20
=20

--51a30d19_12e685fb_1b1-- From ioseb.dzmanashvili@gmail.com Mon May 27 01:06: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 165DF21F8CA5; Mon, 27 May 2013 01:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, 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 WREdCZMpYTQc; Mon, 27 May 2013 01:06:20 -0700 (PDT) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by ietfa.amsl.com (Postfix) with ESMTP id 616DE21F8B64; Mon, 27 May 2013 01:06:19 -0700 (PDT) Received: by mail-ee0-f48.google.com with SMTP id b47so3896152eek.35 for ; Mon, 27 May 2013 01:06:18 -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:x-mailer :mime-version:content-type; bh=46mqdrths8Ir4WSS6b+dvJumwAVdkyZi0fp7Bghdl7Q=; b=qTAlPpOkxPHWNe05XmqnCmFJbMXnR49Oei7fc8nMglaZ+4AO7HkLcsBkN9o1c6H0dc iqpL+UcdVHG19WpqMZ4g09TUQRmrn1TMdm4eZRxcRGYRNOK8NYsBXIVWmFa4tz23mhdW Hlt9lG/DPhLa9RrJ+k4Yvb7R+Vf9mCNgvGiJBVBXYwPn01ICfXh/YCYfUSul4jiCn3JR noNybHBLKe0b99KdNmYl3uWfgUnimipozo8Yq181QL31LLKJ7EeRAozSXDrC2AhwlZ/S ZIxdUM+LvPxHZ68RoVou0OIw3UcpFhElP9M1x+WD7FoqSLg75lqwKk7inD6R6CM914RN v3Tw== X-Received: by 10.15.41.200 with SMTP id s48mr8973721eev.91.1369641978289; Mon, 27 May 2013 01:06:18 -0700 (PDT) Received: from [10.131.33.114] ([213.131.60.234]) by mx.google.com with ESMTPSA id s8sm39909010eeo.4.2013.05.27.01.06.16 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 27 May 2013 01:06:17 -0700 (PDT) Date: Mon, 27 May 2013 12:06:15 +0400 From: Ioseb Dzmanashvili To: janalgermissen1und1@mac.com Message-ID: <3147643D8DBF46A5B87A00E3116A5724@gmail.com> In-Reply-To: References: <4038B5FE76874C54A819A07FE192AEF8@gmail.com> <6E466260-0DDC-4B7F-8FB1-9DAF59BD1BB7@nordsc.com> <2F22027CD7A04FFBA2B5A8442B7927E5@gmail.com> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="51a313f7_354fe9f9_1b1" Cc: apps-discuss@ietf.org, "=?utf-8?Q?link-relations=40ietf.org?=" Subject: Re: [apps-discuss] NEW RELATION: property and context X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 May 2013 08:06:24 -0000 --51a313f7_354fe9f9_1b1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Jan, > Let's try a different way: What is a 'property'? It's a data member. For example "title" or "summary" of an article. ioseb On Monday, May 27, 2013 at 11:46 AM, janalgermissen1und1@mac.com wrote: > > On 27.05.2013, at 09:36, Ioseb Dzmanashvili wrote: > > > > > > What is the difference exactly between a property and a link? > > > > Sorry, i do not get this question? > > Let's try a different way: > > What is a 'property'? > > Jan > > > > > > Cheers, > > ioseb > > On Sunday, May 26, 2013 at 9:00 PM, Jan Algermissen wrote: > > > > > Ioseb, > > > > > > On 26.05.2013, at 13:21, Ioseb Dzmanashvili wrote: > > > > > > > Dear All, > > > > > > > > I've submitted new draft for the "property" and "context" link relation types: http://tools.ietf.org/html/draft-property-and-context-link-relations-00 > > > > > > It feels a bit like reinventing RDF. > > > > > > What is the difference exactly between a property and a link? > > > > > > Jan > > > > > > > > > > > > > > Description: > > > > > > > > - This specification defines link relation types that may be used to express the relationships between a resource and associated properties or between a resource and it's context. > > > > - The "property" and "context" link relations are intentionally generic, and they can be used with multiple media types in a wide variety of use cases > > > > - The "property" Link Relation Type: When included in a response, the "property" link relation identifies a target resource that represents a property of the context resource. > > > > - The "context" Link Relation Type: When included in a response, the "context" link relation identifies a target resource that represents a context document of which the context resource is a member. > > > > > > > > Could you please review? > > > > Thanks in advance! > > > > > > > > Best regards, > > > > ioseb > > > > -- > > > > Ioseb Dzmanashvili > > > > AzRy LLC > > > > Software Architect > > > > #8, Chachava str. > > > > Tbilisi, 0159, Georgia > > > > Mobile: +(995) 99753388 > > > > github.com/ioseb (http://github.com/ioseb) > > > > twitter.com/iosebi (http://twitter.com/iosebi) > > > > _______________________________________________ > > > > apps-discuss mailing list > > > > apps-discuss@ietf.org (mailto:apps-discuss@ietf.org) > > > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > > > > > > > > > > > > --51a313f7_354fe9f9_1b1 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Jan,

> Let's try a diffe= rent way: What is a 'property'=3F

It's a data me= mber. =46or example =22title=22 or =22summary=22 of an article.

ioseb 
=20

On Monday, May 27, 201= 3 at 11:46 AM, janalgermissen1und1=40mac.com wrote:


On 27.05.2013, at= 09:36, Ioseb Dzmanashvili <ioseb.dzmanashvili=40gmail.com> wrote:

<= /div>

What is the difference exactly between a property and a l= ink=3F

Sorry, i do not get this que= stion=3F

Let's try a differe= nt way:

What is a 'property'=3F

Jan



Cheers,
ioseb
On Sunda= y, May 26, 2013 at 9:00 PM, Jan Algermissen wrote:

Ioseb,

On = 26.05.2013, at 13:21, Ioseb Dzmanashvili <ioseb.dzmanashvili=40gmail.com> wrote:

Dear All,

I've submitted new draft for the =22property=22 and = =22context=22 link relation types: http://tools.ietf.org/h= tml/draft-property-and-context-link-relations-00

It feels a bit like reinventing RD=46.
=
What is the difference exactly between a property and a li= nk=3F

Jan



Description:

- This specification defines link relation types that ma= y be used to express the relationships between a resource and associated = properties or between a resource and it's context.
- The =22pro= perty=22 and =22context=22 link relations are intentionally generic, and = they can be used with multiple media types in a wide variety of use cases=
- The =22property=22 Link Relation Type: When included in a re= sponse, the =22property=22 link relation identifies a target resource tha= t represents a property of the context resource.
- The =22conte= xt=22 Link Relation Type: When included in a response, the =22context=22 = link relation identifies a target resource that represents a context docu= ment of which the context resource is a member.

= Could you please review=3F
Thanks in advance=21

<= /div>
Best regards,
ioseb
--
Ioseb Dzma= nashvili
AzRy LLC
Software Architect
=238, = Chachava str.
Tbilisi, 0159, Georgia
Mobile: +(995) 9= 9753388
=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
=20 =20 =20 =20 =20

--51a313f7_354fe9f9_1b1-- From dret@berkeley.edu Mon May 27 07:20: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 2C29321F92EB; Mon, 27 May 2013 07:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.211 X-Spam-Level: * X-Spam-Status: No, score=1.211 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMSlpczSvkNY; Mon, 27 May 2013 07:20:07 -0700 (PDT) Received: from gong.birdhouse.org (gong.birdhouse.org [207.58.180.215]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA1221F8BBC; Mon, 27 May 2013 07:20:07 -0700 (PDT) Received: from mobile-166-137-187-240.mycingular.net ([166.137.187.240]:40760 helo=[10.112.201.71]) by gong.birdhouse.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1UgyHN-0004eU-Ur; Mon, 27 May 2013 07:20:06 -0700 References: <5289AF00-A443-4FAD-BFA5-D62E0D2FE0BC@gmail.com> <51a285da.48ac0e0a.7995.ffffdc06SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <95E83124-0A6D-45FE-AB63-5768F2369717@berkeley.edu> X-Mailer: iPhone Mail (10B350) From: Erik Wilde Date: Mon, 27 May 2013 07:20:01 -0700 To: "link-relations@ietf.org" , "apps-discuss@ietf.org" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gong.birdhouse.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - berkeley.edu X-Get-Message-Sender-Via: gong.birdhouse.org: authenticated_id: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [apps-discuss] NEW RELATION: property and context X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 May 2013 14:20:13 -0000 hello ioseb. On May 27, 2013, at 0:28, Ioseb Dzmanashvili w= rote: > No, title attribute is only used for user interfaces i do not think anyone= uses it for other purposes. In my apps i only use rel attribute values to d= ecide which link to follow. i guess what markus wanted to know is how clients decide which link to follo= w for a specific property, if you have more than one. there must be some "pr= operty identifier" somewhere, so that clients can distinguish, right? i was w= ondering about the same thing. thanks and cheers, dret.= From janalgermissen1und1@mac.com Mon May 27 00:46: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 6FB5121F9260 for ; Mon, 27 May 2013 00:46:34 -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 4wdrOpu9ht2c for ; Mon, 27 May 2013 00:46:30 -0700 (PDT) Received: from nk11p03mm-asmtp001.mac.com (nk11p03mm-asmtp001.mac.com [17.158.232.236]) by ietfa.amsl.com (Postfix) with ESMTP id A45FC21F8FDC for ; Mon, 27 May 2013 00:46:29 -0700 (PDT) Received: from [10.90.135.80] ([87.253.171.193]) by nk11p03mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-26.01(7.0.4.26.0) 64bit (built Jul 13 2012)) with ESMTPSA id <0MNG008LN5KWDI70@nk11p03mm-asmtp001.mac.com> for apps-discuss@ietf.org; Mon, 27 May 2013 07:46:11 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-05-27_02:2013-05-27, 2013-05-27, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1305010000 definitions=main-1305270008 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: janalgermissen1und1@mac.com In-reply-to: <2F22027CD7A04FFBA2B5A8442B7927E5@gmail.com> Date: Mon, 27 May 2013 09:46:11 +0200 Content-transfer-encoding: quoted-printable Message-id: References: <4038B5FE76874C54A819A07FE192AEF8@gmail.com> <6E466260-0DDC-4B7F-8FB1-9DAF59BD1BB7@nordsc.com> <2F22027CD7A04FFBA2B5A8442B7927E5@gmail.com> To: Ioseb Dzmanashvili X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Mon, 27 May 2013 08:04:48 -0700 Cc: link-relations@ieft.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] NEW RELATION: property and context X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 May 2013 07:51:05 -0000 On 27.05.2013, at 09:36, Ioseb Dzmanashvili = wrote: >=20 > > What is the difference exactly between a property and a link? >=20 > Sorry, i do not get this question?=20 Let's try a different way: What is a 'property'? Jan >=20 > Cheers, > ioseb=20 > On Sunday, May 26, 2013 at 9:00 PM, Jan Algermissen wrote: >=20 >> Ioseb, >>=20 >> On 26.05.2013, at 13:21, Ioseb Dzmanashvili = wrote: >>=20 >>> Dear All, >>>=20 >>> I've submitted new draft for the "property" and "context" link = relation types: = http://tools.ietf.org/html/draft-property-and-context-link-relations-00 >>=20 >> It feels a bit like reinventing RDF. >>=20 >> What is the difference exactly between a property and a link? >>=20 >> Jan >>=20 >>=20 >>>=20 >>> Description: >>>=20 >>> - This specification defines link relation types that may be used to = express the relationships between a resource and associated properties = or between a resource and it's context. >>> - The "property" and "context" link relations are intentionally = generic, and they can be used with multiple media types in a wide = variety of use cases >>> - The "property" Link Relation Type: When included in a response, = the "property" link relation identifies a target resource that = represents a property of the context resource. >>> - The "context" Link Relation Type: When included in a response, the = "context" link relation identifies a target resource that represents a = context document of which the context resource is a member. >>>=20 >>> Could you please review? >>> Thanks in advance! >>>=20 >>> Best regards, >>> ioseb >>> -- >>> Ioseb Dzmanashvili >>> AzRy LLC >>> Software Architect >>> #8, Chachava str. >>> Tbilisi, 0159, Georgia >>> Mobile: +(995) 99753388 >>> github.com/ioseb >>> twitter.com/iosebi >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 From xhe@hitachi.cn Mon May 27 03:19: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 94F2F21F91B1 for ; Mon, 27 May 2013 03:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.246 X-Spam-Level: * X-Spam-Status: No, score=1.246 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATICB=1.372, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DArWpgvqDVTp for ; Mon, 27 May 2013 03:19:41 -0700 (PDT) Received: from hitachihk8.hitachi.cn (static-ip-174-194-65-202.rev.dyxnet.com [202.65.194.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC2A21F9017 for ; Mon, 27 May 2013 03:19:39 -0700 (PDT) Received: (qmail 27206 invoked from network); 27 May 2013 10:19:37 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk8;15b14876000265694a45dcdc19ad3204; Received: from unknown (HELO mfrelay03.hitachi.co.jp) (133.144.234.179) by 172-3-20-1.lightspeed.nworla.sbcglobal.net with SMTP; 27 May 2013 10:19:37 -0000 Received: from vshuts04.hitachi.co.jp (vshuts04.hitachi.co.jp [10.201.6.86]) by mfrelay03.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id r4RAJabh016611 for ; Mon, 27 May 2013 19:19:37 +0900 Received: from localhost (unknown [127.0.0.1]) by IMSVA (Postfix) with SMTP id 59739140052 for ; Mon, 27 May 2013 19:19:36 +0900 (JST) X-IMSS-HAND-OFF-DIRECTIVE: 133.144.234.22:25 Received: from hitachi.cn (unknown [170.95.94.58]) by vshuts04.hitachi.co.jp (Postfix) with ESMTP id 7064F140057 for ; Mon, 27 May 2013 19:19:27 +0900 (JST) Received: (qmail 26505 invoked from network); 27 May 2013 10:13:09 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk5;4d03b98eefc1b6eab0fb58917108ff52; Received: from hchidc094072.hitachi-china.com (170.95.94.72) by 172.16.10.14 with SMTP; 27 May 2013 10:12:14 -0000 Received: from hcrdbjipnl017 ([10.96.2.119]) by hchidc094072.hitachi-china.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 May 2013 18:09:08 +0800 From: "He Xuan" To: "'IETF Apps Discuss'" , Date: Mon, 27 May 2013 18:09:07 +0800 Message-ID: <00e701ce5ac2$3a2bb020$ae831060$@cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E8_01CE5B05.484EF020" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5awjjBiY6j3yFNRAu0GwjZLTg/6A== Content-Language: zh-cn X-OriginalArrivalTime: 27 May 2013 10:09:08.0702 (UTC) FILETIME=[3A34D7E0:01CE5AC2] X-Scanned-By-hitachihk5: Virus scan performed by network-box X-Scanned-By-hitachihk5: Scanner file id is hitachihk5-1369649534.718-25634-000 X-Scanned-By-hitachihk5: No known viruses found in message (received+scanned in 0.05/0.16 secs) X-Scanned-By-hitachihk5: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-NetworkBox-BounceSign-hitachi: 0101;15852;5df8d7aa X-Scanned-By-hitachihk8: Virus scan performed by network-box X-Scanned-By-hitachihk8: Scanner file id is hitachihk8-1369649977.504-27193-000 X-Scanned-By-hitachihk8: No known viruses found in message (received+scanned in 0.06/0.10 secs) X-Scanned-By-hitachihk8: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk8: Warning: Invalid outbound signature from Network Box hitachihk5 X-Mailman-Approved-At: Mon, 27 May 2013 08:04:58 -0700 Cc: softwires@ietf.org, 'The IESG' , 'SM' Subject: [apps-discuss] AppsDir review of draft-ietf-softwire-public-4over6-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: Mon, 27 May 2013 10:19:46 -0000 UbJGR;7b MIME 8qJ=5D6`2?7VSJ<~!# ------=_NextPart_000_00E8_01CE5B05.484EF020 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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-softwire-public-4over6-09 Title: Public IPv4 over IPv6 Access Network Reviewer: S. Moonesamy and Xuan He Review Date: May 27, 2013 IETF Last Call Date: IESG Telechat Date: May 30, 2013 Summary: This draft is not ready for publication as an Informational document. The mechanism described in the draft is not clearly specified. It is not possible to assess how this mechanism affects application-related protocols due to the lack of clarity. Major Issues: In Section 4 to 6: The implementation of this mechanism is not clear: on which device (seems this mechanism introduces several devices); how to implement it at which kind of network? For example, is it useful for constrained IPv6 network? Minor: In the Introduction Section: "The purpose of this draft is to document the protocol that was deployed, both for historical purposes and for the benefit of users of that protocol in the field at the time of publication." Why is the intended status of the document Informational instead of Historic? The purposed mentioned in the Introduction Section is "to document the protocol" whereas the Abstract mentions a description of a mechanism. Terms used in the draft are ambiguous, such as: In the Introduction Section: "Therefore, public IPv4 addresses are expected to be provisioned to end users and carrier-side address translation can be avoided." What are "public IPv4 addresses"? "Further more, full address is preferred to port-restricted address." What is "full address"? What is "port-restricted address"? In Section 3: "The DNS registration can be direct using dedicated address;" What is "DNS registration" What is "dedicated address"? Nits: In the Abstract: "This mechanism features the allocation of full IPv4 address over IPv6 network, and has been used in production for high-end IPv4 users, IPv6 transition of ICPs, etc." We suggest expanding "ICPs" In Section 3: Section 3 is about "Scenario and Use Cases". "value-added service" sounds more appropriate in a marketing document than for documenting a scenario or use case. "A typical case of the high-end users that could use Public 4over6 is IPv4 application server." Why is the "IPv4 application server" a "high-end user"? "Along with DS-Lite, Public 4over6 can be deployed as a value-added service, overcoming the service degradation caused by the CGN." "CGN" should be expanded on first use. Disclaimer: The contents of this e-mail, and its attachments, if any, are confidential and may be protected by law against any unauthorized use. If you have received this e-mail by mistake or have reason to believe that you are not the intended recipient, please notify the sender by reply e-mail as soon as possible and delete it from your computer system immediately thereafter. If you are not the intended recipient, you must not copy this e-mail or attachment or disclose the contents to any other person. While we have made every effort to keep our network virus free, we take no responsibility for any computer virus which might be transferred by way of this e-mail. ------=_NextPart_000_00E8_01CE5B05.484EF020 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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/ApplicationsAreaD= irectorate).

 

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-softwire-public-4over6-09

Title: Public IPv4 over IPv6 = Access Network

Reviewer: S. Moonesamy and = Xuan He

Review Date: May 27, = 2013

IETF Last Call = Date:

IESG Telechat Date: May 30, = 2013

 

Summary: =

 

This draft is not ready for = publication as an Informational document.

The mechanism described in = the draft is not clearly specified. 

It is not possible to assess = how this mechanism affects application-related protocols due to the lack of = clarity.

 

Major Issues: =

 

In Section 4 to 6: =

 

The implementation of this = mechanism is not clear: on which device (seems this mechanism introduces several = devices); how to implement it at which kind of network? For example, is it useful = for constrained IPv6 network?

 

Minor:

 

In the Introduction = Section:

 

   "The = purpose of this draft is to document the protocol that was

    deployed, = both for historical purposes and for the benefit of users

    of that = protocol in the field at the time of publication."

 

Why is the intended status of = the document Informational instead of Historic? 

The purposed mentioned in the Introduction Section is "to document the protocol" whereas the Abstract mentions a description of a mechanism.

 

Terms used in the draft are = ambiguous, such as:

 

In the Introduction = Section:

 

"Therefore, public IPv4 = addresses are expected to be provisioned to

    end users = and carrier-side address translation can be = avoided."

 

What are "public IPv4 addresses"?

 

   "Further = more, full address is preferred to port-restricted = address."

 

What is "full = address"?

 

What is "port-restricted address"?

 

In Section = 3:

 

   "The DNS = registration can be direct using dedicated address;"

 

What is "DNS = registration"

 

What is "dedicated = address"?

 

Nits:

 

In the = Abstract:

 

   "This = mechanism features the allocation of full IPv4 address over = IPv6

    network, = and has been used in production for high-end IPv4 users,

    IPv6 = transition of ICPs, etc."

 

We suggest expanding = "ICPs"

 

In Section 3: =

 

Section 3 is about = "Scenario and Use Cases".  "value-added service" =

sounds more appropriate in a = marketing document than for documenting a scenario or use = case.

 

   "A typical = case of the high-end users that could use Public 4over6 is

    IPv4 = application server."

 

Why is the "IPv4 = application server" a "high-end user"?

 

   "Along with = DS-Lite, Public 4over6 can be deployed as a

    = value-added service, overcoming the service degradation caused by the

    = CGN."

 

"CGN" should be = expanded on first use.

 

 

 

 


=

Disclaimer: The contents of this e-mail, and its attachments, if any, are confidential and may be protected by law against any unauthorized use. If you have received this e-mail by mistake or have reason to believe that you are not the intended recipient, please notify the sender by reply e-mail as soon as possible and delete it from your computer system immediately thereafter. If you are not the intended recipient, you must not copy this e-mail or attachment or disclose the contents to any other person. While we have made every effort to keep our network virus free, we take no responsibility for any computer virus which might be transferred by way of this e-mail.


= ------=_NextPart_000_00E8_01CE5B05.484EF020-- From ioseb.dzmanashvili@gmail.com Mon May 27 08:09: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 C6B5C21F92F5; Mon, 27 May 2013 08:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.931 X-Spam-Level: X-Spam-Status: No, score=-2.931 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xgmt0hoAmfG; Mon, 27 May 2013 08:09:35 -0700 (PDT) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3461121F91C4; Mon, 27 May 2013 08:09:34 -0700 (PDT) Received: by mail-ea0-f178.google.com with SMTP id q16so4133545ead.9 for ; Mon, 27 May 2013 08:09: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:x-mailer :mime-version:content-type; bh=z5n1VNWoEiw6yNCyIbqJ1y3+D1T08XQtLZlIW43XyKs=; b=OZ8Y1vNV1m+yUSrJzzzP2K/4a+0MCm3oj/KKqvK47PSPzYcLHg80zW/mwfu+78+flw Er1iRxghrwWG1xYW1RlrBiq8ARISV63XGVIJR59CFwwEyPn031keFDIOTae+Ks68ON3Q 8Xm2Ce8KYWtVKa/TCp3vqKuvmYSbfybd9fwIvM/fUYU4FkHcsuZtCDW08VWSwcgS7GzD 2rR7VmP/DaN2F1aakQN2WEC6t8qR6SwclY1f5fgH770TFfqumwgX+7ywC0+WF0MlvYwf Oah5DYxY4fo49eQ4EvCeBj1wsVJIJqVPFu1Ml5E8Qe+LyoV8jG+Kkmi1WFkiyxrDQwcy khGg== X-Received: by 10.14.38.71 with SMTP id z47mr10461144eea.138.1369667374219; Mon, 27 May 2013 08:09:34 -0700 (PDT) Received: from [10.131.33.114] ([213.131.60.234]) by mx.google.com with ESMTPSA id s8sm42167853eeo.4.2013.05.27.08.09.31 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 27 May 2013 08:09:32 -0700 (PDT) Date: Mon, 27 May 2013 19:09:30 +0400 From: Ioseb Dzmanashvili To: Erik Wilde Message-ID: In-Reply-To: <95E83124-0A6D-45FE-AB63-5768F2369717@berkeley.edu> References: <5289AF00-A443-4FAD-BFA5-D62E0D2FE0BC@gmail.com> <51a285da.48ac0e0a.7995.ffffdc06SMTPIN_ADDED_BROKEN@mx.google.com> <95E83124-0A6D-45FE-AB63-5768F2369717@berkeley.edu> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="51a3772a_579be4f1_1b1" Cc: "=?utf-8?Q?apps-discuss=40ietf.org?=" , "=?utf-8?Q?link-relations=40ietf.org?=" Subject: Re: [apps-discuss] NEW RELATION: property and context X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 May 2013 15:09:37 -0000 --51a3772a_579be4f1_1b1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Erik, > i guess what markus wanted to know is how clients decide which link to follow for a specific property, if you have more than one. there must be some "property identifier" somewhere, so that clients can distinguish, right? i was wondering about the same thing. Thanks for clarification! When i use this relation type in GUI apps the "property" rel is enough to distinguish property links from other links. But in addition i usually use application specific profiles describing link relation extensions for particular property types. For example: Link: ; rel="property http://rels.service.org/properties#title"; title="Human friendly text here..." cheers, ioseb On Monday, May 27, 2013 at 6:20 PM, Erik Wilde wrote: > hello ioseb. > > On May 27, 2013, at 0:28, Ioseb Dzmanashvili wrote: > > No, title attribute is only used for user interfaces i do not think anyone uses it for other purposes. In my apps i only use rel attribute values to decide which link to follow. > > > i guess what markus wanted to know is how clients decide which link to follow for a specific property, if you have more than one. there must be some "property identifier" somewhere, so that clients can distinguish, right? i was wondering about the same thing. > > thanks and cheers, > > dret. --51a3772a_579be4f1_1b1 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Erik,

> i guess = what markus wanted to know is how clients decide which link to follow for= a specific property, if you have more than one. there must be some =22pr= operty identifier=22 somewhere, so that clients can distinguish, right=3F= i was wondering about the same thing.

Thanks fo= r clarification=21 When i use this relation type in GUI apps the =22prope= rty=22 rel is enough to distinguish property links from other links. But = in addition i usually use application specific profiles describing link r= elation extensions for particular property types. =46or example:

Link: </book;title>; rel=3D=22property http://rels= .service.org/properties=23title=22; title=3D=22Human friendly text here..= .=22

cheers,
ioseb
=20

On Monday, May 27, 201= 3 at 6:20 PM, Erik Wilde wrote:

hello ioseb.

On May 27, 2013, at 0:28, Ioseb Dzmanashvili <ioseb.dzmanashvili=40gmail.com>= ; wrote:
No, title attribute is o= nly used for user interfaces i do not think anyone uses it for other purp= oses. In my apps i only use rel attribute values to decide which link to = follow.

i guess what markus wanted = to know is how clients decide which link to follow for a specific propert= y, if you have more than one. there must be some =22property identifier=22= somewhere, so that clients can distinguish, right=3F i was wondering abo= ut the same thing.

thanks and cheers,
=
dret.
=20 =20 =20 =20
=20

--51a3772a_579be4f1_1b1-- From jyee@afilias.info Mon May 27 09:29:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB42D21F9660 for ; Mon, 27 May 2013 09:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWoDhM5pUYv0 for ; Mon, 27 May 2013 09:29:52 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3300D21F969A for ; Mon, 27 May 2013 09:29:52 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1Uh0Ix-0004pT-3k for apps-discuss@ietf.org; Mon, 27 May 2013 16:29:51 +0000 Received: from mail-we0-f179.google.com ([74.125.82.179]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1Uh0Ix-0002lJ-3J for apps-discuss@ietf.org; Mon, 27 May 2013 16:29:51 +0000 Received: by mail-we0-f179.google.com with SMTP id m46so4492999wev.38 for ; Mon, 27 May 2013 09:29:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=/nPIfS6ZoaZCcr+OLOB//5albb9VC1lX3iE8MI5JHvo=; b=EshJynehSsbZBMlaWa6dk++0h1sPK4EqMkWuK8vSu1qJSei6FeH+yDtK5FcfqWjYcv PObRf7mbA2S34oy9Ztpu4pIiKanH1tIMh3Orz0XPZmtYLSTVdu7yyJsjksXZKVCGk5Nm TdJ0m4tUifYokftJi4Ju9hV9Axj17csOKdyPdEe5laTy4AY1/NstG+svIFLn27B43faF xh1lsusWCXWUcEdc11Q4xJQz3LryXyTFgXWE8k6xPqBicpoUQJRSgH+xIillnG6l3Lso QnBx4sVYZvdlFVc5gNjDVThHXHQq42UuVsafIu3uB1sIwxjUeP5DuSN9iPjYJHq4kPJ/ 4NOg== X-Received: by 10.194.175.132 with SMTP id ca4mr9487474wjc.11.1369672184918; Mon, 27 May 2013 09:29:44 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.175.132 with SMTP id ca4mr9487469wjc.11.1369672184840; Mon, 27 May 2013 09:29:44 -0700 (PDT) Received: by 10.217.95.69 with HTTP; Mon, 27 May 2013 09:29:44 -0700 (PDT) Date: Mon, 27 May 2013 12:29:44 -0400 Message-ID: From: Joseph Yee To: "apps-discuss@ietf.org" , draft-ietf-nfsv4-rfc3530bis-dot-x.all@tools.ietf.org Content-Type: multipart/alternative; boundary=089e013d1d8e09562204ddb5a80a X-Gm-Message-State: ALoCoQnwK8Z8FCHYbwzozAbJuSdqn1E5lIygevXuZoUAkFlPpqPEJStG2DnDwtnh7UVBCmHLCgvVBbXp5wR8+L8aFd1Co8VMov0AvjnnS1k9h3g78CjaUC1sczXBsr5wRfB2M5T58CrOt+OXouBqcob18k+rW+tuWg== Subject: [apps-discuss] APPSDIR review of draft-ietf-nfsv4-rfc3530bis-dot-x-17 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 May 2013 16:29:56 -0000 --089e013d1d8e09562204ddb5a80a 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 =E2=80=8B 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-nfsv4-rfc3530bis-dot-x-17 Title: [document title] Reviewer: Joseph Yee Review Date: May 26, 2013 Summary: This draft is ready for publication as Proposed Standard. Major Issues: none Minor Issues: draft-ietf-nfsv4-rfc3530bis-26 already stated that this draft (draft-ietf-nfsv4-rfc3530bis-dot-x-17) is the authoritative one if conflict happened. So re-stating it again in this draft is nice to have, but not necessary. Note: I checked this draft against draft-ietf-nfsv4-rfc3530bis-26 and I didn't find any conflict. Nits: I didn't run it against id-nit tool Best, Joseph --089e013d1d8e09562204ddb5a80a Content-Type: text/html; 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 =E2=80=8Bhttp://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAr= eaDirectorate ).

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: draft-ietf-nfsv4-rfc3530bis-dot-x-17
Title: [document title]
Reviewer: Joseph Yee
Review Date: May 26, 2013

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

Major Issues: none

Minor Issues: draft-ietf-nfsv4-rfc3530bis-26 already stated that this draft= (draft-ietf-nfsv4-rfc3530bis-dot-x-17) is the authoritative one if conflic= t happened.=C2=A0 So re-stating it again in this draft is nice to have, but= not necessary.=C2=A0 Note:=C2=A0 I checked this draft against=C2=A0 draft-= ietf-nfsv4-rfc3530bis-26 and I didn't find any conflict.

Nits: I didn't run it against id-nit tool

Best,

Joseph
<= /p>

--089e013d1d8e09562204ddb5a80a-- From paul.hoffman@vpnc.org Mon May 27 09:31: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 553F821F96A7 for ; Mon, 27 May 2013 09:31:37 -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 mlXZtOuYJk60 for ; Mon, 27 May 2013 09:31:37 -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 E9CD021F969C for ; Mon, 27 May 2013 09:31:36 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4RGVZKV081987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 27 May 2013 09:31:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <790FBA26-527F-4244-BB82-C5759F1E8FC3@vpnc.org> Date: Mon, 27 May 2013 09:31:34 -0700 To: "apps-discuss@ietf.org Discuss" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [apps-discuss] Comparisons in the CBOR draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 May 2013 16:31:37 -0000 Greetings again. Based on the requests here last week, we will be adding = a section to the CBOR draft briefly discussing some major existing = formats with respect to their major properties and the design goals for = CBOR. We already have sections for ASN.1 DER/BER, MessagePack, and BSON. = Are there other formats people would like to see in the list? What are = people's favorite streaming-capable JSON-like binary formats? --Paul Hoffman= From jasnell@gmail.com Mon May 27 10: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 80FD121F91A0 for ; Mon, 27 May 2013 10:30:22 -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 9Hpl567XUlme for ; Mon, 27 May 2013 10:30:22 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 07E6C21F8EB2 for ; Mon, 27 May 2013 10:30:21 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id er7so8203317obc.15 for ; Mon, 27 May 2013 10:30:21 -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=5UGyY9Czp9okAT1t8b/n9gP8xZ/5Rwg4ztZkud8CRKs=; b=gfNRenACvns1iX8X1aTnsCdONlRiMYrhtFCqz4UwPY5xXFRc42NpM+frUbBbc4VbJ9 2Wijb3gZ42w1ZcypDEkNLHzWOimnujlF21utxDJP9lW/FWQ5QYMNUuK2qAQBGuFBCcU2 hhQ0vD2B30ZpE+LES1RqdanVC09OFkump+D3kMu/VyvOg4lW/Su+tkfd+IOWjdfRQmbE TglcCFo4r5tY0s/Pj7lPRl8OdjZwJBH3fQErwkhdeS4HNA4NpM4wZgYN/pOiI1big4a3 wFzAKIq5WM1vbJ6OZWnnBzqJsGqTyJ+Lo8zdxHeB38+n3LmVBCJt4nuSlIxPGZf7k6FH 6FLA== MIME-Version: 1.0 X-Received: by 10.182.34.164 with SMTP id a4mr19192047obj.43.1369675821558; Mon, 27 May 2013 10:30:21 -0700 (PDT) Received: by 10.60.3.137 with HTTP; Mon, 27 May 2013 10:30:21 -0700 (PDT) Received: by 10.60.3.137 with HTTP; Mon, 27 May 2013 10:30:21 -0700 (PDT) In-Reply-To: <790FBA26-527F-4244-BB82-C5759F1E8FC3@vpnc.org> References: <790FBA26-527F-4244-BB82-C5759F1E8FC3@vpnc.org> Date: Mon, 27 May 2013 10:30:21 -0700 Message-ID: From: James M Snell To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11c1daa2cd344d04ddb68061 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Comparisons in the CBOR draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 May 2013 17:30:22 -0000 --001a11c1daa2cd344d04ddb68061 Content-Type: text/plain; charset=UTF-8 Those ought to cover it. On May 27, 2013 9:31 AM, "Paul Hoffman" wrote: > Greetings again. Based on the requests here last week, we will be adding a > section to the CBOR draft briefly discussing some major existing formats > with respect to their major properties and the design goals for CBOR. We > already have sections for ASN.1 DER/BER, MessagePack, and BSON. Are there > other formats people would like to see in the list? What are people's > favorite streaming-capable JSON-like binary formats? > > --Paul Hoffman > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --001a11c1daa2cd344d04ddb68061 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Those ought to cover it.=C2=A0

On May 27, 2013 9:31 AM, "Paul Hoffman"= ; <paul.hoffman@vpnc.org>= ; wrote:
Greetings again. Based on the requests here last week, we will be adding a = section to the CBOR draft briefly discussing some major existing formats wi= th respect to their major properties and the design goals for CBOR. We alre= ady have sections for ASN.1 DER/BER, MessagePack, and BSON. Are there other= formats people would like to see in the list? What are people's favori= te streaming-capable JSON-like binary formats?

--Paul Hoffman
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
--001a11c1daa2cd344d04ddb68061-- From dhc@dcrocker.net Mon May 27 10:39: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 819FD21F8201 for ; Mon, 27 May 2013 10:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.264 X-Spam-Level: X-Spam-Status: No, score=-5.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vP99MaAllcKj for ; Mon, 27 May 2013 10:39:47 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E1AF021F8DFC for ; Mon, 27 May 2013 10:39:47 -0700 (PDT) Received: from [10.0.1.33] ([188.118.215.162]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r4RHdgQY028224 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 27 May 2013 10:39:46 -0700 User-Agent: K-9 Mail for Android In-Reply-To: <790FBA26-527F-4244-BB82-C5759F1E8FC3@vpnc.org> References: <790FBA26-527F-4244-BB82-C5759F1E8FC3@vpnc.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----9YGWBPDWWA8DOFJ0759RHCBHMNV8UV" From: Dave Crocker Date: Mon, 27 May 2013 19:39:38 +0200 To: Paul Hoffman , "apps-discuss@ietf.org Discuss" Message-ID: <8aa846e2-0849-46d5-9734-b7a48072f45e@email.android.com> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 27 May 2013 10:39:47 -0700 (PDT) Subject: Re: [apps-discuss] Comparisons in the CBOR draft X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 May 2013 17:39:52 -0000 ------9YGWBPDWWA8DOFJ0759RHCBHMNV8UV Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Primarily for fun, it would be interesting to see a comparison against Haverty's proposal. /d Paul Hoffman wrote: >Greetings again. Based on the requests here last week, we will be >adding a section to the CBOR draft briefly discussing some major >existing formats with respect to their major properties and the design >goals for CBOR. We already have sections for ASN.1 DER/BER, >MessagePack, and BSON. Are there other formats people would like to see >in the list? What are people's favorite streaming-capable JSON-like >binary formats? > >--Paul Hoffman >_______________________________________________ >apps-discuss mailing list >apps-discuss@ietf.org >https://www.ietf.org/mailman/listinfo/apps-discuss -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------9YGWBPDWWA8DOFJ0759RHCBHMNV8UV Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Primarily for fun, it would be interesting to see a comparison against Haverty's proposal.

/d

Paul Hoffman <paul.hoffman@vpnc.org> wrote:
Greetings again. Based on the requests here last week, we will be adding a section to the CBOR draft briefly discussing some major existing formats with respect to their major properties and the design goals for CBOR. We already have sections for ASN.1 DER/BER, MessagePack, and BSON. Are there other formats people would like to see in the list? What are people's favorite streaming-capable JSON-like binary formats?

--Paul Hoffman

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

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------9YGWBPDWWA8DOFJ0759RHCBHMNV8UV-- From duerst@it.aoyama.ac.jp Mon May 27 17:11: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 D997A21F8F43; Mon, 27 May 2013 17:11:29 -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 NtO378l-obkM; Mon, 27 May 2013 17:11:18 -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 A22E021F87E0; Mon, 27 May 2013 17:11:16 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r4S0B3ub013492; Tue, 28 May 2013 09:11:03 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 7e9c_5c03_159b5e88_c72b_11e2_b4a8_001e6722eec2; Tue, 28 May 2013 09:11:02 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id BE01DBF521; Tue, 28 May 2013 09:10:05 +0900 (JST) Message-ID: <51A3F60D.1030507@it.aoyama.ac.jp> Date: Tue, 28 May 2013 09:10:53 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Erik Wilde References: <5289AF00-A443-4FAD-BFA5-D62E0D2FE0BC@gmail.com> <51a285da.48ac0e0a.7995.ffffdc06SMTPIN_ADDED_BROKEN@mx.google.com> <95E83124-0A6D-45FE-AB63-5768F2369717@berkeley.edu> In-Reply-To: <95E83124-0A6D-45FE-AB63-5768F2369717@berkeley.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" , "link-relations@ietf.org" Subject: Re: [apps-discuss] NEW RELATION: property and context X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 May 2013 00:11:30 -0000 On 2013/05/27 23:20, Erik Wilde wrote: > hello ioseb. > > On May 27, 2013, at 0:28, Ioseb Dzmanashvili wrote: >> No, title attribute is only used for user interfaces i do not think anyone uses it for other purposes. In my apps i only use rel attribute values to decide which link to follow. > > i guess what markus wanted to know is how clients decide which link to follow for a specific property, if you have more than one. there must be some "property identifier" somewhere, so that clients can distinguish, right? i was wondering about the same thing. Also, having only a single property at the end of a link will be rare. Usually it's a collection of properties. So I'm wondering why the relation name is not "properties". Regards, Martin. From ht@inf.ed.ac.uk Tue May 28 02:10: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 967E421F9345; Tue, 28 May 2013 02:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=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 C3VB7guoTZxH; Tue, 28 May 2013 02:10:11 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCAD21F92E8; Tue, 28 May 2013 02:10:09 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id r4S99p0X014278; Tue, 28 May 2013 10:09:56 +0100 (BST) Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r4S99m3n016478; Tue, 28 May 2013 10:09:48 +0100 Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r4S99oqM004679; Tue, 28 May 2013 10:09:50 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id r4S99nH4004675; Tue, 28 May 2013 10:09:49 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Martin Thomson References: <88EA7D224AA4F24F9D7628368F7572A911BE62E0@TK5EX14MBXC254.redmond.corp.microsoft.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 28 May 2013 10:09:49 +0100 In-Reply-To: <88EA7D224AA4F24F9D7628368F7572A911BE62E0@TK5EX14MBXC254.redmond.corp.microsoft.com> (Martin Thomson's message of "Wed\, 8 May 2013 21\:05\:39 +0000") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b32 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: "draft-ietf-geopriv-relative-location.all@tools.ietf.org" , "appsdir@ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" , Brian Rosen Subject: Re: [apps-discuss] Appsdir review of draft-ietf-geopriv-relative-location X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 May 2013 09:10:16 -0000 Martin Thomson writes: > HST wrote: >> Ah, repeated re-readings have uncovered the origin of the problem, >> further back: >> >> "A client that does understand this extension will interpret the >> location within the relative element as a refinement of the >> baseline location, which gives the reference location for the >> relative offset." >> >> I read that the first five times as if it were bracketed like this: >> >> [a refinement of [the baseline location, which gives the >> reference location for the relative offset]]. >> >> But you mean it as if it were bracketed like this: >> >> [a refinement of the baseline location], [which gives the >> reference location for the relative offset]. >> >> So, I suggest you rephrase the whole sentence along the following >> lines: >> >> "A client that does understand this extension will interpret the >> location within the relative element as a refinement of the >> baseline location. The resulting refined location then gives >> the reference location for the relative offset." >> >> With that change, the paragraph containing the first quote above >> (the para beginning "The baseline location SHOULD be general >> enough") is comprehensible, but still very dense. I know >> illustrations are hard when one is restricted to ASCII-art, but a >> pair of examples would be a great help here, where one obeys the >> rules, and is not understood wrongly by a non-extension-supporting >> app, but the other breaks the rules, and therefore liable to be >> interpreted wrongly by such an app. >> >> And, finally, perhaps just _after_ the example now at the end of >> this section, just a brief gloss along the lines of >> >> The baseline location, given by the first ca:civicAddress element, >> the first child of the gp:location-info, is a street address, to >> the level of detail of the house number (123). The reference >> location is [now the front door, something else if you fix the 5.1 >> issue below]. The actual location, which is still within the >> baseline building, is a point 100m east and 50m north [?] of the >> front door. > > Oh. That's a bigger issue than you make out. Baseline != reference. Indeed. As I tried to explain above, I _finally_ figured that out, but the text doesn't make it easy. That's why I suggested a diagram. >> 4.11.1 >> >> "An 'http:' or 'https:' URL MUST be used unless . . ." >> >> Wouldn't it be more in the spirit of 2119 to say "A URI with scheme >> other than 'http:' or 'https:' SHOULD NOT be used unless" ? > > "SHOULD" is a weasel-word that SHOULD be avoided. I like to reserve SHOULD for cases where I am not providing a clear description of the exception cases. Most times, MUST works perfectly well if properly qualified. As I believe this is. Your call. >> 6. Schema Definition >> >> The repeated pattern used for complex type definition in this schema >> doc is[[MT]] ... >> This is overly . . . complex and invites confusion, [[MT]] ... >> Please simplify all your complex type definitions along these lines. > > I'm going to hold the line on this point. XML Schema defines two > ways to do the same thing and this draft consistently uses the form > that permits other uses than complex type restrictions of the > ur-type. I see no good reason to switch to the syntactic sugar > variant. Your gun, your foot, your bullet. You will just cause people to scratch their heads and waste time trying to understand why you used 10 words where one would do. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From cyrus@daboo.name Tue May 28 07:34: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 3B61521F9773 for ; Tue, 28 May 2013 07:34:14 -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 h0TSE89nUxvm for ; Tue, 28 May 2013 07:34:09 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id DE1C221F976E for ; Tue, 28 May 2013 07:34:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 68C0D4442FB9 for ; Tue, 28 May 2013 10:34:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rk15rJKnS1PH for ; Tue, 28 May 2013 10:34:07 -0400 (EDT) Received: from [10.0.1.11] (unknown [17.45.162.251]) by daboo.name (Postfix) with ESMTPSA id F2D374442FAA for ; Tue, 28 May 2013 10:34:06 -0400 (EDT) Date: Tue, 28 May 2013 10:34:07 -0400 From: Cyrus Daboo To: apps-discuss@ietf.org Message-ID: <4F5FFFB33B6673887C6A5ADF@cyrus.local> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1571 Subject: [apps-discuss] Request for adoption of iSchedule as a WG work item X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 May 2013 14:34:14 -0000 Hi folks, After consultation with Apps Area ADs and Apps Area WG chairs I would like to request that the Apps Area WG adopt iSchedule () as a working group item. iSchedule is a cross-domain calendaring and scheduling protocol based on iCalendar (RFC5545), iTIP (RFC5546) and HTTP. The goal is to allow efficient, secure and timely exchange of scheduling messages between servers. The calendaring aspects of this protocol are pretty straightforward. The hard part is security - in effect what we have is a messaging protocol akin to email and what we want to avoid are all the problems inherent in email (spoofing, spam etc). To that end we have adapted DKIM (RFC6376) for use within our protocol (with the primary goal of solving only the issues we need for iSchedule as opposed to developing a generic solution for signing HTTP messages). iSchedule originated with work done at the Calendaring and Scheduling Consortium (CalConnect) and has been developed over the last several years via IETF drafts. There are already a number of prototype implementations and CalConnect has been holding regular interop events to test those and weed out issues with the spec. At this point we want to move forward with the draft with more rigorous review, specifically of the security piece, and ultimately move forward with publication as a proposed standard. So this is a call to see who in this WG would be willing to work on this document, and whether the WG should adopt it. -- Cyrus Daboo From cyrus@daboo.name Tue May 28 07:40:13 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B405121F9759; Tue, 28 May 2013 07:40:13 -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 mk6SAlWNMEQL; Tue, 28 May 2013 07:40:09 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id F32C421F97A5; Tue, 28 May 2013 07:40:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 989124443336; Tue, 28 May 2013 10:40:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJBZUcuBhF3j; Tue, 28 May 2013 10:40:07 -0400 (EDT) Received: from [10.0.1.11] (unknown [17.45.162.251]) by daboo.name (Postfix) with ESMTPSA id 674CC444332B; Tue, 28 May 2013 10:40:06 -0400 (EDT) Date: Tue, 28 May 2013 10:40:07 -0400 From: Cyrus Daboo To: S Moonesamy Message-ID: <2B58ED5599DDF1DD894E64BA@cyrus.local> In-Reply-To: <6.2.5.6.2.20130523142426.0daf25c8@resistor.net> References: <6.2.5.6.2.20130429065657.0d392368@elandnews.com> <1778285.8glKQALeLt@scott-latitude-e6320> <6.2.5.6.2.20130523142426.0daf25c8@resistor.net> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=273 Cc: spfbis@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [spfbis] APPSDIR review of draft-ietf-spfbis-4408bis-14.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, 28 May 2013 14:40:13 -0000 Hi S, --On May 23, 2013 2:28:31 PM -0700 S Moonesamy wrote: > Do the above comments address your AppsDir review ( > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09353.html )? Yes, I am OK with the changes adopted. -- Cyrus Daboo From murch@andrew.cmu.edu Tue May 28 07:58: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 8DB7D21F8EC1 for ; Tue, 28 May 2013 07:58: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 YoARp0ibHFmv for ; Tue, 28 May 2013 07:58:44 -0700 (PDT) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.11.95]) by ietfa.amsl.com (Postfix) with ESMTP id C8ACE21F8E2C for ; Tue, 28 May 2013 07:58:44 -0700 (PDT) Received: from [68.245.171.115] (160.sub-174-254-177.myvzw.com [174.254.177.160]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.4/8.14.4) with ESMTP id r4SEwSrh017857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 28 May 2013 10:58:43 -0400 Message-ID: <51A4C62E.9000201@andrew.cmu.edu> Date: Tue, 28 May 2013 10:58:54 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <32031_1369751656_r4SEYFTw020097_4F5FFFB33B6673887C6A5ADF@cyrus.local> In-Reply-To: <32031_1369751656_r4SEYFTw020097_4F5FFFB33B6673887C6A5ADF@cyrus.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.5.19.222118 X-SMTP-Spam-Clean: 10% ( TO_IN_SUBJECT 0.5, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1800_1899 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, RDNS_POOLED 0, RDNS_SUSP 0, RDNS_SUSP_SPECIFIC 0, RDNS_WIRELESS 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __RDNS_POOLED_6 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_MAILTO 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0) X-SMTP-Spam-Score: 10% X-Scanned-By: MIMEDefang 2.60 on 128.2.11.95 Subject: Re: [apps-discuss] Request for adoption of iSchedule as a WG work item X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 May 2013 14:58:49 -0000 On 5/28/2013 10:34 AM, Cyrus Daboo wrote: > Hi folks, > After consultation with Apps Area ADs and Apps Area WG chairs I would > like to request that the Apps Area WG adopt iSchedule > () as > a working group item. > > iSchedule is a cross-domain calendaring and scheduling protocol based > on iCalendar (RFC5545), iTIP (RFC5546) and HTTP. The goal is to allow > efficient, secure and timely exchange of scheduling messages between > servers. > > The calendaring aspects of this protocol are pretty straightforward. > The hard part is security - in effect what we have is a messaging > protocol akin to email and what we want to avoid are all the problems > inherent in email (spoofing, spam etc). To that end we have adapted > DKIM (RFC6376) for use within our protocol (with the primary goal of > solving only the issues we need for iSchedule as opposed to developing > a generic solution for signing HTTP messages). > > iSchedule originated with work done at the Calendaring and Scheduling > Consortium (CalConnect) and has been developed over the last several > years via IETF drafts. There are already a number of prototype > implementations and CalConnect has been holding regular interop events > to test those and weed out issues with the spec. > > At this point we want to move forward with the draft with more > rigorous review, specifically of the security piece, and ultimately > move forward with publication as a proposed standard. > > So this is a call to see who in this WG would be willing to work on > this document, and whether the WG should adopt it I am in favor of appsawg adopting this draft and I will continue to help work on it. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From internet-drafts@ietf.org Tue May 28 08:08: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 70B0C21F973F; Tue, 28 May 2013 08:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.105, 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 HghGosivjiul; Tue, 28 May 2013 08:08:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0609521F9735; Tue, 28 May 2013 08:08:21 -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.50 Message-ID: <20130528150820.16413.98334.idtracker@ietfa.amsl.com> Date: Tue, 28 May 2013 08:08:20 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-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: Tue, 28 May 2013 15:08:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : XML Media Types Author(s) : Chris Lilley MURATA Makoto Alexey Melnikov Henry S. Thompson Filename : draft-ietf-appsawg-xml-mediatypes-01.txt Pages : 30 Date : 2013-05-28 Abstract: This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types. This specification also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME entities. Major differences from [RFC3023] are alignment of charset handling for text/xml and text/xml-external-parsed-entity with application/ xml, the addition of XPointer and XML Base as fragment identifiers and base URIs, respectively, mention of the XPointer Registry, and updating of many references. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-xml-mediatypes There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-xml-mediatypes-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ht@inf.ed.ac.uk Tue May 28 08:24: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 4819821F9817; Tue, 28 May 2013 08:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 Z-Hj3X-QKQeT; Tue, 28 May 2013 08:24:03 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id B6D5A21F9836; Tue, 28 May 2013 08:24:01 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id r4SFNoGi025285; Tue, 28 May 2013 16:23:50 +0100 (BST) Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r4SFNm67000455; Tue, 28 May 2013 16:23:48 +0100 Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r4SFNoex014001; Tue, 28 May 2013 16:23:50 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id r4SFNoSL013997; Tue, 28 May 2013 16:23:50 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: internet-drafts@ietf.org References: <20130528150820.16413.98334.idtracker@ietfa.amsl.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 28 May 2013 16:23:50 +0100 In-Reply-To: <20130528150820.16413.98334.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Tue\, 28 May 2013 08\:08\:20 -0700") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b32 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: apps-discuss@ietf.org, i-d-announce@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-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: Tue, 28 May 2013 15:24:08 -0000 internet-drafts writes: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Applications Area Working Group Working Group of the IETF. > > Title : XML Media Types > Author(s) : Chris Lilley > MURATA Makoto > Alexey Melnikov > Henry S. Thompson > Filename : draft-ietf-appsawg-xml-mediatypes-01.txt > Pages : 30 > Date : 2013-05-28 The auto-generated diffs are more-or-less useless -- but I put diff markup into the XML, which produces, courtesy of Julian's hard work, http://www.w3.org/XML/2012/10/3023bis/draft-ietf-appsawg-xml-mediatypes-01_diff.html which I hope and believe _is_ useful. Thanks to Peter Rushforth, SM and Martin D. for extensive feedback -- I'll post a detailed account of what I did in response to their comments shortly. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From ht@inf.ed.ac.uk Tue May 28 09:47: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 EDF5C21F983F; Tue, 28 May 2013 09:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 2xbnH-hnhXkT; Tue, 28 May 2013 09:47:33 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id BE8CC21F983E; Tue, 28 May 2013 09:47:32 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id r4SGlTCd024049; Tue, 28 May 2013 17:47:29 +0100 (BST) Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r4SGlR2j004001; Tue, 28 May 2013 17:47:27 +0100 Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r4SGlS0C015968; Tue, 28 May 2013 17:47:28 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id r4SGlSSo015964; Tue, 28 May 2013 17:47:28 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: internet-drafts@ietf.org References: <20130528150820.16413.98334.idtracker@ietfa.amsl.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 28 May 2013 17:47:28 +0100 In-Reply-To: (Henry S. Thompson's message of "Tue\, 28 May 2013 16\:23\:50 +0100") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b32 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: apps-discuss@ietf.org, i-d-announce@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-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: Tue, 28 May 2013 16:47:38 -0000 ht writes: > internet-drafts writes: > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Applications Area Working Group Working Group of the IETF. >> >> Title : XML Media Types >> Author(s) : Chris Lilley >> MURATA Makoto >> Alexey Melnikov >> Henry S. Thompson >> Filename : draft-ietf-appsawg-xml-mediatypes-01.txt >> Pages : 30 >> Date : 2013-05-28 > . . . > Thanks to Peter Rushforth, SM and Martin D. for extensive feedback -- > I'll post a detailed account of what I did in response to their > comments shortly. As promised, a quick-and-dirty-formatted Disposition of Comments is now available at http://www.w3.org/XML/2012/10/3023bis/00-comments.html It's organised by secton and commentator. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From superuser@gmail.com Tue May 28 09:57: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 4F76821F98A9 for ; Tue, 28 May 2013 09:57:09 -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 kgfilMwKQZ8T for ; Tue, 28 May 2013 09:57:08 -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 2E62821F98A6 for ; Tue, 28 May 2013 09:57:04 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id u59so5129050wes.1 for ; Tue, 28 May 2013 09:57:02 -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=uEUaLSyDGLSnVE/y3AMEgd3HJMVswrUBNmYqQ8IQ/XM=; b=Xip/YttJnLkdm+d9vskY6yZfWY/1SpS03pZ3BEGd+X1Rh7MGzSRbxOMDGNZzWUBSQa dx1hRBaUBKq53SNJzX2PmTgkXJeotkFbjH8DGm38zPmrLn9rMqcJFO4MQJFc8Ol8PvnL wZ2cXYluTEm2DOn33Tept+8l/M5aNg5Pp1egNyR4+zrgQqr5xK+jhfgMfjKVf6mRPYgX Obrgu2obQOpY2JkO3GxbvwJVG/SMQu447IirkXG4YwaTg8mfbjUS/g6z98H4WFvryw25 +xtexK0nc4VYBk+1yZ522DpA19+k/ueaiWq80awLfV5iNRkvDYxFkLQp/plOcpnsWLVm JYSA== MIME-Version: 1.0 X-Received: by 10.180.88.231 with SMTP id bj7mr13034861wib.5.1369760222812; Tue, 28 May 2013 09:57:02 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Tue, 28 May 2013 09:57:02 -0700 (PDT) In-Reply-To: References: <01OTO93GD6L2000054@mauve.mrochek.com> <20130515202613.24981.qmail@joyce.lan> <01OTOENRSJ6Q000054@mauve.mrochek.com> <01OTSF48H616000054@mauve.mrochek.com> Date: Tue, 28 May 2013 09:57:02 -0700 Message-ID: From: "Murray S. Kucherawy" To: John R Levine Content-Type: multipart/alternative; boundary=f46d0443048a82230804ddca27c7 Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-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: Tue, 28 May 2013 16:57:10 -0000 --f46d0443048a82230804ddca27c7 Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 18, 2013 at 8:00 PM, John R Levine wrote: > With it refreshed and with all the new content, I'd love to have some more >>> reviews of it in its current form. >>> >> > Well, since you asked. > > I'm looking at the whole thing and I have to say I don't understand the > point of sections 4 and 5. I understand that Exchange and Outlook smash > messages into an internal format and sort of reconstruct the original, > sometimes, but I can't tell whether that's what you're referring to or > something else. > > I think sec 4 is trying to say mail software may have a variety of > internal representations, but all we're talking about here are messages > interchanged in what purports to be 5322 (or its predecessors) format. > Consider a system that has several independent filtering modules. It's important that the modules don't change the content as it passes from one to the next as doing so might obscure something that the next module might consider reject-worthy. Therefore, whatever transformations need to be done have to be kept internal to the module and not released as the "real" content. > Sec 5 appears to say that if you try to parse and unparse a message, you > probably won't get back quite the same thing and particularly in the > presence of DKIM signatures and the like, details matter, so don't do that. > If you need multiple formats, retain the original so if you need to bounce > or report something, you can report what you actually received. > > If that's not what you mean, I'm totally confused. > This is similar, but has a different nuance. If a message makes it all the way to an MUA where it's reported as abusive (spam, virus, whatever), then a report generated based on what the MUA sees might not be useful to the report receiver because it doesn't match the message that was originally generated. In the next revision, I've mushed 4 and 5 together since they were so similar. I'll post later today and see what you think. > I think 8.6 has TMI, I'd just say to synthesize a unique Message-ID. MSAs > have been doing that for decades, people know how to do it, and your > example seems more complicated than enlightening. (Why use gmtime rather > than just stick the numeric value of "now" into the ID. Doesn't matter > what the encoding is so long as it changes frequently.) > That's a real-world example; it's what sendmail does. But sure, simpler is better. I'll clean it up. > > 10.1, bottom of p. 17: MUST take? Even after downcasing the rogue > 2119ism, I'd make it a lot milder than that. If I am feeding stuff into my > webmail system, and I happen to know that my display module handles long > lines OK, I'd just leave the long lines alone. It is my impression that > long lines are much more likely to be from sloppy composition software than > malicious. > That MUST should've come out in the last edit, since we're no longer doing 2119 stuff in here. I'll just take that out. Thanks for your comments. -MSK --f46d0443048a82230804ddca27c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, May 18, 2013 at 8:00 PM, John R Levine <johnl@tau= gh.com> wrote:
With it refreshed and with all the new content, I'd love to have some m= ore
reviews of it in its current form.

Well, since you asked.

I'm looking at the whole thing and I have to say I don't understand= the point of sections 4 and 5. =A0I understand that Exchange and Outlook s= mash messages into an internal format and sort of reconstruct the original,= sometimes, but I can't tell whether that's what you're referri= ng to or something else.

I think sec 4 is trying to say mail software may have a variety of internal= representations, but all we're talking about here are messages interch= anged in what purports to be 5322 (or its predecessors) format.


Consider a system that has several independent=20 filtering modules.=A0 It's important that the modules don't change = the=20 content as it passes from one to the next as doing so might obscure=20 something that the next module might consider reject-worthy.=A0 Therefore, whatever transformations need to be done have to be kept internal to=20 the module and not released as the "real" content.

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Sec 5 appears to say that if you try to parse and unparse a message, you pr= obably won't get back quite the same thing and particularly in the pres= ence of DKIM signatures and the like, details matter, so don't do that.= If you need multiple formats, retain the original so if you need to bounce= or report something, you can report what you actually received.

If that's not what you mean, I'm totally confused.
=

This is similar, but has a different nuance.=A0 If a me= ssage makes it all the way to an MUA where it's reported as abusive (sp= am, virus, whatever), then a report generated based on what the MUA sees mi= ght not be useful to the report receiver because it doesn't match the m= essage that was originally generated.

In the next revision, I've mushed 4 and 5 together since they were = so similar.=A0 I'll post later today and see what you think.


I think 8.6 has TMI, I'd just say to synthesize a unique Message-ID. MS= As have been doing that for decades, people know how to do it, and your exa= mple seems more complicated than enlightening. =A0(Why use gmtime rather th= an just stick the numeric value of "now" into the ID. =A0Doesn= 9;t matter what the encoding is so long as it changes frequently.)

That's a real-world example; it's = what sendmail does.=A0 But sure, simpler is better.=A0 I'll clean it up= .
=A0

10.1, bottom of p. 17: MUST take? =A0Even after downcasing the rogue 2119is= m, I'd make it a lot milder than that. =A0If I am feeding stuff into my= webmail system, and I happen to know that my display module handles long l= ines OK, I'd just leave the long lines alone. =A0It is my impression th= at long lines are much more likely to be from sloppy composition software t= han malicious.

That MUST should've come out in the la= st edit, since we're no longer doing 2119 stuff in here.=A0 I'll ju= st take that out.

Thanks for your comments.

-MSK
--f46d0443048a82230804ddca27c7-- From internet-drafts@ietf.org Tue May 28 14:24: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 D038221F9371; Tue, 28 May 2013 14:24:09 -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 Txz2LNxkh4jd; Tue, 28 May 2013 14:23:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38CA821F8DB7; Tue, 28 May 2013 14:23:25 -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.50 Message-ID: <20130528212325.22291.7841.idtracker@ietfa.amsl.com> Date: Tue, 28 May 2013 14:23:25 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 21:24:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Advice for Safe Handling of Malformed Messages Author(s) : Murray S. Kucherawy Gregory N. Shapiro Filename : draft-ietf-appsawg-malformed-mail-05.txt Pages : 19 Date : 2013-05-28 Abstract: Although Internet mail formats have been precisely defined since the 1970s, authoring and handling software often show only mild conformance to the specifications. The distributed and non- interactive nature of email has often prompted adjustments to receiving software, to handle these variations, rather than trying to gain better conformance by senders, since the receiving operator is primarily driven by complaining recipient users and has no authority over the sending side of the system. Processing with such flexibility comes at some cost, since mail software is faced with decisions about whether or not to permit non-conforming messages to continue toward their destinations unaltered, adjust them to conform (possibly at the cost of losing some of the original message), or outright rejecting them. A core requirement for interoperability is that both sides of an exchange work from the same details and semantics. By having receivers be flexible, beyond the specifications, there can be -- and often has been -- a good chance that a message will not be fully interoperable. Worse, a well-established pattern of tolerance for variations can sometimes be used as an attack vector. This document includes a collection of the best advice available regarding a variety of common malformed mail situations, to be used as implementation guidance. It must be emphasized, however, that the intent of this document is not to standardize malformations or otherwise encourage their proliferation. The messages are manifestly malformed, and the code and culture that generates them needs to be fixed. Therefore, these messages should be rejected outright if at all possible. Nevertheless, many malformed messages from otherwise legitimate senders are in circulation and will be for some time, and, unfortunately, commercial reality shows that we cannot always simply reject or discard them. Accordingly, this document presents alternatives for dealing with them in ways that seem to do the least additional harm until the infrastructure is tightened up to match the standards. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-malformed-mail There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-malformed-mail-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-malformed-mail-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From superuser@gmail.com Tue May 28 14:27: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 11B7811E80E0 for ; Tue, 28 May 2013 14:27: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, 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 FYTjo3oskF16 for ; Tue, 28 May 2013 14:27:12 -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 61E8611E80A5 for ; Tue, 28 May 2013 14:27:12 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hq7so2926346wib.6 for ; Tue, 28 May 2013 14:27:10 -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=tiuQvMh8XyTyQHlqi48OrCioKdKvSpxdoIuJ/dzRVp4=; b=wwUZCy0WIzwyTAbSIUm+zTC3hKiXVHmLEMX45aisihpIXArgVitphAwviuee3wlro5 fbzpUjbPqEP7cynTLkXZg4LwXbVOWVAGP3kjRPJUEXyU9JQeX2uB9H0A9XyD85b2E5U2 ukTB+ULef2qxFl3toM5odGs9MOtsGYRmffvZTeqUiBT3ebfgeY5nGhxRMvaBeMH9NkJQ tdKYgsrJ9hJPgYCOneOZ/GGAYg8CmEqK09xHs9NnWyhEANuC5Ps1rC4GusMKCzGsduOT Rd8xmX6I0MyKdKxRyYDNGbsv9dBOenfKsJ1ZBVLbSC+uH9pZtOP9OY1EtmAvYP+cDLuj wiBw== MIME-Version: 1.0 X-Received: by 10.180.189.136 with SMTP id gi8mr13903297wic.11.1369776430765; Tue, 28 May 2013 14:27:10 -0700 (PDT) Received: by 10.180.14.34 with HTTP; Tue, 28 May 2013 14:27:10 -0700 (PDT) In-Reply-To: <20130528212325.22291.7841.idtracker@ietfa.amsl.com> References: <20130528212325.22291.7841.idtracker@ietfa.amsl.com> Date: Tue, 28 May 2013 14:27:10 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a11c2412c93dc5304ddcded18 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 21:27:13 -0000 --001a11c2412c93dc5304ddcded18 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 28, 2013 at 2:23 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Applications Area Working Group Working > Group of the IETF. > > Title : Advice for Safe Handling of Malformed Messages > Author(s) : Murray S. Kucherawy > Gregory N. Shapiro > Filename : draft-ietf-appsawg-malformed-mail-05.txt > Pages : 19 > Date : 2013-05-28 > [...] > Incorporates the latest feedback from John Levine, Jim Galvin, Ned, and a couple of others. Comments welcome. -MSK --001a11c2412c93dc5304ddcded18 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 28, 2013 at 2:23 PM, <internet-drafts= @ietf.org> wrote:

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

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Advice for Safe Handling of Mal= formed Messages
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Murray S. Kucherawy
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gregory N. Shapiro
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-malformed-mail= -05.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 19
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-05-28
[...]

Incorporates the latest feedback = from John Levine, Jim Galvin, Ned, and a couple of others.=A0 Comments welc= ome.

-MSK
--001a11c2412c93dc5304ddcded18-- From markus.lanthaler@gmx.net Tue May 28 15:57: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 F1BD021F90D2 for ; Tue, 28 May 2013 15:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fl+Oobjbc6Tk for ; Tue, 28 May 2013 15:57:41 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 7179A21F90E0 for ; Tue, 28 May 2013 15:57:34 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.20]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M21p7-1USYPW1VUJ-00tzdC for ; Wed, 29 May 2013 00:57:33 +0200 Received: (qmail invoked by alias); 28 May 2013 22:57:33 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp020) with SMTP; 29 May 2013 00:57:33 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX18otGAtoOMowNodJAkYVi5GO6iGdULAee1NKExaDM scnGCh6GI3iLVG From: "Markus Lanthaler" To: "'Ioseb Dzmanashvili'" References: <5289AF00-A443-4FAD-BFA5-D62E0D2FE0BC@gmail.com> <51a285da.48ac0e0a.7995.ffffdc06SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Wed, 29 May 2013 00:57:08 +0200 Message-ID: <000001ce5bf6$c03a4610$40aed230$@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: Ac5aq7+OUdjHB5AwRc2KieZr+QbfEgA+qCTw Content-Language: de X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org, link-relations@ietf.org Subject: Re: [apps-discuss] NEW RELATION: property and context X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 May 2013 22:57:46 -0000 On Monday, May 27, 2013 9:28 AM, Ioseb Dzmanashvili wrote: > My RDF knowledge is rudimentary, but what i can say for sure the > "context" link relation and "@context" from JSON-LD are different > things. Of course. I just mentioned it because they use exactly the same = terminology and I was not the only one to be confused by this. > Here is what JSON-LD[1] documentation says: "The secret lies > in the @context, which instructs Linked Data-aware processors on how > to interpret the JSON object." which is not the case for the "context" > link relation... it's much simpler and must be used to indicate that a > resource is a member of another resource and only in cases when we do > not have collection/item relationships. Sorry, I don't understand this. It indicates that resource I is a member = of a resource C but only if resource I is not an item of collection C!? = In which case then? Aren't you contradicting yourself? > For example if i share > resource URI which is a member of another resource i can use the > "context" link rel to inform processing agent that shared resource is > a member of another resource. Unfortunately, this doesn't make it any clearer to me. > > How do you know which link to follow in your apps? Do you do that > > based on the title attribute? > > No, title attribute is only used for user interfaces i do not think > anyone uses it for other purposes. In my apps i only use rel attribute > values to decide which link to follow. As Erik already clarified in another thread I'm interested in how your = application is able to select the correct link to follow if you have = multiple links, e.g.: Link: ; rel=3D"property"; title=3D"Property A" Link: ; rel=3D"property"; title=3D"Property B" Link: ; rel=3D"property"; title=3D"Property C" Since there's no other information than the rel and the title (and the = URL) you obviously would have to program against the title. If you need = another rel as you showed in the other thread: > Link: ; rel=3D"property = http://rels.service.org/properties#title"; > title=3D"Human friendly text here..." Then why do you need "property"? Isn't = http://rels.service.org/properties#title all you need then? -- Markus Lanthaler @markuslanthaler From jasnell@gmail.com Tue May 28 16:09: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 BCB4021F91B0 for ; Tue, 28 May 2013 16:09:50 -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 PF7hW9+Qf+CE for ; Tue, 28 May 2013 16:09:49 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D43A221F8B64 for ; Tue, 28 May 2013 16:09:48 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id tb18so9863865obb.31 for ; Tue, 28 May 2013 16:09:46 -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=UHmq8ixJYRqgpdbOYjcIY7UE8BOk5/3PhwmQ9abo0pU=; b=I5/9Fbce0ZleyuDv1k7Cd95/+qwTqhWvD+YgFgZxLj4cozn6fzROU92dUjs27HY8Ab cq50sAMiE6TUfFeVS5cVYJNyZak7WRX9qt/vPiz643RbAvkYGpPoP/2kN8sVnAddMExa yST9yVWa0o7+WxWcED6+3ZLa7tdadN1LUN66HrjQNOQjcwFeUZqv6OVSBoDKcrPMHZ7/ BXiMEPZO5KCGHC3412DNdoOaWixGcWup9SDP21UvWcEpgFBk0GbgzCVif6vZy6neSnSs XwGvpwKfrYPT7DY6rwfVExTyEzHNZGBdP99JFE5WPUP5VsmSW4m8LTfjbqrlQOeEuxW0 DzfQ== X-Received: by 10.60.102.178 with SMTP id fp18mr48441oeb.35.1369782586826; Tue, 28 May 2013 16:09:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.3.137 with HTTP; Tue, 28 May 2013 16:09:26 -0700 (PDT) In-Reply-To: <4038B5FE76874C54A819A07FE192AEF8@gmail.com> References: <4038B5FE76874C54A819A07FE192AEF8@gmail.com> From: James M Snell Date: Tue, 28 May 2013 16:09:26 -0700 Message-ID: To: Ioseb Dzmanashvili Content-Type: text/plain; charset=UTF-8 Cc: link-relations@ieft.org, IETF Apps Discuss Subject: Re: [apps-discuss] NEW RELATION: property and context X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 May 2013 23:09:51 -0000 Based on an initial review (and a few days to process)... The "context" link relation seems somewhat useful, "property" not so much. "context" is useful for things like processing json-ld. That strikes me as being good. - James On Sun, May 26, 2013 at 4:21 AM, Ioseb Dzmanashvili wrote: > Dear All, > > I've submitted new draft for the "property" and "context" link relation > types: > http://tools.ietf.org/html/draft-property-and-context-link-relations-00 > > Description: > > - This specification defines link relation types that may be used to express > the relationships between a resource and associated properties or between a > resource and it's context. > - The "property" and "context" link relations are intentionally generic, and > they can be used with multiple media types in a wide variety of use cases > - The "property" Link Relation Type: When included in a response, the > "property" link relation identifies a target resource that represents a > property of the context resource. > - The "context" Link Relation Type: When included in a response, the > "context" link relation identifies a target resource that represents a > context document of which the context resource is a member. > > Could you please review? > Thanks in advance! > > Best regards, > ioseb > -- > Ioseb Dzmanashvili > AzRy LLC > Software Architect > #8, Chachava str. > Tbilisi, 0159, Georgia > Mobile: +(995) 99753388 > github.com/ioseb > twitter.com/iosebi > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From markus.lanthaler@gmx.net Tue May 28 16:26: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 7950321F8AF4 for ; Tue, 28 May 2013 16:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.22 X-Spam-Level: X-Spam-Status: No, score=-0.22 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, 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 brtA5AuDzoyG for ; Tue, 28 May 2013 16:26:44 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 75D1421F896B for ; Tue, 28 May 2013 16:26:44 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.34]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MNfPA-1Uob5l2Eaw-007Hjp for ; Wed, 29 May 2013 01:26:43 +0200 Received: (qmail invoked by alias); 28 May 2013 23:26:43 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp034) with SMTP; 29 May 2013 01:26:43 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1+w4y5H7uCwG1lYaliZ3XtNKyr8bucMua7FHBZifK MdT1BLPP2/ifEE From: "Markus Lanthaler" To: "'James M Snell'" References: <4038B5FE76874C54A819A07FE192AEF8@gmail.com> In-Reply-To: Date: Wed, 29 May 2013 01:26:47 +0200 Message-ID: <02c301ce5bfa$d3631240$7a2936c0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5b+HfI5BH1eqlzTSK/hm/Qd2jNPwAAgYfg Content-Language: de X-Y-GMX-Trusted: 0 Cc: link-relations@ieft.org, 'IETF Apps Discuss' Subject: Re: [apps-discuss] NEW RELATION: property and context X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 May 2013 23:26:50 -0000 On Wednesday, May 29, 2013 1:09 AM, James M Snell wrote: > Based on an initial review (and a few days to process)... The > "context" link relation seems somewhat useful, "property" not so much. > > "context" is useful for things like processing json-ld. That strikes > me as being good. James, did you read all the discussion? Ioseb made it quite clear that his "context" is intended to be used completely different than JSON-LD's context. I'm still not sure I understand its semantics. -- Markus Lanthaler @markuslanthaler From jasnell@gmail.com Tue May 28 17:21: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 BEA4911E80E4 for ; Tue, 28 May 2013 17:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.766 X-Spam-Level: X-Spam-Status: No, score=-5.766 tagged_above=-999 required=5 tests=[AWL=-2.167, 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 OdiqsEXe4wfD for ; Tue, 28 May 2013 17:21:14 -0700 (PDT) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id C712211E80DE for ; Tue, 28 May 2013 17:21:12 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id f4so10890422oah.10 for ; Tue, 28 May 2013 17:21: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:from:date:message-id:subject:to :cc:content-type; bh=rAi3tbYr5I1k8A7021bMHbmqkXao5pDSREQPCU5lbrc=; b=wjXhV2DeV7oNsGMSzUGccoUu91eQq0TNIO5gbZAEuGHq/nxTyCXYXsT6dtQGRb1b1n ckogFNA6i2up29GCYQuMZ1OxtS8ITbaB1wOAkeo3XVls8l7E9N5NOegjt6nzf/uUO6Nk 4Eh6ovSchl2JQe2/p5TtwWfdimF9+P7C8rahzdhRrFPsimX5QAB85dTvnOwpBhbztqIE GtN8EQiNxiEcTrQASfyXSpaGieLTHez0Onn59lukgpf+TBaUR0xl81IMerXg8mtz57Z7 4cLqYZ2V7cQFGUEqFO4h2Y5kXXijIW2aBy0aUKLKp4VsMVDw1gx22G6VAnA5XCHAusFV jIhQ== X-Received: by 10.182.227.133 with SMTP id sa5mr103421obc.96.1369786869445; Tue, 28 May 2013 17:21:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.3.137 with HTTP; Tue, 28 May 2013 17:20:49 -0700 (PDT) In-Reply-To: <51a53d34.48b40e0a.70fc.1549SMTPIN_ADDED_BROKEN@mx.google.com> References: <4038B5FE76874C54A819A07FE192AEF8@gmail.com> <51a53d34.48b40e0a.70fc.1549SMTPIN_ADDED_BROKEN@mx.google.com> From: James M Snell Date: Tue, 28 May 2013 17:20:49 -0700 Message-ID: To: Markus Lanthaler Content-Type: text/plain; charset=UTF-8 Cc: link-relations@ieft.org, IETF Apps Discuss Subject: Re: [apps-discuss] NEW RELATION: property and context X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 00:21:21 -0000 On Tue, May 28, 2013 at 4:26 PM, Markus Lanthaler wrote: > On Wednesday, May 29, 2013 1:09 AM, James M Snell wrote: >> Based on an initial review (and a few days to process)... The >> "context" link relation seems somewhat useful, "property" not so much. >> >> "context" is useful for things like processing json-ld. That strikes >> me as being good. > > James, did you read all the discussion? Ioseb made it quite clear that his > "context" is intended to be used completely different than JSON-LD's > context. I'm still not sure I understand its semantics. > Yep, I saw that and purposefully chose to ignore it :-) ... given the general definition of "context" given in the draft, use for json-ld type scenarios is not ruled out. - James > > > -- > Markus Lanthaler > @markuslanthaler > > > From markus.lanthaler@gmx.net Tue May 28 17:38: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 02D1221F8B60 for ; Tue, 28 May 2013 17:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1afvjAoubJQ for ; Tue, 28 May 2013 17:38:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9D05A21F8B65 for ; Tue, 28 May 2013 17:38:18 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MISkD-1Uiqus29b5-004EhI for ; Wed, 29 May 2013 02:38:17 +0200 Received: (qmail invoked by alias); 29 May 2013 00:38:17 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp027) with SMTP; 29 May 2013 02:38:17 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1+8iKwL7CS8WCbqYDZmM89roHEUR0cUdHqmzl0d6D RZkGupUE5QE+cF From: "Markus Lanthaler" To: "'James M Snell'" , "'Ioseb Dzmanashvili'" References: <4038B5FE76874C54A819A07FE192AEF8@gmail.com> <51a53d34.48b40e0a.70fc.1549SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Wed, 29 May 2013 02:38:20 +0200 Message-ID: <02e201ce5c04$d2d397f0$787ac7d0$@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: Ac5cAmtJo1mjC5ZnRG+S6ZcADBEt8wAAZF6g Content-Language: de X-Y-GMX-Trusted: 0 Cc: link-relations@ieft.org, 'IETF Apps Discuss' Subject: Re: [apps-discuss] NEW RELATION: property and context X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 00:38:32 -0000 On Wednesday, May 29, 2013 2:21 AM, James M Snell wrote: > > James, did you read all the discussion? Ioseb made it quite clear > that his > > "context" is intended to be used completely different than JSON-LD's > > context. I'm still not sure I understand its semantics. > > >=20 > Yep, I saw that and purposefully chose to ignore it :-) ... given the > general definition of "context" given in the draft, use for json-ld > type scenarios is not ruled out. Well.. the problem I have with the current I-D is that even after all = these discussions I still don't understand what "context" is supposed to = mean. Quoting the I-D: When included in a response, the "context" link relation identifies a target resource that represents a context document of which the context resource is a member. For example, if a resource represents the property of a photo, that same resource may include link to a resource which the property belongs. Taking the second paragraph, wouldn't the "describes" relation achieve = just that? Quoting the abstract of RFC6892 which defines "describes": This specification defines the 'describes' link relation type that allows resource representations to indicate that they are describing another resource. In contexts where applications want to associate described resources and description resources, and want to build services based on these associations, the 'describes' link relation type provides the opposite direction of the 'describedby' link relation type, which already is a registered link relation type. I would really like to understand the differences but so far I haven't = seen any. Ioseb, maybe a couple of more concrete examples about how you = see the two rels being used would help a lot. And maybe also mention why = collection/item or describes/describedBy wouldn't work for those = examples. Cheers, Markus -- Markus Lanthaler @markuslanthaler From ned.freed@mrochek.com Tue May 28 18:05: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 BEC6611E80A2 for ; Tue, 28 May 2013 18:05: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=[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 eack5oOtq8Gp for ; Tue, 28 May 2013 18:05:35 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id AB3B121F8EFC for ; Tue, 28 May 2013 18:05:35 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OU6TEOU9FK0077KV@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 28 May 2013 18:00:33 -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 <01OU5J2573CW000054@mauve.mrochek.com>; Tue, 28 May 2013 18:00:29 -0700 (PDT) Message-id: <01OU6TEMJ65Q000054@mauve.mrochek.com> Date: Tue, 28 May 2013 17:50:35 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 28 May 2013 09:57:02 -0700" References: <01OTO93GD6L2000054@mauve.mrochek.com> <20130515202613.24981.qmail@joyce.lan> <01OTOENRSJ6Q000054@mauve.mrochek.com> <01OTSF48H616000054@mauve.mrochek.com> To: "Murray S. Kucherawy" Cc: Ned Freed , John R Levine , IETF Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-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, 29 May 2013 01:05:42 -0000 > On Sat, May 18, 2013 at 8:00 PM, John R Levine wrote: > > With it refreshed and with all the new content, I'd love to have some more > >>> reviews of it in its current form. > >>> > >> > > Well, since you asked. > > > > I'm looking at the whole thing and I have to say I don't understand the > > point of sections 4 and 5. I understand that Exchange and Outlook smash > > messages into an internal format and sort of reconstruct the original, > > sometimes, but I can't tell whether that's what you're referring to or > > something else. > > > > I think sec 4 is trying to say mail software may have a variety of > > internal representations, but all we're talking about here are messages > > interchanged in what purports to be 5322 (or its predecessors) format. > > > Consider a system that has several independent filtering modules. It's > important that the modules don't change the content as it passes from one > to the next as doing so might obscure something that the next module might > consider reject-worthy. Therefore, whatever transformations need to be > done have to be kept internal to the module and not released as the "real" > content. It's nowhere near this simple. Sometimes you want filtering modules exposed to unadulterated content. One way to arrange for that is preclude any changes, but another is to run the modules in parallel. After all, if they're not talking to each other, why wouldn't you want them to run simultaneously? But other times you want them to be able to pass information to each other. Unfortunately that often can only be done by adding headers. And there are even times when you want much more radical transformations applies, such as the removal of encryption, forced conversion to MIME format, etc. etc. There really isn't a one size fits all answer here, and it's silly to think one can be found. > > Sec 5 appears to say that if you try to parse and unparse a message, you > > probably won't get back quite the same thing and particularly in the > > presence of DKIM signatures and the like, details matter, so don't do that. > > If you need multiple formats, retain the original so if you need to bounce > > or report something, you can report what you actually received. > > > > If that's not what you mean, I'm totally confused. > > > This is similar, but has a different nuance. If a message makes it all the > way to an MUA where it's reported as abusive (spam, virus, whatever), then > a report generated based on what the MUA sees might not be useful to the > report receiver because it doesn't match the message that was originally > generated. And sometimes the opposite is true, e.g., in regards to attaching intermediate analysis results. Again. it's not a one size fits all situation. I'm not making any specific suggestion for a change here, more like suggesting that certain possible changes are best not made. Ned From johnl@taugh.com Tue May 28 18: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 2941921F8DB7 for ; Tue, 28 May 2013 18:17:28 -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 H3bCEukoC5-N for ; Tue, 28 May 2013 18:17:27 -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 2F6EB21F8D79 for ; Tue, 28 May 2013 18:17:26 -0700 (PDT) Received: (qmail 7328 invoked from network); 29 May 2013 01:17:31 -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=1c9f.51a5572b.k1305; bh=exqddQRqse4SfE+xHqwCjZLgStarumUovgTdUBYpPbM=; b=hy2UG5LpMUWw3JDGP5xiaHjjxnEdSg5fHoeOWjtgWgpn5TD1dgG2Y49jd7NU2iieJIQGzgft6z1wRygV5dTLlZMXezFQuCVxpfDRAlyS5aDkalRt5RvUWQZOthpqvIuNd0J1skmXm1a1cl/Wm/F8tsX23oWlO7aLmMHscNmjyAc= 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=1c9f.51a5572b.k1305; bh=exqddQRqse4SfE+xHqwCjZLgStarumUovgTdUBYpPbM=; b=BSBcUYY+EA82jHiZYqX19vSk1xuk39vLCLLkgmmuORTzZS1PRj9KQpw/BfV0OP19zAE0V+rK2OQxXNdy+LMVMBN9LMqOMcyHYtLAL59sDuzJIannwryIqfYL+jvgv/s7s9IG8/WbYilwYwrKGeJ8o1nULXOrQMZXgr2pRhnCcKs= Received: (ofmipd 127.0.0.1); 29 May 2013 01:17:09 -0000 Date: 28 May 2013 21:17:24 -0400 Message-ID: From: "John R Levine" To: "Ned Freed" In-Reply-To: <01OU6TEMJ65Q000054@mauve.mrochek.com> References: <01OTO93GD6L2000054@mauve.mrochek.com> <20130515202613.24981.qmail@joyce.lan> <01OTOENRSJ6Q000054@mauve.mrochek.com> <01OTSF48H616000054@mauve.mrochek.com> <01OU6TEMJ65Q000054@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: IETF Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-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, 29 May 2013 01:17:28 -0000 > There really isn't a one size fits all answer here, and it's silly to think > one can be found. Perhaps it's better to describe results than methods, e.g., if the process leads to a bounce, what you bounce better be close enough to what you received that the other party can recogize it as something they sent. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From ned.freed@mrochek.com Tue May 28 18:47: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 D0B6721F86D8 for ; Tue, 28 May 2013 18:47:34 -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 z615mHGhs3Vo for ; Tue, 28 May 2013 18:47:29 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id BB6CA21F8F20 for ; Tue, 28 May 2013 18:47:29 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OU6UVMSANK007G7G@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 28 May 2013 18:42:26 -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 <01OU5J2573CW000054@mauve.mrochek.com>; Tue, 28 May 2013 18:42:24 -0700 (PDT) Message-id: <01OU6UVKSEHE000054@mauve.mrochek.com> Date: Tue, 28 May 2013 18:42:13 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 28 May 2013 21:17:24 -0400" References: <01OTO93GD6L2000054@mauve.mrochek.com> <20130515202613.24981.qmail@joyce.lan> <01OTOENRSJ6Q000054@mauve.mrochek.com> <01OTSF48H616000054@mauve.mrochek.com> <01OU6TEMJ65Q000054@mauve.mrochek.com> To: John R Levine Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-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, 29 May 2013 01:47:34 -0000 > > There really isn't a one size fits all answer here, and it's silly to think > > one can be found. > Perhaps it's better to describe results than methods, e.g., if the process > leads to a bounce, what you bounce better be close enough to what you > received that the other party can recogize it as something they sent. Seems reasonable. Ned From stpeter@stpeter.im Tue May 28 20:48: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 0D52A21F8EFC; Tue, 28 May 2013 20:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 zp7hTZcPLBN3; Tue, 28 May 2013 20:48:52 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 840F021F8EF7; Tue, 28 May 2013 20:48:52 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4A87D4115C; Tue, 28 May 2013 22:01:38 -0600 (MDT) Message-ID: <51A57AA3.6000403@stpeter.im> Date: Tue, 28 May 2013 21:48:51 -0600 From: Peter Saint-Andre 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: draft-ietf-cuss-sip-uui.all@tools.ietf.org X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: The IESG , "apps-discuss@ietf.org" Subject: [apps-discuss] AppsDir review of draft-ietf-cuss-sip-uui-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, 29 May 2013 03:48:57 -0000 Greetings! I have been selected as the Applications Area Directorate [1] reviewer for draft-ietf-cuss-sip-uui. Please resolve these comments along with any other Last Call comments you might receive. Please wait for direction from your document shepherd or AD before posting a new version of the Internet-Draft. Document: draft-ietf-cuss-sip-uui-10 Title: A Mechanism for Transporting User to User Call Control Information in SIP Reviewer: Peter Saint-Andre Review Date: 2013-05-28 IETF Last Call ends: 2013-05-29 Summary: The document is ready for advancement to Proposed Standard but could do with a bit more polishing. Major Issues: None. Minor Issues: Section 3 states: For redirection and referral use cases and REQ-3, the header field shall be included (escaped) into the Contact or Refer-To URI. No guidelines are provided for deciding between use of the Contact header field or the Refer-To header field. Might that introduce the possibility of interoperability problems? Also, a normative reference to RFC 3515 seems needed here. In Section 4.1, has the ABNF been checked? Section 4.2 states: Each octet of binary data to be represented in the hex encoding MUST be mapped to two hexadecimal digits (represented by ASCII characters 0-9, A-F and a-f), each representing four bits within the octet. Is the output case-insensitive? Also, in Section 4.2: Hex encoding is normally done as a token, although quoted-string is permitted, in which case the quotes MUST be ignored. The phrase "done as" is a bit loose; I assume you mean something like "The hex-encoded value is normally represented using the 'token' construction from RFC 3261, although the 'quoted-string' construction is permitted..." In Section 5, what is the rationale for using a policy of "RFC Required" rather than, say, "Specification Required"? Were the various RFC 5226 options considered by the CUSS WG? Please note that Section 5 states: UUI packages defined using this SIP UUI mechanism MUST follow the "RFC Required" guideline as defined in [RFC5226] and publish a standards track RFC which describes the usage. However, Section 6.3 states: This specification establishes the uui-packages sub-registry under http://www.iana.org/assignments/sip-parameters. New uui-packages MUST follow the "Specification Required" guideline as defined in [RFC5226]. Are those two statements in conflict? In Section 5, condition #5 states: 5. The UUI data is not being utilized for user-to-user Remote Procedure Call (RPC) calls. Is it possible to use the UUI header field for RPC calls, or in general as a kind of back channel? If so, it would be good to discuss that in the Security Considerations Nits: It would be helpful to reference 4244bis on first mention of History-Info. Also, isn't it properly "the History-Info header field"? What is "hi-targeted-to-uri"? If that is a specification, a citation would be helpful. The following text would be better placed in the Terminology section (or, at the least, before the first example that uses this convention, not after the second example): Note that the tag convention from SIP Torture Test Messages [RFC4475] is used to show that there are no line breaks in the actual message syntax. Peter [1] http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate From superuser@gmail.com Wed May 29 00:05:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDD221F856D for ; Wed, 29 May 2013 00:05:56 -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 Crcydv4mzyTw for ; Wed, 29 May 2013 00:05:55 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 67D7B21F855F for ; Wed, 29 May 2013 00:05:55 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so6407417wgg.16 for ; Wed, 29 May 2013 00:05:54 -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=U6V/D1DSS3yXrMmMi+fH4NLI9PuN4uwa7VJT/Ei1JOs=; b=SS9IpI4IiIbfeYfBCYpmM3C/iqyIX7eY3rf8FxEog1yt9PwaZhMUXdifhy+h7lLHWn vqba57EpxSY9aAaf1fg/As4+ceqB1IoyZ6P2hOjaeZaQDnL7p+UJfKLFyAB8JfH4hl6b 5wdIq0/GB+16Zoo2VS+CK8HMwcgfa0H4J8G7Qk2UV39SUSrFCMhkVyce//c23m12Gk07 rqJv53jNNrWA3AoaGUs50A/hHunmtJggsEX5zoC5qKB3vBfHi7T6TBhRQ0w9l5Fq5UbZ tBIqzYqtowYELU5A5THoMMDF+L/LzEJhC/ONY/1lZOZrt3gf4HkYE4v6ysnQRS7lshR0 sfOw== MIME-Version: 1.0 X-Received: by 10.180.20.208 with SMTP id p16mr1006750wie.59.1369811154578; Wed, 29 May 2013 00:05:54 -0700 (PDT) Received: by 10.180.74.203 with HTTP; Wed, 29 May 2013 00:05:54 -0700 (PDT) In-Reply-To: <01OU6TEMJ65Q000054@mauve.mrochek.com> References: <01OTO93GD6L2000054@mauve.mrochek.com> <20130515202613.24981.qmail@joyce.lan> <01OTOENRSJ6Q000054@mauve.mrochek.com> <01OTSF48H616000054@mauve.mrochek.com> <01OU6TEMJ65Q000054@mauve.mrochek.com> Date: Wed, 29 May 2013 00:05:54 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=bcaec53f38c94731a604ddd60346 Cc: John R Levine , IETF Apps Discuss Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-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, 29 May 2013 07:05:56 -0000 --bcaec53f38c94731a604ddd60346 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 28, 2013 at 5:50 PM, Ned Freed wrote: > > Consider a system that has several independent filtering modules. It's > > important that the modules don't change the content as it passes from one > > to the next as doing so might obscure something that the next module > might > > consider reject-worthy. Therefore, whatever transformations need to be > > done have to be kept internal to the module and not released as the > "real" > > content. > > It's nowhere near this simple. Sometimes you want filtering modules exposed > to unadulterated content. One way to arrange for that is preclude any > changes, but another is to run the modules in parallel. After all, if > they're > not talking to each other, why wouldn't you want them to run > simultaneously? > > But other times you want them to be able to pass information to each other. > Unfortunately that often can only be done by adding headers. And there are > even times when you want much more radical transformations applies, such > as the removal of encryption, forced conversion to MIME format, etc. etc. > > There really isn't a one size fits all answer here, and it's silly to think > one can be found. > The -05 version of this document makes it clear that we're talking about a system where the handling modules operate in a sequence, since that's the model I had in mind when I rewrote that text. I'll add some additional prose about the points you've made here. -MSK --bcaec53f38c94731a604ddd60346 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 28, 2013 at 5:50 PM, Ned Freed <ned.freed= @mrochek.com> wrote:
> Consider a system tha= t has several independent filtering modules. =A0It's
> important that the modules don't change the content as it passes f= rom one
> to the next as doing so might obscure something that the next module m= ight
> consider reject-worthy. =A0Therefore, whatever transformations need to= be
> done have to be kept internal to the module and not released as the &q= uot;real"
> content.

It's nowhere near this simple. Sometimes you want filtering modul= es exposed
to unadulterated content. One way to arrange for that is preclude any
changes, but another is to run the modules in parallel. After all, if they&= #39;re
not talking to each other, why wouldn't you want them to run simultaneo= usly?

But other times you want them to be able to pass information to each other.=
Unfortunately that often can only be done by adding headers. And there are<= br> even times when you want much more radical transformations applies, such as the removal of encryption, forced conversion to MIME format, etc. etc.
There really isn't a one size fits all answer here, and it's silly = to think
one can be found.

The -05 version of th= is document makes it clear that we're talking about a system where the = handling modules operate in a sequence, since that's the model I had in= mind when I rewrote that text.=A0 I'll add some additional prose about= the points you've made here.

-MSK
--bcaec53f38c94731a604ddd60346-- From ioseb.dzmanashvili@gmail.com Wed May 29 00:35: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 DE48421F8EC2 for ; Wed, 29 May 2013 00:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=-0.550, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=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 i6Iu4sa5HbzU for ; Wed, 29 May 2013 00:35:32 -0700 (PDT) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5991421F8EBB for ; Wed, 29 May 2013 00:35:32 -0700 (PDT) Received: by mail-ea0-f171.google.com with SMTP id b15so5112729eae.30 for ; Wed, 29 May 2013 00:35:31 -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:x-mailer :mime-version:content-type; bh=XQ+2EdVjcHFyxFBTowFq/BIrmSf97JiGBKrBjRzlYrM=; b=mw+uHfAT/QgssdfQI+LJnJFgT2bP0+JL6zhsYUyIzHg2z50WaR1iubUek+wCZzl4/9 XN5K9knwbJB0O2KGWMOKABYogU3i9Bkn3ET6JS/0c3Aol1WgzVu+pKMgoyUMjgg0plYf PlR4d5EbuSvdEY1UbgpkPDgqr8mZKKJu4TF0r9Ksjb1lZdgEP94hkyDnhoLbaCExqBgc mKnK98JdHaCrjjlbba3+DzZNkFG8rzBbQ+xsKO+/6w2miggnrhoPecQViVgu24C+3UgE Bz+hxMryaPGcB3iuA/ClM5tRqr2xoX7IakswCNJrrddg/pvdFP7AVNODOKGq1BTwFF6E UXgQ== X-Received: by 10.15.76.9 with SMTP id m9mr1173967eey.146.1369812931297; Wed, 29 May 2013 00:35:31 -0700 (PDT) Received: from [10.131.33.114] ([213.131.60.234]) by mx.google.com with ESMTPSA id y2sm52143574eeu.2.2013.05.29.00.35.28 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 29 May 2013 00:35:30 -0700 (PDT) Date: Wed, 29 May 2013 11:35:27 +0400 From: Ioseb Dzmanashvili To: Markus Lanthaler Message-ID: In-Reply-To: <51a54dfa.086f0e0a.693f.2ff4SMTPIN_ADDED_BROKEN@mx.google.com> References: <4038B5FE76874C54A819A07FE192AEF8@gmail.com> <51a53d34.48b40e0a.70fc.1549SMTPIN_ADDED_BROKEN@mx.google.com> <51a54dfa.086f0e0a.693f.2ff4SMTPIN_ADDED_BROKEN@mx.google.com> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="51a5afbf_3494b2fb_1b1" Cc: link-relations@ieft.org, IETF Apps Discuss Subject: Re: [apps-discuss] NEW RELATION: property and context X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 07:35:34 -0000 --51a5afbf_3494b2fb_1b1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline James, Markus, Thanks for taking discussion further=21 I'm at work right = now and will write detailed responses later. =40Markus > I would really like to understand the differences but so far I haven't = seen any. Ioseb, maybe a couple of more concrete examples about how you s= ee the two rels being used would help a lot. And maybe also mention why c= ollection/item or describes/describedBy wouldn't work for those examples.= Here is the example: *** REQUEST: =46etch photo *** > GET /article/photo HTTP/1.1 > Host: service.org *** RESPONSE: Photo representation *** < HTTP/1.1 200 OK < Content-Type: image/jpeg < Content-Length: ... < Link: ; rel=3D=22property=22; title=3D=22Property= 1=22, < ; rel=3D=22property=22; title=3D=22Property 2=22= , < ; rel=3D=22self=22; title=3D=22...=22, < ; rel=3D=22context=22 title=3D=22Thousand Leagues Under the= Sea=22 < =20 < =5BBINARY DATA HERE=5D *** REQUEST: =46etch one of the properties *** > GET /article/photo;prop1 > Host: service.org *** RESPONSE: property representation *** < HTTP/1.1 200 OK < Content-Type: text/plain < Link: ; rel=3D=22self=22 title=3D=22...=22, < ; rel=3D=22context=22; title=3D=22...=22 < =20 < =5BPROPERTY VALUE HERE=5D Based on this example, i'm not sure how the =22describes=22 link relation= can be used instead of the =22context=22 link relation when by definitio= n the =22describes=22 relations says that: =22The relationship A 'describ= es' B asserts that resource A provides a description of resource B. There= are no constraints on the format or representation of either A or B, nei= ther are there any further constraints on either resource.=22=3F In this = particular example =22context=22 indicates resource to which the /article= /photo or /article/photo;prop1 resources belong and context resources do= not provide any description of those members. What i want to say here i= t's a simple relationship between two resources without any descriptions = etc=E2=80=A6 Same with the =22collection=22 and =22item=22 relationships, i do not see= (or maybe do not understand=3F) how /article and /article/photo resources= are collections=3F if yes, collections of what=3F generally we can say t= hat everything is an item but taking the definition of the =22item=22 lin= k relation: =22The target IRI points to a resource that is a member of th= e collection represented by the context IRI.=22 Now if we consider follow= ing example: < HTTP/1.1 200 OK < Content-Type: =E2=80=A6 < Content-Length: =E2=80=A6 < Link: ; rel=3D=22self=22; title=3D=22=E2=80=A6=22, < ; rel=3D=22enclosure=22 title=3D=22=E2=80=A6=22 < < =5BREST O=46 CONTENT HERE=5D can we say for /article/photo resource that context IRI represents a coll= ection=3F or does the /article resource somehow =22describes=22 the /arti= cle/photo resource=3F or is /article/photo resource is an item which belo= ngs to collection=3F =20 Hope these examples will help=21 will write more later today. Thanks agai= n=21 cheers, isoeb On Wednesday, May 29, 2013 at 4:38 AM, Markus Lanthaler wrote: > On Wednesday, May 29, 2013 2:21 AM, James M Snell wrote: > > > James, did you read all the discussion=3F Ioseb made it quite clear= > > =20 > > that his > > > =22context=22 is intended to be used completely different than JSON= -LD's > > > context. I'm still not sure I understand its semantics. > > > =20 > > =20 > > =20 > > Yep, I saw that and purposefully chose to ignore it :-) ... given the= > > general definition of =22context=22 given in the draft, use for json-= ld > > type scenarios is not ruled out. > > =20 > =20 > =20 > Well.. the problem I have with the current I-D is that even after all t= hese discussions I still don't understand what =22context=22 is supposed = to mean. Quoting the I-D: > =20 > =20 > When included in a response, the =22context=22 link relation identifies= a > target resource that represents a context document of which the > context resource is a member. > =20 > =46or example, if a resource represents the property of a photo, that > same resource may include link to a resource which the property > belongs. > =20 > Taking the second paragraph, wouldn't the =22describes=22 relation achi= eve just that=3F Quoting the abstract of R=46C6892 which defines =22descr= ibes=22: > =20 > This specification defines the 'describes' link relation type that > allows resource representations to indicate that they are describing > another resource. In contexts where applications want to associate > described resources and description resources, and want to build > services based on these associations, the 'describes' link relation > type provides the opposite direction of the 'describedby' link > relation type, which already is a registered link relation type. > =20 > =20 > I would really like to understand the differences but so far I haven't = seen any. Ioseb, maybe a couple of more concrete examples about how you s= ee the two rels being used would help a lot. And maybe also mention why c= ollection/item or describes/describedBy wouldn't work for those examples.= > =20 > =20 > Cheers, > Markus > =20 > =20 > -- > Markus Lanthaler > =40markuslanthaler > =20 > =20 --51a5afbf_3494b2fb_1b1 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
James, Markus, Thanks for taking discussion fur= ther=21 I'm at work right now and will write detailed responses later.

=40Markus

> I would re= ally like to understand the differences but so far I haven't seen any. Io= seb, maybe a couple of more concrete examples about how you see the two r= els being used would help a lot. And maybe also mention why collection/it= em or describes/describedBy wouldn't work for those examples.
<= br>
Here is the example:

*** REQU= EST: =46etch photo ***
> GET /article/photo HTTP/1.1
> Host: service.org

*** RESPONSE: Photo re= presentation ***
< HTTP/1.1 200 OK
< Content-Ty= pe: image/jpeg
< Content-Length: ...
< Link: </article/photo;prop1>; rel=3D=22property=22; title=3D=22Property = 1=22,
<   </article/photo;prop2>; rel=3D=22= property=22; title=3D=22Property 2=22,
<   </art= icle/photo>; rel=3D=22self=22; title=3D=22...=22,
<  = ; </article>; rel=3D=22context=22 title=3D=22Thousand Leagues Un= der the Sea=22
<   
< =5BBINARY D= ATA HERE=5D

*** REQUEST: =46etch one of the prop= erties ***
> GET /article/photo;prop1
> Host: s= ervice.org

*** RESPONSE: property representation= ***
< HTTP/1.1 200 OK
< Content-Type: text/pla= in
< Link: </article/photo;prop1>; rel=3D=22self=22= title=3D=22...=22,
<   </article/photo>; = rel=3D=22context=22; title=3D=22...=22
< 
< =5BPROPERTY VALUE HERE=5D

Based on t= his example, i'm not sure how the =22describes=22 link relation can be us= ed instead of the =22context=22 link relation when by definition the =22d= escribes=22 relations says that: =22The relationship A 'describes' B asse= rts that resource A provides a description of resource B. There are no co= nstraints on the format or representation of either A or B, neither are t= here any further constraints on either resource.=22=3F In this particular= example =22context=22 indicates resource to which the /article/photo or = /article/photo;prop1 resources belong and  context resources do not = provide any description of those members.  What i want to say h= ere it's a simple relationship between two resources without any descript= ions etc=E2=80=A6

Same with the =22collection=22= and =22item=22 relationships, i do not see(or maybe do not understand=3F= ) how /article and /article/photo resources are collections=3F if ye= s, collections of what=3F generally we can say that everything is an item= but taking the definition of the =22item=22 link relation: =22The target IRI points to a resource t= hat is a member of the collection represented by the context IRI.=22 Now = if we consider following example:

< HTTP/1.1 200 OK
< Content-Type: =E2=80=A6
< Content-L= ength: =E2=80=A6
< Link: </article>; rel=3D=22self=22; title= =3D=22=E2=80=A6=22,
<    &= lt;/article/photo>; rel=3D=22enclosure=22 title=3D=22=E2=80=A6=22<= /font>
<
< =5BREST O=46 CONTENT HERE=5D
<= div>
can we say for /article/photo resource that = context IRI represents a collection=3F or does the /article resource some= how =22describes=22 the /article/photo resource=3F or is /article/photo r= esource is an item which belongs to collection=3F 
=
Hope these examples will help=21= will write more later today. Thanks again=21

cheers,
isoe= b

=20

On Wednesday, May 29, = 2013 at 4:38 AM, Markus Lanthaler wrote:

On Wednesday, May 29, 2013 2:21 = AM, James M Snell wrote:
James, did you read all the discussion=3F Iose= b made it quite clear
that his
=22context=22 is intended to be used completely= different than JSON-LD's
context. I'm still not sure I underst= and its semantics.

Yep, I saw= that and purposefully chose to ignore it :-) ... given the
gen= eral definition of =22context=22 given in the draft, use for json-ld
type scenarios is not ruled out.

<= /div>
Well.. the problem I have with the current I-D is that even aft= er all these discussions I still don't understand what =22context=22 is s= upposed to mean. Quoting the I-D:


When included in a response, the =22context=22 link relation identifi= es a
target resource that represents a context document of w= hich the
context resource is a member.

<= div> =46or example, if a resource represents the property of a photo, t= hat
same resource may include link to a resource which the p= roperty
belongs.

Taking the second = paragraph, wouldn't the =22describes=22 relation achieve just that=3F Quo= ting the abstract of R=46C6892 which defines =22describes=22:
<= br>
This specification defines the 'describes' link relation= type that
allows resource representations to indicate that = they are describing
another resource. In contexts where app= lications want to associate
described resources and descript= ion resources, and want to build
services based on these ass= ociations, the 'describes' link relation
type provides the o= pposite direction of the 'describedby' link
relation type, w= hich already is a registered link relation type.


I would really like to understand the differences but so = far I haven't seen any. Ioseb, maybe a couple of more concrete examples a= bout how you see the two rels being used would help a lot. And maybe also= mention why collection/item or describes/describedBy wouldn't work for t= hose examples.


Cheers,
= Markus


--
Markus Lantha= ler
=40markuslanthaler
=20 =20 =20 =20 =20

--51a5afbf_3494b2fb_1b1-- From jan.algermissen@nordsc.com Wed May 29 02:06:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A7621F8B64 for ; Wed, 29 May 2013 02:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_32=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 Nex8vSZ07Feg for ; Wed, 29 May 2013 02:06:30 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1E72821F8B04 for ; Wed, 29 May 2013 02:06:27 -0700 (PDT) Received: from [10.90.135.158] ([87.253.171.211]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0LbNwk-1U2HJP3a94-00kqwl; Wed, 29 May 2013 11:06:21 +0200 From: Jan Algermissen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 29 May 2013 11:06:23 +0200 Message-Id: To: Mark Nottingham Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-Provags-ID: V02:K0:pzyXPRvXnEknpeERua2s2+liPKbjiDaJitZXRrjcr9K iRs/GtQifzM4g+JcF/nuB3oKgzW70CO8mf8BgD+5VCC2vBUWaQ Ki8JaQVum1XKxds240iWkh3Ad7ZbRyEietBM9FKlTMesBrFKuJ P30LTzkqfapq7VLEb5JvuRLfAERJUHNFec98rtb5l+5MeoOYPm xmzsjPsP7YRmEZU28ZHujSIkLTvunXmjPOlbXx0xtmSfcyaiiz aOPDumR+3CWcYoLdbrW4cBFgSz9R1JddJqNDvWa+IecVY6lJ4H IttGzP9b+mnkgkppKLU/WlbMd2H/bCs/zuJ0IrM72kkFT8dJYL 0i73enyEEY7X88j5mzQyZBW85cBR1NoBpWeoq+AuHaZJkl+MnB lGbJvpZPpOzuw== Cc: "apps-discuss@ietf.org Discuss" Subject: [apps-discuss] Comments on draft-nottingham-http-problem-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, 29 May 2013 09:06:35 -0000 Hi Mark, here are some comments on = http://tools.ietf.org/html/draft-nottingham-http-problem-03 Excuse the 'purist mindset driven tone' - you know me, no offence = intended :-) Jan 1. Introduction Is it possible to add explanation how an HTTP-API client might benefit from understanding the specific reason 'out of credit'? To me, it is not obvious that a client would do anything with this information besides passing the written information on to the human or to a log consumed by a human. In both cases 403+HTML would be sufficient. I do not want to discuss the usefulness of the draft, but it would be nice to have an example that isn't by any chance controversial. Specifically, someone with my mindset could take this paragraph as pure hand-waving: "However, that doesn't give the API client enough information about why the request was forbidden, the applicable account balance, or how to correct the problem. If these details are included in the response body in a machine-readable format, the client can treat it appropriately." Unless there is a bit more explanation what it could mean for a client to treat "out of credit" appropriately or how to "correct the problem" given understanding of the problem semantics. IMHO, probem types are so very close to tunneling application semantics that it is a good idea to be as clear as possible why HTTP status codes are not enough. Otherwise I fear that readers just take it as a best practice to solve with a zillion of problem types what could be solved = by good resource design. [I know we have been here already, but since this = is sort of last call, I say it again :-)] 3.2 Optional Members "httpStatus" (number) - Can you substitute "number" by the production = for HTTP status codes? E.g. IIS wrongly produces a hord of xxx.yy status codes for finde grained, tunneled, error semantics. People might be = tempted to copy these as values for httpStatus. "detail" (string) - I fail to understand how "detail", being a string, = can help a client do anything (expect display the string). Can you explain? 4.1. Example The sentences "If one is available, you can reuse that URI by documenting use of both this specification and that specific URI value in your API." and "This information could appear within the rest of your API's documentation" contradict the idea that true HTTP APIs do not need documentation and that such documentation creates expectations that get hard coded and introduce coupling. It is a slippery slope to mention in a spec that will likely receive widespread attention given its editor :-) Jan From cabo@tzi.org Wed May 29 07:53: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 5E49621F8F4D for ; Wed, 29 May 2013 07:53:15 -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 zualon2P41hy for ; Wed, 29 May 2013 07:53:09 -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 F0AE721F8F28 for ; Wed, 29 May 2013 07:53:08 -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 r4TEr5gS007609 for ; Wed, 29 May 2013 16:53:05 +0200 (CEST) Received: from [192.168.217.105] (p54890019.dip0.t-ipconnect.de [84.137.0.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 37089304B; Wed, 29 May 2013 16:53:05 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 29 May 2013 16:53:04 +0200 To: "apps-discuss@ietf.org Discuss" Message-Id: <8D8A0953-FE0D-428D-9E57-27376FA5986D@tzi.org> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [apps-discuss] Concise Binary Object Representation (CBOR) -- new version -01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 14:53:15 -0000 Based on the substantive feedback we received here, we have submitted = draft-bormann-cbor-01. The major new addition is support for streaming of arrays and maps and = chunking of strings. You may also like the background information about other binary formats = in Appendix E. List of changes below. Gr=FC=DFe, Carsten * Major changes Changed the values for "additional information" to allow for indefinite length arrays and maps, and to also allow for future expansion. While we were changing the encoding for that: swapped major types 6 and 7 to bring the content-bearing major types together numerically. Added the "break" stop code to (now) major type 7 to allow for indefinite length arrays and maps. Added a tag for chunking of (building from multiple chunks) arrays of byte strings and arrays of UTF-8 strings. * Minor additions Added a section discussing indefinite length arrays and maps and their use in streaming applications. Added a section on optional canonicalizing CBOR data. Added a section on extensibility of CBOR and its future evolution. In the diagnostic notation, added indicators for indefinite length arrays and maps. Added an appendix of comparisions of other binary formats with CBOR's design goals. * Editorial changes Clarified CBOR's endiannness. Added acknowledgements for recent contributors. Fixed all the tables and examples to deal with the above wire changes. From markus.lanthaler@gmx.net Wed May 29 11:39:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A835321F848E for ; Wed, 29 May 2013 11:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.127 X-Spam-Level: X-Spam-Status: No, score=0.127 tagged_above=-999 required=5 tests=[AWL=-0.812, BAYES_05=-1.11, J_CHICKENPOX_32=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 C3xrVu8bQbmh for ; Wed, 29 May 2013 11:39:30 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCCE21F8EAD for ; Wed, 29 May 2013 11:39:28 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.4]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MYqSb-1UufIi0N4V-00Vksf for ; Wed, 29 May 2013 20:39:27 +0200 Received: (qmail invoked by alias); 29 May 2013 18:39:26 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp004) with SMTP; 29 May 2013 20:39:26 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1/WjY93VXnWTVt0sEI2kPo3di41pImnBk8ZFrLZMP Q5Q20pWbe69/Pn From: "Markus Lanthaler" To: "'Ioseb Dzmanashvili'" References: <4038B5FE76874C54A819A07FE192AEF8@gmail.com> <51a53d34.48b40e0a.70fc.1549SMTPIN_ADDED_BROKEN@mx.google.com> <51a54dfa.086f0e0a.693f.2ff4SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Wed, 29 May 2013 20:39:25 +0200 Message-ID: <026b01ce5c9b$d8ed7510$8ac85f30$@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: Ac5cPxjaFwqGigEdSmi3XGmBH80AtwAWtnEQ Content-Language: de X-Y-GMX-Trusted: 0 Cc: link-relations@ieft.org, 'IETF Apps Discuss' Subject: Re: [apps-discuss] NEW RELATION: property and context X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 18:39:35 -0000 On Wednesday, May 29, 2013 9:35 AM, Ioseb Dzmanashvili wrote: > Here is the example: >=20 > *** REQUEST: Fetch photo *** > > GET /article/photo HTTP/1.1 > > Host: service.org >=20 > *** RESPONSE: Photo representation *** > < HTTP/1.1 200 OK > < Content-Type: image/jpeg > < Content-Length: ... > < Link: ; rel=3D"property"; title=3D"Property = 1", > < ; rel=3D"property"; title=3D"Property 2", > < ; rel=3D"self"; title=3D"...", > < ; rel=3D"context" title=3D"Thousand Leagues Under the = Sea" > < =20 > < [BINARY DATA HERE] >=20 > *** REQUEST: Fetch one of the properties *** > > GET /article/photo;prop1 > > Host: service.org This is right at the heart of my first question: How does the client = know to fetch /article/photo;prop1 instead of /article/photo;prop2? There are only two options here: a) code against the target URL or b) = code against the title attribute. Since you said b) is used exclusively = for rendering purposes I assume you would code your client against the = URL (or parts thereof) which would go against the fundamental idea of = typed links. > *** RESPONSE: property representation *** > < HTTP/1.1 200 OK > < Content-Type: text/plain > < Link: ; rel=3D"self" title=3D"...", > < ; rel=3D"context"; title=3D"..." > <=20 > < [PROPERTY VALUE HERE] >=20 > Based on this example, i'm not sure how the "describes" link relation > can be used instead of the "context" link relation when by definition > the "describes" relations says that: "The relationship A 'describes' B > asserts that resource A provides a description of resource B. There > are no constraints on the format or representation of either A or B, > neither are there any further constraints on either resource."? In > this particular example "context" indicates resource to which the > /article/photo or /article/photo;prop1 resources belong and context > resources do not provide any description of those members. Hmm.. I do partly agree for the /article/photo -> /article link but = would argue that /article/photo;prop1 does *describe* /article/photo. = Similarly it could be argued that /article/photo *isDescribedBy* = /article. > What i > want to say here it's a simple relationship between two resources > without any descriptions etc=E2=80=A6 So you want to express a relationship without any specific semantics? In = that case, why do you need a typed link? Can't you just use a untyped = one? > Same with the "collection" and "item" relationships, i do not see(or > maybe do not understand?) how /article and /article/photo resources > are collections? If article would be called slideshow or gallery, would you see it then? = :-) You could say that an article is a collection of information, some = prose, some images, maybe some movies etc. > if yes, collections of what? generally we can say > that everything is an item but taking the definition of the "item" > link relation: "The target IRI points to a resource that is a member > of the collection represented by the context IRI." Now if we consider > following example: >=20 > < HTTP/1.1 200 OK > < Content-Type: =E2=80=A6 > < Content-Length: =E2=80=A6 > < Link: ; rel=3D"self"; title=3D"=E2=80=A6", > < ; rel=3D"enclosure" title=3D"=E2=80=A6" > < > < [REST OF CONTENT HERE] >=20 > can we say for /article/photo resource that context IRI represents a > collection? or does the /article resource somehow "describes" the > /article/photo resource? or is /article/photo resource is an item > which belongs to collection? Could be any of those. If the article describe the photo you could use = "describes". If the article is more a collection of information (e.g. = pictures as in a gallery) you could say it is a "collection" and the = photo is an "item". Btw. On mailing lists it is typically considered as a best practice to = write text-only mails. This makes it much easier to quote etc. Could you = please update your client settings to send text-only mails instead of = HTML formatted mails. Thanks a lot! -- Markus Lanthaler @markuslanthaler From ioseb.dzmanashvili@gmail.com Wed May 29 13:07: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 8DF9121F96D4; Wed, 29 May 2013 13:07:39 -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_32=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 u4rj4NbnyBgQ; Wed, 29 May 2013 13:07:38 -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 4BE4421F96B4; Wed, 29 May 2013 13:07:37 -0700 (PDT) Received: by mail-ea0-f180.google.com with SMTP id g10so5429995eak.25 for ; Wed, 29 May 2013 13:07:36 -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:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition; bh=18fcZCjiKtCAwc+K8TolKkpIi6mzLEkuqsCCOJV1/HE=; b=M7ypVjGjmCh+S/yyMX2+eKVlg7/TaCoTezq9iXKrQOKb+nZdOhhhVnH14vJiMH/VDo oJZm308/2EAfWWAuFa667ZT8is8ylRWmaOELyFpVWUoDD6HtQLGAi56GSaivhlBIOJc7 qJu1m3WtFBSHToTTsE1Ki4y37qfvIzWjXe0nOSIUave6952PgqCRma+5OShLEBEoESr9 /At7OfRKBg2kceQ5drJw00r4fuK2+cxP+J0SQ67rKDuMaPVrVne5OI79uDpLqJjRnOiR p1XkytnpDlTqWFmup6TsPcg+47ECEouOcltr9tXpqPs9pyO8OSL36beT9AHqOkS+yynC I/UQ== X-Received: by 10.14.213.73 with SMTP id z49mr6024968eeo.94.1369858055946; Wed, 29 May 2013 13:07:35 -0700 (PDT) Received: from [192.168.1.7] ([176.73.174.236]) by mx.google.com with ESMTPSA id t6sm19951927eev.14.2013.05.29.13.07.33 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 29 May 2013 13:07:34 -0700 (PDT) Date: Thu, 30 May 2013 00:07:34 +0400 From: Ioseb Dzmanashvili To: Markus Lanthaler Message-ID: <87194C5A218E42F9AA9B81339D2C1BC5@gmail.com> In-Reply-To: <51a64b5f.87000e0a.78ef.ffff87a2SMTPIN_ADDED_BROKEN@mx.google.com> References: <4038B5FE76874C54A819A07FE192AEF8@gmail.com> <51a53d34.48b40e0a.70fc.1549SMTPIN_ADDED_BROKEN@mx.google.com> <51a54dfa.086f0e0a.693f.2ff4SMTPIN_ADDED_BROKEN@mx.google.com> <51a64b5f.87000e0a.78ef.ffff87a2SMTPIN_ADDED_BROKEN@mx.google.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: IETF Apps Discuss , "=?utf-8?Q?link-relations=40ietf.org?=" Subject: Re: [apps-discuss] NEW RELATION: property and context X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 May 2013 20:07:39 -0000 On Wednesday, May 29, 2013 at 10:39 PM, Markus Lanthaler wrote: > On Wednesday, May 29, 2013 9:35 AM, Ioseb Dzmanashvili wrote: > > Here is the example: > > =20 > > *** REQUEST: =46etch photo *** > > > GET /article/photo HTTP/1.1 > > > Host: service.org (http://service.org) > > =20 > > =20 > > =20 > > *** RESPONSE: Photo representation *** > > < HTTP/1.1 200 OK > > < Content-Type: image/jpeg > > < Content-Length: ... > > < Link: ; rel=3D=22property=22; title=3D=22Prop= erty 1=22, > > < ; rel=3D=22property=22; title=3D=22Property 2= =22, > > < ; rel=3D=22self=22; title=3D=22...=22, > > < ; rel=3D=22context=22 title=3D=22Thousand Leagues Under t= he Sea=22 > > < =20 > > < =5BBINARY DATA HERE=5D > > =20 > > *** REQUEST: =46etch one of the properties *** > > > GET /article/photo;prop1 > > > Host: service.org (http://service.org) > > =20 > =20 > =20 > =20 > This is right at the heart of my first question: How does the client kn= ow to fetch /article/photo;prop1 instead of /article/photo;prop2=3F > =20 > There are only two options here: a) code against the target URL or b) c= ode against the title attribute. Since you said b) is used exclusively fo= r rendering purposes I assume you would code your client against the URL = (or parts thereof) which would go against the fundamental idea of typed l= inks. Both options are wrong. =20 > a) code against the target URL or 1) the =22property=22 link relation is enough to indicate that target res= ource is a property and allow agents to distinguish these links form othe= rs; =20 2) additional semantics can be provided with extension link relations and= there is nothing wrong with it, it doesn't violate anything nor can be c= onsidered as anti pattern. 3) your argument implicitly claims that there exists only M2M interaction= which is also wrong. there are also GUI apps for which it's enough to ju= st know that some of links are properties(identified by the =22property=22= relation) 4) having a general purpose link relation makes it useful and reusable fr= om application to application, it eliminates need to redefine each time w= hat =22property=22 is and is media format agnostic. shared understanding = is important i believe and additional semantics for each specific propert= y is solvable on another level. > b) is used exclusively for rendering purposes I assume you would code y= our client against the URL (or parts thereof) which would go against the = fundamental idea of typed links. very strange assumption. =20 =20 > > *** RESPONSE: property representation *** > > < HTTP/1.1 200 OK > > < Content-Type: text/plain > > < Link: ; rel=3D=22self=22 title=3D=22...=22, > > < ; rel=3D=22context=22; title=3D=22...=22 > > < =20 > > < =5BPROPERTY VALUE HERE=5D > > =20 > > Based on this example, i'm not sure how the =22describes=22 link rela= tion > > can be used instead of the =22context=22 link relation when by defini= tion > > the =22describes=22 relations says that: =22The relationship A 'descr= ibes' B > > asserts that resource A provides a description of resource B. There > > are no constraints on the format or representation of either A or B, > > neither are there any further constraints on either resource.=22=3F I= n > > this particular example =22context=22 indicates resource to which the= > > /article/photo or /article/photo;prop1 resources belong and context > > resources do not provide any description of those members. > =20 > =20 > =20 > Hmm.. I do partly agree for the /article/photo -> /article link but wou= ld argue that /article/photo;prop1 does *describe* /article/photo. Simila= rly it could be argued that /article/photo *isDescribedBy* /article. Are you sure that =22describedby=22 and =22describes=22 relations give en= ough semantics to agents=3F is not it necessary to provide some kind of = description=3F if one describes another how it is described=3F and what = it gives to agent particularly in M2M interaction case=3F do automated ag= ents strangely become smart and happy when they just identify typed links= annotated with those relations=3F > > What i > > want to say here it's a simple relationship between two resources > > without any descriptions etc=E2=80=A6 > =20 > =20 > =20 > So you want to express a relationship without any specific semantics=3F= In that case, why do you need a typed link=3F Can't you just use a untyp= ed one=3F Than how GUI or automated agent will distinguish resources which are prop= erties accessible individually from for example the =22edit=22 or =22edit= -form=22 links=3F or implementations are going to follow some convention = like: if a link doesn't have relation just display it=3F or ignore 'em=3F= or=3F > > Same with the =22collection=22 and =22item=22 relationships, i do not= see(or > > maybe do not understand=3F) how /article and /article/photo resources= > > are collections=3F > =20 > =20 > =20 > If article would be called slideshow or gallery, would you see it then=3F= :-) You could say that an article is a collection of information, some p= rose, some images, maybe some movies etc. but i didn't say =22gallery=22 or =22slideshow=22 in my example. what if = a resource is an ID card which has only one and only one photo of a perso= n=3F do you think that ID card or driving license are collections=3F and = yes i can not say that an article is a collection, not because we can not= say it generally but because what you say is overgeneralisation of thing= s. we can discuss everything as a collection and item but what you say ma= kes me think that =22collection=22, =22item=22, =22describes=22 and =22de= scribedby=22 link relations suddenly solved whole world problems. > > if yes, collections of what=3F generally we can say > > that everything is an item but taking the definition of the =22item=22= > > link relation: =22The target IRI points to a resource that is a membe= r > > of the collection represented by the context IRI.=22 Now if we consid= er > > following example: > > =20 > > < HTTP/1.1 200 OK > > < Content-Type: =E2=80=A6 > > < Content-Length: =E2=80=A6 > > < Link: ; rel=3D=22self=22; title=3D=22=E2=80=A6=22, > > < ; rel=3D=22enclosure=22 title=3D=22=E2=80=A6=22 > > < > > < =5BREST O=46 CONTENT HERE=5D > > =20 > > can we say for /article/photo resource that context IRI represents a > > collection=3F or does the /article resource somehow =22describes=22 t= he > > /article/photo resource=3F or is /article/photo resource is an item > > which belongs to collection=3F > =20 > =20 > =20 > Could be any of those. If the article describe the photo you could use = =22describes=22. If the article is more a collection of information (e.g.= pictures as in a gallery) you could say it is a =22collection=22 and the= photo is an =22item=22. could you please point me to the example how article describes photo=3F i= t would be really helpful for me=21. I believe i know and clearly unders= tand when i can say that an article is a collection, but does it make who= le world a collection=3F again, is not it overgeneralisation and oversimp= lification of things=3F =20 > =20 > =20 > Btw. On mailing lists it is typically considered as a best practice to = write text-only mails. This makes it much easier to quote etc. Could you = please update your client settings to send text-only mails instead of HTM= L formatted mails. Thanks a lot=21 done, thanks for letting me know. =20 > =20 > -- > Markus Lanthaler > =40markuslanthaler cheers, =20 ioseb From mnot@mnot.net Wed May 29 17:23: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 4E44F21F94B1 for ; Wed, 29 May 2013 17:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.299 X-Spam-Level: X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=-3.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFvr1D6LGTj8 for ; Wed, 29 May 2013 17:23:49 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id C647821F9436 for ; Wed, 29 May 2013 17:23:48 -0700 (PDT) Received: from [192.168.1.80] (unknown [118.209.184.230]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BA4CD22E1FA; Wed, 29 May 2013 20:23:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Mark Nottingham In-Reply-To: Date: Thu, 30 May 2013 10:23:36 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <46212255-814A-4624-9B78-80700CAF60E7@mnot.net> References: To: Jan Algermissen X-Mailer: Apple Mail (2.1503) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Comments on draft-nottingham-http-problem-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: Thu, 30 May 2013 00:23:53 -0000 Hi Jan, On 29/05/2013, at 7:06 PM, Jan Algermissen = wrote: > Hi Mark, >=20 > here are some comments on = http://tools.ietf.org/html/draft-nottingham-http-problem-03 >=20 > Excuse the 'purist mindset driven tone' - you know me, no offence = intended :-) Of course :) >=20 > Jan >=20 >=20 >=20 > 1. Introduction >=20 > Is it possible to add explanation how an HTTP-API client might benefit > from understanding the specific reason 'out of credit'? To me, it is > not obvious that a client would do anything with this information > besides passing the written information on to the human or to a log > consumed by a human. In both cases 403+HTML would be sufficient. >=20 > I do not want to discuss the usefulness of the draft, but it would > be nice to have an example that isn't by any chance controversial. >=20 > Specifically, someone with my mindset could take this paragraph > as pure hand-waving: >=20 > "However, that doesn't give the API client enough information about > why the request was forbidden, the applicable account balance, or = how > to correct the problem. If these details are included in the > response body in a machine-readable format, the client can treat it > appropriately." >=20 > Unless there is a bit more explanation what it could mean for a client > to treat "out of credit" appropriately or how to "correct the problem" > given understanding of the problem semantics. Makes sense; I'll add some text. > IMHO, probem types are so very close to tunneling application = semantics > that it is a good idea to be as clear as possible why HTTP status = codes > are not enough. Otherwise I fear that readers just take it as a best > practice to solve with a zillion of problem types what could be solved = by > good resource design. [I know we have been here already, but since = this is > sort of last call, I say it again :-)] If you have suggested text, I'm all ears; I tried to address this in the = draft. > 3.2 Optional Members >=20 > "httpStatus" (number) - Can you substitute "number" by the production = for > HTTP status codes? E.g. IIS wrongly produces a hord of xxx.yy status > codes for finde grained, tunneled, error semantics. People might be = tempted to > copy these as values for httpStatus. OK. > "detail" (string) - I fail to understand how "detail", being a string, = can help > a client do anything (expect display the string). Can you explain? One use would be for an intermediary or other generic implementation = when they're logging. > 4.1. Example >=20 > The sentences >=20 > "If one is available, you can reuse that URI by > documenting use of both this specification and that specific URI > value in your API." >=20 > and >=20 > "This information could appear within the rest of your > API's documentation" >=20 > contradict the idea that true HTTP APIs do not need documentation and > that such documentation creates expectations that get hard coded and > introduce coupling. It is a slippery slope to mention in a spec that > will likely receive widespread attention given its editor :-) Without getting into a debate about the One True HTTP API, they *do* = need to document media types and link relations, at a minimum. But I digress. I'll try to reword. Thanks for the feedback! -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Thu May 30 02:07: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 48EB421F9825 for ; Thu, 30 May 2013 02:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.08 X-Spam-Level: X-Spam-Status: No, score=-105.08 tagged_above=-999 required=5 tests=[AWL=-2.481, 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 tPcitqfVYSIc for ; Thu, 30 May 2013 02:07:42 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id BF83621F9815 for ; Thu, 30 May 2013 02:07:41 -0700 (PDT) Received: from [192.168.1.80] (unknown [118.209.184.230]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8E04F22E253; Thu, 30 May 2013 05:07:34 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Mark Nottingham In-Reply-To: Date: Thu, 30 May 2013 19:07:30 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <91AEBA22-6335-475D-A1A5-E1FC5575CD63@mnot.net> References: <255B9BB34FB7D647A506DC292726F6E1151A6C8594@WSMSG3153V.srv.dir.telstra.com> To: James M Snell X-Mailer: Apple Mail (2.1503) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] merge-patch: more examples X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 09:07:46 -0000 Whatever makes sense; do you want a new repo under json-patch, or...? Cheers, On 22/05/2013, at 2:14 AM, James M Snell wrote: > Agreed. The example test cases in the spec are intended to help > bootstrap such an effort. If you'd like to get a repo set up, or, > perhaps, if Mark would be willing to let us expand the existing repo > to deal with merge-patch tests, I'll contribute whatever test casesI > can. >=20 > On Tue, May 21, 2013 at 8:35 AM, Steve Klabnik = wrote: >> It might also be nice to make an analogue to >> https://github.com/json-patch/json-patch-tests > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From James.H.Manger@team.telstra.com Thu May 30 07:44: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 7602E21F900C for ; Thu, 30 May 2013 07:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.326 X-Spam-Level: X-Spam-Status: No, score=-1.326 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBWACBomyAAx for ; Thu, 30 May 2013 07:44:02 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id D97A321F84E7 for ; Thu, 30 May 2013 07:43:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,770,1363093200"; d="scan'208";a="138766744" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipocvi.tcif.telstra.com.au with ESMTP; 31 May 2013 00:43:58 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7090"; a="135466832" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipccvi.tcif.telstra.com.au with ESMTP; 31 May 2013 00:43:58 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Fri, 31 May 2013 00:43:57 +1000 From: "Manger, James H" To: Carsten Bormann , "apps-discuss@ietf.org Discuss" Date: Fri, 31 May 2013 00:43:55 +1000 Thread-Topic: [apps-discuss] Concise Binary Object Representation (CBOR) -- new version -01 Thread-Index: Ac5cfEOWtzHUUtSzSYep0KyqLU0huQAwMSiw Message-ID: <255B9BB34FB7D647A506DC292726F6E1151AD1BCC3@WSMSG3153V.srv.dir.telstra.com> References: <8D8A0953-FE0D-428D-9E57-27376FA5986D@tzi.org> In-Reply-To: <8D8A0953-FE0D-428D-9E57-27376FA5986D@tzi.org> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) -- new version -01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 14:44:09 -0000 PiBCYXNlZCBvbiB0aGUgc3Vic3RhbnRpdmUgZmVlZGJhY2sgd2UgcmVjZWl2ZWQgaGVyZSwgd2Ug aGF2ZSBzdWJtaXR0ZWQNCj4gZHJhZnQtYm9ybWFubi1jYm9yLTAxLg0KPiANCj4gVGhlIG1ham9y IG5ldyBhZGRpdGlvbiBpcyBzdXBwb3J0IGZvciBzdHJlYW1pbmcgb2YgYXJyYXlzIGFuZCBtYXBz IGFuZA0KPiBjaHVua2luZyBvZiBzdHJpbmdzLg0KDQoNCkNCT1IgZHJhZnQgMDEgbG9va3MgZ3Jl YXQuDQpTdHJlYW1pbmcgc3VwcG9ydCBmaXRzIGluIHdpdGhvdXQgdG9vIG11Y2ggZGFtYWdlIHRv IHRoZSBzdHJ1Y3R1cmUuIFRoYW5rcy4NCg0KSSB3cm90ZSBhIENCT1IgZGVjb2RlciBbSmF2YTsg RE9NLXN0eWxlOyAyNDQgbG9jXSBhbmQgaXQgYWdyZWVkIHdpdGggYWxsIHRoZSBleGFtcGxlcyAo ZXhjZXB0IDE2LWJpdCBmbG9hdHMgdGhhdCBJIGhhdmVuJ3QgaW1wbGVtZW50ZWQ7IGFuZCBpbnRl Z2VycyAyXjY0IC0gMSBhbmQgLTJeNjQgd2hpY2ggZG9uJ3QgZml0IGluIEphdmEncyA2NC1iaXQg c2lnbmVkIGxvbmcpLg0KDQpWZXJ5IG1pbm9yIGNvbW1lbnQ6DQpJbiBteSBleHBlcmllbmNlIGJh c2U2NHVybCBpcyBpbnZhcmlhYmx5IHVzZWQgd2l0aG91dCAiPSIgcGFkZGluZywgd2hpbGUgYmFz ZTY0IGlzIGludmFyaWFibHkgdXNlZCB3aXRoICI9IiBwYWRkaW5nLiBJIHdvdWxkIGRlZmluZSB0 YWdzIDIxICYgMjIgYXMgc3VjaCwgaW5zdGVhZCBvZiBzYXlpbmcgbm8gcGFkZGluZyBpcyB1c2Vk IGZvciBlaXRoZXIgW2luIDIuMy41LjIuIEV4cGVjdGVkIExhdGVyIEVuY29kaW5nIGZvciBDQk9S IHRvIEpTT04gQ29udmVydGVyc10uDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== From jasnell@gmail.com Thu May 30 09: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 A361A21F8517 for ; Thu, 30 May 2013 09:03:40 -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 q2S1gw1tsGso for ; Thu, 30 May 2013 09:03:40 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 59A6B21F856D for ; Thu, 30 May 2013 09:02:05 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id wo10so956478obc.3 for ; Thu, 30 May 2013 09:01:42 -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=zNL5o95KCyb2jV4S3SIRwxDA4LWkD9RQIDySISQpxac=; b=xUiBEWhUp0zwuPM+GnLJDb7QwpBywbHxveDcL2YjbIZ6EJQWHU74HPuzB89YQWOBjp h/njRs+jtf8VaBL39CP80YelAIZhwhe9yoVnE799BQUjODoxGzE0drGVwh4HPUqrVkoD ClzARhABAh9j4zi7ZZ+T00pJ0J2DTE8OSqhMviC24x+SedOX25b4LQOMgJbfzf2DrRcA bBnxexq4Ap6HxZA4o0wo5cWyYfgnSlgKffMQ7n079ISQ+7xEtqLInRcQ42vo7eCS+Cts YkHHHBmRXpvDM81LnAcR78z9Drwt9nfh/YXLCEAv41yaMPQxMHN6V2zJbPg2zigMWYRg /h3Q== X-Received: by 10.182.227.133 with SMTP id sa5mr4244534obc.96.1369929702473; Thu, 30 May 2013 09:01:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.3.137 with HTTP; Thu, 30 May 2013 09:01:22 -0700 (PDT) In-Reply-To: <91AEBA22-6335-475D-A1A5-E1FC5575CD63@mnot.net> References: <255B9BB34FB7D647A506DC292726F6E1151A6C8594@WSMSG3153V.srv.dir.telstra.com> <91AEBA22-6335-475D-A1A5-E1FC5575CD63@mnot.net> From: James M Snell Date: Thu, 30 May 2013 09:01:22 -0700 Message-ID: To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] merge-patch: more examples X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 May 2013 16:03:40 -0000 New repo would likely be good. On Thu, May 30, 2013 at 2:07 AM, Mark Nottingham wrote: > Whatever makes sense; do you want a new repo under json-patch, or...? > > Cheers, > > On 22/05/2013, at 2:14 AM, James M Snell wrote: > >> Agreed. The example test cases in the spec are intended to help >> bootstrap such an effort. If you'd like to get a repo set up, or, >> perhaps, if Mark would be willing to let us expand the existing repo >> to deal with merge-patch tests, I'll contribute whatever test casesI >> can. >> >> On Tue, May 21, 2013 at 8:35 AM, Steve Klabnik wrote: >>> It might also be nice to make an analogue to >>> https://github.com/json-patch/json-patch-tests >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > -- > Mark Nottingham http://www.mnot.net/ > > > From nico@cryptonector.com Fri May 31 09:55: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 7B2D321F8609 for ; Fri, 31 May 2013 09:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[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 ftuOMs84yvMJ for ; Fri, 31 May 2013 09:55:34 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 1A77721F8E8F for ; Fri, 31 May 2013 09:55:31 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id C45C6674089 for ; Fri, 31 May 2013 09:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=J2DKVjH0GJdj/rVJSOs3 /r/Hu80=; b=U14eevoA7zPaPOxu7vdJNDdUVoTOXNYXGnFYqQdXEMEKyQbRQAQH sESwpJaKukNUGUCKQeInLbv9HuCt1CEL1P5FAHdjTwXGq2+mhIy6860cDO25kjYB klBfnD3YuThEr8kyWJ7dVcgau2cMZ4JH7nFdc/Zt8kaf38p20UqAh8I= Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 2FF426740A4 for ; Fri, 31 May 2013 09:53:09 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id q56so1436478wes.23 for ; Fri, 31 May 2013 09:53:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pkNKQI0Mq3+bIxA0O5j56Jvv+NGySe25mDdxTuz4xho=; b=CzKi/jTHlVKLXQBP6ENug7X5NQkMUs146qT6TF1SuSKg1t87g/qyI+s4xGkEGzPg8Z O69KyJmtCZ4khcMotHDJOlaGrcoxQgqwoWdUd0mZpHeKLHppSgchlUAtt37RG8PAXFmY /LJt5Qn+gIYYb/1X+/tBQIzaszP0vfPB9YynjR92gHf0SZ6YLzNzfW0ze5QkTl5cCfTK YbAN1YX62G61CZzNChMJwbctlOBl7L1twXvMQyxXSZgoAtRRmYoFdniM/RZiGu7fQuqH hb1fmUznz6jLQpkmHbgdDegt6oiAWxSUhnQ6OQKFLSod0m7zmzdKowUhRfn7SXXsJR9R gDwg== MIME-Version: 1.0 X-Received: by 10.194.83.5 with SMTP id m5mr10320075wjy.20.1370019186357; Fri, 31 May 2013 09:53:06 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Fri, 31 May 2013 09:53:06 -0700 (PDT) In-Reply-To: <8D8A0953-FE0D-428D-9E57-27376FA5986D@tzi.org> References: <8D8A0953-FE0D-428D-9E57-27376FA5986D@tzi.org> Date: Fri, 31 May 2013 11:53:06 -0500 Message-ID: From: Nico Williams To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) -- new version -01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 16:55:38 -0000 Comments on -01: - Do tags stack/nest? I.e., could you have a chunked bignum? - Chunking cannot be optional. Therefore tags can't be "truly optional". - I'm concerned about chunking being a tag. In particular I'm concerned about what tag stacking combinations are permitted (see above), about chunking being optional because tags are optional, and about chunking being a bit of a bolt-on. I think I'd recommend using type 7 to indicate that some of the remaining 5 bits of the type byte carry type information -- that is, make chunking "first class". - JSON cannot provide a strict upper bound on CBOR encoding size. It should be trivial to construct a JSON value that takes up more room using CBOR than JSON (for example: any printable ASCII string (with no embedded newlines) whose length requires more than two bytes to encode). OLD: Stream parser: A process that decodes a data stream and makes each of the data items in the sequence available to an application. NEW: Stream parser: A process that decodes a data stream and makes each of the data items in the sequence available to an application as they are received. - There's also streaming encoders. On the encoder side the cause of the need for indefinite length encoding / chunking is lack of knowledge about the size of source values (the encoder's input is a "stream"), or the receiver's need for the same for the same reason regarding the sink. That is, either the source or the sink can create a need for streaming. In particular, having JSON "piped" in to a JSON->CBOR encoder the encoder cannot use definite lengths nor non-chunked strings for values that don't fit in its buffers. On the receiver side one can imagine CBOR being used to transport data to be processed in a streaming way by a tool like stedolan.github.io/jq (a streaming JSON query processor, a JSON sed of sorts), which might make progress with partially-transferred values. Anyways, -01 is better than -00. Nico -- From jhildebr@cisco.com Fri May 31 10:42: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 BFF8E21F8F6E for ; Fri, 31 May 2013 10:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8 X-Spam-Level: X-Spam-Status: No, score=-8 tagged_above=-999 required=5 tests=[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 ylg-dCzNVJpa for ; Fri, 31 May 2013 10:42:36 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id CCC4221F8F4D for ; Fri, 31 May 2013 10:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2970; q=dns/txt; s=iport; t=1370022157; x=1371231757; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=SkQb7FrXQ6Mv9izIDOfvUN4FvrZRuL33gDawtyagJ2s=; b=ZQRI15vx/uvYHqPy9rOgbu0ipk9i9FNJNxFXPXDEvlg477onnfX/s+9B F+HSuhSWSrdyskYc8llLz+TTr45D/srMbiyg8giFRY8MYFgSBIq4yCS7x vASNrK9sHs4n50+Sx/6ms/5r9hjQtn2WFx3dEBycEOGsKj1uK5NegGakE 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQFABngqFGtJXHB/2dsb2JhbABagwmDbLsyDXUWdIIlAQQjEUUSAQgaAgYgAgQwFRACBAENBQiIBahpkVqBJo1IAjEHgkMzYQOofoFYgTeCJw X-IronPort-AV: E=Sophos;i="4.87,780,1363132800"; d="scan'208";a="217293119" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 31 May 2013 17:42:36 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4VHgaVf025404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 May 2013 17:42:36 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Fri, 31 May 2013 12:42:36 -0500 From: "Joe Hildebrand (jhildebr)" To: Nico Williams , Carsten Bormann Thread-Topic: [apps-discuss] Concise Binary Object Representation (CBOR) -- new version -01 Thread-Index: AQHOXh+vWIyaMMbwPkKPk7DNMOeEx5kff3KA Date: Fri, 31 May 2013 17:42:34 +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.4.130416 x-originating-ip: [64.101.72.52] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) -- new version -01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 17:42:42 -0000 T24gNS8zMS8xMyAxMDo1MyBBTSwgIk5pY28gV2lsbGlhbXMiIDxuaWNvQGNyeXB0b25lY3Rvci5j b20+IHdyb3RlOg0KDQoNCj5Db21tZW50cyBvbiAtMDE6DQo+DQo+IC0gRG8gdGFncyBzdGFjay9u ZXN0PyAgSS5lLiwgY291bGQgeW91IGhhdmUgYSBjaHVua2VkIGJpZ251bT8NCg0KQW4gZWFybGll ciB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBleHBsaWNpdGx5IGZvcmJpZCB0aGlzLCBidXQgSSBjYW4n dCBmaW5kDQp0aGUgbGFuZ3VhZ2UgYW55bW9yZS4gIENhcnN0ZW4sIGlzIHRoYXQgaW50ZW50aW9u YWw/ICBJdCB3b3VsZCBiZSBmaW5lDQp3aXRoIG1lIGlmIHRoZXkgd2VyZSBzdGlsbCBmb3JiaWRk ZW4sIGZyb20gYW4gZWFzZSBvZiBpbXBsZW1lbnRhdGlvbg0KcGVyc3BlY3RpdmUuDQoNCj4gLSBD aHVua2luZyBjYW5ub3QgYmUgb3B0aW9uYWwuICBUaGVyZWZvcmUgdGFncyBjYW4ndCBiZSAidHJ1 bHkgb3B0aW9uYWwiLg0KDQpUaGUgdGFnIGp1c3Qgc2F5cyB0byByZWNvbWJpbmUgdGhlIGNodW5r cyBpbnRvIGEgc2luZ2xlIG9iamVjdC4gIFdpdGhvdXQNCnRoZSB0YWcsIHlvdSBnZXQgYW4gYXJy YXksIHdoaWNoIGlzIGFkZXF1YXRlbHkgcGFyc2VhYmxlLg0KDQo+IC0gSSdtIGNvbmNlcm5lZCBh Ym91dCBjaHVua2luZyBiZWluZyBhIHRhZy4gIEluIHBhcnRpY3VsYXIgSSdtDQo+Y29uY2VybmVk IGFib3V0IHdoYXQgdGFnIHN0YWNraW5nIGNvbWJpbmF0aW9ucyBhcmUgcGVybWl0dGVkIChzZWUN Cj5hYm92ZSksIGFib3V0IGNodW5raW5nIGJlaW5nIG9wdGlvbmFsIGJlY2F1c2UgdGFncyBhcmUg b3B0aW9uYWwsIGFuZA0KPmFib3V0IGNodW5raW5nIGJlaW5nIGEgYml0IG9mIGEgYm9sdC1vbi4g IEkgdGhpbmsgSSdkIHJlY29tbWVuZCB1c2luZw0KPnR5cGUgNyB0byBpbmRpY2F0ZSB0aGF0IHNv bWUgb2YgdGhlIHJlbWFpbmluZyA1IGJpdHMgb2YgdGhlIHR5cGUgYnl0ZQ0KPmNhcnJ5IHR5cGUg aW5mb3JtYXRpb24gLS0gdGhhdCBpcywgbWFrZSBjaHVua2luZyAiZmlyc3QgY2xhc3MiLg0KDQpT ZWUgc2VjdGlvbiAyLjQ7IGl0IHNlZW1zIGxpa2UgeW91J3ZlIGFscmVhZHkgZ290IHdoYXQgeW91 IHdhbnQuICBXaGVuIEkNCnJlYWQgMi4zLjQgd2l0aG91dCBoYXZpbmcgcmVhZCB0aGUgbmV3IGJp dHMgaW4gTVQ0IGFuZCBNVDUsIEkgdGhvdWdodCB0aGUNCnNhbWUgdGhpbmcuICBJIGhhZCB0byBy ZS1yZWFkIHRob3NlIG90aGVyIGJpdHMgYmVmb3JlIEkgZ290IGl0Lg0KDQo+IC0gSlNPTiBjYW5u b3QgcHJvdmlkZSBhIHN0cmljdCB1cHBlciBib3VuZCBvbiBDQk9SIGVuY29kaW5nIHNpemUuICBJ dA0KPnNob3VsZCBiZSB0cml2aWFsIHRvIGNvbnN0cnVjdCBhIEpTT04gdmFsdWUgdGhhdCB0YWtl cyB1cCBtb3JlIHJvb20NCj51c2luZyBDQk9SIHRoYW4gSlNPTiAoZm9yIGV4YW1wbGU6IGFueSBw cmludGFibGUgQVNDSUkgc3RyaW5nICh3aXRoIG5vDQo+ZW1iZWRkZWQgbmV3bGluZXMpIHdob3Nl IGxlbmd0aCByZXF1aXJlcyBtb3JlIHRoYW4gdHdvIGJ5dGVzIHRvDQo+ZW5jb2RlKS4NCg0KWWVz LiAgU29tZSBzdHJpbmdzIHRoYXQgYXJlIDI1Ny02NTUzNiBvY3RldHMgbG9uZyB3aWxsIHRha2Ug dXAgYW4gZXh0cmENCm9jdGV0IG9uIHRoZSB3aXJlLiAgSG93ZXZlciwgYXMgbG9uZyBhcyB5b3Un cmUgbm90IHVzaW5nIGNodW5raW5nLCB5b3UNCmhhdmUgY2hhbmNlcyB0byBvcHRpbWl6ZSB0aGUg bnVtYmVyIG9mIHRpbWVzIHlvdSBhbGxvY2F0ZSBtZW1vcnksIGFuZA0KZG9uJ3QgaGF2ZSB0byB3 b3JyeSBhYm91dCBlc2NhcGUgZGVjb2RpbmcsIGJvdGggb2Ygd2hpY2ggYXJlIHF1aXRlIG5pY2UN CkNQVSB3aW5zLg0KDQpBcyB3ZWxsLCBhbmQgbW9yZSBpbXBvcnRhbnRseSBmb3IgbWUsIHlvdSBj YW4gc2VuZCBnZW5lcmljIG9jdGV0IHN0cmVhbXMNCnRoYXQgYXJlIG5vdCB2YWxpZCBVVEY4Lg0K DQo+QW55d2F5cywgLTAxIGlzIGJldHRlciB0aGFuIC0wMC4NCg0KQWdyZWUuICBJdCBhZGRzIGNv bXBsZXhpdHksIGJ1dCBpZiB0aG9zZSBzdHJlYW1pbmcgdXNlIGNhc2VzIGNvbnRpbnVlIHRvDQpi ZSBpbXBvcnRhbnQgdG8gZm9sa3MsIEkgc3VwcG9zZSBpdCdzIG5vdCBlbm91Z2ggY29tcGxleGl0 eSB0aGF0IGl0IGNhbid0DQpiZSB0b2xlcmF0ZWQuDQoNCi0tIA0KSm9lIEhpbGRlYnJhbmQNCg0K DQo= From cabo@tzi.org Fri May 31 10:51: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 88B1221F9058 for ; Fri, 31 May 2013 10:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.65 X-Spam-Level: X-Spam-Status: No, score=-103.65 tagged_above=-999 required=5 tests=[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 BQ7lt4AaL8FZ for ; Fri, 31 May 2013 10:51: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 DBB0E21F9052 for ; Fri, 31 May 2013 10:51: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 r4VHpUtD026191; Fri, 31 May 2013 19:51:30 +0200 (CEST) Received: from [192.168.217.105] (p5489322F.dip0.t-ipconnect.de [84.137.50.47]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id AC6613EA5; Fri, 31 May 2013 19:51:29 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 31 May 2013 19:51:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <630CE43A-6266-46CF-A724-4E36193A25B3@tzi.org> References: To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.1503) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) -- new version -01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 17:51:55 -0000 On May 31, 2013, at 19:42, "Joe Hildebrand (jhildebr)" = wrote: >> - Do tags stack/nest? I.e., could you have a chunked bignum? >=20 > An earlier version of the draft explicitly forbid this, but I can't = find > the language anymore. Carsten, is that intentional? It would be fine > with me if they were still forbidden, from an ease of implementation > perspective. I believe it would be a mistake for the basic syntax to disallow this. Tags already can nest indirectly (e.g., a Decimal could have a bignum as = a mantissa embedded into its two-element array if only Decimal allowed = that). =20 It is hard to justify why the basic syntax should disallow direct = nesting. However, every single tag we have defined so far is explicit about what = can be in it. I don't think the current text allows you to have a chunked bignum = (i.e., a bignum tag around a chunking tag). So we probably have to pay more attention to where we actually do want = tags to directly nest. Gr=FC=DFe, Carsten From paul.hoffman@vpnc.org Fri May 31 11:11: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 B4E4E21F8EF7 for ; Fri, 31 May 2013 11:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 Yi5xc0OQ+8oc for ; Fri, 31 May 2013 11:11:05 -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 93DB021F8FEB for ; Fri, 31 May 2013 11:11:05 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4VIB3Rb015017 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 31 May 2013 11:11:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: Date: Fri, 31 May 2013 11:11:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9FD69DDF-F8CE-4301-AC55-3176B41D244B@vpnc.org> References: <8D8A0953-FE0D-428D-9E57-27376FA5986D@tzi.org> To: Nico Williams X-Mailer: Apple Mail (2.1503) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) -- new version -01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 18:11:06 -0000 On May 31, 2013, at 9:53 AM, Nico Williams = wrote: > - Do tags stack/nest? =20 We have not specified that yet. Clearly we should do so. > I.e., could you have a chunked bignum? We did not anticipate a chunked bignum; is there a non-edge use case for = this?=20 > - Chunking cannot be optional. Therefore tags can't be "truly = optional". Why can chunking not be optional? The program doing the parsing = presumably knows that is expected at this location that is an array. It = thus knows what to do with that array: treat it as a bunch of items, or = combine them into a single large item. Tagging is to allow an encoder to indicate something to the parser, but = every application that knows what it is receiving already knows what the = tag would be indicating. Tagging is thus only useful to generic parsers = that might also do something different if they knew that the incoming = array could be chunked. All of the tags, including chunking, share this = optional feature. > - I'm concerned about chunking being a tag. In particular I'm > concerned about what tag stacking combinations are permitted (see > above), about chunking being optional because tags are optional, and > about chunking being a bit of a bolt-on. I think I'd recommend using > type 7 to indicate that some of the remaining 5 bits of the type byte > carry type information -- that is, make chunking "first class". See above. I'm not sure where that would be needed other than for a = generic parser, but I could be missing it. > - JSON cannot provide a strict upper bound on CBOR encoding size. It > should be trivial to construct a JSON value that takes up more room > using CBOR than JSON (for example: any printable ASCII string (with no > embedded newlines) whose length requires more than two bytes to > encode). Correct. Did we say something in the doc that needs to be corrected or = clarified for that point? > OLD: > Stream parser: A process that decodes a data stream and makes each > of the data items in the sequence available to an application. > NEW: > Stream parser: A process that decodes a data stream and makes each > of the data items in the sequence available to an application as = they are > received. Sounds good. > - There's also streaming encoders. On the encoder side the cause of > the need for indefinite length encoding / chunking is lack of > knowledge about the size of source values (the encoder's input is a > "stream"), or the receiver's need for the same for the same reason > regarding the sink. That is, either the source or the sink can create > a need for streaming. In particular, having JSON "piped" in to a > JSON->CBOR encoder the encoder cannot use definite lengths nor > non-chunked strings for values that don't fit in its buffers. That's not true as long as the encoder can jump to a particular place in = its buffer. Such an encoder uses a length for the array that is large = enough to fit anything that it could hold, accepts all of the data and = counts as it comes in, then jumps back to the length value and fills it = in. > On the receiver side one can imagine CBOR being used to transport > data to be processed in a streaming way by a tool like > stedolan.github.io/jq (a streaming JSON query processor, a JSON sed of > sorts), which might make progress with partially-transferred values. >=20 > Anyways, -01 is better than -00. Good to hear. --Paul Hoffman= From nico@cryptonector.com Fri May 31 13:12: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 2C94221F85BF for ; Fri, 31 May 2013 13:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[AWL=1.299, 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 jEkxvas2N222 for ; Fri, 31 May 2013 13:12:25 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 67F0821F85B8 for ; Fri, 31 May 2013 13:12:25 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 25EBC3B806C for ; Fri, 31 May 2013 13:12:25 -0700 (PDT) Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id 3435A3B805B for ; Fri, 31 May 2013 13:12:04 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id q58so86894wes.33 for ; Fri, 31 May 2013 13:12:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=SyJ8ZsmQqJdxuR1xPRR3hJp+EdPu8+bipyg/Ju2y0Fo=; b=ZnlbPefuDj3QLa/HavBx14hoLRNwcOQ0hB/R7jK06evxkLyhJprSlCn9SqnyuMVrBH DCWgIigsDxOqKmUvhqGVCg8VszLG1JtAjVoyV/Vs1cF5/nBq/3yszjtjBxCaTQGEvu6C ZK/ymtvuDwz8KuykDHb5OrLtGrDLt1wgh131V9DR0Dkp3JKqy6N862LWWuTDUwUbDxwT uGYNNZWo/bu7ymZlA5Cz8O7oLCKqOxYZLwoS7NAcjElo4Sb1mDRY85oiG+f/x0nbsDTE 6QUEII2vi5Q3etQ6f8W57puKli3kZgwgKU+iYXf38xr83o1HuFf1d6jQZTVriqZXZFtp /m3w== MIME-Version: 1.0 X-Received: by 10.180.183.139 with SMTP id em11mr4783771wic.16.1370031122752; Fri, 31 May 2013 13:12:02 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Fri, 31 May 2013 13:12:02 -0700 (PDT) In-Reply-To: <9FD69DDF-F8CE-4301-AC55-3176B41D244B@vpnc.org> References: <8D8A0953-FE0D-428D-9E57-27376FA5986D@tzi.org> <9FD69DDF-F8CE-4301-AC55-3176B41D244B@vpnc.org> Date: Fri, 31 May 2013 15:12:02 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) -- new version -01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 20:12:31 -0000 On Fri, May 31, 2013 at 1:11 PM, Paul Hoffman wrote= : > On May 31, 2013, at 9:53 AM, Nico Williams wrote: > >> - Do tags stack/nest? > > We have not specified that yet. Clearly we should do so. Yes. >> I.e., could you have a chunked bignum? > > We did not anticipate a chunked bignum; is there a non-edge use case for = this? Bignums can get very big. That's... their point :) >> - Chunking cannot be optional. Therefore tags can't be "truly optional"= . > > Why can chunking not be optional? The program doing the parsing presumabl= y knows that is expected at this location that is an array. It thus knows w= hat to do with that array: treat it as a bunch of items, or combine them in= to a single large item. Chunking needs to be first-class. Otherwise senders and recipients need to agree a priori (or negotiate) on chunking support -- no thanks! > Tagging is to allow an encoder to indicate something to the parser, but e= very application that knows what it is receiving already knows what the tag= would be indicating. Tagging is thus only useful to generic parsers that m= ight also do something different if they knew that the incoming array could= be chunked. All of the tags, including chunking, share this optional featu= re. I don't agree. Chunking is not semantics. "Date" is. But even there, "date" is important *type* information in many systems, rather than incidental or context-specific (or heuristically determined) information. Chunking is nothing more than a form of indefinite length encoding for strings with an unfortunate name (that might be confusing you as to the essence) -- one that does not require escaping codepoints in the string. In fact, JSON's string encoding *is* indefinite-length, and the price we pay for it is having to escape things in it (ugh!). If you agree that indefinite-length encoding of arrays and objects is required, why would you not also agree that indefinite-length encoding of other potentially huge values is *also* required? The whole point of indefinite-length encoding is to allow for streaming encoding and decoding, which means (in part): with bounded- or fixed-size buffers. If a value blows past a buffer size we lose with definite-length encoding. >> - I'm concerned about chunking being a tag. In particular I'm >> concerned about what tag stacking combinations are permitted (see >> above), about chunking being optional because tags are optional, and >> about chunking being a bit of a bolt-on. I think I'd recommend using >> type 7 to indicate that some of the remaining 5 bits of the type byte >> carry type information -- that is, make chunking "first class". > > See above. I'm not sure where that would be needed other than for a gener= ic parser, but I could be missing it. I think you are missing it :) >> - JSON cannot provide a strict upper bound on CBOR encoding size. It >> should be trivial to construct a JSON value that takes up more room >> using CBOR than JSON (for example: any printable ASCII string (with no >> embedded newlines) whose length requires more than two bytes to >> encode). > > Correct. Did we say something in the doc that needs to be corrected or cl= arified for that point? The doc doesn't say that was a strict goal. I'm just pointing out a nit. >> - There's also streaming encoders. On the encoder side the cause of >> the need for indefinite length encoding / chunking is lack of >> knowledge about the size of source values (the encoder's input is a >> "stream"), or the receiver's need for the same for the same reason >> regarding the sink. That is, either the source or the sink can create >> a need for streaming. In particular, having JSON "piped" in to a >> JSON->CBOR encoder the encoder cannot use definite lengths nor >> non-chunked strings for values that don't fit in its buffers. > > That's not true as long as the encoder can jump to a particular place in = its buffer. Such an encoder uses a length for the array that is large enoug= h to fit anything that it could hold, accepts all of the data and counts as= it comes in, then jumps back to the length value and fills it in. The key word in your response there is "buffer". Picture a fixed-sized buffer. There's no way to "jump" to some place in the buffer that's out of the buffer's bounds. Being able to set max buffer sizes is very important. It allows one to limit the resources that a sink can made to consume by a source (not even peer, because for an encoder there's still a source) before realizing that the data is bad (and slam the door). Or even if you think beyond security, to stream from/to disk on a system with thousands of concurrent users, one user forcing you to consume 10GB of buffer space can ruin the others' day. I don't think you can escape the conclusion that indefinite-length encoding is needed for *every* value whose encoding is unbounded (e.g., null, booleans, doubles don't need indefinite-length encoding, while strings, arrays, objects, and yes, even bignums, do). Nico -- From cabo@tzi.org Fri May 31 13: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 ED35921F9079 for ; Fri, 31 May 2013 13:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=0.650, 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 DGtSVKkCTwqs for ; Fri, 31 May 2013 13:23:48 -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 AFCA821F8D90 for ; Fri, 31 May 2013 13:23:47 -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 r4VKNf2j019791; Fri, 31 May 2013 22:23:41 +0200 (CEST) Received: from [192.168.217.105] (p5489322F.dip0.t-ipconnect.de [84.137.50.47]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D07843EE6; Fri, 31 May 2013 22:23:40 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 31 May 2013 22:23:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8DF8E01E-EB27-431A-A19A-A25926BA53AC@tzi.org> References: <8D8A0953-FE0D-428D-9E57-27376FA5986D@tzi.org> <9FD69DDF-F8CE-4301-AC55-3176B41D244B@vpnc.org> To: Nico Williams X-Mailer: Apple Mail (2.1503) Cc: Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) -- new version -01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 20:23:54 -0000 On May 31, 2013, at 22:12, Nico Williams wrote: >>> I.e., could you have a chunked bignum? >>=20 >> We did not anticipate a chunked bignum; is there a non-edge use case = for this? >=20 > Bignums can get very big. That's... their point :) This is just proof by lack of imagination, but I can't imagine = serializing a bignum the size of which you don't know by the time you = start serializing it. Looking at the other tags that accept strings, the 30+ tags probably all = want to accept chunking. Of course, we could redefine them to just accept arrays with chunking = semantics, saving a byte. (21 to 23 can't be redefined that way unless we lose the "all the things = in this map/array are base64url" semantics.) With respect to the first class thing: Nothing stops us from = proclaiming 0xc5 "first class". It's still a tag in the big scheme of things, but probably one that you = do want to implement along with the streaming arrays and maps. (In hindsight, I should have given it tag 15 =3D 0xcf to make this look = more symmetric alongside 0x9f, 0xbf, 0xff :-) Symmetry always is appealing. To add more apparent symmetry, we can always change it to 0xdf :-) Gr=FC=DFe, Carsten From nico@cryptonector.com Fri May 31 13:34: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 95F5A21F8E41 for ; Fri, 31 May 2013 13:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_BACKHAIR_44=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 FTW+juP6jFnj for ; Fri, 31 May 2013 13:34:40 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id DE7C021F8E2C for ; Fri, 31 May 2013 13:34:34 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 8DF9C21DE59 for ; Fri, 31 May 2013 13:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=iff4R8eXIVI/VC+Ws1Tk 9C6/tkY=; b=w7/p/bPoy8fxPVd4qHY3rMj9jAniXJqExjvuRdTF8UQgeFYNf7QS +Cg0su2rVCQIB7T/8xKKpMlkiC21cwyEpa1gMLfMJ05A657Me6AH1YY6OCvCbxnc SofoIpoQzQXg4VHEADLqZz5StcR4QtOjd3mPgUMCJuNHELaubRJqvqs= Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 4FA8221DE77 for ; Fri, 31 May 2013 13:33:45 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hr14so1127978wib.3 for ; Fri, 31 May 2013 13:33:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wjsBv+TYDy6acyr+SwbOfyjXTF5mrAk/KkvEUeH63jQ=; b=lYQtF5JLiQmT2hzHWQ3WHngVQ2crojZNkhECtrkWBwHvuOlN2x6hIdLjo6ASvtN9Ef CPzSWx58QMBq9WDOTbxdqW9k6RvxNuAOvr0MOxmNFtMTezRujX/ggZ9NWLuPmAmLzF0N vZ4CZwJLvSp5davydGVRzsv71hTxIm7pywAL9hjFhDEWf/p1/+AbShukVYS4MkEIGGo1 cP5+hRhOz0PG8RHvVkWi7G0dNyca1vdqRfDFe6UgEY3B+fKpaQLFq5CBn5RnERL1L+ga 4p8Kf4GrR/OXBH+qLbuounDZr0IAcYvxG9y+qepBbyllFJfAfl+GvaHglek6JJXWvhBj pPeQ== MIME-Version: 1.0 X-Received: by 10.194.104.105 with SMTP id gd9mr11069226wjb.1.1370032418120; Fri, 31 May 2013 13:33:38 -0700 (PDT) Received: by 10.216.63.136 with HTTP; Fri, 31 May 2013 13:33:37 -0700 (PDT) In-Reply-To: <8DF8E01E-EB27-431A-A19A-A25926BA53AC@tzi.org> References: <8D8A0953-FE0D-428D-9E57-27376FA5986D@tzi.org> <9FD69DDF-F8CE-4301-AC55-3176B41D244B@vpnc.org> <8DF8E01E-EB27-431A-A19A-A25926BA53AC@tzi.org> Date: Fri, 31 May 2013 15:33:37 -0500 Message-ID: From: Nico Williams To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Cc: Paul Hoffman , "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) -- new version -01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 20:34:45 -0000 On Fri, May 31, 2013 at 3:23 PM, Carsten Bormann wrote: > On May 31, 2013, at 22:12, Nico Williams wrote: > >>>> I.e., could you have a chunked bignum? >>> >>> We did not anticipate a chunked bignum; is there a non-edge use case for this? >> >> Bignums can get very big. That's... their point :) > > This is just proof by lack of imagination, but I can't imagine serializing a bignum the size of which you don't know by the time you start serializing it. Imagine JSON had bignums (doesn't, but imagine). Imagine JSON's bignum encoding as indefinite-length (like *everything* else in JSON). Imagine you were writing a fixed-buffers JSON<->CBOR converter. > Looking at the other tags that accept strings, the 30+ tags probably all want to accept chunking. > Of course, we could redefine them to just accept arrays with chunking semantics, saving a byte. > (21 to 23 can't be redefined that way unless we lose the "all the things in this map/array are base64url" semantics.) No, really, chunking is just indefinite-length encoding for string-like values. We need it for the same reasons that we need indefinite-length encoding for arrays and objects. If you disagree, then please explain the distinction between the two kinds of values (strings on one side, arrays/objects on the other). > With respect to the first class thing: Nothing stops us from proclaiming 0xc5 "first class". You made it "truly optional". (Not OPTIONAL, but proper use of RFC2119 words is a separate nit; I assume you meant OPTIONAL.) > Symmetry always is appealing. > To add more apparent symmetry, we can always change it to 0xdf :-) I don't care about aesthetics here. I care about having indefinite-length encodings for *all* values that lack a bounded encoded size. That's a form of symmetry, but higher up in the stack. I don't mind chunking being expressed with a tag, as long as it's REQUIRED and as long as it's clear what other tags it can be mixed with. (The fact that chunking was made a tag made me nervous because it made it seem like an after-thought, and I'm now convinced that's just what it was. You misunderstood the point of chunking, it's being just another way of saying "indefinite-length without escaping". I can see why you thought that my complaint as about lack of symmetry in the details of encoding, but it wasn't.) Nico -- From markus.lanthaler@gmx.net Fri May 31 16:32: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 4F1A221F8F2F for ; Fri, 31 May 2013 16:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.45 X-Spam-Level: * X-Spam-Status: No, score=1.45 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 3ftiMg6digVx for ; Fri, 31 May 2013 16:31:58 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5F50421F83EF for ; Fri, 31 May 2013 16:31:06 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Laq3S-1TyTS43Ski-00kMsF for ; Sat, 01 Jun 2013 01:31:04 +0200 Received: (qmail invoked by alias); 31 May 2013 23:31:04 -0000 Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp002) with SMTP; 01 Jun 2013 01:31:04 +0200 X-Authenticated: #419883 X-Provags-ID: V01U2FsdGVkX1+80OxM9yO8aF8e0tDv6iPQqWOoF8IsUTWsO30zCI fERiGL8kWoO/uI From: "Markus Lanthaler" To: "'Ioseb Dzmanashvili'" References: <4038B5FE76874C54A819A07FE192AEF8@gmail.com> <51a53d34.48b40e0a.70fc.1549SMTPIN_ADDED_BROKEN@mx.google.com> <51a54dfa.086f0e0a.693f.2ff4SMTPIN_ADDED_BROKEN@mx.google.com> <51a64b5f.87000e0a.78ef.ffff87a2SMTPIN_ADDED_BROKEN@mx.google.com> <87194C5A218E42F9AA9B81339D2C1BC5@gmail.com> In-Reply-To: <87194C5A218E42F9AA9B81339D2C1BC5@gmail.com> Date: Sat, 1 Jun 2013 01:30:59 +0200 Message-ID: <024601ce5e56$ea9206c0$bfb61440$@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: Ac5cqClz0wCu4GdXQIGfoKm6iAefrgBqi6Rw Content-Language: de X-Y-GMX-Trusted: 0 Cc: 'IETF Apps Discuss' , link-relations@ietf.org Subject: Re: [apps-discuss] NEW RELATION: property and context X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 31 May 2013 23:32:03 -0000 On Wednesday, May 29, 2013 10:08 PM, Ioseb Dzmanashvili wrote: > > This is right at the heart of my first question: How does the client > know to fetch /article/photo;prop1 instead of /article/photo;prop2? > > > > There are only two options here: a) code against the target URL or = b) > > code against the title attribute. Since you said b) is used = exclusively > > for rendering purposes I assume you would code your client against = the > > URL (or parts thereof) which would go against the fundamental idea = of > > typed links. > > Both options are wrong. >=20 > > a) code against the target URL or >=20 > 1) the "property" link relation is enough to indicate that target > resource is a property and allow agents to distinguish these links = form > others; Yes, distinguish from other rels, but not enough to distinguish two = properties as in your example: *** RESPONSE: Photo representation *** HTTP/1.1 200 OK Content-Type: image/jpeg Content-Length: ... Link: ; rel=3D"property"; title=3D"Property 1", ; rel=3D"property"; title=3D"Property 2", > 2) additional semantics can be provided with extension link relations > and there is nothing wrong with it, it doesn't violate anything nor = can > be considered as anti pattern. Right, but the question I ask myself then is why you need the generic = "property" relation then. > 3) your argument implicitly claims that there exists only M2M > interaction which is also wrong. there are also GUI apps for which = it's > enough to just know that some of links are properties(identified by = the > "property" relation) Hmm... it helps you to render just the property links, yes. But then the = user has to choose the right link based on the title attribute. > 4) having a general purpose link relation makes it useful and reusable > from application to application, it eliminates need to redefine each > time what "property" is and is media format agnostic. shared > understanding is important i believe and additional semantics for each > specific property is solvable on another level. Right, but property is so generic that I have problems seeing its value. = This goes a bit in the direction of Jan's question. Would you think the = following would be a reasonable design choice: Link: ; rel=3D"link" This allows your application to render all "link" links but by itself = doesn't add any semantics beyond the ones the Link header already has. [...] > > Hmm.. I do partly agree for the /article/photo -> /article link but > > would argue that /article/photo;prop1 does *describe* = /article/photo. > > Similarly it could be argued that /article/photo *isDescribedBy* > > /article. > > Are you sure that "describedby" and "describes" relations give enough > semantics to agents? is not it necessary to provide some kind of > description? Yes, this alongside the media type of the referenced/referencing = resource provides enough semantics for an agent to do something useful = with it. > if one describes another how it is described? The media type defines that. One obvious answer is e.g. RDF. > and what it > gives to agent particularly in M2M interaction case? do automated > agents strangely become smart and happy when they just identify typed > links annotated with those relations? No, but they do know that they can follow the link to get a description = which they (may) understand. You could argue that the same is true for = properties/contexts but that would mean that you, e.g., would have to = define media types for all properties so that clients can express what = they understand. Just returning a string as text/plain for a title = property is definitely not enough to enable M2M communication without = having to rely on out-of-band information. > > So you want to express a relationship without any specific = semantics? > > In that case, why do you need a typed link? Can't you just use a > > untyped one? > > Than how GUI or automated agent will distinguish resources which are > properties accessible individually from for example the "edit" or > "edit-form" links? or implementations are going to follow some > convention like: if a link doesn't have relation just display it? or > ignore 'em? or? Displaying just links without relation would be a reasonable design = choice IMO because they do not provide enough semantics to be handled = automatically. Thus, the choice has to be made by the (human) user which = interprets the link's label, i.e., the title attribute. > > If article would be called slideshow or gallery, would you see it > > then? :-) You could say that an article is a collection of > > information, some prose, some images, maybe some movies etc. > > but i didn't say "gallery" or "slideshow" in my example. what if a > resource is an ID card which has only one and only one photo of a > person? do you think that ID card or driving license are collections? First of all, I don't understand why such a link would have to be = exposed on the HTTP layer. If you really want to, I think in such a = specific case it makes much more sense to use a URL as link relation. = You probably don't even have to invent it yourself as other people did = already and you profit in terms of interoperability and code reusability = if you just reuse it. The FOAF Vocabulary e.g., defines a "depiction" = URL which you could use. See: http://xmlns.com/foaf/spec/#term_depiction > and yes i can not say that an article is a collection, not because we > can not say it generally but because what you say is = overgeneralisation > of things. we can discuss everything as a collection and item but what > you say makes me think that "collection", "item", "describes" and > "describedby" link relations suddenly solved whole world problems. :-) You are putting words in my mouth. I tried to show that that = "property" has extremely weak semantics - IMHO too weak. [...] > > Could be any of those. If the article describe the photo you could > > use "describes". If the article is more a collection of information > > (e.g. pictures as in a gallery) you could say it is a "collection" = and > > the photo is an "item". > > could you please point me to the example how article describes photo? > it would be really helpful for me! http://en.wikipedia.org/wiki/Vitruvian_Man *describes* = http://upload.wikimedia.org/wikipedia/commons/2/22/Da_Vinci_Vitruve_Luc_V= iatour.jpg > I believe i know and clearly > understand when i can say that an article is a collection, but does it > make whole world a collection? again, is not it overgeneralisation and > oversimplification of things? No, of course not. But every link is a property of a resource and thus, = again IMO, "property" has too weak semantics for a standardized link = relation. > > Btw. On mailing lists it is typically considered as a best practice > > to write text-only mails. This makes it much easier to quote etc. = Could > > you please update your client settings to send text-only mails = instead > > of HTML formatted mails. Thanks a lot! > > done, thanks for letting me know. Thanks a lot! This definitely makes replying much easier -- Markus Lanthaler @markuslanthaler From mnot@mnot.net Fri May 31 20:14: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 1D58D21F86EC for ; Fri, 31 May 2013 20:14:24 -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 6H9A28GTRvHR for ; Fri, 31 May 2013 20:14:19 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 605D421F84EF for ; Fri, 31 May 2013 20:14:14 -0700 (PDT) Received: from [192.168.1.80] (unknown [118.209.184.230]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A69C922E1F4 for ; Fri, 31 May 2013 23:14:08 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Sat, 1 Jun 2013 13:14:03 +1000 References: To: Apps Discuss Message-Id: <1DD7EF20-4F2A-494E-A471-98875031E5C7@mnot.net> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [apps-discuss] Fwd: [whatwg] [mimesniff] Review request: Parsing a MIME type X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jun 2013 03:14:24 -0000 FYI. Begin forwarded message: > From: "Gordon P. Hemsley" > Subject: [whatwg] [mimesniff] Review request: Parsing a MIME type > Date: 1 June 2013 3:30:56 AM AEST > To: whatwg List >=20 > Hello all, >=20 > This is a request seeking feedback and review on the MIME Sniffing > algorithm to "parse a MIME type": >=20 > http://mimesniff.spec.whatwg.org/#parse-a-mime-type >=20 > After numerous iterations, I think it is in a state that accurately > reflects the best current practices for interoperability. >=20 > As is common with such things, there are numerous points in this > algorithm where implementations do not agree. In general, Firefox and > Chrome tend to pattern together, as do IE and Opera. Safari often > patterns on its own, in favor of a more literal interpretation of the > various RFCs on the matter. >=20 > At times, I have had to make a decision as to which was the best > approach. This usually results in half of the implementations being in > violation of the spec; I hope, in those instances, the implementations > in question can be updated to become interoperable with the rest. >=20 > With that being said, there are two specific points I want to raise: >=20 > (1) The more recent RFCs on the matter restrict type, subtype, and > parameter names to 127 characters. No implementation actually enforces > this limit, but I have included it in the algorithm (relevant points > appear in red) because I think it would be better and safer for both > the user and the user agent to do so. >=20 > (2) Based on my analysis of existing implementations, anything that > occurs between the semicolon (and any first whitespace) and the equals > sign is treated as the parameter name, including any whitespace before > the equals sign. However, in order to test parameters, I have been > using 'charset' (because that's they only one I'm aware of that has a > Web-visible effect), and certain implementations may be sniffing > specifically for the string "charset=3D", which would cloud the = results > of my testing. Any enlightenment into this issue would be much > appreciated. >=20 > I also have a few general points: >=20 > * You may notice in the algorithm that I am using hybrid terminology, > sometimes talking about bytes and sometimes talking about characters. > This is mostly because I haven't decided/determined whether to treat a > MIME type as ASCII or as UTF-8. I think there are arguments on both > sides of the issue, but I'm eager to hear your opinions and advice > (especially about how I might phrase the algorithm if it were written > in terms of characters instead of bytes). >=20 > * One of the most controversial parts of this algorithm might be the > issue of what to do when a parameter appears more than once. (The RFCs > suggest that the MIME type should be treated as invalid in such a > case, but no implementation actually treats it that way.) I have opted > to make a later appearance of a parameter override and replace an > earlier appearance of a parameter. Modulo caveat (2) above, this is > only done in half the implementations; in particular, IE and Opera > appear to use the first instance of the parameter as the canonical > value. >=20 > * Another important point to notice is the fact that this algorithm > allows parameter names to appear without values. This is useful in > situations such as the "base64" option in data: URLs that use the mere > presence or absence of a parameter to set its boolean value. Note, > however, that a parameter that has been given an explicit value (even > if that value is the empty string) does not get overridden by the > later appearance of a boolean parameter of the same name. >=20 > I think those are the important points of background information you > need to know in order to evaluate this algorithm. >=20 > I look forward to your response. >=20 > Regards, > Gordon >=20 > -- > Gordon P. Hemsley > me@gphemsley.org > http://gphemsley.org/ =95 http://gphemsley.org/blog/ -- Mark Nottingham http://www.mnot.net/